敏捷開發系列文章目錄

講出符合開發團隊味口的故事。

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

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

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

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

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

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

故事舉列：

US993 查詢配藥記錄

1、故事 作為一個藥劑師，我希望可以查詢到待配藥或已配藥的記錄，以便於我對指定患者進行配藥或取消配藥的操作 2、驗收標準 1、功能要求：（1）系統支持按收費時間，配藥窗口，患者就診卡號、門診流水號、發票號查詢當前登錄藥房的待配藥處方信息；（2）系統支持按配藥時間，患者就診卡號、門診流水號、發票號、配藥窗口查詢當前登錄藥房的已配藥處方信息； 2、錄入約束：卡號、門診流水號、發票三個檢索條件在同一個文本輸入框內錄入； 3、交互要求：（1）如果系統參數設定的是自動或手動配發模式，而當前用戶未指定當前工位對應的配藥窗口時，系統會自動在右下角彈出提示，要求用戶設定當前工位對應的配藥窗口。（2）所有功能按鈕上要求有小圖標標示作用。 4、執行結果：（1）查詢到的結果必須與界面設計的內容一致，與後臺數據庫中的歸檔信息一致；（2）查詢到的結果集必須按配藥窗口號，患者掛號序號、收費時間（配藥時間）依次降序排列； 3、需求說明 1、待配藥界面

2、已配藥界面

敏捷開發系列文章目錄

3.PO如何給開發團隊講好故事