【萬字長文】用戶故事拆分終極指南 | IDCF

時間 2021-06-01

標籤數據庫編程 segmentfault 後端性能優化架構 dom 工具性能學習欄目 SQL 简体版

原文原文鏈接

本指南內容

1、爲何故事拆分很重要
2、什麼樣的用戶故事纔算是恰當的故事？
2.1 用戶故事格式
2.2 恰當的故事應遵循INVEST原則
2.3 用戶故事是垂直切片
3、故事拆分流程圖
步驟1：準備好要拆分的故事/特性
步驟2：套用拆分模式
3.3 步驟3：評估拆分效果
4、Cynefin和故事拆分
5、練習故事拆分
6、垂直切片和規模化
6.1 是否應該讓100+的人去開發一個產品？
6.2 規模化垂直切片的基線數據庫

1、爲何故事拆分很重要

從優先級最高的、工做量較小的用戶故事開始開發，可讓產品團隊持續輸出高價值的產物，並得到高質量的反饋。許多團隊都在努力將較大的用戶故事和特性（feature）拆分紅恰當的小故事，可是他們沒有從業務的垂直切片來拆分，而是從整個技術架構的的角度，拆分出了不少看起來更像研發任務（Task）或組件（Component）的故事，最終致使他們未能體驗到小故事應有的價值或反饋。編程

幸運的是，故事拆分是一種能夠在較短的時間內學會的技能。咱們已經看到，團隊僅需幾個小時的練習和一些簡單的工具，就能夠從掙扎中解脫出來，快速地拆分故事。稍後，咱們將介紹如何組織這種練習。segmentfault

2、什麼樣的用戶故事纔算是恰當的故事？

在討論拆分用戶故事以前，咱們須要確保咱們對什麼樣的用戶故事纔算是恰當的故事、以及能夠將哪些內容拆分爲故事有一個共同的理解。後端

首先，讓咱們看下用戶故事的定義：用戶故事是從用戶的角度描述系統行爲的變化。它描述的是用戶想經過系統作的事情，或者但願系統爲他們作的事情，而這些事情如今的系統裏尚未。性能優化

順便說一下，請注意，用戶故事位於方案域（solution space）而不是問題域（problem space）。它不是一我的想在某個地方完成一個任務的描述（就像JTBD[Job to be Done，待完成的工做]同樣），而是一我的想要在你的系統中完成某件事情的描述。JTBD在問題域中能夠與客戶產生很好的共鳴，而用戶故事能夠很好地將客戶的共鳴轉化爲對軟件系統的一系列改變，同時在整個交付過程當中保持客戶的視角。架構

2.1 用戶故事格式

你可能常常會看到以以下特定格式書寫的用戶故事：dom

做爲角色
我想要功能或行動
以實現價值或目標

或者有的是這樣：工具

爲了價值或目標
做爲角色
我想要功能或行動

該模板的優勢在於它要求你回答用戶故事中的三個問題：性能

它是給誰（WHO）使用的？
他們想要作什麼（WHAT），或者讓系統作什麼，而這些功能如今都尚未？
他們爲何（WHY）要這樣作？

不過，重要的不是模板，而是回答這三個問題。學習

實際上，咱們不多會用完整的模板來寫故事。不管是在便籤紙的頂部仍是在在線項目管理工具的標題字段裏，一個寫着「WHAT」的簡短標題都會是比較好的選擇。「WHAT」由標題提供，而「WHO」一般由產品願景或版本目標提供，它描述了核心目標客戶。若是故事是爲該目標客戶準備的，咱們就不重複撰寫了，咱們只有在爲非核心目標客戶撰寫用戶故事時，才把「WHO」加上。最後，咱們將確保在在線工具的「詳細描述」或相似的字段中，或者在便籤紙上用較淺的字體寫明「WHY」。

所以，若是咱們要作一個公共圖書館的網站，而且圖書館的讀者是咱們的默認用戶，則咱們不會這樣來書寫用戶故事：

做爲圖書館的讀者，
我想按書名搜索一本書，
以便我能在搜索結果中毫無干擾地找到我想要的書。

咱們會這樣來寫：

按書名精確查找
由於我知道我想要的具體書籍，因此我不但願在搜索結果中出現干擾

