發表幾個我對我們專案裡敏捷開發的不贊同點：

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。