Scrum 的精實

作者 David Starr. David Starr 是 Scrum.org 的首席軟體大師,他致力於提升軟體開發業界的專業素質: 他也設立了線上技術社群 ElegantCode.com (英文)。

2012 年 7 月

審視 Scrum 架構固有的「精實」品質,以及各種使用「精實考量」協助 Scrum 小組進行改善的方法。

套用至

Team Foundation Server

Overview

Seeing Scrum Through the Lean Lens

Toward Leaner Scrum

Conclusion

目前對敏捷式軟體開發的討論總是不例外地會包括,Scrum、精實 (Lean) 和看板 (Kanban) 這三項用來計劃、監視和執行軟體開發活動的工具。 宣稱 Scrum Framework 和 Lean Thinking 可以配合得很好的敏捷實踐者經常會比較及比對這些工具這些工具,而其他人則認為這些工具是用於交付軟體的不同方式。

概觀

Scrum 大受歡迎,所有聲稱使用敏捷式開發方法的小組中,據報有 92% 使用 Scrum[1]。 體驗成功的 Scrum 實例後,許多小組紛紛尋求使其實務作法的成熟度超越基本 Scrum 架構 本文探索以 Lean 和 Kanban 技術、Kaizen 概念或連續增強延伸 Scrum Framework。

Scrum

Scrum Framework,於 1995 年由 Ken Schwaber 和 Jeff Sutherland 引入,是讓小組合作以逐一查看並交付軟體的方式。 Scrum 小組將工作組織到稱為 Sprint 的時間框限,為期一個月或更短,並在每個 Sprint 中產生一組完整且可行的功能。

Scrum Framework 很容易了解,也非常受到軟體開發團隊及其客戶的愛用。 Scrum 鼓勵跨功能和自組織小組,這些小組在整個 Sprint 期間都會專心一意地要交付可行且可能發行之軟體的增量模組。

Scrum 已在《Scrum 指南》中編集成典 ,其中記錄 Scrum 的角色、成品和事件。 Scrum Guide 由 Scrum 的建立者維護,可於 Scrum.org 線上取得。

精實

「精實考量」是一種達到系統最佳化的途徑,著重於減少浪費和改善穿流於系統的整體價值流程。 「精實」與製造業有深厚的淵源,近年來在軟體開發界大受歡迎。

精益思考運用於軟體開發時,可透過在《精實軟體開發:敏捷式工具箱[2]》一書中初次公開的下列七項原則具體化:達成,首先出現在這本書, 。

  1. 排除浪費

  2. 增強學習

  3. 盡可能到最後再做決定

  4. 盡可能快速交付

  5. 授權給小組

  6. 其中的組建完整性

  7. 綜觀全體

將這些原則套用至交付軟體產品的工作並不是最終目標。 我們不是說某人「做事精實」,而是更正確的說某人運用精實原則來引導決策進行,以及選擇會整體改善系統的技術。 例如,測試驅動式開發 (Test-Driven Development,TDD) 會在建立時檢查軟體以建置其中的完整性,因此支援在建立過程中建置完整性的精實原則。

看板

有一個根源於「精實考量」的技術就是「看板」(Kanban)[3],這個技術會在正式方法中使用精實考量,致力於減少浪費、剛好及時交付和避免執行工作者負荷過重。 不同於 Scrum,Kanban 不是反覆項目及累加的方法;而是建置於五個核心活動的反覆項目 Kanban。

  1. 視覺化工作流程

  2. 限制進行中的工作 (WIP)

  3. 管理流程作業

  4. 明確訂定處理原則

  5. 以共同作業方式改善

使用 Kanban 不同的小組通常會有非常不一樣的流程。 Kanban 方法只是一組技術,用來管理處理程序,然後再刻意將它最佳化。 看板 (Kanban) 很容易運用在已經準備就緒的流程,包括 Scrum。

Scrum 和 Kaizen

只要每個 Sprint 都能始終如一交付可行軟體的增量模組,Scrum 小組就會尋找新的方法來改善他們的作法。 有效 Scrum 的核心是 Kaizen,它的概念為持續改良。 狀況良好的 Scrum 小組幾乎一定會使用大量他們在「改善」(Kaizen) 中所著重的作法。 相對估計值、測試優先開發、自動建置及雙人程式設計都適用於 Scrum 小組。

不僅其他工具、技術和作法可以有效輔助 Scrum,scrum.org 網站上也會說明和管理 Scrum 擴充模型。 這個 Scrum 擴充模型鼓勵社群參與記錄能讓 Scrum 更好並與架構一起使用的做法。 在撰寫本文時,已經有許多擴充功能被提出,明確地在 Scrum 中套用精實 (Lean) 做法。

