敏捷開發

背景

過去我們用合同死死地固定住需求，然后乙方千方百計的只按照合同辦事，沒有發揮更大的創造力，而甲方在固定的成本面前，不想多花一分錢，卻不停的要求新功能。那么甲乙雙方就形成了矛盾的局面，甚至是敵對的局面。如何破除這種局面呢？這就是本期要講的敏捷開發。

敏捷的起源

硬件領域有摩爾定律，即每隔18~24個月，每1$能買到的電腦性能將翻翻一倍以上。而軟件行業卻沒有相應的規律。那么軟件行業如果提高生產率、質量、價值等。而目前軟件公司是如何提高生產率、質量呢？實際上很多傳統的企業仍然靠加班、流程和工具、合同和文檔的約束，而且溝通困難是導致bug、延期的重要原因，這里的溝通包括開發團隊和甲方的溝通，團隊之間的溝通，團隊和管理者的溝通等等；在瀑布式開發模式中，我們會做大量的前期需求分析和詳細設計，我們自認為我們這些努力會保證交付的軟件會是客戶期望的，但是事實并不是如此。另外，所有的軟件開發者都是知識工作者，那么知識工作者的主管能動性和創造力是管理人員管控出來的嗎？

上述這些軟件行業中的痛點，并不是新生的，早在1987年Fred brooks就在《沒有銀彈》中提到沒有任何一項技術或方法可以能讓軟件工程的生產率在十年內提高十倍。軟件開發本身具有復雜性、不可見性、可變性以及一致性，使得軟件開發難以管理，所以將它比喻成" 狼人"，但是沒有一項技術或方法來解決它，即沒有銀彈。

而敏捷開發正是解決軟件開發沖存在的問題的。

瀑布模型

在具體介紹敏捷開發之前，先介紹"不敏捷"的開發模式，即"瀑布模型"，這套方法論分為5個階段：需求分析、設計、編碼、測試和維護。需求分析階段通常定義系統需求；設計階段通常確定系統使用什么數據庫，系統模塊的劃分，各個模塊的功能；編碼階段用編程語言實現設計階段的功能；測試階段主要測試功能是否實現；維護階段是根據用戶新的需求重新修改系統，使系統運行正常，更加穩定。

瀑布模型的局限性非常明顯，比如對市場變化和用戶需求的響應比較慢，更改成本高，甚至可能出現產品一退出市場就宣告失敗。

敏捷開發

我們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：

• 個體和互動 高于 流程和工具
• 工作的軟件 高于 詳盡的文檔
• 客戶合作 高于 合作談判
• 響應變化 高于 遵循計劃

敏捷開發宣言

1. 我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意
2. 欣然面對需求變化，即使在開發后期也一樣，為了客戶的競爭優勢，敏捷過程掌控變化
3. 經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期
4. 業務人員和開發人員必須相互合作，項目中的每一天都不例外
5. 激發個體的斗志，以他們為核心搭建項目，提供所需的環境和支援，輔以信任，從而達成目標
6. 不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面交談
7. 可工作的軟件是進度的首要度量標準
8. 敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠同步維持其步調穩定延續
9. 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強
10. 以簡潔為本，它是極力減少不必要工作量的藝術
11. 最好的架構、需求和設計出自組織團隊
12. 團隊定期地反思如何能提高成效，并以此調整自身的舉止表現

敏捷開發的原則

1. 凝聚人的力量，緊密協（合）作。包括業務負責人、開發團隊、客戶、管理者之間的關系，所有這些關系在以前都是造成項目危機的原因之一，那么，在敏捷時代，我們需要這些角色 緊密合作，最大限度的發揮各個角色的力量
2. 聚焦客戶價值，消除浪費（如何聚焦用戶價值，即頻繁的交付用戶可工作的軟件，快速收到用戶反饋）
3. 除了有人和有價值，我們還需要持續地學習與改進，因為這個世界變化的太快了。

敏捷團隊

敏捷開發的價值觀和原則看起來很美，但是如何落地呢？首先它需要組建一個敏捷團隊。相交于傳統團隊，敏捷團隊具有以下特點：

• 團隊要求團隊小，通常是個位數的人數（3-9人）
• 全職專注，必須是全職人員
• 跨職能
• 被授權自組織

敏捷團隊運作機制

1. 一個團隊有自己的×××事項，對×××事項進行拆小
2. 按客戶價值進行優先級排序，產品經理負責價值排序
3. 團隊成員的工作不是被主管推動的，而是自己拉動工作
4. 小而穩定，跨職能團隊
5. 多個團隊松耦合（依賴性比較低），對齊迭代時間和戰略目標

關鍵的團隊角色

• 產品負責人
• Scrum主管（流程主管）?
• 開發團隊

產品負責人（Product Owner）

• 負責管理產品backlog（×××事項）的唯一負責人
• 代表客戶/項目如責任人
• 定義產品的所有特性
• 負責產品的投入產出
• 管理干系人和他們的利益
• 接受或者拒絕迭代的結果
• 維護正好夠的，準時生產（Just -in-Time）的特性細節
• 跟團隊共享成功
• 負責最大化產品和開發團隊工作的價值

Scrum Master（流程主管）

• 起到教練的職責
• 領導團隊完成Scrum的實踐以及體現其價值
• 排除團隊遇到的困難
• 使得團隊緊密合作，使得團隊個人具有多方面職能的工作能力
• 確保團隊能勝任其工作，并保持高效的生產率
• 保護團隊不受到外來無端影響

  開發團隊

• 團隊擁有3-9人
• 團隊成員跨職能，多面手
• 團隊成員都全職工作
• 團隊自我組織和管理
• 團隊關系在一個迭代周期中應該是固定的，個人的職能可以在新迭×××始時發生調整

關鍵的團隊活動

• 每日站會
  每日站會每天都會召開，時間維持在15分鐘內，站著開會，所有相關人員都需要參加，避免無關問題的討論。

• 評審會
  需要在迭代周期的最后一天召開，1個小時左右就可以了，需要客戶出席，如果客戶不能出席，則需要產品經理出席
• 迭代回顧會
  迭代回顧會是在每個迭代結束時進行，總結工作中的經驗和教訓，時間維持在30-60分鐘內，整個團隊都需要參加（Scrum Master、Product Owner、開發團隊以及客戶）。迭代回顧會包括兩部分，第一部分是定量分析，第二部分是定性分析。其中定量分析又包含團隊是否完成了迭代目標，收集并評審迭代度量指標（包括速率、迭代燃盡圖、迭代計劃故事和實際完成故事、計劃發布日期與實際發布日期、客戶滿意度、團隊滿意度、生產環境Bug數、生產Bug解決時間、用戶故事等）。定性分析包含哪些工作良好（應該繼續保持），哪些做的不好（應該停止）？哪些可以改進（團隊選出１－２條在下一個迭代實現）？

最常用的敏捷方法和實踐

• Scrum
• XP

歡迎關注微信公眾號：木可大大，所有文章都將同步在公眾號上。