.NET 雲原生架構師訓練營（模塊二 基礎鞏固 Scrum 團隊）--學習筆記

2.7.3 Scrum 團隊

• 理想的環境
• 團隊章程
• 如何組建 Scrum 團隊
• 產品待辦事項列表
• 用戶故事
• 敏捷開發流程

理想的環境

• 5-9人
• 100%
• 跨職能
• 在一塊兒
• 自組織

自組織

• 目標
• 受權
• 溝通
• 可視化
• 輔導
• 獎勵

要我作 => 我想作，我要作，我要作好

團隊章程

• 團隊價值觀：速度與工做時間
• 工做協議：例如：「就緒」定義，「完成」定義
• 基礎規則：例如：會議規則
• 團隊規範：遲到、衝突
• 坦誠、高效溝通
• 包容
• 相互幫助
• 簡潔、反饋、尊重

如何組建 Scrum 團隊

• 先肯定 scrum master 人選，再由 SM 組建其餘團隊成員
• SM 應該由熟悉 scrum 流程和敏捷原理的人擔當
• 根據項目的須要決定團隊中要擁有哪些技能
• 團隊中沒有 team lead 這樣的強勢領導
• 選取能力較強的人做爲團隊成員
• 崇尚全棧工程師

產品待辦事項列表

用戶故事

• 三個要素
• 3C 原則
• 拆分原則
• 拆分關鍵點

三個要素

• 角色：站在用戶角度描述需求的一種方式，誰要使用這個功能
• 活動：從操做場景描述，須要完成什麼樣的功能
• 商業價值：爲何要這個功能，帶來什麼樣的價值

典型描述句式：中文：做爲一個 XXX <客戶角色>，我須要 XXX <功能>，帶來 XXX 好處<商業價值>

英文：As a , I want to , so that

3C 原則

• 卡片（Card）：卡片上可能會寫上故事的簡短描述，規則和完成標準
• 交談（Conversation）：用戶故事背後的細節來源於和客戶或產品負責人的交流溝通
• 確認（Confirmation）：經過驗收測試確認用戶故事被正確完成

拆分原則

• I：Independent，可獨立交付給客戶
• N：Negotiable，便於與客戶交流
• V：Valuable，對客戶有價值
• E：Estimate，能估計出工做量
• S：Small，分解到最底層的用戶故事粒度儘可能小，至少在一個迭代中能完成
• T：Testable，可測試

拆分關鍵點

• 週期控制在 1·5 個工做日，通常在 1 個工做日
• 識別關鍵路徑上的 Story，並作風險管理，避免影響項目進度
• Story 下 Task 分解由模塊負責人組織開發一塊兒分解並作工做量評估
• 每一個 Story 要有負責人，通常由工做量較多的人負責，能夠由研發認領

敏捷開發流程

• PO 和開發團隊對產品業務目標達成共識
• PO 負責創建並維護產品待辦需求列表，並排優先級
• PO 在每輪迭代前，先 review 需求列表，並篩選高優先級需求進入本輪迭代開發內
• 開發團隊細化、拆分本輪迭代需求，並按照需求優先級，依次在本輪迭代內完成
• 開發團隊每日站會同步更新開發進展，並持續集成，使開發任務進展透明可見。站會時團隊成員應自個解釋進展，而非 SM 代替解釋
• PO 對每輪迭代（好比：2周）交付的可工做的軟件進行現場驗收和反饋
• Sprint 回顧會
• 回到第三步，開啓下一輪

本做品採用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可。

歡迎轉載、使用、從新發布，但務必保留文章署名 鄭子銘 （包含連接： http://www.cnblogs.com/MingsonZheng/ ），不得用於商業目的，基於本文修改後的做品務必以相同的許可發佈。

若有任何疑問，請與我聯繫 (MingsonZheng@outlook.com) 。