研发部需求开发流程管理

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

管理目标

1、所有关系人清晰明确地了解项目的需求和期望,努力做到满足项目所有关系人的不同需求;项目关系人包括:项目团队成员和项目团队外(内部/外部客户,内部/外部合作伙伴,经销商/客户等)。

2、项目管理三要素平衡(时间/成本/质量),即开发项目按需按时按质的完成。

3、目标:功能满足需求,设计支持变化,开发快速迭代,成果持续交付。

执行概述

1、建立有效的工作流程保证项目的顺利进行,初期使用传统RUP过程,引入部分敏捷方

法,团队磨合完成后逐步实现敏捷开发全流程管理。

2、明确项目目标,制定具有可行性的项目计划,有效明确的分解项目需求。

3、跟踪设计/开发/测试/回归/发布全流程,推动项目按预定计划执行。

4、解决项目过程中出现的问题和冲突,一般集中在需求不明/工作量或时长/开发难度/跨部

门协调等几个方面。

5、调动开发团队的积极性,创造力,推动团队成员在项目过程中的学习成长。

6、风险识别、风险控制以及风险的预案。

项目管理

1、需求阶段

对项目进行技术可行性分析、技术评估、成本评估以及风险评估。

与需求提出方的代表进行需求讨论,明确项目的目标、价值。

确定项目范围、功能及优先级。

组建项目团队,特别要搞清楚项目的关键人。

项目启动会议,相关的关系人都必须参加。

2、设计阶段

根据确认后的软件需求规格说明书,制定项目进度计划,工作任务分解(WBS);资源申请,项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源);数据库设计;系统设计;文档(包括系统用例、Demo、测试用例等);评审会议。

设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。

该阶段交付成果需要进行评审。

3、执行阶段(开发和测试)

准备开发环境、测试环境。

跟踪,推动项目按计划进行。

项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。

按里程碑对阶段成果进行评估,以确保该阶段完成的质量。

代码审核,包括CS审核、SQL审核、WEB审核等。

对需求变更进行控制管理。

测试阶段BUG响应及改进、收集反馈意见。

对项目风险进行管理。

4、发布阶段

包括制定项目发布计划,用户培训,发布上线。

5、试运行阶段

数据监控(日志、服务器状态),根据监控出现的问题,及时进行处理,改进性能问题,特定情况执行补丁升级。

6、收尾阶段

产品交付,项目总结会。

常见问题

1、开发时间的估算

制定项目计划时,需要估算每个任务所需的时间,其中主要是开发任务中模块的分配和时间估算,在公司现有的技术框架下,开发人员主要的工作是投入在具体的业务逻辑实现上。通常单个模块开发时间取决于以下因素:

1、负责模块的业务逻辑的复杂程度。

2、开发人员的技术水平和对项目所在应用的熟悉程度(包括对框架和应用的熟悉程度)。

3、模块技术实现上是否存在难点,所谓的技术难点定义是:在现有系统中还未实现的、开发人员自身未没接触过的技术。对于这样的难点,开发者没有相关的代码可以参考,自己也没有经验,所以需要投入学习时间用于研究解决。

模块分配和开发时间估算的步骤:

1、在划分好模块后,首先项目管理人员预先估算各个模块所需要的开发时间。

2、召集所有开发人员,讨论模块的分配和开发时间估算。将划分好的模块,分配给开发人员,如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量,基本原则如下:

A、类似的模块由同一人负责开发,比如用户信息的增删改应由同一开发者负责。

这样开发者对相关逻辑会比较熟悉,代码/接口的定义也会相对明确,沟通的成本低,相应可以降低功能实现的缺陷概率。

B、技术难度较大的模块由技术水平比较高的人负责。

C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。

3、模块分配完成后,开发人员评估自己负责开发的模块所需要的时间。在此过程中应与开发者讨论每个模块的技术实现细节,使时间的估算更加准确。

4、对开发人员估算的时间进行确认。在确认过程中作为,项目管理者将预估时间和开

发人员估算时间进行比较。那些差异较大的,与人员探讨其中的缘由。对于时间周期比较长的任务,将任务拆分为更小的子任务,每个任务的完成时间为8-24工时,消除时间周期较长的任务,避免不确定性影响项目的进度。

2、CodeReview

CodeReview是保证项目中代码质量非常重要的一个环节,在这一环控制不严往往是测试后出现大量bug的主因,有时甚至导致返工;关于CodeReview执行,首先应有编码规范和代码审查规范。通过这两个文档来规范开发人员的代码实现,代码编写者必须要严格按照规范来进行;代码审核者根据这些标准来CodeReview代码,同时在CodeReview过程中需要不断完善该文档。

CodeReview一般可按以下步骤实施:

1、检查开发者的代码实现是否遵循了编码规范。

2、从代码的易维护性、可扩展性角度考察代码的质量,提出修改建议。

3、代码编写者和代码审核者坐在一起,由代码编写者按照UseCase依次讲解自己负责的

代码和相关逻辑,代码审核者在此过程中可以随时提出自己的疑问,同时积极发现隐藏的bug,对这些bug记录在案。

4、代码讲解完毕后,代码审核者给自己安排几个小时再对代码审核一遍。代码需要检查

Bug。同时全面兼顾,确保代码整体上结构优良;审核完毕后,代码审核者编写“代码审核报告”记录发现的问题及修改建议,提交给相关人员。

5、代码编写者根据“代码审核报告”给出的修改意见,修改好代码,有不清楚的地方可积

极向代码审核者提出。

6、代码编写者bugfixed完毕之后给出反馈。

7、代码审核者把CodeReview中发现的有价值的问题更新到"代码审核规范"的文档中,对

于特别值得提醒的问题可群发email给所有技术人员。

3、需求变更管理

需求变更管理也是项目管理中最重要的一个环节,对需求变更管理的有效性将直接影响项目的成功与否。

对待需求变更的正确态度:

1、需求变更是不可避免的。

2、需求变更要必须被管理。

3、积极发现引起变更的因素,促使变更尽可能早的出现,减低变更带来的风险。

需求变更管理的目标:

1、相关的干系人必须清楚地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风险。

通过制定需求变更的流程,确保项目中的需求变更有效地进行,实现上述的目标。需求变更流程:

1、确定需求的基准线。将以UserCase作为需求基准线,在UserCase确认之后的任

相关文档
最新文档