scrum 和精益（ lean ）軟體開發
傳統的軟體工程模型與建築過程極其相似，尤其是瀑布模型。但是， scrum 和精益卻源於製造工業。當他們被引入軟體工業的時候，實際上卻繼承並擴充套件了傳統的軟體工程模型和方法。
學過軟體工程的人都知道瀑布模型。對於那些在初期需求就很完整清晰，並且在開發過程中不會有太多變化的專案，瀑布式開發非常適用。軟體業發展的初期，在一些專案中人們用瀑布模型取得了一定的成功。但是隨著軟體工業的發展和企業運作速度的加快，在很多情況下，軟體開發的需求在開發過程中始終在不斷的變化。而瀑布式開發顯然不能適應這種變化。因此在越來越的專案中，瀑布式開發以失敗告終。隨後，許多有所改進的開發模式紛紛湧現，比如螺旋模型和統一過程開發（ rup ）模型。螺旋式結合了瀑布式和原型開發模式，這種模型能在一定程度上管理和控制那些在需求和設計階段不可預見的需求變化。統一過程開發（ rup ）模式則更進一步地採用乙個或多個迭代週期。乙個迭代週期包括四個階段：初始階段（ inception ）， 細化階段（ elaboration ），構造階段（construction ），交付階段（ transition ），而在不同的迭代週期則分別側重不同的階段。比如：第乙個週期可能側重初始階段同時也包含很小一部分的細化階段和構造階段用以建立原型。下乙個迭代週期則會側重於細化階段同時也有一定比重的其他階段，依此類推。原形開發和迭代週期的引進使需求的變化在原形或乙個週期後被引入系統加以實現。不過在當代的科技界，越來越多的軟體產品被移植到網際網路上變成一種服務，以更有效、快速、容易地部署產品服務使用者，並獲得使用者的反饋資訊。這種變化大大增加了使用者引導的需求變化頻率。顯然， rup 模式面對這種情況顯得力不從心，並且 rup 模式還存在其他許多不盡人意的地方。 scrum 採用時間更短的迭代週期，這種迭代週期被稱為 sprint ，乙個 sprint 通常為 2-4 周的時間。每個 sprint 只開發價值最高的被稱為 product backlogs 的產品需求，並且每個sprint 週期可能包含全部的開發階段如需求分析，設計，編寫**，測試，整合以及產品部署。每個短暫的 sprint 週期過後，都能產生乙個可以被整合、審查、展示並且最重要的是可以被使用者使用的軟體。許多當前的需求變化都可以被提出並且在下乙個 sprint 週期得以實現。這樣就產生了乙個快速的反饋迴圈，它可以動態管理實現使用者頻繁的需求變化。與此同時， scrum 這一模式也涉及諸如團隊、流程、溝通等其它方面的元素，這些元素共同發展規範了整個 scrum 框架結構。
類似於其它的敏捷方法， scrum 專注於管理需求變化和團隊潛能的發揮，同時也含其它一些具體的規程。精益（ lean ） 則 更多的教人一種思維模式，幫助形成具有精益思維和習慣的開發團隊。將 scrum 與精益結合可以使他們互相補充，取長補短。我們在許多專案中嘗試實現了這種結合。比如，在我們的敏捷協作平台 gscrum 上，通過使用一種稱為 wip 容器的特殊週期，能夠將 scrum 與 lean 有效結合起來。
使用 scrum 和精益（ lean ）開發的常見問題及解決方法
scrum 或精益開發模式以及其它的敏捷方法對比於傳統的軟體工程或專案管理理論與實踐有乙個共同的優點：簡單。不過，雖然 scrum 和精益開發的精髓很簡單，在實際運用過程中卻不近然。
首先，人們普遍傾向於抵制變化，固守成規總是更容易一些。變化對許多人來說難以接受的，特別是那些不能立即為所有人都帶來好處的變化。對於初次使用敏捷開發的團隊，都需要乙個從接受到真正應用的過程。一些敏捷開發實踐如測試驅動開發（ as test driven development ）、結對程式設計（ pair programming ）以及每天的 scrum 會議都需要一段時間讓開發團隊逐漸適應。如果沒有公司上層領導的強力支援，敏捷模式很可能以失敗告終，開發人員只能放棄敏捷開發，重新回到原有的開發模式上。因此，公司領導的強力支援和對團隊的培訓，是讓敏捷模式在乙個公司生存和持續發展下去的重要因素。
對於使用 scrum 的團隊，在實踐過程中也存在許多技術性的問題。不同的開發團隊，不同的開發人員會有不同的感受。
在 scrum 實踐中， scrum 專家（ scrum master）是乙個很重要的角色。這個名詞最初由 scrum alliance 提出。該角色從字面上很容易被理解為乙個在 scrum 開發團隊中擁有極高權力，同時管理所有成員的人。實際上，這個角色並未被賦予真正的職權，但他必須擁有很強的軟力量及社交技巧。從我們自己的實踐經驗看， scrum 專家必須能理解團隊中的每個成員，並且能夠將所有人團結起來。同時， scrum 專家還必須在團隊方向與開發人員感受之間取得平衡。一些研究表明， scrum 專家通常很容易失衡，要麼過度關注scrum 過程和專案進度，要麼過分照顧開發人員。一方面，對scrum 過程和專案進度要求太苛刻，不顧開發團隊及成員的想法很容易勢得其反，增加開發團隊對 scrum 的反感情緒。另一方面，如果scrum 專家太有同情心，過度照顧開發人員的感受並且失去對團隊整體方向的把握，那麼任何乙個團隊成員的問題都會影響整個團隊進度和執行過程。有這樣的 scrum 專家，這個團隊可能讓人感覺很舒適。但是顯然，這樣的團隊很難取得任何成功，最終有可能放棄 scrum 模式回到舊的開發模式上，或者出現其它更糟糕的結果。
scrum 提倡讓客戶全程參與到開發過程中。這就要求客戶和產品擁有者有乙個清晰的產品發展方向和足夠的時間投入。產品擁有者負責任的參與能有效的提高 scrum 專案的成功率。產品擁有者需要平衡專案利益悠關者之間的利益，從而能夠管理產品需求（ product backlogs ）、調整需求的優先順序、 完善需求描述，讓開發團隊有乙個清晰的方向，為客戶獲得最大的投資回報率（ roi ）。而在許多專案中，人們通常會覺得客戶或其管理層太忙，無法參與。開發團隊應該讓客戶明白，如果客戶不投入時間和精力關注產品需求，那不可能取得產品的成功。在某些情況下，由全體或部分專案利益悠關者組成的小組或委員會是必須的。但是，專案擁有者仍然應該是客戶與開發團隊之間實現交流的唯一結合點，這樣能避免開發團隊受到客戶的無序干擾。
敏捷開發團隊要面臨的另一大挑戰是如何能夠不斷改進開發過程。在第一年，敏捷開發對於整個開發團隊來說可能還是比較新鮮的。但是開發團隊很快就會對敏捷方式，特別是每天的 scrum 會議感到乏味。一旦感到乏味並開始鬆懈，開發團隊要麼會放棄敏捷模式回到原有的開發模式上，要麼會停留在對敏捷開發的膚淺應用層次上。這樣一來，團隊的積極性和創造性會受到打擊，停滯不前。這重情況下，結合精益（ lean ）開發方法能有效的解決這些問題。精益（ lean）模式提倡持續不斷地改進, 減少流程中的浪費。這個概念應該被注入到整個團隊中，讓團隊形成精益的思維和長期的習慣。在使用 scrum 開發專案的過程中，我們會經常應用一些精益的方法。例如，我們發現有些 sprint 計畫過程很可能變成一種浪費，特別是對那些沒有連續開發任務的專案。在這種情況下，我們使用gscrum 的 wip 容器和拉式系統來管理我們的開發。實踐證明，這樣非常有效，減少了不必要的會議和浪費。我們也嘗試使用 gscrum 提供的事件時間表來生成價值流圖（value stream maps ），試圖找出在開發過程中可能出現的浪費。 例如， gscrum 可以顯示每個開發人員的事件時間表。有一次我們發現某個開發人員比其他開發者花費更長的時間來修改一些問題，並且多次被測試人員退回要求重新修改，這促使我們意識到系統有些部分沒有單元測試案例。
運用精益（ lean ）開發模式相對比較抽象，有時候會比其他敏捷方法更困難一些。很少一部分成熟的工具和過程能應用於軟體開發領域。製造業中使用的精益（ lean ）工具一般無法直接被用於軟體開發行業。最佳的應用精益軟體開發的途徑是從簡單入手，理解其思想，然後針對團隊情況摸索創新，讓整個團隊習慣精益的思維模式和行為。當然，請有相關經驗的專家指導、交流會事半功倍。
ScruM與精益（Lean） 軟體開發及應用
scrum在眾多的敏捷方法中更多地提供的是乙個框架，而精益 lean 開發則更多地提供了一種思想。二者能很好的結合並相得益彰。傳統的軟體工程模型與建築過程極其相似，尤其是瀑布模型。但是，scrum 和精益卻源於製造工業。當他們被引入軟體工業的時候，實際上卻繼承並擴充套件了傳統的軟體工程模型和方法。學...
敏捷（Agile）與精益（Lean）對比
消除浪費 eliminate waste 嵌入質量 build quality in 創造知識 create knowledage 延遲決策 defer commitment 快速交付 deliver fast 尊重他人 respect people 整體優化 optimize whole 目標都是...
從精益軟體到精益思想
說起精益軟體開發，這絕對算是乙個老生常談的話題了。所以在這裡，我不想去談論諸如 精益軟體開發的幾大原則 或是 精益軟體開發的最佳實踐 等陳詞濫調 只是最近在同事的推薦下，拜讀了一本有關it運維方面的書籍 鳳凰專案 書中的故事十分有趣，同時又引人深思，細細品味後頗有感悟，對工作和生活上有了許多新的想法...