Scrum(1) | 敏捷入門與 Scrum 計劃會

敏捷項目是從計劃會開始的。計劃會的開展，一般需要兩個小時以上，詳細規定了項目的方法面面的規范，目的是選擇和估算本次迭代的工作項。

1. 敏捷開發測試背景知識

1.1 Scrum過程

• Scrum概覽

Scrum是一種兼顧計劃性與靈活性的敏捷開發過程，原詞來自于橄欖球中的“帶球過人”。在橄欖球比賽的每次沖刺前，都將有一個計劃安排的過程，但沖刺開始后則由隊員在原計劃的基礎上隨機應變。

Snap1.jpg

不同于瀑布模型將開發過程劃分為需求、設計、編碼、測試等階段，Scrum將整個開發過程分為多次迭代（稱為Sprint，沖刺），一般為期2～4周。

在日常工作時，產品負責人會維護一個按優先級排序的“產品待開發項”（Product Backlog），即從客戶價值理解和描述的產品功能條目。

在每次迭代的第一天，召開迭代計劃會(Sprint Planning Meeting)。產品負責人會逐一挑選最高優先級的部分進行講解。團隊可就需求細節、完成標準等進行詢問，并逐條估算，放入本次迭代的開發任務中，直至任務量飽和。一旦迭代開始，這些任務將不會發生大的變化。

在迭代期內，團隊將決定任務分配、所需的技術等，逐一完成任務。每天團隊會進行一個簡短的站立會議即每日立會 Daily Stand-up Meeting，溝通當前進度、下一步任務和當前存在的問題，以借助團隊的力量解決。團隊還維護一張“燃燒圖”（Burn Down Chart），即所有任務的累積剩余時間隨開發進程與日遞減的圖形，以觀察和預測所有任務是否會按期完成。

在每個迭代的最后一天，團隊會召集評審會(Review Meeting)，邀請產品負責人等參加，對已經完成的產品功能條目進行評審，后者做出判斷并給出改進反饋。當天還會召開反思會(Retrospective Meeting)，對本次迭代中的成功與失敗之處做出總結，并在以后迭代中進行改進。

• 兩個清單

  • Product Backlog

    產品待開發項 Product Backlog是從客戶價值角度理解的產品功能列表。

    • 功能、缺陷、增強等都可以是待開發項。
    • 一般以條目化的方式描述。
    • 客戶和用戶必須能夠理解。
    • 描述怎樣使用而非怎樣制造。
    • 整體上從客戶價值優先級排序。
    • 總工作量一般需要0.5～10人天。
    • 高優先級的條目應有較詳盡的描述，低優先級的條目可只有一個名稱。

  • Sprint Backlog

    沖刺待開發項 Sprint Backlog是從開發技術角度理解的迭代開發任務。

    • 在簡單的純軟件環境中，可以直接把產品待開發項當作沖刺待開發項分配到迭代中。
    • 在復雜的開發環境中，可以把一個產品待開發項分解為Web/后臺……軟件/硬件……程序/美術……等開發任務。

• 三個角色

  • Product Owner

    Product Owner（產品負責人）負責產品需求的提煉、條目化、優先級排序。
    現實世界的產品負責人

    • 部門經理、產品經理、策劃人員等都可能做產品負責人。
    • 產品負責人是產品的指路人，必須對產品有長遠的規劃和深入了解，因此不能簡單地選擇銷售人員甚至客戶作為產品負責人。
    • 大型產品如嵌入式產品和網絡游戲，常常使用有層級的產品負責人團隊，來解決廣度與深度的矛盾，如產品總監-產品經理 / 主策劃-策劃團隊。

  • Scrum Master

    Scrum Master（Scrum“大師”）負責維護Scrum方法的秩序，并協助解決非技術問題。
    現實世界的Scrum Master

    • Scrum Master的工作方式是靠領導力(leadership)而非權力工作，因此首先應服務于團隊。
    • 一種人選是原來的項目經理轉型，保留原有的管理和技術職能，但弱化指派任務、下達時間點指令等內容，而增強其組織協調能力。
    • 另一種人選是企業原有的過程改進人員，協助不太了解Scrum的項目經理按照Scrum的方法工作，可以每人負責多個項目，接近全職的Scrum Master。

  • The Team

    Team（團隊）以“自組織”的相對扁平方式進行管理，負責完成開發工作。
    現實世界的開發團隊

    • 實際團隊常常不是“扁平的”，而是仍有項目經理、小組長等職位。
    • 工作中他們以“共同估算”“跨職能工作”“共同跟進”等方式自組織工作，而不是完全依賴層層指令。
    • 項目經理、小組長的領導、指導、協同職能大于其指令職能。

