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

    敏捷開發系列文章目錄

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

    上一章說了敏捷開發團隊的構成與迭代過程，本章重點說一下迭代第一天的計劃會議。熟話說「好的開始就成功了一半」，一個迭代的計劃會議作得好很差確實直接註定着迭代的成功與失敗。迭代開始以前，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）若是系統參數設定的是自動或手動配發模式，而當前用戶未指定當前工位對應的配藥窗口時，系統會自動在右下角彈出提示，要求用戶設定當前工位對應的配藥窗口。（2）全部功能按鈕上要求有小圖標標示做用。

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

三、需求說明

    一、待配藥界面

    二、已配藥界面

    敏捷開發系列文章目錄