敏捷Scrum指南二：Scrum流程之Plan

通用流程：

1. PO講解US，Dev Team理解並評審
2. US Point評估

公司小組流程：

1. PO分享上個月的運營數據
2. PO分享當月目標及計劃
3. PO講解US，Dev Team理解並評審
4. US Point評估
5. Sprint Plan排期
6. 團隊成長

PO分享上月運營數據

爲什麼要分享運營數據？

• 公司價值體系，以目標爲導向。
  • Team中每個人都要能看懂團隊的實際業務數據，工作中不要偏離目標。
  • 方向＞努力，業務＞技術：方向不對，努力白費。
  • Team中每個人都要爲團隊目標負責。
• Scrum 用戶故事地圖：用最少的時間做最高價值的事情。
  • 通過業務數據，挖掘產品價值提升的短板之處。
  • 評估上月新增業務功能是否達到預期價值。
• Scrum之跨職能。
  • 產品是Team的產品，不是產品經理的產品。

PO分享當月目標及計劃

1. PO分享當月業務計劃及Deadline，TeamDev討論計劃並對計劃的可執行性進行評審。
2. PO的每個US上面標註下業務目標：提升MAU、留存、創收等，同時填寫功能上線後的預期運營數據。
3. 團隊成員根據上個月的運營數據，評審業務目標的優先級，產品收集comments。
4. 業務計劃會成爲團隊成長計劃的參考文件。

PO講解US

PO準備工作：

1. 當前Sprint的功能已經拆分成US（參照最小MVP原則）。
2. US的需求已經明確。詳細需求增加到US卡片的描述。
3. US若是涉及到外部合作，合作方已提前溝通，可以同步進行。
4. US若是存在外部技術文檔依賴，PO必須提供穩定的技術文檔。文檔增加到US卡片的附件。

US講解步驟：

1. PO詳細描述US的具體需求。
   1. 界面功能需求，PO需要提供交互稿或設計稿，便於理解需求。
   2. 數據統計需求。
      1. 明確期望數據的劃分維度和維度的標準。示例如下：【維度】新舊用戶
         1. 【維度標準】標準一：沒有下單記錄的用戶爲新用戶；老用戶反之。
         2. 【維度標準】標準二：沒有用戶記錄的用戶爲新用戶；老用戶反之。
      2. 明確數據統計的範圍和範圍標準，常用的是時間範圍。示例如下：【範圍】每週
         1. 【範圍標準】標準一：當前日期的最近7天。
         2. 【範圍標準】標準二：上週日到當週週六。
   3. 數學公式計算需求，PO要提供明確可靠的公式。
   4. 算法需求，PO需要提供明確的數據模型。
   5. 壓測需求。PO需求提供壓測目的和目標數值。
   6. 技術需求，由技術童鞋自行定義需求範圍。
2. Dev Team理解並討論需求。Dev Team從職能角度理解並完善需求，異議處與PO溝通。
   • 研發人員：​​評估需求是否可以用技術實現。
     • 對需求的實現思路和技術達成一致，但是並不涉及到具體的技術細節。
     • 研發人員實現需求時，儘量考慮到技術的持續積累和業務的可擴展性。
   • QA人員：
     • 從測試場景角度思考，需求是否存在遺漏和模糊不清地帶，幫PO完善需求的業務場景。
     • 關於需求的業務範圍與PO&研發人員達成一致。
     • 思考如何測試&是否需要新增測試需求。
     • 理解研發童鞋的實現思路。
   • UED人員
     • 可以考慮新增需求是否會影響到產品的統一風格。
     • 隨着不斷膨脹的需求，目前的產品UI設計架構是否需要進行重新的規劃設計。
     • 新增需求的交互方式是否符合產品用戶習慣。
3. 需求討論過程中衍生出新的需求。
   • 不緊急的業務需求由PO記錄到 Product Backlog。
   • 不緊急的技術需求由Leader記錄到 Dev Backlog。

US Point評估

評估工作的前提：

