敏捷转型中常见的问题

总结了敏捷转型过程中常见问题，及应对技巧，有些是教练提供的，有些是自己的实践，供大家参考。大部分问题还是比较有代表性的，还算比较有价值吧。

问题1：如何积极的引导别人？

首先，做为SM，其正向信念、正向表达非常重要。

这直接影响团队是否是积极向上的文化。SM要积极挖掘团队成员的优点、真心的赞美别人，鼓励团队成员用积极词汇正向表达，潜移默化的影响别人。

其次，了解团队成员的特长、兴趣、爱好等并为其创造在团队中展示的机会。比如，可尝试做技能集市，发挥团队成员的特长，让团队成员的诉求互补，增强团队的凝聚力，提高团队成员的能力。

再者，学会将Yes...But的沟通方式转为Yes...And的方式，鼓励团队成员更加积极的表达。

问题2：如果自己都不懂的方案，能推销给自己的团队吗?

作为团队SM不仅要带领团队，坚定的执行项目的任务，更有责任引导PO和团队去判断和选择价值、主动问为什么做？以洞察到真正的用户诉求，而不仅仅是表面的需求。

实施Scrum时，故事进入开发迭代，必须有明确的用户角色、用户价值和使用场景以及验收准则，以便更有效的传递价值、完成交付。不能像以前那样仅是被动的接受，有疑问也不讲出来。以至于团队和项目层产生隔阂，或者做了并不是用户真正想要的东西，这就是最大的浪费了。

问题3：怎么有效的了解员工的诉求？

作为团队SM需要了解每一名员工的内心诉求，每个人的“人生召唤”是什么？只有了解了这些，SM才能更好的将个人诉求和团队诉求相结合。更有效的帮助员工成长和能力提升。SM需要放低姿态，用平等的态度和真诚的心，取得员工信任，了解其内心深处的真正想法。要化身心理咨询师、鼓励师，把队员们的诉求和团队的成长结合起来，才能更加主动、有效的工作。

问题4：五行模型如何运用到实际工作中？

如果真的要用五行模型，现在就可以用。“把香蕉递给我”这件小事就达成了五行平衡，五行是启发思考的工具，要在实际工作中多去体会。

问题5：团队状态平平，一直没有明显的改进，如何破局？

首先，团队需要建立正向的反馈机制。SM要把心态放低，感恩别人作出的努力和贡献。发自内心的感谢、表扬他人。她们一定会感受得到。不要低估自己的影响力，大胆的去表达。可以在回顾会上设置感谢环节。

其次，盲从是最糟糕的状态，最要不得！团队要去要做有意义的事情，没有意义的不要去做，不做形式化的事情。

最后，自己要行动起来，认为正确事情要率先做起来。Action is power.

问题6：团队内的考核问题？

要明确团队内个角色的职责。PO/SM/团队成员，应该做什么？除了开发以外还应该做什么？根据职责才能确定工作好坏。团队成员可以采用团队内评价，互评的方法。PO/SM除了团队内考核外，还要有领域、项目考核。

特别需要强调的是PO不对SM有考核，SM的考核也不应与普通团队成员一样。

SM的核心工作输出应该是士气被激发出来、高绩效的团队。

因此，SM考核的重点是团队的成长、领导力、教练能力等。

问题7：回顾会确定的改进措施有反复，怎么办？

问题分析没有找到根因，改进措施只是针对问题的现象解决了表面问题；还有可能是改进措施不具备SMART原则，在执行过程中很容易走样。总是要有针对性的分析和解决。

要避免这个问题，首先，要从现象开始分析，找到问题背后的原因，然后针对根本原因制定方案。其次，问题解决方案要符合SMART原则，具备可操作性。点滴进度都要展示、回顾、再展示，直到团队针对这个问题已经形成习惯。

问题8：代码走查的好方法？

结对走查。建议每天定时分享。代码走查更重要的功能是知识传递功能。要避免代码走查成为测试、认证环节。功能正确应该通过测试确认，而不是期望通过代码走查背书。

问题9：团队转型中，遇到难以转变的员工如何处理？

每个人的特长、性格不一样。有的人天生就是积极主动的，有的人天生内向。SM需要根据不同的人，使用不同的方法，发挥其作用。一个秘诀是多用正向引导。

