5.1 敏捷分析

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

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

5.1.1 幾個(gè)常見(jiàn)誤解

敏捷意味著更快地完成項(xiàng)目

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

敏捷只是少部分人的事

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

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

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

敏捷不需要嚴(yán)謹(jǐn)和確保質(zhì)量

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

5.1.2 敏捷分析特征

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

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

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

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

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

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

也就是說(shuō)，盡管右項(xiàng)有其價(jià)值，我們更重視左項(xiàng)的價(jià)值。

5.2 用戶故事

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

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

5.2.1 用戶故事概述

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

一件用戶通過(guò)系統(tǒng)實(shí)現(xiàn)他的一個(gè)有價(jià)值的目標(biāo)的事，就是一個(gè)用戶故事，即從用戶角度進(jìn)行描述的故事。

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

??用戶故事通常按照如下的格式來(lái)表達(dá)：

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

??舉例如下：

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

??當(dāng)然，用戶故事也可以按照如下的格式來(lái)表達(dá)：

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

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

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

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

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

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

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

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

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

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

• Independent：獨(dú)立性

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

• Negotiable：可協(xié)商

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

• Valuable：有價(jià)值

??用戶故事必須對(duì)于終端用戶是有價(jià)值的，因此應(yīng)該站在用戶的角度去編寫，描述的是 feature，而非 task。

• Estimable：可評(píng)估

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

• Small：短小

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

• Testable：可測(cè)試

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

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

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

5.2.4 用戶故事是需求的代表

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

5.3 敏捷分析中的用戶故事

?? 下面將會(huì)通過(guò)一個(gè)虛構(gòu)的例子，展示如何在敏捷分析開(kāi)發(fā)的過(guò)程中運(yùn)用用戶故事。

5.3.1 識(shí)別用戶角色

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

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

??通過(guò)頭腦風(fēng)暴收集第一批用戶角色，并將用戶角色列出來(lái)：

收集用戶角色

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

用戶角色分組

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

歸納用戶角色

完善用戶角色

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

5.3.2 用例建模

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

用例圖示例

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

用例細(xì)節(jié)示例

??一個(gè)簡(jiǎn)單的用例可以直接寫成用戶故事，例如“登錄 BI 應(yīng)用”這個(gè)用例就可以簡(jiǎn)單地寫成一則用戶故事：

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

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

5.3.3 拆分用戶故事

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

?? 下面舉兩個(gè)例子：

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

?? 這是一個(gè)典型的包含了多個(gè)用戶故事的集合，實(shí)際上，該故事表達(dá)的是：

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

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

?? 再看另外一個(gè)例子：

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

?? 這個(gè)用戶故事看似合理，卻包含了相對(duì)復(fù)雜的需求，暫時(shí)去除 “前10%“ 和 ”利潤(rùn)率“ 兩部分，才是一個(gè)簡(jiǎn)單、短小的用戶故事。

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

5.3.4 故事優(yōu)先級(jí)

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

（1）基于價(jià)值評(píng)定優(yōu)先級(jí)

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

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

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

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

5.3.5 待辦事項(xiàng)管理

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

5.4 小結(jié)

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