將「精益考量」運用於 Scrum 的優點是不容置疑的。 果然,許多 Scrum 從業人員都體認到將「精實考量」運用於其 Scrum 作法中,已獲得較佳的效能和品質。

透過精實透視鏡審視 Scrum

Scrum Framework 包括下列角色、成品和事件。 如果您不熟悉基本 Scrum 架構,請先閱讀《Scrum 指南》再繼續。

角色

成品

事件

  • 產品擁有者

  • Scrum 主管

  • 開發小組

  • 產品待處理項目

  • 期程待處理項目

  • 遞增

  • 期程

  • Sprint 計劃

  • 每日 Scrum

  • Sprint 檢閱

  • Sprint 回顧

Scrum Guide 制定這些元件互相配合的規則,但 Lean Thinking 則提供進一步最佳化 Scrum 規則、成品及事件的相互作用。 Scrum 小組選取完整產品待處理項目中的一部分來交付每個 Sprint,並專心致力於交付具有適當品質和功能的增量模組。 「精實考量」可以協助工作流程在整個 Sprint 中進行順暢,並降低整體價值流程的浪費。

Scrum 和精實 (Lean) 都在努力保持高品質,這是讓所要執行之整體工作成功的必要做法。 若要實地查看精實軟體開發和 Scrum 共用的原則,只要透過 Lean Thinking 的鏡頭分析 Scrum 的角色、成品和事件即可。

事件

除了 Sprint (所有其他事件的容器) 之外,Scrum 事件只是會議。 「精實考量」通常視會議為浪費,是浪費就應盡力排除。

這會讓人做出 Scrum 事件並非必要的結論。 不過,Scrum 中的每個事件都經謹慎設計以排除其他原本會造成干擾 (非事先計劃) 的會議 執行順暢的 Scrum 事件可以減少開會次數,而且也可以花較少時間回應非預期的中斷。

每個 Scrum 事件都是設計來檢查某個項目和調整某個項目。 此檢查功能支援強化學習及將完整性建置到建立程序等精益原則。 在 Scrum 事件期間調整計畫、需求或其他成品可以支援延後決策和參閱整體的精實原則 下表顯示 Scrum 事件及期間所做的檢查以及調整。

事件

已檢查

適應型

待處理項目整備

產品待處理項目

產品待處理項目

Sprint 計劃

產品待處理項目

先前的增量模組

Sprint 目標

期程待處理項目

每日 Scrum

期程待處理項目

邁向 Sprint 目標的進度

期程待處理項目

每日計畫

Sprint 檢閱

最新的遞增

最新的 Sprint

產品待處理項目

產品待處理項目

其他長期計畫

Sprint 回顧

最新的遞增

最新的 Sprint

Scrum 小組本身

技術作法

Scrum 小組行為

技術作法

在 Scrum 內使用的工作管理作法

成品

Scrum 成品應盡可能簡化到再簡單不過。 Scrum Team 所提供的需求、計劃,甚至軟體,只包含完成工作所需的詳細資料時,都是最有價值的。

產品待處理項目

在完美的世界中,沒有必要建立人們簡單談論範圍以外的需求。 軟體中所需的人員理想上要由建立他們的人從本質上來瞭解,而且也不需要該要求的中間表示。 在與客戶關係緊密的小型小組中,這無法擴充。 在交付功能前預先建立需求對計劃是必要的。 「精實」視需求為庫存 (「精實考量」下的浪費),因此應盡量降到最低。

Scrum 是在產品待處理項目中管理需求,這個待處理項目會規定很少的表單或結構。 不需詳細或明確說明產品待處理項目。

維護產品待處理項目和需求是規劃工作時不可或缺的,但最好的使用方式是在開發小組實際開始處理之前更早建立及修改產品待處理項目。 有效的 Scrum 小組會避免在可能都不會處理到的產品待處理項目中建立需求。

期程待處理項目

在完美的世界中,沒有必要擬定計畫。 開發小組可能只是從佇列中取出下一個功能要求,而忽略需求的內容和成本。 雖然這個簡單的處理工作模型相當有彈性,但未能考量軟體開發本質是複雜的工作。 相當複雜的產品開發受益於計畫的擬定,即使這個計畫簡單又缺少詳細資料。

Scrum Guide 定義 Sprint 選定產品待處理項目子集 Sprint 待處理項目,以及傳遞計劃。 Sprint 待處理項目顯示 Sprint 預計工作的庫存 (浪費),至少每天精簡一次。 這樣每天修改可以確保計劃絕對不是承諾,並且可讓開發小組將實作決策延後到最晚的負責時刻。

