敏捷转型四两拨千斤的秘密 | 第11期

如何打破常规的思维模式？如何让利益相关者更好地参与进来？为响应外界快速变化的环境，很多企业开始选择进行敏捷转型来提高自身的经营能力和适应能力。

践行者第11期，我们邀请到了Scrum联盟最高级导师CTC、资深企业级敏捷教练和咨询顾问Ella Yao，一起聊聊敏捷转型的那些秘密。

一、  敏捷转型四两拨千斤的秘密

企业想要敏捷转型成功都需要具备一些条件，Ella老师表示 第一是高层领导者的支持，真正地为这件事承担责任； 第二是现有的企业文化和敏捷所提倡的价值观匹配度，匹配度越高，敏捷越容易落地。

即使上述条件统统满足，企业在敏捷转型的过程中也会遇到各种各样的问题： 如何获得团队成员的支持？

• 什么样子的团队或企业更适合使用敏捷呢？
• 需求怎么做好价值评估，从而做好产品列表的需求优先级排序？
• 名义上是敏捷，实际上很多需求走特例发布、中间版本、不跟迭代走，怎么才能调整节奏？
• 在传统的瀑布模型里，现在是以组织人员先做可行性分析，技术预研后再来估算工时的这种情况，在敏捷里怎么实施比较合适？

在此次直播中，Ella老师将上述问题的答案融进了自身的敏捷实践故事中，绝对满满干货！ 想了解更多关于敏捷转型的分享，欢迎观看直播回放~~

二、 问答实录

Q1： 一些想要做转型的团队或领导邀请你去到团队或企业后，你一般是怎么跟他们沟通的？

A： 前期，主要与团队或企业的管理层接触，包括了解他们的主要诉求，做敏捷的原因，想要解决的问题。 后期，会同内部员工进行沟通交流，包括向他们讲解做敏捷转型的原因，转型过程中可能会遇到的问题等。

Q2：如果企业领导想要进行敏捷转型，但是团队意愿度跟领导不一致该怎么办？

A：有些团队开始是不理解敏捷转型，因为很多任务是安排好的，现在又要拆成一个个迭代。因此，很多事情需要慢慢向他们说明，比如阶段性明确小目标的好处、需要透明化的好处等。在敏捷转型过程中，大家一旦真切地感受到敏捷的好处，就会从最初的抵触过渡到接受，彼此之间也会建立起信任关系，这更利于进一步影响他们。

Q3：在敏捷转型的过程中你认为获得团队信任的关键转折点是什么？

A：一方面是他们能感受到Scrum本身所带来的好处，如阶段性的迭代目标的可视化，站会、评审会、Review会议的透明性等。另一方面可能是敏捷教练自身与团队的连接关系，敏捷教练尽最大的努力帮助团队实现敏捷转型。

Q4：面对控制欲很强的领导团队，在转型过程中受到了他很大的干扰，面对这种领导可以从哪方面去切入？

A：碰到这种情况，与领导对着干可能会适得其反。一般来说，我会先去了解一下领导真正想要达成的目标，再去寻找解决问题的突破口。

对于这种情况，总结以下三点： 第一，如果是特别关键的干系人，要与他保持密切地、定期地沟通，及时将问题反馈给他；第二，我们要注意表达方式，最好采用诙谐幽默的方式切入，再将话题引入真正问题上；第三，给领导提建议时要注意委婉。

Q5：Scrum Master每天的沟通有哪些？

A：第一是每天早上的15分钟站会；第二是针对站会中提出的问题进行讨论与解决；第三是与其他团队进行沟通交流；第四是Scrum Master之间的定期借鉴学习；第五是每周跟管理层进行一次简短汇报。

Q6：怎么考CTC？

A：这需要在通过CSP后，Scrum Alliance去网站上提交申请。按照网站申请步骤填写申请材料，递交申请后在面试和官方审核通过后就可以拿到认证。

网站上提交申请通常需要注意这几点：

• 在过往几年，你有作为敏捷教练去教练团队的经验；
• 不管是作为组织者、讲师、或者只是参会人，你需要有作为敏捷社区的贡献者的经验；
• 你需要有专业教练的能力。

Q7：在传统的瀑布模型里，组织人员先做可行性分析，技术预研后再来估算工时这种情况，在敏捷里怎么实施比较合适？

