前兩天，在一次聊天中，我問了問未來開發(fā)組的組長：眼看設(shè)計過程就要結(jié)束了，項目啟動到現(xiàn)在進行了3個月的時間，想一想，前一階段我們所做的工作中，有百 分之多少是對后面的工作有意義的？開發(fā)組長無奈的苦笑了一下。顯然大家心里面都有數(shù)，這個比例很不理想。尤其是設(shè)計文檔中的模塊設(shè)計部分，大量的工作量， 完全是為了設(shè)計文檔能夠評審通過。

對于敏捷軟件開發(fā)，目前理解其最重要的目的是識別軟件過程中沒有必要的任務或者是性能低下的任務，然后去除之或者改進之。基于這個出發(fā)點回顧一下目前的情況：

需求分析。***不變的就是變化。項目的早期集中時間進行需求分析然后確認基線，再等到真正動手開發(fā)某一模塊的時候可能已經(jīng)過去了一段時間，并且需求已經(jīng)發(fā)生了變化。這樣還需要對新的需求進行再次分析。在這樣的情況下，前后的需求分析則存在工作量的浪費。

敏捷過程則是需求分析存在與整個項目的始終。細節(jié)的需求分析工作盡在真正開始代碼之前才進行。雖然以后仍然有可能發(fā)生變化，但起碼針對上面的情況做了優(yōu)化。

軟件設(shè)計。目前的項目，設(shè)計階段需要的交付物有：架構(gòu)設(shè)計，概要設(shè)計，詳細設(shè)計，物理模型設(shè)計，接口設(shè)計等等。設(shè)計的目的當然是為了能夠知道開發(fā)。這一部分工作顯然是必須的，但是能否優(yōu)化呢？

敏捷過程典型的對策是

1.僅僅做足夠的設(shè)計；

2.測試驅(qū)動開發(fā)。

系統(tǒng)的架構(gòu)設(shè)計是需要的。但是針對某一功能來講，僅僅在開發(fā)之前才做相應的詳細設(shè)計。設(shè)計僅僅做到能夠指導開發(fā)的程度，對文檔的格式要求比較寬松。

傳統(tǒng)的UML設(shè)計包括類圖、順序圖、協(xié)作圖、活動圖、狀態(tài)圖等等。這個敏捷過程一般沒有強制要求。XP過程中推薦以TDD和CRC分析來代替。其中CRC分 析基本上是UML協(xié)作圖的替代物，但是更加強調(diào)團隊共同完成。而TDD則是在保證了測試自動化的同時還能夠?qū)浖O(shè)計進行指導，做一件事達到兩個效果，體現(xiàn)其高效率。

界面原型。我前面說過，希望能夠在需求分析階段就能夠?qū)ο到y(tǒng)的界面進行確認，還找了一些專業(yè)做頁面原 型的輔助工具。現(xiàn)在看來，其實也存在浪費。其實更高效的做法是以最快的速度拿出開發(fā)出的成品或者半成品讓用戶進行確認（這樣一來，***的問題是你能有多 快？;-) ）。界面草圖有的時候是需要的，但是它變成了非常不正式的中間產(chǎn)物，不必要進行存檔。

重構(gòu)。仔細想想，其實重構(gòu)的工作對于任何一個項目來講都是必須的。而現(xiàn)實是，如果沒有采取全面的自動化測試的話，傳統(tǒng)的軟件開發(fā)項目沒有能力也不敢進行深度的重構(gòu)。而相反基于TDD的XP團隊則更有勇氣對軟件進行徹底重構(gòu)。

集成。集成的工作量無法節(jié)省。敏捷過程的做法是持續(xù)集成——將工作量分散到整個軟件生命周期。這樣能夠及時發(fā)現(xiàn)問題，并從感受上減少工作量。

我有一個朋友，看他上網(wǎng)打橋牌的時候，經(jīng)常發(fā)現(xiàn)他的搭檔在抱怨他發(fā)生了失誤。而實際的情況是怎么樣的呢？我的朋友是全國***橋牌賽事的前四名獲得者。那些被抱怨失誤的牌都是由于他的搭檔的水平不夠，對于他的精妙招數(shù)無法理解。

在軟件開發(fā)領(lǐng)域，其實我們也正在處于我的朋友的搭檔的水平。經(jīng)歷的項目越多，越會發(fā)現(xiàn)業(yè)內(nèi)大師的很多理論的精妙之處。很多情況是：如果大師們的理論你認為有很大問題的話，其實是因為你的層次還不夠。

【編輯推薦】

1. 專題：初探敏捷開發(fā)
2. 不一樣的敏捷開發(fā)實踐
3. 全面認識敏捷建模思想