精益生產是製造業領域的一大創舉，而如果把精益生產的簡單原則運用到軟件開發上，我們稱之爲精益編程（Lean Programming）。有人預言，精益編程的效果可能與20世紀80年代精益生產所帶來的生產改進一樣重大。精益生產的10條簡單原則對精益編程同樣適用。實際上自適用軟件開發及肯特·貝克的極限編程（Extreme Programming）中都運用了這些原則。
精益原則一：消除浪費
精益生產的第一個原則就是消除浪費。利用價值流分析可以發現流程中的所有活動，並能找出最終添加到產品中的價值，然後價值流分析會試圖找到更爲有效的方法去產生同一價值。
在軟件開發過程中製作的文檔、圖表及模型是軟件開發項目的一部分，但它們往往是消耗品，可以用來幫助系統的生產，但未必是最終產品。一旦系統交付，用戶對這些中間過程的消耗品並不在乎。所以此類消耗品需要證明自己不僅能爲最終產品增值，而且還是獲得最終價值的最有效的方法。
精益原則二： 儘量減少冗餘“庫存”
庫存太多會耗用資源、延長響應時間以及隱藏質量問題。軟件開發的“庫存”是指不屬於最終產品的那些文檔。分析一下就會發現，製作這類文檔所花費的時間佔據了產品週期的一大部分，而最大的浪費還是因爲文檔無法正確、全面地抓住用戶需求而開發了不符合用戶需求的系統。
我們知道用戶很難依據文檔去設想系統的細節；即使是在實際使用前，用戶也不可能正確預測系統的運行；甚至在系統交付之後，用戶還可能發現這並不是今後整個使用期間自己所期望的系統運行方式。而在評估文檔的價值時，這些因素都必須考慮在內。
精益原則三： 縮短系統的響應時間
20世紀80年代，TQM（全面質量管理）原則教會我們如何在數小時而不是數天或數週之內完成產品生產；在傳統軟件開發需要幾個月或幾年時間的時候，電子商務項目往往能夠在幾周之內完成。
丹尼斯·弗雷利曾提議利用降低製造週期所用的技術來縮短軟件開發週期。他建議充分利用“小批量”和“流暢流程”原則。
迭代開發基本上就是把這些原則運用到軟件編程上。按照這種方法，在整個開發週期不斷設計和交付小而完整的部分。迭代週期從幾周到幾個月不等，每個迭代階段都涵蓋從收集需求到驗收測試的整個開發過程。
精益原則四：獲取需求 延遲決策
製造行業過去常常認爲，如果營銷部分能夠準確預測市場需求那該多好。但後來發現這種想法是不對的，相反，應該大大縮短系統的響應時間，以便系統能夠對變化做出充分的反應，從而拋棄對預測的依賴。其實IBM目前所推廣的E－Business On Demand正是出於這樣的思路，而此前戴爾的成功也是與這個理念分不開的。
使需求保持靈活性，並儘可能貼近交付系統，將爲軟件開發提供更強的競爭優勢。在軟件開發的早期階段敲定設計同樣帶有預測性，所以軟件系統的設計應該隨時捕獲新的需求，並對變化做出響應。
精益原則五：滿足客戶需求
導致軟件項目失敗最常見的原因就是需求不全面或不正確，針對這種風險，軟件開發商在繼續設計系統之前，會盡量收集詳細的用戶需求，然後由用戶確認。
但很多用戶在確認需求文檔時經常會拖拖拉拉，他們擔心自己認可的項目到頭來會是個錯誤，所以等待他們確認文檔會浪費大量時間。從這個角度來說，獲得用戶的同意非但不能鼓勵用戶參與，反而會造成開發人員和用戶之間的對立。
準確抓住用戶需求的有效辦法就是藉助於迭代系統開發，及早開發核心特性並且通過每個迭代階段的可用性演示獲得客戶反饋。
精益原則六：結合反饋 一次做好
當在生產線上發現劣質產品時，很多製造企業會對劣質品進行返工，但效果不佳。相反，如果在整個製造流程中運用測試和控制手段，確保每次移交時每個部件都是合格的，這樣就很容易查明產品何時偏離了規格。
業界已經公認，軟件交付後找到問題並修正的成本是早期設計階段的100倍，所以企業需要在編寫程序之前驗證詳細設計的合理性。當然軟件的規格在不斷變化，企業需要利用各種技術手段不斷適應變化。
各種測試技術是整個開發過程中適應變化的最佳手段。另一種應對變化的技術就是再構，即通過受控的方式改進現有軟件的設計，利用再構，初始設計可以專注於眼前的問題，以後再考慮將來的需求。
精益原則七：對員工下放權力
如果軟件開發環境不如預期，主管的本能反應往往是實行更嚴格的流程，更加詳細地明確員工如何完成任務。精益生產則建議採取截然相反的方法，如果開發出現了問題，不要引進外面的專家，而是爲員工提供評估及改進各自領域的工具，給予員工足夠的權力，最終自己解決問題。
跟精益生產一樣，精益編程同樣重視團隊的協作。軟件開發至少需要一次信息移交，即從用戶到編程人員，但更多的時候不止一次，比如從用戶到設計人員，再到編程人員。有觀點認爲，這類書面信息最好全部移交，但實際上在移交紙面信息時，會無形中丟失大量有效信息，而讓小組成員協同工作則效率要高得多，同時還減少了文書工作。
精益原則八：取消局部優化
在過去，不讓機器滿負荷運作是難以接受的，但在精益生產中這卻是合理的。
一些受過訓練的項目經理會非常關注某些局部的管理，正如製造工人致力於儘量提高機器的生產效率一樣。但精益編程是受時間和反饋的驅動，所以局部生產力的優化會削弱整個製造流程。在用戶所處環境不斷變化的今天，如果把局部優化放在非常重要的位置，那當用戶需求發生變化時，所有優化工作都付之東流。
如果某個局部的功能有一定的框架限制，只要它不會拖延工期，就不必爲它擔心。
精益原則九：利用逐步採購
供應鏈並不是在今天才產生，讓供應商相互競爭，保證以最低的成本獲得原材料也是很常見的，但精益生產又一次改變了這種慣例。美國管理大師W·愛德華茲·戴明認爲，與供應商基於信賴的關係創造了給雙方公司帶來最大效益的環境。
事實證明，減少供應商的數量，其合作關係具有更高的質量。長期的合作關係可以幫助企業改進產品設計及生產流程，而且幾乎無需文書工作。
很多軟件企業認識到，傳統的軟件開發合同造成了隱性浪費。而對軟件用戶來說，相對穩定的軟件開發商可以專注於爲用戶提供更優秀的軟件，並可在開發中儘可能遲地使需求穩定下來。
精益原則十：締造精益文化
這個原則不用解釋也一目瞭然，如今優秀的軟件開發意味着能夠不斷適應變化。其實在類似CMM的模型中缺乏對變化迅速做出響應的靈活性。
從某種意義上來說，迭代項目環境成了運行環境，因爲流程重複出現，就可以把流程改進技術從一個迭代階段運用到另一個階段。不過我們需要的不僅僅是涵蓋某個項目的改進模型，只要學習現有的項目，就可以改進未來項目的性能。