敏捷开发，多年前就听说过了。那个时候根本不懂软件工程。毕业设计的时候还用了瀑布模型，不过就那点代码，不过是学生自己在YY罢了。

公司一直以来都用V模型，我想，这么大规模的软件，要用敏捷，要迭代，不可行吧？

事实证明不过是我自己鼠目寸光而已。

业界早就在用敏捷了，公司其他部门已经有用敏捷的了，我们隔壁部门已经在用敏捷了。

很幸运我是我们这个团队中第一批接触敏捷的人。

今天的workshop，有兄弟部门的介绍实践，有被部长称为“最接近神的人”的启发，对敏捷，这才算是认识了。

四点：

1、story：迭代的基础。开发的时候，我们也对DS，对功能，对特性进行拆解，但是没有stroy的概念，就没有依赖关系，结果各个子特性做得乱七八糟，要合到一起去，编译还得搞很久。每200～300行一个stroy，这一次要在设计时就考虑了。

2、持续构建：这是最吸引我的地方了。最大的苦恼：做的设计、写的代码，不能尽快得到正确与否的结论，要等到大家的代码都编好，合在一起，编译通过，系统跑起来，才能验证。几个人在一起讨论规格，开发的，测试的，不过是纸上谈兵，这么做好，还是那么做好，全是YY。持续构建一天验证多次，不正是我想要的吗？越大的软件，越要这么做，问题要留到最后，这么大的工程，修改的代价太高了。敏捷把这个作为一个方法，实际上，就算是瀑布，就算是V，不也是可以使用的吗？

3、TDD，也就是测试驱动设计。先写测试用例，再写函数和代码。道理谁都懂，但是一忙起来，鬼才管测试。结果到后头测试部又叽叽歪歪的说没有考虑到可测试性。每个stroy都是一个可测试的交付件，这样一路下来，害怕测不到，测不好吗？

4、PP，结对编程。这个是大家最有疑问的了，到底效率怎么样？业界评价好。我们还要尝试过才知道。方法往往都是好的，但如何实施才决定成败。

好像敏捷可以解决我们遇到的所有的问题了。是的，好像我们列出来的问题都得到解决方法了。

这个要保留。敏捷和V，和瀑布一样，都是方法论，我们也许把它神话了，也许是因为我们太了解正在使用的模型的缺陷了，而对敏捷，只是看到了它好的一面。就想国足每次换帅一样。

无论如何，引入敏捷是必要的，毕竟，我还是认为它提供了一个很好很好的方法。

今天下班回家，又看到两辆车亲密接触了。西北人民民风彪悍，是真彪悍，抢道呗，抢到最后，看，绝对没有输家！