本文介紹了一種新的企業(yè)級(jí)敏捷框架——業(yè)務(wù)驅(qū)動(dòng)型敏捷（Business-driven Agile）與 PRT（Product Requirement Team），旨在解決傳統(tǒng)敏捷方法中需求定義的瓶頸凡恍，從而提升產(chǎn)品價(jià)值并提高開(kāi)發(fā)效率锐极。原文: A new enterprise Agile framework: Business-driven Agile with PRT (Product Requirement Team)

在作為 Scrum Master 改造了幾個(gè)敏捷項(xiàng)目之后茵宪，我意識(shí)到所有項(xiàng)目都面臨著相同的瓶頸轿偎，那就是“需求應(yīng)該由誰(shuí)定義狭魂？”以及“如何高效定義需求拌屏？”盡管官方 Scrum 指南明確指出潮针，產(chǎn)品負(fù)責(zé)人（Product Owner）負(fù)責(zé)產(chǎn)品 Backlog 的管理，但并沒(méi)有明確誰(shuí)應(yīng)該定義需求以及如何定義需求倚喂。通常情況下每篷，由于頻繁的會(huì)議和溝通，產(chǎn)品負(fù)責(zé)人無(wú)暇定義所有詳細(xì)需求端圈，而由開(kāi)發(fā)人員定義則會(huì)減少開(kāi)發(fā)時(shí)間焦读，降低開(kāi)發(fā)速度。值得注意的是舱权，當(dāng)項(xiàng)目規(guī)模擴(kuò)大時(shí)矗晃，這個(gè)問(wèn)題會(huì)變得更加突出。因此宴倍，本文將創(chuàng)建一個(gè)新的企業(yè)級(jí)敏捷框架张症，名為“業(yè)務(wù)驅(qū)動(dòng)型敏捷與 PRT（產(chǎn)品需求團(tuán)隊(duì)）”（簡(jiǎn)而言之，業(yè)務(wù)驅(qū)動(dòng)敏捷）鸵贬，以解決這一問(wèn)題俗他。

什么是采用 PRT 的業(yè)務(wù)驅(qū)動(dòng)型敏捷框架？

業(yè)務(wù)驅(qū)動(dòng)型敏捷框架是一種新的企業(yè)級(jí)敏捷框架阔逼，它設(shè)置了 PRT（Product Requirement Team兆衅，產(chǎn)品需求團(tuán)隊(duì)），明確了如何有效定義需求，以提高效率并最大化產(chǎn)品價(jià)值羡亩。如前所述摩疑，業(yè)務(wù)驅(qū)動(dòng)型敏捷的主要目的是簡(jiǎn)化需求定義過(guò)程，而這往往是開(kāi)發(fā)的瓶頸夕春，據(jù)我所知目前還沒(méi)有相關(guān)框架未荒。

業(yè)務(wù)驅(qū)動(dòng)型敏捷基于 Scrum专挪，因此繼承了 Scrum 的價(jià)值觀及志、角色和實(shí)踐。業(yè)務(wù)驅(qū)動(dòng)型敏捷可用于單個(gè) Scrum 團(tuán)隊(duì)寨腔，但在大規(guī)模團(tuán)隊(duì)中效果更好速侈，因?yàn)樾枨蠖x過(guò)程往往是瓶頸。要了解業(yè)務(wù)驅(qū)動(dòng)型敏捷如何運(yùn)作迫卢，需要了解如何定義需求和附加角色倚搬，下面將對(duì)此進(jìn)行解釋。

需求的 3 個(gè)基本組成部分

在不同軟件項(xiàng)目中乾蛤，定義需求的方法大相徑庭每界，很多人都有自己的方法。然而家卖，除非有令人信服的理由眨层，否則應(yīng)避免使用獨(dú)創(chuàng)的方法，因?yàn)檫@些方法通常無(wú)效上荡，會(huì)造成重復(fù)勞動(dòng)趴樱，應(yīng)該盡量遵循最佳實(shí)踐。

業(yè)務(wù)驅(qū)動(dòng)型敏捷定義了定義需求的三個(gè)基本組成部分：用戶故事（User Story）酪捡、驗(yàn)收標(biāo)準(zhǔn)（Acceptance Criteria）和視覺(jué)圖像（Visual Image）叁征。長(zhǎng)期以來(lái)，用戶故事和驗(yàn)收標(biāo)準(zhǔn)一直作為敏捷最佳實(shí)踐被廣泛應(yīng)用逛薇，而視覺(jué)圖像則是軟件項(xiàng)目中普遍需要的捺疼。

