敏捷团队契约规则与DOD实战

第一版的影响地图做好了之后，很多项目就开始组建团队，团队成员到位之后就正式启动项目，各种工作开始忙活起来了。我强烈建议在团队刚刚成型的时候，大家花上一点时间，制定针对这个项目的团队契约。所以第四式讲的是在项目开工前制定团队契约。

我建议从3个方面去制定团队契约：完成的定义（Definition of Done），工作日历（Work Calendar），通用规则（Common Rules）。

1. 完成的定义（Definition of Done）

对于DOD，Scrum里已经有了清晰的定义，我们这里就不再把Scrum里的DOD再来讲一遍了。这里跟大家分享的是，我们是怎么实际运用这个概念的。先来看一下软件需求的生命周期：

（虽然瀑布交付和敏捷交付从核心目标，思维方式，过程方法，管理手段，绩效指标全方位的都发生巨大的变化，但是软件的生命周期并没有改变，仍然是线性的经历上述阶段）

我们没有完全照搬Scrum里对于DOD的定义和使用原则，而是把DOD打散到了各个阶段，让项目团队一起定义用户故事在每个阶段的DOD，以确保下游可以正常的从上游接手并开始工作。

Scrum是一个非常理想化的框架，考虑到我们的实际情况，很难在项目的一开始就能做到跨职能，自组织，甚至到了项目结束的时候仍然是做不到的。所以对我们而言，一个项目中存在各种不同的角色是一个短期内无法改变的事实，因此我们需要让用户故事在不同角色之间能够顺畅的传递，定义每个阶段的DOD就是我们使用的方法，上图是我们在一个项目中各个DOD的示例。

制定DOD的要点是由团队共同协商和制定，而不是由某个领导拍板决定。并且不同的项目，不同的团队成熟度，制定的DOD完全是可以不同的，因此DOD是根据项目的具体情况而制定的。同一个项目，随着项目的推进，它的DOD也可以发生变化，因此DOD也是可变的。工作的传递都是上游向下游传递，传递是否顺畅是看下游是否能够正常工作，因此DOD是上游对下游负责。

在实践中，我们把每个阶段的DOD都打印出来贴在墙上，让所有的成员随时都能看到。

2. 工作日历（Work Calendar）

工作日历的作用是确定团队的工作节奏，告诉团队在什么时候，应该做什么事情，在什么时候，必须完成什么事情。下图是一个我们使用scrum来开发的一个项目的Work Calendar:

图中的字比较小，在此稍作解释。我们采用2周作为一个sprint，那么一个sprint就是10个工作日，所以上图中一列表示一天，一行表示一个时间段。在这个图中，我们就把scrum要求的每个活动都标注上去，比如说每个sprint第一天的上午，是进行sprint planning，每个sprint最后一天的上午，进行sprint review，下午进行sprint retro，图中黄色的部分表示daily standup, 由于第一天的上午需要进行sprint planning，所以只能下午进行daily standup，第一周的周五上午，领导需要召开状态跟踪会，所以daily standup也只能放在下午。而sprint最后一天需要开一整天会议，所以就取消了那天的daily standup。

这一切也都是根据项目的实际情况来制定的。蓝色表示我们约定的grooming的时间，但并不是固定在每周二，而是在Work Calendar上指出，对于下一个sprint，我们必须进行两次grooming，一次是业务需求构思层面的沟通和梳理，第二次是和技术团队交流并进行初步的方案设计。而第一次需要在第一周的周二之前完成，第二次需要在第二周的周二之前完成，否则后续工作的节奏会受到影响。

下图是我们另外一个项目Work Calendar的例子：

在这个例子中，我们没有使用scrum，而是用KANBAN来管理，按照release来划分项目。这个例子中我们约定每个release的发布日的前一天，是对下个release进行grooming的最后期限（在这个例子中，由于团队成员之间比较默契，因此我们只需要做一次grooming），否则下个release的节奏会受影响。总结一下，Work Calendar和DOD一样，也是由团队共同根据项目的特点来制定，可变的。和DOD不同的是，Work Calendar关注那些必须要做的事情的时间节点。

3. 通用规则（Common Rules）

对于那些无法在DOD和Work Calendar中体现，但是团队成员都需要遵守的规则，我们称之为“通用规则”，比如说：

• PO只能决定发布时间，发布内容由交付团队承诺

• 所有成员在站会之前更新任务状态

• 只能在站会上移动故事卡片

• 任何情况下都不抱怨，不责备，不甩锅

• 需求变更卡片必须从分析阶段开始流动，不能在后续队列里直接放入需求变更卡片

• 完成设计的用户故事可以暂停或丢弃，但不能在开发过程中修改需求

• 用户故事的优先级只能在开始开发之前调整
  

通用规则也是团队根据项目特定共同协商之后决定的，它当然也可以随着项目的推进而演变。

在这里，请同学们思考一个问题，为什么要制定团队契约？我想答案会有很多:为了规范团队的行为，为了提高工作传递效率，为了更好的服务于项目目标，为了让团队快速磨合...... 这些答案都对，每个人的理解都不同，按照自己相信的逻辑去行动就行。但是我们制定团队契约的目的是：让团队迅速的进入稳定的状态。因为我们相信，只有一个团队的运行状态稳定了，我们才能做有意义的度量，才能去找到瓶颈，才能进行真正的持续改进。

我很推荐把团队契约的内容全都打印出来贴在墙上，保证成员在站会的时候都能看到。当项目过程中遇到问题的时候，大家先审视一下是否有违反了团队契约的行为，我的经验是，在项目初期，至少有一半的问题是由于违反了团队契约而导致的。

最后总结一下团队契约：

• 为了让团队迅速进入稳定状态

• 由团队成员根据项目的特点共同制定

• 可变的

• 全都打印出来贴在墙上

• 出问题时先看看团队契约

本文由@合气大蒜 原创发布于管理圈，未经许可禁止转载。