Scrum 小組為了使成本最低,會建置勉強足夠的需求和計畫。 這種將庫存最小化的 Lean 方法可以延緩決策時間,並且讓小組有權在 Sprint 自我組織。 與其將重點放在需求或計畫上,Scrum 小組選擇專注在每個增量模組中交付的價值。

遞增

每個 Sprint 包含至少一個可行軟體增量模組的交付項目。 產品遞增是唯一「精益考量」(Lean Thinking) 不會視為浪費的 Scrum 成品。 即使如此,產品增量模組還是可能含有浪費。 拒絕可能出現在未使用的功能,缺失,不完整功能的形式,不容易維護程式碼或足夠納入考量的設計。

高效能 Scrum 小組會毫不留情地排除產品本身的浪費。 執行這項作業的方法通常是,在整個 Sprint期間頻繁檢查增量模組,並隨附保持高品質。 這可以實現 Lean 建置完整性原則的基本要義。

Scrum 小組也受惠於牢記交付增量模組時應遵循的「精實」原則。 Scrum Framework 本身會確保遞增是開放的,以在 Sprint 檢討會議中進行檢查。 在 Sprint 檢閱上接受有關增量模組的意見是增廣知識的基本原則。

角色

Scrum 規定的角色經謹慎平衡,以充分授權給 Scrum 小組並平衡其中的張力。 Scrum 主管、開發小組和產品擁有者會共同合作以獲致成功,這需要所有的人參與來釐清彼此的觀點。 這個共同作業可確保 Scrum 小組成員能查看整個 Scrum 系統,並且讓所有會因為偏重某個角色而降低 Scrum 小組效能的所有決策透明化。

Scrum 共同創立者 Jeff Sutherland 說到,成功的「精實」實作就是下情上達的體系與經過授權且有管理者輔引的工作人員。 Scrum 的自組織開發小組將「精實考量」具體表現經過授權的員工,他們可以在組織內推動學習的風氣並傳授知識,而不藏私。

Scrum 主管是 Scrum 的特殊角色,Scrum Guide 說明如下:

Scrum 主管負責確保人們能夠理解並實行 Scrum。 Scrum 主管會確保 Scrum 小組遵守 Scrum 理論、作法和規則,以達到此目的。 Scrum 主管是Scrum 小組的服務領導者。Scrum Guide - 2011 年 10 月

優秀 Scrum 主管的其中一個主要技能及活動是輔助引導。 在大部分情況下,Scrum 主管會推動 Scrum 事件進行。 Scrum 主管是管理者,儘管採納並奉行 Scrum,他並非人員。

指向更精簡的 Scrum。

使用精益考量考慮及解決 Scrum 的問題通常可以帶來高報酬率,也是維持 Kaizen 文化特性的好方法。 Scrum 小組一直在學習如何將「精實」套用於 Scrum,但許多作法愈來愈受歡迎,是因為這些作法經證實可讓 Scrum 小組更有效。

有許多常見的做法和技巧可直接支援 Lean 原則。 這幾項技術會在下文中針對如何將其實現在 Scrum 小組中進行探討。

接下來絕對不是完整技術清單,而是有關 Scrum 小組如何運用 Lean 實踐者慣用技巧改善的簡單範例。 此外,每個技巧也適用在許多方面。 本文僅說明少數幾個「精實」技術。 Scrum 小組處理下列情節的方式可能不同於本文件所述。

排除浪費

最基本的精實作法或許是摒除浪費。 「精實」會將任何不是產生預期結果所確實需要的事物視為浪費。 軟體開發中的常見浪費包括:

  1. 未使用的程式碼或功能

  2. 導致重新作業的缺失

  3. 延遲或花費在等候事情的時間

  4. 從一個人員、小組或商務流程到另一個的遞交

  5. 高度細部需求

  6. 不充足的需求

  7. 緩慢或不良的溝通

某些浪費不能避免及甚至是必要的。 例如,在最嚴格的定義下,需求文件是浪費。 索引卡,表示尚未交付給客戶的需求。 因此浪費了索引卡。 需求卡本身不是產品功能;它代表要建立功能必須完成的工作。 需求卡的存在可協助開發人員反覆考量和記錄其工作。 多數小組將此視為必要的作法,但也很容易被認定是浪費。

雖然有些必要是浪費的,但大多可以減少、最佳化,甚至是移除。 有些浪費在軟體開發的價值流裡,例如簽入程式碼的長時間等待,這很容易可以被辨認和排除。 軟體開發小組中找到的其他浪費 (例如,在可進行開發之前建立大型需求文件) 隱藏在文化特性背後,必須投入許多精力和時間才能根本改變。

