2.3 敏捷過程

20世紀(jì)90年代后期，隨著技術(shù)的發(fā)展和經(jīng)濟(jì)的全球化，軟件開發(fā)也出現(xiàn)了新的特點，即在需求和技術(shù)不斷變化的過程中實現(xiàn)快速的軟件開發(fā)。在這個背景下，軟件行業(yè)借鑒了制造業(yè)“敏捷制造”的思想，逐漸形成了敏捷（agile）軟件開發(fā)這一新型軟件開發(fā)模式。在2001年，以Kent Beck、Martin Flower、Alistair Cockburn等為首的一些軟件工程專家成立了“敏捷聯(lián)盟”（http://www.agilealliance.com），并提出了著名的敏捷宣言，這標(biāo)志著敏捷軟件開發(fā)的思想逐步走向成熟。

和傳統(tǒng)過程不同的是，敏捷過程強(qiáng)調(diào)以人為本，快速響應(yīng)需求和變化，把注意力集中到項目的主要目標(biāo)——可用軟件上，在保證質(zhì)量的前提下，適度文檔、適度度量。敏捷過程基于適應(yīng)而非預(yù)測，它弱化了針對未來需求的設(shè)計而注重當(dāng)前系統(tǒng)的簡化，依賴重構(gòu)來適應(yīng)需求的變化，通過快速、短迭代的開發(fā)，不斷產(chǎn)出和演化可運行軟件。敏捷過程以人為導(dǎo)向，把人的因素放在第一位。它認(rèn)為，軟件開發(fā)中的絕大部分是需要創(chuàng)造力的設(shè)計工作，因此，在管理理念上應(yīng)注重領(lǐng)導(dǎo)和協(xié)作，而非命令和控制，充分發(fā)揮軟件人員的能動性和創(chuàng)造力。敏捷過程特別強(qiáng)調(diào)軟件開發(fā)中相關(guān)人員間的信息交流，認(rèn)為面對面的交流的成本要遠(yuǎn)遠(yuǎn)低于文檔交流的成本，應(yīng)減少不必要的文檔，提高應(yīng)變能力。

從本質(zhì)上講，敏捷過程是為克服傳統(tǒng)軟件過程中認(rèn)識和實踐的弱點開發(fā)而成的，它可以帶來多方面的好處，但并不適用于所有的軟件開發(fā)項目。它也并不完全對立于傳統(tǒng)軟件工程實踐，而是保留了傳統(tǒng)軟件工程實踐的基本框架活動：客戶溝通、策劃、建模、構(gòu)建、測試、交付、迭代等，但將其縮減到一個推動項目組進(jìn)行構(gòu)建和交付的最小任務(wù)集。

2.3.1 敏捷過程的價值觀和原則

敏捷過程的框架分為四個層次：動機(jī)、價值、原則和實踐，如圖2-6所示。

（1）動機(jī)

互聯(lián)網(wǎng)的迅猛發(fā)展和經(jīng)濟(jì)全球化向軟件開發(fā)提出了新的挑戰(zhàn)：快速的市場進(jìn)入時間、快速變化的需求、快速發(fā)展的技術(shù)。在這個背景下，許多軟件工程師都試圖改變傳統(tǒng)軟件過程的復(fù)雜性，自下而上地提出了敏捷過程。

（2）價值

《敏捷宣言》中包含了四條著名的敏捷價值觀，所有敏捷過程都必須同意這個價值觀才能加入敏捷聯(lián)盟中。

● 注重個人和交互勝于過程和工具。

● 注重可用的軟件勝于事無巨細(xì)的文檔。

● 注重客戶協(xié)作勝于合同談判。

● 注重隨機(jī)應(yīng)變勝于循規(guī)蹈矩（恪守計劃）。

敏捷開發(fā)認(rèn)為關(guān)注左邊的內(nèi)容更能適應(yīng)市場需求，提升客戶滿意度。

（3）原則

從四條敏捷價值觀出發(fā)，敏捷聯(lián)盟提出了十二條基本原則：

● 最優(yōu)先的目標(biāo)是通過盡早地、持續(xù)地交付高價值的軟件來滿足客戶需要。

● 歡迎需求變化，甚至在開發(fā)后期也是如此。敏捷過程通過駕馭變化來幫助客戶取得競爭優(yōu)勢。

● 經(jīng)常交付可用軟件，間隔從兩周到兩個月不等，優(yōu)先采用較短的時間尺度。

● 整個項目自始至終，業(yè)務(wù)人員和開發(fā)人員都必須每天在一起工作。

● 以積極主動的人員為核心建立項目團(tuán)隊，給予他們所需的環(huán)境和支持，并且信任他們能夠勝任工作。

● 在開發(fā)團(tuán)隊內(nèi)外傳遞信息最有效率和效果的方法是面對面的交流。

● 可用的軟件是最主要的項目進(jìn)展指標(biāo)。

● 敏捷過程提倡可持續(xù)的開發(fā)。項目發(fā)起人、開發(fā)者和用戶都應(yīng)該始終保持穩(wěn)定的工作步調(diào)。

● 持續(xù)關(guān)注技術(shù)上的精益求精和優(yōu)良的設(shè)計以增強(qiáng)敏捷性。

● 簡約——使必要的工作最小化的藝術(shù)——是成功的關(guān)鍵。

● 最優(yōu)的架構(gòu)、需求和設(shè)計浮現(xiàn)于自組織的團(tuán)隊。

● 團(tuán)隊定期不斷地對如何更加有效地開展工作進(jìn)行反思，并相應(yīng)地調(diào)整、校正自身的行為。

這些敏捷原則是用來判斷一個組織是否做到了敏捷的主要依據(jù)。

（4）實踐

敏捷到底應(yīng)該如何做？如何將敏捷價值觀和原則落到實處？這是大多數(shù)人最關(guān)心的問題。人們已研究總結(jié)出大量成熟的敏捷實踐，在此基礎(chǔ)上提出了一系列具體的敏捷過程，如Scrum、Kanban、XP、AgileUP、AM（Agile Modeling）、Lean、FDD、Crystal等。接下來將介紹最有代表性的敏捷過程——Scrum和Kanban。

2.3.2 Scrum

Scrum是目前最流行的軟件過程，它關(guān)注敏捷的軟件項目管理，由Ken Schwaber和Jeff Sutherland于1993年提出，已在全球許多公司中應(yīng)用，適用于需求難以預(yù)測的復(fù)雜商務(wù)應(yīng)用產(chǎn)品的開發(fā)。Scrum一詞來源于橄欖球運動，意為兩隊并列爭球。敏捷軟件開發(fā)就像是橄欖球的爭球過程，是迅速的、有適應(yīng)性的、自組織的。

Scrum認(rèn)為軟件開發(fā)過程更多是經(jīng)驗性過程（empirical process），而不是確定性過程（defined process）。確定性過程是可明確描述的、可預(yù)測的，因而可重復(fù)執(zhí)行并能產(chǎn)生預(yù)期的結(jié)果，并能通過科學(xué)理論對其進(jìn)行最優(yōu)化。經(jīng)驗性過程與之相反，應(yīng)作為一個黑箱（black box）來處理，通過對黑箱的輸入輸出不斷進(jìn)行度量，在此基礎(chǔ)上，結(jié)合經(jīng)驗判斷對黑箱進(jìn)行調(diào)控，使其不越出設(shè)定的邊界，從而產(chǎn)生滿意的輸出。Scrum方法將傳統(tǒng)軟件開發(fā)中的分析、設(shè)計、實現(xiàn)視為一個黑箱，認(rèn)為應(yīng)加強(qiáng)黑箱內(nèi)部的混沌性，使項目組工作在混沌的邊緣，充分發(fā)揮人的創(chuàng)造力。若將經(jīng)驗性過程按確定性過程來處理（如瀑布模型），必將使過程缺乏適應(yīng)力。

Scrum的核心準(zhǔn)則是自我管理和迭代開發(fā)。

（1）自我管理

Scrum團(tuán)隊的目標(biāo)是提高靈活性和生產(chǎn)能力。為此，他們自組織、跨職能，并且以迭代方式工作。每個Scrum團(tuán)隊都有三個角色：①Scrum主管（Scrum Master），負(fù)責(zé)確保成員都能理解并遵循過程，通過指導(dǎo)和引導(dǎo)讓Scrum團(tuán)隊更高效地工作，生產(chǎn)出高質(zhì)量的產(chǎn)品；②產(chǎn)品負(fù)責(zé)人（Product Owner），定義和維護(hù)產(chǎn)品需求，負(fù)責(zé)最大化Scrum團(tuán)隊的工作價值；③團(tuán)隊（Team），負(fù)責(zé)具體工作。團(tuán)隊的理想規(guī)模是5～9人，團(tuán)隊成員具備開發(fā)所需的各種技能，負(fù)責(zé)在每個Sprint（沖刺迭代）結(jié)束之前將產(chǎn)品負(fù)責(zé)人的需求轉(zhuǎn)化為潛在可發(fā)布的產(chǎn)品模塊。

Scrum過程中沒有中心控制者，強(qiáng)調(diào)發(fā)揮個人的創(chuàng)造力和能動性，鼓勵團(tuán)隊成員進(jìn)行自我管理，使用自己認(rèn)為最好的方法和工具進(jìn)行開發(fā)。Scrum主管的職責(zé)不是檢查和監(jiān)督團(tuán)隊成員的日常工作，而是消除團(tuán)隊開發(fā)的外部障礙，指導(dǎo)團(tuán)隊成員工作，對內(nèi)部成員進(jìn)行培訓(xùn)。Scrum通過鼓勵同場地辦公、口頭交流和遵守共同規(guī)范創(chuàng)建自組織團(tuán)隊。

（2）迭代開發(fā)

Scrum是一種演化型的迭代開發(fā)過程，如圖2-7所示。Scrum的核心是Sprint，即貫穿于開發(fā)工作中的短期迭代。一個Sprint周期通常為1～4周，它是一個固定時間盒，在項目進(jìn)行過程中不允許延長或縮短。每個Sprint都會提交一個經(jīng)測試可發(fā)布的軟件產(chǎn)品增量版本。Sprint由Sprint計劃會、開發(fā)工作、Sprint評審會和Sprint反思會組成。

Scrum采用四個主要的文檔：產(chǎn)品待辦事項列表（product backlog）、Sprint待辦事項列表（Sprint backlog）、發(fā)布燃盡圖（release burndown chart）和Sprint燃盡圖（Sprint burndown chart）。產(chǎn)品待辦事項列表是囊括了開發(fā)產(chǎn)品可能需要的所有事項的優(yōu)先排列表。Sprint待辦事項列表包含在一個Sprint內(nèi)將產(chǎn)品待辦事項列表轉(zhuǎn)化成最終可交付產(chǎn)品增量的所有任務(wù)。發(fā)布燃盡圖衡量在一個發(fā)布計劃的時間段內(nèi)剩余的產(chǎn)品待辦事項列表。Sprint燃盡圖衡量在一個Sprint時間段內(nèi)剩余的Sprint待辦事項列表條目。

Scrum采用任務(wù)板來可視化軟件開發(fā)的進(jìn)展，它可以是一個大白板，也可以使用軟件，如圖2-8所示[2]。任務(wù)板上展現(xiàn)了當(dāng)前Sprint的所有任務(wù)，每項任務(wù)用一張“即時貼”來代表，上面記錄著任務(wù)的名稱、優(yōu)先級、接受任務(wù)的開發(fā)者姓名、預(yù)計的完成時間等信息。任務(wù)板上有3列：待處理的任務(wù)（To Do），即Sprint中要著手的待辦事項或用戶故事（user story）；進(jìn)行中的任務(wù)（Doing），即團(tuán)隊成員已經(jīng)認(rèn)領(lǐng)的、正在處理的任務(wù)；已完成的任務(wù)（Done），即團(tuán)隊成員已經(jīng)完成的、被關(guān)閉的任務(wù)。在Sprint過程中我們要不斷地更新任務(wù)板。

Scrum主管通過每日立會（standup meeting）來保證項目組成員了解其他所有人的工作進(jìn)度。Scrum每日立會是每天早上進(jìn)行的15min的會議，大家必須站立開會，例如站在任務(wù)板前。每個團(tuán)隊成員要回答以下三個問題：昨天你做了什么？今天打算做什么？有沒有問題影響你達(dá)成目標(biāo)？團(tuán)隊成員通常需要與Scrum主管溝通解決這些問題，這些溝通不是會議討論內(nèi)容，因此每日立會只是提出問題，會后再個別溝通具體問題的解決方案，以確保每日立會的時長控制在15min以內(nèi)。

Scrum能快速適應(yīng)需求變化，提高開發(fā)進(jìn)度和質(zhì)量，在工業(yè)界取得了很大成功。Standish Group的2018年chaos報告中的調(diào)查結(jié)果表明，Scrum的項目成功率達(dá)到58%，而傳統(tǒng)的瀑布模型的項目成功率僅有18%。

2.3.3 Kanban

Kanban，又稱為看板，源自精益制造，從豐田公司的實踐中演化出來，其核心在于工作的全方位可視化以及基于工作的實時溝通。通過看板墻（Kanban board）中各工作項的直觀展示，讓團(tuán)隊成員清晰了解各項工作的狀態(tài)及進(jìn)展，并識別瓶頸。

看板墻和Scrum任務(wù)板很類似，可以是物理板或電子板。不同的是，在看板墻中，根據(jù)團(tuán)隊的規(guī)模、結(jié)構(gòu)和目標(biāo)的不同，團(tuán)隊可以設(shè)置自己個性化的工作流。圖2-9是一個典型的看板墻，它的每個迭代由待辦事項（Backlog）、選擇（Selected）、開發(fā)/處理中（Develop/Ongoing）、開發(fā)/已完成（Develop/Done）、部署（Deploy）和發(fā)布（Live！）等步驟組成。我們也可以把開發(fā)進(jìn)一步細(xì)分為設(shè)計、編碼和測試。看板墻的作用是把整個開發(fā)流程可視化。團(tuán)隊在看板墻的各欄目中貼上卡片來代表開發(fā)過程中的各個工作項，讓團(tuán)隊工作流可視化呈現(xiàn)。

看板墻上的每張卡片代表一個工作項，它記錄了有關(guān)該工作項的相關(guān)信息，使整個團(tuán)隊能夠全面了解負(fù)責(zé)該工作項的人員、正在完成的工作的簡要描述、估計該工作需要多長時間等。電子板上的卡片通常還會包含功能截圖和其他對經(jīng)辦人有價值的技術(shù)細(xì)節(jié)。看板卡片允許團(tuán)隊成員在任何時間點都能了解每個工作項的狀態(tài)以及相關(guān)細(xì)節(jié)。

欄目頂部的數(shù)字代表該步驟的最大工作項容量。Kanban通過限制進(jìn)行中的工作項的數(shù)量，防止過度生產(chǎn)，并動態(tài)地揭示開發(fā)過程中的瓶頸。進(jìn)行中的工作項（work in progress, WIP）稱為在制品。團(tuán)隊通過將在制品與團(tuán)隊能力的匹配來達(dá)到軟件的“及時”（just in time, JIT）開發(fā)。

Kanban和Scrum都是基于快速迭代的敏捷過程，采用自組織團(tuán)隊。和Scrum不同的是，Kanban的最大特點是限制正在進(jìn)行的工作項的數(shù)量，以及看板墻上可視化的工作流。此外，Kanban的迭代沒有規(guī)定的固定時長，沒有規(guī)定的角色。兩個過程可以相互融合，例如微軟提出的Scrum-ban。