書接上回～～～?故事點燃盡圖有什么用

　　為了能夠得到團隊的真實進度，我們應該采用故事點燃盡圖來跟蹤真實的復合DOD標準的進度。但是敏捷團隊在轉型初期，采用故事點來跟蹤進度的時候，往往會發現故事點很難在迭代的早期下降，如下圖：

　　雖然很努力的按照標準的形式開展了幾個會議，但是每次到了迭代執行的時候，總是不能讓故事點早一點開始下降。

　　可以說衡量一個團隊是否真正的采用了敏捷的方式在工作，一個非常重要的標志就是團隊的故事點燃盡圖可以在迭代早期就進行下降。如下圖：

　　看到這樣的燃盡線，說明團隊確實了理解敏捷中最最核心的一個思想，為客戶盡早交付有價值的可工作的軟件。到這個時候，基本上團隊就可以自我成長和持續改進了。

　　那么，到底做什么、怎么做才能在迭代早期就讓故事點下降，并且在進行中能夠持續下降呢？有很多的團隊苦苦掙扎，到處探索，終是不得要領。以至于到最后心里默默的會說，敏捷就是個形式，沒有什么用處。

～～～～～～～～～～～～～～～　分割線　～～～～～～～～～～～～～～～～～

　　今天給大家看一個例子，來看看如何讓故事點早點下降。

　　“小馬，最近在做什么功能呀？”，“哦，教練，我們最近在開發一個新功能，正好來看看我們拆好的故事，怎么樣？比之前拆得細多了吧 :) ”

　＂額～，這是拆好了？＂，“是的，看看我們這次拆得怎么樣？”

　“這是什么功能呀？看起來很神秘的樣子”，“哦，給你看看我們的界面，它長這個樣子。我們只要把上面的任務做完，下面這個界面就可以用了”。

　　“嗯，一個好的用戶故事，應該是能夠看出他為用戶提供的什么樣的功能。能給我解釋解釋這個界面和拆好的任務之間是什么關系嗎？”，“好的，我來給你解釋解釋”。～～～～一頓解釋～～～～。

　　“哦，我明白了。這是一個三維大樓的模型，要對里面的一個個房間進行裝飾材料的布置，對吧”，“嗯，是的。是這個功能。不過由于房間里面有很多的墻呀／梁呀／柱子呀／板子呀還有踢腳線呀，所以得設置好它們的關系”

“原來是這樣，那這個用戶故事得改改，改成用戶能看懂的描述，那么你的這個功能的用戶是誰呀？”，“哦，是預算員，做工程預算的”。

“OK,　那比如說子任務里面有一個柱布置，那用預算員能聽懂的話來描述這個功能，怎么說呢？”，“我想想，～～～，描述成這樣？＂

作為預算員，我希望對當前房間內的柱子進行統一的墻面裝修

“哦，這樣。那做了這個功能對于預算員有什么用呢？”，“哦，是這樣。原來預算員要對每一面墻、柱子什么的一個個的把裝修材料布置上去，一棟樓里面其實有很多相同的戶型，裝修其實差不多的，這樣預算員就的做好多的重復勞動，所以就提出了這個功能來幫助他們。”

“了解了，能用一句話描述下這個功能對預算員有什么價值嗎？”，“我試試，應該說是減少重復勞動？”

“也可以，減少重復勞動反過來怎么描述呢？”，“那叫做加快完成速度？”，“～～，再想想”，“那要不就說提高工作效率？”，“也可以，不過有點太文縐縐的了。想想站在預算員的角度，對他個人有什么好處”，“嗯～～～，那就是他可以早點完成大樓的裝修工作”，“差不多，那把這個價值加到用戶故事的最后面吧。”

作為預算員，我希望對當前房間內的柱子進行統一的墻面裝修，以便可以快速完成裝修布置任務

“哦，我好像有點明白了，這就可以做為一個用戶故事，有用戶，有功能，還有價值，而且用戶還能看懂”。

“是的，這就是敏捷里的神器，通過用戶故事來描述功能，讓用戶／產品經理／研發同學都能弄懂是什么意思。研發同學圍繞著用戶故事來組織開發任務，這樣才可以用一個語言描述同一個事情”，“哦，了解”。

“你再看看你上面最初拆解好的任務表，看出差別了嗎？”，“～～～，～～～，～～～我們研發能看懂”。“再看看”，“嗯，站在預算員的角度肯定不好懂了”，“那產品經理呢？”，“他們需要我們給解釋解釋就對應上了”，“這就是差別！，多一次信息的轉換就會損失一層含義。所以才要使用用戶故事來對外溝通，對內管理好研發任務”。

