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

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

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

2，部分剛剛了解敏捷的人，尤其是團隊以上的管理者，認為“敏捷不怎么講過程規(guī)范，引入敏捷意味著冒較大的風險，為穩(wěn)妥計，暫時先不搞敏捷了吧”。

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

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

常常看到有些敏捷的材料中來比對經(jīng)驗主義的流程和已定義流程，說明在軟件開發(fā)中，當過程過于復雜時，經(jīng)驗主義方式是適合的選擇。但這里面存在混淆：已定義流程存在三種解釋：

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

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

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

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

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

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

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

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

? ? ? ? ? ? ? ? ? ? ? 圖一 ? 過程的三組平衡

說明：圖一 只是為形象的說明存在三組平衡，高低位置并不代表哪個更重要，尋找合適平衡點是關鍵。

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

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

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

?

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

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

?

參考文獻：

1，MartinFowler, 新方法學, 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é)

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

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