项目管理：项目中什么叫完成，传统瀑布开发与敏捷开发的完成标准是什么？？
在做开发过程中，我们总是在问或是被问到：这个任务完成了么?这个版本开发完成了么?这个产品开发完成了吗?这个……。完成没完成我们都需要有个标准，这个标准是什么呢?今天我们就讲一下这个问题。
首先，对于是否完成在传统开发和敏捷开发中都会有相应的定义或标准。在传统开发模式中，我们以典型的瀑布模型为主，介绍一下完成标准。
在瀑布开发模型中完成标准主要包含有三种：项目完成标准、阶段完成标准、版本发布标准。下面就针对瀑布开发模型的三种完成标准，举例说明：
1. 项目完成标准：
1) 进度:不能超于合同提交时间XXX天。
2) 系统测试缺陷密度<=5个/KLOC
3) 成本花费应不能超于计划的XX%
4) 验收完成项目管理培训
5) 项目相关文档已归档
6) 合同结束
7) 结题评审通过
等项目管理者联盟
2. 阶段完成标准：
瀑布开发模型一般包含：需求、设计、实现、测试、发布阶段。每个阶段都有自己的定性和定量的标准。例如：
3、版本发布标准：
1) 验收测试已通过
2) 发布计划已制定
3) 风险分析及措施已完成
4) 回退、应急方案已制定
5) 问题收集、处理机制已制定
6) 运维团队已明确
7) 所有计划、方案、机制已与用户和开发、运维团队评审通过
8) 发布评审会通过
9) 等
项目、阶段、版本发布的完成标准应该在项目计划中制定并评审。在开发过程中可以调整，但是要走正式的变更流程。
其次，随着现在敏捷开发的流行，越来越多的开发使用小版本迭代模式，从而实现小、快、灵开发。这里我们就以最流行的SCRUM框架为例，讲解一下在敏捷开发中都有哪些完成标准及其具体内容。
敏捷开发中把完成标准成为DoD(完成定义)。根据各自的开发特点可以定义不同的DoD，一般来讲会有版本发布完成定义、迭代完成定义、故事完成定义、周完成定义和每天完成定义等等。可以看出，后面的完成定义实际上是保证前面完成定义的，是一个层层分解、细化的过程。下面我们就以典型的每日完成定义、故事完成定义、迭代完成定义、版本发布完成定义来具体讲述：
1、 每日DoD：
1) 搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。
2) 下班前必须Check in当天书写的代码
3) 当天的代码必须在当天或者第2天邀请同伴进行代码评审
4) 凡是检入的功能代码必须要有对应的单元测试
5) 当天集成、构建的问题当天(或第二天)解决。
6) 等
每日的DoD会在项目初始时确定在框架要求中。
2、 用户故事的DoD：
1) 用户故事最终的描述符合如下原则：
• 独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事，是否可以在一个迭代内完整实现。
• 可协商性(Negotiable)— Team是否理解用户故事，无疑问。如有有疑问，一个用户故事的内容要是可以协商的，因为用户故事不是合同。
• 有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还是购买方，也包括使用新技术的价值)。
• 可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。
• 短小(Small)— 一个好的故事在工作量上要尽量短小，最好不要超过1-2人天的工作量,至少要确保的是在一个迭代中能够完成。
• 可测试性(Testable)—一个用户故事要是可以测试的，以便于确认它是可以完成的。
2) 用户故事得到用户代表试用并初步认可
3) 用户故事都有测试用例对应覆盖
4) 用户故事都有对应的自动化测试用例
5) 用户故事已经实现
6) 用户故事已经测试通过
对于一个用户故事以及验证标准，举例如下：
用户故事实例：作为一个用户，我要在用户界面写入用户名和密码，然后我就可以登录了。
这个功能的验证标准至少应该分为以下三部分：
1) 前置条件
2) 用户输入
3) 用户期待的结果。(注意是用户的期待)
验证实例1：
1) 前置条件：在网站登录页面项目管理者联盟文章
2) 用户输入：输入用户名、密码
3) 用户期待结果：可以登录到网站
验证实例2：
1) 前置条件：在网站登录页面
2) 用户输入：输入错误的用户名、密码
3) 用户期待结果：不能登录到网站，并显示“用户名或密码错误”
验证实例3：
1) 前置条件：在网站登录页面
2) 用户输入：选中“记住我”，输入的用户名、密码，登录后退出，再次进入登录页面。
3) 用户期待结果：用户名、密码自动存在，不用输入。
4) 验证实例3：
1) 前置条件：在移动的网站登录页面
2) 用户输入：输入用户名或密码三次以上。
3) 用户期待结果：再次输入用户名和密码后需要增加一个新的验证。
一般对于用户故事的DoD会写在Use Story CRC背面，并且在对用户故事进行估算时要考虑验证的人工。即对于一个故事的估算点数应该也包含验证的人工。
3、 迭代DoD：(计划会议下半场)bbs.mypm.net
1) 我们都明白在Sprint中交付的价值/目标
2) Sprint交付的所有用户故事都完成了(由谁开确认：PO?用户?)。
3) 确保相关文档更新完成。
4) 确保功能描述更新完成。
5) 验证已识别到/从其他团队的依赖关系和依赖关系。
6) 根据提交的测试分析和变更进行的测试。
7) 执行了的同行评审和评价。
8) 如下产品已经准备和存档完成：
• 故事描述
• 源代码
• 交付报告
• 测试分析报告
• 验证规范和报告
• 详细的需求规范
• 各版本的自动测试脚本
• 所有用户需要的报告
9) 使用静态测试工具没有发现新的缺陷。
10) 所有单元测试用例已经执行通过。
11) 核心代码互查完毕并通过
12) 性能评测通过
13) 代码已经用工具进行检查完毕并通过
14) 所有缺陷已通过确认(明确：已修复或可以暂不修复)
迭代DoD可以在计划会议下半场进行确定。
4、 版本DoD
上面的每个故事都测试通过了，每天也都有持续集成，是不是就可以直接对外交付了?
理论上来讲，如果每日DOD和用户故事DOD，比较完善的话，是可以直接对外交付了，但是在这里我们还要有个决策，这个决策可以算是一个管理里程碑的评审(与技术评审不同)。我们不得不再定义个版本(或者直接叫交付)DOD：
1) 产品文档已全部更新
2) 代码已部署到产品服务器上并进入基线
3) 运维在验收测试环境上测试通过
4) 原始需求提交人对功能已经验收通过
5) 运维、市场、客服对新功能已经培训完成
6) 得到产品经理或是客户的认可。
无论是传统还是敏捷的开发的完成标准，以上都只是给大家一个参考，我们可以根据具体的开发实际情况去定义、执行、分析，从而保证产品/项目的开发目标。
