AUP2敏捷統一過程之一：序言及降低過程的總體擁有成本

文章目錄

• CMMI
• UML
• RUP（Rational Unified Process）
• Scrum/XP

這是敏捷統一過程系列的第一篇。（前篇，之一序言，欄目總目錄）

敏捷統一過程的全稱是AUP（Agile Unified Process），不過為了能區別已經被提過一次的AUP（就是RUP），這裡稱之為AUP2。

這個系列會探討如何在一家企業完整實施敏捷開發過程。在以往業界的討論中，多數時候將話題集中在如何在一個小範圍的團隊中實施敏捷，比如Scrum本身的架構僅限於4～7人的團隊如何做需求管理+計劃管理+任務管理的；即使引入了Scrum of Scrums，其範圍雖然擴大到幾十人乃至上百人，但管理內容仍僅限於這三個環節。

而實際上一個企業實際要管理的內容很多，以一個產品研發企業為例，最早期的產品規劃、使用者群定義、團隊招聘、績效考核、產品運營、技術架構這些都是企業要考慮的問題，如果這些內容沒有被照顧到，開發人員就可能會同時受到CMMI、Scrum、編程規範、團隊模型……等不同的、互不相關的過程或技術的約束，寫完這個文檔再寫那個文檔，導致無所適從。

有些企業在實施敏捷開發後，由於很難和別的過程介面，很容易遇到下面這些問題：

1. 為什麼我們使用了敏捷開發，但產品並沒有成功？（與產品定位的介面，Nokiaer應該經常問這個問題）

2. 我們的隊員有些不喜歡敏捷開發怎麼辦？（與團隊模型的介面，比如不喜歡協助別人，或者不喜歡讓別人看代碼）

3. 使用者故事和用例我們應該寫哪個？（與設計方法的介面，若已經實施了UML、物件導向、MVC、使用者建模……等等一系列技術方法，問題會很尖銳）

4. 我們想同時使用Scrum和持續整合、自動化測試，他們之間有何關係？

5. 公司負責過程的品質部門在敏捷開發中扮演什麼角色？

……

很多企業可能連問這些問題的機會都沒有，因為他們發現“敏捷開發並沒有想象中那麼容易推廣”，於是中途就放棄了。

AUP2敏捷統一過程嘗試提供一個架構來思考這些問題，從而讓軟體開發人員不會感覺自己在很多管理方法、技術中分別工作，而是流暢地在一個統一的過程架構下工作。

AUP2的實踐環節不是普適的，隨著時間的變化也不是一成不變的。它只是提供了一個思路：在任何情況下，我們都應該統一地看待企業所採納的過程、技術、組織架構……等內容，以期達到最低的擁有價值。

Process過程

Process這個詞比較難解，在CMMI傳入之前，國內基本上不知道這個詞，國外也很少提到。對比下面這幾個詞彙，可以大致理解Process的含義。

Practice實踐

大致指小規模的單一實踐，比如需求跟蹤矩陣、用例、順序圖表、使用者故事、每日立會、自動化測試等。實踐的規模大小不一，有些實踐又是若干子實踐的集合，比如持續整合。

Process過程

指若干實踐的集合，這一集合能解決某些領域的某些範圍的問題。

注意：以下的各種模型、方法論並不完全等同於過程，但這裡抽取其呈現出來的過程側面。

CMMI

CMMI中列出的內容大致相當於一家外包領域企業（尤其是為DOD提供外包開發的企業）所需的過程；它所涵蓋的範圍則是CMMI2級（需求管理、計劃、跟蹤……）、CMMI3級（需求開發，設計，測試……）等。

CMMI是迄今為止描述過程最完整的體系，它採用層級Level～過程域Process Area～實踐Practice的方式來完整描述自己的體系；還有一種不太為人熟知的方法，就是先分為工程/管理/支援/組織級改進四個域（具體名字忘了），然後再過程域～實踐三級。

從實用性的價值看，這種分類方法能讓我們理解其他過程能管理多大的範圍。

UML

UML本身不是一種過程，但在使用UML的時候會使用到CMMI中提到的需求開發、設計、編碼三個過程域，還會用到使用者建模、部署這兩個CMMI沒怎麼提的內容。

UML對於理解何為“Unified”非常有好處：UML把需求、設計、編碼三個環節聯合起來思考，一個環節的輸出，會變成下一個環節的輸入，環環相扣，從而大大節省了開發工作量。

這個特點在後面的AUP2描述中還會提到。

RUP（Rational Unified Process）

RUP的範圍包括（含英文縮寫的是與CMMI重合的部分，雖然不完全重合）：

商業建模，需求（RD需求開發），分析與設計（TS設計與現實），實現（TS設計與實現，學名叫“technical solution技術解決方案”），測試（VER驗證測試/VAL驗收），部署（VAL驗收），配置與變更管理（CM組態管理/ReqM需求管理），專案管理（PP專案計劃/PMC項目跟蹤），環境。

商業建模之所以在CMMI中不太重要，應該是因為CMMI應用與外包領域中的乙方，而這個過程則屬於甲方的職責。

環境是RUP的一個重點內容之一，目的是向軟體組織提供過程與工具的支撐。這正是Rational的業務所在。

RUP還潛移默化地定義了眾多角色，雖然從敏捷開發的角度看，這略微有點不“跨職能”，但從實踐的角度看，能讓團隊意識到存在某些複雜的工作需要有人承擔。

Scrum/XP

Scrum的主體內容也可以稱之為一個過程，應用於需求快速變化但又需要整體計劃的企業（這個定義適應面很大，因此才大受歡迎）。按CMMI的名詞定義，Scrum涵蓋了ReqM需求管理、PP專案計劃、PMC項目跟蹤與監控這三個過程域。

XP較少提到過程的內容，更像是互相關聯的一些實踐的鬆散集合，而XP發展的趨勢也是化整為零。按CMMI的名詞定義，極限編程覆蓋了RD需求開發、TS設計與實現、VER驗證與測試。

敏捷開發過程的局限性

與其他過程相比，顯然Scrum/XP的覆蓋面相對少。

“這正是我們選擇敏捷開發的原因，因為它比較輕量級。”或許有人會說。但這個回答的理解有問題：輕量級和覆蓋面是兩個概念。無論採用什麼開發過程，商業建模、績效考核、團隊發展這些內容都是企業必然會考慮的，一個覆蓋面過小且無法為自己不覆蓋的部分提供支援的過程，儘管降低了局部的管理難度，卻有可能反而會使公司的研發管理的總體成本變高。

典型的就是績效管理，由于敏捷開發未提供績效管理的模型，導致很多企業仍然採用傳統的績效管理方法（比如面向個人的績效考核，數程式碼，數缺陷數……），而這種管理方法又會反過來導致敏捷開發進行不下去。

在本人蔘與或瞭解的企業中，實施敏捷開發的主要阻力不是敏捷開發本身的實踐有多難，而是如何將敏捷開發與現有的組織圖和制度相適應，或如何改造現有的結構和制度以適合敏捷開發。

因此應該在敏捷開發的語境下擴充那些周邊的過程，以便為實施敏捷開發的大環境提供指導，以降低研發管理的總體成本。

其中一個有效方法，就是建立以敏捷為指導思想的統一過程，以涵蓋敏捷之外的組織圖與制度，並使之與敏捷開發相匹配。

下一篇文章，將會大致提出一個架構，對UP進行分析，並對AUP2潛在的要覆蓋的範圍進行描述。

本人正在參加CSDN部落格之星評選，如果讀完並喜歡這篇文章，歡迎投票：http://vote.blog.csdn.net/item/blogstar/cheny_com