當Pattern遇到Scrum（4）：Sprint

June 09 17:30~18:30; 20:55~21:34；22:27~22:56

▲圖片節錄自Google搜尋「衝刺」結果

Sprint Pattern

今天談Sprint，該模式的原文在此，有興趣想詳讀的鄉民可以參考。今天看Context、Problem、Force、Solution這四個元素。

Context：你有一個價值流與產品代辦清單（Product Backlog）定義暫定交付項目與交付順序。遵循敏捷精神，你正努力儘早交付並抓到可定期產品增量的節奏，同時管理生產成本。

Problem：如何組織開發流程？

Forces：

• 人類最基本的流程建基於節奏，節奏實現了儀式和文化上的其他可見事件。隨著文化成熟，新人可以藉由學習這些節奏來融入這個文化。
• 你要管理風險：長期複雜的專案太常交付錯的功能，或無法在時程內交付原先計畫的功能。
• 產品開發應符合企業期待，定期且準時的交付令人滿意的內容和價值。
• 理想上團隊可以依據需要及時生產任何東西，但如果沒有保持某種節奏，長期來看團隊很難持續且穩定的交付產品。
• 敏捷團隊需要隨時探索（inspect）與適應（adapt），而團隊成員的工作表現通常基於他們所完成的工作與改善成效。在探索與適應的過程中，團隊成員需要知道他們朝向正確的業務目標前進。

Solution：採用稱為Sprint的重複、頻繁且固定長度的時間間隔來組織開發流程。Scrum團隊的Sprint周期通常介於2~4週，在此期間團隊致力於完成交付任務。Sprint的短回饋週期特性並可有效降低重工的比例與成本。

***

討論

針對Sprint模式今天專注在Forces上面。Teddy有一位朋友原本團隊採用Scrum，前一陣子他迷上看板（Kanban），覺得看板沒有Sprint（iteration）的限制，採用流（flow）的方式管理工作，這樣子好有彈性啊。看板也不要求像Scrum一樣組織跨職能團隊，現有的角色繼續維持，採用漸進式方法引入變革，真的是好棒棒啊。

於是他心一橫，將團隊由Scrum轉型為看板。原本一個sprint開一次review會議取消了，retrospective會議也改成「有需要才招開」，美其名為JIT retrospective（Just-In-Time retrospective，即時自省會議）。反正看板只要測量lead time然後管理工作流就可以了，這樣子容易很多啊。

沒過多久，朋友的老闆受不了了。以前跑Scrum每個sprint至少都還看得到團隊有「生出一點東西出來」，改用看板之後，這種「節奏」不見了，所以老闆很擔心，然後變得不開心，最後直接插手要求改回Scrum。

其實看板雖然拿掉了Sprint，但看板也講究「節奏」。Teddy的朋友沒有注意到Sprint原本要處理的Forces，其實改成看板之後這些Forces並沒有消失，依然存在。朋友改了Form（形式），也就是把Scrum改成看板，Sprint變成Flow，卻沒有注意原本的Forces在新的看板方法中有沒有被平衡、如何被平衡。在原本的Forces沒有被平衡的情況下，最後的結果（Resulting Context）不被老闆接受，只好打回原形，乖乖繼續跑Scrum。

出一個題目給鄉民們當作練習：

• 請問Sprint模式所提到的這些Forces，在看板方法中是否依然存在？
• 如果存在，看板方法如何回應這些Forces？
• 如果不存在，針對「如何組織開發流程？」這個問題，看板方法所處的Context是什麼？所遭遇的Forces又有哪些？

***

友藏內心獨白：期末考會考嗎？