|
6) 运维团队已明确项目管理者联盟
7) 所有计划、方案、机制已与用户和开发、运维团队评审通过项目管理者联盟
8) 发布评审会通过项目管理者联盟
9) 等bbs.mypm.net
项目、阶段、版本发布的完成标准应该在项目计划中制定并评审。在开发过程中可以调整，但是要走正式的变更流程。项目管理者联盟
其次，随着现在敏捷开发的流行，越来越多的开发使用小版本迭代模式，从而实现小、快、灵开发。这里我们就以最流行的SCRUM框架为例，讲解一下在敏捷开发中都有哪些完成标准及其具体内容。项目管理者联盟
敏捷开发中把完成标准成为DoD(完成定义)。根据各自的开发特点可以定义不同的DoD，一般来讲会有版本发布完成定义、迭代完成定义、故事完成定义、周完成定义和每天完成定义等等。可以看出，后面的完成定义实际上是保证前面完成定义的，是一个层层分解、细化的过程。下面我们就以典型的每日完成定义、故事完成定义、迭代完成定义、版本发布完成定义来具体讲述：项目管理者联盟
1、 每日DoD：项目管理培训
1) 搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。项目管理者联盟
2) 下班前必须Check in当天书写的代码项目管理者联盟
3) 当天的代码必须在当天或者第2天邀请同伴进行代码评审项目管理者联盟
4) 凡是检入的功能代码必须要有对应的单元测试项目管理者联盟
5) 当天集成、构建的问题当天(或第二天)解决。项目管理者联盟
等pmp.mypm.net
每日的DoD会在项目初始时确定在框架要求中。项目管理者联盟
2、 用户故事的DoD：项目管理者联盟
1) 用户故事最终的描述符合如下原则：talent.mypm.net
•
独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事，是否可以在一个迭代内完整实现。项目管理者联盟
•
可协商性(Negotiable)— Team是否理解用户故事，无疑问。如有有疑问，一个用户故事的内容要是可以协商的，因为用户故事不是合同。项目管理者联盟
•
有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还是购买方，也包括使用新技术的价值)。项目管理者联盟
•
可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。bbs.mypm.net
•
短小(Small)— 一个好的故事在工作量上要尽量短小，最好不要超过1-2人天的工作量,至少要确保的是在一个迭代中能够完成。项目管理者联盟
•
可测试性(Testable)—一个用户故事要是可以测试的，以便于确认它是可以完成的。项目管理者联盟
2) 用户故事得到用户代表试用并初步认可项目管理者联盟
3) 用户故事都有测试用例对应覆盖项目经理博客
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
