本文是《敏捷熱點(diǎn)問(wèn)題的多角度雜議》（首次刊發(fā)在程序員雜志2011年9月刊）的一部分，為方便討論，在這里獨(dú)立成文。

敏捷軟件開(kāi)發(fā)宣言的第一個(gè)價(jià)值觀指出“個(gè)體和互動(dòng) 高于流程和工具”。“流程”對(duì)應(yīng)的英文是“Process”，在有些地方也譯為“過(guò)程”，下文中“流程”和“過(guò)程”為同義詞。由于敏捷宣言和原則總共篇幅不長(zhǎng)，并沒(méi)有完全說(shuō)明其中問(wèn)題，導(dǎo)致了如下有趣又矛盾的現(xiàn)象：

1，部分敏捷的執(zhí)行者抱怨以Scrum為代表的敏捷流程比較生硬，讓員工都是那一副副苦逼的臉，一些團(tuán)隊(duì)依然察覺(jué)到許多刻板、教條之處，比如站會(huì)，Sprint的干擾，一旦聽(tīng)到ScrumMaster或團(tuán)隊(duì)試圖“照著書(shū)本做Scrum”，就會(huì)為自己敲響警鐘。

2，部分剛剛了解敏捷的人，尤其是團(tuán)隊(duì)以上的管理者，認(rèn)為“敏捷不怎么講過(guò)程規(guī)范，引入敏捷意味著冒較大的風(fēng)險(xiǎn)，為穩(wěn)妥計(jì)，暫時(shí)先不搞敏捷了吧”。

敏捷軟件開(kāi)發(fā)宣言是在軟件工程基礎(chǔ)上提出來(lái)的，出發(fā)點(diǎn)所比對(duì)的是以瀑布型生命周期為核心的傳統(tǒng)軟件工程。Martin Flower把傳統(tǒng)軟件工程方法稱(chēng)為重型方法，敏捷為輕型方法。可以合理的推斷敏捷宣言的意思是在傳統(tǒng)軟件工程已經(jīng)得到了過(guò)程和工具的情況下，個(gè)體和互動(dòng)更重要，并不是沒(méi)有過(guò)程和工具，這點(diǎn)在Martin Flower的《新方法學(xué)》一文中也得到了表述。如果不站在軟件工程基礎(chǔ)上來(lái)采納敏捷，那么很容易淪為軟件作坊，其實(shí)這是違背敏捷的。

敏捷中給予軟件開(kāi)發(fā)團(tuán)隊(duì)最直接、最易操作的指導(dǎo)恰恰是在流程上，比如XP中的持續(xù)集成、TDD、重構(gòu)等共12個(gè)實(shí)踐，Scrum中的4種會(huì)議，FDD的5個(gè)流程等等。分析這些流程，與及傳統(tǒng)軟件工程的流程，可以發(fā)現(xiàn)：敏捷把其中沒(méi)價(jià)值的部分大大弱化了，有些甚至是取消了，比如中間文檔里程碑評(píng)審、狀態(tài)報(bào)告、需求矩陣等等；而對(duì)其中有價(jià)值的部分，敏捷卻是大大加強(qiáng)了，有些甚至鼓勵(lì)追求極限，比如迭代開(kāi)發(fā)、結(jié)對(duì)編程、代碼規(guī)范、TDD等，而且有些敏捷流派還強(qiáng)調(diào)紀(jì)律。

常常看到有些敏捷的材料中來(lái)比對(duì)經(jīng)驗(yàn)主義的流程和已定義流程，說(shuō)明在軟件開(kāi)發(fā)中，當(dāng)過(guò)程過(guò)于復(fù)雜時(shí)，經(jīng)驗(yàn)主義方式是適合的選擇。但這里面存在混淆：已定義流程存在三種解釋：

1.????????第1種是在Cockburn的《敏捷軟件開(kāi)發(fā)》第2版中，“理論的或者已定義的過(guò)程是一個(gè)理解得足夠好可以自動(dòng)化的過(guò)程（這個(gè)定義與CMMI對(duì)‘已定義的’一詞的定義完全不同）。經(jīng)驗(yàn)主義的過(guò)程需要人的檢查和干預(yù)”；

2.????????第2種是在CMMI中，“已定義過(guò)程”的解釋是“根據(jù)組織裁剪指南從組織標(biāo)準(zhǔn)過(guò)程集中裁剪得到的已管理過(guò)程，有得到維護(hù)的過(guò)程描述，為組織過(guò)程資產(chǎn)提供過(guò)程相關(guān)的經(jīng)驗(yàn)”；

