敏捷不是萬能藥
— 筆記整理自 北京理工大學 計算機學院
對敏捷的誤解
- 對人的要求很高
- 自組織，自管理，全職能
- 敏捷沒有文檔，也不做設計
- 不是沒有文檔，強調高效，靈活的交流
- 敏捷好，其他方法不好
- 爭論沒有實際意義
- 敏捷就是XP，就是SCRUM
- 敏捷方法成千上萬, 追求的符合敏捷宣言所倡導的就是敏捷
- 每個項目都要遵循敏捷標準
- 世界上沒有同一片樹葉，要做到無招勝有招
- 有諸多因素會影響我們選擇和實施項目
宣言真的能落地麼?
-
每次迭代後無法交付
- 需求不清
- 開發流程過長
- 代碼質量不高
- 管理混亂
-
引入適合自己團隊的技術工程實踐
- 測試驅動
- 領域驅動
- 結對編程
- 持續集成
- 持續交付
- 重構
- 以上這些根據團隊情況來引入
敏捷誤區
- 需求拍腦袋隨意改動不是快速試錯迅速響應用戶需求(不能沒有底線和方法)
- 代碼質量低劣不停出更新版本不是快速迭代(不考慮質量問題的出版本不能算上是迭代，無意義)
- 不寫正規設計文檔不是降低溝通成本和最好的文檔是代碼(不要爲不寫文檔找藉口)
- 領導站身後指揮程序員寫代碼不是結對編程(領導要做領導的事, 比程序員還專業嗎? 不要開玩笑, 最好引入專業的代碼review團隊)
- 產品質量不靠設計靠測試不是測試驅動開發(這是對TDD的嚴重誤解)
- 研發時間短不是敏捷(不論項目大小, 只知道喊口號, 沒日沒夜加班, 儘早交付, 這不是敏捷)
敏捷與需求分析
- 過分追求敏捷，完全拋棄傳統瀑布模型，會導致很多問題
- 需求分析是Scrum和XP敏捷方法最薄弱的環節之一
- 軟件外包時問題尤其嚴重，當需求無法從最終客戶手裏獲得的時候，再優秀的方法論都是擺設，毫無意義
- 敏捷應當把整理需求與開發一樣當做一個逐漸推進的過程，通過迭代開發等方式來降低需求錯誤的代價，努力專注核心需求，儘早產出可用的軟件來幫助需求的準確推進
不要停止思考
- 個人與互動 勝於流程與工具
- 如何降低溝通成本?最高效的面對面談話?
- 可用的軟件勝於面面俱到的文檔
- 要不要文檔? 要多少? 有什麼用? 怎麼用?
- 與客戶合作勝於合同談判
- 喫飯喝酒不是正確的方式
- 如何引導客戶? 需求隨意改動不是敏捷開發
- 響應變化勝於遵循計劃
- 變化要解決什麼問題? 爲什麼要變? 變多少?
敏捷建議
- 不同的團隊具有不同的最佳實踐
- 項目人員越多，越不適合敏捷開發，最好5~6人
- 小型團隊的入門實踐推薦: TDD，迭代和自組織團隊
結論
- 軟件工程是非常實踐，非常工程，非常靈活的一套方法
- 頂級目標:實現商業目標，創造高品質產品，讓客戶滿意，增強客戶盈利能力等，技術離開市場變得一文不值
- 老闆和客戶不關心到底採用XP，SCRUM還是瀑布，只關心能隨時看到效果，隨時修正，容易應對變更
- 敏捷不是萬能藥，不要過分迷信
擴展話題
1 ） 爲什麼要做敏捷
- 互聯網+的時代，要求業務能夠快速多變的應對, 要求有一種開發模式能夠根據業務快速的變化而變化
- 敏捷是一種更適合互聯網+時代的開發方式
- 敏捷提供了一種低成本誰錯的機會，比如一個idea到上線可能只需要幾天, 這樣可以快速響應用戶來適應我們的產品
- 這樣可以讓我們的創新能夠以一種低成本的方式來交給市場來驗證
- 很多企業都在用敏捷：google，facebok, 以及國內的bat等主要互聯網公司
2 ） 敏捷要怎麼實施
- 建立一個符合自己公司的敏捷標準，通常是12~15條規則
- 需要一個團隊敏捷誠實度模型，比如第一等級，第二等級，第三等級是什麼，比如第一等級是基本可以按照敏捷歷年開一些早會,需求劃分等基本標準，依次第二，第三級別會更高
- 根據這個敏捷模型來做一些敏捷的試點，比如：找幾個團隊，來嘗試開早會,拆分任務,回顧會議,迭代等，5~6個迭代之後，我們就可以做敏捷誠實度的評審, 看看誠實度達到了幾個等級
- 可以藉助一些輔助工具來做一些白板和任務牆等等
3 ） 敏捷之後更高效的開發模式
- 在一兩年敏捷操作之後, 更高效，更快的一種開發模式，比如看板
- 看板和scrum有什麼不一樣, scrum有2~4周的迭代週期，看板則是任務驅動，更細粒度的拆分, 當一個活做完之後使得團隊可以快速的再運轉, 這種模式對團隊誠實度要求更高(業務的理解,技術能力,測試能力)