溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這是敏捷統一過程系列的第一篇。（前篇，之一序言，欄目總目錄）
敏捷統一過程的全稱是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這個詞比較難解，在CMMI傳入之前，國內基本上不知道這個詞，國外也很少提到。對比下面這幾個詞匯，可以大致理解Process的含義。
大致指小規模的單一實踐，比如需求跟蹤矩陣、用例、序列圖、用戶故事、每日立會、自動化測試等。實踐的規模大小不一，有些實踐又是若干子實踐的集合，比如持續集成。
指若干實踐的集合，這一集合能解決某些領域的某些范圍的問題。
注意：以下的各種模型、方法論并不完全等同于過程，但這里抽取其呈現出來的過程側面。
CMMI中列出的內容大致相當于一家外包領域企業（尤其是為DOD提供外包開發的企業）所需的過程；它所涵蓋的范圍則是CMMI2級（需求管理、計劃、跟蹤……）、CMMI3級（需求開發，設計，測試……）等。
CMMI是迄今為止描述過程最完整的體系，它采用級別Level～過程域Process Area～實踐Practice的方式來完整描述自己的體系；還有一種不太為人熟知的方法，就是先分為工程/管理/支持/組織級改進四個域（具體名字忘了），然后再過程域～實踐三級。
從實用性的價值看，這種分類方法能讓我們理解其他過程能管理多大的范圍。
UML本身不是一種過程，但在使用UML的時候會使用到CMMI中提到的需求開發、設計、編碼三個過程域，還會用到用戶建模、部署這兩個CMMI沒怎么提的內容。
UML對于理解何為“Unified”非常有好處：UML把需求、設計、編碼三個環節聯合起來思考，一個環節的輸出，會變成下一個環節的輸入，環環相扣，從而大大節省了開發工作量。
這個特點在后面的AUP2描述中還會提到。
RUP的范圍包括（含英文縮寫的是與CMMI重合的部分，雖然不完全重合）：
商業建模，需求（RD需求開發），分析與設計（TS設計與現實），實現（TS設計與實現，學名叫“technical solution技術解決方案”），測試（VER驗證測試/VAL驗收），部署（VAL驗收），配置與變更管理（CM配置管理/ReqM需求管理），項目管理（PP項目計劃/PMC項目跟蹤），環境。
商業建模之所以在CMMI中不太重要，應該是因為CMMI應用與外包領域中的乙方，而這個過程則屬于甲方的職責。
環境是RUP的一個重點內容之一，目的是向軟件組織提供過程與工具的支撐。這正是Rational的業務所在。
RUP還潛移默化地定義了眾多角色，雖然從敏捷開發的角度看，這略微有點不“跨職能”，但從實踐的角度看，能讓團隊意識到存在某些復雜的工作需要有人承擔。
Scrum的主體內容也可以稱之為一個過程，應用于需求快速變化但又需要整體計劃的企業（這個定義適應面很大，因此才大受歡迎）。按CMMI的名詞定義，Scrum涵蓋了ReqM需求管理、PP項目計劃、PMC項目跟蹤與監控這三個過程域。
XP較少提到過程的內容，更像是互相關聯的一些實踐的松散集合，而XP發展的趨勢也是化整為零。按CMMI的名詞定義，極限編程覆蓋了RD需求開發、TS設計與實現、VER驗證與測試。
與其他過程相比，顯然Scrum/XP的覆蓋面相對少。
“這正是我們選擇敏捷開發的原因，因為它比較輕量級。”或許有人會說。但這個回答的理解有問題：輕量級和覆蓋面是兩個概念。無論采用什么開發過程，商業建模、績效考核、團隊發展這些內容都是企業必然會考慮的，一個覆蓋面過小且無法為自己不覆蓋的部分提供支持的過程，盡管降低了局部的管理難度，卻有可能反而會使公司的研發管理的總體成本變高。
典型的就是績效管理，由于敏捷開發未提供績效管理的模型，導致很多企業仍然采用傳統的績效管理方法（比如面向個人的績效考核，數代碼行，數缺陷數……），而這種管理方法又會反過來導致敏捷開發進行不下去。
在本人參與或了解的企業中，實施敏捷開發的主要阻力不是敏捷開發本身的實踐有多難，而是如何將敏捷開發與現有的組織結構和制度相適應，或如何改造現有的結構和制度以適合敏捷開發。
因此應該在敏捷開發的語境下擴展那些周邊的過程，以便為實施敏捷開發的大環境提供指導，以降低研發管理的總體成本。
其中一個有效的方法，就是建立以敏捷為指導思想的統一過程，以涵蓋敏捷之外的組織結構與制度，并使之與敏捷開發相匹配。
下一篇文章，將會大致提出一個框架，對UP進行分析，并對AUP2潛在的要覆蓋的范圍進行描述。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
