5.1 敏捷分析

??敏捷分析（Agile Analytics）是一種開發(fā)風格，在它的指導下，用戶、利益相關者以及開發(fā)者在整個開發(fā)周期中共同協(xié)作，盡早且持續(xù)不斷地傳遞商業(yè)價值，構建一個高品質(zhì)、可用的數(shù)據(jù)倉庫（Data Warehousing）與商業(yè)智能（Business Intelligence）系統(tǒng)。

??類似于敏捷軟件開發(fā)（Agile Software Development），敏捷分析建立在一系列簡單的核心價值及指導原則上，它不是一個死板固定的方法，但需要高度訓練及嚴謹正確地執(zhí)行?？梢哉f這是一種介于完整結構與靈活性之間的開發(fā)風格，區(qū)別于沒有結構或者過于僵化的過程。在進一步分析敏捷分析的特征之前，首先需要對關于敏捷的幾個常見誤解進行說明。

5.1.1 幾個常見誤解

敏捷意味著更快地完成項目

??在敏捷的指導下，快速完成項目是可能的，但這不是敏捷的首要目標，敏捷追求的應該是傳遞商業(yè)價值，提高項目質(zhì)量和成功率。

敏捷只是少部分人的事

??敏捷絕不只是少部分人的事，一次卓越的敏捷實踐，必須集合所有團隊成員的努力，從思維上到行動上都朝著敏捷轉(zhuǎn)變。

敏捷就是簡短且經(jīng)常性的迭代開發(fā)周期

??敏捷給人直觀的感受之一，就是簡短且經(jīng)常性的迭代開發(fā)周期，一般一到三周就是敏捷的一個迭代開發(fā)周期，這也是敏捷的重要基石之一。但這不意味著只要迭代開發(fā)周期短就是敏捷了，敏捷要求每個迭代都能產(chǎn)生一個可演示的可用軟件，以盡早展示可用功能并從用戶那頻繁地獲取反饋。

敏捷不需要嚴謹和確保質(zhì)量

??敏捷簡單但不容易，它必須在遵循其核心價值及指導原則的前提下，被嚴謹正確地執(zhí)行，確保交付高價值、高質(zhì)量、可用的軟件。

5.1.2 敏捷分析特征

??正如前文所述，敏捷分析是一種開發(fā)風格，其首要目標是構建一個高價值、高質(zhì)量、可用的商業(yè)智能和數(shù)據(jù)倉庫系統(tǒng)。為了實現(xiàn)這個目標，敏捷分析需要具備如下的特征：

• 迭代、增量、進化：敏捷通過不斷適應用戶的頻繁反饋和持續(xù)地進行短期迭代，逐步發(fā)展為可用的系統(tǒng)。我們可以將構建DW/BI系統(tǒng)的過程視為在陌生海域的一次航行，在沒有確認方向正確、航線暢通的情況下，需求借助與用戶頻繁的短期交互，來確保沒有偏離正確的方向太遠。
• 價值驅(qū)動：在上一節(jié)提到，敏捷要求每個迭代都能產(chǎn)生一個可演示的可用軟件，這是為了確保每個迭代都能產(chǎn)生一個具備用戶價值的功能，以幫助用戶解決問題。
• 產(chǎn)品質(zhì)量：每個功能都必須確保其質(zhì)量，以確保向用戶傳遞正確的價值。
• 剛剛好的過程：敏捷的最主要目標是高價值、高質(zhì)量、可用的系統(tǒng)，為了達到這個目標，必須確保質(zhì)量，但構建這個系統(tǒng)的過程卻可以一切從簡，不需要每一步都完美無缺，只需剛剛好。
• 自動化：真正的敏捷需要盡可能地自動化處理日常流程，已更加專注于開發(fā)高價值的功能。
• 協(xié)作：用戶、利益相關者以及開發(fā)者的緊密協(xié)作是敏捷項目成功的關鍵。
• 自我驅(qū)動：最大程度地發(fā)揮團隊成員的主觀能動性。

5.1.3 敏捷分析開發(fā)宣言

??在2001年，一群偉大的開發(fā)者發(fā)布了敏捷軟件開發(fā)宣言，它為敏捷的實踐提供了依據(jù)，為了讓宣言更適用于敏捷分析， Ken Collier 對它進行了一些調(diào)整：

我們一直在實踐中探尋更好的軟件開發(fā)方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：

• 個體和互動 高于 流程和工具
• 可用的數(shù)據(jù)倉庫和商業(yè)智能系統(tǒng) 高于 詳盡的文檔
• 終端用戶和利益相關者協(xié)作 高于 合同談判
• 響應變化 高于 遵循計劃

也就是說，盡管右項有其價值，我們更重視左項的價值。