有時咱們會遇到將單獨的研發任務或架構組件假裝成用戶故事的狀況。即便你使用了諸如「做爲開發人員，我想要一份數據庫關係圖，以便我能瞭解數據庫的結構」這樣的神奇描述，它仍然只是一個開發任務。

2.2 恰當的故事應遵循INVEST原則

幾年前，極限編程先驅Bill Wake提出了一個很好的首字母縮略詞，用來表示一個恰當的用戶故事應具備的6個關鍵屬性：INVEST。讓咱們來挨個看一下：

I表明INDEPENDENT（獨立的）。這意味着一個恰當的故事可以足夠的獨立，它能夠不用考慮技術依賴就能夠排定優先級。有時，這意味着須要暫時提供一些Mock數據或接口，以即可以獨立測試故事，讓你在項目的早期就能更快地得到價值或下降風險。
N表明NEGOTIABLE（可協商的）。一個恰當的故事會爲作什麼、如何作等細節留下協商的空間。固然，隨着協商的進行、更多細節的敲定，故事的可協商性就會下降。
V表明VALUABLE（有價值的）。每一個故事都應該爲用戶增長一些可見的價值增量。現階段這彷佛是不可能的，由於你的Product Backlog裏可能有大量的技術組件和基礎架構的任務，這些技術任務假裝成了用戶故事，但這並不能直接爲用戶增長價值。隨着你故事拆分技能的不斷成長，你能更好地找到能直接提供價值的、短小的功能切片。

（故事並不須要單獨提供足夠的價值來直接發佈。你可能須要積累多個故事，才能從有價值轉變爲可銷售。我喜歡最小可銷售特性（MMF，Minimum Marketable Features）做爲故事的容器。）

E表明ESTIMABLE（可估算的）。一個恰當的故事應該定義到足以讓團隊可以估算它的工做量，這個工做量通常是相對於一個基準故事所作的相對估算。
S表明SMALL（短小的）。經驗告訴咱們，對於一個已排序的Product Backlog，你應該可以將優先級最高的6到10個故事排入下一個Sprint中。這樣作既能常常得到反饋和管理風險，同時也不須要管理太多的故事。不過這個故事數量只是一個建議，它會隨着Sprint長度、團隊規模、團隊速率等因素按比例縮放。
T表明TESTABLE（可測試的）。咱們應該有辦法知道咱們已經完成了某個故事。它不能只是一個模糊的指望，而須要是系統行爲的具體變化。

固然，這些屬性之間存在着必定的互斥關係。好比說，隨着故事的規模變小，使其變得獨立且有價值的難度就會變大；隨着故事的可協商性變大，其可估算和可測試的難度就會變大。

不過幸運的是，不一樣的屬性在不一樣的時間起主要做用。例如在進入Sprint計劃後，更重要的是故事要短小、可估算和可測試。這時咱們仍然須要故事有必定的獨立性、可協商性和有價值，但這些屬性這時已經變得不那麼重要了。而在Product Backlog中的故事，狀況偏偏相反。

2.3 用戶故事是垂直切片

在提到恰當的故事時，你常常會聽到垂直切片（vertical slice）這個詞。這是恰當的故事在軟件架構方面的要求。

垂直切片是指「一個能給系統行爲帶來變化的有價值的工做項，它可能要觸及多個架構層級（architectural layers）來實現這個變化」。當你把這個切片（slice）稱爲「完成」時，該系統對於用戶而言顯然更有價值。
水平切片（horizontal slice）與垂直切片恰好相反，它是指「對一個組件（component）或架構層級（architectural layer）進行更改的工做項，它須要結合其餘組件或架構層級的改變，才能對用戶交付可感知的價值」。

咱們來看一個很是簡單的系統架構，這裏有UI層、業務邏輯層和持久層。你的系統可能比這更復雜，但它可能至少包含這三層。

（系統架構示意圖）

要想得到INVEST的大部分屬性，故事必然會涉及這3個架構層級。若是不進行某些UI的改變、邏輯的改變、持久存儲的改變，咱們可能就沒法交付價值。所以，故事就是系統的一個垂直切片。

有時候，這些垂直切片很是寬。當咱們進行故事拆分時，咱們將討論如何在較寬的垂直切片中找到較薄的垂直切片。可是到目前爲止，咱們只須要知道故事應該在必要時跨越架構層級來提供價值就足夠了。

