第1 章 從傳統(tǒng)向敏捷軟件開發(fā)的演進(jìn)

　　在產(chǎn)品開發(fā)中，“敏捷”和“精益”這一對熱詞如影隨形。精益產(chǎn)品開發(fā)離不開對敏捷軟件開發(fā)的深入理解，所以我們的精益之旅也將從敏捷軟件開發(fā)開始。本章講述軟件開發(fā)從傳統(tǒng)進(jìn)化到敏捷背后的業(yè)務(wù)動因以及敏捷軟件開發(fā)實(shí)踐體系。

　　傳統(tǒng)軟件開發(fā)方式面臨的挑戰(zhàn)

　　傳統(tǒng)軟件開發(fā)方法是與軟件工程的概念一同誕生的（圖1-1）。1968 年，北約（NATO）召開全球第一屆以“軟件工程”命名的會議，這次會議通常被視為軟件工程誕生的標(biāo)志。會議上提出了“軟件危機(jī)”的概念。隨著軟件復(fù)雜度的不斷提高，軟件項(xiàng)目普遍出現(xiàn)預(yù)算超支、質(zhì)量低、性能差、不符合實(shí)際需求和延期等問題，造成所謂的“軟件危機(jī)”。

　　圖1-1　傳統(tǒng)開發(fā)方法的產(chǎn)生歷程

　　當(dāng)時，業(yè)界普遍認(rèn)為，軟件行業(yè)應(yīng)該借鑒工程領(lǐng)域的經(jīng)驗(yàn)，“系統(tǒng)地應(yīng)用工程管理方法”，以此來應(yīng)對軟件危機(jī)。這是軟件工程誕生的背景，在這一思路下產(chǎn)生的軟件開發(fā)方法就是傳統(tǒng)軟件開發(fā)方法。它們共同的特點(diǎn)是強(qiáng)調(diào)計(jì)劃、管控和結(jié)構(gòu)化的工程方法，并遵循嚴(yán)格的生命周期概念，把軟件開發(fā)分割為順序階段構(gòu)成的過程，瀑布式開發(fā)方法是其中的代表之一。

　　相比作坊式的開發(fā)，傳統(tǒng)方法開發(fā)方法進(jìn)步明顯。它讓產(chǎn)品開發(fā)有矩可循，讓項(xiàng)目和產(chǎn)品的成功可以重復(fù)，讓組織的能力可以被評估，這些當(dāng)然是好的。圖1-1 是傳統(tǒng)開發(fā)方法的大致發(fā)展歷程，到了上世紀(jì)90 年代初，CMMI 和PMI 項(xiàng)目管理知識體系[1] 成為傳統(tǒng)產(chǎn)品開發(fā)管理方法的典型代表。

　　然而，傳統(tǒng)方法并沒有從根本上解決軟件危機(jī)，軟件項(xiàng)目的失敗率依然居高不下，甚至越來越糟糕。在這方面被引用得最多的是Standish Group 定期發(fā)布的IT 項(xiàng)目報(bào)告[2]，該報(bào)告在1994 年第一次發(fā)布時的數(shù)據(jù)顯示，項(xiàng)目成功比例只有16%，有31% 在發(fā)布前就被“砍掉”，剩下的53% 平均超出了預(yù)算189%。

　　人們認(rèn)識到，遵循嚴(yán)格生命周期的概念，把開發(fā)分割為順序階段構(gòu)成的過程，實(shí)施起來不現(xiàn)實(shí)，造成了以下直接的危害。

　　�6�1 希望通過對各個階段設(shè)置關(guān)卡，嚴(yán)格控制，以期更早地發(fā)現(xiàn)問題，卻滯后了集成和測試，讓錯誤的發(fā)現(xiàn)延遲到最后，這是很多項(xiàng)目失敗的根源。

　　�6�1 希望一開始就能設(shè)定完整和正確的需求，這對軟件產(chǎn)品越來越不可能，因?yàn)橛脩粢膊恢�道或說不清楚自己想要什么。事實(shí)上，對需求的挖掘和理解，應(yīng)該是一個持續(xù)的過程，需要不斷的反饋。

　　�6�1 把成功定義為“遵循最初的計(jì)劃和范圍”。為了確保項(xiàng)目的“成功”而避免或拒絕進(jìn)行合理的變更，卻忽略了“達(dá)成商業(yè)目標(biāo)才是真正的成功”。這已經(jīng)成為業(yè)務(wù)成功的一個嚴(yán)重障礙。

　　另一方面，傳統(tǒng)產(chǎn)品開發(fā)方法強(qiáng)調(diào)控制，所以一旦流程出現(xiàn)問題，自然的應(yīng)對就是進(jìn)一步加強(qiáng)管控，流程本身有自我復(fù)雜化的趨勢，反而會壓制關(guān)鍵軟件開發(fā)人員的主觀能動性。