5.2 用戶故事

??在構建數(shù)據(jù)倉庫和商業(yè)智能系統(tǒng)（下面簡稱DW/BI系統(tǒng)）時，開發(fā)者們總是會以數(shù)據(jù)為中心，首先從數(shù)據(jù)層面上進行大量的工作，他們甚至錯誤的認為，只要確保數(shù)據(jù)的正確，就可以滿足未來一切可能的用戶需求。但實際上，這樣的DW/BI系統(tǒng)往往不能很好地解決具體的商業(yè)問題，因為這類系統(tǒng)并不是建構在對用戶需求的了解上，也沒有盡早地向用戶傳遞商業(yè)價值，以至被用戶所拋棄。

??而敏捷分析強調(diào)的是價值驅(qū)動，在整個開發(fā)的過程中，開發(fā)者迫切地期望開發(fā)出能滿足用戶需求、解決商業(yè)問題的可用功能，數(shù)據(jù)只是服務于這個目標。因此，敏捷分析的第一步應當是廣泛而快速地收集用戶需求，并加以組織，然后將其轉(zhuǎn)化為確實需要開發(fā)的高價值功能。要做到這點，就需要使用到敏捷開發(fā)中的用戶故事（User Story）?？梢哉f，敏捷分析是以用戶故事驅(qū)動的方法來構建DW/BI系統(tǒng)，而非數(shù)據(jù)驅(qū)動。

5.2.1 用戶故事概述

??用戶故事被廣泛地運用在敏捷開發(fā)的過程中，它是對需求的細化和切分。通過用戶故事，可以快速地收集并組織項目需求，而無需在前期進行廣泛而深入的需求分析，并在之后將需求具體化成可以進行迭代開發(fā)的一個個現(xiàn)實的可見的開發(fā)任務?？梢赃@樣理解用戶故事：

一件用戶通過系統(tǒng)實現(xiàn)他的一個有價值的目標的事，就是一個用戶故事，即從用戶角度進行描述的故事。

5.2.2 用戶故事內(nèi)容

??用戶故事通常按照如下的格式來表達：

作為一個<角色>，我需要系統(tǒng)能夠<做某事>，這樣我可以<目標陳述>。

??舉例如下：

??作為一個產(chǎn)品運營人員，我希望系統(tǒng)能夠讓我看到新登用戶中只有一次會話的用戶（DOSU: Daily One Session Users），這樣我可以衡量新用戶的質(zhì)量。

??當然，用戶故事也可以按照如下的格式來表達：

為了實現(xiàn)<目標陳述>，作為一個<角色>，我需要系統(tǒng)能夠<做某事>。

??在這兩個模板中，都包含有3個要素：

• Who：用戶角色。
• What：通過系統(tǒng)完成的某項操作。
• Why（reason）：需要達成的某個目標（實現(xiàn)的商業(yè)價值）。

??需要注意，用戶故事不需要使用技術語言來描述，而是以用戶可以理解的業(yè)務語言來描述。另外要避免用戶故事的內(nèi)容過于復雜，例如下面這個反面案例：

??作為一個產(chǎn)品運營人員，我希望系統(tǒng)能夠讓我了解每一個用戶的留存成本，這和平臺的盈利相關。我還需要按照性別、年齡層、收入水平來分析用戶特征，這樣我可以發(fā)現(xiàn)降低成本或者增加例如的機會。

5.2.3 編寫優(yōu)秀的故事

??一個優(yōu)秀的用戶故事需要具備如下特點：

• 它可以代表客戶群體的商業(yè)價值。
• 能夠?qū)崿F(xiàn)為可用的功能演示給商業(yè)用戶，以便收集他們的反饋。
• 能在單個迭代期內(nèi)完成，成為架構完整（architecturally complete）且達到上線質(zhì)量（production-quality）的可用功能。

??上節(jié)的反例就沒有做到第三點，它過于復雜，難以在單個迭代期內(nèi)完成，需要將其分解為多個更簡單且符合上述3個特點的用戶故事。這里我們還要再了解一個經(jīng)常與用戶故事一起出現(xiàn)的概念——史詩故事（Epic），通俗來說就是大型故事。Epic由許多較大的不確定的需求（large fuzzy requirements）組成，而且經(jīng)?；祀s了許多不同的特性（一個特性就是一組可以歸為一類的需求），不能直接通過其完成迭代和開發(fā)。因此，我們首先需要將史詩故事劃分成較小的真正的用戶故事，然后才能組織用戶故事進行迭代開發(fā)。

??在編寫一個優(yōu)秀的用戶故事時，需要遵循INVEST原則：

• Independent：獨立性

