關(guān)于軟件開發(fā)中應(yīng)用精益原則的討論铆帽，大部分集中在識別和消除浪費（浪費在日語中叫作：muda）。同樣，精益思考的目標是消除過重的負擔(dān)（過重的負擔(dān)在日語中叫作：muri）和不必要的變化（不必要的變化在日語中叫作：mura）氮采。Muda，muri和mura合稱為“Ｍ三兄弟”染苛。它們?nèi)齻€在一起就成了不諧調(diào)的組合鹊漠。只有消除了這“M三兄弟”，才能創(chuàng)造一個可持續(xù)的精益過程茶行。本文討論了這“三兄弟”的關(guān)系躯概，并認為對于軟件開發(fā)組織來說，要建立一個精益過程拢军，第一步要做的事情就是消除額外的負擔(dān)楞陷。
浪費
在精益思考（lean thinking）中，浪費被定義為：所有以客戶的角度看來不增加價值并且可以移除的活動茉唉。例如固蛾，生產(chǎn)過剩、過渡加工度陆、在制品艾凯，或者庫存、缺陷懂傀、任務(wù)易手和任務(wù)切換趾诗、等待，以及沒有用到的員工創(chuàng)造力蹬蚁。
從客戶的角度來看恃泪，能增加價值的活動才能讓產(chǎn)品品質(zhì)得到提高。判斷是否為增值活動的好辦法就是問自己這樣一個問題犀斋，“假如我是客戶贝乎，我愿意為這個活動付費嗎？”如果回答為“是”叽粹，那它就可能是個增值活動览效。例如，發(fā)現(xiàn)和理解客戶需求虫几，并寫出代碼锤灿。另外，正如后來Allen
C.
Ward所指出的那樣辆脸，使用原型法來學(xué)習(xí)相關(guān)知識以便開發(fā)軟件系統(tǒng)但校，這樣類似的活動也屬于增值活動。任何不創(chuàng)造價值而當(dāng)前又無法消除的活動被叫做“非增值”活動啡氢。例如配置管理和項目計劃活動状囱。
敏捷宣言中提到“可工作的軟件勝過全面的文檔”州刽，也就是強調(diào)整增值活動在軟件開發(fā)中的重要性。通過消除浪費浪箭，我們可以更快更好地創(chuàng)造軟件產(chǎn)品穗椅。
過重的負擔(dān)
那么首先將關(guān)注點放在發(fā)現(xiàn)和消除浪費上面，有什么不對的呢奶栖？即使大部分傳統(tǒng)開發(fā)組織從事的都是沒有增加什么價值的活動匹表，都是浪費；但是要想以精益的方式工作宣鄙，正確的方法不是先對付浪費袍镀，而是要首先應(yīng)對另外一個痼疾：過重的負擔(dān)。只要大家瘋狂加班冻晤，只要項目和團隊有被大量工作壓垮的可能苇羡，那么僅僅消除浪費就沒有什么效果了。除非我們將工作量限定在組織能力所及范圍之內(nèi)鼻弧，否則浪費就可能會悄悄返回设江。假設(shè)你正試著消滅缺陷，可項目卻還是在重負之下攘轩，那么質(zhì)量問題還是會重現(xiàn)叉存，因為項目成員仍會感到壓力過大以及過度操勞。事實上度帮，過重的負擔(dān)是在制品歼捏、等待和推遲、任務(wù)切換和缺陷等浪費的主要來源笨篷。
將需求限制在工作能力范圍之內(nèi)瞳秽，正是Scrum和極限編程要做的事。讓團隊自己為一個迭代指定可行的工作量率翅，過重的負擔(dān)就會被制止练俐，從而并有系統(tǒng)地避免它的發(fā)生。這樣就達到了一個穩(wěn)定的步伐安聘。另外痰洒，Scrum和XP建立了“拉”式過程和穩(wěn)定的節(jié)奏瓢棒，團隊成員實際上就是從產(chǎn)品backlog上以“拉”的方式來獲取需求浴韭，并以一種有規(guī)律的基準來將這些需求轉(zhuǎn)化為產(chǎn)品的增量。
這種“拉”式過程的優(yōu)點之一就是：除了避免負擔(dān)過重脯宿，它還會使浪費和其它問題暴露出來念颈。隨著過多庫存的消失，問題就會很快暴露出來连霉。Scrum意識到了識別和消除問題和障礙的重要性榴芳。它的每日Scrum會議就是識別問題的一種機制嗡靡。
多變性
具有穩(wěn)定節(jié)奏的“拉”式過程使得不必要的變數(shù)可視化，例如在迭代計劃會議上窟感，團隊發(fā)現(xiàn)需求的大小和粒度不同讨彼，或者使用了多種不同的構(gòu)建腳本。不必要變數(shù)的其它例子還包括：使用不同的開發(fā)工具柿祈，應(yīng)用開發(fā)實踐（如測試先行及重構(gòu)）時的不一致性哈误，以及不遵守編碼標準等等。這類變數(shù)產(chǎn)生了諸如有缺陷的軟件躏嚎、過度加工以及返工等浪費蜜自。而規(guī)范和標準則消除了這些變數(shù)。
但是卢佣，并不是所有的變數(shù)在軟件開發(fā)中都是壞事重荠！例如，產(chǎn)品backlog中以不同的詳細程度來表述需求虚茶，可以避免生產(chǎn)過剩戈鲁，
過度加工和返工。通過創(chuàng)建原型來探索不同的技術(shù)和設(shè)計選擇是一種必要的變化形式嘹叫，這樣可以獲得相關(guān)的知識荞彼，以便做出正確的架構(gòu)和技術(shù)決策。需要注意的是：要盡早進行有計劃的組織試驗待笑，而不要孤注一擲于可能未加證實的設(shè)計理念鸣皂，后者往往會導(dǎo)致后來重寫軟件。
總結(jié)
為了建立一個精益過程暮蹂，必須從根本上改變傳統(tǒng)的開發(fā)體系寞缝，從而建立一個正確的過程。對于軟件開發(fā)組織來說仰泻，最好通過使用有節(jié)奏的“拉”式過程荆陆，以創(chuàng)建和Scrum和XP同樣的過程。在日語中集侯，這種根本上的改進叫做“改革（kaikaku）”被啼。一旦建立了這種新的工作方法，浪費和變數(shù)肯定會被系統(tǒng)化地清除棠枉。因此浓体，這種過程要逐步不斷改進，在日語中就是所謂的“改進（kaizen）”辈讶。有規(guī)律的回顧會議會有益于反思和持續(xù)改進命浴。總而言之，要建立正確過程首先就要減負生闲，然后授權(quán)并鼓勵團隊義無反顧地消除浪費和不必要的變數(shù)媳溺。
Literature
Jeffrey K Liker:The Toyota Way. McGraw-Hill. 2003.
James M. Morgan, Jeffrey K. Liker:The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press. 2006.
Mary and Tom Poppendieck:Implementing Lean Software Development: From Concept to Cash. Addison-Wesley. 2006.
Donald G. Reinertsen:Managing the Design Factory. A Product Developer's Toolkit. Free Press. 1997.
Allen C. Ward:Lean Product and Process Development. Lean Enterprise Institute. 2007.
James P. Womack, Daniel T. Jones:Lean Thinking. Touchstone Books. 1996.
作者簡介
Roman Pichler,是一名獨立咨詢師及教練。Roman的客戶認為他具備豐富且不同的經(jīng)驗碍讯，能夠幫助剛起步的創(chuàng)業(yè)公司悬蔽，乃至很大的全球性企業(yè)實施精益思考和Scrum。他還是《Scrum - Agiles Projektmanagement richtig einsetzen(dpunkt 2007)》一書的作者捉兴。
查看英文原文:The Three M's - The Lean Triad
