敏捷開發縱橫談

　　“敏捷”陷阱

　　小甲想到某開發公司應聘開發工程師，向該公司的某開發人員打聽他們的開發方式。

　　小甲：請問貴公司開發模式是怎樣的?

　　開發人員：咱們敏捷開發!不用寫文檔，寫好代碼就可以了。

　　小甲心想：哇，爽啊!趕緊去應聘!

　　小甲已經在該公司工作了數周，他覺得很郁悶：

　　無需求文檔，要做東西都是口頭分配的。

　　無計劃可言，想到啥就做啥。

　　加班不在話下，返工是家常便飯。

　　這就是敏捷開發嗎?

　　不少公司搞CMMI認證，推行過程改進，往往被開發人員嗤之以鼻，開發人員喜歡自由奔放有創造力的工作模式，喜歡敏捷!

　　然而很多號稱“敏捷”的公司，其實只是手工作坊的工作模式，想到啥就干啥，如果你是開發人員可能還會好一點，如果你是測試人員、實施人員，在這樣的公司你簡直會覺得無法溝通無法工作!

　　到底什么是敏捷呢?如何才不會跌入敏捷陷阱呢?

　　為什么會有“敏捷”這個說法?

　　大學時我們就被灌輸了這樣的知識：

　　生命周期模型有瀑布型、噴泉型、迭代型、螺旋型等。

　　一般來說，大型的、復雜的、對安全要求高的系統，應該采用傳統的瀑布型來開發，應采取重型過程。

　　對于中小型、需要快速投產的系統，應采用靈活的生命周期，采用敏捷的方式開發。

　　其實“敏捷”是相對于“重型”提出來的，重型開發有這樣的特點：(摘自互聯網)

　　1.刻板而嚴格控制。

　　2.很多活動和工件，官僚主義氣息濃重。

　　3.文檔繁多。

　　4.長期而詳細的計劃。

　　5.過程高于本質核心的工作。

　　6.面向過程而不是面向人，把人看成機械方法中的插件。

　　7.預見而不是適應。

　　于是我就很有疑問了，如果重型開發有這樣的特點，那么請問：對于大型的、復雜的、安全要求高的系統，也需要用具備上述特點的重型過程來開發嗎?如果是這樣，誰愿意在這樣的工作環境下工作?具備這樣特點的過程對項目成功有什么好處?

　　“重型”的重要特點是呆板，因為大家不喜歡呆板，喜歡靈活，所以提出了“敏捷”的說法!

　　我猜想：

　　1.重型過程其實是一些沒有實際項目經驗的理論家搞出來的產物。

　　2.重型過程的出發點純粹就是為了過程而過程。

　　當然上述論述純屬瞎猜，無法證實。

　　每個人對“重型”與“敏捷”的理解其實都不太一樣，這里我用一個問題來測試一下你：

　　我國的航天事業取得長足的發展，讓國人振奮，請問：你認為嫦娥工程采用的過程是重型的還是敏捷的?

　　這么重大的項目，很多人可能認為應該是重型過程，很多人可能認為敏捷的過程是不太嚴禁的過程，其實嫦娥工程是靈活而又十分嚴謹的工程。

　　大家有沒有留意到我們火箭發射時間是如何預報的?是不是具體說某天某時某刻發射?

　　不是!而是說某段時間內擇機發射!“擇機發射”是多么靈活、科學、嚴謹的發射計劃啊，完全與我們傳統的計劃想法不一樣，難道你能說這也是重型過程嗎?

　　所謂“重型”與“敏捷”其實都是相對的，我們沒有必要去爭論到底是“重型”還是“敏捷”。我們平時見到這么多“重型”“敏捷”的不同說法，其實大家都是各自從不同的標準出發。

　　下面我們將介紹常見的幾種敏捷開發，每種理念其實背后的道理是很類似的，我們沒有必要去爭論哪種方式更好，你完全可以吸取百家所長化為自己的理念，按照你的想法將項目做好。

　　極限編程

　　極限編程英文叫：Extreme Programming，簡稱叫XP，最開始我接觸到XP的說法時，還覺得是Windows XP的XP呢!

　　我第一次學習極限編程的最佳實踐時，讓我震撼不已，后來再工作中不斷體會，有了自己的見解。我將這些最佳實踐分為幾類：需求、設計、測試、編碼、項目管理。

　　需求方面的最佳實踐：

　　1.客戶故事：強調以客戶的語言來表達需求。

　　需求分析有很多科學系統的方法，采用這些系統方法有時候往往不如使用最原始的土方法，就是用客戶的陳述來表達需求!

　　極限編程認為，客戶不能清晰認識自己想要什么是很正常的事情，項目組也沒有必要成為業務專家，所以通過這兩個最佳實踐讓客戶來引導項目。項目的開發工作講究短平快，系統會分為多個小版本發布，客戶經過多個版本發布會逐步清楚認識到自己想要什么。

　　這個最佳實踐鑒于我國的情況，其實是很難執行的。我們的項目一般合同價錢是簽死的，項目時間也是死的，基本都沒有機會讓我們來回折騰，如果我們不能在項目初期精準地分析出客戶真正的需求，項目失敗的機會是非常高的。

　　我在實際工作中往往會通過用戶故事來獲取原始需求，然后對這些用戶故事進行提煉，提煉后的需求再跟客戶確認。我認為項目組還是很有必要成為業務專家，項目組中還是很需要有需求分析方面的高手，項目經不起折騰啊!

　　2.客戶全程參與：強調從項目一開始到最后，客戶應該與項目緊密聯系，發揮更大的作用。

　　這個實踐在實際工作中應該很好地貫徹，不要僅在需求階段才讓客戶介入，客戶最好就能常駐在項目小組內。下面有一些讓客戶多參與的建議做法：

　　1)需求階段要與各用戶反復確認需求。

　　2)系統做出界面時馬上讓客戶看看。

　　3)項目計劃要讓客戶知道。

　　4)每周向客戶發送項目進展報告。

　　5)讓客戶參與測試軟件。

　　設計方面的最佳實踐只有一條：

　　1.簡單設計：不用長遠考慮，只要設計能保證當前功能可以實現就行。

　　軟件開發的可謂千變萬化，能將功能做出來的最簡單設計就是最好的設計，你不需要考慮以后發生變化還能重用這些設計和代碼，明天的事情鬼知道，搞定今天的事情就可以了!

原文轉自：http://www.cnblogs.com/umlonline/archive/2010/03/17/1687760.html