l

2010年10月5日 星期二

消除浪費 (1):Partially Done Work

Oct. 05 22:21~23:28

在『軟體庫存』這一篇,Teddy 提到可以藉由降低軟體庫存來改善軟體開發流程。這裡面的想法其實是來自於 Implementing Lean Software Development: From Concept to Cash 這本書。該書將『Toyota Production System (TPS)』所提到藉由減少七種不必要的浪費來提昇產品品質的精神,套用到軟體開發中,用以降低開發成本並且改善軟體品質。


這七種浪費分別是 (括號為 TPS 中所採用的名稱),分七次逐一說明:
  1. Partially Done Work (In-Process Inventory)
  2. Extra Features (Over-Production)
  3. Relearning (Extra Processing)
  4. Handoffs (Transportation)
  5. Task Switching (Motion)
  6. Delays (Waiting)
  7. Defects (Defects)

Partially Done Work 

東西沒做完,這些半成品無法出貨給客戶,只能放在家裡,時間一久可能會有發霉的疑慮。屬於這類的例子有『尚未被實做的需求文件,尚未 check-in 的程式碼,尚未被測試的程式碼尚未被佈署的程式碼』。Partially Done Work 是一件很可怕的東西,首先,它會讓開發團隊有一種『進度正常甚至超前』的錯覺。


程式設計師們:功能都寫好了啊(其實還沒完整測試,所以只能算『半成品』)。


專案經理:好開心,好開心,每個人的工作都做好了。

經過  N 天之後,專案截止日期快到了。

專案經理:騙肖ㄟ,系統連安裝都有問題,是誰說做好的?(Teddy 內心獨白:胃潰瘍又發作了。)



***

其次,這種半成品數量太多,時間一久,開發團隊都忘了系統中哪些東西是可以用的,哪些是半成品。到時候整個系統要整合起來,又是一大問題。再者,東西放太久沒用是會『壞掉』的,沒錯,軟體或文件也會臭酸(路人甲:那放在冰箱不就好了...)。

例如,以傳統的軟體開發方式,撰寫程式之前,一定要先做『需求分析』,然後產出一本厚厚的『需求分析書』(路人甲:人家的需求分析書怎麼只有薄薄的幾張 A4 紙,而且還是用 double spaces  排版過的...XD)。假設這本分析書是用 use cases 格式撰寫,裡面包含 100 個 use cases,此時這本分析書就是『尚未被實做的需求文件』,屬於 Partially Done Work 的一種。假設開發團隊每一個 iteration (兩週) 可以實做完成 3 個 use cases ,經過半年後也才完成 36 個 use cases。剩下的 64 個 use cases,經過這半年後,還有多少是屬於『值得信賴』的 use cases 呢(不需要修改依然有效)?

開發過軟體的人應該都知道,『需求一直在變』是軟體專案唯一不變的真理,所以,從這個角度來看,太早把需求寫完』並不是一件好事,因為太早寫完之後如果沒有足夠的資源能在短時間內實做完成,那麼這些沒實做完的需求,放久之後是會『壞掉』滴(feedback loop 太長,時間拖太久)。

東西放著讓它壞掉,你說這是不是一種浪費?

所以,在 Scrum 中,希望開發團隊要為每一項 task 與每一個 story 定義完成條件 (the definition of done),以避免這種 Partially Done Work 的現象,這就是一種消除浪費的手段

***

友藏內心獨白:有沒有數位冰箱可以存放尚未實做完成的文件和程式碼?



4 則留言:

  1. 一開始不要寫下所有的 use case 這是可以理解的,但是有個疑問想請教一下,專案一開始是否要先對整個專案的需求進行了解呢? 還是專案進行中一邊開發一邊了解就好了?

    回覆刪除
  2. To Che Guevara:

    這個問題需要要看專案的『特性』。例如,如果是接公家機關的案子,對方不太可能讓廠商『一邊開發一邊了解』,所以事先『需求分析』所需要的時間可能就比較多,寫出來的需求分析文件內容也會比較詳細(姑且不論這份文件到後來是否有派上用場...XD)。在這種情況下,因為形勢所逼,就算事後需要重寫需求,也沒辦法,就視為『必要的浪費吧』(公關費或交際費?)。

    如果是公司內部的專案,或是開發產品的專案,就比較有可能『一邊開發一邊了解』。當然這都是『程度多寡』的差別而已,如果你認為,『需求分析』作到這樣,已經足夠釐清主要的問題與可能的風險,那就儘量早點開工吧。以 Scrum 的作法,Product Owner 是需要先把 product backlog (也就是需求) 準備好專案才可以動工,不過此時 product backlog 只要有幾個可以讓團隊動工的 stories 就可以了,其他放在 product backlog 的 stories 可能只是很粗略的想法,可以隨著專案開發的演進慢慢地逐步釐清,或是再增加新的 stories 進去。

    最後,思考一個問題:何謂『整個專案的需求』?如果軟體專案的需求是一直在改變的,那麼要如何在專案一開始就整理出『整個專案的需求』?如果用『陣列』來打比方,『專案需求』應該視為『動態陣列』而不是『靜態陣列』。

    回覆刪除
  3. 再請教個問題,在資訊服務公司 (軟體公司)中進行專案時,product owner 通常會是公司內部的人? 還是由客戶端的人來擔任? 因為依您的說法『以 Scrum 的作法,Product Owner 是需要先把 product backlog (也就是需求) 準備好專案才可以動工』,這個人勢必對需求有足夠的了解才行。

    回覆刪除
  4. To Che Guevara:

    以 Teddy 的了解,資訊服務公司是不是那種『搶案子』的公司?以目前台灣的情況,要客戶直接扮演 Product Owner 可能有一定的困難度(除非你跟客戶熟到某種程度,而這個客戶也很上進,願意接受挑戰)。所以,比較簡單的方法,是公司內部指派一人擔任 Product Owner(算是客戶代表),對外,由公司內部所指派的 Product Owner 去了解客戶的需求,對內,由 Product Owner 參與 Scrum 的活動。

    回覆刪除