軟體開發過程中的等待

等待在軟體開發過程中的浪費比例應該是最大的。

下面這些種等待，在你的項目中是否也發生過呢？

(1)等待客戶確認
(2)等待上司命令
(3)等待環境構築
(4)等待前一個階段的成果物
(5)等待Bug修改完畢
(6)等待測試結果
(7)等待UI設計圖
(8)等待不知道什麼——莫名其妙的等待

其實大可不必發生這些等待。

首先，要弄明白髮生等待的原因，只有這樣才能夠找到根本去消除一些不必要的等待。

等待是怎麼發生的呢？

第一種等待工序定義錯誤造成的。

為什麼兩個工序之間需要空閑時間呢？因為這兩個工序是由不同的人來完成的。一個人工作的時候另外一個人必須等待。

---------------

比如：以Bug修改為例，測試人員登記Bug後，開發人員需要分析一下Bug產生原因，進行影響性分析，進而提出解決方案，並修改bug，自己驗證後再提交給測試人員確認。

整個過程中，測試人員基本處在等待狀態。

如果說這是因為工序就是這樣定的，沒有辦法，只能等待，那就有些遺憾了。

在分析出問題的現象之後應該繼續分析問題的實質。
之所以迴歸測試的過程需要等待的原因是流程本身設計有誤。也就是說，測試需要等待的流程設計導致了等待的發生。

設想一下，如果把測試放在前面，而代碼修改放在後面會怎麼樣呢？

也就是說，測試案例是通過自動化的測試代碼來表達的。
開發人員只要運行測試代碼就可以知道代碼的修改是否正確。那麼，此時測試代碼已經書寫完成了的測試人員大可以去做別的工作（比如增加新的測試案例），而無需等待。

--------------------

再比如，需求文檔發送給客戶後，需要等待的客戶確認，只有等客戶確認了之後才能夠開始開發工作。

這也是工序要求如此，前一工程不完成，後一工序無法開始。

其實並不是這樣的，這種等待是因為溝通方式選擇錯誤。

需求採用文檔書寫就導致了必須要等待。如果（功能性）需求採用可以工作的原型來展示（也就是說直接開始開發工作，並且用開發出來的成果物向客戶展示），那麼只要客戶確認說OK，就可以直接將原型轉成可以工作的軟體（比如修改開發版/發布版標誌位）。換句話說，需求確認結束，開發也就基本完成了。如果客戶說要變更，那就按要求變更，直到客戶確認OK即可。

至於非功能性需求，如效能、安全、容錯等可以通過會議討論，白板拷貝的方式留下確認，馬上進入開發對應，而無需等待。

上述兩種等待是工序設計錯誤導致的等待，可以通過調整工序來規避。

第二種等待是由於管理不到位造成的。

比如：由於沒有對需求確認文檔進行管理，導致需求細節不明，需要回憶、搜尋。在回憶搜尋、期間無法進行後續工作所形成的等待就是管理不到位造成的。

但是，反過來講，如果要將所有的確認細節進行文檔整理，也是需要花費工時的，二者之間的得失如何權衡？Team Dev會出於自我保護的目的而留下文檔記錄。但是這種做法還會形成別的浪費。比如：咬文嚼字。

那麼功能性需求應該是怎麼記錄的呢？故事卡，編號。

 

更有甚者，全員停機殺毒...

 

管理不到位的問題，可以通過改善管理方式進行規避。