在『軟體庫存』這一篇，Teddy 提到可以藉由降低軟體庫存來改善軟體開發流程。這裡面的想法其實是來自於 Implementing Lean Software Development: From Concept to Cash 這本書。該書將『Toyota Production System (TPS)』所提到藉由減少七種不必要的浪費來提昇產品品質的精神，套用到軟體開發中，用以降低開發成本並且改善軟體品質。
這七種浪費分別是 (括號為 TPS 中所採用的名稱)，分七次逐一說明：
- Partially Done Work (In-Process Inventory)
- Extra Features (Over-Production)
- Relearning (Extra Processing)
- Handoffs (Transportation)
- Task Switching (Motion)
- Delays (Waiting)
- 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 的現象，這就是一種消除浪費的手段。
***
友藏內心獨白：有沒有數位冰箱可以存放尚未實做完成的文件和程式碼？
一開始不要寫下所有的 use case 這是可以理解的，但是有個疑問想請教一下，專案一開始是否要先對整個專案的需求進行了解呢? 還是專案進行中一邊開發一邊了解就好了?
回覆刪除To Che Guevara:
回覆刪除這個問題需要要看專案的『特性』。例如，如果是接公家機關的案子，對方不太可能讓廠商『一邊開發一邊了解』，所以事先『需求分析』所需要的時間可能就比較多，寫出來的需求分析文件內容也會比較詳細（姑且不論這份文件到後來是否有派上用場...XD）。在這種情況下，因為形勢所逼，就算事後需要重寫需求，也沒辦法，就視為『必要的浪費吧』（公關費或交際費？）。
如果是公司內部的專案，或是開發產品的專案，就比較有可能『一邊開發一邊了解』。當然這都是『程度多寡』的差別而已，如果你認為，『需求分析』作到這樣，已經足夠釐清主要的問題與可能的風險，那就儘量早點開工吧。以 Scrum 的作法，Product Owner 是需要先把 product backlog (也就是需求) 準備好專案才可以動工，不過此時 product backlog 只要有幾個可以讓團隊動工的 stories 就可以了，其他放在 product backlog 的 stories 可能只是很粗略的想法，可以隨著專案開發的演進慢慢地逐步釐清，或是再增加新的 stories 進去。
最後，思考一個問題：何謂『整個專案的需求』？如果軟體專案的需求是一直在改變的，那麼要如何在專案一開始就整理出『整個專案的需求』？如果用『陣列』來打比方，『專案需求』應該視為『動態陣列』而不是『靜態陣列』。
再請教個問題，在資訊服務公司 (軟體公司)中進行專案時，product owner 通常會是公司內部的人? 還是由客戶端的人來擔任? 因為依您的說法『以 Scrum 的作法，Product Owner 是需要先把 product backlog (也就是需求) 準備好專案才可以動工』，這個人勢必對需求有足夠的了解才行。
回覆刪除To Che Guevara:
回覆刪除以 Teddy 的了解，資訊服務公司是不是那種『搶案子』的公司？以目前台灣的情況，要客戶直接扮演 Product Owner 可能有一定的困難度（除非你跟客戶熟到某種程度，而這個客戶也很上進，願意接受挑戰）。所以，比較簡單的方法，是公司內部指派一人擔任 Product Owner（算是客戶代表），對外，由公司內部所指派的 Product Owner 去了解客戶的需求，對內，由 Product Owner 參與 Scrum 的活動。