第1章 從傳統向敏捷軟件開發的演進

在產品開發中，“敏捷”和“精益”這一對熱詞如影隨形。精益產品開發離不開對敏捷軟件開發的深入理解，所以我們的精益之旅也將從敏捷軟件開發開始。本章講述軟件開發從傳統進化到敏捷背后的業務動因以及敏捷軟件開發實踐體系。

傳統軟件開發方式面臨的挑戰

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

當時，業界普遍認為，軟件行業應該借鑒工程領域的經驗，“系統地應用工程管理方法”，以此來應對軟件危機。這是軟件工程誕生的背景，在這一思路下產生的軟件開發方法就是傳統軟件開發方法。它們共同的特點是強調計劃、管控和結構化的工程方法，并遵循嚴格的生命周期概念，把軟件開發分割為順序階段構成的過程，瀑布式開發方法是其中的代表之一。

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

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

人們認識到，遵循嚴格生命周期的概念，把開發分割為順序階段構成的過程，實施起來不現實，造成了以下直接的危害。

? 希望通過對各個階段設置關卡，嚴格控制，以期更早地發現問題，卻滯后了集成和測試，讓錯誤的發現延遲到最后，這是很多項目失敗的根源。

? 希望一開始就能設定完整和正確的需求，這對軟件產品越來越不可能，因為用戶也不知道或說不清楚自己想要什么。事實上，對需求的挖掘和理解，應該是一個持續的過程，需要不斷的反饋。

? 把成功定義為“遵循最初的計劃和范圍”。為了確保項目的“成功”而避免或拒絕進行合理的變更，卻忽略了“達成商業目標才是真正的成功”。這已經成為業務成功的一個嚴重障礙。

另一方面，傳統產品開發方法強調控制，所以一旦流程出現問題，自然的應對就是進一步加強管控，流程本身有自我復雜化的趨勢，反而會壓制關鍵軟件開發人員的主觀能動性。

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

從傳統到敏捷

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

上世紀90年代，另一個主要變化是PC軟件流行和第四代編程語言的出現，面向對象和設計模式運動的興起，使小型開發項目蓬勃發展，同時互聯網應用和開源社區也在此時興起，有別于傳統的開發模式不斷涌現，優秀個人在程序開發中的作用越來越明顯。

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

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

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

理解敏捷必須回歸業務視角

《敏捷宣言》屬于價值觀層面的宣導，對敏捷的推廣和公眾的認知起到了很大的作用。但對于敏捷是什么，卻從來沒有統一的定義。2010年，軟件工程大師Ivar Jacobson在一篇博文中這樣說：“過去你問我支不支持敏捷，我會說哪些支持，哪些不支持，并給出我的理由。但現在你再問，我就只能回答支持。因為，如今敏捷的意思已經演變成“軟件開發中一切好的東西（Everything good about software development）。”

Ivar一語道破了真相。如圖1-4所示，敏捷成了一個集合性的概念，一切好的，都歸入敏捷，而一切失敗，都歸于不敏捷。這在商業上或許不錯，卻不利于概念的明晰和有效實施。畢竟，要真正理解敏捷，還是要回歸業務目標。產品開發的最終目標是業務成功，這是沒有異議的。接下來我們將從目標出發，理解敏捷的意義所在，并以此來指導我們具體落實敏捷實踐。

敏捷產品開發的業務目標一：更早地交付價值

我們經常把敏捷與傳統瀑布開發方法相對應。如圖1-5所示，瀑布開發方法按順序的階段推進項目，到最后一次性交付全部的價值，在此之前的產出都是半成品。這無法適應今天市場競爭的要求。

IT行業的人都熟知摩爾定律：“18個月后，同樣的錢，能買到相對今天兩倍的產品——如計算能力、存儲量、晶元數等。”我們今天講的是反摩爾定律，它是2006年時任谷歌CEO的施密特提出的。如圖1-6所示，反摩爾定律是摩爾定律的鏡像，正如施密特所說的：

“如果我們18個月后賣出的產品和今天相同，那么得到的收入就只能是今天的一半。”

—— 反摩爾定律，施密特，Google前CEO，現執行董事長

反摩爾定律給我們的啟示是，越早交付價值，其價值越高；反之越遲交付，則價值越低。IT行業就是這樣殘酷，如果身處硬件行業，必須跟得上摩爾定律的步伐，否則就會被反摩爾定律吞噬。

軟件或服務行業會好一些嗎？其實問題更甚。尤其是在移動互聯時代，如圖1-7所示，價值交付的延遲，讓你無法享受早期的紅利。更有甚者，錯過時間窗口，可能意味著完全一無所獲。

面對這些事實，敏捷開發給出的答案非常簡單，迭代交付價值。如圖1-8所示，在迭代開發模式下，每個迭代交付一部分價值。根據反摩爾定律，相對最后交付，這也是更多的價值。由此，我們得出敏捷開發的第一個業務目標：

從業務視角看敏捷的業務目標一：更快（早）地交付價值。

值得注意的是，“更快”并不是絕對速度的快，而是指時間上的早，即通過迭代交付，實現分批和更早交付。

敏捷產品開發的業務目標二：靈活地應對變化

繼續從業務的角度來看傳統到敏捷開發方法的變化。圖1-9描述了傳統開發模式下知識的積累歷程。橫坐標是項目從開始到結束的時間，縱坐標是團隊對項目和產品的相關知識。隨著時間的進展，團隊不斷積累相關的知識，比如用戶要什么，最合適的產品和技術方案，最大的風險，等等。越往后，團隊對項目和產品的知識越豐富和準確，團隊知識最豐富的時刻顯然是項目后期。

然而，關于項目的決策是什么時間做出呢？是在項目一開始的時候，比如確定需求范圍、產品方案、實現方式、實施計劃等決策。在知識最不充分的時候，做出了最重要的決定，并把它作為此后的基準，這就是傳統開發下知識累積和決策時間間的悖論。在需求、市場和技術方案越來越不確定的移動互聯時代，這是個生死攸關的大問題。

敏捷開發方法對這個問題的回答依然是迭代。如圖1-10所示，迭代開發模式下，初始時，團隊仍然需要做出一些決定，比如確定總體目標和初始方案。隨著每個迭代的進展，團隊獲取新信息，比如市場和用戶對產品的反饋、技術環境和競爭對手策略的變化等，團隊通過這些新信息，建立新的認知，并在隨后的迭代計劃中做出調整，響應這些變化。

獲取反饋，靈活響應變化，不斷調整優化，在充滿不確定性、變化和競爭激烈的時代，這是團隊做出符合用戶及市場要求與競爭產品的必由之路。由此，我們得出敏捷產品開發的第二個業務目標：

從業務視角看敏捷的業務目標二：更靈活地響應變化。

總結以上兩個點，我們可以得出如下的結論：

敏捷的業務目標：打造組織更早地交付價值和更靈活地應對變化的能力。

回到敏捷（agile）這個詞，在朗文詞典中它的解釋是：“Able to move quickly and easily”，指的是迅速行動和響應的能力。因此，我們可以說：“敏捷就是敏捷。”第一個敏捷是“敏捷開發”，第二個敏捷是“敏捷這個詞的原始含義”，它與我們所說的敏捷業務目標是一致的。

敏捷實踐體系

實踐上，迭代交付模式是敏捷開發的核心要素，它使更早交付和更靈活應對變化成為可能。然而，迭代交付模式與瀑布開發模式的區別，使很多過去可行的實踐變得不再可行。

要落實敏捷開發方法，需要構建與之匹配的團隊組織方式、開發管理方法和技術實踐體系。例如，Scrum提供了迭代管理和持續改進的框架，極限編程則奠定了早期敏捷開發技術實踐的基礎。在實施過程中，敏捷的實踐體系不斷完善，針對不同問題形成了較為完備的實踐集。

? 如何管理迭代交付過程呢？對應的有Scrum、特性驅動開發和極限編程中的管理實踐等迭代管理框架。

