背景
過去我們用合同死死地固定住需求，然後乙方千方百計的只按照合同辦事，沒有發揮更大的創造力，而甲方在固定的成本面前，不想多花一分錢，卻不停的要求新功能。那麼甲乙雙方就形成了矛盾的局面，甚至是敵對的局面。如何破除這種局面呢？這就是本期要講的敏捷開發。
敏捷的起源
硬體領域有摩爾定律，即每隔18~24個月，每1$能買到的電腦效能將翻翻一倍以上。而軟體行業卻沒有相應的規律。那麼軟體行業如果提高生產率、質量、價值等。而目前軟體公司是如何提高生產率、質量呢？實際上很多傳統的企業仍然靠加班、流程和工具、合同和文件的約束，而且溝通困難是導致bug、延期的重要原因，這裡的溝通包括開發團隊和甲方的溝通，團隊之間的溝通，團隊和管理者的溝通等等；在瀑布式開發模式中，我們會做大量的前期需求分析和詳細設計，我們自認為我們這些努力會保證交付的軟體會是客戶期望的，但是事實並不是如此。另外，所有的軟體開發者都是知識工作者，那麼知識工作者的主管能動性和創造力是管理人員管控出來的嗎？
上述這些軟體行業中的痛點，並不是新生的，早在1987年Fred brooks就在《沒有銀彈》中提到沒有任何一項技術或方法可以能讓軟體工程的生產率在十年內提高十倍。軟體開發本身具有複雜性、不可見性、可變性以及一致性，使得軟體開發難以管理，所以將它比喻成" 狼人"，但是沒有一項技術或方法來解決它，即沒有銀彈。
而敏捷開發正是解決軟體開發衝存在的問題的。
瀑布模型
在具體介紹敏捷開發之前，先介紹"不敏捷"的開發模式，即"瀑布模型"，這套方法論分為5個階段：需求分析、設計、編碼、測試和維護。需求分析階段通常定義系統需求；設計階段通常確定系統使用什麼資料庫，系統模組的劃分，各個模組的功能；編碼階段用程式語言實現設計階段的功能；測試階段主要測試功能是否實現；維護階段是根據使用者新的需求重新修改系統，使系統執行正常，更加穩定。
瀑布模型的侷限性非常明顯，比如對市場變化和使用者需求的響應比較慢，更改成本高，甚至可能出現產品一退出市場就宣告失敗。
敏捷開發
我們一直在實踐中探尋更好的軟體開發方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：
- 個體和互動 高於 流程和工具
- 工作的軟體 高於 詳盡的文件
- 客戶合作 高於 合作談判
- 響應變化 高於 遵循計劃
敏捷開發宣言
- 我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意
- 欣然面對需求變化，即使在開發後期也一樣，為了客戶的競爭優勢，敏捷過程掌控變化
- 經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期
- 業務人員和開發人員必須相互合作，專案中的每一天都不例外
- 激發個體的鬥志，以他們為核心搭建專案，提供所需的環境和支援，輔以信任，從而達成目標
- 不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面交談
- 可工作的軟體是進度的首要度量標準
- 敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠同步維持其步調穩定延續
- 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強
- 以簡潔為本，它是極力減少不必要工作量的藝術
- 最好的架構、需求和設計出自組織團隊
- 團隊定期地反思如何能提高成效，並以此調整自身的舉止表現
敏捷開發的原則
- 凝聚人的力量，緊密協（合）作。包括業務負責人、開發團隊、客戶、管理者之間的關係，所有這些關係在以前都是造成專案危機的原因之一，那麼，在敏捷時代，我們需要這些角色 緊密合作，最大限度的發揮各個角色的力量
- 聚焦客戶價值，消除浪費（如何聚焦使用者價值，即頻繁的交付使用者可工作的軟體，快速收到使用者反饋）
- 除了有人和有價值，我們還需要持續地學習與改進，因為這個世界變化的太快了。
敏捷團隊
敏捷開發的價值觀和原則看起來很美，但是如何落地呢？首先它需要組建一個敏捷團隊。相交於傳統團隊，敏捷團隊具有以下特點：
- 團隊要求團隊小，通常是個位數的人數（3-9人）
- 全職專注，必須是全職人員
- 跨職能
- 被授權自組織
敏捷團隊運作機制
- 一個團隊有自己的代辦事項，對代辦事項進行拆小
- 按客戶價值進行優先順序排序，產品經理負責價值排序
- 團隊成員的工作不是被主管推動的，而是自己拉動工作
- 小而穩定，跨職能團隊
- 多個團隊鬆耦合（依賴性比較低），對齊迭代時間和戰略目標
關鍵的團隊角色
- 產品負責人
- Scrum主管（流程主管）
- 開發團隊
產品負責人（Product Owner）
- 負責管理產品backlog（代辦事項）的唯一負責人
- 代表客戶/專案如責任人
- 定義產品的所有特性
- 負責產品的投入產出
- 管理干係人和他們的利益
- 接受或者拒絕迭代的結果
- 維護正好夠的，準時生產（Just -in-Time）的特性細節
- 跟團隊共享成功
- 負責最大化產品和開發團隊工作的價值
Scrum Master（流程主管）
- 起到教練的職責
- 領導團隊完成Scrum的實踐以及體現其價值
- 排除團隊遇到的困難
- 使得團隊緊密合作，使得團隊個人具有多方面職能的工作能力
- 確保團隊能勝任其工作，並保持高效的生產率
- 保護團隊不受到外來無端影響
開發團隊
- 團隊擁有3-9人
- 團隊成員跨職能，多面手
- 團隊成員都全職工作
- 團隊自我組織和管理
- 團隊關係在一個迭代週期中應該是固定的，個人的職能可以在新迭代開始時發生調整
關鍵的團隊活動
-
每日站會 每日站會每天都會召開，時間維持在15分鐘內，站著開會，所有相關人員都需要參加，避免無關問題的討論。
-
評審會 需要在迭代週期的最後一天召開，1個小時左右就可以了，需要客戶出席，如果客戶不能出席，則需要產品經理出席
-
迭代回顧會 迭代回顧會是在每個迭代結束時進行，總結工作中的經驗和教訓，時間維持在30-60分鐘內，整個團隊都需要參加（Scrum Master、Product Owner、開發團隊以及客戶）。迭代回顧會包括兩部分，第一部分是定量分析，第二部分是定性分析。其中定量分析又包含團隊是否完成了迭代目標，收集並評審迭代度量指標（包括速率、迭代燃盡圖、迭代計劃故事和實際完成故事、計劃釋出日期與實際釋出日期、客戶滿意度、團隊滿意度、生產環境Bug數、生產Bug解決時間、使用者故事等）。定性分析包含哪些工作良好（應該繼續保持），哪些做的不好（應該停止）？哪些可以改進（團隊選出１－２條在下一個迭代實現）？
最常用的敏捷方法和實踐
- Scrum
- XP
歡迎關注微信公眾號：木可大大，所有文章都將同步在公眾號上。