做了才有感覺

Nov. 25 10:40~11:34

 

昨天上午在北科上「敏捷與精實軟體開發」，一上課擔任「專案經理」角色的同學先報告上週專案進度，包含專案看板、用Cucumber寫成的自動化驗收測試、跑在Jenkinks上的整合報表。看完之後Teddy問了幾個問題：

1. 看板的邊界在哪裡？lead time怎麼計算？
2. 知道看板邊界之後，誰是你們的上游、誰是下游？你們和上、下游的關係如何？如何透過增進上、下游關係來改善你們的敏捷度？
3. 為什麼看板第一個工作階段「Backlog」沒有設定WIP？
4. 如何、何時決定把工作項目拉進Backlog？
5. 用Given-When-Then（GWT）格式寫成的自動化驗收測試Ｗhen的部分有兩條句子，用 and連接起來，為什麼要這麼寫？會不會有什麼問題？
6. 「定義測試DoD」這個工作項目已經完成了，當初該工作項目在看板流動的時候是經過分析、實作、才流到測試階段，還是直接從Backlog拉到測試階段？

針對這些問題和學生討論過後，他們也問了幾個問題，其中有一個比較有趣的問題：

學生：一個工作項目從「Backlog」拉到「分析階段」，分析完成之後發現太大，可以切成兩個工作項目嗎？例如「開發票」這個功能，經過分析階段之後發現可以分成「二聯發票」和「三聯發票」。

Teddy：為什麼要切？

學生：因為不切會做不完？

Teddy：何謂「做不完」？看板有要求你要在多久完成一個工作項目嗎？

學生：「做不完」的意思是要花比較長的時間才能完成。

Teddy：這個狀況在看板中會如何展現？

學生：就…會有比較長的lead time（交期）？

Teddy：對啊，所以發現lead time太長就是一種改善的訊號（看板六大原則第三條：Managing Flow）。你們應該是Scrum跑太習慣，所以地一個反應會想把工作項目切小一點，希望在「一個開發週期中完成」，忘了看板是「流（flow）」的概念。

Teddy：但是，這個問題也有另一個角度可以探討。請問你們Backlog工作階段的「DoR」（Definition of Read）是什麼？

學生：我們沒有訂。

Teddy：這會不會是問題的根源？因為工作項目沒有跟「上游的人」討論清楚就直接拉到Backlog，所以才會在分析之後想要把工作切小。為了縮短lead time，在看板中如果可以在工作進入Backlog之前就先切成大小相近且偏小的工作項目也許可以改善這個問題。

Teddy：最後退一萬步想，你可不可以在分析之後把一個工作項目切成兩個？你想這麼做也不會有警察來開你罰單。

***

友藏內心獨白：是不是比微積分簡單很多。