七浪費之六:Delays,Teddy 覺的用原本 TPS 的用語 Waiting 好像比較容易了解。軟體開發的 delays 情況有:
- 等待某人有空:例如,等待 DBA (資料庫管理員) 幫忙設定資料庫;等待 technical writer 幫忙寫使用手冊;等待『隊友』幫忙一起解 bugs;等待公司招募到新人。
- 等待資源:等待測試設備;等待購買的軟硬體設備到貨;等待從 Amazon 買的書寄到台灣。
- 等待某項知識。例如,等待 Product Owner 明確的告訴開發者所有的需求細節;等待 team leader 告訴你 bugs 要如何解,程式要如何寫;等待新人搞清楚專案狀況。
- 等待核准。例如,等待老闆核准專案進行;等待法務審核合約;等待客戶畫押需求;等待批准需求變更。
- 等待功能或產品完成。例如,等待系統分析師生出完整的軟體架構;等待系統設計師畫出全部的 UML 設計圖;等待程式全部完成以便測試;等待程式通過測試。
根據書上的說法,開發人員每 15 分鐘就會做出一個重要的決定(一秒鐘幾十萬上下?!),如果開發人員對於他正在做的工作有足夠的知識(例如,知道客戶到底要他做什麼),或是當他有問題時馬上就可以獲得解答,那麼開發人員就可以快速做出(較高品質的)決定。如果開發人員缺少足夠的知識或是沒有人可以回答他的問題,那麼聰明的人類只會有三種反應:
- 停下手邊的工作,試圖去找出答案:原本的工作被中斷,如果找答案的過程很冗長,造成 task switching 的浪費。
- 停下手邊的工作,找其他事情來做:柿子挑軟的吃,原本的工作可能變成 partially done work。最慘的就是不斷地找新的事情,沒有一件事完成,一直到 stack overflow 為止。
- 猜測可能的作法,硬著頭皮繼續做下去:蠻幹,最後的成果可能不是客戶所需要的,需要 rework 或 relearning。這個現象常常在很多『有理想,有抱負外加有創意』的開發人員身上發現。
***
消除 delays 的方法很多,書上提到一個最簡單的做法:
Complete, collocated teams and short iterations with regular feedback can dramatically decrease delays while increasing the quality of decisions.
Teddy 幫鄉民們把上面這句翻成白話文,就是『採用 agile methods 就對了啦』。
PS:
Teddy 氣象小叮嚀:鄉民們,不必再等待不可能的『颱風假』,除非你的公司在宜蘭縣。
***
友藏內心獨白:等待『發薪水』和『下班』應該不算浪費吧...XD。
越看越覺得跟溫伯格寫的軟體管理學第一冊的內容很像
回覆刪除