敏捷看板管理实践——Trello篇
原文链接：http://blog.yeyuzhen.cn/?p=264
最近朋友打算在项目组中推广Trello的看板管理方法。由于之前自己项目组也实践过半年的Trello看板管理方法，就与他交流了使用经验。其实，去年半年的Trello使用体验还是不错的，有不少的心得。不过，没有系统的总结过，未能很好的分享出来。趁着春节大假，该补补了。
Trello，是免费的在线多人协作看板系统。操作体验非常好，加之看板管理的理念简洁易懂，使trello是个分分钟上手的东西。
在实践Trello之前，参考了《精益开发实战——用看板管理大型项目》。结合自己的实际情况，设计了如下的Trello看板管理方案。
Trello看板管理方案
trello.Board 表示一个项目或一些相关的项目。可以把相关的小项目组合起来放到一个Board中，Board太多管理起来很麻烦，也容易遗漏任务。我的建议是一个项目组只用一个Board，这样容易在Board中看到整个项目组的工作瓶颈，优化项目流程。
trello.List 是任务列表。从左到右，List 组成的一个工作流，任务在列表之间转移，走完任务的生命周期。我经过多次的调整，创建了如下的List：
待定任务
||
\/
未处理需求任务、未处理优化&&学习任务、未处理Bug任务
||
\/
本周待处理任务
||
\/
本周处理中任务
||
\/
本周测试中任务
||
\/
本周已完成任务
||
\/
历史测试中任务
||
\/
历史已完成任务
“待定任务”任务列表用来收集一些可能做也可能不做的任务，多是一些关于项目的较长远的任务。如确实需要开发，则移动到相关的下游的未处理任务列表。
“未处理需求任务”是工作需求分解后的任务，即关于实际业务的需求，一般就是领导交代下来的任务。
“未处理优化&&学习任务”，这个就是自己优化系统性能的人，以及与项目密切相关的新技术学习任务。这个列表中的任务，体现了你对自己的要求。
“未处理Bug任务”，Bug，都是伤心事，就不多说了。
“本周待处理任务”、“本周处理中任务”、“本周测试中任务”和“本周已完成任务”是周迭代的相关的4个列表。经过，多次的调整，发现以周围迭代周期是比较合适的。周一上午，花个把小时讨论并安排一周的工作。从未处理任务列表中移动任务到“本周待处理任务”列表。开发进行开发的时候，就将任务移动到“本周处理中任务”。开发完成后，将任务移动到“本周测试中任务”，进行任务相关的测试。测试完成后，将任务移动至“本周已完成任务”。测试失败，可以将任务打回到“本周处理中任务”。
“历史测试中任务”和“历史已完成任务”。其实，“历史测试中任务”本是不应该出现的分类。项目的需求验收测试需要协调外部资源，无法做到每周一迭代。每周完成任务开发后，自己只能做功能测试。本周结束，未进行验收测试的任务，就只能累积在“历史测试中任务”列表中，等待外部资源的协调。“历史已完成任务”就是已验收完成的任务。
trello.Card 表示一个任务卡片。每个任务卡片都可以有一个简短的任务描述显示在外，只要合理的设计，任务简述就可以在卡片上显示很多的任务信息。经多次修改后，任务简述模板如下：
任务ID：“XX：20150221_任务简述”，所属系统：？？？”。[Milestone:v1.0][AAA:BBB]
任务ID是这个任务的标识，会出现在关于这个任务的讨论，关于这个任务的代码提交日志等等，关于这个任务的一切东西中。其中，“XX”表示任务的类型，包括：需求、优化、学习和Bug。后续的中括号对中，可以添加任务相关的属性和状态。如，任务所属里程碑“[Milestone:v1.0]”，任务完成日期“[完成日期：2015-221]”等等。
周迭代的情况下，在周三下班的时候就要审视一下剩余的工作任务。多“加”少补，T_T。经过多周的练习，大家应该都能比较正确的估计工作量。只要每周能按时完成周迭代，总体的项目进度也不会出现大的偏差。
由于看板是对所有成员完全开放的，所以应用看板管理时需要全体成员主动参与进来。每个人要完成属于自己的卡片的详细内容填写和卡片在不同列表中的移动。让看板尽量实时的展现项目当前的状态。至少要保证周五下班时的看板和当前项目的进展一致，使得下一周的周迭代能有正确的起点。
简化的看板方案的不足
以上的看板管理方法可能比较适合10人以下的项目组，任务管理比较粗放，也没有可实践的流程改进方案。《精益开发实战》中描述的是40~60人左右的项目组管理方法，所以更大型的项目组看板管理可能需要如书中所述的更加系统的方法。你需要在看板管理的基础上不断迭代开发流程，找到开发流程的瓶颈，不断提高开发效率。