敏捷方法的成功密技(十一):Scrum 如何最佳化利用衝刺的容量?


    在上一篇文章《敏捷方法的成功密技(十):Scrum 衝刺目標誰決定?》當中,我們談到了衝刺(Sprint)目標,雖然名義上應該由 Product Owner產品負責人)來制定,但為免團隊根本就不 buy-in,或是團隊實在是無力可達成,故,實務上 PO 仍應與 Scrum Master 和開發團隊「一起」討論,來制定各個衝刺的目標,這樣才像一個符合 Scrum 精神的「團隊」!

    假設當初在衝刺規劃會議時,設定衝刺的週期為兩週(10 個工作天)一個輪迴,開發團隊總共有五個人,那麼開發團隊就總共有 5 x 10 = 50 天(50 man-day)可用。又假設,當初在衝刺規劃會議時,團隊對於「用戶故事點數(User Story point)」的認知,定義為「一點等於一個 man-day」,那麼,衝刺容量就是 50 點。

    當我們依用戶故事的優先級先後,把它們一一塞進第一個、第二個衝刺之後,絕對會發生一件事,那就是,每個衝刺都會有一些剩餘的空間,無法有適合的故事去填補、塞滿!那該怎麼辦呢?

    解決方法其實可以有兩種!

    其一是,我們大可以直接在產品待辦事項清單Product backlog)內,選一些大小合適,但優先級卻不是這麼高的用戶故事,來塞滿各個衝刺的剩餘空間。雖然這樣做,也不會對產品和團隊造成多大的傷害,但是,這樣做並不夠符合 Scrum 的精神,也就是「高優先級用戶故事,必定是提供用戶較高的價值,所以應該優先做」。

    比較好的方式,應該是「將較重要(高優先級),又比較肥大(用戶故事的點數較多)的用戶故事拆解為數個小巧的用戶故事」!這樣做的結果就是,各個衝刺的剩餘空間都會變得更少,更容易可以被塞滿。

    例如,假設衝刺一的容量還有 5 點的剩餘空間,而衝刺二的第 1 個(高優先級)用戶故事卻是 7 點大小,所以衝刺二的第 1 用戶故事是無法往前塞進衝刺一的。可是如果衝刺二的第 1 用戶故事,其實還有可能可以被 PO 開發團隊一起拆解為兩個小故事,優先級先後和其大小分別是「5 點」和「2 點」,那麼,「5 點」的小故事就能被往前搬到衝刺一去執行了,「2 點」的小故事也能繼續放在衝刺二了。

    延伸上述的例子,假設這個「2 點」的小故事,其實已經比衝刺二內其他的用戶故事優先級還要低了,那麼,這個「2 點」的小故事就可以往後搬了,繼續跟衝刺三的用戶故事比,一路這樣比下去,就會發現,搞不好這「2 點」的小故事根本就已經排到第十幾衝刺去了!

    回過頭來,經過這樣「將優先級高的大故事,拆解為數個小故事」的技巧,各個衝刺最後仍然會有一些零星的剩餘空間,那又該怎麼辦?

    其實,只要即將要執行的這前幾個衝刺有做到這些動作,整個產品的用戶故事優先級也就守得八九不離十了,也就是說,開發團隊的精力也幾乎都用在對的時機和對的事物上了。這時,不妨就拋開優先級的束縛,從產品待辦事項清單內,往下(低優先級的方向)找一些大小合適的用戶故事,去塞滿這前幾個衝刺的剩餘空間吧,因為,這其實已經不影響大局了!

    說到這了,有經驗的您也許發現了一個潛在的問題,那就是,怎麼可能那麼理想,一個工作天可以完全被用來做產品開發相關的工作?那公司或部門的例行性會議,不用花開發團隊的時間嗎?團隊成員都不會生病請假嗎?特休假、國定節慶假日不用考量嗎?不用考慮滑手機、看 FB 的放鬆調節空檔嗎?

    是的,您的考量一點也沒錯!欲知詳情,請待我下回來分曉!

    待續...



    更多相關文章:《敏捷方法的成功密技》系列文章總覽