精簡的軟體開發
作者 David J. Anderson。 David J. Anderson 是三個書籍， 《課程中的在敏捷管理方面:在向看板的路徑上》 的作者，於 2012 年發行， 《看板:為您的科技企業展開成功的演進式變革》， [1] 於 2010 年發行，和 《軟體工程的敏捷式管理:套用條件約束的商業結果》， [2] 於 2003 年發行。 他是 1997 年和 1999 年間於新加坡建立敏捷式軟體開發方法、功能導向開發之小組的成員。 他建立 MSF for CMMI Process Improvement，，這會是共同撰寫軟體工程學院的技術提示， 《CMMI 和 Agile:何不兩個都接受!」他是精實系統公開的建立者 (http://www.leansystemssociety.org)。 他是 Lean Kanban University Inc.，授權訓練的 CEO，而且全世界的 Kanban 訓練的品質等級組織透過網路夥伴而導致一家國際管理訓練和顧問公司， David J。 Anderson & Associates Inc. (http://www.agilemanagement.net)，可協助科技企業透過較佳的管理原則和決策制定改善其績效。
Anderson 說明「精實軟體開發」。
套用至
精實、軟體開發、專案管理、Team Foundation Server
Introduction
精實與敏捷
敏捷之外的精實
定義精實軟體開發
值
準則
實務作法
「精實軟體開發」一詞最初是在會議名稱，是歐盟 ESPRIT 計劃在 1992 年 10 月於德國 Stuttgart 舉辦的會議。 Robert "Bob" Charette 於次年 1993 年單獨在其探討較佳軟體專案風險管理方法的著作中，一併提出「精實軟體開發」的概念。 「Lean」一詞最早在 1991 年由 James Womack、Daniel Jones 和 Daniel Roos 在《改變世界的機器： Lean Production 的故事[3]》一書中提出，是用於描述 Toyoya 管理方法的英語詞彙。 稍早已有精益 (Lean) 可能適用於軟體開發的想法，只在之後的 1 至 2 年首度在生產程序和工業工程採用過。
Womack 和 Jones 在他們 1995 年出版的第二本書籍中[4]定義了「精實考量」的五大核心支柱。 這些為：
值
值資料流
流程
提取
完美
這已經成為接下來十年的預設 Lean 工作定義。 為達到完美，就必須減少浪費。 有 5 個支柱時，是第 5 個支柱真正能與眾多觀眾產生共鳴 (透過系統化識別及排除浪費的活動以追求完美)。 從 1990 年代後期一直到 21 世紀初期，「精實」(Lean) 幾乎完全與摒除浪費的作法聯想在一起。
Lean 的 Womack 和 Jones 定義尚未通用。 Toyota 的管理原則更為合適。 以三個日文術語更能貼切地描述單一英文字「浪費」：
Muda：日文字面意義是「浪費」，但隱含表示無附加價值的活動
Mura：日文字面意義為「不均」，並解釋為「流程中的可變性」
Muri：日文字面意義為「負擔過多」或「不合理」
「完美」不僅透過減少無附加價值活動來追求，也會透過順暢的流程和避免超過負荷來達成。 此外，豐田生產管理方法是主要以人員的基本層面為基礎，深受 20 世紀品質保證和統計製程控制專家如 W. 等人學說的影響 Edwards Deming 提出的建言。
可惜的是，Lean 的定義不一而足。
精實與敏捷
Bob Charette 受邀，但無法出席 2001 年在美國猶他州 Snowbird 舉行的會議，會中發起了＜敏捷式軟體開發宣言＞[5]。 儘管錯過了這次重大的歷史性會議，「精實軟體開發」仍被視為其中一個敏捷式軟體開發方法。 Jim Highsmith 在他 2002 年出版的書籍[6] 中，以專章收錄 Bob 關於本主題的會談。 Mary & Tom Poppendieck 後來又繼續著作 3 本[7,8,9] 系列叢書。 在 21 世紀開始幾年期間，「精實」(Lean) 原則會用來說明敏捷式方法較佳的原因。 「精實」說明了敏捷式方法會包含一點「浪費」，因此產生較佳的經濟結果。 精實原則會用來當做採用敏捷方法的「許可授與者」。
敏捷之外的精實
近年來，「精實軟體開發」已實際在其相關專業領域中脫穎而出，但不明確屬於「精實」運動旗下的一支。 這個演進從 Lean 產品開發概念假設及 Donald G 的作品開始。 Reinertsen[10,11]，以及從大型系統工程之非 Agile 陣營與 James Sutton 和 Peter Middleton[12] 的作著興起的觀念。 我也綜合整理了 Eli Goldratt 和 W. 的著作 Edwards Deming 的著作，並逐漸形成對流程而非對減少浪費的著重[13]。 我在 2005 年依照 Reinertsen 的吩咐，推廣看板系統的使用，這些系統會限制進行中的工作，只有在準備好要處理工作時才會「調出」新工作。 Alan Shalloway 在其 2009 年出書的相關主題[14] 中加入了對「精實軟體開發」的想法。 自 2007 年起，精益生產的出現成為軟體專業開發流程當中的一個主要的勢力，並專注於流程改善、管理風險和改善 (管理) 決策制定。 看板 (Kanban) 已成為精實行動在 IT 相關工作中的主要推手。 這顯明專注於流程而非排除浪費，在知識工作 (例如軟體開發) 的連續改善活動中證實是較佳的促進因素。
定義精實軟體開發
因為沒有特定的「精實軟體開發」方法或流程，定義「精實軟體開發」頗具有挑戰性。 「精實」並不等同於個人軟體流程、V 模型、螺旋模型、EVO、功能導向開發、極致程式設計 (Extreme Programming)、Scrum 或測試導向開發。 如果軟體開發生命週期流程或專案管理流程經觀察，與「精實軟體開發」運動的價值觀及「精實軟體開發」的原則一致，就稱這個流程是「精實的」。 因此那些期望有一個能夠遵循的方法的人並且將其名為精實軟體開發的人將會感到失望。 您必須了解 Lean 原則並採用 Lean 的核心價值，以改變或調整自己的軟體開發程序。
精實軟體開發分為許多不同的學派。 最大和可爭議，導致學校是精實系統公開，包括 Donald Reinertsen， David Jim Sutton、Alan Shalloway， Bob Charette， Mary Poppendeick 和 David J。 Anderson。 在公開及其確定行位置的 Shape 之前個別進行開發的 Mary 和 Tom Poppendieck 的工作，例如克雷格 Larman， Bas Vodde[15,16]，，和，最近，會 Coplien[17]工作。 本文會要求廣泛是精實系統公開檢視中表示為其確定行表示並提供它們的想法複合和摘要。
值
精實系統公開發行它的信號之後[18] 的 2012 Lean Software & Systems 工作階段[19]。 依據發行的一組值一年前。 這些值包括:
體貼人情事故
同意複雜性與不確定性對知識工作而言理所當然的。
朝更好的經濟結果努力
促進更好的社會行為結果
搜尋、接受和質疑各種專業領域中的概念
價值觀取向的社群會增進正向變革的速度與深度
.gif "Hh533841.collapse_all(zh-tw,VS.110).gif")
體貼人情事故
從事如軟體開發等知識工作的是人類。 人類的本質就非常複雜，而且使用邏輯思考，同時受理性無法克服的情緒和動物本性影響。 設計我們工作的系統或流程時，必須將我們的心理狀態和神經心理特性列入考量。 也必須順應我們的社交行為。 人類天生就是帶情感、好群居且有集體意識的，我們的行為會因為疲勞和壓力而變更。 成功的流程是那些能夠擁抱及包容人為條件的行為，而非那些試圖否定它以及像機器般的邏輯假設行為。
同意複雜性與不確定性對知識工作而言理所當然的。
客戶的行為和市場無法預期。 無法預期完成工作的流程及一組工作人員。 缺失和必要的重新作業是無法預期的。 軟體開發的許多層級有機會或看似隨機的行為。 專案的用途、目標及範圍傾向於要交付時就變更。 某些一開始未知的不確定性和可變屬性，透過學習與量化是可以被認知的，並且其風險是被控制住的；但是，有些可變屬性即便在未來也無法被探知而且無法完全預期。 因此，「精實軟體開發」系統必須能夠回應不斷演變的事件，而且能夠適應瞬息萬變的情況。 因此，任何「精實軟體開發」流程都必須存在於允許因應不斷演變之事件進行調整 (流程) 的架構中。
朝更好的經濟結果努力
人類活動 (例如「精實軟體開發」) 應該專注在產生較佳的經濟成果。 如果對企業的價值及客戶的利益有所貢獻，資本主義是可接受的。 企業投資者和業主理應獲得投資報酬。 員工和工作人員在執行工作時付出相當的努力，理應獲得公平的工資報酬。 客戶支付公平的價格，理應換得依照承諾提供效益的良好產品或服務。 更加經濟的結果需要以較低的成本為客戶提供更多的價值，同時以盡可能最有效的方式管理投資者或業主所部署的資本。
啟用較佳的社會行為結果
不應為了交付更加經濟的結果而犧牲執行工作的那些項目。 建立工作場所是一件非常重要的事，這個工作場所應該顧及人情事故來尊重個人，並提供重視人性心理及社會層面的工作制度。 建立可執行重要工作的良好環境是「精實軟體開發」社群的核心價值。
準則
Lean Software & Systems 社群似乎對鞏固 Lean Software Development 程序的某些準則表示同意。
遵循系統思考與設計方法
究竟結果可能會受「建構複雜調適系統的內容」影響。
尊重人員 (做為系統的一部分)
使用科學方法 (驅動改善)
勉勵領導人員
產生可視性 (於工作、工作流程和系統作業中)
減少流程時間
減少浪費以改善效率
遵循系統思考與設計方法
這在 Lean 文獻中通常稱為「最佳化整體」，表示這是想要最佳化之整個系統 (或處理序) 的輸出，而且我們不應錯誤地只最佳化其中的幾個部份而希望能神奇地最佳化整體。 大部分的從業人員都認為這個推論是正確的，也就是，對一部分進行最佳化 (局部最佳化) 將會產生次優的結果。
「精益系統考量與設計方法」(Lean Systems Thinking and Design Approach) 要求我們必須考慮外部專案關係人 (例如客戶) 對系統提出的需求以及這些專案關係人需要的理想結果。 我們必須研究需求的本質，並且比較需求和系統的交付能力。 需要包括所謂的「價值需要」(客戶願意付款來買的) 和「失敗需要」(這通常是重新作業或其他因為無法供應價值需要而引發的需要)。 未達成的需要通常有兩種形式：在先前交付的價值需要上重新作業，以及因為無法供應價值需要而提供額外的服務或支援。 在軟體開發中，未達成的需要通常是要求修正 Bug 和要求客戶服務或詢問台職責。
系統設計方法要求我們也應遵循「計劃-實施-研究-行動」(PDSA) 方法來進行設計和改善。 西 Edwards Deming 使用詞彙「學習」和「功能」暗示我們要研究系統行為的自然哲學。 這個系統包括我們的軟體開發程序和所有操作人員。 在功能或交付功能 (在 Agile 文獻中稱為「速度」) 的前置時間、品質、數量等方面將會值得注意的的行為。 這些度量將表示可變性，此外，透過研究變化的方法和散佈方式，我們可以更加了解功能。 如果這不符合需要和客戶期望，則必須重新設計系統以縮小這個差距。
Deming 也教導能力有 95% 受到系統設計影響，個人績效的比重只佔 5%。 換句話說，我們可以尊重人員，所透過的方式不是苛責人員能力不及要求的缺憾，而是重新設計系統使他們都能成功。
為了解系統設計，我們必須知道系統功能動力學的科學原理，以及如何影響該動力學。 模型是開發來預測此系統的動態。 雖然有許多可能的模型，但其中有數種較通用：了解經濟成本；亦稱為異動和協調成本 (與生產客戶重視的產品或服務相關)；條件約束理論 (了解瓶頸)；以及淵博知識理論 (可變性在系統設計中屬於一般情況或特殊/外部情況的研究與認知)。
究竟結果可能會受「建構複雜調適系統的內容」影響。
複雜系統具有起始條件以及會在重複執行時產生新生結果的簡單規則。 究竟結果很難或無法根據開始的條件來預測。 電腦科學實驗「即時遊戲」是複雜系統的範例。 複雜的調適型系統具有內在自動感知與內部反映方法，可用來考量目前的一組規則使其得以達到所要結果的成效。 這個複雜符合系統可能會選取符合自己–變更其簡單規則–縮小目前結果和預期結果之間的間距。 即時遊戲採用這種可以在執行期間重新撰寫的規則，會是一種複雜的適應性系統。
“simple rules” of complex adaptive systems are the policies that make up the process definition.在軟體開發流程中，複雜適應性系統的「簡單規則」是組成流程定義的原則。 這裡的核心原則是基於相信開發軟體產品和服務不是決定性活動，因此無法符合自己的已定義的程序不會是對不可預測事件的完整回應。 因此，設計做為我們系統考量和設計方法之一部分的流程必須可變通。 它會透過修改其組成原則來變通。
Lean Software Development 的 Kanban 方法利用此概念，將 kanban 提取系統的原則視為「簡單規則」、開始的條件即是工作且工作流程可以用視覺化方式來檢視、以瞭解系統動態的方式來管理流程，而該組織使用科學方法去了解、建議及實作流程改善。
尊重人員
Lean 社群採用知識工作的 Drucker Peter 的定義，它表示工作者若對自己執行的工作比自己的上司更知識淵博，就是知識工作者。 這樣會讓人以為最好讓工作者做出執行工作及如何修改流程才能改善工作執行方式的決策。 因此工作人員的心聲應該受到尊重。 工作者應有足夠的權限自我組織，以完成工作及達到想要的結果。 他們也應該有權建議及實作流程改善機會或 Lean 文獻中所指的「kaizen 事件」。 明確建立處理原則，讓工作人員知道約束他們的規則，是另一種尊重他們的方式。 清楚定義的規則會因為消除了恐懼和勇氣缺乏而激勵自我組織行為。 對人員授權並提供一組明確宣告的原則是尊重人員的表示，而這也符合體貼人情事故的核心價值。
使用科學方法
尋求使用模型了解完成工作的動態方式，以及「精實軟體開發」的運作情況。 觀測並研究此系統及其功能，然後開發並套用模型，對其行為進行預測。 收集您研究中的量化資料，並使用該資料來了解系統執行方式，以及預測這個方式在流程變更時可能變更的情況。
Lean Software & Systems 社群使用統計資料方法 ，例如引導時間與速度的原始資料做成的統計流程控制圖表和光譜分析長條圖，這樣可以了解系統的功能。 他們也使用下列模型：用於了解瓶頸的條件約束理論；用於了解系統設計變化與外部影響的淵博知識體系；以及透過執行只協調、安裝、交付或在建立客戶重視的產品或服務之後清理之工作這種形式而進行的經濟成本分析。 其他模型輸也開始被採用，例如實物期權理論，其旨在從金融風險管理到真實世界的決策制定中套用財務期權理論。
科學方法建議：我們學習；我們根據模型假設結果；我們根據預測干擾系統；然後我們再次觀察，瞭解干擾作業是否會產生模型所預測的結果。 如果不是，我們會檢查資料並重新考慮模型是否正確。 使用模型驅動流程改善，可以使其變成科學活動，並將其從以直覺為基礎的迷信活動提升。
勉勵領導人員
領導能力與經營能力是不相同的。 管理是設計流程、建立、修改和刪除原則、制定策略性和營運決策、收集資源、提供財務和設施以及傳達內容相關資訊 (例如原則、目標和想要的結果) 的活動。 領導能力指是的願景、策略、戰術、勇氣、創新、判斷、倡導等許多特質。 領導能力可以而且應該來自組織內的任何人。 工作成員的一些微小的領導動作將能建立起一連串的改進以達成精實軟體開發的流程。
產生可視性
知識工作是無形的。 如果您看不到處理作業，就 (幾乎) 無法進行管理。 直到工作完成以前，都必須透過個人、技能與部門的網狀脈絡，產生所承接工作及其流程作業的能見度。 尋找視覺化程序流程的方法，訂定明確處理原則讓所有人員查看並考量，以增加流程設計的能見度是有其必要的作法。 釐清所有事情後，即可使用科學方法，也才能客觀地合作進行有關潛在改良方法的對話。 如果工作和工作流程不可見，而且處理原則不明確，那麼共同作業流程改善幾乎是不可能的。
減少流程時間
研究軟體工程的軟體開發專業人員和學者向來專注於測量處理活動所需的時間。 Lean Software Development 社群已發現對測量某作業實際上花費的行事曆時間來說可能更有用。 這通常稱為循環時間，而且通常以所執行之活動的界限認定資格。 例如，「經過分析到準備開始部署的週期時間」會測量針對工作項目 (例如使用者劇本) 進行分析、設計、開發、多種方式測試以及佇列準備部署到生產環境的總耗用時間。
將焦點放在工作流經程序所需的時間在許多方面都很重要。 較長的週期時間已顯示與 Bug 率的非線性成長有相互關聯。 因此較短的週期時間可產生較高的品質。 這是不符合直覺的，因為看起來荒謬，但錯誤可能會在佇列時被插入到程式碼中，完全未經人工處理。 傳統上，學習這個的軟體工程專業人員和學者會忽略這段閒置時間。 不過，經驗證據顯示週期時間對初始品質很重要。
Alan Shalloway 也談到了「誘發性工作」(Induced Work) 的概念。他的觀察是執行工作的延遲可能會導致需要花費比依期完成工作還要大量的精力。 例如，找到 Bug 後立即修正可能只需要 20 分鐘來修正，但如果 Bug 已分級、佇列然後等候數天或數週才修正，就可能需要數個或許多小時進行修正。 因此，週期時間延遲已「誘發」額外的工作。 因為這個工作是可以避免的，以「精實」來說，必須將之視為「浪費」。
強調循環時間的第三個原因是與業務相關的原因。 每項功能、職務或使用者劇本都具有價值。 此值可能不確定，雖然有值。 值可能隨時間而變更。 經過一段時間後變更值的概念可節省如同市場付款功能的資源。 當工作項目的市場付款函式理解時，即使函式，可顯示值傳用模型的不確定性，評估延遲的「代價是可能的」。延遲的成本並減少可讓我們將值週期。
處理某些工作項目時，市場付款機制會在未來的已知日期才開始。 例如，設計要在美國 7 月 4 日假日期間使用的功能在該日期以前沒有任何價值。 在這樣的範例裡，縮短週期時間以及有能力可以在某些不確定性因素存在下預測週期時間仍是相當有幫助的。 最理想的是，我們會想要開始工作，好讓這項功能可以在需要時「及時」交付，而不要比預定日期提前太多，也不要延後，因為延遲交付會造成延遲的成本。 剛好及時交付可確保充分利用可用的資源。 較早交付就意味著我們可能已經在處理其他項目，而隱含地負擔延遲的機會成本。
由於這三個原因，「精實軟體開發」會尋求讓流程時間減至最短並記錄可用來預測流程時間的資料。 這個目標是讓 Bug 的失敗降至最低，延遲修復 Bug 而造成過度的浪費，以及盡量都避免造成延遲成本和延遲機會成本而獲取最大的利益。
減少浪費以改善效率
每個加值活動都會有設定、清除和交付活動，這些活動是必要的，但不會就其個別的名目加值。 例如，開發可行軟體增量模組的專案反覆項目需要規劃 (設定活動)、環境與可能在版本控制中的程式碼分支 (統稱組態管理，同樣也是設定活動)、發行計畫與執行實際發行 (交付活動)、向客戶展示 (交付活動)，以及可能的環境終止或重新設定 (清除活動)。以經濟學詞彙來說，設定、清除和交付活動是執行加值工作的異動成本。 這些成本 (或額外負荷) 在 Lean 中視為浪費。
任何形式的通訊額外負荷都可以視為浪費。 以經濟語言來說，判斷專案狀態以及為小組成員排程或指派工作將會視為協調成本。 所有的協調成本在「精益考量」中都是浪費。 「精實軟體開發」方法設法運用讓小組成員同處一室、近距離面對面會議 (例如晨會) 或視覺化控制 (例如卡片圍牆) 等方式，摒除或降低協調成本。
精實軟體開發中第三種常見的浪費形式是失敗需要。 未達成的需要是軟體開發系統的負擔。 未達成的需要通常是重新作業或是因為不良品質而產生為副作用的新形式工作。 軟體開發過程中，失敗的最常見形式有 Bug、生產缺失和因錯誤使用軟體而衍生出的客戶支援活動。 進行中的工作 (即失敗需求) 的百分比通常稱為載入失敗。 增值工作在失敗需要中所佔的百分比是系統效率的測量標準。
增值工作在全部工作中所佔的百分比，包含所有非增值的異動、協調成本及決定效率標準。 沒有任何異動及協調成本與失敗負載的系統視為 100% 有效率。
傳統上，西方管理科學都認定可以透過提高工作的批次大小提升效率。 通常，異動和協調成本是固定的，只會因批次大小增加而稍微提高。 因此，大批次工作會更有效率。 這個概念稱為「規模經濟」。coordination costs tend to rise non-linearly with batch size, while transaction costs can often exhibit a linear growth.不過，在知識工作問題中，協調成本很容易隨著批次大小以非線性方式上漲，而異動成本則通常呈現線性成長。 因此，傳統尋求效率的 20 世紀方法對於像軟體開發這樣的知識工作問題並不適用。
最好將焦點放在減少額外負荷，同時維持小批次以提高效率。 因此，「精實」方法要有效率就是要減少浪費。 「精實軟體開發」方法著重快速、低成本和迅即規劃的方法、降低的溝通額外負荷，以及有效的低額外負荷協調機制，例如看板系統中的視覺化控制。 他們也鼓勵自動化測試和自動化部署，以減少交付的異動成本。 用來讓環境設定及終止成本降至最低的現代工具 (例如，現代版本控制系統和使用虛擬化) 也有助於改善小批次軟體開發的效率。
實務作法
「精實軟體開發」不規定實務作法。 更重要的是，展示實際的流程定義與原則及價值的契合。 然而，有一些作法最常被採用。 本節提供其中一部分的簡短概觀。
累計流程圖
自 2005 年以來，累計流程圖已經是 Team Foundation Server 的報告標準組件。 累計流程圖會依工作流程的每個狀態，繪製累計工作項目的區域圖形。 資訊豐富，而且可用於衍生流程步驟之間的平均循環時間，以及輸送率 (或速度)。 不同的軟體開發生命週期流程會在累計流程圖上產生不同的視覺簽章。 從業人員可以學習辨識顯示在區域圖形上的流程中功能不良模式。 真正的精實流程將會顯示分佈均勻的色彩區域，以規律的間隔平穩上升。 該圖片會顯示平滑，而沒有任何色彩的鋸齒狀或可見區塊。
以最基本的形式來說，使用累計流程圖的目的是透過視覺化方式檢視工作項目生命週期中任何指定步驟上的進行中工作的數量。 這可用於偵測瓶頸及觀察「mura」的效果 (流程中的可變性)。
視覺控制項
除了使用累計流程圖之外，精實軟體開發小組會使用實體面板、電子投影視覺化系統，以視覺化方式檢視工作並觀察其執行流程。 這種方式可協助小組成員檢視未完成的工作累積並讓它們看見瓶頸和「木拉 (mura) 效果」。可見的控制項也可讓小組成員自我組織以挑選工作，並且能不需特意的規畫以及特定的管理方針或干預之下便能與他人一起合作。 這些視覺控制項通常稱為通常稱為「卡片牆」或 (不正確) 「kanban 面板」。
虛擬 Kanban 系統
看板體系 (Kanban system) 是精益製造 (Lean Manufacturing) 的推廣作法。 它會使用實體卡片系統來限制進行中工作在工作流程中任何指定階段上的數量。 這種未完成的工作限制系統建立「提取」新工作開始的位置，並且選擇性看板系統表示此時新工作可以「提取」傳入特定狀態，而且工作可以進展至這個。
在精實軟體開發中，看板 (Kanban) 是虛擬的，通常是藉由在工作項目類型的工作流程中設定特定步驟的數目上限來進行追蹤。 在有些實作中，電子系統會追蹤虛擬看板，並在可以開始新工作時提供通知信號。 訊號的形式可以是視覺化的，也可以是像電子郵件之類的警示。
虛擬 kanban 系統通常結合視覺控制項，以提供視覺化虛擬 kanban 系統，代表一個或數個工作項目型別的工作流程。 這類系統通常稱為「看板管理 (Kanban)」或「電子看板 (Kanban) 系統」。一個看的見的虛擬看板系統可從 Team Foundation Server 的外掛程式取得，其稱為 Visual WIP[20]。 這個專案是 Hakan Forss 在瑞典開發的開放原始碼。
小批次/單一流程
「精實軟體開發」要求小批次承辦工作 (通常稱為「反覆項目」或「增量模組」) 或獨立執行工作項目流程 (稱為「單件流程作業」)。單件流程作業需要縝密的組態管理策略，讓完成的工作可以交付，而不會意外發行未完成的工作。 這通常可在版本控制矽土中利用分支策略達成。 小批次工作通常視為可由 8 人小組負責或是在 2 週以內完成的的批次。
小批次和單一流程需要企業擁有人頻繁的補充待處理項目、佇列或工作。 他們也需要頻繁發行的功能。 為提高與商人之間的互動，以及提高交付頻率，必須減少兩種活動的異動和協調成本。 達成這個目的常用的方式就是使用 Automation。
Automation
「精實軟體開發」期許高階自動化，以啟動合乎經濟效益的單件流程作業、鼓勵高品質並降低失敗需要。 使用自動化測試、自動化部署和軟體工廠自動化設計模式的部署和重複性低變化原始程式碼區段的建立，會成為精實軟體開發的一般程序。
改善活動
在「精實」文獻中，「改善」(Kaizen) 一詞意味著「連續改進」，而「改善」活動是指進行流程或工具變更，希望能產生改善的措施。
「精實軟體開發」流程會利用許多不同活動來推行改善 (Kaizen) 活動。 這些列於此處。 這些活動都是設計來激發相關問題的交談，這些問題對功能會有負面影響進而減損交付需要項目的能力。 基本知識的 kaizen 本質是我們必須促使不同專案的小組成員能夠使用不同的技術來討論問題。
每日晨會
小組軟體開發人員，在像是白板視覺化顯示他們進行中的工作這類視覺控制系統中，通常可以滿足至多 50 項的工作。 他們討論流程動向和影響工作流程的因素。 重點特別鎖定在外部阻擋的工作和因為 Bug 而延遲的工作。 流程的問題通常會在經過一系列的每日晨會之後變得明顯。 結果是較小的群組可能會在會議結束後繼續討論問題，並且提出建議方案或流程變更。 接著將會進行改善活動 (Kaizen Event)。 這些自發性會議在舊文獻中通常稱為自發性品質圈。 這種自發性的會議正是「改善 (kaizen)」的核心文化。 管理人員在每日晨會之後鼓勵發起改善 (Kaizen) 活動，在其組織內推行精實 (Lean) 作法。
追溯性
專案小組可能排程定期會議來反映近期的績效。 在 Agile 軟體開發中，這些通常會在特定專案交付項目完成後或稱為反覆項目或衝刺 (Sprint) 的固定時間累加開發之後完成。
追溯性會議通常會使用逸事反思方法，透過詢問如「什麼工作進展順利？」、「我們不同情況下怎麼做？」和「我們應停止做什麼？」等問題來發人深省。
追溯性會議通常會產生對改善 (Kaizen) 活動的建議待處理項目。 小組還可以排定其中一些項目的實作優先順序。
作業檢閱
作業檢閱通常大於追溯性且包含整體價值流程的代表。 讓多達 12 個部門簡報客觀的量化資料，以說明他們受理的需要並反映其根據需要完成交付的能力，這是常有的事。 作業檢閱通常每月份舉行。 作業檢閱和追溯之間的主要差異是作業檢閱橫跨一組廣泛的功能，通常是跨專案和其他創始的組合，並使用客觀及量化資料。 相較之下，追溯性會議通常以單一專案為範圍，只有少數幾個小組 (例如分析、開發和測試) 參與，而且基本上談的都是一些有趣的故事。
作業檢閱會就影響小組之間效能的動態過程引發討論。 一個小組產生的失敗需要可能會由另一個小組來處理嗎？ 或許該失敗需要會引起混亂，造成第二個小組遺漏其承諾，而無法按照預期完成交付？ 作業檢閱提供討論這類問題及提議變更的機會。 作業檢閱通常會產生可能改善 (Kaizen) 活動的小型待處理項目，這可排定日後進行實作的優先權和排程。
沒有單一精實軟體開發流程。 如果一個流程與「精實軟體開發」的價值觀及原則一致，就稱這個流程是精實的。 「精實軟體開發」不規定任何實務作法，但有些活動已成通常慣例。 精實組織會設法透過工作流程和進行中工作的視覺化，以及了解流程的動態過程與影響因素 (例如，瓶頸、非立即可用性、易變性和浪費)，來激勵改善 (Kaizen)。 建議進行流程改善，理由通常非常充分，因為可以做為降低原始程式碼的可變性、摒除浪費、改進流程作業或改善價值交付或風險管理的方法。 因此，「精實軟體開發」流程會永遠不斷進展，而且特別針對其演化所在的組織量身訂製。 單純將某個組織的流程定義複製給另一個組織，而期待能在不同環境下行得通，並不正常。 這也不可能在數週或數月之後回到組織，卻發現使用中的流程與先前觀測到的一樣。 它永遠在進展。
使用精益 (Lean) 軟體開發流程的組織可以說是精益 (Lean) ，只用三種格式示範了小量的成本:“mura”、“muri” 及 “muda”，並顯示透過有效的風險管理將價值最佳化。 精益求精是不間斷的。 目的地沒有被指定。 真正的精實組織一定會尋求進一步改善。
「精實軟體開發」仍然是新興的領域，未來十年將持續進展，榮景可期。
Anderson, David J. 原著《看板：為您的科技企業展開成功的演進式變革》(英文)，Blue Hole Press，2010
Anderson, David J. 原著《軟體工程的敏捷式管理：套用條件約束的理想商務結果》(英文)，Prentice Hall PTR，2003
Womack, James P.、Daniel T. Jones 和 Daniel Roos 原著《改變世界的機器：精實生產的故事》(英文) 2007 更新版，Free Press，2007
Womack, James P. 和 Daniel T. Jones 原著《精實考量：企業摒除浪費、創造財富之道，第二版》(英文)，Free Press，2003
Beck, Kent 等，＜The Manifesto for Agile Software Development＞，2001，http://www.agilemanifesto.org/
Highsmith, James A. 原著《敏捷式軟體開發生態系統》(英文)，Addison Wesley，2002
Poppendieck, Mary 和 Tom Poppendieck 原著《精實軟體開發：敏捷式工具箱》(英文)，Addison Wesely，2003
Poppendieck, Mary 和 Tom Poppendieck 原著《實作精實軟體開發：從概念變現金》(英文)，Addison Wesley，2006
Poppendieck, Mary 和 Tom Poppendieck 原著《主導精實軟體開發：結果不是重點》(英文)，Addison Wesley，2009
Reinertsen, Donald G. 原著《管理設計工廠》(英文)，Free Press，1997
Reinertsen, Donald G. 原著《產品開發流程的原則：第二代精實產品開發》(英文)，Celeritas Publishing，2009
Sutton, James 和 Peter Middleton 原著《Lean Software Strategies: Proven Techniques for Managers and Developers》，Productivity Press，2005
Anderson, David J. 原著《軟體工程的敏捷式管理：套用條件約束的理想商務結果》(英文)，Prentice Hall PTR，2003
Shalloway, Alan、Guy Beaver 和 James R. Trott 原著《Lean-Agile Software Development: Achieving Enterprise Agility》，Addison Wesley，2009
Larman, Craig 和 Bas Vodde 原著《攀登精實與敏捷開發：考量及組織大型 Scrum 的工具》，Addison Wesley Professional，2008
《精實與敏捷開發規模縮放實務：大型、多地點及境外委外產品開發與大型 Scrum》(英文)，Addison Wesley Professional，2010
Coplien, James O. 和 Gertrud Bjornvig 原著《精實架構：探討敏捷式軟體開發》，Wiley，2010
http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/