需求对于一个没有做到发布状态的需求，也觉得不好体验。
为了有效的跟进较大的用户故事的进展，我们开始进行任务拆分。
我们规定：一项任务的粒度最大不能超过三天的工作量。我们趋向于团队成员尽量把任务都拆解到小于一天工作量的粒度，因为这样有利于我们每日晨会进行跟进。
于是看板上的卡片就分为了两类，出现了下面的看板。
我们将看板上的卡片分为用户故事和与用户故事对应的任务，当所有与用户故事相关的任务都完成时，将用户故事挪到待发布中。
用户故事与任务之间使用编号进行关联，这使得我们的晨会过程讨论的内容更加具体，而不是简单的汇报工作，项目进展情况也比以前更加清晰。
然而，问题依旧存在：
当任务卡片较多时，任务与用户故事的对应关系找起来相对麻烦，不能一目了然的了解到用户故事的进展情况。
同样的，这样的看板依旧会存在前端需求大量的向后端涌入，导致后端负荷过重，效率降低的情况。
得益于精益的限制在制品概念，结合我们之前的各种经验，我们最终使用了下面这种看板墙。
在这个看板墙里，只有用户故事卡，用户故事卡上拆分了用户故事的不同任务，我们不再追求多个领域能针对一个用户故事并行开展任务，而是一个领域做完后，再流入到下个领域。
表面上并行开展工作看起来效率更高，但是那样各领域信息并不一致，返工较多，反而导致效率低。由于任务和故事在同一张卡片上，我们可以从看板上一目了然的看到用户故事当前的状态。
另外，我们将卡片分为三种颜色，对应于三个优先级，这样大家在领取任务时，能更加自主。
还有一点十分重要：每个领域我们根据他们的人数设置在制品限制，目前规定一个人同时开展的工作不能超过两项。我们由推的模式转变为拉的模式。
这样能清晰的暴露领域边界的资源匹配情况，同时也能保护相关领域不至于任务过多引起混乱，进而导致效率降低——我们由要做更多的需求转变为“停止启动，聚焦完成”。
一个人的同时工作项不超过两项并不是一个标准答案，我们内部也未完全按照该标准执行。对于基本不会出现阻塞的领域，也许一项也是一个合适的选择。
2.4. 版本规划
由于我们的产品包括iOS应用、Android应用、手表端、服务器、H5这样5个技术领域。
在初期，我们遭遇了各领域互相依赖，因某个领域有bug未能及时修复，导致整体发布延期的问题，而且还经常发生。
因此，我们采用了版本火车的概念：以发布为主，功能为辅——也就是在固定的时间节点必须发布，如果对应功能没有达到发布要求，就推迟到下一个发布版本。
这样做却带来了几个比较揪心的问题：我们版本没有明确的主题，仅仅是一堆已完成的需求而已，导致每个版本的亮点不够。
另外，由于没有规划版本，因此无法给到前端明确的心理预期，他们不知道他们的需求在什么时候能发布，他们也不知道我们的下一个版本将会携带哪些需求。
而对于开发而言，也缺乏明确的目标感，给人一种来了需求我就做，做多少算多少的感觉。
于是，我们最终还是放弃了版本火车，改为版本规划的方式进行整个产品的研发。
版本规划，最头痛的问题就是选哪些需求进入该版本进行开发的问题。要知道，需求永远都是源源不断的来，需求的总量总会远远大于你当前版本能开发完成的总量。
因此就涉及到一个需求收集和筛选的问题：
如果每次版本都要筛选那么多需求，需要
