研发部需求开发规程管理

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

精心整理

管理目标

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

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

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

执行概述

1、

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一般可按以下步骤实施:

1、

2、

3、

bug,对这些bug记录在案。

4、Bug。同

5、

6、

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

给所有技术人员。

3

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

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

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

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

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

需求变更管理的目标:

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

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

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

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

1、确定需求的基准线。将以UserCase作为需求基准线,在UserCase确认之后的任何需求改变,都需要走需求变更流程。

2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。

3、项目管理者评估该需求变更。针对接收到的需求变更的要求,召集相关人员讨论该需求变更的合理性、可行性,实施的代价以及对项目的影响。项目管理者对项目的成功与否负有主要的责任。需求变更的决策应由项目管理者做出。

45、确定

员。

6的相关内

7

及时沟通和处理。

8

4、风险管理

1

人员开始疲于奔命和应付,很难保证项目的进度和质量,也难以取得业务部门的认可。

在项目的前期一定要采取相应的手段或措施,与业务部门共同明确项目目标、需求范围,充分考虑现有的时间和资源约束,将需求排定优先级,对于关键的需求优先实现,其他辅助性的根据过程中的具体情况进行滚动式计划,并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求,可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。

2、项目目标扩大以及需求变更

在有了明确的目标和需求范围的情况下,需求的变更还是不可避免的,业务部门在看到具体系统的真实雏形之后,源源不断地要求、新想法随之产生,如果不对此加以控制,新的需求的加入通常会影响已实现的需求,并且对项目进度和成本产生很大的影响。项目管理者针对这

相关文档
最新文档