看板（Kanban），在应用过程中动态调整
2018-11-15
来源：神兵wizard 乔欣
看板作为透明团队状态风险的有效实践，在平安得到了广泛的应用。笔者出于管理需要，在一个移动APP类项目中首次尝试应用看板。在实际的使用过程中最大的体会是，没有万金油型的看板，看板需要依据团队当时的实际情况，不断的动态调整。
笔者此次作为PM负责的天下通-Beacon团队是一个移动APP开发类团队，团队有iOS、andriod、H5、后端开发及前后端测试共计8人，对口PO1位，是一个比较小的端到端的特性交付团队。
我们尝试的首版看板，是一个平安通用的看板，只按照开发测试的主流程建板，对同一业务需求，按实现的技术类型拆分Story（如，领取奖励-JAVA；领取奖励-iOS），按人跟进工作。
（原版看板）
使用一段时间后，问题出来了：同一需求前后端进展不一致，造成需求真正可以测试的的时机很晚，但看板上暴露不出来。我们开始了第一次看板改造尝试：
●看板的“开发中”按技术类型拆分列
●Story下拆分不同技术类型的Task
●按Story划分泳道，展示Story各Task的关联，跟进进展
●以Story泳道数量来限制在行story工作数
改造后，按Story建泳道，强调跟进事而非人，Story的整体进展更明晰，前后端配合更密切，效果明显。
（首次改造的看板）
随着团队的扩张，受限于看板的大小，story泳道数量逐渐满足不了团队的使用，而且看板中无处跟进关联方的工作及技术预研类的工作，第二版看板上线了：
●按Feature划分泳道限制在行Feature数，下属的story和task在泳道中流动
●增加技术预研类卡片，以反应团队技术预研类任务
●增加关联方跟进区，以对非团队的关联工作进展作Review
（第二次改造看板）
第二版的看板存活期很短暂，缺点太明显：一个Feature泳道里有多个Story及相应有Task在流动，Story和Task间的关联不明确，看板不够清晰。同时产品经理吐槽对于他有意义的Feature产出周期太长。我们又尝试改版看板：
●回归按Story划分泳道，使Story和Task进展更清晰
●Feature在对应Story开始后放入已选择排列，说明正在进行
●倾向集中完成一个Feature再开始下一个Feature，缩短Feature交付时间
（第三次改造的看板）
兵无常势水无常形，看板亦如是。如果您是初次接触看板，可以从借鉴类似项目的看板开始：在使用的过程中，依据团队行进中不断涌现的问题需要，实时的调整看板，以找到真正适合团队特点的看板，做到“我的看板我做主”！（本资讯于2016-08-16首次发布）
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
