谈谈：关于敏捷规划的微信对话

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


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