讲出符合开发团队味口的故事。
上一章说了敏捷开发团队的构成与迭代过程，本章重点说一下迭代第一天的计划会议。熟话说“好的开始就成功了一半”，一个迭代的计划会议做得好不好确实直接注定着迭代的成功与失败。迭代开始之前，PO肯定都已经提前准备好了本次迭代的所有故事，并且提前都发给了团队熟悉，后来我们一般都会在前一个迭代快要完成的时候开一个下个迭代的熟悉会议，组织大家一起熟悉下个迭代的故事，一开始并没有这么做，是在过去的多个迭代中，发现每个迭代计划会议都会拖得很长，有时候会开整整一天还没开完，需要晚上加班继续把故事讲完，任务安排好。在回顾会议的时候我们有总结为什么会这样？我们发现每个故事消耗的时间都特别的长，大家会提针对这个故事提很多的问题，PO会跟大家解释这个故事的需求，有时候PO也没有想到的地方大家就会讨论，这样深入下去，那么时间就这样消耗掉了。最后大家就会觉得迭代会议开得太累，肯定不是长久的法子。如果团队能在计划会议之前做一次提前的沟通，这样团队会提前把自己的想法告诉PO，PO也能提前想好抉择故事的业务。如此一来后来的迭代计划会议确实高效多了，还能够节约下来时间提前做一些功能设计。
PO为了把故事讲明白，肯定提前都把所有的故事都想过一遍，流程是通的，也不会存在相互矛盾。PO有一个自己的用户故事地图，然后把故事地图中的故事按优先级放入Product Backlog排好顺序，从Product Backlog 进入迭代的故事列表就是Sprint backlog。PO一定不能拿出自己都还没弄明白的史诗级的故事拿进Spring backlog给开发团队。
计划会议的流程是这样的，PO把故事列出来，可以在白板上贴卡片，我们直接用的leangoo，一个电子版的看板。然后PO会一个个讲解这些故事，讲完一个故事，SM就会让团队成员提问，如果没有问题就开始估点，估点用扑克牌。现在摆在PO面前最大的问题就是故事怎么讲？大家觉得讲故事可能很容易，其他没那么简单，为什么了，因为PO和开发团队很少是站在同一个频道上思考的，PO经常是跟市场、客户、老板打交道的，从他们那里获取到产品的需求，所以他讲得更多是这个功能的重要性，这个功能的价值，而开发人员是跟机器打交道更多的，他们更多的是站在技术层面如何来实现这个需求，所以PO如果讲的时候越偏向于实现方式上面，开发人员就更容易理解，才会觉得这个故事符合他们的味口。
延伸阅读
- ssh框架 2016-09-30
- 阿里移动安全 [无线安全]玩转无线电——不安全的蓝牙锁 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实现JSON转Model - HandyJSON使用讲解 2017-07-26
- 阿里移动安全 Android端恶意锁屏勒索应用分析 2017-07-26
- 集合结合数据结构来看看(二) 2017-07-26
学习是年轻人改变自己的最好方式