作者：J先森/趣丸科技敏捷转型教练
我是一名敏捷教练，负责趣丸科技研发中心敏捷转型的赋能和指导。在团队实践敏捷转型以来，我时常问自己：“现阶段我们的敏捷转型在做一件什么事情？如果能用一句话概括，这句话会是什么？”
最近，观察着各个团队的敏捷实践以及与内部敏捷教练的交流中，我似乎找到了这句话——在有序的流程上，构建团队的信任与项目的交付质量。
已框出三个重点：有序的流程、信任、质量。其实，本文还会讲另外一个点：提效。提效也是团队正在做的事情。
1. 信任
什么是信任？
这一篇，我想先跟大家分享「信任」，为什么先说信任，而不先说流程呢？流程是日常的活动，团队的协作行为都在流程上发生。信任，释义上：相信并敢于托付。信任是团队高质量协作的前提，是敏捷转型要走的第一步。工作在一个充满信任的团队，在协作的过程中，工作项只需要做对应的澄清，而不需要做太多解释性的工作。
如何构建团队的信任？
目前趣丸科技研发中心的敏捷转型团队，做了哪些动作去构建团队的信任？
1、加强团队的沟通
达成共识团队的合作变得更加紧密了，能感受到是一个团队，而不是受限于职能的对接。在这方面，许多的敏捷团队已经坐在了一起办公。在实践方面，每日站会很大程度促进了产研团队的日常沟通，答疑解惑。
2、积极响应需求
积极响应需求，不是只要插入需求，就无脑地纳入到当前迭代。敏捷团队在积极响应需求的过程中，是对变更风险的积极的暴露跟理性的评估。根据迭代的情况，客观地评判是否允许纳入到当前迭代。同时，产品人员应当澄清需求的目的跟内容，传递需求的价值解读。
3、进度清晰同步
这点在业务方的反馈中，站会的形式同步进度最为明显。以前产研的协作，需求整理过程跟研发过程都比较不透明。在需求评审的时候，研发人员才比较清楚需求的样子；在研发交付的时候，产品人员才看到开发出来产品的样子，进度不清晰。
现在，每日站会，伙伴们都会同步任务的一个进展情况，暴露风险项，拟定后续的行动项；迭代日历上，记录着里程碑事件，以及下个迭代的开展计划...
4、产品人员参与迭代改进
这里主要讲讲产品人员参与迭代回顾会。观察下来，很多团队的第一次回顾会，基本都会有关于需求文档的问题反馈，例如需求文档更新不及时、需求文档描述不清晰等。 理所应当，这个问题肯定是要改进的，而Owner往往就是产品人员了。在需求文档改进的这项事情上，也是产品人员一直需要努力的事情。
小结一下
构建团队的信任，其一，让团队这个场域变得开放、安全。更加开放安全的沟通，团队成员也敢于暴露风险；其二，相信相信的力量。在信任的基础上，团队可以做更多的尝试，能够在验证中学习、成长。
2. 质量
质量的修复成本
这里讲「质量」，我想要让大家聚焦『避免返工』四个字。下面这里有一张图，阐述的理论也很简单：越早暴露风险，其修复成本越低。
举一个极端的例子：如果等到软件要上线的那一刻，产品人员才发现开发出来的功能不是他（她）想要的。这个时候要返工的话，可能要从需求梳理开始，抢修（研发），测试（功能测试，回归测试等等），最后再验收上线，等同于之前的流程再来一遍，也会同期影响团队手头正在进行的工作。谁也不希望这样的事情发生。
如何控制交付质量？
说到这里，可能有人心里已经在问：趣丸科技研发中心的敏捷，是通过什么手段去控制质量？
1、建立有序的流程
目前趣丸科技研发中心大部分的团队实施的敏捷流程是Scrum，如下图。
每个角色都有明确的权责，每个会议都有明确的目的跟执行的动作，底层还有价值观指导着团队。大部分会议（包括会前会后）想达成的两个最核心的目的：1. 加强团队不同角色的人员之间的沟通，达成共识；2. 尽早暴露风险，制定行动计划，尽早解决。
2、持续检核准入准出标准（DoD)
我之前看到DoD的这些条目的时候，其实也会有一些不解：“设置这么多完成标准，我们的交付不就会变慢了吗 ？”在找寻答案的过程中，我给自己提问了一下：“我们交付的目的是单纯为了快吗？”相信这个时候，大家心里肯定跟我一样，有了答案——“欲速则不达”。快速交付的基本要求，应该是质量过关。然而怎么样去保证团队的质量品牌？那就需要有一些标准，也就是我们的完成定义（Definition of Done）。把这些标准下放到各个协作的环节中，团队成员互相检核，最终才能保证全流程的质量过关。
除了各个环节的准入准出标准，有些团队对紧急需求的插入也有准入标准。但这是准入标准，不是拒绝标准。可能产品人员就会觉得，这是不是在为难他们？其实不然，当我们有准入标准的时候，一方面可以让产品人员思考得更加清楚；另一方面，在信息比较清楚的情况下，研发人员做评估，做决策也会比较高效准确，同时紧急需求是否可以插入的反馈时间也会比较短。
3、团队的回顾机制
这里主要讲的是Scrum中的迭代回顾会（有些团队也有开复盘会）。迭代回顾会要开得比较高效其实比较难，但目前敏捷团队对这个会议的反馈还是比较好的，大家比较渴望能坐在一起讨论团队存在的问题，并对齐进行改进的机会。
熵增原理上，团队在时间轴上奋勇前进，必定会产生问题。当问题出现的时候，团队置之不理，或者没有一个机制能够去处理，那对团队的士气必定是一个莫大的伤害。试想一个很多问题的团队，还有人想待吗？电梯、汽车还年检呢。所以我一直呼吁，无论是敏捷团队，还是其他团队，回顾和改进的机制需要建立起来。改进的步伐一开始不需要跨得太大，每一次改进，根据团队的余力，做合适的改进项就行，主要是要做出成果。当有了成果之后，团队成员才能非常直观的感受到这个回顾机制的价值。
3. 提效
这里的提效指的是提升效率。提效这个事情，常常会从两个视角去提升：全局的视角、局部的视角。在敏捷的团队中，我们强调的是全局的视角。基于「价值流」去暴露团队当前价值交付或者团队管理上的阻碍点，进而利用可视化的方法进行「公开透明」。利用回顾会让团队「澄清阻碍点，达成共识」，进而制定「改进计划」（可以利用一些决策矩阵）。最终，将改进执行过程融合到实际过程中帮助团队迭代升级。
（决策二维矩阵）
如何帮助团队提效？
1、协作前置需求前置沟通
产品人员识别出未来的一些需求有技术实现不确定性的地方，主动找研发做技术预研，而不是等出完详尽的需求文档再沟通。如果技术预研后产出的结论是实现成本高，就能尽早反馈给产品人员，产品人员就可以判断是否要继续细化需求，不会造成浪费。UI设计稿迭代式输出：目前UI资源比较紧张的敏捷团队，会跟UI设计团队讨论出协作方案。简单抽象一下，一般都是这个框架：先输出UI的整体轮廓图以及后续出图排期。一边确认核心需求UI，一边输出UI，一边进行开发。尽量不因为UI资源紧缺而造成造成交付阻塞。接口文档先出：服务端开发人员预先定义「接口的名称和传输数据结构」给到前端和客户端开发人员。依照这份协议文档，各自进行开发。当然，细节是可以调整的，过程中进行沟通就行。
2、需求任务拆分需求拆分
一般会分两个步骤执行该动作。第一步是产品人员基于业务的视角对需求进行拆分。第二步，当第一步拆分的颗粒度还是较粗的时候，会由研发负责人基于系统的视角进行第二次的拆分。任务拆分：具体开发人员对其负责的需求，进行任务拆分。一般是要求按天拆任务。为什么要进行拆分？拆分的过程，是对需求内部的解构，一方面更加了解需求；另一方面是风险可控。
3、工具和自动化CICD建设
将工程上一些重复性的工作和容易犯错的工作交由系统帮助我们解决。团队主要是攻克不确定性的知识壁垒。功能组件化： UI设计组件化，前端组件化，乃至实现低代码平台。组件化的过程是在抽象系统的功能。自动化测试逐步演进：通过自动化的方式，减少测试人员人工式的投入，将更加宝贵的时间和精力投入到系统的质量建设上。其实在提效方面的改进的动作还有很多，在这里就不一一赘述了。想要了解的，敬请期待后续文章。
总结
「在有序的流程中，构建团队的信任与项目的交付质量」。按照阶段性目标去拆解的话，其实是：
目标①：构建团队的信任，把信任的的桥梁先筑造起来；
目标②：持续打造有序的流程；
目标③：提升交付质量，给快速的交付中，提供一个稳如磐石的河床；
目标④：提高研发效能，在快速的迭代交付中，从验证中学习，持续对产品和团队进行改进升级。
我们已经在路上了，如何走好这条路，持续性提升团队能力，是我们也是所有正在进行敏捷转型的团队需要共同面对的课题。