許多剛組建的敏捷團隊會嘗試按照架構層級來拆分故事：一個故事用來實現UI，另外一個故事用於更新數據庫等等。雖然這個故事可能也很小，但在獨立性和價值交付上是失敗的。當團隊以垂直切片的方式拆分時，他們將會獲得以下收益：

使Backlog的價值明確
進行更多關於價值的對話
有助於避免意外地創建低價值的變動
更快得到價值
更早得到更高質量的反饋
更容易看到約束和待辦，並能作出相應的響應
交付價值時變得更加可預測（由於可工做的軟件是進度的首要度量標準）

咱們還能夠繼續說下去，但這些應該已經能夠給你一些啓發了。當咱們一塊兒坐下來，寫下咱們在成功的敏捷團隊中看到的各類習慣，以及各個習慣之間的關係時，咱們發現垂直切片幾乎與全部其餘習慣有關，或至少與部分習慣有關。

看看Product Backlog中的故事，有些是你最近完成的，有些是未來要作的。根據INVEST標準評估每個故事，找出垂直切片和非垂直切片的故事。而後，看看你是否能夠改進這些故事。

3、故事拆分流程圖

爲了方便咱們更好地指導團隊，Richard建立了一個故事拆分流程圖，該流程圖介紹了咱們在幫助團隊拆分故事時要問的問題。

（用戶故事拆分流程縮略圖）

讓咱們分別看一下圖中的三個步驟：

步驟1：準備好要拆分的故事/特性

（準備待拆分的故事）

首先要確保你要拆分的故事/特性知足INVEST標準（短小的（Small）除外）。大多數狀況下，有價值的（Valuable）是問題所在。當人們把他們認爲是「不可拆分」的故事帶給咱們時，它們實際上是假裝成故事的開發任務或架構組件。若是你不從增長價值的角度入手，就沒法將其拆分並得到價值增量。在這種狀況下，下一步就是將非故事（non-story）與其餘水平切片結合起來，這樣，它們才能夠共同表明一個價值增量。接下來，是否是切片太大了？若是是的話，就能夠開始拆分了。

步驟2：套用拆分模式

（套用拆分模式）

模式1：按工做流程步驟拆分

（按工做流程步驟拆分）

這是個人客戶在建立一個內容管理系統的故事：

做爲內容管理員，我能夠將新聞發佈到公司網站。

聽起來故事並不大——直到咱們深刻研究了發佈新聞的工做流程。結果發現，僅僅是把一個幾句話的新聞發佈到公司網站上，就須要編輯和法律部門的批准，以及在預發佈網站上作發佈前的最終審覈。像這樣的6-10個故事不可能在一次迭代中完成。

在這樣的工做流程中，最大的價值每每來自於開頭和結尾。中間的步驟會增長增量價值，但並不獨立。因此先構建簡單的端到端案例，而後再添加中間步驟和特殊案例，效果會很好。

新的故事包括：

…我能夠直接將新聞發佈到公司網站上。
…我能夠在發佈新聞前作一下編輯審覈。
…我能夠在發佈新聞前作一下法律審覈。
…我能夠在預發佈網站上查看新聞。

…我能夠將一篇新聞報道從預發佈網站發佈到正式網站。

但有時，整個工做流程都很重要，你不能只從開頭和結尾開始。在這些狀況下，尋找一個貫穿整個工做流的薄薄的切片。也許它支持最多見的狀況；也許你能夠硬編碼或以其餘方式簡化工做流中最容易理解的部分，而後你才能探索更復雜的部分。

不管哪一種方式，最明顯的拆分——從頭至尾按功能模塊一步一步執行——都是錯誤的方式。查看個人80/20產品全部權課程的這段摘錄，瞭解更多關於爲何這種拆分是錯誤的，以及如何使用其餘兩種方法。

模式2：按不一樣的業務規則拆分

（按不一樣的業務規則拆分）

這個故事中隱藏着一些一樣複雜的故事，這些故事使用不一樣的業務規則來完成同一件事：

做爲一個用戶，我可使用靈活的日期規則搜索航班。

深刻研究「靈活的日期規則」，會發現有好幾種不一樣的業務規則，每一個規則均可以單獨成爲一個恰當的故事：

「日期X和日期Y之間的N天」。
「12月的某個週末」。
「日期Z的先後N天」。

模式3：按主要工做拆分

（按主要工做拆分）

有時，一個故事能夠拆分爲幾個部分，其中大部分的精力會去實現第一個部分。例如這個信用卡支付的故事：

