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

對于敏捷軟件開發(fā)，目前理解其最重要的目的是識別軟件過程中沒有必要的任務(wù)或者是性能低下的任務(wù)，然后去除之或者改進之?；谶@個出發(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ā)之前才做相應(yīng)的詳細設(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è)做頁面原 型的輔助工具?，F(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. 全面認識敏捷建模思想