SCRUM筆記

cookie..c發表於2024-07-13
Scrum筆記

大綱

  • 神馬是敏捷？

  • SCRUM是神馬？

  • SCRUM的團隊架構

  • SCRUM的最佳實踐

    • 使用者故事
    • Sprint（衝刺）
    • Burn Down Chart（燃盡圖）

1.神馬是敏捷？

 敏捷各路諸侯：極限程式設計（XP）、SCRUM、MSF（微軟解決方案框架）、OpenUP(RUP敏捷版)、精益開發、水晶方法、特性驅動開發
什麼是敏捷？
  • 美國敏捷聯盟提出四大宣言和十二條準則
  • 敏捷宣言：
    image
    • 個體和互動更優於流程和工具
    • 工作的軟體更優於詳盡的文件
    • 客戶合作更優於合同談判
    • 響應變化更優於遵循計劃

    靠左更敏捷，靠右更接近傳統開發模式

  • 敏捷準則
    1、 我們的最高目標是，透過儘早和持續地交付有價值的軟體來滿足客戶
    2、 歡迎對需求提出變更——即使是在專案開發後期。要善於利用需求變更，幫助客戶獲得競爭優勢
    3、要不斷交付可用的軟體，週期從幾周到幾個月不等，且越短越好
    4、 專案過程中，業務人員與開發人員必須在一起工作
    5、 要善於激勵專案人員，給他們以所需要的環境與支援，並相信他們能夠完成任務
    6、 無論是團隊內還是團隊間，最有效的溝通方法是面對面交談
    7、 可用的軟體是衡量進度的主要指標
    8、敏捷過程提倡可持續的開發。專案方、開發人員和使用者應該能夠保持恆久穩定的進展速度
    9、對技術的精益求精以及對設計的不斷完善將提升敏捷性
    10、要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術
    11、最佳的架構、需求和設計出自於自組織的團隊
    12、團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行為

2.SCRUM是神馬？

  • 近年最火的敏捷方法論
  • SCRUM中文翻譯：橄欖球
  • SCRUM適用於大中小性專案
  • SCRUM核心內容
    • 團隊架構
    • 軟體研發框架
      image

3.SCRUM的團隊架構

  • SCRUM的團隊角色
    • 產品負責人
    • SCRUM Master
    • “自組織”的開發團隊

  • 產品負責人（產品經理）
    • 主要職責：
      • 提供願景
      • 提供邊界
      • 提供使用者故事的優先順序
    • 要特別注意：
      • 需要和開發團隊溝通需求
      • 需要考慮開發團隊的研發能力

  • SCRUM Master（相當於教練角色）≠專案經理
    • 沒有行政權利
    • 訓練團隊用正確的方法做事，遵循SCRUM的流程和做事原則
    • 不代替團隊做決定

  • “自組織”的開發團隊有什麼角色？
    • 業務分析師
    • 程式設計師
    • 測試人員
    • 軟體架構師
    • 資料庫設計師
    • 使用者體驗設計師
    • ……

  • 怎樣才是“自組織”？——SCRUM Master領銜，其他成員聽從指揮
    示例如下
    image

4.SCRUM的最佳實踐

SCRUM在需求方面的核心理念

  • 需求是“湧現”的！
    • 不要檢視初期就明細化全部需求
    • 透過“使用者故事”來組織及細化需求
  • 將“寫需求”轉變為“討論需求”。
    • 使用“使用者故事”來討論需求
    • 所有人都參與討論，儲蓄明確需求細節

4.1使用者故事

 示例：
	 作為網站的所有者，我希望能統計廣告的點選次數，以便我能清楚廣告收益

 標註格式：（重要）
	- 作為……角色
	- 希望系統可以……（目標）
	- 以便……（原因）