做爲用戶，我能夠用VISA、MasterCard、Diners Club或American Express支付機票費用。

這個故事能夠再拆分爲四個故事，每種信用卡一個故事。可是，在處理第一個故事的時候就要創建起信用卡交易的基礎架構；增長更多的信用卡類型時這方面的工做就會相對較小了。咱們能夠估算第一個故事的規模大於其餘三個故事，可是若是產品負責人後來改變了優先級，咱們就必須記得要改變咱們的估算。相反，咱們能夠以下述所示，推遲決定哪一種卡的類型先被實現：

…我可使用一種信用卡類型（VISA，MC，DC，AMEX）付款。
…我可使用全部四種信用卡類型（VISA，MC，DC，AMEX）付款（前提是已經實施了一種信用卡類型）。

這兩個新的故事仍然不是獨立的，但依賴性會比爲每一種信用卡類型編寫一個故事要清晰得多。

模式4：按簡單/複雜拆分

（按簡單/複雜拆分）

當你在計劃會上討論一個故事時，故事彷佛愈來愈大（"X怎麼辦？"、"你考慮過Y嗎？"），這時候你應該停下來，詢問下你們：「最簡單的版本是什麼？」把這個簡單的版本寫成用戶故事。你可能必須在現場定義一些驗收標準以保持簡單。而後，把全部的變化和複雜性拆分紅其它的故事。好比這個故事：

做爲用戶，我能夠搜索兩個目的地之間的航班。

經過像下面的方式拆分變化來保持簡單：

...指定最大中轉次數。
...包括附近的機場。
...使用靈活的日期篩選規則。
...等等。

模式5：按不一樣類型的數據拆分

（按不一樣類型的數據拆分）

故事中的複雜性可能來自於處理數據的變化。例如，我當前正在開發的系統須要對運輸服務提供商所服務的地理區域進行建模。僅僅是處理複雜的服務區域的地理學知識，咱們就可能燒掉整個項目的預算。當我講完這個故過後：

做爲用戶，我能夠根據行程的始發地和目的地來搜索運輸服務提供商。

與產品負責人討論後發現，雖然咱們不須要成熟的GIS，但對地理環境進行建模仍然很是複雜。咱們停下來反思：「什麼是‘足夠好’的地理建模方案，以便咱們如今就能夠構建其餘高價值的功能？」咱們選擇了：

做爲用戶，我能夠按行程的始發地（市）和目的地（市）搜索運輸服務提供商。

這在一段時間內是沒問題的，直到咱們收集了更多的數據，發現有些服務提供商只服務於某些縣城甚至鄉鎮。因而一個新的故事出現了：

做爲用戶，我能夠按行程的始發地（如市、縣、鄉/鎮、街道）和目的地（如市、縣、鄉/鎮、街道）搜索運輸服務提供商。

在查看新的服務提供商數據時，咱們還發現，有些服務提供商會支持出發地爲單一城市，但終點爲周邊任意多個城市的行程。這就引出了下面這個故事：

服務提供商能夠爲行程的始發地和目的地提供不一樣的地理區域。

這三個故事都是從原來的地理故事中拆分出來的。這裏的區別是，咱們在構建最簡單的版本後，及時添加了新的故事。但有些狀況下，你在項目前期就能知道數據的變化。典型的例子是系統的本地化：

做爲內容管理員，我能夠用如下語言建立新聞：
英語
日語
阿拉伯語
等等……

模式6：按不一樣界面拆分

（按不一樣界面拆分）

有時，故事的複雜性在於用戶界面而非功能。在這種狀況下，故事的拆分要從最簡單的UI開始，而後再構建更易用或更華麗的UI。固然，這些並非獨立的——若是你先作第二個故事的話，第二個故事實際上就是初始故事——但它仍然能夠是一種有用的故事拆分方式。

做爲用戶，我能夠搜索兩個目的地之間的航班。

...使用簡單的日期輸入。

...帶有精美的日曆界面。

模式7：延遲性能優化

（延遲性能優化）

有時，一個故事的基礎功能實現可能並不難，可是須要花不少時間在性能的優化上。若是你能夠從較差性能的基礎功能中學到不少知識，而且它對用戶有必定的價值（好比沒有這個功能用戶就沒法完成故事中的動做），在這種狀況下，你能夠把故事拆分爲「使其能用」和「使其好用」：

