• 2009-01-13

    非“敏捷”咨询(二)

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

    客户公司原本是一个采用重型过程的公司,所以,谈起敏捷,总有不同的人问我们一个类似的问题,能不能告诉我一步一步怎么做,我照着做就可以了。

    事实上,他们已经有了一些照着做的东西,比如,单元测试。有人和我们说,单元测试挺好,有一定价值,就是写起来太麻烦。为了覆盖到代码所有的分支,他不得不在单元测试里写下大量的代码,当时,我刚刚了解到,几百行的函数对他们而言,是小函数。

    和我们合作的就是一个多多少少有些先行经验的项目组,当我们开始用我们的方式编写代码时,他们才意识到之所以测试难写,因为他们是照着原有的思路写代码,即便测试先于代码写出来。

    另一个例子来自于Story分解。分析需求的时侯,客户的人告诉我们,他们已经开始将需求分解为Story了。当我们开始讨论需求的时侯,却发现这些Story并没有考虑过真正的价值,也没有考虑过开发和测试人员。

    敏捷,似乎已经由许多人心目中的“奢侈品”变成了“消费品”。在各种各样的新闻、论坛和邮件列表,总是不断的看到有人说自己已经“敏捷”了。随之而来的,就是一些人以“过来人”的身份告诉后来者,敏捷不过如此。

    敏捷看上去很简单,就是一大堆的敏捷实践,但真正有价值的部份却是敏捷的思想。因为一个实践推行不下去就置疑敏捷的人大有人在,而这才是真正需要下功夫的地方。

    比如在C/C++如何做TDD。单纯从单元测试的角度出发,用一些单元测试框架,可以做。但是用敏捷的思路去考虑这个问题,我们需要的不仅仅是能做,而且需要快速反馈,一些单元测试框架的问题就会暴露出来。另外,为了做TDD,我们就需要将我们的单元隔离开来,这时侯,却发现这个单元的编译链接需要其他单元,或是过于庞大的头文件导致编译时间增长等等,那需要的就是一些设计和实现上的调整。

    其实,从我们和客户的交流来看,即便没有真正的敏捷,而只是采纳一些敏捷实践,比如TDD、比如持续集成,对团队来说,都是有价值的,很多的问题不必等到最后才去发现,这就大大提高了产品的质量。

    为什么很多人愿意倾向于那一些敏捷实践说事,说白了,因为它简单。扔下一句TDD不好做,容易,想办法把它做好,难!所以,我们做的是《非“敏捷”咨询》。
    分享到:

    历史上的今天:

    引用地址: