研发部需求开发流程管理

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

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

3、 （WBS） ；资 源申请，项目涉及到的开发资源、测试资源、设计资源（包括人员和软硬件资源 ）；数据库设计；系统设计；文档 （包括系统用例、 Demo 、测试用例等 ）；评审会议。设计阶段结果交付一般为系统用例/系统原型 / 系统设计文档 （概要设计和详细设计）/ 数据库设计文档等。该阶段交付成果需要进行评审。3、执行阶段 （ 开发和测试 ）准备开发环境、测试环境。 跟踪，推动项目按计划进行。 项目成员以日报 / 项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括 CS 审核、 SQL 审核、 WEB 审核等。 对需求变

4、更进行控制管理。测试阶段 BUG 响应及改进、收集反馈意见。 对项目风险进行管理。4、发布阶段包括制定项目发布计划，用户培训，发布上线。5、试运行阶段数据监控 （日志、服务器状态 ），根据监控出现的问题，及时进行处理，改进性能问 题，特定情况执行补丁升级。6、收尾阶段产品交付，项目总结会。常见问题1、开发时间的估算制定项目计划时， 需要估算每个任务所需的时间， 其中主要是开发任务中模块的分配和 时间估算，在公司现有的技术框架下， 开发人员主要的工作是投入在具体的业务逻辑实现上。 通常单个模块开发时间取决于以下因素：1、负责模块的业务逻辑的复杂程度。2、开发人员的技术水平和对项目所在应用的熟悉程

5、度（包括对框架和应用的熟悉程度 ）。3、模块技术实现上是否存在难点， 所谓的技术难点定义是： 在现有系统中还未实现的、 开发人员自身未没接触过的技术。 对于这样的难点， 开发者没有相关的代码可以参考， 自己 也没有经验，所以需要投入学习时间用于研究解决。模块分配和开发时间估算的步骤：1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开 发人员， 如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。 分配模块 的时为确保开发的速度和质量，基本原则如下：A、类似的模块由同一人负责开发，比如用户

6、信息的增删改应由同一开发者负责。这样开发者对相关逻辑会比较熟悉，代码 / 接口的定义也会相对明确，沟通的成本低， 相应可以降低功能实现的缺陷概率。B、技术难度较大的模块由技术水平比较高的人负责。C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。3、模块分配完成后，开发人员评估自己负责开发的模块所需要的时间。在此过程中应 与开发者讨论每个模块的技术实现细节，使时间的估算更加准确。4、对开发人员估算的时间进行确认。在确认过程中作为，项目管理者将预估时间和开8-24 工时，消除时间周期较发人员估算时间进行比较。 那些差异较大的， 与人员探讨其中的缘由。 对于时间周期比较长 的任务，将任务拆分为更小

7、的子任务，每个任务的完成时间为 长的任务，避免不确定性影响项目的进度。2、CodeReviewCodeReview 是保证项目中代码质量非常重要的一个环节，在这一环控制不严往往是 测试后出现大量 bug 的主因，有时甚至导致返工；关于 CodeReview 执行，首先应有编码 规范和代码审查规范。 通过这两个文档来规范开发人员的代码实现， 代码编写者必须要严格 按照规范来进行；代码审核者根据这些标准来 CodeReview 代码，同时在 CodeReview 过 程中需要不断完善该文档。CodeReview 一般可按以下步骤实施：1、检查开发者的代码实现是否遵循了编码规范。2、3、4、5、6、

8、7、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。 代码编写者和代码审核者坐在一起，由代码编写者按照 UseCase 依次讲解自己负责的 代码和相关逻辑，代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏 的 bug ，对这些 bug 记录在案。 代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要检查 Bug 。同时全面兼顾，确保代码整体上结构优良；审核完毕后，代码审核者编写“代码 审核报告”记录发现的问题及修改建议，提交给相关人员。 代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积 极向代码审核者提出。代码编写者 bug

9、fixed 完毕之后给出反馈。代码审核者把 CodeReview 中发现的有价值的问题更新到 "代码审核规范 "的文档中， 对于特别值得提醒的问题可群发 email 给所有技术人员。3、需求变更管理对需求变更管理的有效性将直接影响需求变更管理也是项目管理中最重要的一个环节， 项目的成功与否。对待需求变更的正确态度：1、需求变更是不可避免的。2、需求变更要必须被管理。3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。 需求变更管理的目标：1、相关的干系人必须清楚地了解发生的变更。2、变更处于有效的管理中。3、尽量降低变更带来的风险。通过制定需求变更的流程

10、， 确保项目中的需求变更有效地进行， 实现上述的目标。 需求 变更流程：1、确定需求的基准线。将以UserCase 作为需求基准线，在 UserCase 确认之后的任 何需求改变，都需要走需求变更流程。2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括 产品经理、市场人员、开发人员、测试人员等。3、项目管理者评估该需求变更。针对接收到的需求变更的要求，召集相关人员讨论该 需求变更的合理性、 可行性， 实施的代价以及对项目的影响。 项目管理者对项目的成功与否 负有主要的责任。需求变更的决策应由项目管理者做出。4、需求变更确认后，由专人将生成需求变更单记录下来，通知给项目

11、中所有关系人。5、确定变更的负责人。 承担需求变更的具体工作， 比如基线控制， 对需求变更的记录，并通知相关人员。6、相关人员接收到确认的需求变更后，需求分析人员修改需求说明书和UserCase 的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。7、按照变更后的计划实施项目，并进行检查，跟踪，对变更后的实施反馈和可能出现 的问题及时沟通和处理。8、需求冻结。项目越到后期，需求变更对项目的影响就越大，所以在一定时候要进入 需求冻结阶段，不再接收新需求或需求的变更。4、风险管理影响项目成败的因素涉及方方面面， 并且风险伴随着项目的始终， 是客观存在的， 风险 引起的负面后果

12、集中体现在进度延后、成本超支、质量不达标等方面，常见风险如下：1、目标以及需求不明确为了市场竞争或内部管理决策的需要， 业务部门提出的需求往往要求的时间比较紧 迫，需求的提出大多停留在几张纸或口头的传达上， 没有正式的业务需求文档， 在没有 明确的需求范围的情况下， 有时为了迎合业务部门的口味匆匆开工， 过程中用户不断地 提出新的想法， 技术人员开始疲于奔命和应付， 很难保证项目的进度和质量， 也难以取 得业务部门的认可。在项目的前期一定要采取相应的手段或措施， 与业务部门共同明确项目目标、 需求 范围，充分考虑现有的时间和资源约束， 将需求排定优先级， 对于关键的需求优先实现， 其他辅助性的

13、根据过程中的具体情况进行滚动式计划， 并取得业务部门的书面确认。 在 此过程中要注重挖掘用户的隐性需求， 可以通过引导、 系统原型等手段让用户在前期充 分暴露自己的想法和需求。2、项目目标扩大以及需求变更在有了明确的目标和需求范围的情况下， 需求的变更还是不可避免的， 业务部门在 看到具体系统的真实雏形之后， 源源不断地要求、 新想法随之产生， 如果不对此加以控 制，新的需求的加入通常会影响已实现的需求， 并且对项目进度和成本产生很大的影响。 项目管理者针对这种情况一定要采取严格的变更控制流程， 不能碍于面子， 否则最终的 结果往往是出力不讨好。 针对用户提出的新需求， 按照正式流程提出变更申

14、请， 组织相 关团队成员进行分析及评估， 作为是否实施的依据， 变更控制负责人根据分析结果判断 是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求。前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者 （通常会是产品经理、相关职能主管、客户），所有的需求要经过他们的认可。 客户在项目过程中的全程参与有助于降低此类风险。 需求讨论、 需求确 认、 UserCase 确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变 更时， 严格按照需求变更流程执行。 在分析设计阶段的中的确认和评审也是降低此类风 险的重要手段。3、代码质量风险

15、质量风险主要指开发代码的质量。 在制定项目计划时， 对开发时间的评估要尽可能 的合适。 合理的开发时间对开发质量的影响很大。 开发人员为了赶进度在比较紧张的时 间需要完成指定的任务， 可能就存在很大的开发质量问题。 在编码前， 开发人员要对框 架熟练掌握；一份好的系统设计文档对指导开发非常重要。往往有这样一种情况， 每个团队成员按照项目计划报告进度都是100% 完成， 但一到最后系统交互测试或集成的时候就会发现一大堆问题。 这需要在项目实施过程中采取 有效的措施来规避风险， 通常的做法有同行评审， 比如概要设计完成之后， 邀请其他项 目组的技术专家进行技术评审以发现架构设计问题； 管理评审，

16、通过组织级的质量审计 看产品以及实施过程是否满足质量要求； 代码走查， 在编码过程中加入至少一次的代码 走查，排查不符合规范或性能要求的代码，走查通常能够发现 50%-70% 的错误；每日 构建， 这是一种非常有效的方法， 可以避免把各部分的集成问题拖到最后， 并且能够及 时发现相应的错误， 日构建一般在项目的中后期开始， 每天自动从版本服务器上获取源 代码进行自动编译和测试。4、人员技能和资源的不足一个天。项目管针对不同的项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见， 熟练的技术人员完成同样一个任务需要 3 天，但一个新手可能就需要 7-10 理者应该在前期就分析清楚项

17、目所要采用的技术以及相应的人员技能要求， 角色，及时采取相应的技能培训，以保证项目的顺利实施。开发过程中遇到技术难题， 导致开发时间延迟或者需求不得不发生变更。 在项目开始前的技术评估阶段， 明确技术 难点， 提前安排人员进行攻克。 如果在可预期的时间内无法解决， 如果可以，将向需求 提出方要求变更需求或寻找可替代方案。 这样的风险应该在项目的前期阶段就应该解决 在萌芽状态来避免这样的风险在后期或中期出现。5、缺乏良好的团队协作软件项目实施属于知识型， 要发挥团队成员的创造力， 不同于制造业计件生产， 各 模块最终要集成在一起形成一个有机的整体， 这就需要各小组之间的密切配合， 界定清 楚工作

18、界面及接口关系， 并在实施过程中持续地沟通交流和共享， 首先团队要融为一体， 产出的软件才能融为一体。 这是一个团队的软实力， 团队之间的协作好坏也将是个潜在 的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。6、项目会议 组织会议是项目执行过程中一项非常重要的工作任务， 项目过程中很多重要的决定都是 在会议中做出的，不成功的会议会对项目本身造成了不好的影响。不成功的会议通常表现为如下形式：1、会议氛围不好，参与者发言不踊跃；2、会议讨论常常偏离主题；3、会议没有取得预期的结果；4、会议时间常常一拖再拖。 这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的

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