A：这种情况的团队在前期做可行性分析或技术预研的时候，通常是不采用Scrum，尤其项目没到正式启动阶段，人员还没到位。前期团队可能会使用看板，先把可行性分析、技术预研等获得内容管理起来，随着内容的完成与人员的到位再开始使用Scrum。

Q8：名义上是敏捷，实际上很多需求走特例发布、中间版本、不跟迭代走，怎么才能调整节奏？

A： 先 澄清一点，发布是按业务需求随时发布， 而 迭代是开发的节奏，不是发布的节奏，所以发布和迭代 是 两个概念 。

首先要明确这些特例需求到底是什么类型的需求，是可预知的需求还是不可预知的需求。

其次要明确这种情况发生的频率。如果只是偶尔出现特例需求，是不影响迭代的推进，但特例需求经常出现，那团队在做迭代计划时，可以考虑预留一些时间，专门去处理这类需求，给整个迭代计划增添一定的弹性灵活度，从而确保整个迭代计划顺利地推进。

Q9：什么项目或者组织不适合用敏捷？

A：敏捷本质上是为了让项目或者组织能够迅速响应外界快速变化的环境。

外界的环境是快速变化的，用户的需求是日新月异的，竞争对手也是与日俱增的，所使用的技术也是不断更新换代的，在这种情况下，你的项目或者组织就比较适合采用敏捷的方式，因为可以提高组织的响应能力和适应性。

但反过来讲，如果外界环境、用户需求、用户市场等变化非常小甚至不变，在这种情况下是可以不采用敏捷方式。

Q10：敏捷交付中，迭代结束时需要完整的功能上线吗？

A：迭代结束时需要有完整的功能完成，但是上线跟迭代是没有关系的。发布与迭代是解耦的，是没有关系的。

Q11：在团队有限的情况下，怎么做好减法使得做的需求价值最高？

A：这种情况下很有可能是团队还没有一个真正的P O在帮你们做这些决策，这就会导致需求的优先级高低很难分辨。

在团队级别，因为价值很难有一套评估体系，因此判断需求的优先级可以进行共同协商一下。如果想要量化价值需求，一定要把价值计算的结果进行排序。

Q12：如何做好向上汇报，从而让上层认可敏捷转型是对的决策？

A：一个团队的Scrum Master很难通过一个汇报让高层觉得应该做敏捷转型。但大家可以参考一下琳达·瑞欣（Linda Rising）所写的《从1到100，用心求变》中的一些变革模式，书中提到一些方式是运用到实际的小技巧，而不是无从下手的模型。

Q13：企业敏捷转型成功需要具备哪些条件？

A：首先也是最重要的条件是一定要有高层领导者的支持。这不仅是口头上的支持，而是领导参与到敏捷转型过程中真正地承担责任。

其次是企业现有的文化跟敏捷所倡导的价值观。如果匹配度越高，敏捷转型越容易落地；但如果匹配度低，就很难形成氛围与文化。

Q14：需求准入条件是什么？有什么参考标准？PO拆解需求应该拆到什么颗粒度呢？

A：团队一般是有一个DoR，团队可以共同协商定义一下。以下这些是DoR条目，但通常也会把这些作为需求准入条件：

• 需求是不是拆得够小
• 需求是不是梳理会上讨论过并且大家一致都理解了
• 需求是不是所有的验收标准已经足够细化与清晰了
• 可需求的优先级是不是大家都讨论过并达成一致了

一般来说，PO拆解需求就是 拆到一个需求至少一个迭代能完成的颗粒度，但不同产品的拆解需求也是有一些限制的。

Q15：需求验收标准是不是必要的？

A：这是必要的，DoR里通常也包含验收标准要达到什么要求。

Q16：完成的定义（DoD）很重要，但定义多了感觉对团队效率有影响。怎么把握这个度？

A：DoD也是团队一起定义的，可以对质量有很好的保障。DoD定义多对工作效率基本不会造成影响，可能对每个迭代的完成率或完成量有影响，但这个不等同于效率。

在质量与其他因素的平衡上，别人很难给准确建议，因为每个产品的情况不同，质量的意义不同。所以，团队需要协商怎样的DoD更适合自己。有些企业也有定义迭代DoD，release DoD等不同level的DoD，这个做法可供参考。