??用戶故事之間應該具有獨立性，不應該依賴于其他的用戶故事。否則將會導致用戶故事之間存在著不同的優(yōu)先級，只有被依賴的用戶故事完成才能繼續(xù)開發(fā)依賴的用戶故事。一般可以通過對用戶故事的組合或分割來減少相互依賴性。

• Negotiable：可協(xié)商

??用戶故事不是簽訂的商業(yè)合同，它是由客戶或者PO同開發(fā)小組的成員共同協(xié)商制定的，因此它不需要太多的條條框框，以保證更好的溝通及協(xié)商。

• Valuable：有價值

??用戶故事必須對于終端用戶是有價值的，因此應該站在用戶的角度去編寫，描述的是 feature，而非 task。

• Estimable：可評估

??用戶故事的劃分要保證其可以被很好地評估，以減少估算的不確定性。

• Small：短小

??故事應當盡量的短小，最好是能夠在一個迭代周期之內(nèi)完成的，如果太大就應該考慮將其拆分為多個更細顆粒度的故事。

• Testable：可測試

??用戶故事必須是可測試的，否則無法判斷該故事是否被完成，另外測試的過程做好可以實現(xiàn)自動化。

??關于用戶故事，還有一個很經(jīng)典的由 Ron Jeffries 提出的 3C 原則：

• Card（卡片）：用戶故事一般寫在小的記事卡片上，除了故事本身的描述之外，還應該包括故事的時間點估計及對應的測試行為等等。
• Conversation（交談）：用戶故事背后的細節(jié)需要項目組中的成員與PO或者客戶之間溝通得出的。
• Confirmation（確認）：通過驗收測試確認用戶故事被正確完成。

5.2.4 用戶故事是需求的代表

??用戶故事本身不是需求，而是需求的代表，它幫助項目組快速收集并組織需求，并通過討論和協(xié)商確定系統(tǒng)需要支持的性能和功能，而無需在一開始就在詳細的需求分析和設計中花去大量的精力。正如 Mike Cohn 所說，用戶故事“確保了大家能夠?qū)τ脩粜枨筮M行對話交流”。而 Scott Ambler 在一次開發(fā)BI系統(tǒng)的過程中發(fā)現(xiàn)，通過和用戶協(xié)作撰寫用戶故事，可以在幾天內(nèi)便收集到所有需求的 80%。

5.3 敏捷分析中的用戶故事

?? 下面將會通過一個虛構的例子，展示如何在敏捷分析開發(fā)的過程中運用用戶故事。

5.3.1 識別用戶角色

??有一家名為富貴便利店的連鎖便利店公司，需要搭建一套 DW/BI 應用，以滿足其內(nèi)部多個部門對數(shù)據(jù)的商業(yè)需求。在這種情況下，首先需要識別不同用戶角色，以便對照著這些用戶角色來撰寫用戶故事，而不至于偏離方向。在識別用戶角色的過程中，需要注意以下兩點：

• 在一段時間內(nèi)，同一個人可能兼任不同的用戶角色，例如財務總監(jiān)在整個商業(yè)過程中扮演了很多不同的角色。
• 當用戶的目標發(fā)生變化時，也可以修改用戶角色。

??通過頭腦風暴收集第一批用戶角色，并將用戶角色列出來：

收集用戶角色

??接著，按職能的相似程度進行分組，將職能上有重疊的兩個角色重疊放置：

用戶角色分組

??最后，將重疊度高的角色進行歸納，再通過定義差異特征、預期使用頻率、使用模式、數(shù)據(jù)分析能力、領域?qū)I(yè)度、使用目標以及其他因素來完善用戶角色，并用一段簡短、描述性的話將這些信息寫在用戶角色卡片上：

歸納用戶角色

完善用戶角色

??為每個定義好的用戶角色創(chuàng)建一個具體的用戶形象，有助于團隊持續(xù)地具象思考他們的用戶是誰、需要什么樣的功能、實現(xiàn)什么目標。

5.3.2 用例建模

??現(xiàn)在，已經(jīng)建立了一系列的用戶角色，要在此基礎上撰寫一整套的用戶故事，這工作似乎有點龐大。不要緊，還可以通過用例建模，將問題逐步分解。用例建模的第一步就是創(chuàng)建一張用例圖：

用例圖示例

??下一步是定義用例圖中每個用例的細節(jié)：

用例細節(jié)示例

??一個簡單的用例可以直接寫成用戶故事，例如“登錄 BI 應用”這個用例就可以簡單地寫成一則用戶故事：

??作為一名盈利能力分析員，我希望系統(tǒng)能讓我登錄到 BI 應用上。

??但大部分情況下，用例細節(jié)中都包含了若干用戶故事，需要在用例細節(jié)中的主事件流找到這些用戶故事，并將其拆分出來。

5.3.3 拆分用戶故事

