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

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

敏捷統一過程的全稱是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潛在的要覆蓋的範圍進行描述。