? 每個迭代交付什么？怎么規劃？對應的有用戶故事、用戶故事地圖和產品待辦事項等敏捷需求實踐。

? 怎樣組織團隊才能讓他們直接面對用戶的需求？對應的有跨功能、跨職能和自組織的敏捷團隊組織方式。

? 如何在迭代模式下，更有效地組織需求澄清及驗收過程？對應的實踐有實例化需求、行為驅動開發或驗收測試驅動開發等實踐。

? 怎么應對持續增加的集成和回歸測試？對應的實踐有自動驗收測試及持續集成等。

? 如何在迭代模式下保障設計的一致性和持續演進？對應的實踐有代碼共有、簡單設計、測試驅動開發、持續重構和領域驅動設計等。

圖1-11總結了敏捷實踐以及它們要解決的問題，這并不是最終完整的實踐列表，敏捷實踐是在解決問題的過程中不斷成長的。

我并沒有把微服務架構、容器技術等最新的技術實踐包含在內，是因為它們已經被DevOps的框架所容納，后面介紹DevOps時還會提到它們。當然，你也可以把DevOps看成敏捷的延續或升級。重要的是不忘初心，記住敏捷的業務目標：更早地交付價值；更靈活地應對變化。

小結

相對作坊式的軟件開發，傳統軟件開發方法進步明顯，但也問題重重，更滿足不了軟件業日益提高的對及早交付和靈活應變的要求；敏捷產品開發的業務目標是為了更早地交付價值和更靈活地響應變化，理解業務目標，讓我們更容易達成一致的理解，也為針對性地實施具體敏捷實踐提供了依據。

本章要點

? 傳統的軟件開發方法誕生于上世紀60年代末的軟件危機，它借鑒了傳統工程管理的思想和方法。

? 對傳統開發方法的反思從未停止過，上世紀90年代各類輕量級軟件開發方法開始形成，發布于2001年的《敏捷軟件開發宣言》匯總了這些輕量級軟件開發背后的價值觀和原則。

? 敏捷開發的業務目標是更早地交付價值和更靈活地應對變化。

? 敏捷開發實踐應該服務于業務目標。

常見問題

問題：敏捷適用于所有組織嗎？

回答：敏捷首先是目標，而不是具體的方法。作為目標，提升組織及早交付價值和靈活應變的能力，這當然是正確的，也是所有組織想追求的。只不過，不同類型的組織對這一目標的迫切程度不一樣。

如果從事移動互聯網產品的開發，敏捷和迭代交付就是必然之選，是這個行業的基本模式。不這么做，你根本無法參與市場競爭。相對傳統的行業，對敏捷的需求要弱一些，但趨勢也十分明顯。如電信設備提供商在全面云化和網絡虛擬化的沖擊下，不得不面對互聯網廠商的競爭，因而應用敏捷開發實踐的需求也越來越強烈；過去認為傳統的金融行業，面臨互聯網金融的顛覆，就更不必多說了。

問題：傳統組織變得敏捷會有哪些困難，應該怎么做？

回答：使用傳統開發方法的組織，其組織文化、團隊結構、技術手段、流程工具還有考評和認可體系都會向傳統方法優化，所以要想變得敏捷，會遇到各種問題。各個問題之間相互關聯和牽扯會進一步放大問題，比如流程變了，考評和認可體系卻沒變，或者反之，都會造成組織無法運轉順暢。

另一方面，技術基礎設施和遺留代碼也可能成為變得更敏捷的障礙。這些從傳統變得敏捷過程中遇到的問題，都會表現為敏捷的弱點，也是我們需要正視的問題。

實施敏捷很困難，這是一個事實。組織要想清楚要不要變得敏捷，對這個問題的肯定回答已經成為大部分組織的共識，因為它關系到組織的競爭力，甚至生死。如果變得更敏捷是組織的選擇，那么接下來就是如何正確實施，正視和應對變革過程中的困難，并找到一條相對有效的和便捷的變革路徑。我們在本書第II部分和第III部分講的精益方法和實施，可以為實現敏捷變革提供一個有效的路徑。