敏捷軟件開發項目的快速啟動方法

在軟件業界，敏捷開發及項目管理方法已成為很多團隊高效運作的有力武器。在項目的啟動環節中引入QuickStart方法，幫助快速確立項目目標，統一理解，發掘用戶需求，使用各種流程建模和分析技術，產生交付計劃。之后項目團隊就可以立即投入迭代開發工作。該方法是一種可以有效推動軟件項目快速啟動的敏捷項目管理方法。

【關鍵詞】敏捷項目管理敏捷軟件開發快速啟動 QuickStart用戶模型場景模型用戶故事交付計劃

1 敏捷開發及項目管理方法體系

1.1 敏捷方法介紹

敏捷方法誕生于2001年初，當時，由于看到開發團隊陷入越來越沉重的軟件過程當中。業界專家們總結出了一套使團隊具有快速工作、響應變化能力的價值觀和原則。基于這一套價值觀和原則的軟件開發方法，被稱為敏捷軟件開發方法（Agile Software Develop-ment），而這類方法也發展出相應的敏捷項目管理體系（Agile Project Management）。敏捷開發方法及項目管理體系統稱為敏捷方法（Agile）。

1.2 敏捷方法的優點

敏捷方法是一種以人為核心、迭代、循序漸進的開發及項目管理方法。該方法使用了迭代、增量等方法來優化可預見性并控制風險。它靈活、高效、可持續，可以幫助軟件開發團隊有效地應對復雜的適應性問題。

該方法受到擁護和流行是因為采用了該方法后，團隊得到的收益：據統計，敏捷方法可以讓團隊的效率提升3～10倍；軟件的質量也更有保障；團隊成員有良好的發展機會；技術能力和團隊協作也得到了提高。

2 敏捷項目的快速啟動

2.1 什么是快速啟動？

敏捷軟件開發項目通常會通過1～4周的快速啟動（QuickStart）工作，制定出迭代開發計劃，然后在開發過程中逐漸完善需求。QuickStart是一種高效的項目啟動方式，主要用以在項目開始之前識別關鍵的驅動因素，這種方式能夠讓關鍵干系人認可并理解即將交付的產品。如圖1所示。

3 QuickStart的前期準備

3.1 邀請相關參與人員

QuickStart過程中需要邀請參與的人員包括：核心團隊、領域專家及用戶代表、關鍵干系人（受益人、高層領導等）。核心團隊一般包括產品負責人、需求分析人員、項目負責人及核心團隊成員。這些人需要全程參與整個QuickStart，他們是成果的主要貢獻者。領域專家及用戶代表主要在用戶建模、場景建模等環節為團隊提供專業的意見和建議。他們可以在某些階段時參與到QuickStart中來。關鍵干系人主要參與QuickStart的啟動和展示匯報的環節，并對產出成果進行確認，特別是需要對產品目標和發布計劃進行確認和授權。

3.2 擬定QuickStart的計劃

在QuickStart正式開始之前，項目負責人和產品負責人需要擬定QuickStart的整體計劃。以一個2周的QuickStart為例，整個QuickStart計劃可以這樣安排：

QuickStart啟動及業務目標識別（0.5～1天）

參與人員包括：核心團隊、領域專家及用戶代表、項目領導

產出物：產品目標

識別主要角色及場景（3～5天）

參與人員包括：核心團隊、領域專家及用戶代表、項目領導

產出物：主要用戶角色列表、核心場景及流程、頁面設計及原型

需求列表梳理（1～2天）

參與人員包括：核心團隊、領域專家及用戶代表

產出物：用戶故事清單

規模及成本估算（0.5～1天）

參與人員包括：核心團隊

產出物：估算結果

迭代/發布計劃制定（0.5～1天）

參與人員包括：核心團隊

產出物：迭代/發布計劃

QuickStart的成果匯報（0.5天）

參與人員包括：全體團隊成員

產出物：成果匯報材料

4 引入的各種流程建模及分析技術

4.1 識別業務目標及愿景

業務目標的識別和確定需要符合SMART原則；需要了解問題的背景及上下文信息；需要定義驗證問題成功的標準；需要界定問題的范圍，例如規模指的是數量還是金額，或者單品規模；需要明確并逐步完善關鍵干系人信息；需要明確關鍵資源，例如領域專家或者關鍵信息等等；還需要明確該問題的各種約束條件。

4.2 識別角色及主要場景

用戶識別從頭腦風暴的形式開始，盡可能識別出更多的用戶，然后挑選出主要的用戶和角色，并且為用戶進行用戶畫像，并建立用戶模型。通過理解用戶的目標需求和痛點，梳理出更多的細分用戶場景，之后對用戶場景進行優先級排序、分析，以發現其中的問題或隱含的機會。

對問題和機會進行結構化的分析可以通過這幾個方面來進行：

（1）進行問題/機會的原始描述；

（2）通過事例來說明問題/機會的現象；

（3）對問題/機會進行定量的分析；