用戶故事

用戶故事（User Story）是一個(gè)簡(jiǎn)單的單行句子，概括的描述了用戶想用產(chǎn)品做什么以及為什么永罚。它最初是作為 XP（極限編程）的實(shí)踐之一而產(chǎn)生帅涂，并被用于各種敏捷框架中，這是一種涵蓋所有重要方面（誰(shuí)尤蛮、做什么媳友、為什么）的強(qiáng)大描述。首先創(chuàng)建用戶故事产捞，然后根據(jù)用戶故事進(jìn)行討論醇锚。用戶故事有標(biāo)準(zhǔn)格式，如下面的登錄示例。

[結(jié)構(gòu)] 作為……焊唬，我希望……恋昼，以便……。

[示例] 作為用戶赶促，我想用電子郵件和密碼登錄平臺(tái)液肌，以便安全的使用平臺(tái)。

驗(yàn)收標(biāo)準(zhǔn)

驗(yàn)收標(biāo)準(zhǔn)是支持用戶故事的詳細(xì)要求鸥滨，將用于驗(yàn)收測(cè)試嗦哆。這意味著驗(yàn)收標(biāo)準(zhǔn)扮演了兩種角色：詳細(xì)需求和驗(yàn)收測(cè)試。這種方法非常有效婿滓，因?yàn)樵谄俨际巾?xiàng)目中老速，它們通常是分開(kāi)編寫(xiě)的，這會(huì)造成工作和文檔的重復(fù)凸主。首先編寫(xiě)驗(yàn)收標(biāo)準(zhǔn)被稱(chēng)為 BDD（Behaviour-Driven Development橘券，行為驅(qū)動(dòng)開(kāi)發(fā)），其概念源于 TDD（Test-Driven Development卿吐，測(cè)試驅(qū)動(dòng)開(kāi)發(fā)）旁舰，明確了產(chǎn)品應(yīng)如何滿足用戶的期望。

編寫(xiě)有效的驗(yàn)收標(biāo)準(zhǔn)是業(yè)務(wù)驅(qū)動(dòng)型敏捷的關(guān)鍵嗡官，因?yàn)檫@是最具挑戰(zhàn)性的過(guò)程箭窜，需要技巧和時(shí)間。說(shuō)到由誰(shuí)來(lái)寫(xiě)谨湘，總是會(huì)引起爭(zhēng)議绽快。雖然產(chǎn)品負(fù)責(zé)人是合適的人選，但他往往忙于工作紧阔，無(wú)暇編寫(xiě)驗(yàn)收標(biāo)準(zhǔn)坊罢。由開(kāi)發(fā)人員編寫(xiě)則會(huì)減少編碼時(shí)間，降低開(kāi)發(fā)速度擅耽。因此活孩，以業(yè)務(wù)為導(dǎo)向的敏捷技術(shù)設(shè)置了一個(gè)新角色：需求定義者（Requirement Definers），稍后將對(duì)此進(jìn)行解釋乖仇。

強(qiáng)烈推薦使用 Cucumber 創(chuàng)始人 Aslak Helles?y 創(chuàng)建的 “小黃瓜語(yǔ)法（Gherkin Syntax” 來(lái)編寫(xiě)驗(yàn)收標(biāo)準(zhǔn)憾儒，它涵蓋了所有必要的方面：Given（條件）、When（操作）乃沙、Then（結(jié)果）起趾。

[描述] “情景（Scenario）”描述測(cè)試（需求）的內(nèi)容【澹“給定（Given）”描述用戶采取任何行動(dòng)前的初始情境或狀態(tài)训裆】舾“當(dāng)（When）”描述用戶采取的行動(dòng)”吡穑“然后（Then）”描述用戶行動(dòng)的預(yù)期結(jié)果或后果属百。

[示例] 場(chǎng)景：成功登錄。給定：用戶擁有平臺(tái)賬戶变姨。當(dāng)：用戶輸入電子郵件地址和密碼族扰。然后：按下登錄按鈕。 然后：成功登錄平臺(tái)定欧。

