咕咚老王分享了一个案例《一个成功敏捷团队的失败历程》[1]，其分析得到的第1个失败原因是权威下取得的前期敏捷成功，在权威撤出后敏捷实践无法坚持下去。然后笔者跟进了分析，提出将形成的好实践落在团队章程上，形成组织+团队双重监督。让团队章程保持权威，权威方式获得的团队章程，应当高于权威，也即是团队章程不会被权威轻易的修改，团队章程的形成会对权威形成制约。这样固化在团队章程中的共识和敏捷实践就不会因为个别权威人员的离开而消散。
那么团队章程真的能有拯救敏捷失败团队的魔力吗？ 本文试图来解答。
敏捷团队章程是什么？
团队章程是提供指导原则、规则并指导团队成员行为的方针政策， 也可以理解为团队开展工作的规则，可以包括预期的行为，价值观，工作规则，做事的方式。团队章程相比较于项目章程，是一个新的概念。章程应由团队成员共同完成，并为所有成员服务。在团队章程中团队成员可以约定相互权力和义务，制定团队行事的基本原则，并设计面临突发事件时的应对措施。在实践中，一些软件团队的章程可以将交付质量目标和组织绩效目标联系起来[1]。
现代组织中很多团队中存在不同程度的人际信任、相互依存和共同责任问题，团队在动态发展中的内在”摩擦”是现实存在的。团队章程可以最大程度地降低歧义、误解和误会，从而减少这些摩擦。通过明确预期，团队章程确立了既定的规则，有助于促进共同理解，达成共识。
团队章程首先作为一个交流工具，它的价值在于把抽象理念变成具体的、有价值的行动，从而提高了成员缔结心理契约的可能性，而不是违反心理契约。因此，“通过明确的约定规则规范行为”是团队章程的基本内容。
团队章程几乎可以适用于任何希望建立正式或非正式团队的组织或人员，它在以下形式的团队中都有很好的应用和表现，如项目团队、任务团队、风险投资团队、虚拟团队和董事会等。
团队愿景和团队章程
团队愿景是团队对指导原则的共同理解，包括了使命，目标，预期的行为，价值观，和最终成果，由团队识别定义并得到使用。一般而言，团队愿景不是团队计划，不包括团队所要完成的任务计划。但是有些项目计划或项目章程会包括团队愿景。团队愿景也不是功能需求概要，一般不包括需求。同样地，团队章程不是计划，一般不涉及具体任务/里程碑/干系人等等安排。团队章程也不是项目章程，不包括项目特定任务和细节。
团队愿景与团队章程两者的主体内容是重合的，一般而言，团队章程可以包括团队愿景，团队愿景也包含团队章程的主体内容，对于一个团队而言，不必同时有团队章程和团队愿景两样。团队章程是团队的正式文件，更加正式，对团队成员有更强的约束力。
团队章程的好处
团队章程可能带来五个方面的绩效改进：
- 减少团队内部冲突；
- 提高速度；
- 提升决策质量；
- 共同价值观；
- 团队成员的满意。
这些结果特别有益于工作团队，而且普遍对组织也有利[2]。
没有一样工具是适合所有任务的，许多因素可能会降低团队章程达到预期结果的可能性。其中四个因素是团队成员经常会遇到的：
- 初期分歧；
- 成员流动；
- 设立条件；
- 组织背景。
在进入全球超竞争时代的今天，组织要想生存并保持繁荣，必须将抽象的理念转化为一系列实际的文化价值观、行为规范、行动指令、产品设计、工艺流程，才能切实保障自身的发展。团队章程在团队层面提供了一个强有力的工具，用以指导各种类型团队的行为。
敏捷与团队章程
对于敏捷团队，敏捷团队的团队章程就是敏捷团队章程。事实上，敏捷其实已经考虑到了团队章程，只是在名称上采用了其它说法，比如团队契约、Working Agreement、团队公约。而在水晶系列方法中，明确设置了团队方法体系建成这样的实践，这个实践与建立团队章程是完全一致的。
对于常见的敏捷实践而言，回顾会议的产物是天然的可以归入到团队章程，回顾会议上团队一起识别到的改进措施和一起的约定值得团队后续持续的遵循，在后面再次进行回顾，发现更好的改进可以再次改进。所以从范畴和内容上讲，回顾会议产物如果记录为团队级文档，那么这就是团队章程；那么就算是没有文档化，回顾会议产物也可以算是未文档化的团队章程。只是未经记录文档化，需要依赖于团队的共享记忆，当关键人员离开时，难以保证团队共享记忆不丢失。
当然从章程的字眼来看，未文档化的约定难以上升到章程的高度，所以本文所说的团队章程是指文档化的，可以被团队内外相关人员阅读。
如何建立和维护敏捷团队章程
本章分析敏捷团队章程有哪些主要组成部分，以帮助启发敏捷团队制定适合自己的团队章程。在分析之前必须指出敏捷团队章程秉承敏捷文档刚刚好的原则，在刚刚开始的时候，没有必要追求面面俱到，恰恰只需记录达成的约定即可。常见的最需要达成的约定是每日早会的召开时间，只有每日早会约定的团队章程只有一句话，作为团队章程的第一版，这样完全可以。
随着团队实践，或者团队组建有较好的起点，那么值得来考虑更加全面的来建设维护团队章程。笔者推荐团队章程包括如下5大方面：
一、团队愿景
二、交付目标
三、团队模型
四、管理实践
五、工程实践
- 1
- 2
- 3
- 4
- 5
而管理实践和工程实践的内容在敏捷当中常常组织到完成定义（Definition of Done，缩写DoD）当中。
以下分别进行说明。
团队愿景
团队愿景就是团队的愿望或最想达到的目标。有许多团队建设方法来得到团队愿景，得到敏捷团队愿景与得到普通团队愿景并没有区别。 简单的方法是在团队建设务虚讨论时，讨论选择下团队的名称、口号、使命、价值观等等。可以查到更多团队建设方法，本文不再赘述。
交付目标
交付目标主要说明优先的交付要求和交付频率 交付目标是其它选择的出发依据，因此值得在开始就进行识别。常见的优先交付要求有： 0缺陷、按时、越快越好、必须保障性能、必须保障业务连续、等等。
有不少团队认为，以上的要求都要满足，但是在实际上，当鱼与熊掌不可兼得时，就会面临艰难的选择，那么识别唯一的最高优先交付要求能够帮助到艰难选择。
常见的交付频率有：每日、每周、每月、每季度、按需高频（高于每2周一次）、按需低频（低于每2周一次）。
根据团队所在的实际情况，对于交付频率，不难做出选择。当然由于世界变化越来越快，竞争激烈，导向上鼓励选择更高的交付频率。
团队模型
团队模型主要说明团队分工大方向以及角色分工。首先的硬性指标是团队规模，敏捷鼓励采用小团队，典型5~9人，一般不超过12人。
在团队大方向选定后，选择团队角色设置，典型团队角色设置如下：
- Product Owner，Scrum Master，团队成员
（当前敏捷团队中，采用Scrum团队模型的比例比较高） - 传统项目团队
项目经理，成员：开发、测试等等 - 某XP团队
敏捷教练，团队成员 - 看板团队
团队领导、团队成员、看板管理员
对于汇报关系，也是团队模型值得考虑的部分。在绝大多数组织中，汇报关系是客观存在，明确汇报关系，能够帮助团队开展更好的沟通管理和干系人管理。
管理实践
管理实践是指与代码不紧密相关的偏管理类实践，比如各类会议、估算度量、风险管理、白板看板等等。 对于管理实践，如果采用迭代开发，那么首要回答的问题是迭代周期是多长。迭代周期的选择必须匹配交付频率，一般地，常见选择2周。典型的管理实践有：
- 来自Scrum系列管理实践
计划会议，站立会议，评审会议，回顾会议等
Backlog、燃尽图等 - 来自精益
看板，价值流图等 - 综合自PMBOK
风险管理、干系人管理、范围管理等等
配合管理实践的各类工具有：
- 大型ALM工具：RTC，VSTS，Polarion
- 中小型ALM工具:Jira，Redmine
- 云工具：Tower，Rally
- 看板：物理看板，电子看板
- 简易工具：Excel
工程实践
工程实践是指与代码紧密相关的偏技术类实践，比如持续集成、测试驱动开发、用户故事等等。常见的工程实践有：架构设计、需求分析、持续集成、TDD、ATDD、BDD、UI自动化测试、非UI自动化测试、探索性测试、用户故事分析，等等。这些工程实践一般不会在一开始就采纳，往往的，在敏捷开发进行中，随着每次回顾来选择合适的实践，逐步建成。
常见配合工程实践的工具有：
- 配置管理：Git，SVN等等
- 设计：UML
- 需求：Fitnesse、Jira、Rally、Wiki等
- IDE：eclipse，myeclipse等
- Code Review: ReviewBoard、Gerrit
- 代码扫描：SonarQube
- 测试：xUnit、Selenium
- 持续集成：Jenkins、CruiseControl
完成定义
对于以上管理实践、工程实践的选择，往往会形成相应的DoD。在以往的说法中，常见用退出标准 , 完成条件等等。在敏捷软件开发中，存在多级的不同的完成定义-DoD，以下分别说明。
迭代DoD
在Scrum中，一般需要预先定义DoD，常见的迭代DoD条款有:
- 所有完成的用户故事得到PO的验证
- 所有代码得到静态分析，纠正最高级别的不符合项，静态分析的规则参见…
- 所有新增代码得到人工评审
- 所有完成的用户故事都有对应的测试用例
发布DoD
而对于发布，一般就有更加严格的要求，发布DoD的典型条款有：
- 完成发布规划所要求的重点内容
- 通过发布的回归测试，回归测试范围是全范围，回归比率不低于50%
- 修复所有等级为1、2、3的缺陷，4级及4级以下缺陷不超过20个
用户故事DoD
为了更好的达成迭代DoD，就需要提前注意，所以有些更加细节的DoD得到识别并使用。
用户故事DoD列举样例如下：
- 用户故事最终的描述符合INVEST
- 用户故事得到测试用例的对应覆盖
- 用户故事得到对应的自动化测试用例
- 用户故事得到用户代表试用并初步认可
每日DoD
典型条款有：
- 搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。
- 下班前必须检入当天书写的代码
- 当天的代码必须在当天或者第2天邀请同伴进行代码评审
- 搭建持续集成环境，当天上下午必须至少各检入代码一次（这与第1条可能冲突）
- 采用TDD，凡是检入的功能代码必须要有对应的单元测试（严格采用TDD）
其它DoD
敏捷团队追求内建的质量，根据碰到的问题也许会设立更多的DoD，这完全可以由团队自行来决策。不同级别的DoD可能会重复部分内容，这样的重复是在不同层面对相同事物的强调，是可以的，但需要保持一致。
敏捷团队章程样例-某互联网开发情景
如下提供一个某互联网开发团队的团队章程供参考。
团队愿景
团队名称：闪电Flash 使命：快速提供互联网金融技术解决方案，成为国际一流的互联网金融开发团队！
价值观：敏捷、诚信、协作、创新、成就
交付目标
高频交付，优先快速响应客户需要
团队模型
团队分工：特性跨职能团队
团队角色：产品经理1位+开发经理1位，各类成员，覆盖前后台开发到非UI自动化测试到UI手工测试，一共7人。在行政汇报关系上，成员向产品经理和开发经理双线汇报，产品经理与开发经理向团队之上的领导汇报。
主要的管理实践
- 选择迭代周期为2周，每2周进行展示回顾会议
- 定制工作流工具管理用户故事流动，不识别用户故事的任务
- 同时采用物理看板管理用户故事流动，手工与工作流工具保持同步
- 每日早会
主要的工程实践
- Git守护主分支加功能特性分支
- Gitlab带强制合并code review
- 合并触发集成带非UI自动化测试
- 每日构建带代码扫描和测试覆盖率观测
完成定义
此样例的所有DoD条款列举在一起了，不同层次要求可以从内容中看出来。
- 所有用户故事经过PO确认、测试，走完全部流程，所有新增或者的用户故事都有对应的新测试用例，并执行通过
- 每天下班前必须检入当天书写的代码，每周至少2次把进行中的分支合并到develop
- 所有新增或者变化的代码必须得到人工评审，在合并到develop分支时必须提交合并请求
- 晚上自动进行静态代码检查、编译、部署和测试，如果有缺陷和新不符合项，每日首先修复前一日构建和测试发现的缺陷和新不符合项。
- 对于发布，需进行全范围回归测试，回归覆盖率不低于30%，所有等级为1、2的缺陷必须修复，3级缺陷经过带缺陷发布审批后可以发布，但绝对数量不得超过3个，4级及4级以下缺陷不超过20个。
小结
本文说明了什么是敏捷团队章程，给出了敏捷团队章程典型的5个方面。在最后必须指出，敏捷团队章程必须是一份鲜活的章程，每次团队回顾都值得来把回顾所得加入或者修改到敏捷团队章程。这份章程不在于面面俱到，恰恰在于刚刚好并鲜活的指导团队，让团队成员觉得有帮助。在具体实践中有争议时应当首先考虑团队章程是否对此有说明，如果有，按说明办；如果原说明不合适，如何修改；如果没有，是否值得加入。最后强调，团队章程的权威性应当高于团队里面的任何角色。保持团队章程的鲜活和权限，是团队持续敏捷的好办法。
参考资料
- 一个成功敏捷团队的失败历程， 咕咚老王， http://t.cn/Rc94ZYD
- 团队章程—团队合作新工具(上) ．上海质量．2011-7
- 团队章程—团队合作新工具(下) ．上海质量．2011-8
扫一扫
1131
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