情節

Scrum 已實施六個月。 開發小組正在著手產生軟體的增量、每二週的 Sprint 和所有正向且可測量的品質指標。

捷徑

Scrum 主管開會討論如何指導其小組提高生產力與品質。 Scrum 主管會建議排除「精益考量」(Lean Thinking) 中規定的浪費。 Scrum 主管同意要嘗試這個想法,並尋找浪費的範例,將這些範例歸類為兩份清單:可立即排除的浪費和需要時間管理的浪費。

第一個清單包含 Scrum 主管本身或開發小組排除旳浪費以及不需要任何的許可或等待。 另一個標記為「浪費待處理項目」(Waste Backlog) 並識別浪費是取得全部同意而來,但要花大量時間或心力來變更。 兩個清單的範例如下所示:

立即處理

浪費待處理項目

  • 某些組建是被手動的在組建電腦上被執行,為了這目的這些組建必須被特別的維護。

  • 網站封裝是手動 ZIP 處理序。 將這項作業自動化。

  • 開發人員都在使用共用開發資料庫,因此資料變更經常中斷開發流程。 移至每個開發人員各有專屬開發資料庫的模型。

  • 直到功能可以運行才編寫測試。 鼓勵並教導測試專家的測試先行實務作法。

  • 在編寫所有功能的程式碼之前建立的 UML 模型。

  • 辦公室配置妨礙溝通,相同開發小組的成員為了進行臨時的小型討論也要奔走於各辦公室之間。

  • 盡可能加入安裝程式,讓部署不是手動在作業。

  • Bug 追蹤報告系統中的許多欄位是必要的且很少使用。 將欄位資料設為選擇性項目可以節省建立這些欄位資料所花費的時間。

Scrum 主管帶著這些清單向個別 Scrum 小組提出可採取行動的建議,要求立即改善。 雖然 Scrum 主管帶領小組追求更高等級的品質,但是 Scrum 小組的自我組織本質會要求小組本身重視變革並建立計畫來展現這些變革。

Srpint 追溯性是一個專屬論壇,用於分享增強的想法及獲得實作支援。 有效的 Sprint 追溯性會議通常會產生計畫以制定改善方案,支援「改善」(Kaizen) 文化特性。 排除或改善待處理項目中追蹤的浪費可能需要在 Scrum 小組之外的工作。 這是 Scrum 主管的責任,其工作包括強化 Scrum 的使用與提升整個組織的敏捷度。

限制進行中的工作

情節

成員有五名的開發小組已經使用 Scrum 長達 12 週,完成三個為期四週的 Sprint 並產生各種不同結果。 產生的遞增品質高於實作 Scrun 之前所建立的軟體,但完成的工作似乎變少了,且開發小組成員仍然無法共同作業。 Daily Scrum 每天會提醒小組內每個人自己的工作,不過,這種情況似乎沒有改善。

在 Sprint 計劃期間,開發小組會建立「待辦事項」清單,其中列出要求交付 Sprint 所選每個產品待處理項目的工作。 此技術會在 Sprint 規劃期間建立 Sprint 待處理項目,以及在整個 Sprint 期間追蹤開發小組進度的機制。

開發小組在開發小組工作區域的牆上使用看得見的工作面板,追蹤 Sprint 全部進度。 在最後一次 Sprint 期間, Scrum 主管會在每日 Scrum 之前拍攝工作面板的照片。 有些相片顯示在下面:

第 1 天的工作面板內容

第一天

第 4 天的工作面板內容

第四天

第 9 天的工作面板內容

第九天

第 14 天的工作面板內容

第十四天

第 17 天的工作面板內容

第十七天

第 20 天的工作面板內容

第二十天

Scrum 主管與開發小組共用這些相片。 某些事情是顯而易見的,例如:

  • 正常進行中的工作比開發小組中的成員還要多。

  • 在第一天,開發人員將功能 C 的所有工作提取至「進行中」狀態,並在 Sprint 持續期間讓這些工作維持在該狀態中。

  • 功能 B 一直到 Sprint 結束都未獲得處理,而且沒有完成。

  • 功能 C 在整個 Sprint 期間都有處理,但沒有完成。 當發生不熟悉的問題時,正在使用功能 C 的程式開發人員因為沒有說明檔而感到挫折。 儘管她在每日 Scrum 上巧妙暗示樂於接受任何協助,但是這個期待從未實現,因為其他小組成員都專注在本身的工作上,沒有感覺要對功能 C 負責。

  • 在 Sprint 計劃期間,功能依優先權順序放置在 Sprint 待處理項目中,產品擁有者非常失望 B 功能無法在 Sprint 中完成,因為其順序高於其他已交付的功能。

  • 同時有數個功能在進行中,造成非常不同的程式碼區段都在相同時間變更。 在此 Sprint 期間,當開發人員無意中影響了彼此的程式碼時,這會導致數個組建失敗和重新作業。

