• 2009-03-15

    敏捷 != 敏捷实践

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/36607822.html

    说起敏捷,会让人想起什么?
    TDD、持续集成、结对编程、Standup、回顾会议……

    当人们谈论起敏捷,首先进入大脑的词汇便是这些敏捷实践的名字。

    所以,与人交流的过程,经常会有人告诉我们,我们已经敏捷了,我们搞过TDD,我们做过持续集成等等。然后,语重心长的说,敏捷不行啊!我们遇到了这样那样的问题,总之,都是敏捷惹得祸。

    这个时侯,我们会耐心的与他们交流一下,问他们一下具体的情况。下面就是一些经常得到的答案:
    * TDD就是测试,浪费时间。
    * 测试不好写,为了测一个函数需要设置好多东西,太麻烦了。
    * 我们的持续集成每天都给我们发报告的。
    * 结对编程就是两个坐在一起,太浪费时间了。
    * ……

    有时,我们会饶有兴致让他们打开一段他们的测试代码给我们看,我们经常可以看到一个一屏都无法容纳的测试用例。

    看到这里,我相信,单以敏捷实践而言,他们已经开始做了,但他们却并没有理解敏捷。

    曾经,我读Kent Beck的那本书《Extreme Programming Explained: Embrace Change》,我记住的只是那些实践。现在,我开始理解,真正更具价值的部分,实际是那些价值观:沟通、反馈、简单、勇气和尊重:
    * 当我们经常发现自己的理解和其他人存在不一致的情况时,也许沟通是最好的解决办法
    * 当我们每天才得到一个报告时,我们也就失去了持续集成应有的快速反馈
    * 当我们编写一个长长的测试用例时,我们如何还能保证简单
    * 当我们准备放弃重构代码的念头时,我们是否需要勇气
    * 当我们和pair争执得不可开交时,我们有没有想过尊重

    对于敏捷而言,相比于敏捷具体实践的“形”,这些价值观才是“神”。正是有了这些价值观的驱动,我们才会考虑:
    * 把测试和代码写得清晰易懂,因为复杂了,就不容易理解
    * 不断重构代码,因为一旦腐烂,再想回到干净,就是一件困难重重的任务
    * 代码提交了就会在持续集成中验证,出了错,肯定最新提交代码的人破坏的,而不是把大家的工作混杂在一起。
    * 选择尽可能的自动化,因为人工是繁琐的
    * ……

    分享到:
    引用地址: