軟件開發模型與過程改進

        從過去軟件開發模型, 咱們有不少的反思與借鑑. 筆者曾看到國內三線城市的一些公司的軟件開發過程, 項目的成功依賴我的能力. 對於每個軟件系統研發過程, 只是拍腦殼定個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 應用程序，您可能但願頻繁推出更新以添加新功能，或者在得到客戶的反饋時改進該應用程序。您沒必要擔憂繁重的版本控制任務，或者維護文件以跟蹤哪一個客戶端具備哪一個版本。若是版本發佈涉及到客戶端的更改或工做，您可能不但願頻繁地作出更新。此外，頻繁的迭代也許是個好主意，由於您知道本身能夠在數週而不是數月內實現和發佈更改。

工做軟件
主要的進度度量標準是工做軟件。已編寫的文檔和幻燈片演示並不足以知足大多數業務需求——您須要相關的工做軟件。若是您從事的是諮詢業，也許文檔和幻燈片就足夠了，可是部署工做軟件最終是大多數組織的目標。

適應
在敏捷開發方法中，即便是後期的需求更改也是受歡迎的。很長時期以來，軟件專業人員不遺餘力地避免或減小作出後期更改。然而，因爲業務環境可能快速變化，軟件需求也應當如此。

親密無間，平常協做
業務人員和軟件開發人員應該天天就解決方案交換意見並展開協做。後期需求更改可能來自於業務人員，而且開發人員應該實現那些需求。若是流程容許需求變動，則平常協做是必需的。
對於實現接口或規範的應用程序，需求應該與指定的權威機構發佈的規範文檔相同。對該文檔的更改不僅是大事，這種更改根本就不該該出現。

積極主動、熟練人員
項目是圍繞積極主動、熟練的受信任我的而構建的。（這確實應該是任何組織的基礎。）無疑能夠編寫另外一個專欄來討論爲何某些人積極主動，而其餘人則不是。您是否擁有用於激勵和培訓沒有動力和不熟練的工做人員的資源，或者您是否須要肯定已經充滿動力而且高度熟練的可僱用人員

自組織的團隊
自組織的團隊在大多數軟件開發工做中還不是現實。他們須要大量的開發和管理方面的經驗。自組織的團隊將決定他們能夠在某個迭代中實現需求的哪一個部分，並將決定由誰負責該實現。團隊成員的角色基於他們的興趣和知識，而不是基於管理層的任命。組織渙散的團隊將僅接受少許需求，而且產出成果也很少。爲了正確地工做，團隊必須瞭解他們在作什麼，而且管理層必須信任他們。

您的公司準備好了?

協商文化
開放和誠實的討論在任何組織中都很是重要，可是若是您計劃採用敏捷方法，則組織的各個部門必須良好溝通而且可以在必要時作出妥協。

組織中的工做的人員之間的信任
若是管理層不信任開發人員，或者開發人員不信任銷售人員，您就麻煩了。

規模較小、能力級別較高的團隊
只需使用少許沒必要應付額外官僚做風的很是優秀的開發人員便可完成大量的工做。

促進團隊成員之間快速溝通的環境。
業務需求須要在眼下而不是在下週獲得知足。您的組織文化須要是快速響應的文化，而不是在過程當中束手無策的文化。

七條原則幫助來判斷什麼項目是敏捷的項目:

1. 項目中有利益干係人（Stakeholder）的參與
2. 團隊擁有而且可隨時執行的迴歸測試
3. 關注產品自身而不是冗餘的文檔
4. 項目開發擁有嚴格的源碼管理、版本控制
5. 開發可以積極面對和響應項目需求變化
6. 團隊做爲總體直接擔負項目責任
7. 可以自動化重複性的活動

共性

擁抱變化（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第一級，判斷你的軟件和測試團隊實踐是否符合如下的任何一個描述：

1. 爲了得到靈活性，軟件過程大致是在項目過程當中由從業者和他們的管理者臨時準備的。
2. 即便肯定了一個軟件過程，它不是嚴格維護或強制從每一個階段或迭代中嚴格執行的。
3. 團隊的焦點是解決眼下的危機（救火）。
4. 當強加了嚴峻的截止時間時，產品的功能和質量不得不對時間表作出妥協。
5. 意圖是增強質量的活動，好比結構化的評估和測試，在項目落後於時間表時常常被削減或取消。

CMM的核心思想是: 過程, 要事先定義; 過程的實施效果, 要不斷驗證(能夠持續改進); 過程當中的基本活動形式,要保證.

軟件能力成熟度模型集成(CMMI)

將現有的實施以及將來的各類能力成熟度模型進行了集成，目的就是加強並改進軟件過程，以最低的成本最高的效率，開發出最符合客戶需求的高質量軟件。

目前通用的成熟度模型有五級：

• 初始級：混亂無序的軟件過程，成功與否徹底依賴於我的的努力。
• 可重複級：有基本的項目管理過程去跟蹤項目進度、成本等。
• 已定義級：具備過程的文檔化、標準化。
• 量化管理級：軟件質量和過程有的詳細度量數據支持，並有定量的控制。
• 優化管理級：過程量化，並定量反饋信息，可持續改進。

人力資源能力成熟度模型PCMM（People Capability Maturity Model）

是美國卡耐基.梅隆大學的軟件工程研究院（SEI）開發的一個管理架構，於1995 年推出第1版標準,隨即在世界範圍內被各類商業組織、政府組織以及其餘類型的組織普遍運用。後來又推出第2版標準，促使PCMM更爲科學化、更具備適用性和普遍性，同時進行了PCMM評估方法的拓展和完善，使PCMM更具實用性。

TMM測試能力成熟度等級

混沌級

一、沒有專業測試團隊
二、沒有創建測試需求和測試用例管理

初始級

一、創建了專業測試團隊

測試團隊
二、實現了需求、測試用例和測試執行的管理

需求管理
測試用例管理
測試執行管理
缺陷跟蹤

提升級

一、劃分了測試分析、測試設計和測試執行階段

測試需求分析

二、引入了測試分析和測試設計方法，保障了測試覆蓋度

測試用例設計
評審管理

優化級

一、引入缺陷分析，發現軟件開發和測試過程當中質量改進點，不斷優化流程
測試計劃

二、引入測試度量，使得測試過程可視化，達到量化管理目標

測試度量
缺陷分析

 

Final

    組建敏捷團隊, 須要優秀的工程師, 持續長期招聘, 創造公司的影響力, 招聘優秀與合適的人容入團隊.  層級組織不能快速應對新的市場機遇和變化，這會妨礙公司的長期生存。組織應該在跨職能團隊和董事會之間分配管理職責，從而實現扁平化並提升總體敏捷. 每個理智的人都想在一個開放、透明、誠實、民主的環境中工做，在那裏他們的知識和訴求可以獲得響應。擁有中層管理的傳統的層級結構每每不能作到這一點。它仍然可以很是有效地解決問題，可是它每每是一個冰冷的環境。敏捷團隊是自組織的團隊,擁有制定計劃和作技術決定的自主權.若是項目成員足夠優秀,那麼他們幾乎能夠採用任何一種過程來完成任務. 若是項目成員不夠優秀,那麼沒有任何一種過程能夠彌補這個不足.
    團隊持續進化, 淘汰白食者與未被進化者, 成員必須在環境中自我學習與進化. 凡事須要度量, 有度量纔有管理.
    對於短時間缺少優秀工程師組織, 仍是先成功實踐CMMI過程半年之後, 再逐步嘗試轉化于敏捷開發. 從其中須要通過組織與企業文化變革

    快速反饋（在全部層面，爲了更快速響應、更快速的發現問題和機會）
    權力下放和透明的信息流（爲了更快地解決問題）
    學習和知識共享（爲了解決複雜問題）

--------------------------------------------------------------------------------------------------------------------------------------------

今天先到這兒,但願對您在團隊管理, 項目管理,產品管理 有參考做用 , 您可能感興趣的文章:
企業信息化與軟件工程的迷思
企業項目化管理介紹
軟件項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與我的目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網數據庫架構設計思路
IT基礎架構規劃方案一(網絡系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變

若有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關注個人微信訂閱號：

做者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。
該文章也同時發佈在個人獨立博客中-Petter Liu Blog。