做爲用戶，我能夠搜索兩個目的地之間的航班。

...（只要功能完成就好，加載時顯示一個「搜索中……」的動畫。）

...（加載時間限制在5秒之內）。

模式8：按不一樣的業務規則拆分

（按不一樣的業務規則拆分）

用戶故事中的「管理」會涵蓋故事的多個操做。這就爲故事的拆分提供了一種天然的方式。好比說：

做爲用戶，我能夠管理個人賬戶。

...我能夠註冊一個帳戶。

...我能夠編輯個人帳戶設置。

...我能夠註銷個人帳戶。

模式9：拆分出一個探針

（拆分出一個探針）

一個故事之因此被你們認爲工做量很大，可能並非由於它的業務有多複雜，也有多是由於開發團隊對其技術實現不太瞭解。在這種狀況下，不管你怎麼澄清故事的業務部分，都沒法將其拆分。先拆分一個有時間盒限制的探針故事，以便解決開發過程當中的不肯定性，而後咱們能夠決定是直接實現，仍是使用上述的8種模式來拆分它。假如咱們不知道下面的故事如何實現：

做爲用戶，我能夠用信用卡付款。

那麼，就把它分解成：

調研信用卡付款。
實施信用卡付款。

在「調研」故事中，驗收標準應該是你須要回答的問題。調研要點到爲止，能回答問題便可，作調研很容易走火入魔。

探針拆分模式放在最後講解，是由於它應該是你最後的選擇。你目前已知的知識可能已經能夠用來構建一些功能了，按照你已知的知識直接開始開發吧，隨着項目的推動，這些問題頗有可能會不攻自破。所以，在求助於探針模式以前，請盡一切努力使用前面八個模式之一。

元模式：找出複雜性並減小變化

在咱們指導團隊更有效地拆分故事的過程當中，咱們發現了這些模式共有的元模式：關注複雜性，並經過它減小變化。使用元模式的方法以下：

找出核心複雜性。最有可能讓你感到驚訝或者出現問題的部分是什麼？這個問題的答案每每取決於人們的我的喜愛或行爲習慣。有時，這是一個須要從新整合或有外部依賴的部分。
識別出其中的變化。變化比較多的東西是什麼？業務規則、用戶類型、接口、數據變化、實體等。
把全部的變化減小到一個。在複雜的部分中找到一個單一的、完整的切片。它多是一個單獨的場景，也多是經過單個業務規則變化出的一系列場景。

大多數故事拆分模式只是肯定變化的來源並將其減小到一個的例子。

這種方法對於一個新事物的第一個切片特別好用，由於它直奔核心複雜性，並避免了任何可能會讓工做變得更大的內容。

步驟3：評估拆分效果

（評估拆分效果）

你可能會發現，有時你可使用好幾種模式來拆分同一個故事。那咱們應該選擇哪一種拆分方式呢？我通常經過如下兩個經驗法則來判斷：

選擇能讓你下降優先級或扔掉一個故事的拆分方式。80/20法則代表，用戶故事的大部分價值來自於一小部分功能。當一種拆分方式揭示了低價值的功能，而另外一種拆分方式沒有揭示，這說明後一個拆分方式在每一個小故事裏面都隱藏着浪費。選擇能讓你扔掉低價值功能的拆分方式。

選擇能讓你獲得更多同等大小的小故事的拆分方式。把一個8點的故事變成四個2點的故事的拆分方式比產生一個5點和一個3點的拆分方式更有用，由於它能讓產品負責人有更多的自由來分別對這些拆分後的故事進行優先級排序。

可能須要屢次嘗試才能找到最適合你的故事拆分模式——你可能須要不斷地試驗才能找到正確的模式。

4、Cynefin和故事拆分

（Cynefin）

Dave Snowden的Cynefin模型是一種根據問題的複雜程度來思考問題最優策略的有用方法。咱們發現Cynefin很是有用，幾乎全部的工做坊都使用了它，有的是做爲先決條件，有的是做爲工做坊自己。若是你還不熟悉這個模型，請查看咱們的概述。

Cynefin每一個領域的故事拆分看起來都不同。下面是具體拆分方法：

