OOPAA

敏捷实践

下面，我们从“个人－团队－组织”的不同层次分别选取几个突出实践简要解释它们是如何提供频繁、直接的反馈。

l        个人层级

测试驱动开发能给开发人员提供最直接也是最快捷的反馈：先写测试，再用最简单的方式实现，再重构代码以符合简单设计的原则。如此短间隔的反馈能很快地告诉开发人员刚才增加的代码是否破坏了已有的功能。而且，已完成test case的列表能很清晰地告诉其他人开发任务的完成情况。对比着用户故事的验收条件，开发人员很容易评估剩余的工作量，并不至于破坏已有的功能。

l        团队层级

敏捷实践中的持续集成，强调尽可能快尽可能频繁地提交代码，与系统的其他部分进行集成。在提交新代码之前，必须保证本地的构建过程是成功无误的。谁提交代码使得持续集成服务器构建失败，必须立即停下手中的活，负责修复构建直到成功。下班之前必须要保证持续集成服务器上的集成构建状态是成功的。这样，开发人员和团队很容易检查新功能与其他模块的集成，另外也把未来的集成风险降到最低。

l        组织层级

用户故事是开发团队与客户之间讨论需求的基础。用户故事必须对客户有真实可见的业务价值，并且必须包含对该需求完成的验收条件。用户故事作为业务分析人员、测试人员、项目经理与客户一起确定的用户需求，具有经过验证的确切性。开发人员开发故事之前，必须和业务分析人员、测试人员沟通理解需求；开发完故事之后，必须要由业务分析人员与测试人员根据验收条件进行验收。组织和客户之间可以针对达成共识的故事列表来分析项目状态，从而验证或者修改项目计划。

上面只是从“个人－团队－组织”的层次分别挑出了测试驱动开发、持续集成，以及用户故事的实践阐述了敏捷实践如何在不同的层次提供频繁的反馈，一孔窥豹，还有其他若干实践在这里就不再赘述。总之，敏捷众多的实践就像组成了一张全面立体的安全网，时时刻刻从各个角度给项目成员、团队，以及组织提供短周期的反馈，帮助团队成员不仅感受到开发过程中的同伴约束，而且也可以感受到来自整个团队的约束，甚至是来自组织之间的约束。这些外来约束也像是缠绕在个人周围的催化剂，纠正或改善个人的行为，达到提升个人的纪律性。

实际团队

经过几天魔鬼般的技术实践培训，我们在第三天给学员们安排了全天的模拟项目演练。在演练中，由学员自行组织自己的团队：选出自己的团队名称和口号、推选出项目经理、各自分配开发任务，所有人都信心满满。在刚开始接触开发任务的时候，他们还是有一些不好的习惯，这时候，我们鼓励他们把前几天学到的敏捷实践都用起来。于是就出现了这样的形式：当结对中的一人先写实现，而不是先写测试时，另一个人会指出问题，然后重新使用测试驱动的方式；在提交代码时，会有培训讲师监督着他们按照正确的方式来提交；开发用户故事，要求开发人员必须跟分析人员沟通清楚细节，验收故事时，开发人员必须与分析人员和“现场客户”同时参与验收......虽然有些磕磕碰碰，但整体上团队还是有条不紊地进行下去，而且每个人只需要关注自己手头的那部分工作，也易于让他们把事情做得正确。

到了下午，随着学员对技术和业务理解的加深，他们也开始自觉地维护起开发过程，使其保持顺畅。开发过程中，结对的两人激烈地讨论实现的方法，达成一致后又一起开怀大笑；碰上了问题，主动招手找业务分析师询问需求细节，如果业务分析师也弄不清楚，再找现场客户来解答，直到三方都满意；多人开发遇上了冲突，主动找到对方，商量沟通解决方案，实在不行，就找项目经理进行沟通协调；当有人提交了代码使得持续集成服务器构建失败，所有人会善意地提醒犯错的人，督促他们修复；谁遇上了技术问题，有人听见了他们的讨论就会自发上前提供自己的信息；项目经理因为团队自组织也就从繁杂的管理工作里面脱身而出，饶有兴趣地与开发人员一起结对干起了开发的活......整个团队像一列火车一样，前轮带动后轮，后轮推动前轮，井然有序，毫不停歇地往前行进。

最后，我们作为模拟客户参加了这个团队的show case会议，惊讶地看到这个团队的士气和活力，以及他们完成的工作。特别是他们表现出来的团队集体感，让人会以为他们是一个磨合很久的团队。项目经理还在为没有完成更多的工作任务觉得惋惜，但对于“如果给更多时间，是否有信心这个团队可以更好地完成更多的任务”这一问题，他表达了明确的认同。然后再问“为什么”，他说，这个团队的士气和纪律让他刮目相看，目前完成任务的质量让他对未来的任务充满信心。最后问“愿意率领这样的团队么？”，答案是“为什么不？”

作者简介：金明，ThoughtWorks咨询师，InfoQ中文社区编辑，SCJP，系统分析师。他在机械模具、数字安全证书，以及海洋航运等行业拥有超过4年的企业应用开发经验。他对敏捷方法学，特别是敏捷咨询和项目管理，以及面向对象分析和架构设计等方面有浓厚的兴趣。

－－完－－