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

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

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

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

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

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

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

3. 用戶故事和用例我們應該寫哪個？（與設計方法的接口，若已經實施了UML、面向對象、MVC、用戶建?！鹊纫幌盗屑夹g方法，問題會很尖銳）

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的覆蓋面相對少。

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

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

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

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

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

?

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

轉載于:https://blog.51cto.com/cheny/1101518

總結

以上是生活随笔為你收集整理的AUP2敏捷统一过程之一：序言及降低过程的总体拥有成本的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。