http://tommwq.tech/blog/2020/12/01/254
Scrum敏捷開發方法
Scrum敏捷開發過程由多個衝刺（sprint）組成，每個衝刺表示一次迭代，週期通常是2-4周。在進入衝刺之前，產品負責人（product owner）需要提供一個產品待開發項（product backlog），這是一份從客戶價值理解和描述的產品功能條目。開始衝刺後，第一天要召開衝刺計劃會議（sprint planning meeting）。產品負責人按照優先級逐一對功能進行講解，開發團隊就需求細節和完成標準進行詢問，估算任務量，然後加入衝刺待開發項（sprint backlog）。當任務量飽和時，迭代計劃會結束。在衝刺內，任務不會發生大的變化。開始衝刺後，開發團隊決定任務分配和技術選型，並逐一完成任務。每天開發團隊進行一個簡短的每日立會（daily stand-up meeting），溝通當前進度、下一步任務和遇到的問題。開發團隊還維護一張燃燒圖（burn down chart），以觀察和預測工作進度。在衝刺的最後一天，開發團隊召集評審會（review meeting），請產品負責人對已完成的產品功能條目進行評審，後者給出改進反饋。然後開發團隊召開反思會（retrospective meeting），總結本次衝刺中的成功和不足，在後續衝刺中改進。
Scrum中的工作產出物
- 產品待開發項。從客戶價值角度理解的產品功能列表。功能、缺陷、增強都可以是待開發項，重點描述使用方法，以客戶價值爲優先級排序。通常每個條目的工作量在0.5-10人天。
- 衝刺待開發項。從開發技術角度理解的迭代開發任務。
- 可工作軟件（working software）。可交付的軟件產品。產品負責人、客戶代表根據可工作軟件進行評審。“差不多完成了”的產品不應被視爲可交付。
Scrum中的角色
- 產品負責人。負責產品需求的提煉、條目化、優先級排序。
- Scrum大師。負責維護Scrum方法的秩序，協助解決非技術問題。
- 團隊（Team）。以扁平方式組織和管理，完成開發工作。團隊是“自組織”的。
Scrum實施中的一些細節
- 產品待開發項怎麼寫。產品待開發項要包含角色、功能、價值三個要素。角色是用戶在該場景下的身份，功能是角色執行的操作，價值是操作完成後，角色得到的利益。比如：作爲一個觀衆（角色），可以查看電子節目單（功能），以瞭解一週以內所有電視頻道的節目日程（價值）。要注意的是，角色必須明確，不能用模糊的“用戶”替代。
- 有了文檔爲什麼還要迭代計劃會。文檔類似電影劇本，迭代計劃會類似導言說戲。讓開發者對迭代任務和用戶價值有更全面和深入的理解。
- 如何判斷任務量飽和。通常開發者只有70%的時間可以投入到開發工作，因此每個人月安排15人天左右即爲包和。對於新團隊，可能低至10人天。
- 任務量估算。採用共同估算的方式。在估算前不應指定承擔任務的開發者，而是以團隊爲單位進行估算，每個人提出自己的看法，綜合起來。共同估算的目的是用集體智慧和知識對“做什麼、怎麼做”達成共識。產品負責人必須全程參與估算過程，產品複製人需要解答團隊提出的“做什麼，做到什麼程度”的問題。
- 撲克牌估算（planning poker）。產品負責人向團隊進行講解後，團隊中每個人獨立進行估算，選擇對應的撲克牌，扣着放在桌上。所有人都完成估算後，進行開牌。如果估算結果較爲接近，以平均數作爲團隊估算結果。否則讓估算數值最大和最小的人進行PK，其他人也可以參與討論。討論結束後，重新估算和開牌。
- 每日立會時長。每日立會通常10-15分鐘。
- 燃燒圖怎麼畫。燃燒圖的橫座標是時間，縱座標是衝刺待開發項的剩餘時間。
- 如何處理延期。敏捷開發採用時間盒（time boxing），即限定時間，而非限定範圍。因此迭代不會延期。對於無法完成的待開發項，放棄這個任務。
- 評審的標準。評審的標準是產品功能是否達到可交付標準。“差一點”不能算是可交付。可交付標準在衝刺計劃會上，有產品負責人和團隊溝通確認。
- 反思會如何召開。反思會應當每次僅就關鍵的1-3個問題提出可行的解決方案。可行在這裏是指：
- 一、方法簡單、影響面小、見效快。
- 二、目標不要激進，要現實可行，積少成多。必要時，反思會可以執行領導迴避制度，即具有管理職能的人迴避。
- 如何分配任務。任務由開發者認領。
用戶建模
- 用戶建模的目的。理解哪些用戶，爲解決哪些問題或達成哪些目的而使用該產品。
- 用戶建模的步驟。
- 一、列出儘可能多的用戶。
- 二、識別關鍵用戶，即購買決策者和主要使用者。
- 三、合併次要用戶。
- 四、面向關鍵用戶編寫用戶故事。