　　面對以上問題，對傳統(tǒng)軟件開發(fā)方法的反思，幾乎與其本身一樣悠久。比如，瀑布模型的提出者Wiston Royce 1970 年在他的論文[3] 中，只是把瀑布模型作為一個理論模型提出，并警告人們它絕對不適合用來進(jìn)行大型軟件開發(fā)。在論文的后半部分，Royce 提出了一個包含原型和各階段之間反饋的修正模型。遺憾的是，業(yè)界當(dāng)時渴望的是一種建構(gòu)式工程方法，瀑布模型迎合了這一要求，導(dǎo)致反對瀑布模型的Royce 反倒被業(yè)界稱為“瀑布模型之父”。至于Royce 的忠告，也只有等到30 年后敏捷運(yùn)動興起時才又被人們重新提起。

　　從傳統(tǒng)到敏捷

　　面對傳統(tǒng)軟件工程方法的現(xiàn)實(shí)問題，一批輕量級的軟件開發(fā)方法陸續(xù)涌現(xiàn)（圖1-2），它們共同的特點(diǎn)是遵循演進(jìn)和迭代的模型。其中，上世紀(jì)90 年代出現(xiàn)的Scrum 和極限編程在實(shí)踐上最為成功，它們都是迭代和增量的軟件開發(fā)框架。兩者的區(qū)別是，Scrum只包含管理實(shí)踐，而極限編程同時涵蓋工程和管理實(shí)踐。

　　圖1-2　敏捷產(chǎn)生和發(fā)展的歷程

　　上世紀(jì)90 年代，另一個主要變化是PC 軟件流行和第四代編程語言的出現(xiàn)，面向?qū)ο蠛驮O(shè)計(jì)模式運(yùn)動的興起，使小型開發(fā)項(xiàng)目蓬勃發(fā)展，同時互聯(lián)網(wǎng)應(yīng)用和開源社區(qū)也在此時興起，有別于傳統(tǒng)的開發(fā)模式不斷涌現(xiàn)，優(yōu)秀個人在程序開發(fā)中的作用越來越明顯。

　　這些因素都讓非傳統(tǒng)開發(fā)方法有了實(shí)驗(yàn)的土壤。其結(jié)果是，一方面質(zhì)量問題層出不窮，促使源自全面質(zhì)量管理體系的CMM/CMMI 在這一時間迅速繁榮和推廣；另一方面也產(chǎn)生了許多不同于傳統(tǒng)方法的有效實(shí)踐，讓業(yè)界看到新的可能。敏捷運(yùn)動這時呼之欲出，它既是對傳統(tǒng)的反叛，也是對野蠻生長的規(guī)范。

　　2001 年2 月，17 位輕量級軟件工程方法的代表人物齊聚美國猶他州的雪鳥滑雪勝地，在兩天的會議之后，發(fā)布了對后來產(chǎn)生巨大影響的《敏捷軟件開發(fā)宣言》[4]，如圖1-3所示，敏捷宣言陳述了他們共同認(rèn)可的軟件開發(fā)方法理念，同樣重要的是，他們找到“敏捷”這個詞來總領(lǐng)這些理念。

　　敏捷概念在2001 年出現(xiàn)，可謂適逢其時。當(dāng)時一方面，傳統(tǒng)方法變得越來越臃腫笨重，卻沒有解決軟件危機(jī)；另一方面，人類正在進(jìn)入互聯(lián)網(wǎng)時代，軟件業(yè)對響應(yīng)變化和創(chuàng)新的要求迅速升級，這是更根本的原因，畢竟需求才是行業(yè)發(fā)展最好的助推劑。很快，敏捷成為一場運(yùn)動，被迅速推廣和應(yīng)用。

　　圖1-3　《敏捷軟件開發(fā)宣言》

　　理解敏捷必須回歸業(yè)務(wù)視角

　　《敏捷宣言》屬于價值觀層面的宣導(dǎo)，對敏捷的推廣和公眾的認(rèn)知起到了很大的作用。但對于敏捷是什么，卻從來沒有統(tǒng)一的定義。2010 年，軟件工程大師Ivar Jacobson 在一篇博文中這樣說：“過去你問我支不支持敏捷，我會說哪些支持，哪些不支持，并給出我的理由。但現(xiàn)在你再問，我就只能回答支持。因?yàn)椋�如今敏捷的意思已�?jīng)演變成“軟件開發(fā)中一切好的東西（Everything good about software development）。”Ivar 一語道破了真相。如圖1-4 所示，敏捷成了一個集合性的概念，一切好的，都?xì)w入敏捷，而一切失敗，都?xì)w于不敏捷。這在商業(yè)上或許不錯，卻不利于概念的明晰和有效實(shí)施。

　　畢竟，要真正理解敏捷，還是要回歸業(yè)務(wù)目標(biāo)。產(chǎn)品開發(fā)的最終目標(biāo)是業(yè)務(wù)成功，這是沒有異議的。接下來我們將從目標(biāo)出發(fā)，理解敏捷的意義所在，并以此來指導(dǎo)我們具體落實(shí)敏捷實(shí)踐。

　　圖1-4　霧里看花，敏捷是一個集合性名詞