從過去軟體開發模型, 我們有很多的反思與借鑒. 筆者曾看到國内三線城市的一些公司的軟體開發過程, 項目的成功依賴個人能力. 對于每一個軟體系統研發過程, 隻是拍腦袋定個Dead Line. 規定時間2個月做出來, 臨近快要傳遞的時間點, 說無論采用什麼方式,加班還是其它都要做出來, 最後做出來系統品質差. 然後後面幾個月對系統開始打更新檔, 撲火. 實際上就是一個小做坊. 對于研發工程師都是苦不堪言. 想實施靈活又限于公司文化, 人員的瓶頸, 隻能是不斷轉化思想與方法. 最後屬于哪一類過程也不清楚了. 由于現在還沒有任何一種方法能夠解決軟體危機中的所有問題，是以在軟體開發的各個階段采用綜合治理的方法. 軟體開發模型直接影響軟體開發的周期和軟體品質，是軟體開發的組織管理形式，是軟體工程最重要的内容之一。 讓我們先回顧一下軟體工程中開發模型:
WaterFall模型
缺點
• Requirements must be known up front: It\'s difficul t to imagine every detail in advance. Most projects start out with some uncertainty, and more detai ls are learned as the project progresses.
• Hard to estimate reliably: To gain conidence in an estimate, there may be the need to design and implement parts, especially riskier ones. Estimates become more precise as the project progresses.
• No feedhack of system by stakeholders until after testing phase: The process does not facilitate intermediate versions. Stakeholders often need reassurance of progress and conirmation that what is being developed meets requirements.
• Major problems with system aren\'t discovered until late in process: The testing phase is where these problems are found, but it leaves very li ttle time for correction, resulting in potentially disastrous effects on project schedule and cost.
• Lack of parallelism: Each phase is executed to completion. Disjointed parts of the system could otherwise be completed in parallel.
• Inefficient use of resources: Team members can be idle while waiting for others to complete their dependent tasks or for phases to complete. Also, someone good at requirements analys is is not necessarily good at programming.
原型
在獲得使用者基本需求說明的基礎上，投入少量人力和物力，快速建立一個原始模型，使使用者及時運作和看到模型的概貌和使用效果，并對需求說明進行補充和精化，提出改進意見，開發人員進一步修改完善，如此循環疊代，直到得到一個使用者滿意的模型為止。從原型法的基本思想中可以看到，使用者能及早看到系統模型，在循環疊代修改和完善過程中，使使用者的需求日益明确，進而消除了使用者需求的不确定性，同時從原型到模型的生成，周期短、見效快，對環境變化的适應能力較強。
優點：
開發者與使用者充分交流，可以澄清模糊需求，需求定義比其他模型好得多
為使用者需求的改變提供了充分的餘地
缺點：
開發者為了使一個原型快速運作起來，往往在實作過程中采用折衷的手段。軟體系統的組成部分可能會打折扣；
資源規劃和管理較為困難，随時更新文檔也帶來麻煩。
一般使用場合：
開發者在不了解的應用領域開發
客戶不清楚其所開發軟體項目的最終目标
增量
系統設計時分片傳遞，可使使用者在使用某些基本功能的同時，開發剩餘的功能。這樣通常會并行地存在兩個系統：生産系統和開發系統。運作或生産系統是目前被客戶或使用者所使用的系統。而開發系統是準備用于替代目前生産系統的下一個版本。
• 增量模型是一種非整體開發的模型。是瀑布模型的順序特征和快速原型模型的疊代特征相結合的産物。
• 該模型具有較大的靈活性，适合于軟體需求不明确、設計方案有一定風險的軟體項目。
•特點：
在前面增量的基礎上開發後面的增量
每個增量的開發可用瀑布或快速原型模型
疊代的思路
•優點：
如果在項目既定的商業要求期限不可能找到足夠的開發人員，這種情況下增量模型顯得特别有用。早期的增量可以有少量的人員實作。同時，增量模型可以規避技術風險。
螺旋
軟體開發模型與過程改進
螺旋模型是一種疊代模型，每疊代一次，螺旋線就前進一周。當項目按照順時針方向沿螺旋移動時，每一個螺旋周期包含了風險分析，并且按以下4個步驟來進行：
（1）确定目标，標明方案，設定限制條件，標明完成本周期所定目标的政策。
（2）分析該政策可能存在的風險。必要時通過建立一個原型來确定風險的大小，然後據此決定是按原定目标執行，還是修改目标或終止項目。
（3）在排除風險之後，實作本螺旋周期的目标，例如，第一圈可能産生産品的規格說明，第二圈可能産生實作産品設計等。
（4）最後一步是評價前一步的結果，并且計劃下一輪的工作。
優點：
結合瀑布模型和原型模型的優點
風險分析可使一些極端困難的問題和可能導緻費用過高的問題被更改或取消
缺點：
螺旋模型開發的成敗，很大程度上依賴于風險評估的成敗。需要開發人員具有相當豐富的風險評估經驗和專門知識
一般使用場合：
需求不能完全确定，同時又存在技術、資金或開發時間等風險因素的大型開發項目。
RUP(Rational Unified Process) 軟體開發模型與過程改進
上圖示例3個疊代示例, 再來看經典的RUP示例圖:
來自IBM的海報: RUP 入門最佳導航圖：Rational 統一過程，切實可行的流程
原則
- 隻開發需要的東西。
- 關注有價值的結果，而不是獲得結果的過程。
- 文檔最小化。
- 足夠靈活。
- 從錯誤中吸取教訓。
- 定期做風險回顧。
- 為進度設定客觀和可度量的條件。
- 自動化需要大量人力投入且單調易錯的工作。
- 使用小而有自主權的團隊。
- 有計劃。
疊代開發是針對問題解決和解決方案開發的基于團隊的方法。它要求所有參與的人 —— 包括開發團隊、客戶團隊，和管理團隊 —— 都采用協作的技術。
從開發團隊的觀點出發，采用疊代和增量開發是需要授權的，并要求團隊成員積極進取地用他們認為最适當的方式處理項目危機和難題。通過設定清晰的目标和客觀地度量結果（但不訓示活動）來管理疊代可以確定輕松地找到最佳的方式來傳遞成果。
從客戶和業務團隊的觀點出發，引入清晰有意義的目标，并結合回顧可論證成果的能力，可以使那些最終使用新軟體的人在項目中發揮積極作用，并與開發團隊分享所有權。疊代對所有涉及項目的業務人員産生深遠且長久的影響，并且從根本上改變了他們規定、支付，并實作軟體解決方案商業利益的方式。
從管理團隊的觀點出發，每個項目都被分解為一系列小的項目，稱為疊代，每個疊代都建立在前一個疊代的結果之上，并不斷增加地實作項目的總目标。當授權開發團隊創造革新的且有效的解決方案時，這種對項目的分割引入了正常的，可度量的，使項目保持正軌的裡程碑，将項目成功的幾率最大化。
企業統一過程
企業統一過程, RUP定義了軟體開發生命周期，EUP則将它進行了擴充以覆寫整個資訊技術（IT）的生命周期。擴充包括兩個新的階段，産品階段和衰退階段，還有一些新的準則：營運和支援以及7個企業準則（企業商業模組化，資産組合管理，企業架構，戰略重用，人力管理，企業行政和軟體過程改進）
靈活統一過程
靈活統一過程，關注的是輕便的方法和一套能夠用靈活原則和價值觀驅動的、最小化的實踐。AgileUP：
是一個Rational統一軟體過程（RUP）的簡化版。它描述了一個簡單易懂的方法，該方法通過使用靈活技術和概念來開發商業程式軟體，但它依然忠于RUP。我努力讓AgileUP在方法和描述上盡量簡單。那些描述單刀直入，如果你需要更詳細的内容，網上都有連結。方法則緻力于靈活技術，包括測試驅動開發（TDD）、靈活模組化驅動開發（AMDD）、靈活變更管理以及資料庫重構，這些都可以改進生産率。
缺點
• The UP was originally conceived of for large projects : This is fine, except that many modern approaches perform work in small self-contained phases .
• The process may be overkill for small projects : The level of complication may not be necessary for smaller projects. Practitioners and vendors of the uniied process have modified it to be more like an agile process.
靈活
宣言
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
原則與優點
快速、連續的傳遞
通過快速、連續的有用軟體傳遞來獲得客戶滿意度。這對您的組織是否重要？您的公司是否為希望開始用某個應用程式的 Beta 版本來吸引客戶的新公司？您的應用程式是否将通過取代手動工作來節省内部開支？
頻繁的傳遞
可以按照數周而不是數月的間隔頻繁地傳遞可工作的軟體。如果您的應用程式是 Web 應用程式，您可能希望頻繁推出更新以添加新功能，或者在獲得客戶的回報時改進該應用程式。您不必擔心繁重的版本控制任務，或者維護檔案以跟蹤哪個用戶端具有哪個版本。如果版本釋出涉及到用戶端的更改或工作，您可能不希望頻繁地做出更新。此外，頻繁的疊代也許是個好主意，因為您知道自己可以在數周而不是數月内實作和釋出更改。
工作軟體
主要的進度度量标準是工作軟體。已編寫的文檔和幻燈片示範并不足以滿足大多數業務需求——您需要相關的工作軟體。如果您從事的是咨詢業，也許文檔和幻燈片就足夠了，但是部署工作軟體最終是大多數組織的目标。
适應
在靈活開發方法中，即使是後期的需求更改也是受歡迎的。很長時期以來，軟體專業人員竭盡全力地避免或減少做出後期更改。然而，由于業務環境可能快速變化，軟體需求也應當如此。
親密無間，日常協作
業務人員和軟體開發人員應該每天就解決方案交換意見并展開協作。後期需求更改可能來自于業務人員，并且開發人員應該實作那些需求。如果流程允許需求變更，則日常協作是必需的。
對于實作接口或規範的應用程式，需求應該與指定的權威機構釋出的規範文檔相同。對該文檔的更改不隻是大事，這種更改根本就不應該出現。
積極主動、熟練人員
項目是圍繞積極主動、熟練的受信任個人而建構的。（這确實應該是任何組織的基礎。）無疑可以編寫另一個專欄來讨論為什麼某些人積極主動，而其他人則不是。您是否擁有用于激勵和教育訓練沒有動力和不熟練的從業人員的資源，或者您是否需要确定已經充滿動力并且高度熟練的可雇用人員
自組織的團隊
自組織的團隊在大多數軟體開發工作中還不是現實。他們需要大量的開發和管理方面的經驗。自組織的團隊将決定他們可以在某個疊代中實作需求的哪個部分，并将決定由誰負責該實作。團隊成員的角色基于他們的興趣和知識，而不是基于管理層的任命。組織渙散的團隊将僅接受少量需求，并且産出成果也不多。為了正确地工作，團隊必須了解他們在做什麼，并且管理層必須信任他們。
您的公司準備好了?
協商文化
開放和誠實的讨論在任何組織中都非常重要，但是如果您計劃采用靈活方法，則組織的各個部門必須良好溝通并且能夠在必要時做出妥協。
組織中的工作的人員之間的信任
如果管理層不信任開發人員，或者開發人員不信任銷售人員，您就麻煩了。
規模較小、能力級别較高的團隊
隻需使用少量不必應付額外官僚作風的非常優秀的開發人員即可完成大量的工作。
促進團隊成員之間快速溝通的環境。
業務需求需要在眼下而不是在下周得到滿足。您的組織文化需要是快速響應的文化，而不是在過程中一籌莫展的文化。
七條原則幫助來判斷什麼項目是靈活的項目:
- 項目中有利益幹系人（Stakeholder）的參與
- 團隊擁有并且可随時執行的回歸測試
- 關注産品自身而不是備援的文檔
- 項目開發擁有嚴格的源碼管理、版本控制
- 開發能夠積極面對和響應項目需求變化
- 團隊作為整體直接擔負項目責任
- 能夠自動化重複性的活動
共性
擁抱變化（Embrace the change）
無論是多麼明智，多麼正确的決定，也有可能在日後發生改變。是以，團隊要能夠充分了解我們的利益幹系人（Stakeholder）和客戶代表為什麼經常提出新的需求和設計要求，一句話，就是心中有數“唯一不變的是變化”。團隊更要信任 利益幹系人（Stakeholder）做出的每次決定和需求的調整都是将産品開發推向更正确的發展方向，新變化将進一步降低風險，實作團隊最大化利益，了解這是适應市場變化的必然行為。而在接受變化的同時，我們應該積極的向 利益幹系人（Stakeholder）和客戶代表反映實作活動中暴露出來的可能的設計缺陷和錯誤。在實際工作中，團隊成員應該用優先級制度來劃分事情和目标先後順序，在疊代周期内對于還沒有最終決定的設計方案可以予以後來實作、測試，不用急于投入資源展開全面的開發、測試活動。這樣一來，開發測試團隊也會人員也将更加适應，真正擁抱變化。
客戶的參與（With Customer Representative on site）
首先誰是客戶（Customer），客戶代表（Customer Representative） 呢？利益幹系人（Stakeholder），或者我們可以了解為我們的客戶（Customer），産品的最終使用者（End user），内部使用者（Insider），商業夥伴（Business Partner）。利益幹系人（Stakeholder）作為團隊中最了解業務（Business）的人物将幫助開發團隊的快速達到目标和做出适時決策。開發團隊擁有很好的技術但在業務（Business）方面他們需要 利益幹系人（Stakeholder）的幫助。而通常在靈活的開發項目中，團隊中的任何一個人若需要幫助時，隻要簡單的邀請大家參加一個 15 分鐘會議，或一封郵件、一個電話便可以解決。但是，如果利益幹系人（Stakeholder）各執一詞怎麼辦呢？為解決這個問題，将 Product Owner 引入到讨論中來，作為 Product Owner 他可以作為是 利益幹系人（Stakeholder）的代表，能夠在分歧中做最後抉擇。是以，通過這樣的客戶代表的參與，團隊更好的了解了所做事情的價值和意義，其工作效率也因而得到很大提高。利益幹系人（Stakeholder）能夠幫助團隊中的每一個人更好，更快的完成了工作，他們的直接參與成為了靈活開發、靈活測試的重要前提。
較少的文檔（With less documents）
靈活開發更重視生産出可用的産品而不是詳細文檔。而時常有發覺文檔又是無論靈活還是傳統開發、測試不可或缺的一部分。筆者認為，傳統開發的文檔在靈活開發裡仍有大用，隻是原來十來頁的内容精煉到現在的一頁半頁。靈活主義者相信文檔不是最佳的溝通方式，他們鼓勵通暢的交流和溝通，要求避免和減少陳詞濫調和空頭支票。尤其是複雜的文檔說明隻是增加了溝通成本，因而靈活開發、測試的文檔不需要長篇累讀，需要的是簡潔，清晰。任何一段清楚的文字，甚至一張圖檔，照片，一封記錄着會議記錄的郵件都是我們認可的靈活文檔。因為是無論是通過文字闆書的檔案還是其他的溝通方式和載體都是為了幫助團隊進行更高效的交流和溝通。隻有團隊保持着溝通上、了解上的一緻後才能夠充分發揮出團隊最佳戰鬥力。但凡這是幫助團隊有效溝通的方式，靈活開發是不會放棄的。
最大化的生産力（Maximize Productivity）
靈活開發模式要最大化的提高團隊的工作效率。無論是依靠剪除備援的文檔工作，還是提供民主的、通暢的溝通平台都是為了幫助團隊能夠集中有限的精力處理有意義的問題。據調查，通常人會在兩個、多個任務并行的情況下産生出出最高工作效率。而靈活也恰恰使用了各種方法得到團隊的最大生産力。靈活開發的 Scrum 模式，要求在計劃階段，團隊成員主動定制疊代周期的所有工作任務，是以，本身從團隊開始疊代活動的那時起，已經在在多重工作的壓力下緊張工作了。而在日常的疊代生産活動裡，各個成員需要當衆簡單彙報當天的工作進度和承諾下一個 24 小時的工作計劃。是以，通過增加靈活人員的工作的透明度，無形之中，團隊成員的生産力進一步得到提高。
測試驅動開發（Test Driven Development）
測試驅動開發，是讓開發人員在編寫功能代碼之前，根據對需求的了解先設計和編寫單元測試代碼。先思考如何對将要實作的功能進行驗證，再考慮功能的實作。然後疊代的增加新功能的單元測試和功能代碼編寫，直到完成全部功能的開發。
自動化備援工作（Automate the redundant work）
将團隊成員從備援的勞動中解放出來，無論是自動化的測試還是自動化工具的開發隻要能夠節約成本都是靈活開發、靈活測試的目标。
民主的團隊（Democracy in team）
靈活團隊是一支民主的團隊，團隊關系是平行的，每個團隊成員能夠平等的參與讨論，決策。傳統開發的垂直的官僚機構在靈活開發中已是過時的。
尊重團隊（Respect to team）
靈活團隊的決定權交有團隊自己，決定是團隊統一制定。無論是産品設計方案還是産品的功能實作都是的最佳結果。團隊脫離了任何一個成員的工作都是不完整的，是以我們應當足夠尊重其他成員的勞動果實和表達對其他成員的充分信任。尊重團隊，尊重團隊中的每一個成員都是靈活開發的原則之一。
Tips: 靈活關注人與實踐, 通常需要成功實施靈活團隊需要半年融合期.
XP極限程式設計 軟體開發模型與過程改進
Scrum
目前很多公司在廣泛使用的, Scrum是一個包括了一系列的實踐和預定義角色的過程骨架（是一種流程、計劃、模式，用于有效率地開發軟體）。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，産品負責人代表利益所有者，開發團隊包括了所有開發人員。在每一次沖刺（一個15到30 天周期 ，長度由開發團隊決定），開發團隊建立可用的（可以随時推出）軟體的一個增量。每一個沖刺所要實作的特性來自産品訂單（product backlog，我覺得翻譯成“産品目标”更恰當）， 産品訂單（産品目标）是指按照優先級排列的需要完成的工作的概要的需求（目标）。哪些訂單項（目标項目）會被加入一次沖刺，由沖刺計劃會議決定。 在會議中，産品負責人告訴開發團隊他需要完成産品訂單中的哪些訂單項。開發團隊決定在下一次沖刺中他們能夠承諾完成多少訂單項。 在沖刺的過程中，沒有人能夠變更沖刺訂單（sprint backlog），這意味着在一個沖刺中需求是被當機的。
篇幅有限, 其它有關水晶等靈活方法在這兒不展開了
邊做邊改模型（Build and Fix Model）
很多小型初創公司其實已演變為 邊做邊改模型, 對于開發人員來說是痛苦的, 如下圖
當一個軟體産品在沒有規格說明或主要設計的情況下被開發時，開發者往往不得不重新對産品編碼多次直到他們得到正确穩定的産品。這種開發模型就是邊做邊改模型。
邊做邊改模型的最重要缺點是存在于需求。設計和實作中的錯誤要到整個産品被建構出來後才能被發現。
這是一種類似作坊的開發方式，對編寫幾百行的小程式來說還不錯，但這種方法對任何規模的開發來說都是不能令人滿意的，其主要問題在于：
1） 缺少規劃和設計環節，軟體的結構随着不斷的修改越來越糟，導緻無法繼續修改；
2） 忽略需求環節，給軟體開發帶來很大的風險；
3） 沒有考慮測試和程式的可維護性，也沒有任何文檔，軟體的維護十分困難。
其它模型還有 快速應用開發(Rapid Application Development), 噴泉, 變換模型,智能模型,WINWIN,并發開發模型,基于構件的開發模型, 基于體系結構的開發模型, Adaptive Software Development
創業公司的軟體開發
“完成比完美重要”以及“快速移動且要突破一些事情”，當你進入到創業公司的工作區域時會看到這樣的箴言。
流程管理是靈活的、進化的、機會主義的
在創業公司中流程管理代表了用于管理産品開發的所有工程活動。因為靈活性對于創業公司來說能夠使用頻繁的變化至關重要，靈活方法論被認為是最可行的流程－他們鼓勵變化、允許開發去适應業務的政策。以增量和疊代的方式快速釋出可以縮短從創意構思到生産部署的時間。其中一個靈活的變體就是精益方法，此方法倡導識别軟體業務中風險最大的部分，且據系統的測試提供最小化的可行辦法，以及在下一代産品疊代時的修改計劃。在此方面，原型是縮短上市時間必不可少的。為了能夠更好的設計原型，在第一階段需要實作“軟編碼”的進化工作流程，直到找到最優解為止。盡管在開發中用來鼓勵快速的開發原型使用了多種方法論，但是創業公司沒有一個是按照某種方法論嚴格執行的。然而創業公司的不确定和快速變化的性質驅使他們尋找最小化的流程管理來實作短期的目标，以快節奏的學習過程來适應使用者，進而解決市場的不确定性。創業公司急于尋找利益增長點和獲得投資，進而得到進一步的發展。這也就意味着軟體品質并非是他們主要關心的。為了能夠快速的驗證産品，他們傾向于利用特定的靈活或精益方法。
- 根據市場需求使用衆所周知的架構來快速的适應産品的變更；
- 通過已有的元件來使用進化的原型和實驗；
- 持久的客戶承認成立專門的團隊來作早期的采用者；
- 持續的價值傳遞，專注于從事那些為付費使用者服務的核心功能;
- 團隊的授權會影響到最終到結果；
- 使用量化來快速的學習使用者的回報和需求；
- 使用容易實作的工具來促進産品的開發，且要掌控快節奏的、不斷變化的資訊。
溝通
溝通包括三個部分：視覺、口頭和筆頭。去掉視覺和口頭元素，溝通隻能保留原本7%的資訊。跟旁邊隔間的程式員在網絡上溝通，實際上跟閱讀筆頭文字沒有差別。您可以用文字發送問題（寫郵件等于另一堆筆頭文字），得到回應（也是郵件）。如果不能提供程式員可以面對面溝通的區域，我們就進一步限制了溝通。隔離也會降低士氣。
第一條：組織不應做任何事情限制溝通。典型的、也是很常見的障礙，就是格子間。在行動相對不受限的開放空間中，團隊工作更有成效。
第二條：不要将兩個甚至更多團隊放在同一個項目區域中。與手上任務無關的人也是障礙，這些外人的出現會造成噪音，降低士氣。
第三條：為開發團隊提供白闆、會議桌、馬克筆。
第四條：不要試圖在項目之間分享團隊成員。
軟體過程改進
過程改進（Software Process improvement，SPI）幫助軟體企業對其軟體（制作）過程的改變（進）進行計劃、（措施）制定以及實施。 他的實施對象就是軟體企業的軟體過程，也就是軟體産品的生産過程，當然也包括軟體維護之類的維護過程，而對于其他的過程并不關注. 五個原則:
·注重問題
·強調知識創新
·鼓勵參與
·上司層的統一
·計劃不斷地改進
為了決定你的組織是否處于CMM第一級，判斷你的軟體和測試團隊實踐是否符合以下的任何一個描述：
- 為了獲得靈活性，軟體過程大體是在項目過程中由從業者和他們的管理者臨時準備的。
- 即使确定了一個軟體過程，它不是嚴格維護或強制從每個階段或疊代中嚴格執行的。
- 團隊的焦點是解決眼下的危機（救火）。
- 當強加了嚴峻的截止時間時，産品的功能和品質不得不對時間表做出妥協。
- 意圖是加強品質的活動，比如結構化的評估和測試，在項目落後于時間表時經常被削減或取消。
CMM的核心思想是: 過程, 要事先定義; 過程的實施效果, 要不斷驗證(可以持續改進); 過程中的基本活動形式,要保證.
軟體能力成熟度模型內建(CMMI)
将現有的實施以及未來的各種能力成熟度模型進行了內建，目的就是增強并改進軟體過程，以最低的成本最高的效率，開發出最符合客戶需求的高品質軟體。
目前通用的成熟度模型有五級：
- 初始級：混亂無序的軟體過程，成功與否完全依賴于個人的努力。
- 可重複級：有基本的項目管理過程去跟蹤項目進度、成本等。
- 已定義級：具有過程的文檔化、标準化。
- 量化管理級：軟體品質和過程有的詳細度量資料支援，并有定量的控制。
- 優化管理級：過程量化，并定量回報資訊，可持續改進。
人力資源能力成熟度模型PCMM（People Capability Maturity Model）
是美國卡耐基.梅隆大學的軟體工程研究院（SEI）開發的一個管理架構，于1995 年推出第1版标準,随即在世界範圍内被各種商業組織、政府組織以及其他類型的組織廣泛運用。後來又推出第2版标準，促使PCMM更為科學化、更具有适用性和廣泛性，同時進行了PCMM評估方法的拓展和完善，使PCMM更具實用性。
混沌級
1、沒有專業測試團隊
2、沒有建立測試需求和測試用例管理
初始級
1、建立了專業測試團隊
測試團隊
2、實作了需求、測試用例和測試執行的管理
需求管理
測試用例管理
測試執行管理
缺陷跟蹤
提進階
1、劃分了測試分析、測試設計和測試執行階段
測試需求分析
2、引入了測試分析和測試設計方法，保障了測試覆寫度
測試用例設計
評審管理
優化級
1、引入缺陷分析，發現軟體開發和測試過程中品質改進點，不斷優化流程
測試計劃
2、引入測試度量，使得測試過程可視化，達到量化管理目标
測試度量
缺陷分析
Final
組建靈活團隊, 需要優秀的工程師, 持續長期招聘, 創造公司的影響力, 招聘優秀與合适的人容入團隊. 層級組織不能快速應對新的市場機遇和變化，這會妨礙公司的長期生存。組織應該在跨職能團隊和董事會之間配置設定管理職責，進而實作扁平化并提高整體靈活. 每一個理智的人都想在一個開放、透明、誠實、民主的環境中工作，在那裡他們的知識和訴求能夠得到響應。擁有中層管理的傳統的層級結構往往不能做到這一點。它仍然能夠非常有效地解決問題，但是它往往是一個冰冷的環境。靈活團隊是自組織的團隊,擁有制定計劃和做技術決定的自主權.如果項目成員足夠優秀,那麼他們幾乎可以采用任何一種過程來完成任務. 如果項目成員不夠優秀,那麼沒有任何一種過程可以彌補這個不足.
團隊持續進化, 淘汰白食者與未被進化者, 成員必須在環境中自我學習與進化. 凡事需要度量, 有度量才有管理.
對于短期缺乏優秀工程師組織, 還是先成功實踐CMMI過程半年以後, 再逐漸嘗試轉化于靈活開發. 從其中需要經過組織與企業文化變革
快速回報（在所有層面，為了更快速響應、更快速的發現問題和機會）
權力下放和透明的資訊流（為了更快地解決問題）
學習和知識共享（為了解決複雜問題）
--------------------------------------------------------------------------------------------------------------------------------------------
今天先到這兒,希望對您在團隊管理, 項目管理,産品管理 有參考作用 , 您可能感興趣的文章:
企業資訊化與軟體工程的迷思
企業項目化管理介紹
軟體項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式上司
學習型組織與企業
企業創新文化與等級觀念
組織目标與個人目标
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計劃
建構高效的研發與自動化運維
某大型電商雲平台實踐
網際網路資料庫架構設計思路
IT基礎架構規劃方案一(網絡系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之采購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鍊需求調研CheckList
企業應用之性能實時度量系統演變
如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理 資訊，請關注我的微信訂閱号：
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。
該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。