視覺(jué)圖像

視覺(jué)圖像能讓團(tuán)隊(duì)成員對(duì)需求有共同的理解渔呵。它可以采取任何形式，如草圖忧额、線框或復(fù)雜的設(shè)計(jì)厘肮，只要能幫助團(tuán)隊(duì)成員直觀理解產(chǎn)品的外觀和工作方式即可愧口。由于“用戶故事”和“驗(yàn)收標(biāo)準(zhǔn)”是基于文本的表達(dá)方式睦番，其效果有限，而視覺(jué)圖像則可以彌補(bǔ)這一不足耍属。人類(lèi)是高度視覺(jué)導(dǎo)向的動(dòng)物托嚣，因此呈現(xiàn)視覺(jué)圖像有助于我們加深理解。

PRT（產(chǎn)品需求小組）

PRT 負(fù)責(zé)需求定義并將其正確傳達(dá)給開(kāi)發(fā)人員厚骗。PRT 由產(chǎn)品負(fù)責(zé)人示启、需求定義者和設(shè)計(jì)者組成。下圖展示了 PRT 與 Scrum 團(tuán)隊(duì)的組成领舰。

產(chǎn)品負(fù)責(zé)人

產(chǎn)品負(fù)責(zé)人（Product Owner）的角色與標(biāo)準(zhǔn) Scrum 相同，負(fù)責(zé)明確需求并做出決策。雖然設(shè)計(jì)人員和需求定義人員會(huì)幫助產(chǎn)品負(fù)責(zé)人定義需求赶掖，但產(chǎn)品負(fù)責(zé)人是唯一的決策點(diǎn)镊靴，從而避免決策過(guò)程的混亂。

產(chǎn)品負(fù)責(zé)人與設(shè)計(jì)師锉桑、需求定義者排霉、Scrum 團(tuán)隊(duì)和利益相關(guān)者密切溝通，因此他的主要工作就是與人溝通民轴。

要求定義者

需求定義者（Requirement Definer）是業(yè)務(wù)驅(qū)動(dòng)型敏捷中新定義的職位攻柠，其職責(zé)是通過(guò)與產(chǎn)品負(fù)責(zé)人（Product Owner）和設(shè)計(jì)師密切溝通來(lái)定義詳細(xì)需求。如上所述后裸，詳細(xì)需求被定義為驗(yàn)收標(biāo)準(zhǔn)瑰钮，而需求定義者的主要任務(wù)就是編寫(xiě)驗(yàn)收標(biāo)準(zhǔn)。

雖然理想情況下需求定義者是專(zhuān)職職位微驶，尤其是在大規(guī)模項(xiàng)目中浪谴，但當(dāng)項(xiàng)目無(wú)法聘請(qǐng)專(zhuān)職人員時(shí)，需求定義者也可以兼任其他職位，如測(cè)試人員较店、設(shè)計(jì)人員士八、Scrum Master 等。例如梁呈，如果項(xiàng)目預(yù)算太緊婚度，無(wú)法雇用專(zhuān)職的需求定義者，那么設(shè)計(jì)人員或測(cè)試人員就可以兼任需求定義者官卡，應(yīng)根據(jù)具體業(yè)務(wù)環(huán)境來(lái)定義和分配實(shí)際職責(zé)蝗茁。

設(shè)計(jì)師

設(shè)計(jì)師負(fù)責(zé)繪制草圖、插圖或設(shè)計(jì)圖等視覺(jué)圖像寻咒，供整個(gè)團(tuán)隊(duì)共同理解哮翘。人類(lèi)是高度視覺(jué)導(dǎo)向的動(dòng)物，視覺(jué)圖像有助于我們理解應(yīng)該做什么毛秘。關(guān)鍵一點(diǎn)是饭寺，只要有助于共同的理解，視覺(jué)圖像可以采取任何形式叫挟，其目的是讓每個(gè)人的理解都保持一致艰匙。

整體流程

需求定義的整體流程如下圖所示。通常抹恳，產(chǎn)品負(fù)責(zé)人首先根據(jù)利益相關(guān)者的想法創(chuàng)建用戶故事员凝。然后，設(shè)計(jì)師和需求定義者制作視覺(jué)圖像和驗(yàn)收標(biāo)準(zhǔn)奋献。盡管圖中是順序排列健霹，但通常需要反復(fù)來(lái)回多次。