3.????????第3種是字面意思，形成描述的過(guò)程是已定義流程。

顯然，與經(jīng)驗(yàn)主義流程比對(duì)的已定義流程采用的是第1種解釋。在這種解釋下，軟件開(kāi)發(fā)中的已定義過(guò)程是很少的，典型的有持續(xù)集成、每日集成、靜態(tài)代碼檢查等，絕大多數(shù)過(guò)程需要人的檢查和干預(yù)，無(wú)論是傳統(tǒng)的需求分析、OOAD等，還是敏捷推薦的TDD、結(jié)對(duì)編程等等。所以經(jīng)驗(yàn)主義的過(guò)程并不是不要描述，需要而且必須要一定形式的描述。停留在個(gè)別團(tuán)隊(duì)成員頭腦里的經(jīng)驗(yàn)主義的流程是無(wú)法討論傳播的，而只要說(shuō)出來(lái)，哪怕沒(méi)有寫(xiě)下來(lái)，這個(gè)流程就已經(jīng)得到了描述。“只可意會(huì)、不可言傳”的東西是佛學(xué)考慮的問(wèn)題，不是軟件開(kāi)發(fā)考慮的問(wèn)題。不了解上下文的朋友會(huì)很自然的采用第3種解釋，那么極可能會(huì)誤以為敏捷不需要過(guò)程描述。

因此這里真正的問(wèn)題在于流程描述的顆粒度不同。口頭表達(dá)的流程往往是顆粒度最大的，也是最不穩(wěn)定的，而傳統(tǒng)軟件工程中包括進(jìn)入-任務(wù)步驟-確認(rèn)-退出（ETVX范式）再加上詳盡文檔模板+評(píng)審+度量等的流程提供了很細(xì)的顆粒度，被MartinFlower等稱(chēng)為“繁瑣滯重”。細(xì)粒度的過(guò)程有更好的指導(dǎo)性，但顯得繁瑣呆板，粗粒度的過(guò)程往往是抓住關(guān)鍵，但對(duì)細(xì)節(jié)往往指導(dǎo)不夠。按照剛剛好（Just enough）的原則，敏捷類(lèi)流程描述傾向于剛剛好的粗顆粒度，整體上要講究平衡。

得到描述的流程能夠處理大多數(shù)情況，一般的顆粒度粗的流程適用性更寬些，但無(wú)論如何是不可能把所有未來(lái)流程執(zhí)行時(shí)碰到的情況都說(shuō)明，所以就存在如何遵循流程的問(wèn)題。顯然的在道理上，碰到新情況不能死硬的遵循流程，碰到老情況也不能肆意的破壞流程。雖然恪守約束，避免整個(gè)流程體系走向混亂是很好的，但過(guò)于教條以至于無(wú)視實(shí)際情況同樣不利于項(xiàng)目和團(tuán)隊(duì)。 根據(jù)精益的理念，筆者主張：“過(guò)程中發(fā)現(xiàn)浪費(fèi)并積極消除重于遵守既定教條”。流程的嚴(yán)格程度要根據(jù)團(tuán)隊(duì)和團(tuán)隊(duì)碰到的實(shí)際情況來(lái)處理，不要忘記敏捷宣言的第1條價(jià)值觀：“個(gè)體和互動(dòng)高于 流程和工具”。

在流程方面還有一個(gè)問(wèn)題，就是流程的定義和執(zhí)行不完全是項(xiàng)目團(tuán)隊(duì)級(jí)的事情，就算是最尊重團(tuán)隊(duì)決策、已經(jīng)采納敏捷的組織也會(huì)倡導(dǎo)團(tuán)隊(duì)之間的經(jīng)驗(yàn)分享，而有些組織就會(huì)直接要求團(tuán)隊(duì)采納其它團(tuán)隊(duì)獲得的流程，這些流程在不同組織有不同說(shuō)法，比如有效實(shí)踐、最佳實(shí)踐、規(guī)范、規(guī)程、經(jīng)驗(yàn)分享、知識(shí)共享等等。這里筆者提議“組織整體協(xié)同并重于團(tuán)隊(duì)自身提高”。

把流程發(fā)揮最大作用，必須處理好如圖三所示的三對(duì)平衡：

? ? ? ? ? ? ? ? ? ? ? 圖一 ? 過(guò)程的三組平衡