“教練，我理解了這個含義了。不過用用戶故事怎么能管理好開發任務呢？你看看這個界面，左邊是不同的房間，中間是每個房間里面不同構件的分類（墻梁板柱），下面是這些房間和分類的具體屬性，右下角還有一個各種構件是否需要統一布置的一個配置界面。剛才那么寫故事好像不對呀”。“嗯～那你覺得怎么寫才合適呢？”

“我覺的應該這樣”

左邊的房間定義一個故事，就叫做：房間和房間屬性的管理

中間的構建定義一個故事，叫做：房間內構件和屬性的管理

右邊的構建的配置也定義一個故事，叫做：布置設置

“這樣才能和研發的任務對應上！所以前面的那個故事應該拆成這三個才對”。

“原來你是這么想的呀，如果這樣的話，比如說我們把你拆好的第一個故事房間和房間屬性做完了，對于用戶－預算員來說有什么價值嗎？”，“當然有啦，預算員可以定義和管理房間了呀”。

“再想想，我們發掘出來的用戶價值是？”，“是快速完成裝修布置任務”。

“那么，可以管理房間這個功能對于預算員完成裝飾布置有直接的價值嗎？”，“直接價值？那還不行，只是完成了第一步。還要選構件，進行構建設置，然后才能一個個房間去布置裝修材料”

“所以呀，這個只能算一個開發任務，而不能算用戶故事，因為它對于最終用戶沒有產生價值，也沒有辦法拿去找真正的客戶做驗證，你總不好意思拿著一個半成品功能去驗證吧。”，“那倒是，可以這么想的話，要對用戶有價值，那我就得把所有的這些房間裝修布置的功能全部做完才能算作一個用戶故事了。這么大一個故事怎么可能在迭代前幾天就完成呢？”

“嗯，你前面的想法是正確的，我們做功能要想著做完以后能夠拿去給用戶去演示，也就是代表著用戶故事是要有用戶價值的才算一個真正用戶故事。在這個前提下，要想做到迭代內盡早交付，就需要想各種辦法對這個故事進行拆分”

“哦，那其實前面我們已經拆分過了，把房間里面的構件拆出來變成一個個故事，比如可以把柱子的裝修和踢腳的裝修功能單獨定義”

作為預算員, 我希望將當前房間內所有的柱統一進行墻面裝修, 以便提高房間內所有柱的墻面裝修布置效率

作為預算員, 我希望將當前房間內所有的柱統一進行踢腳裝修, 以便提高房間內所有柱的踢腳裝修布置效率

“不錯，是這個套路”，“那教練，還有一個配置的界面是不是要單獨寫一個故事呢？像下面這樣”

“這還是要回到業務，預算員在對房間內的各個構件到底怎么布置都需要在這個界面進行配置，但是單獨配置完對于用戶來說，算是完成了裝修布置任務了嗎？”，“那不算，可這塊功能背后的規則也很復雜呀，不算故事的話，放到哪個故事里也太大了呀？”

“我們還是要想辦法在保證用戶故事對于預算員有價值的前提下，進行拆解。來看看上面這配置界面里面包含了各種構件類型，我們能不能把它們一一拆解出來，合并到其他故事里面去。比如，界面里面有關于柱的配置（第六行／第七行），我們把它單獨拆出來放入到下面這個故事里面去”

作為預算員, 我希望將當前房間內所有的柱統一進行墻面裝修, 以便提高房間內所有柱的墻面裝修布置效率
　　　　－柱構件窗口功能（構件的增刪改查）
　　　　－柱構件屬性功能（屬性的調整）
　　　　－配置窗口里面柱的配置（其他配置先不顯示或灰掉）

“怎么樣，這樣一個用戶故事就和他的幾個開發任務緊密關聯起來了”，“這樣做也可以，但是對于研發來說，我們之前都是一塊塊開發的，這樣不符合開發習慣。”

“那么這樣做可以行的通嗎？”

“可以是可以，但是就是感覺有重復工作量，本來一個窗口，開發完就完了，這么拆的話，要來來回回的在這里改代碼，還有重復測試，感覺浪費了呀？”

“～～～你再想想，這樣做真的是浪費了嗎？～～～”

要開會了～，欲知后事如何，且聽再下回分解。