講出符合開發(fā)團隊味口的故事。

    上一章說了敏捷開發(fā)團隊的構成與迭代過程，本章重點說一下迭代第一天的計劃會議。熟話說“好的開始就成功了一半”，一個迭代的計劃會議做得好不好確實直接注定著迭代的成功與失敗。迭代開始之前，PO肯定都已經(jīng)提前準備好了本次迭代的所有故事，并且提前都發(fā)給了團隊熟悉，后來我們一般都會在前一個迭代快要完成的時候開一個下個迭代的熟悉會議，組織大家一起熟悉下個迭代的故事，一開始并沒有這么做，是在過去的多個迭代中，發(fā)現(xiàn)每個迭代計劃會議都會拖得很長，有時候會開整整一天還沒開完，需要晚上加班繼續(xù)把故事講完，任務安排好。在回顧會議的時候我們有總結為什么會這樣？我們發(fā)現(xiàn)每個故事消耗的時間都特別的長，大家會提針對這個故事提很多的問題，PO會跟大家解釋這個故事的需求，有時候PO也沒有想到的地方大家就會討論，這樣深入下去，那么時間就這樣消耗掉了。最后大家就會覺得迭代會議開得太累，肯定不是長久的法子。如果團隊能在計劃會議之前做一次提前的溝通，這樣團隊會提前把自己的想法告訴PO，PO也能提前想好抉擇故事的業(yè)務。如此一來后來的迭代計劃會議確實高效多了，還能夠節(jié)約下來時間提前做一些功能設計。

seo優(yōu)化培訓,網(wǎng)絡推廣培訓,網(wǎng)絡營銷培訓,SEM培訓,網(wǎng)絡優(yōu)化,在線營銷培訓

 

    PO為了把故事講明白，肯定提前都把所有的故事都想過一遍，流程是通的，也不會存在相互矛盾。PO有一個自己的用戶故事地圖，然后把故事地圖中的故事按優(yōu)先級放入Product Backlog排好順序，從Product Backlog 進入迭代的故事列表就是Sprint backlog。PO一定不能拿出自己都還沒弄明白的史詩級的故事拿進Spring backlog給開發(fā)團隊。

    計劃會議的流程是這樣的，PO把故事列出來，可以在白板上貼卡片，我們直接用的leangoo，一個電子版的看板。然后PO會一個個講解這些故事，講完一個故事，SM就會讓團隊成員提問，如果沒有問題就開始估點，估點用撲克牌?，F(xiàn)在擺在PO面前最大的問題就是故事怎么講？大家覺得講故事可能很容易，其他沒那么簡單，為什么了，因為PO和開發(fā)團隊很少是站在同一個頻道上思考的，PO經(jīng)常是跟市場、客戶、老板打交道的，從他們那里獲取到產(chǎn)品的需求，所以他講得更多是這個功能的重要性，這個功能的價值，而開發(fā)人員是跟機器打交道更多的，他們更多的是站在技術層面如何來實現(xiàn)這個需求，所以PO如果講的時候越偏向于實現(xiàn)方式上面，開發(fā)人員就更容易理解，才會覺得這個故事符合他們的味口。

seo優(yōu)化培訓,網(wǎng)絡推廣培訓,網(wǎng)絡營銷培訓,SEM培訓,網(wǎng)絡優(yōu)化,在線營銷培訓

 

    我到目前為止還在糾結這個故事描述的方式和詳細程度，我覺得這個胃口肯定是某個團隊的胃口，不一定適合所有團隊，只有團隊之間形成一種默契，那么交流起來肯定是事半功倍的，所以PO寫故事需求，一定不要拘泥與某一種形式，一定得多嘗試多思考。

    故事不要寫太多的文字，寫太多開發(fā)人員也很少會認真的去看，寫太詳細也不行，會讓有些人產(chǎn)生依賴，也不自己思考。之前就有一個測試人員，一個小時就寫了幾十個測試用例，怎么可能這么厲害，后來一評審他的用例發(fā)現(xiàn)用例的內(nèi)容都是成段成段從需求中拷貝過來的，一問他這段什么意思，根本還沒來得及搞清楚。所以太詳細就容易產(chǎn)生依賴，也浪費PO太多精力在文字工作上。太少了肯定也不行，之前就見到過別的團隊，故事就是一句話，作為一個用戶，我希望能有某某功能，以便于我某某方面會更好。這樣的需求開發(fā)人員肯定看著都是木的，就算你口才再好也難以有條理的把這個需求講出來，就算講出來了，開發(fā)人員也不一定有條理的接收了，開發(fā)人員肯定覺得你至少有張圖吧，對著圖講也好有個消化過程。所以我們一般故事中的需求會涉及到業(yè)務說明、業(yè)務流程圖、界面草圖、驗收條件，所以了不多不少剛剛好。

    一個完整的故事，首先在卡片上會對這個故事有一個整體的說明，比如“作為一個藥劑師，我希望可以查詢到待配藥或已配藥的記錄，以便于我對指定患者進行配藥或取消配藥的操作”。這是一個標準格式，作為...我希望...以便于...，三個省略的地方，第一個說出了這個需求的提出者，第二個說出了他需要一個什么功能，第三個說出了為什么需要這個功能，它有什么價值。然后在卡片后面我們有一個鏈接地址，進一步來描述這個故事，這個鏈接里就包含了該有的業(yè)務說明、流程圖、界面草圖和驗收條件。

故事舉列：

US993 查詢配藥記錄

1、故事

    作為一個藥劑師，我希望可以查詢到待配藥或已配藥的記錄，以便于我對指定患者進行配藥或取消配藥的操作

2、驗收標準

    1、功能要求：（1）系統(tǒng)支持按收費時間，配藥窗口，患者就診卡號、門診流水號、發(fā)票號查詢當前登錄藥房的待配藥處方信息；（2）系統(tǒng)支持按配藥時間，患者就診卡號、門診流水號、發(fā)票號、配藥窗口查詢當前登錄藥房的已配藥處方信息；

    2、錄入約束：卡號、門診流水號、發(fā)票三個檢索條件在同一個文本輸入框內(nèi)錄入；

    3、交互要求：（1）如果系統(tǒng)參數(shù)設定的是自動或手動配發(fā)模式，而當前用戶未指定當前工位對應的配藥窗口時，系統(tǒng)會自動在右下角彈出提示，要求用戶設定當前工位對應的配藥窗口。（2）所有功能按鈕上要求有小圖標標示作用。

    4、執(zhí)行結果：（1）查詢到的結果必須與界面設計的內(nèi)容一致，與后臺數(shù)據(jù)庫中的歸檔信息一致；（2）查詢到的結果集必須按配藥窗口號，患者掛號序號、收費時間（配藥時間）依次降序排列；

http://www.cnblogs.com/kakake/p/7205480.html