Scrum敏捷開發

• 2019 年 12 月 20 日
• 筆記

什麼是Scrum敏捷開發 Scrum是敏捷開發的一種，是一種以人為本，迭代式增量軟體開發的過程，以英式橄欖球爭球隊形（Scrum）為名，因此可以想像，整個團隊是高效而富有激情的。以人為本，即Scrum開發特彆強調溝通，要求團隊所有人員都坐著一起工作，通過高效的溝通解決問題。

Scrum的模式和流程 標準的Scrum開發模式 以下是標準的Scrum開發模式：所有的需求都到達PO/PM這裡，整理出Product backlog，每次的迭代開發（Sprint）都是PO/PM從Product backlog里挑出需要開發的部分需求，然後團隊一起開planning meeting，確定出sprint backlog及交付日期。接下來利用2到4周的時間進行開發和測試，其中每天都要開站會（Scrum meeting），團隊內部成員在這個會議上了解整個迭代的進展情況，最終交付後，團隊一起開sprint review和retrospective會議，而這整個過程都有一個很關鍵的角色Scrum Master來把控和組織。

開發周期 Scrum開發一般建議為2-4周為一個周期，以兩周為例，整個時間線大概如下，可以看到第一個迭代的結束和第二個迭代的開始是有重合部分的。

三三四原則 Scrum開發有一個「三三四」原則，即三個角色、三個產出物、四個會議：

三個角色：PO、Scrum Master、Dev Team

PO：Product Owner，一般都是產品經理，負責需求分析和整理、分解驗收story、維護Product backlog等（關於backlog和story會在下面有詳細的描述）。 Scrum Master：扮演推動者的角色，他要負責主持會議、協助團隊內部成員解決困難、解決外部對團隊內部的過分干擾、和外界的主要溝通工作等。Master可以由專門的人來擔當，也可以由團隊內部的成員來擔當，很多團隊都是由PO來同時兼任Master，筆者建議由團隊內部成員輪流擔當，這樣能夠培養團隊成員的責任感，增強團隊的凝聚力，並讓大家更加容易理解敏捷開發的精髓。 Dev Team：整個開發和測試團隊，包括UI設計師等所有相關人員。 三個產出物：Product Backlog、Sprint Backlog、Potential Shippable Product Increment

Product Backlog：產品需求池 Sprint Backlog：此次需要開發的需求集合 Potential Shippable Product Increment：可交付的結果 四個會議：Sprint Planning、Daily Scrum Planning、Sprint Review、Sprint Retrospective

Sprint Planning：需求評審會和迭代啟動會，這個會議上，需要得出以下結論：

全員明確清晰的迭代目標 澄清所有的需求及技術實現風險 評估需要的工作量，以及需要投入的人員 確定出所有最終需要發布的功能集合及工作量，需要將Story拆解成Task，以小時為單位。 Daily Scrum Planning：每日站會，顧名思義，就是站著開會，大家圍成一個圈或者半圈，這樣做有兩個目的，一個是高效，另一個是可以方便團隊所有人都可以看見對方。站會的目的有以下3個：

監督個人的承諾：確認個人是否完成昨日的目標 培養團隊文化 了解項目進展：團隊中每個人都應該了解其他人在做的事情，以及當前團隊的進展和風險。最實際的好處就是這樣可以清楚的知道別人做的事情是否對自己有影響，或者自己是否可以提供幫助等。 站會的時間，建議不超過15分鐘，只描述狀態和任務，不討論技術細節，另外，每個人圍繞以下3個話題來簡單描述自己的進展：

昨天完成了什麼？ 目前有什麼困難，需要幫助的？ 今天準備做什麼？ 站會的時候，Scrum Master一定要注意以下問題：制止不必要的討論、禁止小會、控制發言時間、不要跑題等，另外，站會的時候，Master需要修改燃盡圖（後面會有對燃盡圖的詳細描述）。

Sprint Review：迭代評審會，此次會議的主要內容是相關利益者及團隊成員展現本次迭代的功能增量，需要注意的是不展示未完成的功能，也不需要PPT，演示結束後記錄好相關回饋。很多採用敏捷開的團隊都不開Review會議，其實Review會議是有一定的好處和目的的：