簡單（Simple） - 只需構建便可。若是故事太大，找出全部的故事，先作最有價值的便可。
繁雜（Complicated） - 找出全部的故事，並首先作最有價值和/或最具風險的故事。
複雜（Complex） - 不要試圖找出全部的故事。找出一兩個能提供一些價值的，並能教給你一些關於問題和解決方案的知識，構建這些故事，而後利用你所學到的知識去尋找其他的故事。
混亂（Chaotic） - 先把手頭緊急的事情解決吧，如今拆分故事可能並不重要。
失序（Disordered） - 拆分以前先弄清楚你在哪一個領域，以避免採起錯誤的方法。

最重要的細微差異在複雜域（complex domain），從這裏開始工做會讓你快速瞭解工做的內容。在這種狀況下，試圖找到構成原始大故事的全部小故事是沒有意義的。找到一兩個能夠當即開始學習的故事會更有效率。

有些人不喜歡這種方法，他但願把全部的故事都列舉出來，並肯定大小，以便可以把故事記錄到Backlog並估算時間。但若是你真的是處於複雜域（complex domain），這樣作只會給你帶來可預測性的錯覺——實際的故事極可能會隨着工做的推動而發生變化。最好對複雜工做中固有的不肯定性保持透明。

5、練習故事拆分

就像咱們以前說過的那樣，在較薄的垂直切片中工做是敏捷軟件開發的關鍵習慣。不少人都在努力尋找垂直切片，但其實這是一項很是容易習得的技能。團隊只需2.5-3個小時的練習，就能夠從苦苦掙扎到快速地識別出其領域中的特性和大故事的切片。固然，練習的質量很重要。下面是我推薦的作法：

在1-2周的時間內安排兩到三次1小時的練習課程。邀請整個團隊或至少能很好地結合業務和技術觀點的組合。
爲了準備第一次練習，看看你最近幾個月的Backlog。選擇幾個你曾難以拆分但如今已經成功實現的故事或特性。
用Cynefin的術語來講，這些已完成的特性如今是有序的（繁雜的或簡單的），由於出現了足夠的秩序來實現它們。將來的工做極可能是複雜和無序的。但如今這並不重要。在第一個練習環節中，你的目標是識別出在你的領域中使特性變大的緣由。追溯已完成的工做是練習有效性的關鍵。
在第一個練習環節中，拿着你選擇的一個特性或故事，對照故事拆分流程圖中的問題一塊兒過一遍。假設這個特性還沒有實現，也能夠檢測下你本身如今對它有多瞭解。
若是你使用其中一種模式找到了一個好的拆分方式，請不要停下來。繼續瀏覽其餘模式，並嘗試找到另外一種可能的拆分方式。
若是一次拆分不能產生足夠小的故事，請嘗試對拆分後的故事繼續拆分。
大約50分鐘後停下來。對於你準備的特性或故事，使用流程圖上的每種拆分模式後，請檢查下各模式下拆分後的小故事。
若是你在這個環節沒有找到合適的拆分方式，花點時間讓你們一塊兒來頭腦風暴一下。當這些拆分模式應用到你的特性或故事時，你們是否已經達成了共識。
若是在第一次練習結束時，拆分已完成的特性彷佛很容易，那麼你就能夠嘗試對後續的工做進行拆分了。若是不是，須要再重複下第一次的練習。在下次練習以前，找幾個合適的特性，重複上述過程。
這樣作的難點在於，它是一個「練習」。不少人只願意經過正式培訓或在工做中邊幹邊學來提高能力，他們每每不肯意花時間用來作一些練習，尤爲是練習拆分已經完成的特性，由於這個活動不會有新的工做產出——好比說，它不會完善即將要作的Backlog。但這方面的練習能夠快速提高團隊故事拆分的能力。千萬不要跳過它。
通過2到3個這樣的練習，你應該達到這樣的程度，即對於工做中的每一個特性，每一個人都能快速找出適當的拆分模式，並迅速拆分出適合迭代的故事。

6、垂直切片和規模化

當你有100+人在同一個產品上工做時，可使用垂直切片嗎？

當你有多個敏捷團隊開發同一個產品時，能夠採用這兩種組織方式：特性團隊（feature team）或組件團隊（component team）。

特性團隊的組織方式是，每一個團隊都有足夠多的跨功能成員，以即可以在部分或所有產品上提供完整的價值切片（即「垂直切片」）。根據產品的規模，特性團隊可能會專一於產品的某些部分，有效地建立子產品，或者他們可能會完成整個產品中最重要的部分。

