关于敏捷规划的微信对话

说明：下面取自于微信对话，介绍了一种敏捷规划的做法，供参考

唐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 这些实践的东西才能解决问题啊