顧問文章分享 Consultant Articles

執行長室 專案經理 林亮均 James Lin

 

1970年，Winston W. Royce於IEEE WestCom軟體工程學會發表的論文中，描述了一種「線性順序」的流程，每一階段都需要等待上一階段的結束，下個階段才能開始，而誤會非常大的是，Royce以其為反例說明，軟體開發不能如此進行，而描述「迭代式」流程可視為更高級的開發流程。其迭代式流程與當今的敏捷方法論相似，但不知為何，「線性順序」的瀑布模型受到了聽眾的青睞，並成為一時的主流。

 

「Agile」，我們耳熟能詳的翻譯即為「敏捷」，以實務上的解讀「因應環境的變化，能夠快速適時地進行反應及調整」。以「Scrum」而言，屬於一種迭代式的軟體開發流程，其因應變化所做出的調整週期，最快為一個「Sprint」。

 

Scrum的概念源頭可追溯至1986年《哈佛商業評論》由野中郁次郎、竹內弘高所著的〈The New New Product Development Game〉，於文中首次使用了橄欖球術語「Scrum」，描述產品開發所使用的方法，以團隊作為單位透過不斷的來回傳球，向目標往前推進。

 

其文章影響Peter DeGrace、Leslie Hulet Stahl所著《Wicked Problems, Righteous Solution: A Catalog of Modern Engineering Paradigms》一書，二位作者參考日本產品設計與製造方法，尋找軟體開發領域的相似案例，並描述他們認為「齊頭並進 (all-at-once system)」的體系比「線性瀑布式的流程」更為有效。

 

Jeff Sutherland從書中獲悉許多理念，並著手發展自己的軟體開發模型，其闡述「以單一一位超級程式設計師，從開發到交付所有工作項目，是最為簡單的齊頭並進方式」，但壞處在於未來的擴充性與知識傳承，他期望建立的開發模型能讓團隊緊密結合，如同一位超級程式設計師從頭做到尾的一致性。於1993年，由Jeff Sutherland、Jeff Mckenna與John Scumniotales組成第一個Scrum團隊。

 

為讓讀者了解迭代式開發，透過「Coin Flip Game」網路影片，從中體會其帶來的差異：https://www.youtube.com/watch?v=HW2DEZLRAhw

 

在快速瞭解Scrum的發展源起後，筆者將從規劃至執行，綜合角色與情境，希望透過簡易的描述說明，讓讀者體會實務上團隊建置與運作：

 

一、從規劃下手

（一）定義團隊成員

專案團隊的成員組成，依功能性的職稱可能有所不同，如專案經理、系統分析師、系統設計師、程式設計師、測試人員等，但在Scrum團隊中僅定義三個重要角色，分別是：

• Product Owner (產品負責人，可視為需求的來源)

1. 擔任客戶與團隊之間，傳遞需求的溝通媒介
2. 手上有著一份需求項目的「待辦清單」
3. 掌握所有需求項目的故事內容、輕重緩急與允收標準

• Scrum Master (Scrum專家，可視為讓Scrum往前推進的教練)

1. 扮演教練的角色，透過「引導」而非「權力」的方式凝聚團隊。
2. 退居幕後，不斷調整自己的風格以順應團隊
3. 可為團隊移除各項障礙

• Team Member (團隊成員)

1. 負責將故事內容拆解為工作項目，並評估項目的大小
2. 負責開發工作
3. 交付需求項目

 

（二）定義團隊的執行速率

團隊的執行速率，會影響團隊在一個Sprint內，可容納處理多少個需求項目。初期的預設及定義標準，會隨著執行期的推進，經由不斷的歷練與回顧，將使預測Sprint的可處理量，越趨於符合團隊的實際速率。

• 定義Sprint的總工時：扣除可能的工時損耗，計算團隊每個Sprint的預設容量，如同預測手上的杯子可容納多少水量。
• 定義衡量需求大小的標準：如同準備幾種尺寸的實物(XS、S、M、X、XL等)，可協助快速丈量與評估需求故事的大小，未來亦作為剩餘工作量的估算。

 

（三）定義Sprint週期

依不同的專案屬性、需求特性、團隊能力，甚至是客戶的可配合度等，評估與定義合適的Sprint週期，一個Sprint週期包含從需求確認、執行一直到展示成品、執行回顧等，週期最短可能是一週，而普遍認定的上限為四周。

 

（四）規劃Sprint會議

在一個Sprint週期內，主要會有四個會議，其會議的長度，在團隊幾次Sprint循環後，可找到最適合於屬於自己的會議時長。主要的會議包含：

• Sprint Planning Meeting
  Sprint規畫會議，一般建議若以一週為週期，約2小時以此類推
• Daily Scrum
  每日站立會議，一般建議不超過15分鐘
• Sprint Review 或Sprint Demo Meeting
  檢視或Demo會議，一般建議若以一週為週期，約0.5至1小時以此類推
• Retrospective Meeting
  自省會議，一般建議若以一週為週期，約1至2小時以此類推

 

（五）導入輔助工具建立檢核點

以筆者的經驗，建議可加入輔助工具，如看板管理，藉以增加多人協同作業中，資訊傳遞的透明度。更進一步，可增加數個檢核點，掌握各需求項目在Sprint內的流動。看板管理並不侷限於實體透過便利貼方式，或是線上平台 (如Trello等)，各有其應用上的考量與優缺點。

 

二、動手執行

（一）溝通與佈達

新的開發模式如同進行組織變革，所謂的變革就會帶來抗拒，向團隊成員與相關利害關係人的溝通就顯更為重要，甚至需求的來源-客戶是否願意配合這樣的切割交付與週期產出，就會是立即碰到的課題待雙方溝通。

 

（二）從現在開始

Product Owner收集與彙整來自四面八方的客戶需求，手上除了擁有待辦清單外，已準備好預計在此Sprint內完成的項目。

在Sprint Planning Meeting的目標，就是要讓團隊成員「承諾」此Sprint內預計要完成的項目。上半場，Product Owner著重與團隊討論所有的需求故事「要做什麼」。而下半場，團隊開始運作，將故事拆解為各個工作項目，找出「要怎麼做」，並開始分派各工作項目。

一般效率較高的團隊，可於會議上確認六至七成的工作內容，於工作展開後，剩餘的工作隨著推進，將越來越具體與清晰，而Product Owner要有空間讓團隊持續諮詢與問問題。

在Daily Scrum，團隊成員快速的相互交流進度，也因此，進度的推遲具體可在一天左右就被發現，而需要適時補救，不再擴大。

Sprint Review或Sprint Demo Meeting，團隊成員透過此次會議，除交付「已承諾」的成品外，亦同時取得相關人員的回饋，藉以調整接下來的待辦清單。

Retrospective Meeting，於每次的Sprint的尾聲最後才召開，針對問題尚未根深蒂固，趁著團隊記憶猶新，找出幾件可改進的具體事項，制定計畫後，依計畫完成這些改變。

 

返回列表頁