講出符合開發(fā)團隊味口的故事。
上一章說了敏捷開發(fā)團隊的構(gòu)成與迭代過程，本章重點說一下迭代第一天的計劃會議。熟話說“好的開始就成功了一半”，一個迭代的計劃會議做得好不好確實直接注定著迭代的成功與失敗。迭代開始之前，PO肯定都已經(jīng)提前準備好了本次迭代的所有故事，并且提前都發(fā)給了團隊熟悉，后來我們一般都會在前一個迭代快要完成的時候開一個下個迭代的熟悉會議，組織大家一起熟悉下個迭代的故事，一開始并沒有這么做，是在過去的多個迭代中，發(fā)現(xiàn)每個迭代計劃會議都會拖得很長，有時候會開整整一天還沒開完，需要晚上加班繼續(xù)把故事講完，任務安排好。在回顧會議的時候我們有總結(jié)為什么會這樣？我們發(fā)現(xiàn)每個故事消耗的時間都特別的長，大家會提針對這個故事提很多的問題，PO會跟大家解釋這個故事的需求，有時候PO也沒有想到的地方大家就會討論，這樣深入下去，那么時間就這樣消耗掉了。最后大家就會覺得迭代會議開得太累，肯定不是長久的法子。如果團隊能在計劃會議之前做一次提前的溝通，這樣團隊會提前把自己的想法告訴PO，PO也能提前想好抉擇故事的業(yè)務。如此一來后來的迭代計劃會議確實高效多了，還能夠節(jié)約下來時間提前做一些功能設計。
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ā)人員是跟機器打交道更多的，他們更多的是站在技術(shù)層面如何來實現(xiàn)這個需求，所以PO如果講的時候越偏向于實現(xiàn)方式上面，開發(fā)人員就更容易理解，才會覺得這個故事符合他們的味口。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉(zhuǎn)無線電——不安全的藍牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來看看(二) 2017-07-26
學習是年輕人改變自己的最好方式