所有這些觀測都回頭指向開發小組一次處理許多事項的做法。 在多個工作之中切換並且嘗試同時專注在多個項目上,讓開發小組感覺到在 Sprint 待處理的工作之中超出負荷。 因此,每個小組成員專注在其本身的工作,並扮演個人而非小組成員的角色。

捷徑

在 Sprint 追溯性會議期間,Scrum 主管說明將 WIP 侷限於決定嘗試此技術之開發小組的構想。 開發小組決定在下一版 Sprint 實作所設計的三個新規則,以減少 WIP:

  1. Sprint 待處理項目中的功能是按照由上而下的順序來實作。

  2. 一次最多只能有 3 個項目在進行中。 如果第四個項目已投入進度,小組會暫停以判斷系統發生瓶頸的原因。

Scrum 主管在下次 Sprint 期間全程再次拍照。 有幾張相片顯示在下面:

第 2 天的工作面板內容

第二天

第 8 天的工作面板內容

第八天

第 12 天的工作面板內容

第十二天

第 20 天的工作面板內容

第二十天

在 Sprint 追溯性會議期間,會再次與進行下列 (關於他們在這次 Sprint 期間所變更之項目) 觀測的開發小組共用相片:

  1. 開發小組成員合作處理更複雜的項目。 雖然完成工作所採用的方法有時不同,但這些差異已解決,而且小組整體完成的進度更為快速。

  2. 開發小組成員開始了解原本沒有詳加考慮的產品功能。 每個成員都會報告對共同擁有整體產品的感想。 這突顯了之前個人只注重自己了解的功能的做法。

  3. 會大幅降低立即對程式碼的許多不同區域的協調變更複雜性。 事實上,開發小組的產能大幅地加入。

  4. 雖然功能 E 未此 Sprint 內完成,交付的所有功能,其優先權都比功能 E 的優先權還要高。 即使沒有這個低優先權的功能,產品擁有者很高興決定將遞增交付給用戶端。

雖然在 Sprint 計劃期間建立 Sprint 待處理項目會限制 Sprint 所選工作的批次大小,但是進一步在 Sprint 之內限制 WIP 可以產生更快速的處理量並提高產能。 在 Sprint 期間限制 WIP 也會增進共同作業,並降低小組有別人對其工作無所知的技術專家存在的風險。

減少等候時間

大量時間花費在等候軟體開發過程中的作業結果。 多數開發小組都很容易出現這種浪費形式。 新的 Scrum 小組會在 Sprint 期間發現他們在等候許多作業,包括:

  • 允許執行某個動作

  • 要完成的冗長流程

  • 其他小組或個人的交辦事項

  • 要執行的測試或完成的驗證

  • 存取一個需要的資源

  • 小組之外成員的共同作業

比起 Scrum 小組效率低落,更糟的是客戶和企業等待整合、封裝及運送軟體所花的時間。 這個問題會隨著開發組織的規模而擴大。 當更多開發人員或小組加入專案時,將其工作整合成單一產品的成本會隨之增加。

內建至 Scrum 的最長等待時間是 Sprint。 Sprint 期間是所有 Scrum 事件的容器,其唯一需求是這段期間必須是一個月或更短的時間。 這樣會將等待使用軟體累加的時間限制在一個月內。 大部分的 Scrum 小組更是經常交付可行的增量模組。

情節

公司有六個在大型且複雜軟體產品上工作的 Scrum 小組。 每個專注於特定功能區域和工作的 Scrum 小組會透過主要產品待處理項目進行協調。 Sprint 的長度是三週並包括所有開發小組的整合工作。

之前,Sprint 為期兩週,但當產品增加時,建立的複雜度也隨之增加。 新 Scrum 小組已加入,需要更多時間整合他們的工作,因此 Sprint 已延長來容納整合活動。

第三週現在也稱為整合週。 將新功能整合到主要程式碼行是這段期間的主要活動。 來自每個開發小組的代表人員會在每個「整合週」共同組成「整合小組」。 他們引導整合活動的工作。

整合週期間,整合小組不會接受新的功能,即使要求小幅變更以解決整合問題。 這會因為需要整合小組而在整合週期間導致大量臨機操作程式碼變更。

