软件开发项目管理模版

1、治理目标1、所有关系人清楚明确地了解工程的需求和期望,努力做到满足工程所有关系人的不同需求；工程关系人包括：工程团队成员和工程团队外内部/外部客户,内部/外部合作伙伴,经销商/客户等.2、工程治理三要素平衡时间/本钱/质量,即开发工程按需按时按质的完成.3、目标：功能满足需求,设计支持变化,开发快速迭代,成果持续交付.执行概述1、建立有效的工作流程保证工程的顺利进行,初期使用传统RUP过程,引入局部敏捷方法,团队磨合完成后逐步实现敏捷开发全流程治理.2、明确工程目标,制定具有可行性的工程方案,有效明确的分解工程需求.3、跟踪设计/开发/测试/回归/发布全流程,推动工程按预定方案执行.4、解决工

2、程过程中出现的问题和冲突,一般集中在需求不明/工作量或时长/开发难度/跨部门协调等几个方面.5、调动开发团队的积极性,创造力,推动团队成员在工程过程中的学习成长.6、风险识别、风险限制以及风险的预案.工程治理1、需求阶段对工程进行技术可行性分析、技术评估、本钱评估以及风险评估.与需求提出方的代表进行需求讨论,明确工程的目标、价值.确定工程范围、功能及优先级.组建工程团队,特别要搞清楚工程的关键人.工程启动会议,相关的关系人都必须参加.2、设计阶段根据确认后的软件需求规格说明书, 制定工程进度方案, 工作任务分解WBS;资 源申请,工程涉及到的开发资源、测试资源、设计资源 包括人员和软硬件资源；

3、数据 库设计；系统设计；文档 包括系统用例、Demo、测试用例等；评审会议.设计阶段结果交付一般为系统用例/系统原型/系统设计文档概要设计和详细设计/数据库设计文档等.该阶段交付成果需要进行评审.3、执行阶段开发和测试准备开发环境、测试环境.跟踪,推动工程按方案进行.工程成员以日报/工程负责人以周报的形式通报各关系人当前工程的进展情况.按里程碑对阶段成果进行评估,以保证该阶段完成的质量.代码审核,包括 CS审核、SQL审核、WEB审核等.对需求变更进行限制治理.测试阶段BUG响应及改良、收集反应意见.对工程风险进行治理.4、发布阶段包括制定工程发布方案,用户培训,发布上线.5、试运行阶段数据监

4、控日志、效劳器状态,根据监控出现的问题,及时进行处理,改良性能问题,特定情况执行补丁升级.6、收尾阶段产品交付,工程总结会.常见问题1、开发时间的估算制定工程方案时,需要估算每个任务所需的时间, 其中主要是开发任务中模块的分配和 时间估算,在公司现有的技术框架下,开发人员主要的工作是投入在具体的业务逻辑实现上. 通常单个模块开发时间取决于以下因素：1、负责模块的业务逻辑的复杂程度.2、开发人员的技术水平和对工程所在应用的熟悉程度包括对框架和应用的熟悉程度 .3、模块技术实现上是否存在难点,所谓的技术难点定义是： 在现有系统中还未实现的、开发人员自身未没接触过的技术.对于这样的难点,开发者没有相

5、关的代码可以参考,自己也没有经验,所以需要投入学习时间用于研究解决.模块分配和开发时间估算的步骤：1、在划分好模块后,首先工程治理人员预先估算各个模块所需要的开发时间.2、召集所有开发人员,讨论模块的分配和开发时间估算.将划分好的模块,分配给开发人员,如状况允许可允许开发人员自主选择以提升开发人员的主动性和参与性.分配模块的时为保证开发的速度和质量,根本原那么如下：A、类似的模块由同一人负责开发,比方用户信息的增删改应由同一开发者负责.这样开发者对相关逻辑会比拟熟悉,代码/接口的定义也会相对明确,沟通的本钱低,相应可以降低功能实现的缺陷概率.B、技术难度较大的模块由技术水平比拟高的人负责.C、

6、业务逻辑比拟复杂的由对业务逻辑比拟了解的人负责.3、模块分配完成后,开发人员评估自己负责开发的模块所需要的时间.在此过程中应 与开发者讨论每个模块的技术实现细节,使时间的估算更加准确.4、对开发人员估算的时间进行确认.在确认过程中作为,工程治理者将预估时间和开发人员估算时间进行比拟.那些差异较大的,与人员探讨其中的缘由.对于时间周期比拟长 的任务,将任务拆分为更小的子任务,每个任务的完成时间为8-24工时,消除时间周期较长的任务,防止不确定性影响工程的进度.2、CodeReviewCodeReview 是保证工程中代码质量非常重要的一个环节,在这一环限制不严往往是 测试后出现大量 bug的主因

