企業在商業方面取得成功的要素是產品（Product），人才（People和流程（Process

中培可以通過敏捷咨詢，從產品，人才和流程層面幫助客戶改變。

1.產品提高

敏捷可以幫助客戶：

響應變化的需求

縮短首次上線周期，縮短反饋周期

提高產品質量

降低已有系統維護成本，降低需求變更成本

我們通過如下實踐來達到：

迭代式開發?

相比瀑布式過程，更好的方式是迭代式開發，它將整個軟件的開發過程分成了若干階段，客戶根據優先級或者風險高低選擇需求進行增量的設計和開發。每次迭代完成時都會生成一個經過測試的最終產品，開發團隊可以通過它獲得更多的反饋，繼續完善軟件產品。

迭代式開發的好處是：??

快速交付投入使用，快速獲得投資回報?

快速得到反饋，快速調整?

把項目分成較小周期，更容易管理?

更直觀看到項目的進展，風險更小?

迭代幫助客戶及早地創造價值，開發團隊可以通過它得到反饋，?不斷地修正各種錯誤。分析人員可以得到更進一步的需求。　

持續集成?

要得到迭代產物，產品的開發人員必須將產品代碼不斷與現有系統進行集成。　這意味著團隊

需要通過使用版本控制工具有效的管理代碼，并做到頻繁提交。　

持續集成的好處是：?

自動從版本控制庫取出最新的源程序?

運行自動構建腳本，從頭進行構建和部署?

針對構建出來的軟件運行全部測試?

自動發布集成結果?

測試驅動開發?

測試驅動開發基本思路就是通過測試來推動整個開發的進行。而測試驅動開發技術并不只是單純的測試工作。　

測試驅動開發的好處是：?

正確的描述了需求。需求向來就是軟件開發過程中感覺最不好明確描述、易變的東西。編寫正確的測試代碼，就是對需求最好的描述，當測試通過時，產品代碼也就自然滿足了需求。　

正確的注釋代碼。開發人員通常對編寫文檔非常厭煩，但要使用、理解別人的代碼時通常又希望能有文檔進行指導。而測試驅動開發過程中產生的測試用例代碼就是對代碼的最好的解釋。

保證項目質量。開發人員可以容易的保證測試覆蓋率，并且不斷完善測試用例，來達到符合質量要求的測試密度，為開發人員增強信心?

測試不僅是質量保證部門的事情，它貫穿了整個軟件生命周期。中培的測試策略覆蓋了應用系統的各個方面，并且幫助客戶使整個測試過程自動化，覆蓋單元測試、功能測試、驗收測試、性能測試、回歸測試、集成測試、以及驗收測試，測試腳本的可重用性很高。頻繁的進行測試活動，可以在早期發現問題，使修正問題的質量成本降低，大幅提高產品質量，并提高測試和開發人員工作效率。

2.人才培養

敏捷溝通?

敏捷開發強調開發過程中人的重要性。重點在于：?

以人為本，注重編程中人的自我特長發揮，鼓勵建立自組織的團隊。

客戶與開發者的關系是協作，而不僅是合同關系

項目成功的一個重要因素就是充分的交流。中培通過結對編程等敏捷實踐，促進項目團隊的交流，創造一種開發人員交流分享的文化，構筑學習型組織。

結對編程

結對編程，指的是這樣一種程序設計實踐：兩名程序員并肩工作在同一臺計算機前，共同探討設計方案、共同設計算法、共同編寫程序代碼、共同完成各種測試。在這兩個人中，被稱為“駕駛員”的那個人負責實際操作或做設計方案，被稱為“領航員”的另一個負責其他工作，包括隨時觀察“駕駛員”的工作情況，發現并糾正其操作?性和策略性失誤。　

結對編程的好處在于：?

在團隊中傳遞知識。經驗少的開發人員和經驗多的一起工作，從實際工作中學習到很多難以言傳的知識和技能，比光看文檔效果好得多?

降低人員風險。開發人員一起開發相同功能，并經常交換配對，大家互為備份。當出現人員變動或者休假等情況，仍然有人熟悉其他人的工作，開發收到的影響相對小得多?

