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

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

1. 敏捷開發(fā)測試背景知識

1.1 Scrum過程

• Scrum概覽

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

Snap1.jpg

不同于瀑布模型將開發(fā)過程劃分為需求范删、設計、編碼拷肌、測試等階段到旦，Scrum將整個開發(fā)過程分為多次迭代（稱為Sprint，沖刺）巨缘，一般為期2～4周添忘。

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

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

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

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

• 兩個清單

  • Product Backlog

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

    • 功能仪吧、缺陷、增強等都可以是待開發(fā)項山憨。
    • 一般以條目化的方式描述裆蒸。
    • 客戶和用戶必須能夠理解郊艘。
    • 描述怎樣使用而非怎樣制造唯咬。
    • 整體上從客戶價值優(yōu)先級排序。
    • 總工作量一般需要0.5～10人天。
    • 高優(yōu)先級的條目應有較詳盡的描述瞎嬉，低優(yōu)先級的條目可只有一個名稱氧枣。

  • Sprint Backlog

    沖刺待開發(fā)項 Sprint Backlog是從開發(fā)技術角度理解的迭代開發(fā)任務挑胸。

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

• 三個角色

  • Product Owner

    Product Owner（產品負責人）負責產品需求的提煉巷嚣、條目化、優(yōu)先級排序廷粒。
    現(xiàn)實世界的產品負責人

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

  • Scrum Master

    Scrum Master（Scrum“大師”）負責維護Scrum方法的秩序盒刚，并協(xié)助解決非技術問題腺劣。
    現(xiàn)實世界的Scrum Master

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

  • The Team

    Team（團隊）以“自組織”的相對扁平方式進行管理堵腹，負責完成開發(fā)工作炸站。
    現(xiàn)實世界的開發(fā)團隊

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

• 四個儀式

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

1.2 用戶故事

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

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

• 角色切記不要總是寫“作為一個用戶”扎拣，而是要把用戶區(qū)別對待。這樣才能更好地理解他們使用什么功能素跺，如何使用二蓝，為何使用。
• 功能即用戶能親自執(zhí)行的操作指厌。應區(qū)分用戶操作和產品功能之間的關系刊愚，因為產品功能可能也提供了用戶所需的價值，但卻極可能不便于操作踩验。
• 價值是完成操作后鸥诽，客戶所得到的好處。價值里邊箕憾，常常要帶有一點褒義詞牡借，或有一些吸引人的內容，比如“高效地……”“……可以節(jié)省話費”等袭异。

需求分解為任務钠龙，由開發(fā)完成，實現(xiàn)功能御铃。

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

1.3 敏捷日常跟進

• 看板
  • 看板又叫任務版并闲，對于Sprint進度的溝通，看板是一種簡單而強大的方式谷羞。從形式上看帝火，看板顯示的是Sprint沖刺待開發(fā)項隨時間的進展狀態(tài)。
  • 故事板簡單說就是把所有正在工作的內容湃缎，張貼到一個板狀空間中犀填。
  • 看板（Kanban）一詞來自日語，指的是制造業(yè)中的一種可視化方法嗓违，有相當復雜的思想和流程九巡。由于兩者看上去很類似，兩個詞匯經初寮荆混用冕广。
• 燃盡圖
  • 在Sprint執(zhí)行的每一天疏日，團隊成員都要更新未完成任務的剩余工作量估算。我們可以創(chuàng)建一個表來是使數據可視化撒汉，就是燃盡圖
  • 根據整個團隊的剩余工作總量沟优，每天進行更新，就可以得到燃盡圖睬辐。

2. 計劃會

• 計劃會準備的內容

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

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

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

  PM 項目經理 Scrum Master 敏捷教練

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

• 計劃會輸出文檔

  • sprint 開始日期枚钓，結束日期

  • sprint 周期

  • 表格（sprint backlog表格）

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

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

  • 每日站會時間

  • 評審會表格

    1. 日期
    2. 評審需求

3. 每日立會

1. 匯報內容

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

2. 燃盡圖

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

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

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

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

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

   1. 團隊內有些信息會隱藏。有的團隊反映說團隊蟹褂凇（比如4-5人）并且大家都坐在一起蜀踏，隨時都會溝通维蒙，沒必要每日站會。而實際上團隊內的溝通在多數情況下只有相關2-3人一起脓斩，而不是整個團隊一起木西。因此每日站會還是非常有必要的（同步、透明化信息）随静；
   2. 團隊錯過最佳的調整機會八千。每日站會中，團隊可以得知距離Sprint目標有多遠燎猛，是否存在障礙或者問題恋捆。尤其存在障礙時，需要整個團隊共同努力重绷，來想辦法解決沸停。這不是說發(fā)現(xiàn)問題了只有在每日站會才說出來，而是發(fā)現(xiàn)問題馬上暴露昭卓，但每日站會需要正式得讓整個團隊得知情況（一般這類信息容易在2-3人之間討論）愤钾；
   3. 團隊沒有儀式感。每日站會可以讓團隊形成規(guī)律候醒，每天固定時間能颁、固定地點所有團隊成員湊在一起同步信息和進度，很容易團隊成員可以形成儀式感倒淫，這是一個非常重要的事情伙菊。

4. 項目迭代

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