敏捷团队一般被描述为“跨职能的小团队”，跨职能是团队内部有不同角色担负不同职责，小团队指的是团队的规模不大（一般10人以内）。虽然是小团队，在启动和协作的过程，依然要形成一些基本的行为规范。
试举几个栗子。
站会规则：
在敏捷团队的构建初期，一般站会是最容易被导入的敏捷实践了-源于其简单易行，大家呼朋引伴呼啦啦一下就可以聚集这个会议。而恰恰是这个简单，很多时候最容易做不好。比如有人迟到，有人看手机，或者听到自己不感兴趣的内容直接神游八极了。这样的结果就是最终站会效果不好-在站会这样的小事情上都没有“共同承诺”，更不用说任务和冲刺这样更费心费力的实践了。
那么，站会的规范应该怎么做呢？
在站会之前，团队通过共同决策（具体形式比如站会开始前的“站会”），大家一起决定：每天固定时间9点30分在大屏幕前开始站会，迟到者做5个俯卧撑或者发一个20元的红包，开会期间全部手机禁用，有特殊情况需要接打电话请退出站会，在旁边接打电话；每个人针对自己任务做进展陈述，对于需要深入讨论的问题先记录下来，等待会后再同步等。
DoR（产品列表就绪的定义）规则：
对于进入产品待办事项列表，团队的公约可以归纳为6个原则INVEST和4大特征（DEEP)。我在另外一篇文章中有详细对DEEP的思考，可以参考。Scrum敏捷产品列表管理的再思考
对于INVEST的说法解释的很多，后续我再另外用文章介绍。
6个原则INVEST
Independent相对独立
Negotiable可协商
Valuable有价值
Estimatable经过估算
Small大小适宜
Testable可测试
四大特征（DEEP)
Detailed appropriately 详略得当
Emergent 涌现的
Estimated估算过的
Prioritized排序过的
DoD（完成的定义）规则：
对于敏捷团队来说，判断一个事情是否完成与原有的协作模式有所不同。以往的项目团队，一般会划分很多个完成阶段：如产品设计完成，研发完成，测试完成等好几个阶段。为了方便追踪，划分阶段也是无可厚非，而这只是从内部团队的视角出发-很显然，我们如果还是从小团队的视角出发，容易造成局部优化，反而造成全部流程的阻滞（如研发单纯的完成很多的功能开发，没有做必要的自测，随意的把任务推到测试库里，给测试团队造成堆积）。
如果从用户的视角来看，Scrum的团队理论就可以说得通。在Scrum Guide中，有这么一段话：
Scrum 不认可开发团队中所谓的“子团队”，无论是否有特别的专业领域，例如无论是测试还是业务分析的成员都不能划分为“子团队”。此规则无一例外； 同时,开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
从客户的角度来看，我提出的需求和功能，在你的团队内部如何流转我并不care-只有两种状态，完成或者没完成。就算是你内部完成了编码和测试，只差最后一步的上线-没有上线就是未完成，没有例外。
在团队中建立完成的定义这样的“公约”，就是统一团队认知的过程：没有那么多的阶段，99%都不是完成，功能交付给到客户可用，才是真正完成。
敏捷团队执行过程中还有很多的团队公约。所谓团队公约，我认为就是跨职能团队在自组织的形势下自然生长出来的基础规范，其最重要的功能是平衡团队认知，规范团队行为。毕竟，自组织团队自己制定游戏规则，才是敏捷的精髓不是吗。