• 四個儀式

  • 計劃會：Sprint Planning Meeting
    • 迭代計劃會在每個迭代第一天召開，目的是選擇和估算本次迭代的工作項。
    • 產品負責人逐條講解最重要的產品功能。
    • 開發團隊共同估算故事所需工作量，直到本迭代工作量達到飽和。
    • 產品負責人參與討論并回答與需求相關的問題，但不干擾估算結果。
  • 每日立會：Standup Meeting
    • 隊員認領任務（或由組長協商分發），獨立或與別人一起完成任務。
    • 團隊內部利用每日立會來溝通進度。
    • 開發團隊利用燃盡圖來展示整體進度。
    • 如無特殊原因，迭代期內無變更。
  • 評審會：Review Meeting
    • 小組向產品負責人展示迭代工作結果。
    • 產品負責人給出評價和反饋。
    • 以用戶故事是否能成功交付來評價任務完成情況。
  • 反思會：Retrospective Meeting
    • 在每個迭代后召開簡短的反思會。
    • 總結哪些事情做的好，哪些事情做的不好。
    • 制定改進計劃。

1.2 用戶故事

用戶故事：描述具體的需求的卡片。

按作為一個……，可以……，以便……樣式和思路寫成的用戶需求，就是用戶故事。
這種樣式是技法層面的東西，它保證了無需太多思考，用戶故事中即可全面包含角色、功能、價值這三個要素。
要想寫好用戶故事，要改變那種面向功能而非客戶需求的純技術觀念。

• 角色切記不要總是寫“作為一個用戶”，而是要把用戶區別對待。這樣才能更好地理解他們使用什么功能，如何使用，為何使用。
• 功能即用戶能親自執行的操作。應區分用戶操作和產品功能之間的關系，因為產品功能可能也提供了用戶所需的價值，但卻極可能不便于操作。
• 價值是完成操作后，客戶所得到的好處。價值里邊，常常要帶有一點褒義詞，或有一些吸引人的內容，比如“高效地……”“……可以節省話費”等。

需求分解為任務，由開發完成，實現功能。

需求費解為用例，有測試完成，驗證功能。

1.3 敏捷日常跟進

• 看板
  • 看板又叫任務版，對于Sprint進度的溝通，看板是一種簡單而強大的方式。從形式上看，看板顯示的是Sprint沖刺待開發項隨時間的進展狀態。
  • 故事板簡單說就是把所有正在工作的內容，張貼到一個板狀空間中。
  • 看板（Kanban）一詞來自日語，指的是制造業中的一種可視化方法，有相當復雜的思想和流程。由于兩者看上去很類似，兩個詞匯經常混用。
• 燃盡圖
  • 在Sprint執行的每一天，團隊成員都要更新未完成任務的剩余工作量估算。我們可以創建一個表來是使數據可視化，就是燃盡圖
  • 根據整個團隊的剩余工作總量，每天進行更新，就可以得到燃盡圖。

2. 計劃會

• 計劃會準備的內容

  1. 每個人準備做（測試）哪幾個需求？
     1. 手工
     2. 自動化測試UI
     3. APP測試
  2. 自動化測試（驗收、回歸、批量）方案？
  3. APP測試
     1. Android模擬器
     2. Android真機（adb） iphone真機（手工）