何時(shí)定義需求

需求定義應(yīng)在 Sprint 之前進(jìn)行瓶蚂，所需時(shí)間與 Sprint 相同糖埋。例如，如果項(xiàng)目 Sprint 為期一周扬跋，那么需求定義應(yīng)該在前一周完成阶捆。這是因?yàn)樾枨蠖x所需時(shí)間通常比我們預(yù)期的要多，而且精確的需求定義對(duì)估算钦听、優(yōu)先級(jí)排序和范圍管理都很重要洒试。

Sprint 計(jì)劃是團(tuán)隊(duì)確定 Sprint Backlog 的地方，Sprint Backlog 是選定的 PBI（Product Backlog Items朴上，產(chǎn)品待辦事項(xiàng)）垒棋，預(yù)計(jì)在即將到來(lái)的 Sprint 中完成。換句話說(shuō)痪宰，在敏捷中叼架，范圍是根據(jù) Sprint 來(lái)控制畔裕，而 Sprint Backlog 就是 Sprint 的實(shí)際范圍。需求乖订、估算和優(yōu)先級(jí)應(yīng)被定義為確定 Sprint Backlog 的輸入扮饶。這意味著團(tuán)隊(duì)不僅要確定需求，還要在前一周確定估算和優(yōu)先級(jí)乍构。由于這些要素相互交織甜无，因此通常需要來(lái)回討論。下圖說(shuō)明了 Sprint 計(jì)劃的整體流程哥遮。

大規(guī)模模式

業(yè)務(wù)驅(qū)動(dòng)型敏捷的設(shè)計(jì)是為了擴(kuò)展岂丘，因?yàn)楫?dāng)項(xiàng)目規(guī)模變大時(shí)，需求定義過(guò)程往往會(huì)成為瓶頸眠饮，不過(guò)可以應(yīng)用于單個(gè)團(tuán)隊(duì)奥帘。雖然 PRT 的架構(gòu)不會(huì)改變，但需求定義者和設(shè)計(jì)者的數(shù)量會(huì)根據(jù) Scrum 團(tuán)隊(duì)的規(guī)模和數(shù)量進(jìn)行調(diào)整仪召。下圖描述了大規(guī)模團(tuán)隊(duì)架構(gòu)寨蹋。

即使項(xiàng)目規(guī)模擴(kuò)大，產(chǎn)品負(fù)責(zé)人仍然是一個(gè)人返咱，而不是委員會(huì)钥庇，以明確誰(shuí)應(yīng)該做出決策牍鞠，防止決策過(guò)程中出現(xiàn)混亂咖摹。

采用 PRT 的業(yè)務(wù)驅(qū)動(dòng)型敏捷實(shí)踐

業(yè)務(wù)驅(qū)動(dòng)型敏捷項(xiàng)目設(shè)置了多種實(shí)踐，以最大限度提高產(chǎn)品價(jià)值和管理效率难述，這些實(shí)踐包括 BDD萤晴、看板和路線圖、無(wú)故事點(diǎn)估算和長(zhǎng)期決策胁后。

BDD（Behaviour-Driven Development店读，行為驅(qū)動(dòng)開(kāi)發(fā)）

BDD 是敏捷最佳實(shí)踐之一，即在編碼前編寫(xiě)帶有驗(yàn)收標(biāo)準(zhǔn)的驗(yàn)收測(cè)試攀芯。BDD 明確了產(chǎn)品的行為方式屯断，以滿足用戶期望以及業(yè)務(wù)人員和軟件工程師之間的共同理解。BDD 是業(yè)務(wù)驅(qū)動(dòng)型敏捷的核心侣诺，是需求的關(guān)鍵要素殖演，能帶來(lái)準(zhǔn)確的估算、決策并防止產(chǎn)生 bug年鸳。如前所述趴久，Gherkin Syntax 被強(qiáng)烈推薦用于實(shí)踐 BDD 和編寫(xiě)驗(yàn)收標(biāo)準(zhǔn)，它是廣泛使用的最佳實(shí)踐搔确。

看板和路線圖

