精實軟體開發

精益軟件開發是精益製造原則和實踐在軟件開發領域的變體。它基於豐田生產方式（TPS）^[1]，由敏捷社區引入並發展。

起源

精益軟件開發一詞源於Mary Poppendieck和Tom Poppendieck的同名書籍。^[2][3]這本書將傳統的精益原則重新闡釋，提供了22種開發實踐「工具」，並與敏捷開發的實踐做了比較。 通過Poppendieck夫婦在敏捷軟件開發社區中的努力，包括在敏捷開發會議上的幾次演講，精益軟件開發已經被敏捷開發社區廣泛接受。

精益原則

和精益製造原則的概念相近，精益開發也可以總結為如下七條原則：

• 消除浪費
• 增強學習
• 儘量延遲決定
• 儘快發布
• 下放權力
• 嵌入質量
• 全局優化

消除浪費

消除浪費（或者叫muda（英語：Muda (Japanese term)）（日語：無駄），是豐田管理詞典中的一種特殊的浪費）原則，最初是由大野耐一（豐田生產方式之父）的理念所採用的。他將如下行為視為浪費：

• 儲存的等着被使用的汽車零配件
• 生產任何不是馬上就需要的產品
• 不必要的配件移動
• 等待其他配件被生產
• 製造過程中多餘的處理步驟
• 缺陷（質量差）

換句話說，按照精益思維，任何不能為客戶增加價值的行為即是浪費。包括：

• 不必要的功能和代碼
• 軟件開發過程的延遲
• 不明確的需求
• 繁文縟節
• 低效的內部溝通

為了消除浪費，首先必須能夠識別、認識到浪費。如果某項活動可以被跳過或者取消也能達成最終的結果，那它就是浪費。在開發過程中作成但最終被廢棄的代碼是浪費；客戶不經常使用的額外的處理和特性是浪費；令人員在多個任務間切換是浪費；等待其他任務是浪費；缺陷和低品質是浪費；不產生實際價值的、過度的管理也是浪費。

價值流（英語：Value_stream_mapping）方法可以用來識別浪費。指出浪費的根源並消滅它。消除浪費的活動應該迭代進行，最終甚至可以消除一些看似必要的流程。

增強學習

面對開發團隊以及最終的產品大小的額外挑戰，可以說軟件開發是個持續學習的過程。最佳的改善軟件開發環境的做法就是增強學習。在代碼完成後馬上進行測試可以避免缺陷的累積。不是去做成更多的文檔或詳細設計，而是對各種各樣的想法進行實際的編碼嘗試。用戶需求的收集過程可以簡單地通過給最終客戶演示，並聽取他們的反饋來完成。

使用短周期的迭代（每個迭代都應包括重構和集成測試）可以加速學習過程。在決定當前階段的開發內容並對未來改善的努力方向進行調整時，在客戶端幫助下通過簡短的反饋會議來增強反饋。通過這些簡短的反饋會議，客戶代表和開發團隊會更多地發現在進一步開發時會遇到的主要問題及可能的解決方案。從而，基於已開發出的原型，客戶可以更好地理解自己的需求，開發者也能了解到如何才能更好地滿足客戶的需求。另一個關於和客戶溝通、學習的想法是「基於組的開發」，這種方法聚焦於未來解決方案的約束限定而不是各種可能的解決方案，因此通過和客戶的對話加速了解決方案的產生。

儘量延遲決定

因為軟件開發通常具有一定的不確定性，基於多種選擇的方法能夠達成更好的結果，儘可能的延遲決定，直到能夠基於事實而不是不確定的假定和預測來做出決定。系統越複雜，那麼這個系統容納變化的能力就應該越強，使其能夠具備推遲重要以及關鍵的決定的能力。

儘快發布

在一個技術發展非常迅速的時代，儘早的發布產品有助於更快的獲得用戶的反饋來改善當前產品的質量，從而更快的完成下一次迭代。如果每一次快速的發布都能滿足用戶的需求，那麼這個產品就可以視為成功的。每一次迭代的時間越短，團隊內部的學習和交流就會變得更好。擁有了速度，決策會被延遲。擁有了速度，就可以更好的滿足客戶當前而非昨天的需求。

下放權力

傳統的團隊裡都是由團隊的領導者來決定和分配每個人所要完成的任務。但是精益開發主張將這種權利下放到團隊的每個人手裡，從而使開發人員有權利來闡述自己觀點並提出建議。

嵌入質量

質量的管理在精益軟件開發中尤其重要。在這裡，質量的保證一開始便被貫穿在開發過程中的每一個階段，而不只是在測試階段來發現質量問題。

全局優化

全局優化使得每個部門之間的聯繫更緊密。相對於努力降低每個部門內的成本，消除部門之間的隔閡和浪費會產生更顯著的效果。在DevOps成為一大趨勢的今天，開發部門，質量管理部門和運行維護部門之間的協同變得越來越重要了。

參看

• Scrum (development)