提高代碼質量。　一個人思路難免受到局限，兩個人一起工作考慮的要全面；更進一步，如果一個人的設計，結對的另一方不能理解，說明設計還不夠簡單明了，需要繼續改進。　直接的，持續的CodeReview，使代碼質量大大提高。

提高工作效率。在有人在旁邊盯著的時候，去偷懶要困難的多；同時，在遇到困難的時候，可以更容易更及時的得到他人的幫助?

增進團隊凝聚力。敏捷方法創造一種公開和交流的團隊氣氛，鼓勵通過一起工作來互相學習，相互了解，增進信任?

團隊內部知識庫

通過內部知識庫的形式（如Wiki），鼓勵大家將開發過程中的得到的領域知識，最佳實踐變成組織過程資產，促進公司內部的知識積累。個人技能提高的過程，也會成為組織成長的過程。建立自組織的團隊和學習型組織，可以從知識層面打破了因組織結構形成的邊界，大家都能分享自己的知識，并能從其他人那里獲得新的知識。　

這樣的團隊能最大程度上激發個體的主觀能動性，吸引更多的優秀人才加入，達到企業和個人共贏。　?

3.流程改善

敏捷開發強調軟件開發的產品是軟件，而不是文檔。文檔是為軟件開發服務的，而不是開發的主體。所有流程是為了開發軟件服務的，而不是為開發團隊增加不必要的負擔。　

流程簡化?

敏捷開發和CMM/CMMI并不沖突。在CMMI過程域中，OPD（組織級過程定義）和IPM（集成項目管理），也強調流程剪裁，因地制宜。這一點往往在傳統開發實踐中被忽視。開發團隊把很多時間和精力花費在制作格式一致，美觀華麗的文檔上，而忽視了文檔作為溝通媒介這一重要屬性。　

敏捷不是不要文檔，而是減少無效的文檔，使項目團隊把更多精力放在可以創造商業價值的可運行的軟件產品上。文檔和計劃的詳細程度是根據項目的特點、開發階段和內容的重要性來決定的。需要項目開發團隊在實踐中不斷摸索最適合項目的實踐。　

在敏捷開發中，MS Word不是唯一的文檔格式，項目團隊可以使用多種多樣的文檔工具來進行溝通，如MSPowerPointMSExcel，團隊Wiki，甚至把白板上討論的內容用數碼相機拍攝下來，存為圖片。選擇最適合的工具，傳遞合適的信息，達到消除浪費和冗余，加強溝通的目的。　

敏捷項目計劃?

計劃是為了交付，而不是按計劃交付。敏捷項目的計劃是：?

做長計劃?變成?常做（短）計劃?

價值驅動型，首先做對業務價值（或者投資回報率）最大的部分

在開發過程中，一種常見的浪費是“為將來準備的投資”。例如為了應付將來可能出現的需求變化而提前引入的靈活設計，如果需求沒有發生變化，這些靈活設計就會成為浪費。因為這樣的設計是空想出來的，而不是來源于實際。這種做法消耗了很多開發成本。制造業為了降低庫存成本而創造出“JustInTime”的生產和決策方法同樣適用于軟件行業。　

如何消除預測錯誤的浪費？避免預測錯誤的?根本辦法就是推遲決策：決策下得越晚，就越不容易因為預測失準而造成浪費。當然也不能晚到錯過了時機、耽誤了工作才下決策，決策也要JustInTime。過早的、含有太多預測成分的決策也會造成浪費，其危害絲毫不亞于過晚的決策。　

擁抱變更?

在開發全過程中，敏捷方法能很好的接受客戶的需求增加和變更，同時和客戶風險共擔。　

隨時可提出變更  

變更在迭代開始時引入，開發中的需求不做變更。根據變更，確定優先級，調整下個迭代的計劃

保持計劃工作量（工作時間）與團隊的能力相當

因為是采取的較短的交付周期，項目團隊可以盡早的提交可工作的軟件。客戶可以根據實際的軟件，能盡早的對開發做出反饋，不斷完善需求，提出新的更有價值的特性，降低變更帶來的成本。　

以故事（Story）為單位管理需求?

通過故事卡片（Story Card）和故事墻（Story Wall）等敏捷實踐來管理需求和開發過程，提高開發效率，降低文檔量，使項目更加可控。這些方法可以促進技術人員和非技術人員的溝通和交流，使管理者一目了然的了解項目的進展。