我眼中的敏捷实践

作为一个刚毕业就进入Thoughtworks的人，从参加TWU（Thoughtworks university，专门针对应届毕业生的一次文化和技术培训活动）到真正上项目都一直被灌输敏捷开发实践的知识和重要性。当时懵懵懂懂也从来没考虑过为什么要这么做，仿佛每天的工作本来就应该是早上第一件事就是开站会，总结昨天，计划今天的工作；仿佛开发工作本来就应该是需要有故事卡，需要经历开卡、开发、验收的流程；仿佛两周一个迭代是必然的过程，迭代结束都是一定需要开迭代总结回顾回顾的。一切好像都是那么自然而然的。

以前的时候好像从来没有认真思考过这些实践对于一个项目来说的实际意义是什么，只知道我是刚入职的菜鸟，所以公司的老人们怎么跟我说，我就怎么做，有样学样还是会的。然而随着时间的推移，在项目中有新人加入，他们有的就会问，我们为什么需要这么做？为什么不那么做？为了给别人更合理的答复，我也开始思考我们为什么要这么做？

站会（stand up）

站会是每天上班要做的第一件事，从表面上来说站会就是每个人更新一下自己昨天做了什么，今天准备做什么，有没有什么需要团队其他成员提供帮助的问题，有没有什么有可能妨碍到项目正常交付的困难。站会时间一般不会太长。实际上站会也是帮助项目管理人员了解项目进程的一个很重要的方式，可以通过一个全员参与的简短会议对项目进行全局的把握，也有利于后续工作的安排和调整。同时站会也给一些大型团队提供了每天一次固定的沟通渠道，特别是有些项目开发人员分布在不同城市，甚至不同国家的时候，也许有些沟通不及时，站会就提供了一个很好的机会。

迭代计划会议（IPM）

迭代计划会议是项目组所有开发人员对项目一个迭代（一般为两周时间）的工作量的提前预估，一般在下一个迭代开始之前开。我在网上看到一种说法说敏捷开发就是没什么计划，直接开始写代码。其实这种说法是不客观，虽然敏捷强调拥抱变化，但是必要的计划还是会做的，甚至于会比一些传统开发的计划做得更加精细。个人觉得迭代计划会议有几个很重要的点：首先，在迭代计划会议开始之前，需求分析师一定要确保故事卡已经准备就绪，不然会出现大家兴致勃勃的来参加会议，结果完全不知道会议要讨论什么，也不知道下个迭代需要做什么事情的尴尬情况；其次，所有与会者应该认真对待，起码对于即将要做的事有个清晰的认识，我之前就曾经碰到过在迭代计划会议时就下意识的觉得某张卡肯定不会给我做，在讲那张故事卡时走神，导致后续发现自己要做的别的故事卡跟这个有关联，还需要浪费需求分析人员帮我重新理一遍逻辑的事。第三，在做迭代计划时，需要准备一些备用的故事卡，以防需求变更，或者某些需求突然不做了时，开发人员出现空档期的问题。

当然，敏捷实践还有一些其他的方法论和技巧，未完待续……