常犯的敏捷错误

在实施敏捷过程中，我们总会遇到一些错误，下面让我们花几分钟，来 细数我们犯过的错 。这些错误一些比较常见常，也有一些带来的后果比较严重的错误，供大家参考。

站例会时间过长

思前想后，这条绝对是应该放在第一位的。这可以算是所有新手SM都会犯的错，并且有些SM还不理解为何不能站例会过长。

站例会的目的是同步信息，让团队所有成员对于当前工作进度有一个相同的认知。这就要求我们在同步中，只能同步“状态”，而不能同步“细节”。同步状态已经可以产生足够多的“渗透式”沟通，达到我们主动帮助别人的目的。

如果此时同步过多的细节，则会让会议变得超长，而且会陷入到技术细节中。而这些细节不是每个人都在意的，这就会导致部分同事对站例会心存不满，从而逐渐削弱该站例会的作用。

选择太多工作

这个错误比较常见于刚刚转型的敏捷团队。此时团队野心勃勃，并且对于敏捷会有一种不切实际的幻想。这种情况下，绝大多数团队会在第一个迭代中计划过多的事情，从而导致迭代工作无法完成，从而影响团队士气。

在这种情况下，Scrum Master（或者其他类似角色，下面用SM 简称）需要在计划会议时，对团队进行全面的引导，在不打击团队积极性的同时，控制迭代计划量，避免后期产生不必要的士气影响。

模仿其他人

有些SM 为了让自己看起来更有权威，所以会有意无意的模仿其他成功的领导，希望借此来提升自己的接受度。但殊不知你在团队中是不可替代的，你就是你，不是其他人。所以跟团队相处时，不要模仿其他人，用你自己的真实状态来与团队相处。

不严格遵守四场仪式的时间点

有些团队为了所谓的“方便”或者“适应”，对Scrum 中的仪式时间点随便调整。但殊不知这种调整会打乱团队原本的节奏。比如有些团队喜欢将Review 会议提前，但是提前之后呢？提前的那几天看起来更早交付，但是交付之后，团队就进入了无所事事的状态，这是会极大的影响团队节奏感的事情。

教团队怎么做

这个是大忌中的大忌。敏捷团队中的Self Organized不是说着好玩的，这是让团队自我发现和提升的根本架构之一。我们对敏捷团队的要求之一（甚至是最大的要求），是希望团队可以通过内部自我学习的方式来实现continuous improvement，这个过程我们称之为coach。而“教”团队怎么去做，本质上是剥夺了团队自我提升的机会，放弃了让团队自我升级的契机。

未经足够的澄清就开始故事开发

这点也是常见于敏捷转型初期团队。团队成员为了快，从而在对故事澄清的过程中降低了要求。这就会导致团队开始一项事务的时候，还没有完全把握这件事情的来龙去脉，甚至连主体框架都没搞清楚，更不要谈所谓的UA（User Acceptance）。这种看起来“快”的作法，最终只会导致团队需要花费更大的时间在Sprint 中进行澄清。

计划安排过满

这种情况在项目进度落后时最容易发生，也常出现于部份初级SM。这种做法其实是一种微观管理，希望可以通过将团队成员时间全部塞满，进而达到提升工作效率的目的。

但很可惜，当前绝大的多数的脑力劳动，都无法通过安排过多任务来提升工作效率。

如果有人说“那可以延长工作时长啊”，那么请去看看敏捷原则第八条呗。

问的问题过少

部份SM喜欢做结论，而不是问问题，这点是非常不Agile的。

SM的角色是一个Coach，他的最大目的是帮助团队发现问题，然后团队自己解决问题。而SM 最有力的工具就是“提问”。

一旦SM 开始出现提问数量少于做结论或者给建议的数量，那么这个SM 也就向着微观管理的方向去了。

不开会

有些敏捷团队觉得自己比较小，所以对四场仪式有些抵触，甚至就“优化”掉这些会议。

千万不要！

四场仪式是经过无数团队实践后，得到印证的。即使你的团队很小，依然要坚持四场仪式的规则，不要做增删或者调整。

比如站例会就是为了同步信息，即使团队每天一起工作，依然不能保证大家100％知道别人在做什么，这时候站例会作用就体现出来了。其他三场会议亦然。

当然，你可以适当的变化时间，比如站例会缩短一些等等，但必须要开，不能认为缩减。

给团队压力过小

还记得这篇文章么？每次迭代计划，都是需要我们努力去一起才能完成的。如果SM 给予团队压力过小或者鼓励过小，这将会直接导致团队无法完成迭代内容的概率大大增加，久而久之团队将会失去冲劲，让团队自我提升压力减少，今儿降低了团队自我的提升速度。

抓住错误不放

错误是团队进步的促进剂，我们需要不断从错误中才能学到提升自己的知识。如果一个SM抓住团队的错误不放，只会让团队在做所有决定（自组织团队所有HOW层面的决定都是自己做）都会极度慎重，甚至会产生瀑布式的工作方式，这对整个敏捷团队都是一个极大的损害。所以当我们在发现错误时，分析错误并从中获取经验就可以了，不用抓住错误不放，并对此喋喋不休。