关于敏捷开发的3个误区

发表几个我对我们项目里敏捷开发的不赞同点：

1.专注于形式，不注重精髓

我问我的一个同事他怎么理解敏捷开发，他给我的回答是，pair coding。让我崩溃，这就是不理解精髓，只重视表象。敏捷的精髓是沟通与反馈。各种practice的作用只是用来帮助我们更好的沟通，帮助信息流通。如果分不清这些，就算在做pair coding，你也不知道它的目的是干什么。

专注形式可能会让团队变得笨重，完全不敏捷了。Agile就我的理解就是轻装上阵，已经减轻了很多文档之类的负担，目的就是写出更好的代码。但是如果过于专注形式，就会在团队里加入更多的practice，各种各样的practice加在一起，团队除了写代码会多出一堆的负担来。

敏捷开发的最大特点就是不定信，practice很多，但是采用哪些，完全要自己项目的实际情况来决定，千篇一律是不行的。

2.所谓的拥抱变更

敏捷开发拥抱变更，提倡和用户直接打交道。这也是它的软肋，很多企业在开发的时候，根本没机会直接接触客户，或者频繁的接触客户。最好的结果在一个iteration里见一次就不错了。需求还是要用BA那里获取。

这就出现有些BA打着敏捷开发的旗号在那乱出需求，对项目的整体把握没有就开始开发，一个iteration里变来变去是常事，甚至有BA说：“我现在还没想清楚，你先这样做，做完再改”，明摆着肯定要改，那我现在做了干嘛。

敏捷提倡拥抱变更，开发人员需要做到这点，但是不要做无谓的变化。变更需要refactor，如果refactor来，refactor去，最后说不定全部删除，那等需求确定了再做不迟。

3.Unit Test作用

Unit Test的作用是什么？如果做到TDD，Unit Test可能可以在开发初始阶段检查出一些bug。但是有几个项目做到了TDD呢。更多的是写完code再写Unit Test。 那有些老板说有bug是因为Unit Test没写，这就没道理了。

基本上来说，就算没有Unit Test，在开发的时候也会测试一下功能，写Unit Test基本上也就是把手工的工作在代码里再做一遍。有些criteria如果我在写代码，手动测试的时候都没想到，正常情况下在写Unit Test的时候也不会想到，所以初始的时候有bug是正常的。那些Unit Test的目的呢，就是为以后refactor代码的时候，不至于代码出现bug。所以Unit Test的目的还是用来保证将来的refactor，而不是保证刚写出来的代码没有bug。