（4）對問題/機會進行定義并明確對于問題解決的期望；

（5）將問題和機會的相關分析及描述標識在用戶場景描述的周圍。

業務流程梳理的過程中可以將之前識別出來的用戶場景在進行串聯。較高層級的業務流程將各個場景串聯起來之后，就可以在場景中進行場景流程的細化和展開，分析出流程步驟和各個步驟的細節。業務流程場景中的步驟細節需要包含這些信息：場景名稱、場景入口的背景說明，本場景中需要跟進解決的問題，場景中事件步驟，某個步驟的細節說明，還需要有場景的出口目標。

4.3 產出Product backlog

根據上一環節中梳理出來的用戶模型、場景模型、業務流程以及場景細節，開始進行用戶故事的梳理，并建立用戶故事列表。用戶故事是為了方便與用戶溝通而記錄的信息，它不是需求文檔，它需要以用戶能理解的方式來進行描述。它的目的是要將用戶的關注點從“寫”轉移到“交流”上，讓開發團隊做用戶真正需要的東西，而不是用戶寫的東西。

一個用戶故事的描述樣例是：“作為一個<角色>，我想要<活動>，以便于<商業價值>”。一個用戶故事是否成功可以從以下幾點（INVEST）來判斷：是不是獨立的（Independent），是不是可協商的（Negotiable），是不是有價值的（Valuable），是不是可以估算的（Estimable），是不是大小合適、粒度相似的（Sized appropriately），是不是測試能夠測試、業務能夠驗收的（Testable）。

4.4 梳理依賴、估算及優先級排序

核心開發人員對已經梳理出來的用戶故事進行初步的技術解決方案分析，確定用戶故事的技術實現可行性和一些可能的實現方案。然后從邏輯層面和技術實現層面，對用戶故事列表中的故事進行一次檢視，對于一些無法避免的用戶故事之間的相互依賴，需要在故事卡片上標識出來。對已經梳理出來的用戶故事進行估算，估算內容包括故事規模估算、工作量估算等。

估算完成后可以根據用戶故事的價值、重要程度、依賴等信息進行用戶故事優先級排序。排序的原則是優先考慮那些最有價值的故事、最關鍵的故事、被其他關鍵故事依賴最多的故事。

4.5 制定交付計劃

經過以上各個環節，團隊已經得到了了一份標識了優先級、依賴關系、工作量估算等信息的用戶故事列表，此時可以開始來制定交付/發布計劃了。根據已經排序的優先級選擇并整理每個迭代/版本需要完成的用戶故事，使用每個故事上之前已經完成的規模或工作量估算，加上功能聯調和集成可能增加投入量的buffer值，整理并安排出整個交付計劃。

對于最近的一個交付周期的安排是團隊應該投入最多時間進去分析和做進一步估算的。確保第一個交付周期的所有用戶故事清晰且被團隊理解，并且該周期中的所有用戶故事都已經有較明確的技術實現方案，可以在QuickStart結束之后馬上進入開發實現。如圖2所示。

4.6 匯報QuickStart的成果

QuickStart的最后一個環節是召開QuickStart成果匯報的會議，該會議的邀請人員包括項目團隊全體成員、項目領導、相關干系人。會議上向項目相關人員匯報QuickStart的成果產出，包括確定項目產品目標及愿景、需求列表及交付計劃。在展示項目團隊QuickStart成果的同時也獲取相關領導及干系人對成果的認可和支持，統一項目團隊人員的認識，為匯報結束后立刻投入到需求的開發實現奠定基石。

5 結束語

敏捷項目中的QuickStart是一種高效的項目啟動方法，幫助項目快速確立目標、梳理需求并排定計劃。它是一種敏捷的項目管理方式，強調共享、合作與包容，業務與IT關鍵干系人全程共同參與，注重群體決策。它是一種經過反復實踐驗證，效果較好的項目快速啟動方法。

參考文獻

[1]（美）John C.Goodpasture，陳秋萍譯.敏捷項目管理：企業級實踐與案例[M].電子工業出版社，2012.

[2]（美）Robert C.Martin，鄧輝譯.敏捷軟件開發原則模式與實踐[M].清華大學出版社，2003.

[3]（美）Michele Sliger Stacia Broderick，李曉麗，李虎，趙華譯.軟件項目管理與敏捷方法[M].機械工業出版社，2010.

[4]（美）Mike Cohn，石永超，張博超譯.用戶故事與敏捷方法[M].機械工業出版社，2008.

[5]（美）Jeff Patton，李濤，向振東譯.用戶故事地圖[M].清華大學出版社，2016.

[6]（美）Mike Cohn，宋銳譯.敏捷估計與規劃[M].清華大學出版社，2007.

作者簡介

梁瑾（1978-），女，廣東省深圳市人。學士學位。現為平安科技（深圳）有限公司項目副總監。主要研究方向為敏捷軟件項目管理。

作者單位

平安科技（深圳）有限公司 廣東省深圳市 518000