前言

在 Scrum 當中，花費最多時間，對於產出直接有影響就是衝刺(Sprint)本身了。衝刺隨時可能有預期之外的困難，特別是團隊正在挑戰新的領域、專案，或開發新的產品功能，就算團隊能夠達成衝刺目標 (Sprint Goal)，在此之外仍然有我們可以關注的地方。

衝刺目標

由於跟接下來要談的東西有些相關，作為預備知識，讓我們先快速看一下何為衝刺目標 (Sprint Goal)，從 Scrum Guide (2020 中譯) 看起：

Sprint Goal 是 Sprint 的單一目標，儘管 Sprint Goal 是由 Developers 所做出的承諾，但它為實現該目標所需的確切工作提供了彈性。Sprint Goal 還創造了連貫性和專注性，鼓勵 Scrum Team 一起工作而不是分開行事。

Sprint Goal 是在 Sprint Planning 事件中被創造出來，然後添加到 Sprint Backlog 裡。當 Developers 在 Sprint 期間工作時，他們將 Sprint Goal 銘記在心。如果需要做的工作跟他們原本預期的不一樣，他們會與 Product Owner 協同合作，在不影響 Sprint Goal 的情況下，來協商 Sprint Backlog 的範圍。

我們可以從中發現到，衝刺目標具有幾個重點：彈性、連貫性、專注性、可作為協商 Backlog 的依據。簡單來說，因為有了明確目標，團隊可以隨時校準，避免偏誤之餘也保有彈性。

此外，先有衝刺目標，才會挑出適當的 Sprint Backlog；而不是從挑完的 Backlog 再總結出衝刺目標，好似先射箭再畫靶一般。

衝刺之外

通常我們會把焦點放在交付價值，當團隊實現了衝刺目標，也順利交付價值予客戶，這是個很棒的結果，產生收益，皆大歡喜。該如何達到這個境界，已經有許多業界前輩們分享各種努力方式與歷程，而今天文章的主題「衝刺之外的學習」則關注在另一個議題－－「衝刺之後，團隊能力有什麼增長？」

產品目標 (Product Goal) 與衝刺目標 (Sprint Goal) 並不一定能對團隊能力帶來成長，而在團隊投入一次又一次的衝刺後，我們都不樂見團隊仍然維持在過去相同的技術水準，缺少新知更迭，以同一套模式不斷運作，這對於未來要「回應變化」是個隱憂。

於是我們可以思考，是不是該做點什麼，來讓能力有進步的可能？

學習衝刺

如果我們把衝刺的概念應用到學習上面呢？利用短期時限、明確目標、持續回饋的概念來引領學習。這並不是什麼劃時代的想法，只是把過去的個人學習計劃、小組學習，以衝刺的形式表現出來，但當我們要執行時，馬上會遇到時間的問題，我們可能會考慮：

1. 直接空一段時間來執行，把衝刺完全拿來做學習。這種方式密集且高效，但可能不是所有團隊都能夠採納，也會有向上(或外)說服的困難。
2. 切割工作時間，例如 80% 在開發，20% 在學習。這種方式採雙軌併行，影響較小，但容易產生優先權的問題，在工作出現問題時，學習可能會被忽略掉，以及它的節奏可能無法穩固。
3. 發生在工作之外。這取決於團隊的自發、熱情、好奇等，但並無明確的承諾在其中。

第二個方案看起來問題還不少，但仍然是一個相對權衡的方法。我以它為例，繪製下圖來呈現學習衝刺與開發衝刺之間的闖係。

在中間，開發衝刺是大家最熟悉的部分，在這之前會先執行規劃會議，再配合日會與衝刺、而後的審查與回顧會議，最終將增量交付到客戶手上。

而上方「學習衝刺」的部分呈現了期間不固定的現象，但它仍然與開發衝刺具有一定的因果關係，它的成果會「支持」未來的開發衝刺，而開發衝刺的「瓶頸」或對於未來的「預則」則成為學習衝刺起跑原因。

下方，作為對照，若團隊沒有刻意進行學習，讓技能固守在起始，隨著時間可能讓缺口擴大，反而把技術債、阻礙、缺陷帶給帶入未來的開發衝刺。是否能在開發衝刺中稍然無息的還債，或修正缺陷呢？這是個理想，但並不容易，所以有目的的發起新活動，或許是個突破點。

關於學習衝刺這個概念，還有一些需要提醒的小主題，我們接著看。

學習衝刺只是概念

我們大可把它當作一個名詞，看完就可以忘了，但重點是如何發揮它的精神。目的是促進團隊保持學習，避免在無限又緊湊的開發衝刺當中限制了成長。

也許我們會疑惑，那請成員提學習計劃，自己利用時間進行不就可以了嗎？是的，這的確是一種方法，也行之有年。

但是，透過衝刺的概念，讓團隊有機會思考：

1. 學習的題目可以產生多大的價值？團隊有多麼需要這些新知識？ (長期目標)
2. 在接下來最近的時間點，我們的學習目標是什麼？ (短衝、目標)
3. 團隊成員是否知道彼此在學什麼？還有什麼互補的機會？ (透明、展示)
4. 學習的過程是不是可以定期分享出來？ (透明、他人也學習)
5. 學習的路線是否出現偏誤？ (檢視)
6. 因應現況，我應該對學習的安排做出什麼調整？ (調適)
7. 學習的困難是否有人可以幫忙排解？手邊有什麼資源是可以加速學習的？ (透明、互助)
8. 這次的學習有什麼值得一再運用的技巧？有什是未來應該避開的冤枉路？ (回顧)

敏捷精神是關鍵

學習衝刺是一種刻意安排的活動，它有目標、有方向、有時限，也會與未來的開發衝刺有所掛勾。它具備 Scrum 與敏捷精神，並不是單調一路學習路線，學習本身也要充滿透明、檢視與調適。因此學習過程是透明的、是參與到日常對話的，成員彼此有機會看到問題並相互協助。

有趣的是，學習衝刺的增量會發生在自己身上，產生的價值同時在自己也在團隊身上。

時間問題

這麼做有沒有什麼問題？我想對於一個成熟的敏捷團隊而言，這些活動與精神要移轉到「學習」這件事上是沒有問題的，但「時間」會是考驗。這邊也是沒有魔法的部分，對於開發團隊而言，時間確實是稀缺的。

正如之前的文章「時間擠一下就有了，我們擠了沒？」所言，這都是一種取捨，端看團隊成員與管理階層願不願意進行，我們是否要承擔未來可能發生技能不足的風險？

什麼時候開始

Scrum 當中回顧會議可以是一個學習衝刺開始的契機，團隊除了常規的分享好的表現與可以改善的部分之外，建議增加一個問題：「在專業技術上，我們應該做出什麼改變？」。

合併開發與學習是否可行

或許團隊不想切割，而是直接把「學習」作為 PBI 放入衝刺當中，表面上看起來好像簡單了一些，但實質上它不容易與開發項目進行排序，也不容易對準當下的衝刺目標，仍是建議分開進行較為清晰。

後記：更多的可能性

不僅是學習，處理技術債、修正年久失修的問題們，也可以試著以相同的思維來面對。