下圖顯示 Sprint 期間的一般組態管理。 開發小組會在每次 Sprint 開始時建立自己的開發分支。 他們會在第 2 週的尾聲合併程式碼。 在第 3 週期間,開發小組會視需要針對整合會議的要求提供協助。

衝刺 (Sprint) 圖表,顯示三週時間及六個小組

在 Sprint 期間進行整合是必要的,六個 Scrum 小組的產能當中,有三分之一目前用於完成整合。 在這段時間內,小組的許多容量投注在 Sprint 之外的活動上。 請注意,在上述範例中,小組 5 在整合週期間根本沒有作用。

Scrum 小組必須經常轉換環境,其流程中斷逐漸墊高整合週的成本。 某些小組私下將用程式碼建立分支、岔開程式碼,試圖藉此保持當週的生產力,然而卻因此增加的整體複雜度和顛覆做出正確的決定所需的透明度。。

捷徑

小組的 Scrum 主管開會討論選擇。 一個 Scrum 主管敍述她的小組已非常成功的在每個 Sprint 的前兩週期間限制 WIP。 Scrum 主管觀察到,如果小組限制 WIP 一次只能有一項功能,可能可以在完成每項功能時整合。

如果所有開發小組都使用這個作法,就沒有小組會等到第二週結束來整合他們的工作。 不需要等候整合新功能,每個小組現在都可以考慮整合至其所處理功能之「Done1 定義」的主要程式碼行部分。

「完成」的定義是 Scrum 在開發小組對 Sprint 選用的每個產品待處理項目要同意是為真,才能將產品待處理項目視為「完成」。 如需完工定義的詳細資訊,請參閱 MSDN 文章 完成與未完成

在下一次 Sprint 追溯性會議期間,開發小組同意嘗試在個別功能完成時整合他們的工作。 他們建立並遵守下列新規則:

  1. 每個開發小組會將 WIP 限制為一次一項功能。

  2. 在整合至主要程式碼行以前,功能是不完整的。

  3. 在開始進行新功能工作之前,開發小組會以主程式碼行的全新複本來更新程式碼行。

下圖說明產生的活動:

流程更為平順的衝刺 (Sprint) 圖表

新規則已經讓小組體驗到交付功能過程中稍慢的流程。 因為沒有整合週,開發小組再也不必於 Sprint 的第三週期間枯坐而放下工作。

Sprint 期間整合變更所花費的時間起初較長,但更熟悉連續整合模型之後,每個開發小組的生產力都會提高。 經過一段時間後,每個 Sprint 加入的功能會增加。

由於完成功能現在表示功能整合到主要程式碼行,因此再也沒有任何有關功能是否真的完成的問題。 「完成」的定義現在包含整合至每個個別功能的主要代碼。 無法整合的風險大幅降低。

最後,減少開發小組必須等候整合程式碼之時間的決定已提高開發小組的整體產能,而不再需要整合週。 因此,Scrum 小組可能會返回較短的 Sprint,讓產品擁有者能夠視需要提高交貨頻率。

延後承諾

延後承諾是其中一個表達「精實軟體開發」價值觀的原創精實原則。 這個原則通常被描述為「等到最後負責時刻」再進行決策。

過早認可行動的決策毫無價值,因此需要思考。 為何不等到必須決定的時候,屆時可以知道最多與問題相關的資訊。 這樣會限制做出錯誤決策的風險,並且讓您有時間進行更多選擇或決定表面的動作路徑。

情節

在 Sprint 計劃期間,開發小組會建立如何實作 Sprint 所選 PBI 的詳細計劃。 當得知更多資訊時,計畫通常會在 Sprint 期間變更。 他們注意到當工作較不清楚時,計畫的變化更大。 深知未使用的需求是浪費,小組想要避免這個計劃重新作業。

認可一個動作過程需要捨棄其他選項。 這通常會讓體認到承諾的人捨棄想法。 有許多方式可以實作指定的功能,但已選擇動作時,開發人員可能會停止考量其他解決問題的方法或停止創新。

捷徑

開發小組決定允許在 Sprint 待處理項目中定義最大及最小已定義的項目數。 實際上,他們根本沒有詳細規劃,就決定可以在 Sprint 中接受產品待處理項目。

開發小組現在等待瞭解更多時,再來建立此詳細計劃。 對其而言,這表示會在實際開始或進行時,將較大的 Sprint 待處理項目細分為較小的部分 這樣可以將詳細計劃延緩到實際需要時,並且讓小組能夠針對實作改變心意,更貼近工作點。 這也可以確保使用最適合的可能計畫,而不會執行可能不再有效的計畫。

