前言

随着使用风车的团队越来越多，不少人都问我有没有一些风车使用最佳实践，很想知道我们风车团队自己是怎么使用风车这个工具的。所以在这里我就介绍一下我们的使用方式，整体来说，因为团队性质原因，会更加贴近产品开发团队。

背景

任何离开背景的使用方法都是没有意义的，所以在介绍我们如何使用风车前，先介绍一下我们的背景，如果你读过我之前写的一些文章的话，你可能会有所了解，我们是一个远程开发团队，每个成员都在不同的地方，主要通过在线沟通，所以在进度管理和沟通交流上很需要一个管理工具，对远程有兴趣的可以参看我的这篇文章 『远程工作经验谈 - 如何适应及如何管理』。二是风车的诞生初衷是为了解决我自己在项目管理上的问题的。我的上一份工作是一个企业社交工具的技术负责人，需要做项目管理的工作，我们前前后后使用过不少的工具，非常不尽如人意，我每天需要在工具上浪费一两个小时，非常痛苦，所以就萌生了自己做一个刚刚好的工具，风车就是这么来的。可以说，风车一开始是专门为开发人员打造的项目管理工具。尽管现在更加的普适，适用于任何流程化任务管理的场景，风车还是非常适合开发团队做项目管理用。

计划

对于风车，我们有很多计划，比如日历、自定义状态等。但是毕竟资源所限，事情得一个一个来做，所以我们得区分长期计划和短期计划。对应到风车里，我们大量的使用收集箱和任务列表，如下图。

风车是项目、任务列表和任务的三层结构。任务列表作为中间很重要的一环，是任务的集合，用来组织和管理任务。对开发来说，任务列表主要就是迭代周期。所以，我们会有两类非常重要的列表，一是当前迭代列表，二是短期计划列表。当前迭代列表如上图的『Dashboard Stats』和『May Day』，短期计划列表如上图的『六月工作计划』。这里之所以有两个当前迭代列表是因为『Dashboard Stats』是一个大且独立的功能，会有很多小任务，需要多人协作，所以我们单独拿出来跟踪，而『May Day』是真正的当前迭代列表。至于『六月工作计划』，顾名思义，就是我们计划在下个月做的一些事情。

『收集箱』是另外一个很重要的列表，用来收集暂时还没有计划、零散的想法，比如一些未来有可能会加的功能。这里主要供我们做头脑风暴，当跟用户交流时有一些有意思的点后，就在收集箱记录下来，但是暂时不在当前周期做任何评估。等到了新的迭代开始前，我会过一遍收集箱，调整优先级，把一些能开始做的放入到短期计划列表中。

也许这时你有个新的问题，『收集箱』和『六月工作计划』是否有冲突或者冗余？这两者还是很不一样的。收集箱里存放的更多是用户故事这种，从用户角度出发的需求定义，粒度大，把一件事情说清楚就可以了。而六月执行计划里任务则从用户故事细化，变成可执行的任务，同时，这个列表也用来记录一些不太紧急的 bug。

所以当做计划时，事情就方便了，可以直接在『六月工作计划』里选择优先级高的任务，移动到新的当前迭代列表就可以了。与此同时，会对任务做一些简单的评估以及分配，确保工作量合理。而已经完成的任务列表，此时已经可以归档掉了。

执行

计划后就是执行期了，流程化的任务执行是风车的核心，让正确的人能在正确的时间去做正确的事情。要做到这点，首先必须确保大家的信息对称和一致，任何人都知道项目里发生了什么，事情做到了哪一步了。所以，我们要求任何人开始做某个任务的时候，都必须更新状态到『进行中』，同时，同时在进行中的任务最好不要超过一个。如果任务完成了，需要更新状态到『已完成』，可以让团队其他成员进行验收。所以，我随时都可以了解当前迭代进行到什么状态了，团队每个人正在做什么，哪些任务已经完成等待验收，哪些任务已经验收通过部署到线上，哪些任务还需要完成，如下图。同时，事情有轻重缓急，有重要不重要、紧急不紧急两个维度，所以我们约定待办列表里越上面的任务越紧急，同时在任务详情里设置重要或者不重要。

每个任务在待办的状态时并不一定会被分配给某位成员，我们更主张主动的去领任务，看看有什么自己可以做的，包括即使已经被分配给别人了。除了负责人以外，有些任务需要多人协作，比如上图 Roy 在实现『下载所有附件』的功能时，需要我这边提供一些前端实现上的帮忙，所以我会被 Roy 加入到协作者列表里面，这样这个任务发生的任何变化都会实时的通知到 Roy 和我，包括动态和讨论。关于协作者这个功能的用法，可以参考 Roy 写得这篇文章，『新功能：协作者』。

讨论是另一个工作上非常重要的部分。我们是远程团队，大部分沟通都发生在线上，即使在线下我也不主张随意的去打断同事，见我之前写的文章 『不要让办公室成为你的效率杀手』。我们会尽量把跟任务执行相关的事情都放到风车里讨论，主要是出于两点考虑。首先是任何讨论都是按照主题划分的，对比用 QQ 这些聊天工具，实时的交流体验一样，但是主题明确，不会错乱，过程和结论也都有记录，随时可以回顾和查找。同时，对比交流直接靠吼，虽然讨论是同步推送到所有团队成员那里，但是可以异步处理，没有打断别人，可以等到完成手上工作后才去处理。有时如果需要把某个人拉进来讨论一些 feature，直接用 @ mention 就可以了，对方就会收到实时的通知。

作为产品团队，时常会有一些新的需求进来，亦或是一些 bug。我们是允许随时有新的任务进来的，但是如果是哪种迟一天做早一天做关系不大的任务，就没必要添加进来打乱节奏了。

发布

作为产品团队，只有发布才是带来最终价值的，这也是我坚持做持续发布，而不是等整个迭代结束后统一发布的原因。另外，我们的代码质量更多的依赖代码审核和自动化测试，而不是放在 staging 环境做人肉测试，除非是一些比较大拿不准的变化。我在之前的文章『实用 GIT 工作流』介绍了我们团队使用的代码工作流，简单说，就是必须随时有一个可发布的分支，对应风车是 master 分支，同时，工作分支对应风车里的具体任务，跟 git commits 结合起来，同时能很简单很早的 merge 过来。我们的代码审核流程可以阅读这篇文章『让代码审查成为你的团队习惯』。

总结

回到风车的设计初衷，我们就是想设计一个刚刚好的工具，即使以后会有所扩展，但是一致的原则是用户使用仍然要简单高效，如果违背了这个原则，那么宁愿砍功能。我希望用户在使用时能专注做事，不要被冗余的东西所干扰，分散注意力或者带来额外的操作成本，这也是我们在可视范围只放必要东西的原因，让用户可以节省时间，更多的花在做事执行上。尽管用户会有各种各样的要求，希望能加这个功能那个功能，但是我会非常慎重的去筛选，我真的受够了过去在那些复杂的工具上浪费一两个小时！！！

如果说风车只有一个价值，那就是能让你的团队真正的不断优化工作流程。偶尔能听到一些人说人是最重要的，流程和工具无所谓，我只能说声呵呵，要不你就是能力没到，要不你就是没用过好的工具。一个简单的工具加上一个优化的流程能让整个团队事半功倍，这也是为什么在敏捷项目管理过程中会单独有个非常重要的步骤 Retrospective，正是为了迭代改进流程。当你有了合适的人和合适的流程，千万不要忽略合适的工具，它真的会带来很大的不同，无论是不是风车。