可以选择先不管，等团队其他有意愿的成员先转变，努力做出结果，让他感受到团队的变化，触发他转变。

也可以找到更牛的人与之结对，让其切身体会到好处，然后自己转变。久而久之，那些本来不够积极主动的人也会慢慢主动。重点是一定要正向反馈。

问题10：如何调动团队中态度比较消极的成员的积极性？

首先，要从自身出发，放低身段。SM不是团队领导者，而应该是团队服务者。应该帮助团队成员和团队成员一起努力，达成团队共同的愿景，要让大家感受到你的真诚。

其次，跟他深入沟通，挖掘他的优势，帮助他发挥出来。每个人都希望得到认可，对于团队成员的优点，要积极鼓励，并发散到整个团队。

最后，团队是一个整体，要发挥团队的力量来影响他、带动他。

问题11：如何调动团队成员的积极性?如何给团队注入新鲜血液?

首先，应从自身分析，找到自身方式、方法、组织、为人等等方面是否需要改进，给自己充电，提升和充实自己才能影响别人。团队是一面镜子，团队产生问题往往是自己有些方面需要改进。

其次，多与团队成员沟通，走进成员的内心，积极倾听成员的心声。找到真正的诉求，找到共同的目标。

再次，可以通过转变例会、分享、讨论等活动的形式、人员角色、环节等，给大家带来新鲜感，以调动大家的积极性和参与度。

最后，还有一点是最重要的。我们是一个集体，一个共同目标的圈子，积极与其他团队SM、教练沟通，寻求帮助。相信集体的力量是强大的，共同改进、共同进步。

问题12：如何提升团队整体能力？

1. 团队能力提升方式：建立能力规划，定期review。完成任务的同时，要关注成长。制定任务目标的同时也要制定成长目标，纳入考核。

2. 模块壁垒打破： 重要模块采用团队重构的方式，业务熟悉的人员负责需求。其他人员共同参与开发。模块重构结束之时，就是团队所有成员掌握模块之时。僵尸模块可以不关注。另外，重构的时机应该选择在每年的2、3月份（闲时）

3. 知识传递：知识传递可以通过各种形式，结对开发，重构，讲解，防火墙，代码走查等各种形式。对于技能高但是不积极分享的人员，可以不强迫，鼓励其往技术深度方向发展。

4. 关于测试：测试应当分层，能在底层测试就在底层测试，测试也是一等公民，要考虑可测试性设计，降低测试开发维护的工作量。测试应当区分快速测试和慢速测试，耗时长的测试和耗时短的测试用例应该分开执行。

问题13：团队PO的某些意见和想法与敏捷理念冲突怎么办？

首先，任何事情都有其背后的正向意愿。PO提出的一些与敏捷里面相左的意见也一样，必然有其背后的正向意愿。因此，挖掘出该正向意愿，进行分析和认可，再进行冲突解决。

问题管理的整个过程中可以采用Scrum的三原则：透明、检视、改进。

以具体问题为例，开发过程中要求从质量考虑，必须提供UT、IT等测试用例，但是对于某些任务，PO认为时间紧急，不需要提供，只要抓紧时间完成功能交付即可。事情的结果是功能完成了，UT等待完善的部分永远不会有人做。

首先可以肯定的是PO希望按时交付功能的意愿，也是项目、产品、团队的共同意愿，是正向的，也是我们要首先保证的。

其次，把快速交付而缺失的部分“技术债”透明化，让项目、PO以及团队都明确清楚该缺失，并用一定的机制来跟踪。然后及时检视、回顾、不让“技术债”在中途丢失。

最后，进行改进，可以在最及时的时间内还掉“技术债”。冲突只是表面现象，找到背后的原因，仔细分析，而不是盲目的看待冲突本身。

问题14：SM是否需要全面的专业技能?

敏捷团队中，对多数人员的技能要求是T型人才，而SM也不例外。他在教练技术，敏捷及scrum等方面应该是专家，但业务同样需要了解，只是不要求那么深那么专罢了。

需要注意的是sm不能是技术专家，尤其对于成熟度还不是很高的敏捷团队。否则sm很可能会成为事实上的权力控制中心，将不利于自组织的形成。