Agile Alliance 如何打造自运转敏捷团队-京东云开发者社区

每一个团队都有自己的条条框框，这些条条框框指导着我们的日常工作，是我们的行为准则。

敏捷团队建设，团队规范不能一意孤行，每一项都需要获得团队中每一个小伙伴的认同，否则很难贯彻执行下去，出现口头执行实际无法落地的情况。这让我想起春晚黄晓明的一句台词“我不要你觉得，我要我觉得！”

放权≠放任，在敏捷团队推进过程中，我们也制定了一些团队内部约定，但是所有约定的形成都是基于解决现有问题而制定的，让小伙伴能够深入体会到这样做的好处，让每一个人成为规则的受益者，而不是简简单单的执行者。所有的约定都是围绕“打造自运转敏捷团队”这个核心目标，以提升个人自管理能力，让工作有序开展为目的团队约定：

1. 为保证按承诺交付，本周迭代启动后不接受新需求插队，新需求统一放到backlog中进行排期，每周可以对未启动的任务排期进行一次重新梳理。保障紧急任务在不影响大家工作节奏的前提下，能够得到紧急处理。
2. 需求认领要先领取优先级高的任务，不能光挑简单任务。避免了挑任务，复杂任务没人承接的情况出现。
3. 一次一个，做完再领。（临时插队的任务除外，通过预留buffer时间进行管控）。避免多任务并发，增加自管理难度，影响个人工作效率。
4. 研发领取任务时必须给出排期，测试根据研发排期给出测试的排期。明确任务目标，确保工作有序开展。
5. 研发提测前一定要做单元测试，并且通过冒烟测试用例。从启用单测及冒烟测试以来，提测质量得到了大幅度的提升。我们以一个大项目进行了对比，问题数从原来的50+减少到了现在的20+（此处有掌声）
6. 公开透明促进协作，使用看板管理个人工作，每日工作结束前，在看板上及时更新看板。
7. 每天站会根据看板向团队共享工作进展：
① 前一天做了什么? 进度是什么样的？是否按计划完成工作？
② 问题提出，相关人员留下进行讨论
8. 验收标准约定：
① 产品提出需求后，简单需求直接给出验收标准；复杂需求研发出详细设计，设计评审后产品、研发按照约定进行任务卡片拆分，同时给出验收标准。
② 需求需要测试验证的， 由测试对任务的验收标准进行补充。
9. 三个人以上共同开发的任务认为是大需求， 大需求需要指定第一责任人，负责整体需求跟进，以及后续测试沟通、资源协调、上线， 按需求整体的5% ~ 10%进行工作量加成 （按外系统交互来定百分比）没有这个约定之前，测试在测试过程中，经常发现报了问题，找不到人来看问题，研发也不太好判定问题是否跟自己相关，最后变成没人跟进，影响项目进度。现在指定了第一责任人，对整个项目负责，过程中有问题，第一时间有人跟进，推进了项目进度同时，也培养了个人的项目管理能力，一举两得。
10. 对于比较大的需求，其中比较独立的需求点不要合并到大需求中进行提出，可以单独提需求，独立上线，避免需求互相依赖，延长需求周期。在以前，经常出现几个小问题，合并需求提出，导致项目周期边长，开发难度边大。现在我们对需求进行拆分解耦，无关的需求拆分提出，可以进行快速迭代上线。同时也大大降低了项目交付难度。

经过前期的踩坑及团队磨合，团队中的约定已经得到团队小伙伴的认可，并贯彻执行下来，为团队稳定运转保驾护航。

扩展一下：有很多小伙伴经常分不清团队公约和DOD，会把他们混在一起管理，上面TC团队的实践都是针对团队公约的，是团队协作的约定，而DOD是针对软件是否完成的把控，更多的是对质量的把控。

------------

###### Being Agile 京东物流技术发展部效能提升部
###### 作者：供应链技术部  刘海鸣