摘要： 软件“可运行”了就可以评审且通过了？这是个问题。在多年前参加Scrum Master培训的时候，老师拿出一个很好的表格，每行是一个故事，每列大致如此：编码完成功能测试单元测试集成测试压力测试自动测试……这样在计划会的时候，PO就告知大家每个故事他的要求是什么，一方面大家会因此对于要估计的用户故事有一个更明确的理解，另一方面就是约定了评审会上这个故事的完成标准。这个方法已经不错了，不过后来又发现一个更好的：EA（一家游戏公司）将其所有故事完成标准分为5级，分别是：1. 可提供反馈的（就是马马虎虎做出来能玩就行）2. 可运行的3. 可提供玩家评价的4. 可提供玩家体验的（在体验服务器上安装（在线游 阅读全文

摘要： 最近被两次问到同一个问题：如果一个软件需要大量密集的设计工作，导致存在独立的设计和开发团队，应如何实施敏捷开发？整体上讲，敏捷开发不希望存在设计和开发的分离，因为这样就会产生“设计文档”这种东西，而且因为两个团队分离，设计文档一定相当详尽，而且在交接的时候多半要进行评审，否则很难保证开发团队能理解并按其编写代码，最终还可能会导致两个团队的矛盾。在敏捷开发中一般这样处理这种情况：将设计人员下放到开发团队中，由于他们一般技术水平高于开发人员，所以可以作为139团队的骨干（请参考“139团队”相关的博文），一方面继续自己的设计工作，另一方面带领自己的小组进行开发。由于两者关系拉近，设计文档即使不能被 阅读全文