3月份我们启动SPU搜索改版，这次改版其实相当于重做一个新的搜索，从数据库到建索引、到查询以及前端设计开发都是需要重新开发的。这个工作在今年属于重点任务，所以我带着大家在这次迭代中开始进行故事拆解，并且重新布置了看板墙。
下面就简要说一下是如何进行的，对于新的团队也可以借鉴一下。
按照Scrum的计划会议分为上下两部分。上部分主要是产品需求人员讲业务，下半部分主要是开发估时。
一开始进行的是业务交底工作。这个过程原型是必须要准备好的。
这个环节我发了一次脾气。因为前一天我是要求2位产品负责人进行需求分析工作的，需要按照故事，从用户角度去编写卡片，并且排定优先级。这样按预期进行的话，交底应该是从概括到细节，从高优先级到低优先级讲，而且必须和开发讲明为什么要做这个功能，让开发明白所做的东西有什么价值。但这次明显没达到需求分析的要求，发完脾气之后让大家继续。其实我很少发脾气的，主要是太着急了。
因为故事也没写，所以接下来就带着团队从头开始去分析需求、写故事卡片。因产品人员有事请假，于是我带着技术和测试人员开始写故事拆任务。
首先在白板上写上故事的一般写法，引导大家按照这种方式去思考。
- 首先是对应的是哪部分用户，分的越细越好，例如是甲方、还是咨询、还是施工方等。如果说不清，那就先写造价员或者不写。
- 接着是把这个故事想要表达的用户的核心需求写下来
- 最后写完成这个需求后能给用户带来什么
不清楚用户故事背后的理念，可以看我下面这张内训PPT
没多大功夫大家就写满一桌子
大家写完之后，我说故事中不能出现比较明显的技术话语，否则一定是违背故事卡片背后从用户出发的初衷。
说完之后，大家看看自己的卡片，都异口同声的说：我肯定写的都不合格，好像都是技术相关的：）
于是我引导大家打开原型，从上往下、从左往右的就每个功能开始反问大家。“为什么你们要做导航查询？”“为什么要进行对比？”….
问得大家都懵了，说又不懂业务需求，谁知道有什么用。我明确告诉大家，把现在当成需求人员来对待。以前可以不懂为什么做，但是现在每个人都要开始去关注功能背后的东西。我继续引导大家“如果做不知道有什么用的功能，是不会真正做好的。对于一个功能是这样，对于一个完整的产品更是如此。其实价值不仅对工作，对做人也是，如果一个不知道自己价值的人，生活必定是没有多大意义的。“ 后来我提醒大家可以邀请公司之前是造价用户的同事给予帮助。于是他们自己去请了同事过来进行交流…
互动的还不错，大家加深了对业务的理解，也更明确了自己要做的事情能在实际哪些业务场景中使用，增强了自己的目标感，这其实对于团队来说是很重要的。大家明白了，多品牌的不同材料比价对于甲方更为重要，他们可能在选择用什么材料。而施工方更重视同一材料不同供应商比价，因为他们是在确定的材料下进行预算…..问完之后，请走了同事，然后团队开始重写故事卡片
写完之后我告诉大家接下来重要的事情就是排定优先级。大家把黄纸贴都贴到玻璃板上围城一圈
开始讨论各自对优先级的看法
黄纸贴慢慢形成了一个队列
遇到需要细节的地方就停下来讨论一下
从站着到坐着，对故事的认识多花些时间是值得的
清楚之后，可能之前故事卡片写的不清楚，甚至可能需要重新再写故事卡片。这是大家讨论结束后对原有故事卡片的重新编写。
从下图看，左边是之前的卡片，右边是重新写的卡片。左边的是故事的写法，右边的更有点像功能点。
这次我没有要求大家按照故事的写法去写，这也是很多初为敏捷教练容易犯的错误。一定要记住故事的作用，它是用来交流达成一致的，有些产品按照看似功能的写法可能更简洁，但是只要之前大家对产品功能的业务背景进行过沟通，并达成一致即可。
以上部分是写故事卡片。这部分其实应该属于需求工作，是在开计划会议之前由产品需求团队完成的。故事写完了，接下来就是拆解任务了。通过故事的任务拆解，我们可以更细节的讨论如何去做，并得出更为精确的估时。
第一个故事拆分仍是我引导大家进行。从【数据准备】故事卡片开始，让大家把可能涉及的工作分类写上，过程中我再补充了几个。通过在白板上书写的方式先讨论清楚，再写到卡片上
接下来就没我的事了，我就旁观，偶尔引导一下。经过一段时间的讨论之后，大家把故事下的任务都拆解完毕。
接下来就是给每个任务进行估时了。因涉及UI工作，所以涉及这部分工作时就把UI同事叫过来，简单讲了一下需要完成的功能之后开始估时。其实最好是UI人员也全程参与。只是现在UI不归属我们团队管理，遇到任务时间冲突只能临时叫过来估时了。
每个任务经过大致预估，所有故事任务时间都估算完毕。目前团队基本还不能做到全栈型开发，估时方式主要还是基于主要编写代码的人估时。
估时完毕后，我继续引导大家给我一个预上线时间以及发版时间。大家给了一个，我说如果提前一周完成的话，有哪些工作可以并行。大家开始讨论，最后估时结束。
估时完成后，就要把新故事和任务放到看板上了。这是放新需求之前的看板，【发布】一行中有很多上一时间完成的。
在我实施的kanban中，每个月我会整理一次发布的内容，发布完的会打印在一张纸上，贴在看板最下面。把看板整理后，再放上这一迭代的故事卡片和任务卡片。大家可以看到，故事卡片仍是以前的样子，多的是每张故事卡片下的任务卡片。
这是执行过程中的看板，大家可以看到任务卡片往下沉，也代表着任务在执行。当一张故事卡片的所有任务完成之后，这个故事卡片就可以从【需求 done】挪到【测试 doing】了。
对于随时接受反馈的产品团队，在计划之内总是会有很多计划之外的任务。你看，这面墙上【需求 doing】的已经快贴满了，这个时候如何解决？我们现在的做法是，需求有最后时间的写上，如果开发自己感觉最后时间完成不了，则自行加班解决，总之不能逾期。当然前提之下仍是产品需求人员需要向开发讲明做这件事情的价值所在，而这正是团队更需要在日常工作中慢慢培养的工作意识。
