天机不可泄漏

最近关于敏捷的的讨论很是热闹(1,2)，要是各位专家不常常出来讨论一下，我都快忘记敏捷这个词了。

看了各位大牛和专家的讨论，特别赞同Martin Fowler说的：……it isn’t methodologies that succeed or fail, it’s teams that succeed or fail. 所谓事在人为（见《伟大的软件要靠伟大的团队》，《敏捷团队建设》），就是看你做不做，当然要挑符合实际情况的最佳实践来做。

所以，接下去我要把敏捷“山寨”一下，找到适合自己的敏捷方法，然后不断改进（这点上很符合迭代的要求嘛），用敏捷的理念来指导敏捷实践。

比如：一个团队刚刚接触敏捷开发，结对编程的门槛可能有些高，但每天的立会、程序员参与对需求的估计相对来讲要求低一些，也能达到敏捷的目的，就可以先实施。甚至我觉得结对编程不是很适合“中国国情”，因为中国的程序员相对比较内敛，不善于表达，习惯得到任务后直接完成，不会像国外的员工喜欢问为什么，要把整个流程问清楚。这也是我欣赏敏捷的原因之一，程序员（人）在敏捷实践的过程中需要更多的交流，更加符合人性。（人之所以有丰富的表情，就是表达用的，我认为表达欲是人性）

好，哪些实践是敏捷的呢？我们先来看《检验团队是否敏捷的四个标准》

1. 是否执行了单元测试？如果你不是以回归的方式执行单元测试，你就不是敏捷的。
2. 是否将项目客户引入开发团队？你是否建立一种交流机制，要求每天或者一周几次的与你的客户进行交流？
3. 你正在开发的软件是否是可工作的（working software）？我希望看到可工作的软件演示，它的配置版本。是否有团队之外的人员在每周都看到你所开发的软件？
4. 开发团队是否是自组织（self-organization）的？也就是说，团队对于项目是否具有控制权。自组织并不意味着毫无限制，但对于项目的一些重要事情应该具有决定的权利。

太好了！我先自我检查一下：单元测试我倒是用，但没有迭代的用，以后望改进。其余的3项，不折不扣可以帮助到项目顺利进行，在项目遇到困难（block）的时候，更是很让客户理解项目遇到的问题，说到底还是“沟通”。

我们再看一下去年VersionOne发布的一份报告。报告中显示，在调查的团队中，实践敏捷方法的，迭代计划86%，单元测试77%，每日立会75%，持续集成72%，……结对编程31%。

好极了，我们的“山寨”敏捷就从迭代计划、单元测试、每日立会、持续集成开始吧！当然我们需要一些特别的工具来帮助我们做迭代计划（我觉得Story Card太浪费纸张了）；用*Unit来做单元测试；大白板做每日立会；*Ant做持续集成，等等……内容很多，每个人的选择不一样。

最后，我没搞明白Scrum、XP啥关系，只知道两者的共同点就是迭代，Scrum大方向上要迭代计划、迭代开发；XP在技术层面上要小规模签入、单元测试、每日集成。我只知道它们都叫“敏捷”，以区别传统的瀑布。如果理解有不对的地方，还请您赐教。