精益軟件開發中的 7 種浪費以及如何防止它們

精益流程思維優先考慮消除和減少浪費編譯。 儘管大公司採用了“精益”方法，但由於其“明顯的性質”，一些標準的“浪費”做法仍然存在。 在採取嚴格的方法之前，深深烙印在人類和組織實踐中的本性是頑固的。

什麼是廢物？

任何需要資源/時間或精力但在績效或收入方面沒有產生相關結果的東西都被稱為“浪費”。

最終，“減少浪費”程序的設計和指導旨在提高團隊的生產力和成果。

然而，既然精益軟件開發是敏捷的先驅，我們可以在軟件工程和開發中採用這七個減少浪費的原則，以產生有效的產品和服務，降低成本，加快產品上市時間。

1. 部分完成的工作

如果以前的工作從未重新開始，那麼這種努力就是浪費。

在完成/完成之前的任何工作都不會增加客戶的價值主張； 因此，如果擱置，它會浪費時間並挑戰維護代碼。

一個當代的例子是當客戶需要對產品進行修改或額外功能時。 企業致力於緊急完成它們； 開發團隊必須停止正在進行的工作並根據要求採取行動。 在同一頁面上，如果以前的工作永遠不會重新開始，那就是浪費精力。

或者

未編碼的文檔：要求非常詳細，但從未得到實施。

如何減少這種浪費？

• 重點應該是“完成”，而不僅僅是“開始”一個項目。
• 減少在製品的任期。
• 停止等待每個需求的詳細規範，直到團隊準備好實施這些工作（那時這不會是一個失敗的原因）。

2. 額外流程

任何沒有傳達實用價值並不必要地延長產品上市時間或成就的添加過程或未讀文檔都是一種浪費。

然而，商業政策通常要求此類文件，有大量文書工作但從未閱讀過。 這些努力是奢侈的。

典型例子：

• 不必要的文檔細節。
• 沒有執行的額外管理或計劃。

如何減少它？

組織可以區分什麼是失敗的原因/努力和什麼帶來價值，重點應該放在產生有意義的結果和通過限制“數量”工作來完成更多“質量”工作的渠道上。

3. 額外功能

任何為/由客戶添加但未要求/無助於增加收入的功能或低價值功能都是浪費精力。

企業在添加不會被大量使用或執行的功能時會犯此開發錯誤； 這個新功能確實處於閒置狀態並增加了應用程序的複雜性。

軟件 80/20 規則起著重要作用——80% 的用戶只使用其 20% 的功能。 因此，重點應該是讓這 20% 的功能成為一流的，以留住現有用戶。

附加代碼有其缺點：

• 增加應用程序的複雜性。
• 可以使潛在的應用程序崩潰點。
• 需要在產品生命週期內進行不必要的跟踪和維護。

如何減少這種浪費？
專注於迭代開發——這意味著在初始產品發布期間，構建強大的主要功能來定義您的應用程序的 USP。

專注於使其功能化並驗證學習產品的持續進步。 此外，根據您的市場分析、消費者行為和反饋，繼續構建適當的功能。

4.任務切換

當人們不適應並阻礙他們現有的流程時，將他們分配給多項任務可能會花費他們大量的時間。 完成一兩項特定任務的最有效方法是一次完成一項。

在任務之間切換時，關閉現有任務並在另一個任務上獲得動力需要花費少量時間，這稱為上下文切換，如果您期望從一個任務不斷轉換到另一個任務，這些內容切換會累積，從而延遲“結果”或“交付時間”。

如何減少它？

簡單——一次做一件事。

• 減少內容切換。
• 盡量減少干擾或分心。
• 推遲那些不重要的。
• 一次將資源分配為一個項目。

5. 等待/延誤

批准依賴關係應主要在產品路線圖中進行計時； 如果沒有分配特定的時間間隔，請準備好延遲回復和反饋。 延遲也使消費者無法實現產品的實際價值。 但是，作為開發人員或設計師，您必須等待完成工作的批准； 因此，您無法完全避免延時。

你能做些什麼來減少這種情況？

• 在等待現有反饋的同時選擇/分配一些東西。
• 分配時間輸入和審查。
• 考慮快速通話、面對面交談，而不是通過電子郵件發送更改。
• 定期反饋。

6. 運動

如果開發或研究團隊分散了所獲得的信息並且沒有適當地標記/標記它們，則可能需要很長時間才能消除混亂和加入。 如果每次交付可交付成果時信息都放錯了位置； 這將嚴重阻礙結果。

如何減少它？

• 標籤分配或獲得的資源。
• 減少反饋時間。
• 面對面的合作。

7.缺陷

缺陷造成的浪費量=（缺陷的影響）x（未檢測到的時間）

由於其複雜性，軟件開發不可避免地會出現缺陷，但是當它們在執行和修復過程中被延長或因修復或返工而產生的成本影響時，就會出現問題。 此外，主要的代碼錯誤和錯誤可能會影響和阻礙整個產品生命週期，並使其容易受到安全威脅，從而造成數百萬的收入損失。

你能做些什麼來減少這種情況？

• 立即測試。
• 不斷整合。
• 產品測試並儘快發布。