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

涉縣ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！

敏捷統(tǒng)一過程的全稱是AUP（Agile Unified Process），不過為了能區(qū)別已經(jīng)被提過一次的AUP（就是RUP），這里稱之為AUP2。

這個系列會探討如何在一家企業(yè)完整實施敏捷開發(fā)過程。在以往業(yè)界的討論中，多數(shù)時候?qū)⒃掝}集中在如何在一個小范圍的團隊中實施敏捷，比如Scrum本身的框架僅限于4～7人的團隊如何做需求管理+計劃管理+任務(wù)管理的；即使引入了Scrum of Scrums，其范圍雖然擴大到幾十人乃至上百人，但管理內(nèi)容仍僅限于這三個環(huán)節(jié)。

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

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

1. 為什么我們使用了敏捷開發(fā)，但產(chǎn)品并沒有成功？（與產(chǎn)品定位的接口，Nokiaer應(yīng)該經(jīng)常問這個問題）

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

3. 用戶故事和用例我們應(yīng)該寫哪個？（與設(shè)計方法的接口，若已經(jīng)實施了UML、面向?qū)ο?、MVC、用戶建模……等等一系列技術(shù)方法，問題會很尖銳）

4. 我們想同時使用Scrum和持續(xù)集成、自動化測試，他們之間有何關(guān)系？

5. 公司負(fù)責(zé)過程的質(zhì)量部門在敏捷開發(fā)中扮演什么角色？

……

很多企業(yè)可能連問這些問題的機會都沒有，因為他們發(fā)現(xiàn)“敏捷開發(fā)并沒有想象中那么容易推廣”，于是中途就放棄了。

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

AUP2的實踐環(huán)節(jié)不是普適的，隨著時間的變化也不是一成不變的。它只是提供了一個思路：在任何情況下，我們都應(yīng)該統(tǒng)一地看待企業(yè)所采納的過程、技術(shù)、組織架構(gòu)……等內(nèi)容，以期達到最低的擁有價值。

Process過程

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

Practice實踐

大致指小規(guī)模的單一實踐，比如需求跟蹤矩陣、用例、序列圖、用戶故事、每日立會、自動化測試等。實踐的規(guī)模大小不一，有些實踐又是若干子實踐的集合，比如持續(xù)集成。

Process過程

指若干實踐的集合，這一集合能解決某些領(lǐng)域的某些范圍的問題。

注意：以下的各種模型、方法論并不完全等同于過程，但這里抽取其呈現(xiàn)出來的過程側(cè)面。

CMMI

CMMI中列出的內(nèi)容大致相當(dāng)于一家外包領(lǐng)域企業(yè)（尤其是為DOD提供外包開發(fā)的企業(yè)）所需的過程；它所涵蓋的范圍則是CMMI2級（需求管理、計劃、跟蹤……）、CMMI3級（需求開發(fā)，設(shè)計，測試……）等。

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

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

UML

UML本身不是一種過程，但在使用UML的時候會使用到CMMI中提到的需求開發(fā)、設(shè)計、編碼三個過程域，還會用到用戶建模、部署這兩個CMMI沒怎么提的內(nèi)容。

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

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

RUP（Rational Unified Process）

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

商業(yè)建模，需求（RD需求開發(fā)），分析與設(shè)計（TS設(shè)計與現(xiàn)實），實現(xiàn)（TS設(shè)計與實現(xiàn)，學(xué)名叫“technical solution技術(shù)解決方案”），測試（VER驗證測試/VAL驗收），部署（VAL驗收），配置與變更管理（CM配置管理/ReqM需求管理），項目管理（PP項目計劃/PMC項目跟蹤），環(huán)境。

商業(yè)建模之所以在CMMI中不太重要，應(yīng)該是因為CMMI應(yīng)用與外包領(lǐng)域中的乙方，而這個過程則屬于甲方的職責(zé)。

環(huán)境是RUP的一個重點內(nèi)容之一，目的是向軟件組織提供過程與工具的支撐。這正是Rational的業(yè)務(wù)所在。

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

Scrum/XP

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

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

敏捷開發(fā)過程的局限性

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

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

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

在本人參與或了解的企業(yè)中，實施敏捷開發(fā)的主要阻力不是敏捷開發(fā)本身的實踐有多難，而是如何將敏捷開發(fā)與現(xiàn)有的組織結(jié)構(gòu)和制度相適應(yīng)，或如何改造現(xiàn)有的結(jié)構(gòu)和制度以適合敏捷開發(fā)。

因此應(yīng)該在敏捷開發(fā)的語境下擴展那些周邊的過程，以便為實施敏捷開發(fā)的大環(huán)境提供指導(dǎo)，以降低研發(fā)管理的總體成本。

其中一個有效的方法，就是建立以敏捷為指導(dǎo)思想的統(tǒng)一過程，以涵蓋敏捷之外的組織結(jié)構(gòu)與制度，并使之與敏捷開發(fā)相匹配。

 

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

當(dāng)前題目：AUP2敏捷統(tǒng)一過程之一：序言及降低過程的總體擁有成本
當(dāng)前網(wǎng)址：http://m.rwnh.cn/article18/jippdp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、網(wǎng)站排名、關(guān)鍵詞優(yōu)化、動態(tài)網(wǎng)站、網(wǎng)站維護、軟件開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)