l

2014年9月1日 星期一

不是Scrum也不是Kanban的問題,是Story有待加強

August 29 22:50~23:59

螢幕截圖 2014-08-29 23.57.37

 

8月28日【Kanban遊戲工作坊】結束之後,有一位好朋友留下來跟Teddy聊天…

朋友:今天下午我們用製作「炭烤雞排」的方式來親自體驗看板方法(Kanban Method)的六項基本精神(Visualize 、Limit WIP 、Manage flow 、Make policies explicit 、Implement feedback loops 、Improve collaboratively, evolve experimentally)。但是軟體開發和工廠的生產線不一樣,軟體的每個需求都是獨一無二、不重複性的開發工作,真的可以把精實生產或TPS那一套應用在軟體開發上面嗎?

螢幕截圖 2014-08-29 23.58.36螢幕截圖 2014-08-30 08.05.50螢幕截圖 2014-08-30 08.07.38螢幕截圖 2014-08-30 08.10.46螢幕截圖 2014-08-30 08.11.17螢幕截圖 2014-08-30 08.17.19螢幕截圖 2014-08-30 08.11.27螢幕截圖 2014-08-30 08.10.58螢幕截圖 2014-08-30 08.09.49

Teddy:這個問題很好。可以給我一個你覺得沒辦法應用的例子嗎?

朋友:我們經常會接到完全不知道要如何實作的需求,這時候我們就必須要花時間去研究。例如,我們最近需要開發Android App,但是我們團隊沒有一個人具備這樣的知識。所以研究Android App開發的這個工作,我們就不知道要花多少時間。

Teddy:這和「炭烤雞排遊戲」之間的關係是?

朋友:剛剛在遊戲中我們測量了製作一份雞排訂單的lead time(前置時間、交期),然後持續改善,藉由限制WIP、觀察瓶頸、調整工作流程、精進技術、添購設備、降低變異性等,來讓工作流順暢並且提高品質與產能。但是,像我剛剛提到的技術研究工作,這種工作在軟體開發中經常出現,而且每次長短都無法預估,這樣我測量lead time還有意義嗎?

Teddy:你們現在怎麼進行你所說的「技術研究工作」?

朋友:我們會寫一個technical story,像是「研究Android App開發」。

Teddy:這個工作會預估多久的時間呢?

朋友:這就是我們現在遇到的問題啊,假設一開始我們預估兩周,時間到了之後去問負責的人,他總是回答「還沒研究完畢」。

Teddy:難道你沒發現問題出在哪裡嗎?

朋友:哪裡?

Teddy:就是你們撰寫story的方式有問題啊。首先,「研究Android App開發」並不是一個end-to-end story。其次,這項工作太大了,無邊無際,驗收條件也不明確。到底怎樣才算是把這件工作做完?看完10篇文章?一本書?會安裝開發環境?會寫Hello World?還是要做出特定功能的App並且上架?

朋友:我大概了解你的意思了,因為需求不明確,所以開發人員不知道這項工作如何才算做完。因此,很可能會漫無目的的研究下去。

Teddy:沒錯,對應到剛剛的炭烤雞排遊戲,你們的技術研究工作正在不斷地產生「半成品庫存」

朋友:嗯,因為我們沒有設定WIP。

Teddy:除了沒有限定WIP以外,加上需求太大,所以開發人員不斷地累積「技術庫存」,而沒有產出實際的東西出來。

朋友:所以我應該要先把工作切小,然後限定每位開發人員的WIP。

Teddy:這是一種做法,你也可以限定每個工作流程的WIP。另外,就算先不管WIP,我相信只要將story改寫成粒度較小的end-to-end story,問題就可以改善很多。

朋友:可以給我一個例子嗎?

Teddy:你們的App想要做什麼?

朋友:嗯,簡單說,就是把我們web-based系統可以看到的一些資料顯示在手機上面。

Teddy:這樣就簡單了啊,根本不用寫technical story,可以直接寫user story。例如,身為使用者,我可以在手機上看到XX資料。這個「XX資料」就是你們系統的資料,任何資料都可以,一開始越簡單越好。這樣子這個user story就比較有可能在短時間內完成,也比較容易了解開發人員的進度。

朋友:你是說,利用撰寫實際功能,讓開發人員專注在所需要完成此功能的最小所需知識即可

Teddy:對,就是這個意思。

朋友:我回去可以試看看。

Teddy:很棒

***

有些人導入Scrum或Kanban,但最後失敗,於是宣稱:「Scrum失敗了、Kanban失敗了、敏捷開發失敗了」。Teddy要說:「方法沒有失敗,是應用方法的人失敗了。」簡單的說,就是你、你的團隊、你的公司失敗了。

***

友藏內心獨白:Stop starting, start finishing。

***

廣告插播,10月4日(六)【深入探索需求—捷體驗設計工作坊】已確定開課,課程介紹請按此

6 則留言:

  1. 這跟邪教有什麼不一樣
    宗教本身都不會失敗,失敗的都是人? 那還要宗教幹什麼?

    什麼時候scrum/kanban成為方法論的唯一真理了?
    容不下其他看法的看法本身就是失敗的。Teddy你已經不是個稱職的trainer了。

    回覆刪除
    回覆
    1. 文章中的哪一句有說「scrum/kanban成為方法論的唯一真理? 容不下其他看法的看法本身就是失敗?」我談的是引進方法,但卻沒有依據方法本身去落實,導致結果不如預期。這樣的結果,是方法失敗,還是實施方法的人失敗?我的看法是後者。

      刪除
  2. 這故事我感覺跟 Scrum/Kanban沒有太大關係,反而比較像是目標管理的問題...

    回覆刪除
    回覆
    1. 個人覺得Agile方法是較透明化及多次溝通的方法
      或許管理本身就很有問題,而在Scrum/Kanban的方法下被突顯出來

      個人覺得重點當然是把事情作好,但常常有的人會覺得不必搞什麼Agile
      卻又作事亂作一通...XD

      如果可以,個人還是喜歡進行Agile的合作方式,較能突顯問題

      刪除
  3. 認同Teddy的說法.不是工具的問題,是使用的人不懂得善用.(難聽點就是小朋友考試考不好,怪老師沒教XDXD)
    Agile的方式是漸進式系統性的管理,能夠有效幫助對於系統結構較敏銳的人來進行管理,亦能夠幫助對於流程規劃較沒有概念的同仁釐清流程重點,並指令式的讓他們去Follow階段性的工作,畢竟不是每個人都可以當PM或對於規劃這件事較擅長的.
    個人認為Teddy的文章非常有助於我們更了解這些功能與方法,非常感謝Teddy的分享!期待未來更多的分享!

    回覆刪除