精益軟體開發七條原則
前段時間看完了《
lean thinking
》這本書，學到很多東西，也有很多感觸。這兩天又在網上看到乙個老外根據自己的理解詮釋七條原則，但他的解釋中有不少曲解之處，所以產生了寫本文的動力，也來按照自己的理解闡述下這七條原則，感興趣的朋友最好去看原著。
任何不增加價值的工作都是浪費；
沒有人會去看的文件是浪費，不符合客戶使用場景的需求是浪費，開發出來的特性不是使用者最急需的是浪費，工作轉交是浪費；所有的
bug都是浪費；任何多餘的東西和步驟，都是浪費；
盡量減低複雜性，減少重複勞動；僅做必要的工作；
軟體開發的過程是個不斷
發現，不斷
學習的過程，
這個過程中會不斷湧現出很多新的知識和新的資訊，充分利用這些資訊將幫助團隊把軟體做得更好
；通過盡快開始嘗試，快速失敗，獲取資訊並調整這種做法，能有效增強我們對未知事物的學習；
不要過早框定自己，保持靈活性，以便獲取新知時可以及時調整；
延遲決策意味著在獲得足夠的資訊之前，不要草率下決定，或者在你不得不決策的時候
(影響商務目標時
)才下決定；就是說讓你的決策盡可能依賴於充分的資訊，而不是依賴於對這些資訊的假設；
如果提前做出決定，意味著你必須做出各種假設，這將造成對應的風險；譬如在需求不清晰的時候給出專案的時間估計，在沒有充分調研的情況下決定採用某種技術；
與延遲決策配套的是快速響應的能力，如果做不到快速響應決策，那麼決策是無法延遲的；這也意味著系統的架構設計要能容納變化，高內聚，低耦合；
快速交付能夠使客戶更早地看到產品，能使產品更快地投入市場，更早地**產品價值；
快速交付縮短了終端使用者對產品的反饋迴圈，避免創造出客戶不需要的內容而造成的浪費；
快速交付還可以暴漏你在價值交付流程中存在的問題，促使這些問題得到解決；
工作在一線的人最了解實際情況，他們知道現在發生了什麼，知道當前情況下的最佳應對方法；
要讓他們熟知每天使用的工具、流程、規則以及背後的原因，完全具備足夠的知識提出改進意見；
獲得授權的團隊會產生更強的動力和更好的創造力；
完整性是為了讓客戶對產品的體驗具備平滑性、一致性，完整性是在整個開發過程中產生的；
為了保證完整性，關鍵是建立客戶到開發人員之間通暢的資訊流；
通暢的資訊流有助於各類參與人員做出的各類決定之間具有協調一致性，也幫助發現和解決對完整性的背離；
整體的表現，通常不是受制於某乙個區域性的表現，而是受制於各區域性之間的協調配合；
區域性的優化，有時候會惡化整體的協調一致，若區域性優化不能帶來整體的改善，將是沒有價值的；
拿合作的雙方來說，彼此之間也有乙個大的全域性，那構成他們的共同目標；這種情況下優化區域性通常都不能導致好的結果；
精益軟體開發七條原則
精益軟體開發七條原則 工作在一線的人最了解實際情況，他們知道現在發生了什麼，知道當前情況下的最佳應對方法 他們熟知每天使用的工具 流程 規則，因而完全具備足夠的知識提出改進意見 要充分尊重一線人員的意見 任何不增加價值的工作都是浪費 沒有人會去看的文件是浪費，不符合客戶使用場景的需求是浪費，開發出來...
精益軟體開發的思想 精益軟體開發原理快速指南
精益軟體開發的思想 我記得在早期的中學商業課上就曾在豐田公司學習精益生產，並且對通過有意設計來最大限度地減少浪費和提高生產率的想法深深著迷。隨著時間的流逝，精益方法被製造業以外的多個行業所採用，包括軟體開發。精益軟體開發將一些核心原則付諸實踐以優化生產力。軟體開發具有幾個關鍵功能，這使其成為應用精益...
ScruM與精益（Lean） 軟體開發及應用
scrum在眾多的敏捷方法中更多地提供的是乙個框架，而精益 lean 開發則更多地提供了一種思想。二者能很好的結合並相得益彰。傳統的軟體工程模型與建築過程極其相似，尤其是瀑布模型。但是，scrum 和精益卻源於製造工業。當他們被引入軟體工業的時候，實際上卻繼承並擴充套件了傳統的軟體工程模型和方法。學...