開始實作功能時,這可以促進對實作選項的了解。 在 Sprint 實作了之前的功能以及有時間去做必要的調查期間,開發小組更了解本產品。

視覺化工作流程

Kanban 方法的第一個步驟需要將小組所使用的實際工作流程視覺化。 這可以實現 Lean 的「放眼全局」原則,並且要求顯示實際工作流程,而不只是業務流程文件或其他現有模型的理想化版本。 有用的視覺化會呈現實際發生的狀況。

有了工作視覺化之後,就可以在其中追蹤工作。 一般階段關卡式 (或瀑布模式) 開發流程的範例模型,如下所示,有數個功能正在進行。

在六個閘道中擁有五項功能的瀑布圖

Scrum 小組多年以來都是使用工作流程視覺化來查看 Sprint 的工作。 Scrum 開發小組中,工作流程視覺化最常見的形式是 Scrum「工作委員會」或簡易「Scrum 委員會」。 這個視覺化通常比上述的模型簡單,看起來可能類似下列模型。

Scrum 面板

這種典型的工作流程視覺化形式受到 Scrum 流程跨功能開發小組規則的嚴重影響。 對跨功能開發小組的重點是定義 Scrum 架構的特性。 跨功能小組具備可在每個 Sprint 中交付可行軟體之完整增量模組所需的所有能力。 小組成員同時執行多項軟體開發中的活動。

當跨功能小組一起實作一項功能時,他們可能偶而會同時進行所有項目。 這非常不同於計劃導向模式,在此模式中,專員著重在同時執行一個活動的所有項目。 此外,跨功能小組成員可能會有專門負責的部分,但所有小組成員通常都會處理交付軟體所需的所有活動,無論活動是否在個人的專責範圍內。 跨功能軟體開發小組通常做得比專屬的專家小組還要好。

情節

開發小組即將交付可行軟體增量模組,但是小組成員無法有效配合共同作業。 將程式碼交給測試人員之前,程式碼撰寫人員都是在隔離狀態下處理問題,而這些測試人員則必須在 Sprint 結束前匆忙完成驗證。

這可以在 Sprint 尾聲留一點時間進行測試,因此開發小組有時候會跳過這個步驟,並且交付回復測試未完成的累加。 在生產環境中找到一些缺失,如果當初可以讓功能性回復測試完成,早就發現這些缺失了。

捷徑

Scrum 主管與開發小組一同根據每次 Sprint 期間發生的實際工作流程建模。 即使小組在每日 Scrum 上使用一般的 Scrum 面板,很快就會顯明實際的工作流程是階段關卡式流程。 小組可以產生下列模型反映真正的工作流程:

最初的工作流程,包含五個步驟

Scrum 主管協助小組了解跨部門合作可能提高的生產力。 雖然不確定,小組成員同意試著改善工作流程,使其跨功能性更為提升。

開發小組保持視覺化完整並用它來監視 Sprint 的工作,不過同意尋找每個機會去摺疊階段。 也就是小組尋找兩個階段可能合併成一個的機會,因而取代遞交進行共同作業。 他們針對開發小組中的個人如何合作進行謹慎的變更,一次執行一小部份。 以每個 Sprint 追溯性,修訂模型以反映小組所做的改善。

首先,Arnie 和 Kyle 同意共同作業以合併設計和程式碼撰寫階段。 他們嘗試數種不同的技巧,以增強共同作業,很快就了解工作流程已經變更如下:

修訂後的工作流程,包含四個步驟

開發小組很快就學習到如何在實作程式碼之前建立失敗的功能回復測試,從而產生下列變更:

最後的工作流程,包含兩個步驟

接下來幾月期間,開發小組尋找機會減少交付管線中的階段數目。 小組的文化特性會因為專家分享他們的知識,並且每個人參與成功說明工作流程小組時而有所變更。 小組成員在更多的共同作業發生時,開始會考慮他們自己的「專業通才」。

當小組中的共同作業增加時,關於建立中軟體的共同認知以及小組成員對彼此職責的了解也會跟著提升級。 這個共同作業會在 Sprint 期間自然摺疊工作階段,並且會反映在發生於 Sprint 中的較簡易的工作流程視覺化。 開發小組現在是跨功能,實際工作流程如下所示。

待辦、執行中、完成

小組對排除程序階段的逐一查看反應,最終會產生一開始描述的工作流程 Scrum,也就是進行中的單一開發階段。 這顯示完全最佳化的 Kanban 面板最後如何將其本身顯示為傳統 Scrum 面板。