業(yè)務(wù)驅(qū)動(dòng)型敏捷同時(shí)使用看板和路線圖來(lái)管理開(kāi)發(fā)狀態(tài)和長(zhǎng)期業(yè)務(wù)戰(zhàn)略彼棍∶鹬遥看板是一種顯示開(kāi)發(fā)流程和任務(wù)狀態(tài)的可視化板，在敏捷中被廣泛使用座硕〕谧鳎看板適合短期管理，能顯示細(xì)粒度信息华匾。另一方面缆蝉，路線圖適合中長(zhǎng)期管理，能顯示詳細(xì)信息和總體進(jìn)度瘦真，適用于與企業(yè)管理層等利益相關(guān)者進(jìn)行討論刊头。業(yè)務(wù)驅(qū)動(dòng)型敏捷在有效管理的背景下利用了兩者的優(yōu)勢(shì)。

無(wú)故事點(diǎn)估算

業(yè)務(wù)驅(qū)動(dòng)型敏捷從不使用故事點(diǎn)進(jìn)行估算诸尽，因?yàn)楣适曼c(diǎn)有幾個(gè)缺陷原杂。最關(guān)鍵的原因是，故事點(diǎn)無(wú)法支持產(chǎn)品負(fù)責(zé)人的決策您机。雖然估算的最終目的是支持業(yè)務(wù)決策穿肄，但業(yè)務(wù)人員無(wú)法根據(jù)故事點(diǎn)做出決定，因?yàn)樗⒉皇菢?biāo)準(zhǔn)的度量單位际看。業(yè)務(wù)驅(qū)動(dòng)型敏捷的目的是加強(qiáng)業(yè)務(wù)人員與軟件工程師之間的協(xié)作咸产，最大限度提高產(chǎn)品價(jià)值，而故事點(diǎn)并不能幫助實(shí)現(xiàn)這兩點(diǎn)仲闽。

相反脑溢，業(yè)務(wù)驅(qū)動(dòng)型敏捷采用簡(jiǎn)單、標(biāo)準(zhǔn)的計(jì)量單位赖欣，如小時(shí)屑彻、天或周，以便于理解顶吮。只要能支持業(yè)務(wù)決策并讓團(tuán)隊(duì)成員理解社牲，可以采用任何單位。

長(zhǎng)期決策

20 世紀(jì) 60 年代末和 70 年代初悴了，人們做了一個(gè)著名的實(shí)驗(yàn)搏恤，叫做“棉花糖試驗(yàn)”，這個(gè)實(shí)驗(yàn)一直被人們討論和銘記湃交。一位教授把孩子們一個(gè)個(gè)放在小房間里熟空，桌子上放著一個(gè)棉花糖，并告訴他們：“如果你們能等上 15 分鐘巡揍，就能得到兩個(gè)棉花糖痛阻。如果等不及，就只能得到一個(gè)”腮敌。有些孩子能等上 15 分鐘阱当，有些孩子卻等不了俏扩。教授對(duì)這些孩子進(jìn)行了長(zhǎng)達(dá)數(shù)十年的跟蹤調(diào)查，結(jié)果發(fā)現(xiàn)弊添，與不能等待的孩子相比录淡，能等待的孩子在經(jīng)濟(jì)穩(wěn)定、學(xué)業(yè)成績(jī)和事業(yè)成功方面都更勝一籌油坝。實(shí)驗(yàn)證明嫉戚，“延遲滿足”和“耐心”有助于取得長(zhǎng)期成功。

業(yè)務(wù)驅(qū)動(dòng)型敏捷采用“延遲滿足”和“耐心”澈圈，從長(zhǎng)遠(yuǎn)角度思考和決策彬檀，因?yàn)檐浖?xiàng)目通常是長(zhǎng)期的，而長(zhǎng)遠(yuǎn)思考會(huì)帶來(lái)成功瞬女。例如窍帝，人們往往會(huì)被拖著開(kāi)發(fā)新功能，認(rèn)為這是“即時(shí)滿足”诽偷，而拖延重構(gòu)坤学、重新設(shè)計(jì)數(shù)據(jù)庫(kù)和基礎(chǔ)設(shè)施，或教育下一任領(lǐng)導(dǎo)者报慕。雖然后者不能立竿見(jiàn)影深浮，但從長(zhǎng)遠(yuǎn)看，它們會(huì)產(chǎn)生巨大影響眠冈。下圖是“影響力矩陣（Impact Effort Matrix）”飞苇，描述了在短期和長(zhǎng)期內(nèi)哪些是重要的，哪些是不重要的洋闽。

