關於敏捷軟體開發的一些思考

從瀑布流開發轉為敏捷開發已有兩年多，從最初的照貓畫虎到現在能夠結合實際情況做定製化的敏捷開發流程，期間的經歷改變了我對敏捷開發的一些認知，實踐才能出真知。

敏捷開發不是快，而是靈活

• 小步快跑，最小化驗證並不是強調迭代節奏要快，很多人都誤解了，而是強調靈活，船小好調頭；

• 快的意思是單個迭代周期短，能夠快速交付（相比於瀑布流開發）和驗證；

• 靈活的前提是每個迭代的技術債務盡量在當周或者次周清理，技術債務積累後會導致項目無法靈活，所以清理技術債務也應該算作是迭代的一部分，屬於技術性需求；

• 為了足夠靈活，就應該盡量減少人員的復用，所以只要是需要消耗時間的工作都應該放在迭代中，比如改bug、程序設計和評審、代碼評審、性能優化、市場反饋問題改善等和技術強相關的工作；

敏捷開發是讓項目盡量透明

• 敏捷開發可以理解為是將瀑布流開發拆分為若干個小的瀑布流開發，這樣做的目的是讓項目足夠靈活，即使有需求變動也能夠快速調整，在迭代中消化；

• 如果不能做到項目透明，會導致技術債務堆積、存在潛在的問題、項目進度的延遲，如果不能保證產品的穩定和迭代進度，那脫離了目標的敏捷就沒什麼意義了；

• 瀑布流開發並不是一無是處，它很適合於大型軟體的開發，如果能夠做到項目透明，其實也是非常棒的；

敏捷開發對人的要求高（是意願而不是技能）

• 當敏捷開發失敗或者不順暢時，往往會得出敏捷開發對人的要求很高導致不可抗力的結論，的確，敏捷開發對人的意願要求很高，因為需要團隊協作和根據實際項目情況隨時改變，但對人的技能要求並不會很高，即使剛畢業的大學生也是可以參與到敏捷開發中的；

敏捷開發同樣需要規範和流程

• 要相信規範和流程對人的約束比每個人對自己的約束更有效，你見到過沒有紅綠燈的交叉路口的交通場景嗎？

• 有明確的規範和流程有助於提高迭代效率，減少不必要的溝通和無意義的工作；

• 所以敏捷宣言中的「個體和互動高於流程和工具」要看你自己如何理解，好的流程和工具可以提高工作效率、減少溝通成本，並且可以實現敏捷開發並不一定對人要求高；

• 敏捷宣言中「工作的軟體高於詳盡的文檔」可能適合於整個敏捷團隊，但不適合於開發人員，關於程序設計、流程圖、數據結構、ReadMe等還是有必要有詳細的文檔的，起碼能夠讓自己加深對需求的理解、方便他人接手工作。

關於晨會內容

• 晨會的目的是讓項目透明，組員之間知道相互的進度，有問題儘早暴露；

• 晨會中每個人只敘述昨天做完了什麼？遇到了什麼問題？今天要做什麼？

• 晨會中一個領域（產品、軟體前端、測試、軟體後端等）只派一個代表參加就可以了，沒有必要都參加，浪費時間；

• 晨會上不做問題的討論（要討論就在會後拉上相關干係人討論就好了），只敘述項目的實際情況；

• 晨會多半都會是流於形式，意義並不大，所以平時保持溝通比特意開晨會更有意義。

敏捷開發是非常好的一種軟體開發方法，他能夠調用各個崗位對工作的積極性，也能夠提高項目的成功率，但千萬不要被敏捷宣言和一些表面上的敘述誤導，在真正的實踐中總結、定製化會有助於項目真正地實現敏捷。