組件團隊的組織方式是，每一個團隊專一於一個特定的組件、架構層次或技術方向。要想交付一個完整的價值片斷，須要協調多個團隊的工做。

讓咱們看一個大型商業軟件的具體例子：淘寶。(注：我不知道淘寶的實際組織方式或技術是什麼樣的，可是這並不重要，我只是須要一個你們都熟悉的軟件產品來進行推理）。

淘寶有一個APP。它經過某種通信協議與某種語言編寫的後端進行通信。後端有一些流程處理的程序，好比搜索商品、生成訂單、支付訂單以及跟蹤物流信息等。

若是採用組件團隊結構，你會有APP團隊，例如，他們能夠對APP界面進行修改，但他們極可能依賴於後端團隊對其系統部分進行相應的修改。各個團隊之間的協調將集中在確保他們的工做同步推動，以最終可以提供價值。

在特性團隊的結構下，你可能會有一個團隊或一組團隊負責商品的搜索模塊，另外一個負責訂單模塊，第三個負責支付模塊等。這些團隊中的每個都擁有APP和後端技能。在這種狀況下，各團隊之間的協調將集中於確保整個產品的設計和架構一致。

相同的產品，團隊以兩種不一樣的組織方式，將獲得兩套不一樣的結果和協調方案。

因此，有關「垂直切片是否與規模相關」這個問題，答案取決於你的組織方式。組件團隊是不以垂直切片的方式工做的。但組件團隊能夠圍繞更大的垂直切片（如MMF）協調工做，但在具體的工做項層面，組件團隊沒法完成垂直切片所需的所有功能。構建組件團隊沒法獨立交付價值，但這種組織方式能夠針對其餘方面進行優化（一般是更容易進行架構調整或更高的研發人員利用率）。

特性團隊與組建團隊的收益恰好相反。他們旨在獨立提供垂直切片，以便更快速的交付價值、獲取反饋，代價是須要明確地協調架構一致性。

特性團隊與組件團隊是2種主要的組織方法。固然，有些組織可能有細微的差異或混合，而且會隨着時間的推移而變化。我之前寫過這方面的文章，特別是在改造一個擁有大型遺留產品的組織的狀況下。

6.1 是否應該讓100+的人去開發一個產品？

如今，咱們心中還有一個更重要的問題，那就是：無論咱們是否能夠在大型產品/項目中使用垂直切片（正如咱們所展現的那樣，若是咱們以特性團隊來組織，咱們是能夠的），這麼多人蜂擁而上，是否真的有效?

爲單個產品/項目添加人員或團隊，都會帶來一些生產力和協調的開銷：項目若是隻有一我的，那麼這我的的生產力幾乎是100%；再增長一我的的話，咱們不會獲得2倍的生產力，可能只會獲得1.8倍的生產力（平均每一個人提供90%的生產力），由於這兩我的須要花時間用來進行工做的協調（每一個人消耗10%的生產力用於協調）；增長到3我的的時候，生產力會獲得再次提高，此次有可能會提升到2.4倍（平均每一個人提供80%的生產力），相應的，協調的開銷也會隨着上升（每一個人消耗20%的生產力用於協調）。並且，這種協調的開銷會隨着人與人之間聯繫的數量呈指數增加。

經過組建小規模團隊，使每一個人只須要與少數人協調工做細節，並嘗試在團隊之間進行分工，儘可能減小依賴性，從而能在必定程度上減小協調的開銷。但工做越複雜，依賴關係就越難以預測，團隊之間須要協調的可能性就越大。

所以，在某些時候，在項目/產品中再增長一我的或一個團隊，不只不能提高生產力，還會給整個系統帶來協調開銷的增長，最終致使總體生產力的降低。

（團隊規模、價值增長和協調開銷之間的關係）

團隊規模的臨界點到底落在哪裏，在很大程度上取決於項目/產品的具體狀況。但拋物線的形狀至少應該讓咱們對大型團隊產生懷疑，並慎重考慮人員或團隊的增長。

對於複雜的工做來講尤爲如此，由於極可能須要咱們在一個項目/產品上工做一段時間後才能瞭解真正的問題和解決方案。而在軟件開發過程當中，複雜性彷佛與價值高度相關。越是高價值的特性，項目/產品前期越可能發現不了。若是是一個新項目/產品，咱們在工做中頗有可能會學到一些新知識，從而改善咱們交付的價值。