ScruM 與精益（ Lean ） 軟件開發及應用
Scrum 在衆多的敏捷方法中更多地提供的是一個框架，而精益（ Lean ）開發則更多地提供了一種思想。二者能很好的結合並相得益彰。
Scrum 和精益（ Lean ）軟件開發
傳統的軟件工程模型與建築過程極其相似，尤其是瀑布模型。但是， Scrum 和精益卻源於製造工業。當他們被引入軟件工業的時候，實際上卻繼承並擴展了傳統的軟件工程模型和方法。
學過軟件工程的人都知道瀑布模型。對於那些在初期需求就很完整清晰，並且在開發過程中不會有太多變化的項目，瀑布式開發非常適用。軟件業發展的初期，在一些項目中人們用瀑布模型取得了一定的成功。但是隨着軟件工業的發展和企業運作速度的加快，在很多情況下，軟件開發的需求在開發過程中始終在不斷的變化。而瀑布式開發顯然不能適應這種變化。因此在越來越的項目中，瀑布式開發以失敗告終。隨後，許多有所改進的開發模式紛紛湧現，比如螺旋模型和統一過程開發（ RUP ）模型。螺旋式結合了瀑布式和原型開發模式，這種模型能在一定程度上管理和控制那些在需求和設計階段不可預見的需求變化。統一過程開發（ RUP ）模式則更進一步地採用一個或多個迭代週期。一個迭代週期包括四個階段：初始階段（ inception ）， 細化階段（ elaboration ），構造階段（ construction ），交付階段（ transition ），而在不同的迭代週期則分別側重不同的階段。比如：第一個週期可能側重初始階段同時也包含很小一部分的細化階段和構造階段用以創建原型。下一個迭代週期則會側重於細化階段同時也有一定比重的其他階段，依此類推。原形開發和迭代週期的引進使需求的變化在原形或一個週期後被引入系統加以實現。不過在當代的科技界，越來越多的軟件產品被移植到互聯網上變成一種服務，以更有效、快速、容易地部署產品服務用戶，並獲得用戶的反饋信息。這種變化大大增加了用戶引導的需求變化頻率。顯然， RUP 模式面對這種情況顯得力不從心，並且 RUP 模式還存在其他許多不盡人意的地方。 Scrum 採用時間更短的迭代週期，這種迭代週期被稱爲 Sprint ，一個 Sprint 通常爲 2-4 周的時間。每個 Sprint 只開發價值最高的被稱爲 product backlogs 的產品需求，並且每個 Sprint 週期可能包含全部的開發階段如需求分析，設計，編寫代碼，測試，整合以及產品部署。每個短暫的 Sprint 週期過後，都能產生一個可以被整合、審查、展示並且最重要的是可以被用戶使用的軟件。許多當前的需求變化都可以被提出並且在下一個 sprint 週期得以實現。這樣就產生了一個快速的反饋循環，它可以動態管理實現用戶頻繁的需求變化。與此同時， Scrum 這一模式也涉及諸如團隊、流程、溝通等其它方面的元素，這些元素共同發展規範了整個 Scrum 框架結構。
精益（ Lean ）軟件開發模式從一開始便側重於提高過程中的效率。它最初來自豐田公司的製造工業，其主要思想是分析所有的流程，以查明和消除浪費，不斷提高效率。爲了達到這個目的，精益（ Lean ）模式提出了一些概念和實用的工具。大部分的工具都是在製造業使用而不能直接應用於軟件開發。但是精益軟件開發會經常提及其中的兩個概念。一個是拉式系統（ pull system ）。在拉式系統中，一個流水線上的任何一個環節的任務完成後 , 都會從前一個環節自動提取下一個任務。該模式以客戶的需求而不是市場預測來推動工作進程。另一方面，通過精益模式可以最小化未完成工作以及半成品的數量。它們通常被認爲是開發過程中的浪費。除了拉式系統（ pull system ），價值流圖（ value stream mapping ）也經常被應用於軟件開發過程中。價值流圖能夠有效的幫助識別過程中的浪費。
類似於其它的敏捷方法， 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 和 精益開發及應用的一些探討。有些方面也許會不太成熟，我們非常歡迎感興趣的業界同仁一起來討論。