我们是如何使用风车的

May 20, 2014 风车 流程

前言

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

背景

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

计划

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

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

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

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

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

执行

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

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

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

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

发布

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

总结

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

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

Yedingding

关于我

技术创业者,系统架构师,GrowingIO 联合创始人,Teahour 主播。

comments powered by Disqus