Tag:

scrum

生活分享

工作系列－軟體產品經理的Scrum推動筆記

by rice0315

記得在兩年前新入職一個草創階段的團隊，合作的技術夥伴希望可以使用敏捷式開發作為產品開發的節奏。就這樣跌跌撞撞地過了兩年，我們在開發團隊上也打造了屬於自己的敏捷開發節奏，這一路的推動與取捨也在這裡整理成筆記與大家分享。

在文章開始之前，以下先整理了一些Scrum的基本知識，來源皆來自參考資料（文章尾端附上參考連結）

什麼是Scrum?

Scrum是敏捷式開發，是一種以人為本的開發方法，強調團隊合作和客戶參與。軟體團隊通常會透過短期的迭代開發，持續交付價值高的軟體，以及根據客戶的反饋進行調整和改進。

敏捷式軟體開發門派更注重在人的層面，講求的是「快速從經驗中學習反應」和「團隊的自我管理」。

Scrum跟其他Agile方法最大差異是在把人（Team，Product Owner, Scrum Master），事（Sprint Planning，Sprint Retro等），物（Product backlog），很明確的定義處理

Scrum需要有哪些元素

Scrum角色：

  • 產品擁有者(Product Owner)：負責決定軟體開發的功能
  • Scrum Master：負責提倡以及確保 Scrum 在團隊中順利進行
  • 開發團隊：負責需求的軟體建置開發、部署
  • 利害關係人：除了Scrum團隊以外的都是利害關係人，凡舉主管、業務主管、老闆、客戶、行銷同事等。

Scrum工件

  • Item：明確的羅列出待開發的項目
  • Task：羅列出開發人員該做甚麼事情以符合 Item 的需求（在Sprint的進行過程中，Task需要可視化管理，）
  • Product Backlog：放置未來待開發的 Item 清單
  • Sprint Backlog：放置本次 Sprint 要開發的 Item
  • Potentially Shippable Product Increment：Sprint 結束後上線的功能
  • Burndown Chart：紀錄 Tasks 剩下的數量

Scrum Ceremonies

  • Product Backlog Refinement
  • Sprint Planning
  • Sprint
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

好的，我們要進入正題了！在導入敏捷開發的過程中，這裡整理了我們的做法與實踐的步驟：

我想要導入，我需要準備什麼?

1.願意一起改變的夥伴：

最好是在組織有影響力的，願意相信Scrum精神，且有毅力願意面對挫折與持續調整，理解Scrum是一個開發流程，不一定完全適合團隊，可以取其精神及優點，客製化到目前的團隊上

2.具備Scrum的基本概念：

領航者或是一起改變的夥伴對Scrum的知識或是理解需要一致，想法相近的話推動起來會比較有力道。且在推動的過程中會遇到團隊的各種疑問，雖然沒有辦法給出完美的答案，但希望可以就本身的知識理解，和團隊現況找到適合團隊的解法。

3.輔助使用的工具：

我要在哪裡整理Backlog? 開發團隊可以在哪裡預估時間? 我要用什麼工具追蹤每日進度?目前我們團隊使用的是Jira，同時擁有以上的功能。一般來說最簡單的可以使用Excel+白板，可以解決以上問題，也是一個工具，或是小型開發團隊可以使用 Notion 或 Jira免費版本

4.找到開始的時間點：

什麼樣的時間點是適合開始的?可以從獨立的、規模不大的專案開始試著進行。先取得小小的勝利。後面會更有信心。

一步步教學(目前我們執行的版本)

Step 1：找到排Backlog順序的人，決定本次Sprint要開發的項目：PO是誰?

Backlog 是確定要作的功能需求列表，給PO定義需求開發順序時使用，PO會從Backlog內安排優先順序，如果沒有優先順序，將很難Backlog項目往下推進。 Backlog分兩塊，Sprint Backlog & Product Backlog，Sprint Backlog是從Product Backlog拉出本次要開發的項目的清單。

Step 2：Sprint計劃會議 這個Sprint要開發什麼的決定會議，

決定這樣的短跑衝刺要達成什麼樣的目標。這時候依靠的是PO排定的順序、技術的評估、Scrum Master的引導收斂，得到結論。 依照目前我們的習慣，在Planing Meeting已會有PM與需求單位確認好的規格，讓技術可以充分理解與對各個Story的初步評估。 我要怎麼知道這個Sprint是否可以完成這些需求?須請技術了解完需求後，針對需求拆解成任務、針對每個項目估時。

*在實務經驗上，Planing Meeting到Sprint開始前我們有針對各個Story的估時會議，會議目的是：確認此次Sprint Backlog的項目已預估時間，與實際人力資源與Sprint天數是否符合。預先知道是否能達成此次目標。

Step 3：每日站立會議：Scrum Master是誰?

站立會議由Scrum Master帶領，每次會議都在大約15分鐘內完成，每人花約2分鐘報告昨天所做的事情，並承諾今天要完成的任務，且可以提出與無法解決的障礙或相關的問題 注意：因為是每日例行，非常容易流於形式 每位團隊成員報告內容都需要對應到任務卡片上，遇到的困難需”最晚”於站立會議上會提出。

