团队的软件项目管理和开发流程.docx
《团队的软件项目管理和开发流程.docx》由会员分享，可在线阅读，更多相关《团队的软件项目管理和开发流程.docx（18页珍藏版）》请在冰豆网上搜索。
团队的软件项目管理和开发流程
团队的软件项目管理和开发流程
1目的
● 用于指导公司的技术中心软件开发工作
● 定义了各部门与技术部的协作接口和流程
● 定义了项目开发流程和管理办法
● 定义了任务开发流程和管理办法
2说明
2.1 范围
本文档只适用于技术中心针对网站及其相关的一般性开发工作。
包括：
● 网站维护性开发
● 项目开发
本文档不适用于网站运维护性的系统维护工作。
不涉及：
● 网站的网络安全、权限等
● 数据库的安全、备份等
● 系统环境等
凡网站运维性的系统维护工作请另参见《运维管理规范》文档。
2.2技术中心组织架构
技术中心组织架构图
技术中心组织架构说明
目前技术中心从处理的工作性质分为三大部分：
运维、开发和测试。
根据需求工作量的大和小，其中开发的工作又细分为两类：
● 网站维护开发
● 网站项目开发
根据网站具体的开发工作内容不同，又可将维护开发组和项目开发组的人员细分前台开发人员和后台开发人员。
各小组的职责范围
● 运维组：
处理系统维护性的工作，包括系统安装维护、网络安全、数据库调优备份等。
关于运维的工作本文档不再详细说明，请参见《运维管理规范》文档
● 维护开发组：
处理网站的日常小问题的修改、新需求的增加（但工作量不大）等维护性的开发。
● 项目开发组：
处理新项目的开发。
● 测试组：
负责对维护开发和项目开发进行测试。
● 网站前台开发人员：
负责对网站前台的功能进行开发。
● 网站后台开发人员：
负责对网站后台的用户管理、权限管理、开发、出票等后台的功能进行开发。
由于人力资源的限制，目前没有专职的网站维护开发和项目开发，在没有新项目时，所有人员都可安排参与网站维护开发的工作。
当有新项目时再组建项目组。
但有高优先级的维护工作要处理而又人手不够的情况下，项目组的人员必须优先处理网站维护紧急事件。
2.3项目与任务的定义
什么是开发类项目（项目）
满足以下任意一条件进行开发的项目均为开发类项目：
● 以前从未开发过的系统；
● 不存在或基本不存在可复用的技术、模块，或业务逻辑、体系结构等或者在原产品上进行大的结构性调整。
● 在公司已有的成熟产品或可复用模块或技术基础上，根据业务需要和客户需求，新增独立业务模块，且开发工作量超过1人月，如果是2至3人开发工作但超过2星期根据情况也可划为开发类项目。
新彩种、新玩法、新产品的开发等都可以划为开发类项目。
（此要求没有硬性要求，可以视情况而定。
）
例如：
网站二期项目、增加福彩七乐彩、增加快乐十分游戏、足彩单场项目、无线项目、安微客服项目等。
什么是维护类开发（任务）
● 在现已运行的网站基础上，根据运营的需要或者市场规划的需要，提供补丁、实现新的需求
● 工作量通过技术部经理评估小于1人月但超过1个小时的。
例如：
页面的调整、促销专题页面，日常运营中发现网站的问题等。
3.需求管理
3.1需求来源
需求来源类型：
● 技术部提出
● 运营部（包括客服组）提出
● 市场策划部提出
技术部需求
提出人：
技术部经理或技术骨干
提出原因：
1. 随着网站新加游戏、玩法，注册用户增多等，对网站的可扩展性、稳定性、安全性等提出了更高的要求，在时间允许的情况下，技术部有对网站进行技术优化的需求。
此种情况的执行和跟踪转根据工作量的大和小转项目管理或任务管理。
2. 在用户还未发现的问题，但技术部清楚存在的缺陷，需要对网站进行打补丁升级。
此种情况的执行和跟踪转任务管理。
提交文档：
如果是任务，填写《需求变更申请单（技术部）》；如果是项目，编写《需求说明书》和给出《项目计划（初步）》
运营部需求
提出人：
运营部的所有人员（包括客服、编辑等）
提出原因：
在日常运营过程中会发现一些问题和提一些完善的建议。
网站发布后，面对广大用户，用户在使用过程中会产生大量的问题和意见。
这些问题和意见由客服组统一收集，然后反馈给运营负责人。
根据工作量的大和小转项目管理或任务管理。
提交文档：
如果是任务，填写《需求申请单（运营部）》；如果是项目，编写《需求说明书》和给出《项目计划（初步）》
注：
客服在接收客户的问题和建议后，如果是影响交易的，可以直接向技术部经理反馈，否则把问题反馈给运营负责人，由运营负责人按正常流程处理。
市场策划部需求
提出人：
策划部主管
提出原因：
总结、提炼客户原始需求，推出升级版本、根据市场需要推出新产品、活动促销等。
根据工作量的大和小转项目管理或任务管理。
一般工作量比较大，转项目管理。
提交文档：
如果是任务，填写《需求申请单（策划部）》；如果是项目，编写《需求说明书》和给出《项目计划（初步）》
其它
上述只列出了三个部门的需求来源，但公司欢迎任何人向我们公司网站和产品等提出问题和建议。
可以通过口头或书面的形式向运营主管或策划主管先提，运营主管或策划主管再整理需求提交给需求管理负责人安排处理。
3.2需求的接收和审批
技术中心指定一名专职需求管理负责人，专门接收来自各部门的需求，协助技术部经理作进度的安排等。
需求的审批分为两种情况：
● 技术部经理审批：
一般情况由技术经理直接审批
● 审批小组审批：
技术部经理不确定的情况下由审批小组进行审批。
需求响应时间：
接收需求后，必须在半天以内向需求申请人反馈对需求的处理结果。
包括处理意见，处理人，计划完成时间等信息。
需求管理负责人职责：
● 专门分类汇总、整理提交的需求。
初步划分是任务还是项目。
● 整理后交给技术部经理进行划分
● 整理后如果是项目交给审批小组进行评估和审批。
审批小组组成：
根据需求的内容临时组建审批小组。
成员一般包括与该需求有关的各部门主管、业务专家、技术主干等。
审批小组职责：
● 批准立项是否成立
● 根据《需求优先级规则表》划分需求的优先级
● 确定是项目还是任务
● 指定解决的部门或个人。
● 安排解决的时间。
3.3需求申请流程
需求的申请流程分为任务需求申请和项目需求申请。
任务需求申请
任务需求申请流程说明：
1. 需求申请人填写《需求申请跟踪单》，并确定紧急程度；
2. 申请部门的主管或经理审批需求，通过后将需求转给技术中心需求管理负责人，不通过则继续修改或取消；
3.1需求管理负责人接收需求后，再次初步划分是任务还是项目和优先级等，然后转给技术部经理进行具体的排期、评估工作量、分配处理人等
3.2根据情况，如果技术部经理不确定，则转审批小组进行审批和安排
4. 按照任务管理或项目管理进行处理。
需求管理人跟踪进度；是任务，需求申请人跟踪进度；是项目，则项目经理跟踪进度。
项目需求申请
项目需求申请流程说明：
项目需求的提出人一般是需求部门主管和经理根据重要性直接要求，然后安排执行人。
1. 需求执行人编写《需求说明书》和《项目计划》（如果能给《项目建议书》更好），写完后提交给技术中心需求管理负责人
2. 技术中心需求管理负责人接收项目后，组织审批小组进行审批和安排
3. 按照项目管理进行执行。
需求管理人跟踪进度，项目经理跟踪进度。
3.4需求响应优先级表
优先级类别
内容
响应
高
● 重大事故
● 网站无法访问。
网站不能打开，或部分网页不能打开
● 用户无法注册、冲值
● 派奖金额错误
● 无法出票
● 用户无法交易
立即响应
注：
出现此类问题，不需要填写需求申请单，发现人直接与技术部经理交流
中
● 问题不影响交易，但影响网站运营
● 网站促销活动的任务
● 新彩种、新玩法、新产品的开发。
例如：
网站二期项目、增加福彩七乐彩等
● 页面的调整、促销专题页面
按正常流程处理
低
● 完善性的需求，属于锦上添花的功能。
先处理中级别任务，有时间再处理低级别需求
4项目管理
4.1立项管理
立项管理（,）的目的是：
（1）采纳符合机构最大利益的立项建议，通过立项管理使该建议成为正式的项目（即合法化）。
（2）杜绝不符合机构最大利益的立项建议被采纳，避免浪费机构的人力资源、资金、时间等。
立项管理是决策行为，其目标是“做正确的事情”（）。
而立项之后的研发活动和管理活动的目标是“正确地做事情”（）。
只有“正确的决策”加上“正确地执行”才可能产生优秀的产品。
立项评审
机构领导组织一个评审委员会进行立项评审。
评审委员会根据《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及立项建议小组的答辩，投票决定是否同意立项（按少数服从多数原则）。
评审委员会应根据机构的实际情况（发展战略、资金、人力资源等），对《立项建议书》提出改进意见。
机构领导对立项具有最终审批权。
如果机构领导赞同评审委员会的决策，那么他们将共同分担决策责任。
如果机构领导行使“一票否决权”，那么他将对该决策负全部责任。
项目启动
正式成立项目组时，必须要有项目启动会议，高管也参与会议，作任命项目经理的说明，并简要介绍项目的内容和目标简要说明。
然后项目经理介绍项目计划，包括项目目标，内容，时间进度，组员分工安排等。
项目经理被任命之后，机构领导协助项目经理获取项目经费、人力资源、软硬件资源等。
要注意的是，如果项目所需的资金和资源难以按时到位，此时项目经理不可老在等待或只是抱怨，应当主动设法克服困难，尽早行动起来。
很多时候，资金和资源是争取来的，而不是等来的。
如果必要的资金和资源已经到位，项目经理和项目核心成员根据实际情况撰写《项目计划》，执行项目研发和管理工作。
4.2项目开发流程
不强调太复杂的流程和多数量的文档。
主要以项目管理的方式来进行管理。
总体的流程思路按照需求→设计→开发→测试→上线
开发流程说明
1.市场的策划人员收集用户需求，整理成《用户需求说明书》
调查、分析用户的需求
2.1技术部的系统分析人员，将用户的原始需求从技术的角度翻译成可实现的《产品需求规格说明书》
2.2市场的策划人员根据《用户需求说明书》，与技术部的相关人员进行协商，设计界面原型。
3.1技术部的系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
形成《系统概要设计说明》，包括网站的架构，数据库，后台，核心流程，模块划分等。
3.2运营部的策划人员细化界面
4.1技术部的开发人员依据《系统概要设计说明》一边做详细设计一边开始编码。
时间允许的情况下写《详细设计说明书》，不允许的情况下直接编码
4.2美工人员做图片，等
4.3测试人员根据需求规格说明书和详细设计说明书以及设计界面写测试方案和测试用例
5.测试和问题修改。
6.上线
注：
本文档只是简要列明项目的开发过程，具体的实践操作请参见《技术中心项目开发过程规范》。
4.3开发方法
界面原型法。
需求除了用文字描述之外，直接画成图形界面来表达功能。
界面直接反映了该网站所具有的功能情况。
不足点能立即发现和修改，避免项目的后期返工。
4.4质量保证办法
建立评审制度，对开发各阶段的工件进行评审，如：
需求阶段的用户需求说明书和界面原型等进行讨论。
评审办法：
评审前，文档编写人员先提前半天，一天甚至两天将自己的工作成果文档等发送给所有将需要参与评审的人员进行查看，以便有个初步了解。
需要确定评审的主题。
需要一个评审主持人，控制讨论不要偏题和讨论的进度。
否则讨论没完没了。
需求编写人员分享自己的思路
其他人员发表意见。
文档编写人员及时记录需要修改的意见。
4.5项目进度监控和管理
项目经理对整个项目负责。
进行监督成本、进度和质量。
目前的成本主要是人员的薪水，包含在进度中。
即项目经理对整个项目进行管理，监控进度和质量。
辅助项目经理对项目进度进行跟踪。
在开发流程和管理给予支持，帮助项目经理争取资源等。
白板展示管理法
将项目的阶段、执行人、时间、进行状态展示在公司的公告栏上。
项目进度更新为每周五下午进行一次更新。
如果完成一个大的里程牌，也可当即更新。
周五更新后，项目成员在周一时继续按照项目进度计划来处理安排给自己的工作。
4.6项目结项管理
立项管理与结项管理是前后呼应的两个过程域，使得项目管理过程“有始有终”。
项目结束有两种状况：
一是正常结束，二是异常结束。
前者是指项目按预定计划结束。
后者原因有多种，归根结底都是由于该项目不再符合机构的最大利益。
例如有些项目因不适应市场而被中途淘汰，有些项目在执行过程中大大因偏离计划（如进度延误、费用超支）而被取消。
不论项目属于正常结束还是异常结束，都要按照结项管理规范处理。
有价值的结项管理至少包括三项内容：
✧ 对项目的有形资产和无形资产进行清算，既要防止资产流失，又要及时地利用这些资产。
✧ 对项目进行综合评估。
例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等。
该评估报告可以作为考核项目人员业绩的重要依据。
✧ 总结经验教训，使整个机构受益。
项目结项标准
测试后，严重问题0个，一般严重问题1~3个。
可以上线。
试运行
上线后，网站运营交给运营部。
上线后的前两个星期为试运行阶段，在该阶段技术部和运营部都参与，一旦发现问题，技术需立即响应进行修改和测试，运营可以提出问题和建议给技术。
提出方式还是以问题的方式，在中填写，开发人员修改自己名单下的。
正式运行
两星期后，一般视情况，问题的多和少来决定试运行的时间。
在试运行没有什么大问题后，进入正式运行阶段。
全权交与运营部接管。
正式运行后，如果有什么问题或建议，则由运营部填写《需求变更申请跟踪单》，按照任务处理流程进行处理。
5任务管理
5.1任务开发流程
任务开发流程图
任务开发流程说明
注：
接收的需求不包含页面、图片的调整。
如有页面、图片的调整直接转网站设计部。
1.接收客服、运营、市场策划或技术部提出的需求
2.需求接收人a.预审需求内容；b.根据“任务优先级规则表”预排优先级；
3.需求预审通过后，技术部经理a.进一步评审需求内容；b.评估开发工作量；c.确定优先级；d.分配执行人；e.安排开发时间进度。
需求内容：
如果有需要则由相关领导和业务专家组成评审小组来讨论需求
优先级：
对于特珠的需求，超出“任务优先级规则表”范围，则由领导小组来指定。
4. 执行开发
5. 执行测试
6.上线
5.2任务响应优先级表
优先级类别
内容
响应
高
● 重大事故
● 网站无法访问。
网站不能打开，或部分网页不能打开
● 用户无法注册、冲值
● 派奖金额错误
● 无法出票
● 用户无法交易
立即响应
注：
出现此类问题，不需要填写需求申请单，发现人直接与技术部经理交流
中
● 问题不影响交易，但影响网站运营
● 页面的调整、促销专题页面
按正常任务流程处理
低
● 完善性的需求，属于锦上添花的功能。
先处理中级别任务，有时间则处理低级别任务
5.3任务进度监控和管理
任务会有许多个，并且是并发进行的。
每一个任务不可能指定一个任务管理人。
需要一个专人对任务进行跟踪和监督，并在任务出现异常时随时向领导汇报。
白板展示管理法
将这个月的任务、优先级、执行人、时间、进行状态展示在公司的公告栏上。
任务进度更新为每周五下午进行一次更新。
如果该任务完成，也可当即更新。
周五更新后，任务执行人在周一时继续按照任务进度计划来处理安排给自己的工作。
5.4任务结束管理
任务结束标准
测试后，严重问题0个，一般严重问题1~3个。
测试通过上线后，由运营部接管。
上线后先试运行一段时间，如果有问题，运营直接反馈给技术部的相关人员进行修改。
试运行没问题后转入正式运行。
附录
相关文档模板：
需求申请跟踪单
项目建议书
项目计划
用户需求说明书
需求规格说明书
客服问题记录跟踪单
项目团队组建的基本原则
①根据项目范围和预算确定团队的人数
项目初始阶段，项目经理也许只了解到一些有关项目范围、交货期限方面的信息以及客户对一些功能需求的简单描述。
为了对项目人力进行估计，有必要进一步细化项目范围。
◆首先在企业内部争取到一个比较得力的助手，他可能是项目未来的开发经理、系统分析员或高级程序员。
这一点很重要，既然你的项目组一定会有其他人的参与，与其到外面去招，不如在内部找你熟悉和信赖的同事加盟。
因为你不仅了解他们的能力，而且作为老员工，他们的稳定性也相对有保障，更重要的是，项目一开始你就不再是孤军奋战，至少有一个得力的助手和你一起讨论，分担你的工作压力。
经验表明，在有人一起讨论的情况下，工作的积极性、决策的准确度等通常都会提高。
◆下一步就是和他一起花一些时间与客户沟通，把手头上的项目范围和功能需求描述尽可能再细化一些，包括每个功能需求都有哪些子需求，这些需求是如何配合形成一个业务链的。
有哪些系统数据需要维护，有多少张报表要出，哪些需求是要优先完成的，系统需要实现的业务有多复杂，哪些外围系统和当前系统有关系，是否有数据接口和数据转换方面的需求等等。
◆把细化后的项目范围录入项目管理系统（推荐使用），根据客户要求的优先级把项目划分成若干阶段，每个阶段提交一部分功能并预留一些风险准备时间，根据需要加上需求分析、系统设计、编码、测试以及项目管理等方面的活动。
◆对其中的任务，找实现技术相近的已完成的项目进行对照，估算出每个任务大致需要的数，然后参考以下方法粗略估计出项目需要的人数。
人数总数/（距交货期限的工作日数×工作效率）
其中工作效率指的是日有效工作时间与日总工作时间的比值。
例如：
企业采取8小时工作制，组员可能只有6～7小时真正投入到工作中，有1～2个小时可能会心不在焉，四处走动或处理一些私事，那么工作效率就介于6/8=0.75和7/8=0.875之间，根据经验一般取0.8比较合理。
Y提示
★估算某一任务的数时，最好两个人独立估算，然后再进行比对，差距较大时，听一听对方的考虑，再得出结论。
★估算某一任务的数时，估算人应该依据目标角色的平均水准而不是他自己的能力标准来进行估算（除非该项任务就是由他本人负责的）。
★成熟的企业一般建有项目资源库，也会提供一些标准的经验统计值，这些都是很好的参考，但还是建议和对照项目的负责人好好聊一聊，取取经，可以获得更加准确的信息。
★这个估算值是比较粗略的，因为有好些因素还没有考虑进去。
例如：
组员的休假计划，特别是一些可预期的长假计划，任务之间的制约关系，人员未必是一次性全部到位的。
◆如果任务超过5个，需要把它进一步拆分成相关的多个子任务，这样每个子任务就可以只分配给一个人完成，并且在一周内就可以得到明确的进度反馈。
考虑到任务之间会有一定的制约关系，有些任务必须等到其他任务完成后才可以开始，有些任务必须与其他任务同时开始或同步完成，尽量把这些最基本的约束关系明确下来。
很多项目管理软件提供了甘特图功能，可以方便地完成这些事情。
◆以之前粗略估计的人员数目为基准，根据人员的目标角色和预计的到位情况，尝试逐个增加人数，对甘特图进行调整，直到能较好地匹配交货期限为止。
◆估计出大致需要的团队人数后，还要统筹考虑项目的预算。
国内很少项目经理有用人方面的预算支配权，更多的是老板告诉你，项目组最多不能超过多少人，甚至干脆为你指定了一些人手，在这种情况下，争吵和认命都是不足取的。
事实上，对较大的项目，很少有项目经理感到他们得到了足够的人手，项目经理仍然应该做好人员的估算工作，并尽力发掘比较可行的方案。
这样当发现人手确实严重不足时，你手头上就已经拥有了一些有说服力的数据，不然你拿什么和老板聊，老板又凭什么要相信你。
②系统分析员岗位以上的人选，优先考虑内部选拔
对项目起关键作用的人选，应该优选考虑内部选拔。
这样做有几个好处：
首先，这些人你都比较熟悉，你了解他们的缺点和长处，长时间的同事关系，使得大家也容易相处和合作。
项目初始阶段，这些人的职责和能力都比较重要，有了他们的协助，项目就会有一个良好的开端。
这些人都是比较资深的员工，稳定性比较有保障，项目实施过程中，可能会有组员离职，但只要这些核心的人没有走，回旋的空间就比较大，项目也不易受到致命的影响。
③人员没有必要一次性到位，应优先保证第一阶段的需求
没有谁能够绝对准确地估计到项目需要多少人，上面建议的方法也仅仅是一个比较粗略的估计，要想更准确地作出估计，必须在系统设计的基础上，进一步对任务进行细化，并作出更加详细的计划安排。
这在项目初始阶段是没有条件做到的。
不仅如此，随着项目的进展，组员对系统和业务的了解越来越深入，编码效率会不断提高，人力需求和任务计划也需要同步调整。
人员一次性到位，可能会造成资源浪费；反之，如果一开始在人力资源上算得太紧，一旦有预料不到的事件发生，将没有回旋的余地。
作为折中的做法，建议一开始把重点放在第一阶段的人力需求上，并在适当的时候，根据项目的实际需求，及时补充人手以满足下一阶段的需求。
这要求在项目初始任务计划中就考虑到人员梯次到位的情况。
这种做法对大型项目非常有效，可以节约大量的成本。
升级会员 