?? 在前文反復提到，一個優(yōu)秀的用戶故事應當是能在一個迭代期內(nèi)完成的，但不可避免地會遇到中篇、長篇甚至超長篇（史詩）的用戶故事。這類故事與用例接近，它們描述的功能反映了各種事件流和場景，常包含多個不同的故事，或單個復雜的故事。必須將這類故事拆分為更加短小、簡單的用戶故事，以確保能在一個迭代期內(nèi)完成用戶故事。

?? 下面舉兩個例子：

?? 作為一名銷售預測人員，我需要系統(tǒng)能夠讓我了解每家店的日常收益、每天的成交筆數(shù)、每家店附近的顧客在人口統(tǒng)計學上的特征、過去兩年每家店的歷史收益，這樣我才能分析并且預測收益和購買的趨勢。

?? 這是一個典型的包含了多個用戶故事的集合，實際上，該故事表達的是：

?? 作為一名銷售預測人員，我需要系統(tǒng)提供以下幾個功能：

• 了解每家店的日常收入。
• 了解每天（或每家店）的成交筆數(shù)。
• 了解每家店附近的顧客在人口統(tǒng)計學上的特征。
• 了解過去兩年每家店的歷史收益。

?? 再看另外一個例子：

?? 作為一名財務預測人員，我需要系統(tǒng)能夠讓我了解前 10% 的客戶中，每個客戶在每筆交易中的利潤和利潤率，這樣我就能找到最具盈利能力的交易具備哪些特征。

?? 這個用戶故事看似合理，卻包含了相對復雜的需求，暫時去除 “前10%“ 和 ”利潤率“ 兩部分，才是一個簡單、短小的用戶故事。

?? 為了讓每個迭代期都能向用戶交付架構完整且達到上線質(zhì)量的功能，需要確保用戶故事足夠簡單、短小，這也意味著這些用戶故事不夠成熟，可能需要幾個成功的迭代期來不斷完善。

5.3.4 故事優(yōu)先級

??用戶故事放在設定好優(yōu)先級的產(chǎn)品待辦事項列表上進行管理。用戶故事評定優(yōu)先級與其他敏捷行為一樣，也是一個逐步遞增和迭代的過程，一開始可以比較粗略，然后再逐步深入細節(jié)來加以區(qū)分。評定優(yōu)先級的方法通常有兩種：

（1）基于價值評定優(yōu)先級

??敏捷分析的目標是持續(xù)不斷地為客戶/用戶交付高價值、高質(zhì)量、可用的軟件，這使得評定優(yōu)先級的首要考慮因素便是價值，但同時還要考慮開發(fā)成本和風險，因此一個基于價值的優(yōu)先級評定模型應如下：

1. 首先完成高價值、高風險的故事（如果它們的開發(fā)成本合理）。
2. 接著完成高價值、低風險的故事（如果它們的開發(fā)成本合理）。
3. 最后完成低價值、低風險的故事。
4. 舍棄低價值、高風險的故事。

（2）基于主題或功能評定優(yōu)先級

??當項目包含數(shù)量龐大的用戶故事時，按主題或功能進行分組，可以區(qū)分不同組用戶故事的優(yōu)先級，同時可以通過發(fā)布周期的主題，將非相關的用戶故事評定為較低的優(yōu)先級，保證屬于該主題或功能用戶故事被優(yōu)先開發(fā)。

5.3.5 待辦事項管理

??在為用戶故事放入待辦事項列表并評定好優(yōu)先級后，需要對其進行持續(xù)地維護和管理。按從高到低的順序?qū)⒂脩艄适屡湃氲趦?nèi)進行開發(fā)，對完成并通過驗收測試的用戶故事打上標簽并歸檔。若在開發(fā)期間出現(xiàn)新的需求信息，那么優(yōu)先級和對用戶故事的理解都有可能過時或發(fā)生變化，需要及時加以調(diào)整，保持待辦事項對用戶故事的最新理解和新的優(yōu)先級的體現(xiàn)。

5.4 小結

?? 敏捷分析開發(fā)相較于傳統(tǒng)的 DW/BI 開發(fā)方式，更加關注盡早且持續(xù)地交付給用戶高價值、高質(zhì)量、可用的功能，關注用戶以及他們想要做什么的用戶故事。因此，在敏捷分析開發(fā)過程中，使用用戶故事替代傳統(tǒng)的功能性需求分析，正如本章第3節(jié)所展示的那樣，通過識別用戶角色、用例建模、梳理用戶故事逐步完善更多細節(jié)，并保證用戶故事的撰寫符合 INVEST 原則，足夠短小、簡單，能在單個迭代期內(nèi)完成，然后設置故事優(yōu)先級和管理待辦事項。