说明：下面取自于微信对话，介绍了一种敏捷规划的做法，供参考
唐XX 22:08 @张克强 能否谈一下你们 规划怎么开的 规划会怎么开的，都有几种拆分任务的方式？
张克强 22:09 planning meeting 迭代计划会议 我们不拆任务，只拆故事 ,根据故事流转来进行 ,看板方式
唐XX 22:11 对拆故事
丁XX 22:11 如果故事复杂度高或是客户不在现场，可以提前开需求澄清会，为计划会做准备
唐XX 22:11 我们专门有个迭代准备会。
唐XX 22:11 故事不拆分成具体的开发任务么？
张克强 22:12 不拆任务，看板流转也可视为任务分解吧
唐XX 22:13 那你把故事拆的很小？？大概多少工作量一个人完成？
张克强 22:13 是的，追求小颗粒度
张克强 22:15 大概多少工作量一个人完成？ 指什么情况？
唐XX 22:15 就是说你这个小颗粒度的 衡量
唐XX 22:15 是3人天 or 5人天？
丁XX 22:16 最大要能在一个迭代内交付
唐XX 22:18 那是否跟踪进度不是那么透明呢？风险不容易被暴露啊
丁XX 22:18 那当然
唐XX 22:19 我们现在要求一个故事拆分之后，不能大于5人天的工作量
丁XX 22:19 这里指最极端的情况
唐XX 22:19 嗯
丁XX 22:19 正常情况要保证在纵拆的前提下，越小越好
张克强 22:20 看板在于流动，在相同状态停留时间一样设计在5天以内
唐XX 22:20 那拆成这样，就不细分任务了吗？
清玉 22:21 故事也不是越小越好吧
张克强 22:21 不显式的拆任务
张克强 22:21 以客户感知为标准，关于故事的小
唐XX 22:22 就是说直接将 故事贴到看板上，看板上没有开发任务卡，只有故事卡。。。
张克强 22:22 是的 @唐XX
唐XX 22:23 哦。。那你们早上站会的 怎么讲的
张克强 22:25 看板移动
唐XX 22:25 但是前几天可能没有故事移动啊
张克强 22:27 也有的，有上个迭代拖下来的，有小的，完成的快
唐XX 22:27 现在很少一个故事、前端、后端同步开发的。。
唐XX 22:28 有点纠结，导致的原因就是，人员配置
唐XX 22:28 比如说有5个后端java开发，只有1个前台
唐XX 22:28 h5
唐XX 22:29 然后这个故事就拖很久
金XX 22:31 我们有相同问题，人员配置应该是共性问题，值得研究的方向
唐XX 22:31 你们测试发现bug了，怎么在看板上体现的
张克强 22:33 bug对应的故事退回到编码或者需求环节
唐XX 22:33 要看等级是吧。。1、2级bug就退回。。
唐XX 22:34 退回去可能导致 在制品 增加了
张克强 22:34 故事尽量拆小，解藕，解决同步依赖，，但确实总有些同步依赖
张克强 22:35 @唐XX 只要是要修改的bug，都退回 ，不分级别，这样才能显示正确的在制品
唐XX 22:37 这些实践的东西才能解决问题啊
摘抄美文4、承诺是一件美好的事情，但美好的东西往往不会变为现实。
