https://wiki.taigi.ima.org.tw/w/index.php?action=history&feed=atom&title=%E7%B2%BE%E5%AF%A6%E8%BB%9F%E9%AB%94%E9%96%8B%E7%99%BC
精實軟體開發 - 修訂紀錄
2026-05-19T03:46:46Z
本 wiki 上此頁面的修訂紀錄
MediaWiki 1.43.1
https://wiki.taigi.ima.org.tw/w/index.php?title=%E7%B2%BE%E5%AF%A6%E8%BB%9F%E9%AB%94%E9%96%8B%E7%99%BC&diff=400702&oldid=prev
TaiwanTonguesApiRobot：從 JSON 檔案批量匯入
2025-08-22T10:09:59Z
<p>從 JSON 檔案批量匯入</p>
<p><b>新頁面</b></p><div>'''精實軟體開發'''是精實製造原則佮實踐佇咧軟體開發領域的變體。伊是對豐田生產的方式（TPS）， 由敏捷社區引入並且發展。<br />
<br />
==起源==<br />
<br />
'''精實軟體開發'''一詞源於 Mary Poppendieck 和 Tom Poppendieck 的仝名冊。這本冊將傳統的精實原則重新闡釋，提供了二十二種開發實踐「工具」，閣佮敏捷開發的實踐做較。<br />
通過 Poppendieck 翁仔某佇扭掠軟體開發社區中的努力，包括佇敏捷開發會議頂頭幾擺演講，誠實軟體開發已經予敏捷開發社區廣泛接受。<br />
<br />
==精實原則==<br />
<br />
佮精實製造原則的概念相倚，精實開發原仔會當總結親像落七條原則：<br />
<br />
* 消除拍損<br />
* 增強學習<br />
* 盡量延遲決定<br />
* 緊咧發布<br />
* 放權力<br />
* 1875入品質<br />
* 全局優化<br />
<br />
===消除拍損===<br />
<br />
消除拍損（抑是講叫做 muda（日本語：無影）， 是豐田管理詞典中的一種特殊的浪費）原則，上早是由大野耐一（豐田生產方式之父）的理念所採用的。伊將這馬若共行為看做浪費：<br />
<br />
* 儉存的等等被使用的汽車零配件<br />
* 生產任何毋是講隨就需要的產品<br />
* 無必要的配件徙振動<br />
* 等待其他的配件予人生產<br />
* 製造過程當中加的處理步數<br />
* 缺陷（品質差）<br />
<br />
嘛會使講，按照精實思維，任何袂使替客戶增加價值的行為就是浪費。包括講：<br />
<br />
* 無必要的功能佮代碼<br />
* 軟體開發過程的延遲<br />
* 不明確的需求<br />
* 沓沓滴滴<br />
* 低效的內部溝通為著消除浪費，首先著愛會識別、熟似著拍損。若是某一項活動會當予跳過抑是取消嘛會當達成最後的結果，伊就是浪費。佇開發過程中作成但最終予廢棄的代碼是浪費；客戶毋經常使用的額外的處理佮特性是浪費；予人員佇咧濟任務間切換是浪費；等待其他任務是浪費；缺陷佮低品質是浪費；無產生實際價值的、過度的管理嘛是浪費。<br />
<br />
價值流方法會當用來識別浪費。指出浪費的根源閣消滅伊。消除浪費的活動應該迵天代進行，終其尾甚至會當消除一寡看起來若像必要的流程。<br />
<br />
===增強學習===<br />
<br />
面對開發團隊以及最終的產品大細額外挑戰，會當講軟體開發是一个繼續學習的過程。最佳的改善軟體開發環境的做法就是增強學習。佇咧代碼完成了後馬上進行測試會當避免缺陷的累積。毋是去做閣較濟的文檔抑是詳細設計，是對各種各樣的想法進行實際的編碼試看覓。用戶需求的收集過程會當簡單來通過予最終客戶演示講，而且聽這个𪜶的反饋來共完成。<br />
<br />
使用短周期的迵天代（每一个迵天代攏應包括重構佮集做測試）伊會當加速學習過程。咧決定當前階段的開發內容並對未來改善的努力方向進行調整時，佇客戶捀鬥相共之下通過簡短的反饋會議來增強反饋。通過遮的簡短的反饋會議，客戶代表佮開發團隊會閣較濟的發現佇進一步開發的時陣會拄著的主要問題佮可能的解決方案。對而且，因為已經開發出的原型，客戶會使閣較好理解家己的需求，開發者嘛會當了解著講按怎才會當閣較好地滿足客戶的需求。另外一个關於佮客戶溝通、學習的想法是「因為組的開發」，這種方法較焦未來解決方案的約束限定毋是各種可能的解決方案，就按呢通過和客戶對話變加速了解決方案的產生。<br />
<br />
===盡量延遲決定===<br />
<br />
因為軟體開發通常具有一定的無確定性，是因為加種選擇的方法會當達成閣較好的結果，雖然會當延遲決定，一直到會當代誌真正毋是無確定的假定佮預測來做出決定。系統愈複雜，按呢這个系統容納變化的能力就應該愈強，使其會使具備推遲重要閣有關鍵的決定的能力。<br />
<br />
===緊咧發布===<br />
<br />
佇一个技術發展足猛醒的時代，冗早的發布產品對千閣較緊的得著用戶的反饋來改善當前產品的品質，迵過閣較緊的完成後一擺迵天。若是每一擺快速的發佈攏會當滿足用戶的需求，這个產品就會當看做是成功的。每一擺迵天代的時間愈短，團隊內底的學習佮交流就會變閣較好。有矣速度，決策會去予人延遲。有矣速度，就會當閣較好的滿足客戶當前是毋是昨昏的需求。<br />
<br />
===放權力===<br />
<br />
傳統的團隊內面攏是由團隊的領導者來決定佮分配逐个人所欲完成的任務。但是精實開發主張將這款權利下囥到團隊的每一个跤手內，自按呢開發人員有權利來闡述家己觀點並提出建議。<br />
<br />
===1875入品質===<br />
<br />
品質的管理佇精實軟體開發內底尤其重要。佇遮，品質的保證一開始便予貫穿佇開發過程中的每一个階段，毋但是咧測試階段來發現品質問題。<br />
<br />
===全局優化===<br />
<br />
全局優化予每一个部門之間的聯絡閣較緊密。相對每一个部門內底的成本，消除部門之間的隔嚇佮浪費會產生閣較顯明的效果。佇咧 DevOps 成做一大趨勢的今仔日，開發部門，品質管理部門佮運行維護部門之間的協同變甲那來那重要。<br />
<br />
==參看==<br />
<br />
* Scrum ( development )<br />
<br />
==外部連結==<br />
<br />
* Interview with Mary Poppendieck<br />
* Mary Poppendieck , Tom Poppendieck _ Lean Software Development : An Agile Toolkit for Software Development Managers _<br />
* Lean-Agile Straight Talk A podcast hosted by author Jim Trott and featuring author Alan Shalloway about Lean Software Development and Agile Software Development .<br />
* Lean Software Institute<br />
* Improving Agile through Lean , or The Essence of Lean Software Development Insights into Lean Software Development from projects , and implementation notes around extending Agile through Lean .<br />
* InfoQ . com / Agile ( includes Lean )-Tracking change and innovation in the enterprise software development community ( News , Articles , Books , Video )<br />
* Lean-Agile-Scrum-a discussion group for those interested in how Lean , Agility , and Scrum work together<br />
* Lean Programming-a discussion group for those interested in programming in Lean Software Development environments<br />
* Training in Lean Software Development Net Objectives training in Lean Software Development<br />
* http : / / www . unigate . dk / Unigate develop software by using the principples in Lean . We have written a book about it . " Lean in software development´ "<br />
<br />
[[分類: 待校正]]</div>
TaiwanTonguesApiRobot