1. Dev Team都瞭解Point的計數規則，0.5、1、2、3、5、8、13等等。
   1. 小組約定俗成：US最大爲5Point。每個Sprint 5Point的US不能超過3個。
   2. Dev Team對於1個Point的工作量達成了一致。
   3. Scrum中的Point指的是工作量，同一個US的Point是固定的，但不同的人去完成時工時是不一樣的。
   4. 1個Point指的是1個簡單增刪改查需求的DoD工作量。
2. Dev Team對於DoD(Definition of Done)達成了一致。
   1. 前端完成研發。
   2. US已上線到日常。
   3. QA完成新接口的自動化。
   4. QA完成case編寫&測試。
   5. 前後端完成聯調。
   6. 新增功能涉及到架構調整的，研發必須完成架構設計文檔。
   7. 後端完成研發，包含單測。

               之前DoD標準包含UED，Point總數相等的情況下，出現或是提前完成或是Delay的情況。雖然Scrum要求跨職能，但是UED在技術崗中的職能跨度較大，實施半年後覺得不適用於KOI組當前的業務。

              Scrum要求“輕文檔重溝通”。Team實施一段時間後，發現項目文檔缺少，故新增文檔項。針對項目新增的核心功能以及涉及到項目技術架構變動的文檔，必須同步更新。

US評估步驟：

1. 評估每個US Point。依據DoD，Dev Team每個人都說出評估的數字，去掉Point最大數和最小數，剩下的Point數字取平均值。依次評估完所有的US。
2. 計算Sprint Point總數。
   1. PO計劃US的總和爲Point總數的基礎數N。
   2. 基礎數N的增減因素：
      1. 上個Sprint的Point總數。
      2. Sprint是否有大量的項目之外的日常事務或會議。比如績年中年末階段。
      3. 是否存在緊急的技術需求。
      4. Team成員的精神狀態：是否加班過多太疲憊，是否業務少太過鬆散。
      5. 項目是否存在Deadline。
      6. Sprint的人員請假或變更情況。
   3. 增加的策略：
      1. 若是需要減少，PO要從“最少功能最高價值”、業務緊急程度、US準備工作進展情況等維度，進行US優先級排序。優先級由高到底，Dev Team選取能力範圍內的US。
      2. 若是需要增加，從Dev BackLog & Product BackLog中選取高優先級US。
3. US總量評估完成後，填寫到看板的Current Sprint中。

Sprint US排期

US排期的基礎理論：

1. 目標設置理論是強調設置目標的特定會影響激勵水平和工作效績的理論，屬於過程型激勵理論之一。
2. 目標設置應滿足“SMART”原則：
   1. ​​​​​​​
3. 每個US就是一個小目標，給US設置Deadline，符合目標設置的Time-based原則。

US排期步驟：

1. PO把US按照優先級進行排列。
2. PO與Dev Team定義Sprint發版計劃，詳細說明發版時間和上線內容。
3. Dev Team把每個US按照時間順序設置DeadLine。
4. Scrum依據US Deadline畫出並查看BurntDownChat的預燃圖，圖表走勢是否順暢。根據圖表走勢調整US Deadline，最終於Dev Team達成一致。

團隊成長

參照業務US拆分和排序的流程，對團隊的成長計劃進行US的拆分和排期。唯一的區別是，團隊成長對焦的是績效目標。主要是保證業務增長的同時，保證團隊成長和個人成長。

團隊成長，包含團隊的技術成長和軟技能成長。

之前幾個季度並未針對季度的團隊業務外的目標進行拆分和排期，季度結束的時候，團隊成員完成度並不是很理想。一直思考的是團隊成長應該是依賴於團隊督促還是依賴於個人自制力，未能找到完美答案。身爲團隊的領隊人，如何帶領團隊去更好的發展是我該思考的問題。也許優秀的個人依賴於個人超強的學習能力和自制力，但團隊中並不是所有人都可以做到高自制力。如何讓自制力一般的成員不掉隊，激發他最大的潛力，是我該學習的事情，故在新的季度打算把團隊成長以項目管理的方式進行管理。此計劃只是試水，結果待揭曉。