這個格式的作用：
	作為……角色--->從使用者的角度來思考問題
	希望系統可以……（目標）--->思考系統要實現什麼功能，達到什麼效果等
	以便……（原因）--->思考這個功能對於該使用者有什麼實質價值
  1. 使用者故事的難點
  • 需求有一系列大小不一的使用者故事組成。
  • 最開始的使用者故事往往是“大故事”，需要拆分為“中故事”、“小故事”。
  • 難點：
    • 發現發現和提煉使用者故事
    • 由粗到細地拆分使用者故事
    • 安排使用者故事優先順序，分派不同的Sprint中去實現

  1. 如何寫出第一個使用者故事？
    實戰：某網上售票系統，請寫出第一個使用者故事！
    建議：以甲方老闆角度來寫。
    參考答案：作為某某局長，希望建造一套網上售票系統，以便更好地為人們服務。

    開始分解使用者故事：

    • 從第一個使用者故事開始分解
      • 細分“以便……”這部分
      • 反向思考“希望系統可以……”部分
    • 進行系統涉眾分析，列出關鍵使用者
      • 思考使用者在本專案上的利益所在
      • 思考“希望系統可以……”部分
      • 思考“以便……”這部分，確認“希望系統可以……”這部分的是否合適

  2. 同一種使用者不同場景繼續拆分

  • 如何拆分下面的使用者故事？
    • 作為一個使用者，我需要登入系統，以便只有我才能訪問自己的資訊。
  • 提示：
    • 作為一名已註冊過的使用者，……
    • 作為一名新使用者，……
    • 作為一名健忘的使用者，……
    • 作為一名已註冊的使用者，……
  • 參考答案-1
    • 作為一名已註冊過的使用者，我能用我的使用者名稱和密碼登入，讓我能信任該系統。
    • 作為一名新使用者，我能透過建立使用者名稱和密碼註冊，讓該系統能記住我的個人資訊。
    • 作為一名已經註冊過的使用者，我能改變我的密碼， 讓我能保證它是安全的或容易記住他。
    • 作為一名已經註冊過的使用者，我想要系統在我的密碼很容易被猜測時提醒我，讓我的賬號很難被侵入。
  • 參考答案2
    • 作為一名健忘的使用者，我想能夠申請一個新的密碼，讓我忘記密碼時不會被永久地鎖住。
    • 作為一名一註冊過的使用者，我不想在我登入嘗試失敗後看到這是由於使用者名稱錯誤、密碼錯誤或二者資訊都錯誤導致的資訊，讓其他人很難冒充我。
    • 作為一名已註冊過的使用者，我應能在我的賬戶出現連續3次失敗的嘗試後得到通知，讓我知道是否有人在檢視訪問我的賬戶。
  1. 使用者故事到底要拆分到多細？

  • 兩大標準：

    • 能在一個Sprint中完成。
    • 加入滿意條件（詳細要求）

  • 例如：以下使用者故事可在一個Sprint中完成：

    • 作為負責市場的副總裁，我想在評估以往廣告促銷活動的效果時可以選擇節假日季節，以便我能確認那些有利潤的促銷活動。
    • 如何加入滿意條件（詳細條件）呢？

  • “滿意條件”示例

    • 確保它可以工作在大部分零售節假日。
      • 聖誕節、復活節、總統節、母親節、父親節、勞動節和新年
    • 支援跨2個日曆年的節日。
    • 節假日季節可以從某個節假日到另一個設定（比如感恩節到聖誕節）
    • 節假日季節可以設定為該節假日前面的某些天
    • 不用支援中國的春節

4.2 Sprint

  1. Product Backlog 和 Sprint Backlog
  • Product Backlog
    • 中文翻譯：產品代辦列表
    • 產品需要完成的所有使用者故事的集合
    • 使用者故事有大有小，既有史詩級別，也有小粒度級別
  • Sprint Backlog
    • 中文翻譯：衝刺代辦列表
    • Sprint中需要完成的所有使用者故事的集合
    • Sprint中的使用者故事都可以在該Sprint中完成，並且都應該有滿意條件。
  1. Sprint - 1
  • 一個Sprint就是一個小版本。
  • 建議時長1個月。
  • 一個Sprint並不是一個“小瀑布”。
    • 很難區分需求、設計、程式碼、測試階段。
    • 所有工作基於對使用者故事的討論。
    • 測試先行，測試驅動，單元測試必不可少。
    • 設計也是“湧現”式的。
  1. Sprint - 2
  • 產品負責人和“自組織”開發團隊商量並規劃每個Sprint的使用者故事。
  • 估算使用者故事。
    • 精準估算有“滿意條件”
    • 精準估算規劃在Sprint中的使用者故事。
    • 粗略估算或暫不估損大中粒度的使用者故事。
    • 估算由“自組織”開發團隊負責。
    • 精準估算時，單位建議為小時；粗略估算時，單位建議為天。

4.3 Burn Down Chart

  • 用來跟蹤Sprint未完成工作的情況
    image

Sprint中的一些最佳實踐

  • 結對程式設計。
  • 持續整合。
  • 測試驅動、測試自動化。
  • 每日會議。
  • Lessons Learned（經驗教訓總結）

相關文章