可以讓團隊的成果得到認可，提升團隊的自我價值感 其他人可以了解團隊在做的事情 可以吸引一些利益相關者的注意，並得到一些回饋 演示能夠對團隊成員造成的一定的壓力，迫使團隊認真完成工作 Sprint Retrospective：迭代回顧會，會議主要是回顧此次迭代的整體情況，一定要全員參加，一起回顧此次迭代做的好的地方，以及需要改進的地方，並對這些需要改進的點，提出改進措施。

Product Backlog & User Story User Story：即用戶故事，是一個解決用戶某個問題的，對用戶有價值的，某個功能的，一目了然的描述。這裡有一個理念需要注意，即多個小故事勝過一個龐大的故事，因此User Story的描述非常重要，好的用戶故事具備INVEST原則：

Independent：可以獨立開發 Negotiable：可以協商 Valuable：有價值 Estimable：大小可評估 Sized appropriately：合適粒度 Testable：可測試驗證的 User Story的描述一定要站著用戶角度，而且一定要注意顆粒度，一般以這種格式」作為一個<角色>，想要<活動>，達到<目的>」來描述。另外，根據經驗，筆者建議描述的時候可以不用這種句式，但是思考的時候一定要這樣思考，因為所有事情，過分的追求形式就會失去他本身的價值，但是從這個角度去思考每一個需求和功能點，對產品經理分析需求確實有非常大的幫助。接下來舉幾個User Story的例子：

「圖片編輯功能「：不是一個好的User Story，首先顆粒度太大，其實大小不可評估，因此需要對這個需求做拆分，拆分成小的User Story；

」作為一個喜歡自拍，又希望自己可以拍出來比較白的用戶，可以通過圖片編輯的美白功能，使自己看起來白一點「：該Story是一個比較好的User Story，當然，思考這樣思考，記錄的時候，完全可以簡單描述為」圖片編輯增加美白功能「。

User Story的分解是一個技術活，對產品經理是有一定的要求的，當然，一切從用戶角度出發，多思考用戶場景，那麼這個問題也就也就沒有那麼難了。

Product Backlog：User Story的集合，即產品需求池，這裡面包含所有和該產品相關的需求，根據筆者經驗，這些需求最好包含以下狀態：need to check、pending、reject、planning、developing、released、wait to dev，這些狀態基本包含了一個需求的所有可能的狀態，對產品經理管理需求有非常大的幫助。

看板 & 燃盡圖 看板一般是一個物理白板，目的是做迭代進展可視化跟蹤和協作溝通。看板上需要將每個人的任務，以對應的狀態（To Do/Not checked out、Doing/Checked out、Done）展示出來，一般使用便簽紙。

同時要在白板上畫出燃盡圖，燃盡圖指示的是當前剩餘的工作量，是一個跟蹤項目進展非常好的指示器。燃盡圖上一般有2條曲線，如下圖的燃盡圖，灰色的直線表示的是最優剩餘工作量曲線，藍色的表示實際的剩餘工作量曲線，正常情況下，藍色的線應該在灰色的線上下浮動，並在最後一天合到同一個點上。燃盡圖可以在每天站會的時候由PO更新狀態。

關於看板和燃盡圖，有以下一些需要注意的點：

每個功能通過測試，且PO認可，才算結束； 白板上也要講測試、UE等的任務放上去； bug修復的任務可以估算出工作量，作為單獨的任務放在看板上； 延期的任務，應該註明延期天數； 只有完成的任務才在燃盡圖中刪減工作量，所以，如果增加了工作量，燃盡圖的曲線可能會向上。

敏捷帶來的價值

快速響應變化，及時響應用戶回饋，調整優先順序：Scrum開發可以完全適應現在互聯網開發里的」小步快跑「，以輕量級的Story作為需求進行迭代式開發，保證最重要的總是優先做。 可以持續向用戶交付有價值的軟體產品，以及短的軟體交付周期：這是現在的互聯網開發的基本要求，就是不停的通過每次迭代和升級，進行產品的優化和提升。 項目團隊的透明性：團隊所有成員都可以完全了解當前的項目進展和問題。 低的軟體成本：Scrum開發可以讓產品快速試錯，即使錯了，浪費的也最多是一個迭代的資源，而不會像瀑布開發，有可能浪費的是好幾個月的資源。 高的投資回報率：以較低的成本，和高效的模式進行產品的迭代，回報率當然會較高。