發表幾個我對我們專案裡敏捷開發的不贊同點：
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。
理解敏捷開發的常見誤區
1.敏捷是 乙個 過程 敏捷不是乙個過程，是一類過程的統稱，它們有乙個共性，就是符合敏捷價值觀，遵循敏捷的原則。敏捷的價值觀如下 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過 遵循計畫 由價值觀引出的12條敏捷原則 我們最優先要做的是通...
關於敏捷開發
前一段參加了北軟教育的乙個 敏捷開發技術 的培訓，一直沒來的總結一下。剛好結合最近的專案，把老師提到的應用了一把，感覺還不錯。敏捷的特點 1 小版本發布 可以給開發人員持續的成就感 2 測試驅動開發 3 持續整合 4 重構 獲得更好的 結構 5 結對變成 最好選取水平相當的兩人 一定要是交叉結對 6...
關於敏捷開發
scrum 英式橄欖球爭球隊 軟體開發模型是敏捷開發的一種。scrum的基本假設是 開發軟體就像開發新產品，無法一開始就能定義軟體產品最終的規程，過程中需要研發 創意 嘗試錯誤。scrum 將軟體開發團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具備的最佳典範與技術，具有高度自主權，緊密地...