1. 目的
规范软件产品开发项目管理过程，指导开展项目研发、管理等活动。
2. 适用范围
本章程的作用范围为软件产品开发立项至结项管理过程。
1. 对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导。
2. 对项目团队的日常管理活动及内容进行了指导。
3. 敏捷开发的特点
3.1 敏捷迭代开发
1. 敏捷软件开发核心是迭代式开发，增量交付。
2. 每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。
3. 迭代型的方法就是将整个软件生命周期分成多个小的迭代，每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。
4. 迭代建议采用固定的周期（1-4）周，可以每个迭代周期不一定要相同，但迭代内工作不能完成，应该缩减交付范围而不是延长周期。
3.2 敏捷开发的宣言核心价值
1. 个体和互动高于流程和工具;
2. 工作的软件高于详尽的文档;
5. 客户合作高于合同谈判;
4. 响应变化高于遵循计划;
3.3 敏捷开发过程监控
项目沟通贯穿信息从搜集、管理、流通、执行、最终反馈的全流程。伴随项目复杂程度提升和团队规模扩大，高效的沟通除了传统集中办公、会议、周报等制度之外，也可以借助更多的工具和方法。
1. 可视化工具：如甘特图、看板、燃尽图等，帮助团队所有成员直观了解项目进度情况，任务背景状态、负责人、已完成项和剩余工时等一目了然、清晰可见。
2. 在线的团队知识库：共享项目计划和文件，文档资源及时共享，帮助不同角色职能快速找到答案和可用经验。
3. 项目沟通流程规范和会议制度：尤其是跨团队沟通的流程和规范，团队所有成员都按照统一的标准和规范执行，降低沟通成本。
4. 营造团队合作的良好氛围：多多促进成员之间的日常交流让他们更亲近，从而在工作中更容易合作。
4. 角色及职责定义
4.1 产品经理
1. 为产品全生命周期的操盘者，要跟进产品迭代的全流程：需求管理、产品/功能定义、交互/视觉设计、技术评审、研发、测试、发版、跟踪数据及优化。
2. 在项目中担任起需求管理、产品设计、项目管理、风险控制、计划排定、数据分析等多个角色，遇到问题，要及时复盘并完善任何问题环节。
4.2 产品策划
1. 确定产品的功能，拆分用户故事。
2. 需求功能确定优先级。
3. 接受或拒绝开发团队的工作成果。
4. 参与产品开发过程中的有关会议。
4.3 项目经理
1. 进行产品开发过程中的业务目标、进度、成本、质量控制。
2. 挑选项目团队并进行团队建设，激发、鼓舞和改进团队的生产效率。
3. 识别项目干系人，定期向干系人汇报，并作为团队和外部的接口，屏蔽外界对团队的干扰。
4. 确保项目中流程被遵循，组织、监督、培训项目各实践活动。
4.4 UI产品设计
1. 根据用户故事，负责产品的功能交互及界面设计。
2. 组织开展人机交互及用户体验，不断跟踪改进，提高产品表现力。
3. 参与产品开发过程中的有关会议。
4.5 开发工程师
1. 根据用户故事，负责产品的技术架构设计及功能开发。
2. 评估、设计及维护产品相应模块，确保模块的稳定性、易用性、高效性。
3. 参加产品开发过程中的有关会议。
4.6 测试工程师
1. 根据用户故事，设计产品测试标准，确保产品品质满足市场需求。
2. 合理分配测试资源，组织产品测试并优化测试流程及测试标准，提高测试效率。
3. 编写产品测试用例，提交测试问题，编写测试总结报告，以测试角度来确定产品版本是否发布。
4. 参加产品开发过程中的有关会议。
5. 项目管理过程
5.1 前期准备阶段
前期准备三件事: 需求分析， 数据分析， 概要开发方案。
需求分析: 产品经理人员收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表；分析到此业务的背景， 解决的问题， 用户的操作场景。
数据分析: 数据库是不可缺少的东西。 对开发数据设计方案中预估数据量和增长速度，能否支持程序运行。 数据的存储的介质，格式决定了后面的开发方案。
概要开发方案: 确保所有关键业务逻辑全部走通，确保异常数据处理正常，确保各种兼容性，确保最终研发出来的产品符合用户使用逻辑。
5.2 方案评审
在设计师完成交互及视觉设计后，就到了需求交付给研发的时候了，产品要将PRD、交互设计稿、视觉设计稿统一提交给研发。
交付之前，要由产品牵头组织需求评审，邀请设计、研发、测试参与评审，产品给大家演示讲解交互、视觉以及详细的功能介绍，中间任何同事有疑问均可提出，由产品回答，遇到的争议点由产品、设计、研发、测试一起商量确定最终方案。
评审完成后，技术负责人反馈评审结果及大致开发排期。争议点较多、问题较大的需求，可能就评审不通过了；有个别小毛病的，可能评审通过；完全没有问题的，当然也评审通过。评审通过后，研发进入开发流程；如果没有评审通过，产品继续完善需求，等待下一次评审。
针对需求评审过程中的疑问点、争议点以及各方确定的最终方案，产品都要做好记录，评审后，产品完成PRD内容修改，注意版本的迭代及标注。
5.3 项目启动会议
项目负责人召集相关人员召开计划会议，会议主要是明确团队成员，统一方向，说明产品完整交付给客户的计划时间和交付物，给予授权，鼓舞士气增加信心。
项目计划会议上可以明确每天站立会时间及其规则要求（建议会议时间在15-20分钟左右），每个人回答3个问题：昨天做了什么，遇到什么问题，今天要做什么。具体问题讨论及其解决，在私下进行沟通，不要在会议上讨论。
5.4 迭代开发
迭代计划前会议，每一个迭代启动时，召集整个开发团队，召开迭代计划会议，全部的团队成员畅所欲言，明白迭代的开发任务，解答疑惑。
短周期迭代， 我们可以把每一个任务做成一个小周期的迭代。你这个迭代是有里程碑交付物的，没有交付物，那就没办法验证你的成果。
在这个过程中， 我们只需要回答两个问题就足够了: 1. 能不能用。 2.有什么用。 当你进行完这个迭代后能回答这两个问题，那么，我就可以认为这个迭代完成，可以进行一下个周期的迭代。
结对编程是指两个开发者结对编码。结对编程的优点是：经过两个人讨论后编写的代码比一个人独立完毕会更加的完好，一些大的方向不至于出现偏差，一些细节也能够被充分考虑到。一个有经验的开发者和一个新手结对编程，能够促进新手的成长，保证软件开发的质量。
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。在整个开发组频繁的更新代码，出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题能否够被及时发现并消灭掉，取决于自己主动化单元测试和系统测试能力是否足够强大，特别是自己主动化系统测试能力。假设自己主动化测试仅仅能验证最简单的操作，则新合入代码的隐患将非常难被发现，并遗留到项目后期，形成大的风险。
演示培训，每次迭代完毕以后，开发者叫上测试人员，演示软件功能，以便测试人员充分理解软件功能。
测试驱动开发。迭代开发的特点是频繁合入代码，频繁公布版本号。测试驱动开发是保证合入代码正常执行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。
5.5 集成测试
1. 测试用例撰写
研发过程中，测试人员就要根据PRD、交互稿、视觉稿完成测试用例撰写。
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。
2. 测试用例评审
由测试人员牵头发起，并邀请产品、设计师、研发参与，测试主导完成用例讲解，过程中有任何问题，都可以提出，疑问点由各方共同商讨确定最终方案。
评审完成后，测试人员要完成用例内容修改及完善，并周知各位相关人员。
3. 提测与测试
研发完成后，由研发负责人申请提测，测试人员介入。按照事先多方已达成一致的测试用例测试，过程中发现的问题要及时跟产品、研发同步，研发完成bug修复，产品要跟进bug修复；修复完成后，由测试人员继续测试，直至没问题为止。
4 测试环境测试报告
测试人员完成测试后，要输出测试报告，并周知各方人员，测试报告要体现关键结论、风险点、测试内容。测试报告也会作为归档申请的关键依据，即测试通过后，研发方可申请归档。
5.6 发版归档
由研发牵头提出申请，由领导审批后方可执行发版，确认本次版本中存在的问题， 解决的问题内容。
5.7 复盘回顾
总结和反思。每一个迭代结束以后，项目组成员召开总结会议，总结好的实践和教训，并落实到实际的开发中。为团队在消除障碍、改善流程方面积累的经验。