說(shuō)明：圖一 只是為形象的說(shuō)明存在三組平衡，高低位置并不代表哪個(gè)更重要，尋找合適平衡點(diǎn)是關(guān)鍵。

從Scrum看，Scrum本身給出的過(guò)程略偏向于細(xì)顆粒度，比如站會(huì)、燃盡圖等，而圍繞著Scrum的不少培訓(xùn)材料和文章對(duì)計(jì)劃會(huì)、反思、評(píng)審會(huì)等給了很多指導(dǎo)，感覺(jué)更加偏向于細(xì)顆粒度。在Scrum的咨詢(xún)、培訓(xùn)和文章中，一般要求遵循Scrum給定的過(guò)程，對(duì)裁剪Scrum中的元素要慎重，盡量不要裁剪。KenSchwaber對(duì)此的描述是，“對(duì)Scrum規(guī)則的修改，只有在ScrumMaster確信團(tuán)隊(duì)足夠深入的掌握了Scrum的運(yùn)行原理，有足夠的技能和思維來(lái)修改規(guī)則時(shí)才可以進(jìn)行”。Sprint計(jì)劃會(huì)上制定的計(jì)劃通常被假定為某種承諾，作為承諾往往意味著務(wù)必要完成。在2011年7月發(fā)布的最新scrum指南中，澄清那不是承諾，而是可以完成工作的預(yù)測(cè)，而且這個(gè)預(yù)測(cè)會(huì)在Sprint過(guò)程中因?yàn)楦嘈畔⒍淖儭９P者認(rèn)為這個(gè)澄清非常好。承諾并不能準(zhǔn)確預(yù)測(cè)未來(lái)發(fā)展，但卻要求（甚至于是壓迫）開(kāi)發(fā)人員必須在限定時(shí)間內(nèi)完成某些任務(wù)。澄清為預(yù)測(cè)后，相對(duì)容易改變，執(zhí)行起來(lái)不再那么生硬。

從CMMI看，CMMI本身對(duì)各個(gè)過(guò)程域給出了目標(biāo)、實(shí)踐和子實(shí)踐，看起來(lái)顆粒度上偏向于細(xì)，而且CMMI覆蓋的過(guò)程范圍比幾個(gè)常見(jiàn)敏捷軟件開(kāi)發(fā)流派覆蓋的范圍要大，所以整體上顯得也細(xì)。對(duì)待裁剪，CMMI在滿(mǎn)足目標(biāo)的情況下是允許并鼓勵(lì)的，CMMI全部目標(biāo)的累計(jì)字?jǐn)?shù)與敏捷宣言+原則的字?jǐn)?shù)在同一個(gè)數(shù)量級(jí)上，偏向于粗粒度的敏捷類(lèi)過(guò)程描述也是能夠符合CMMI要求的。

XP給出了12個(gè)實(shí)踐，比較強(qiáng)調(diào)紀(jì)律，而水晶方法系列探索了用最少紀(jì)律約束而仍能成功的方法，從而在產(chǎn)出效率與易于運(yùn)作上達(dá)到一種平衡。

?

1.????? 結(jié)束語(yǔ)

???敏捷宣言和原則及主要的敏捷流派指出了優(yōu)化的方向。根據(jù)實(shí)際情況進(jìn)行適配，把握恰當(dāng)?shù)钠胶?#xff0c;同時(shí)保持對(duì)優(yōu)化方向的追求，保持在"ing"---進(jìn)行中，持續(xù)發(fā)現(xiàn)不足并提升，這就滿(mǎn)足了敏捷軟件開(kāi)發(fā)宣言和原則。平衡、適配是本文強(qiáng)調(diào)的關(guān)鍵詞。

?

參考文獻(xiàn)：

1，MartinFowler, 新方法學(xué), http://www.uml.org.cn/SoftWareProcess/rjgc.12052003.htm

2，Vikas Hazrati, Scrum到底有多教條？, http://www.infoq.com/cn/news/2011/08/rigid-scrum?

3，Pete Deemer,經(jīng)理2.0：Scrum中經(jīng)理的角色,

?????????????????????????http://www.infoq.com/cn/articles/scrum-management-deemer?

4，JeffSutherland, Ken Schwaber,Scrum Update:&2011,

??????????????????????????http://www.scrum.org/storage/Scrum%20Update%202011.pdf

總結(jié)

以上是生活随笔為你收集整理的”过程”在敏捷开发中的位置的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。