其中的建置完整性

許多軟體工藝技術著重於建置在建立流程中的完整性。 軟體設計模式、測試第一個開發技巧、重構、結對程式設計,這些技巧都為了尋求軟體在變建立時的品質提升。 使用在建立程序初期提高品質的技術,確保小組不會依賴事後品質檢查「在之後才測試品質」。

情節

開發小組已對測試先行開發技術進行實驗,並且在開發期間成功地將驗收準則的 Given/When/Then 運算式運用於開發人員建立的單元測試。

「假設情況/發生時的/處理方式」(Given/When/Then) 驗收準則格式

給定 <部分初始內容>

當 <發生某個動作>

<此為結果>

小組有易讀的單元測試套件,開發人員可經常根據此套件設計與測試程式碼,享有自動化測試的優點。

雖然這個方法在單元測試層級可行,開發小組的測試專家仍然使用 Microsoft Word 文件來建立功能測試的驗收準則。 在功能程式碼撰寫並完成後,會以手動方式進行驗證。 由於在編碼器認為功能已完成之前,都不會執行這些測試,因此多數的缺失是測試專家所發現的。 這會導致在 Sprint 內重新作業,有時候也會造成在 Sprint 檢閱前無法完成功能。

捷徑

在 Sprint 追溯性會議期間討論接受度準則工作流程時,開發小組決定嘗試下列作業:

  1. 測試專業人員建立的接受度準則不同於 Microsoft Word 文件,而是會使沒有內部實作的自動化測試失敗。

  2. 新的自動化測試每天都會在早上 5 點和下午 3 點產生測試成功和失敗的報告。 新建立的測試永遠失敗。

  3. 程式碼編譯人員選取處理新功能時,會先實作 stub 接受度測試功能開始。

  4. 編碼人員可以進一步精簡這項測試,但須與負責建立的測試專業人員協同合作,才能保持原始測試目的。

  5. 這個功能直到通過測試才會完成。

  6. 所有測試都必須在 Sprint 結束前傳遞。

使用這個技術經過幾個 Sprint 到,缺失和重新作業的情況已減少。 開發小組監視每日兩次執行自動化測試所更新之報告,並讓成功和失敗測試可以顯示成趨勢圖。 小組會建立在每次執行自動測試時更新的報告。 報表顯示兩週 Sprint 內的接受度測試成功和失敗結果趨勢。 圖形如下所示。

自動化接受度測試圖表

開發小組發現在 Daily Scrum 檢視報表比在一般的待執行工作圖表中更有價值。 Scrum 主管確認這個新圖形可以做為 Sprint 待處理項目的一個重要部分。

Scrum Guide 指定 Sprint 待處理項目是選定 Sprint 產品待處理項目的集合,加上傳遞計劃。 對於這個開發小組,計畫現在是從失敗的接受度測試所建構,而完成進度則是根據測試成功與失敗次數的趨勢來追蹤。 如同在 Sprint 待處理項目中使用工作的情形,一樣可以在整個 Sprint 中加入、刪除或修改測試。 特定測試的建立通常會導致日漸增加對應功能的實作。

現在使用實際自動化測試做為功能回復的需求和機制,表示測試是必要的。 這也讓人可以將 Sprint 的工作視為通過自動化測試的進度。 這項測試優先開發技術重新定義了小組對於使用 Scrum 的想法,並且在建立流程本身插入需求驗證,從而建置產品的完整性。

大受歡迎的 Scrum 架構在許多層面上都支援精實原則。 隨著 Scrum 小組的成熟與改善,這些小組通常會發覺「精益考量」是在反覆及累加開發中尋獲更多價值的有效工具。

雖然可以嘗試使用特定技術,但要維持狀況良好的軟體開發小組,必須持續注意改善。 Scrum Framework 的彈性足以容納類似在 Kanban 中找到的 Lean 增強方法。 透過精益考量的鏡頭檢視 Scrum,通常可以產生更好的品質、更高的產能,並且可以減少浪費。

若有意要最佳化小組的 Scrum 的實作,可能還需要一些技巧。 尋找改善方法時,不需要追求完美。 Scrum 追求完美遠比客戶重視的交付高品質可行軟體來得不重要,因此請先將重點放在那些真正會改善產品的事務上。

參考

  1. West, D. (2011). XXXXX。 Forrester Research

  2. Poppendieck, M. P. (2003). 《精實軟體開發:敏捷式工具箱》(英文)。 Addison-Wesley Professional。

  3. Anderson, D. (2010). 《看板:為您的科技企業展開成功的演進式變革》(英文). Blue Hole Press。