7、,有时甚至导致返工；关于 CodeReview 执行,首先应有编码 标准和代码审查标准. 通过这两个文档来标准开发人员的代码实现,代码编写者必须要严格根据标准来进行；代码审核者根据这些标准来CodeReview 代码,同时在CodeReview 过程中需要不断完善该文档.CodeReview 一般可按以下步骤实施：1、检查开发者的代码实现是否遵循了编码标准.2、从代码的易维护性、可扩展性角度考察代码的质量,提出修改建议.3、代码编写者和代码审核者坐在一起,由代码编写者根据UseCase依次讲解自己负责的代码和相关逻辑,代码审核者在此过程中可以随时提出自己的疑问,同时积极发现隐藏 的bug ,对

8、这些bug记录在案.4、代码讲解完毕后,代码审核者给自己安排几个小时再对代码审核一遍.代码需要检查Bug.同时全面兼顾,保证代码整体上结构优良；审核完毕后,代码审核者编写“代码 审核报告记录发现的问题及修改建议,提交给相关人员.5、代码编写者根据“代码审核报告给出的修改意见,修改好代码,有不清楚的地方可积 极向代码审核者提出.6、代码编写者bugfixed 完毕之后给出反应.7、代码审核者把 CodeReview 中发现的有价值的问题更新到代码审核标准的文档中,对于特别值得提醒的问题可群发email给所有技术人员.3、需求变更治理需求变更治理也是工程治理中最重要的一个环节,对需求变更治理的有效

9、性将直接影响工程的成功与否.对待需求变更的正确态度：1、需求变更是不可防止的.2、需求变更要必须被治理.3、积极发现引起变更的因素,促使变更尽可能早的出现,减低变更带来的风险.需求变更治理的目标：1、相关的干系人必须清楚地了解发生的变更.2、变更处于有效的治理中.3、尽量降低变更带来的风险.通过制定需求变更的流程,保证工程中的需求变更有效地进行,实现上述的目标.需求变更流程：1、确定需求的基准线.将以 UserCase作为需求基准线,在 UserCase确认之后的任 何需求改变,都需要走需求变更流程.2、工程治理者接收到需求变更的要求.需求变更的提出者可以是工程中的任何人包括 产品经理、市场人

10、员、开发人员、测试人员等.3、工程治理者评估该需求变更.针对接收到的需求变更的要求,召集相关人员讨论该 需求变更的合理性、 可行性,实施的代价以及对工程的影响.工程治理者对工程的成功与否负有主要的责任.需求变更的决策应由工程治理者做出.4、需求变更确认后,由专人将生成需求变更单记录下来,通知给工程中所有关系人.5、确定变更的负责人. 承当需求变更的具体工作,比方基线限制,对需求变更的记录,并通知相关人员.6、相关人员接收到确认的需求变更后,需求分析人员修改需求说明书和UserCase的相关内容.测试人员修改测试用例的相关内容.开发人员修改代码中的相关局部.7、根据变更后的方案实施工程,并进行检

11、查,跟踪,对变更后的实施反应和可能出现 的问题及时沟通和处理.8、需求冻结.工程越到后期,需求变更对工程的影响就越大,所以在一定时候要进入 需求冻结阶段,不再接收新需求或需求的变更.4、风险治理影响工程成败的因素涉及方方面面,并且风险伴随着工程的始终, 是客观存在的,风险引起的负面后果集中表达在进度延后、本钱超支、质量不达标等方面,常见风险如下：1、目标以及需求不明确为了市场竞争或内部治理决策的需要,业务部门提出的需求往往要求的时间比拟紧迫,需求的提出大多停留在几张纸或口头的传达上,没有正式的业务需求文档,在没有明确的需求范围的情况下,有时为了迎合业务部门的口味匆匆开工,过程中用户不断地提出新

12、的想法,技术人员开始疲于奔命和应付,很难保证工程的进度和质量,也难以取得业务部门的认可.在工程的前期一定要采取相应的手段或举措,与业务部门共同明确工程目标、 需求范围,充分考虑现有的时间和资源约束,将需求排定优先级,对于关键的需求优先实现,其他辅助性的根据过程中的具体情况进行滚动式方案,并取得业务部门的书面确认.在此过程中要注重挖掘用户的隐性需求,可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求.2、工程目标扩大以及需求变更在有了明确的目标和需求范围的情况下,需求的变更还是不可防止的, 业务部门在看到具体系统的真实雏形之后,源源不断地要求、新想法随之产生,如果不对此加以控制,新