結(jié)論

采用 PRT（產(chǎn)品需求團(tuán)隊(duì)）的業(yè)務(wù)驅(qū)動(dòng)型敏捷框架是一種新的企業(yè)級(jí)敏捷框架玄柠，可簡(jiǎn)化需求定義流程（該流程往往成為軟件開(kāi)發(fā)的瓶頸），并最大限度的提高產(chǎn)品價(jià)值诫舅。由誰(shuí)來(lái)定義需求一直是個(gè)有爭(zhēng)議的問(wèn)題，因?yàn)闆](méi)有一個(gè)敏捷框架能明確這一點(diǎn)宫患。業(yè)務(wù)驅(qū)動(dòng)型敏捷通過(guò)設(shè)置 PRT 和描述如何定義需求來(lái)解決這個(gè)問(wèn)題刊懈。

PRT 由產(chǎn)品負(fù)責(zé)人、需求定義者和設(shè)計(jì)者組成娃闲。產(chǎn)品負(fù)責(zé)人的角色與標(biāo)準(zhǔn) Scrum 并無(wú)不同虚汛，其主要職責(zé)是做出決策，最大限度提高產(chǎn)品價(jià)值皇帮。需求定義者是新設(shè)立的角色卷哩，他們通過(guò)與產(chǎn)品負(fù)責(zé)人密切溝通，定義帶有驗(yàn)收標(biāo)準(zhǔn)的詳細(xì)需求属拾。設(shè)計(jì)人員制作視覺(jué)圖像将谊，以便共同理解產(chǎn)品的外觀和性能冷溶。

業(yè)務(wù)驅(qū)動(dòng)型敏捷還建立了一些實(shí)踐：BDD、看板和路線圖尊浓、無(wú)故事點(diǎn)估算和長(zhǎng)期決策逞频。BDD 是源于 TDD（測(cè)試驅(qū)動(dòng)開(kāi)發(fā)）的一種軟件開(kāi)發(fā)實(shí)踐，在編碼前定義了產(chǎn)品應(yīng)如何滿足用戶期望栋齿∶缯停看板有助于將開(kāi)發(fā)過(guò)程和任務(wù)狀態(tài)可視化，以管理短期開(kāi)發(fā)瓦堵，而路線圖則通過(guò)消除細(xì)粒度信息來(lái)描述長(zhǎng)期計(jì)劃的概況基协。避免使用故事點(diǎn)，因?yàn)樗鼈儗?duì)業(yè)務(wù)不友好菇用，不能支持業(yè)務(wù)決策堡掏，而這正是估算的最終目的。最后刨疼，團(tuán)隊(duì)?wèi)?yīng)決定長(zhǎng)期計(jì)劃泉唁，因?yàn)檐浖_(kāi)發(fā)不是短跑，而是馬拉松揩慕，延遲滿足將對(duì)長(zhǎng)期發(fā)展產(chǎn)生巨大影響亭畜。

你好，我是俞凡迎卤，在Motorola做過(guò)研發(fā)拴鸵，現(xiàn)在在Mavenir做技術(shù)工作，對(duì)通信蜗搔、網(wǎng)絡(luò)劲藐、后端架構(gòu)、云原生樟凄、DevOps聘芜、CICD、區(qū)塊鏈缝龄、AI等技術(shù)始終保持著濃厚的興趣汰现，平時(shí)喜歡閱讀、思考叔壤，相信持續(xù)學(xué)習(xí)瞎饲、終身成長(zhǎng)，歡迎一起交流學(xué)習(xí)炼绘。為了方便大家以后能第一時(shí)間看到文章嗅战，請(qǐng)朋友們關(guān)注公眾號(hào)"DeepNoMind"，并設(shè)個(gè)星標(biāo)吧俺亮，如果能一鍵三連(轉(zhuǎn)發(fā)驮捍、點(diǎn)贊疟呐、在看)，則能給我?guī)?lái)更多的支持和動(dòng)力厌漂，激勵(lì)我持續(xù)寫(xiě)下去萨醒，和大家共同成長(zhǎng)進(jìn)步！

本文由mdnice多平臺(tái)發(fā)布