講出符合開發(fā)團(tuán)隊(duì)味口的故事。
上一章說了敏捷開發(fā)團(tuán)隊(duì)的構(gòu)成與迭代過程，本章重點(diǎn)說一下迭代第一天的計(jì)劃會(huì)議。熟話說“好的開始就成功了一半”，一個(gè)迭代的計(jì)劃會(huì)議做得好不好確實(shí)直接注定著迭代的成功與失敗。迭代開始之前，PO肯定都已經(jīng)提前準(zhǔn)備好了本次迭代的所有故事，并且提前都發(fā)給了團(tuán)隊(duì)熟悉，后來我們一般都會(huì)在前一個(gè)迭代快要完成的時(shí)候開一個(gè)下個(gè)迭代的熟悉會(huì)議，組織大家一起熟悉下個(gè)迭代的故事，一開始并沒有這么做，是在過去的多個(gè)迭代中，發(fā)現(xiàn)每個(gè)迭代計(jì)劃會(huì)議都會(huì)拖得很長，有時(shí)候會(huì)開整整一天還沒開完，需要晚上加班繼續(xù)把故事講完，任務(wù)安排好。在回顧會(huì)議的時(shí)候我們有總結(jié)為什么會(huì)這樣？我們發(fā)現(xiàn)每個(gè)故事消耗的時(shí)間都特別的長，大家會(huì)提針對(duì)這個(gè)故事提很多的問題，PO會(huì)跟大家解釋這個(gè)故事的需求，有時(shí)候PO也沒有想到的地方大家就會(huì)討論，這樣深入下去，那么時(shí)間就這樣消耗掉了。最后大家就會(huì)覺得迭代會(huì)議開得太累，肯定不是長久的法子。如果團(tuán)隊(duì)能在計(jì)劃會(huì)議之前做一次提前的溝通，這樣團(tuán)隊(duì)會(huì)提前把自己的想法告訴PO，PO也能提前想好抉擇故事的業(yè)務(wù)。如此一來后來的迭代計(jì)劃會(huì)議確實(shí)高效多了，還能夠節(jié)約下來時(shí)間提前做一些功能設(shè)計(jì)。
PO為了把故事講明白，肯定提前都把所有的故事都想過一遍，流程是通的，也不會(huì)存在相互矛盾。PO有一個(gè)自己的用戶故事地圖，然后把故事地圖中的故事按優(yōu)先級(jí)放入Product Backlog排好順序，從Product Backlog 進(jìn)入迭代的故事列表就是Sprint backlog。PO一定不能拿出自己都還沒弄明白的史詩級(jí)的故事拿進(jìn)Spring backlog給開發(fā)團(tuán)隊(duì)。
計(jì)劃會(huì)議的流程是這樣的，PO把故事列出來，可以在白板上貼卡片，我們直接用的leangoo，一個(gè)電子版的看板。然后PO會(huì)一個(gè)個(gè)講解這些故事，講完一個(gè)故事，SM就會(huì)讓團(tuán)隊(duì)成員提問，如果沒有問題就開始估點(diǎn)，估點(diǎn)用撲克牌?，F(xiàn)在擺在PO面前最大的問題就是故事怎么講？大家覺得講故事可能很容易，其他沒那么簡單，為什么了，因?yàn)镻O和開發(fā)團(tuán)隊(duì)很少是站在同一個(gè)頻道上思考的，PO經(jīng)常是跟市場、客戶、老板打交道的，從他們那里獲取到產(chǎn)品的需求，所以他講得更多是這個(gè)功能的重要性，這個(gè)功能的價(jià)值，而開發(fā)人員是跟機(jī)器打交道更多的，他們更多的是站在技術(shù)層面如何來實(shí)現(xiàn)這個(gè)需求，所以PO如果講的時(shí)候越偏向于實(shí)現(xiàn)方式上面，開發(fā)人員就更容易理解，才會(huì)覺得這個(gè)故事符合他們的味口。