13、的需求的参加通常会影响已实现的需求,并且对工程进度和本钱产生很大的影响.工程治理者针对这种情况一定要采取严格的变更限制流程,不能碍于面子,否那么最终的结果往往是出力不讨好. 针对用户提出的新需求, 根据正式流程提出变更申请,组织相关团队成员进行分析及评估,作为是否实施的依据,变更限制负责人根据分析结果判断 是否批准,如果批准,那工程组可以安排实施,否那么,正式拒绝用户的请求.前期的需求讨论要详细、充分.需求文档中需求的范围要明确、功能描述要清楚.找出工程中需求的决策者 通常会是产品经理、相关职能主管、客户,所有的需求要经过他们的认可.客户在工程过程中的全程参与有助于降低此类风险.需求讨论、需求

14、确认、UserCase确认、测试阶段的客户验收等环节,都要要求客户参与.在发生需求变 更时,严格根据需求变更流程执行. 在分析设计阶段的中确实认和评审也是降低此类风 险的重要手段.3、代码质量风险质量风险主要指开发代码的质量.在制定工程方案时,对开发时间的评估要尽可能的适宜.合理的开发时间对开发质量的影响很大.开发人员为了赶进度在比拟紧张的时间需要完成指定的任务,可能就存在很大的开发质量问题.在编码前,开发人员要对框架熟练掌握；一份好的系统设计文档对指导开发非常重要.往往有这样一种情况, 每个团队成员根据工程方案报告进度都是100%完成,但一到最后系统交互测试或集成的时候就会发现一大堆问题.这

15、需要在工程实施过程中采取有效的举措来躲避风险,通常的做法有同行评审, 比方概要设计完成之后, 邀请其他项目组的技术专家进行技术评审以发现架构设计问题；治理评审,通过组织级的质量审计看产品以及实施过程是否满足质量要求；代码走查,在编码过程中参加至少一次的代码走查,排查不符合标准或性能要求的代码,走查通常能够发现50%-70%的错误；每日构建,这是一种非常有效的方法,可以防止把各局部的集成问题拖到最后,并且能够及时发现相应的错误,日构建一般在工程的中后期开始,每天自动从版本效劳器上获取源代码进行自动编译和测试.4、人员技能和资源的缺乏工程实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少

16、见,一个熟练的技术人员完成同样一个任务需要3天,但一个新手可能就需要 7-10天.工程管理者应该在前期就分析清楚工程所要采用的技术以及相应的人员技能要求,针对不同的角色,及时采取相应的技能培训,以保证工程的顺利实施.开发过程中遇到技术难题, 导致开发时间延迟或者需求不得不发生变更.在工程开始前的技术评估阶段,明确技术难点,提前安排人员进行攻克. 如果在可预期的时间内无法解决,如果可以,将向需求提出方要求变更需求或寻找可替代方案.这样的风险应该在工程的前期阶段就应该解决在萌芽状态来防止这样的风险在后期或中期出现.5、缺乏良好的团队协作软件工程实施属于知识型, 要发挥团队成员的创造力,不同于制造业

17、计件生产, 各模块最终要集成在一起形成一个有机的整体,这就需要各小组之间的密切配合,界定清楚工作界面及接口关系,并在实施过程中持续地沟通交流和共享,首先团队要融为一体,产出的软件才能融为一体.这是一个团队的软实力, 团队之间的协作好坏也将是个潜在的风险问题,在工程启动和团队组建的时候就应该加以躲避这样的风险出现.6、工程会议组织会议是工程执行过程中一项非常重要的工作任务,工程过程中很多重要的决定都是在会议中做出的,不成功的会议会对工程本身造成了不好的影响.不成功的会议通常表现为如下形式：1、会议气氛不好,参与者发言不踊跃；2、会议讨论常常偏离主题；3、会议没有取得预期的结果；4、会议时间常常一

18、拖再拖.这些不成功的会议最终的结果就是：既浪费了大家的珍贵时间又没有到达会议的目的, 很多人都对这样的会议都有抵触情绪,对此也是深恶痛绝.以下是组织会议时应该注意的问题,也可看作组织会议的最正确实践.在列出最正确实践之前有三点我们必须要清楚：1、会议是否会取得成功很大程度上取决于会议的组织者.只有组织得有力,会议才有 可能取得成功,这是会议成功的充分条件.2、会议的组织者和参与者的想法通常是不一致的,有时候甚至会大相径庭.所以不要 希望会议的参与者和你一样,对会议有着如此的期待, 对大多数参与者而言, 在会议中他只是一个发表想法的人,他不用对会议的成功承当责任.3、以下十一条最正确实践是形式上的约定,具体的实施可以根据实际情况来做.组织会议的十一条最正确实践：1、只有需要开会时才开会.有时候两三个人单独小范围沟通会更加有效.2、提前发出会议议程,以便会议参与者知道他们来做什么.3、请对