Scrum执行中的注意事项和常见问题

Posted 2021-04-25 技术大V

文章已提请相应维权机构保护，未经许可严禁转载，否则将承担一切相应后果。

开发模式演进史(四)

在上一篇我们介绍了Scrum开发方式，在这一篇里，我们讨论一下Scrum在具体执行中，常见的一些问题和注意事项。

第一个经常被谈起的问题就是产品负责人PO和Scrum Master分别由谁担任。

PO一般由项目经理或者产品经理担任。这个是没有问题的。在某些情况下，也有让开发组长或开发经理担任的情况，这种情况一般是团队较小，没有专职的产品经理，或者一个产品经理要同时负责多个开发组，精力不够。这种情况下就让开发方面的经理和组长，承担了一部分产品和沟通的职责，这也是可以理解的。

Scrum Master的情况更有意思。在一般情况下，Scrum Master是由开发团队里面比较资深的员工或者开发经理\组长担任的。Scrum Master需要帮助团队扫清障碍。这里的障碍可能是技术性的，也有可能是非技术性的。如果是技术性的，资深的员工或者开发经理\组长通常在技术上较强，可以提供帮助。如果是非技术性的，资深员工或者开发经理\组长比起资历较浅的员工，也有更多的人脉和威信，相对更擅长跟人打交道。

另外如果在一个开发团队里面有多个资深员工并都掌握Scrum方法的话，更好的方式是让他们轮流担任Scrum Master。担任Scrum Master的经历会帮助员工从另外一个视角看问题。同时也能培养他们的领导才能，帮助他们更快地成长。同时，有多个备选人员也能预防单点失败。笔者曾见过几个非常成熟的开发团队，几乎每个成员都有担任Scrum Master的能力，每个人都能自发地实践Scrum的流程。当然这样的团队是可遇而不可求。

有一种很有争议的情况，就是由项目经理或者产品经理担任Scrum Master。这种方式的支持者认为，由于项目\产品经理一般比较擅长沟通。和与人打交道，让他们担任Scrum Master可以更好地扫清非技术性的障碍。同时这样不用耗用开发团队人员的时间来做Scrum Master的事。而笔者对这种方式持保留态度，不是特别赞同，原因如下：由于项目经理或者产品经理一般也担任PO, 很多时候在这种情况下是把Scrum Master和PO集于一人了。而PO和Scrum Master在职责上天然就有利益冲突的地方。PO代表客户的声音。从客户的角度来讲，他们希望他们所需要的功能更多更早的交付。而Scrum Master经常需要为开发团队说话，保证开发团队不受干扰，产出高质量的代码。为了保证软件的质量，需要花额外的时间进行各种测试，找出潜藏的问题，对有隐患的地方进行修改。一昧要求在单位时间内产出更多功能的结果，很多时候会在软件质量上留下大量隐患，最终也会降低客户满意度。正确的做法，是在产出功能的数量和代码质量之间达到一个平衡，而这个平衡是在Sprint计划会议上, 通过Scrum Master、PO和开发团队反复讨论权衡作出的。把Scrum Master和PO都让项目\产品经理担任，相当于把原本稳固的三角关系中两点合为了一端，剩下的另一端必然要承受比原来强很多的压力。开发团队可能在压力之下产出更多不合规范的代码，出现Bug后最终伤害的还是公司的名誉和利益。开发团队在产出更多功能的压力下频繁的加班加点，长此以往，也会降低开发团队的士气、积极性和工作满意度。

还有一个在国内的传统企业的IT开发部门比较常见，在互联网企业和外企不太常见的问题，就是比较高级的管理层，直接越级插手开发事项的问题。这样直接破坏了Scrum的基石之一，开发团队的自主管理。如果Scrum Master也只是普通员工的话，很难抵抗来自较高层的压力，久而久之Scrum Master就成了摆设，Scrum本身也名存实亡，难以激发出开发团队的主人翁意识，回到了传统的上级管理模式。如果是在这种情况下的话，建议还是由开发经理和开发组长担任Scrum Master，一方面方便沟通，另一方面在面对不合理要求时也能取得较好的抗压能力。

每日站会(Daily Scrum/Daily Standup)的时间控制也是一个关于Scrum经常被谈起的话题，大家都知道，每日站会不应该超过20分钟。每个人发言时间一般不应该超过三分钟。但事实上，很多时候都会超时。超时的原因主要是两方面：有团队成员叙述自己的进度时用时过多。或者大家卷入对某一个具体技术问题的讨论。如果是前者的话，Scrum Master应该及时提醒发言应简明扼要，被提醒一两次后基本都会改正。如果是后者的话，应该让卷入具体技术问题讨论的几个人到站会后再自行讨论，不要耽搁和此问题无关的其他人的时间。

最后，实行Scrum的团队在项目的后期需要考虑重构的问题。当项目刚开始时由于Scrum都是采用小步快跑的模式，一小块一小块的代码被添加进来，每一小块的代码, 在当时都是符合要求并快速完成。然而，当代码变多，组合到一起之后，有可能原有架构会慢慢变得不再符合要求，这时就会需要重构。所以在项目进行到后期，代码库变大之后，需要重新检视整个代码结构并考虑是否需要重构的问题，如果确有必要，等到有时间和条件时进行重构，这就是所谓的“技术还债”。

点此查看前篇:开发模式演进史(三):