l

2016年11月25日 星期五

做了才有感覺

Nov. 25 10:40~11:34

屏幕截图 2016-11-25 10.42.38

 

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

  1. 看板的邊界在哪裡?lead time怎麼計算?
  2. 知道看板邊界之後,誰是你們的上游、誰是下游?你們和上、下游的關係如何?如何透過增進上、下游關係來改善你們的敏捷度?
  3. 為什麼看板第一個工作階段「Backlog」沒有設定WIP?
  4. 如何、何時決定把工作項目拉進Backlog?
  5. 用Given-When-Then(GWT)格式寫成的自動化驗收測試When的部分有兩條句子,用 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:最後退一萬步想,你可不可以在分析之後把一個工作項目切成兩個?你想這麼做也不會有警察來開你罰單。

***

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

沒有留言:

張貼留言