• 計劃會的步驟
  PO 產品負責人 產品經理

  1. 業務背景介紹
     • 整體的介紹產品的業務
     • 產品可以做什么事情
     • 產品有多少種平臺：
       • Web (B/S)
       • PC (C/S)
       • Android
       • iOS
     • 產品有什么樣的版本：
       • 免費版
       • PRO版（付費）
     • 有多少種競爭的產品
       • Worktile
       • 明道
       • Leangoo
       • teambition
       • trello
  2. 準備 product backlog （更新產品待開發項）
     • 產品經理登錄禪道
     • 創建產品
     • 提需求，構成產品待開發項
  3. 挑選 sprint backlog （選擇該迭代要做的 沖刺待開發項）
     • 項目經理登錄禪道
     • 創建迭代（項目）
     • 關聯產品
     • 關聯需求（從第二步創建的需求中，選擇一部分，構成沖刺待開發項）
     • 團隊設定
  4. 講解 sprint backlog 的具體需求（用戶故事）
     • 產品經理講解每一個被關聯的需求
     • 確定驗收標準

  PM 項目經理 Scrum Master 敏捷教練

  4. 確定 sprint 周期長度 1 week？ 2 weeks？
     • 2周/Sprint
  5. 認領 sprint backlog，預估時間
     需求（開發，xxx，多少時間；測試，xxx，多少時間）
     • 項目經理登錄禪道
     • 選擇本次迭代
     • 打開需求
     • 依次選定每一個需求 | 編輯
     • 編輯備注：
       1. 開發：XXX，2h
       2. 測試：YYY，3h
  6. 確定 評審會的 日期
     • 開幾次？
     • 每次評審什么需求？
     • 確定演示會的次數
     • 確定每次評審會的需要評審的需求
     • 確定每次評審會的時間
  7. 每日立會開會時間
     • 09:05每天

• 計劃會輸出文檔

  • sprint 開始日期，結束日期

  • sprint 周期

  • 表格（sprint backlog表格）

    1. sprint backlog 列表
    2. 任務認領 + 估算

    編號	需求名稱	[所屬模塊]	認領開發	開發時間	認領測試	測試時間
    105	登錄/數據提交[手工 自動化 安全 抓包]	xxx
    106
    109
    -	APP Monkey測試

  • 每日站會時間

  • 評審會表格

    1. 日期
    2. 評審需求

3. 每日立會

1. 匯報內容

   1. 我昨天做了什么事情（完成什么需求的測試？開發？）
   2. 我今天準備做什么事情
   3. 我目前有什么用的困難（挑戰）
      1. 缺乏數據庫權限
      2. 缺乏服務器系統用戶權限
      3. 技術問題
      4. 業務問題
      5. 時間問題

2. 燃盡圖

   統計需求：產品本身的需求（或者需求分解的任務總數） + 產品級對應的測試任務數

3. 每日站會中，每個團隊成員需要回答3個問題。通過這3個問題，我們可以得到兩個層面的信息：

   • 團隊內信息的透明度，整個團隊的進度以及距離Sprint目標還有多遠；
   • 同時是否存在障礙

   每天團隊都會得到反饋，并可以根據得到的反饋做出調整。

   如果不是每天開站會，那么就可能：

   1. 團隊內有些信息會隱藏。有的團隊反映說團隊小（比如4-5人）并且大家都坐在一起，隨時都會溝通，沒必要每日站會。而實際上團隊內的溝通在多數情況下只有相關2-3人一起，而不是整個團隊一起。因此每日站會還是非常有必要的（同步、透明化信息）；
   2. 團隊錯過最佳的調整機會。每日站會中，團隊可以得知距離Sprint目標有多遠，是否存在障礙或者問題。尤其存在障礙時，需要整個團隊共同努力，來想辦法解決。這不是說發現問題了只有在每日站會才說出來，而是發現問題馬上暴露，但每日站會需要正式得讓整個團隊得知情況（一般這類信息容易在2-3人之間討論）；
   3. 團隊沒有儀式感。每日站會可以讓團隊形成規律，每天固定時間、固定地點所有團隊成員湊在一起同步信息和進度，很容易團隊成員可以形成儀式感，這是一個非常重要的事情。

4. 項目迭代

1. Web手工測試準備
2. 自動化測試環境搭建
3. APP測試準備
4. SVN配置
5. 禪道項目管理工具配置