Scrum Master 須在站立會議中引導的方式

  1. 當報告內容開始往細節討論或發散，須及時打住另拉會議討論。
  2. 若報告內容無法了解進度，也須請團隊成員明確指出對應任務卡片上，知道自己在說哪個項目。
  3. 若進度不如預期，一張估時1天的卡片報告3天之久，代表估時有問題或開發上遇到問題無法排解，若團隊成員未主動說明，則Scrum Master 須提出討論，引導團隊一起解決。

Step 4：Sprint Review&Sprint Retrospective回顧會議：

在每次Sprint結束後，會與開發團隊一起檢視此次Sprint的成果。並且討論以下問題：

  1. 確認本次Sprint是否有確實進行(檢核點定義、燃盡圖狀態)
  2. 確認工作流程是否有可以優化之處
  3. 定調Sprint規範與更新

這個會議也是Sprint的精神所在，一個部分是可以與團隊一同檢視成果，建立共同的成就感以外，也可以針對每次Sprint討論並且提出小小的調整、小小的優化，長時間堆疊後會成長出最適合開發團隊的開發流程（複利效應啊！）建議此會議可以不要省就不要省。

Scrum適合我的開發團隊嗎?

1.先檢視現況：梳理出目前開發流程的步調，以及目前遇到的困難。我要解決目前開發流程什麼樣的問題？是開發速度太慢、永遠都在delay、還是需求變來變去，沒有做完的一天?

2.團隊本身的狀態：Scrum推崇的團隊大小大約10人以內，較大型的開發團隊會更不適合，尤其是在最一開始推動的時候。以及團隊本身的成員都是較資深的狀態嗎？Scrum追求的是每位成員都是可以保持開放與持續改進的狀態，團隊成員可以接受這種模式嗎？推動Scrum就會把所有開發流程透明化，團隊每天完成什麼、規格敘述什麼、一切都是共享的資訊，團隊的狀態會很同步一致，但相同的不會有保護自己的心態出現，願意與團隊一起調整一起成長是很重要的。

3.我準備好了嗎：檢視自己在團隊內的角色，推動新的流程絕對會遇到很多困難，和付出很多成本，困難與成本都是可以負荷的嗎?或是本身是一個傳教士的狀態，不怕困難的帶領大家（拖著大家）往理想的世界前進，不畏困難且有信仰！

在網路上的Scrum流程中，我們實務上保留的&我們捨棄的

我們保留的：

  • Sprint Planning
  • Daily Scrum
  • Sprint Retrospective

我們捨棄的：

  • Product Backlog Refinement
  • Sprint Review

為什麼?

對我們來說，推動Scrum是要讓產品快速迭代以符合產品發展。我們執行的是0到1的產品，以及我們是從5人的開發團隊一路推廣到進15-20人的開發團隊上。在團隊擴張迅速且產品快速從無到有的情況下，對目標有共識、有共同畫面是很重要的環節，所以我們保留Planning 會議，與技術一同訂定目標與預期時間。

且每日的會議追蹤有助益將問題的影響降到最小，我們會說：「開發上有問題時，最晚提出討論的時間是每天站會。」而在這種快速節奏上的開發模式，有可能是常常一轉眼忘記自己做過了什麼，或是同時團隊也在快速擴張，這個時候Retrospective就會很重要。但這也是相對困難的一場會議，網路上有些參考做法可以看看。

至於我們捨棄的

  • Product Backlog Refinement

中文名為產品待辦清單精煉會議，是在確定每個Sprint Backlog之前，針對待辦清單內的項目進行討論與優先序與釐清內容的會議。有助於後續的Sprint Planning會議更能明確的安排。現在回頭來看覺得如果有時間可以試著執行看看。

推動心得小結：

在軟體產品開發這條路上，最重要的是找到適合團隊的開發節奏。在這段推動的過程中我們也調整了好幾次開發流程，取消我們覺得不需要的會議、加回曾經被取消的步驟，重新拉回節奏等等。甚至在產品剛上線的時候的節奏也與日常維運、迭代開發時的會不同，對於我來說，Scrum是輔助我們建立一套屬於我們團隊的節奏工具，並不是照本宣科。不是網路上有，我們就一定要做。

在這個推動的過程中我們也受到很多的質疑、不肯定，團隊內的夥伴與團隊外的都有，但使我們堅定運行下去的除了長官的支持以外，穩定地交出符合期待的成果和維持站台品質、快速配合等，漸漸讓大家可以理解這樣的做法是可行且可長期運行的。這段經驗很難能可貴，也整理出來與大家分享，希望有幫助對Scrum有興趣的開發團隊。

其他工作系列文章：

我手上有很多事情要怎麼整理? 第一次聽到甘特圖可以這樣開始
工作系列 – 如何量化自己的工作？掌握工作時間的方法

參考資料

0 comment
1 FacebookEmail