当你的“敏捷”团队以蜗牛的速度行进：5个关键路障以及如何克服它们

在过去的十年里，作为敏捷项目的讲师和经理，我发现自己越来越认同我一开始工作的时候阅读的一个引述：

我们已经从一个教理（瀑布式）转到了另一个教理（scrum和XP），我认为所有的重点是我们被期望能做到敏捷的。我们的思维发生了什么？——Brendan’s Braindump中的注解。

然而大多数的软件工程团队，特别是那些精益开发团队，极其信赖像Scrum和Kanban这样的敏捷开发过程框架，在理论和实践中总有很大的差距。当敏捷对于一个组织或是团队的新成员来说是一个相对来说比较新的概念时，这句话尤其地正确。

敏捷方法可以清楚地帮助处理由来已久的IT关注点：缺乏团队效能，螺旋形上升的开发时间和开销，以及适应变化的困难。然而，这显然不是一个银色子弹：我看过大量的敏捷开发团队不能完全履行任务，下面的五条是我遇到过最普遍的原因。

敏捷的阻力

一个解决祸患的百发百中的秘诀是不断向一个不可信服的团队灌输敏捷过程。许多大的组织仅仅雇佣一个敏捷教练，训练使用Scrum或者其他方法的团队，希望所有团队都会变好。但是习惯对于个人来说是最难戒的毒药。说起对于敏捷的抵抗，Mountain Goat所说的正中要害：

许多团队可能会抵抗敏捷，因为他们对现在的工作和同事感到很舒适。另外的团队可能因为真的不喜欢或不相信Scrum 方法而抵抗敏捷。他们可能相信反复开发复杂的产品而不做重要的事先设计会导致事故。

真实的故事：我工作过的一个产品团队用扑克牌来决定处理积压的工作的优先权。但是经理所说的任何话仍然是板上钉钉的，击败了我们做团队决定所付出的努力。尽管经理、开发者和测试员都知道过程背后的理论，遵从的习惯太难被改变动摇。领导不想失去他们的影响力，所以选择不追随开发过程中的许多关键部分。

这意味着虽然我们名义上是遵守“敏捷”过程的，我们的行动还是固守于一些以前的思考方法。这种工作方法让领导和许多团队成员都感到很舒适。不用说，这个团队没有从敏捷过程中得到任何的好处。

如何克服它：为了使用敏捷方面取得成功，记录谁失败了谁获得了能力是非常重要的。你必须保证整个团队都能从这个过程中获益。这需要说服所有的利益相关者，证明并且列出从过程中可以获得的清楚的好处，听取所有的反馈，在极端的例子中，把顽固的反对者分开，减低他们对团队活力产生负影响的能力。

无法应对不断变化的优先级

大多数的Scrum管理员和产品经理都承受着大项目，小团队的压力。由于没有任何可能偏离于sprint，所以任何没有预想到的需求都会造成严重的问题。万一你有有限的资源，不能为这个项目加更多的人，任何迫切的需求都可以强迫你离开原先预计的轨道。

对太多的团队来说，接收新的需求的同时还按照原先的计划执行几乎是不可能完成的任务。因此，团队在不停的迭代规划过程中，许多次失败于持续交付所承诺的成果。

当然，你可以因为考虑sprint中期的优先权而拒绝临时的需求。但这不是每次都可取的方法。在这种情况下，你可能必须要从现有的sprint中去除一些需求，之后新的需求才能添加进来。在其他情况下，你会被强制取消sprint并着眼于急迫的需求。

真实的故事：我几年前做的一个项目，客户想要一个简约的登录注册表单，然后他们的顾客可以简单地通过他们的email登录注册。团队创造了一个表单设计，也得到了认可。此后，在下一个sprint中，后台开发完成后，客户决定在表单中添加一些参数，以从用户那里获取更多数据。

这阻碍了工作的发展。Scrum管理员迅速地重新安排了资源，改变了sprint的优先权，关注于首先持续交付设计，让设计获得认可，再用剩余的实际来完成后台开发。由于需要改变的部分相对来说比较简单，优先级的改变并没有很坏地影响进程的发展。但是那些会影响接下来的sprints重大改变会很难处理。

如何克服它：最好的避免这种情况发生的方法是请一位受过训练且有经验的Scrum管理员来指挥团队的进展，他可以设想预测未来的需求，有效地把事情按照优先权排好，并为产品工程创造最优的计划。

同时，各种不同的编程实践的知识，还有一些可以使用于解决具体问题的经验也会帮助应对没有预想到的问题。这是向一个经验老道的敏捷教练请教时可以获得的巨大的帮助。Scrum管理员拥有的经验越多，越容易解决因为改变优先权所引发的问题。

处理不了的缺陷积压

Agile关注于不停地持续交付和开发，这迫使团队快速进展，持续交付通常优先考虑质量问题。发现许多错误和缺陷堆积起来形成一个巨大的、令人生畏的积压非常常见。随着时间的推移，团队工作的一个非常巨大的组成部分就是处理积压问题，导致只有非常少的时间和精力可以致力于新的设计或是开发。

太多的团队，特别是新接触敏捷的团队，最终会处于一个站不住脚的位置，因为他们团队整个开发过程的很大部分都在处理积压问题。在最差的情况下，开发软件的过程就像你在开车时手刹拉着的情况。

真实的故事：我们的一个团队曾经做一个有清楚需求的明确的项目。然而，当客户把这个产品的某些部分推广至更大的用户群时，完全想不到的初始功能的概念性缺陷被发现，这严重破坏了正在进行的sprints。

产品经理迅速调整了分配于缺陷清理的时间比例，并改变了管理，重视了客户想法改变的频率、团队的速度和我们的质量基准。通过分配20%的时间给缺陷积压，为一些sprints增加额外的资源，以及运用结对编程的方法来加速进程，我们最终度过难关，防止事态失控发展。

如何克服它：没有一个简单的答案——团队只需要产生较少的缺陷，并很好地解决它们。为了实践的目的，将开发过程中10-15%的工作（或是适合你的项目的比例），用于解决测试过程中发现的错误，这是一个很好的可以防止积压变得很多的方法。

一个熟练的，可以迅速优先缺陷处理，使用正确的Extreme Programming和Test Driven Development方法的Scrum管理员在项目的成功完成中起到了关键性的作用。

延迟于构造MVP

当运用MVP模式工作的时候，许多敏捷团队都以平行地执行UI设计和后台活动告终，而并没有建立这两者之间的桥梁。我们不妨假设产品开发预计需要9个月。在这种情况下，大概需要4个月平行开发UI和后端（并没有建立两者之间的桥梁）。在这种场景下，首次查看统一的产品造成的更改会有深远的影响，这通常会导致大规模的修改。

真实的故事：我曾经工作的一个团队负责开发一款移动端以及网络端的应用，开发过程从屏幕设计开始。一旦PSDs 或JPEGs被批准，中间层、数据库和商业逻辑元素也得到了解决。然而，由于应用程序的交互仅在设计被批准后才可以看到，客户经常返回修改设计，使得整个开发过程紊乱。

Scrum管理员可以通过将所有的交互放在一起来简化整个开发过程，并让整个开发过程合理。因此，设计、开发和每个过程的交互都串行建立，向客户提供一个工作模块或功能。这可以让客户从一开始就获得一个清晰的图像，因此可以减少紧要关头的改变的数量。

如何克服它：只有当开发过程中的所有部分，包括设计、JPGs、HTML、代码、中间层和数据库都连接在一起的时候，才能使产品拥有一个对于真实可用的产品的清晰视图。团队可以在每个sprint递交一个功能性的、交互性的产品。这个产品层层建立，每次迭代过程都给产品拥有者一个更清晰的视图。这可以帮助及时递交MVP，减少开发最后阶段的重要改变。

缺乏敏捷教育，交流的缺口

当产品拥有者不能经常与大型团队进行沟通时，或者当他/她不理解敏捷过程时，往往会出现问题。

真实的故事：例如，我曾经工作的一个团队遇到了一些延迟，仅仅因为产品拥有者不能每周在sprints提供及时的输入。

在另外一个项目中，没有单独的产品拥有者。这个角色被分成了一个技术领导和一个功能领导，他们有不同的优先权和不同的观点。这两个领导不参与日常团队工作中，他们经常提出互相矛盾的需求。这对于优先化产生了很大的问题，使得开发者很难处理。

如何克服它：虽然做决定和从整个团队以及利益相关者那里输入很重要，让问题可以止步也同等重要。对于产品有清晰广泛的视野的个体，和一个可以做最终决定的人，在大多数情况下都非常需要，他们可以在开发时避免分散的方法。

与此同时，教育产品拥有者和管理人员敏捷过程的工作方式，以及他们在成功开发中必须扮演的角色是非常重要的。为了这个目的，雇佣一个有经验的敏捷教练会是一个有益的决定。

总结

当然，如果你想从任何的敏捷过程中获利，会有许多其他的障碍需要你去克服。但是以上的这些是最普遍的和可避免的错误，这些错误仍然困扰着许多团队，仅仅因为组织不能改变他们的习惯和思考过程。

对于敏捷你经常抱怨的问题是什么？什么正在妨碍你的软件产品开发过程的敏捷性？请在评论中与我们分享你的见解和经验。

关于作者

Bhoomi Mehta是一位IT专业人员，她在Cygnet Infotech公司任职，拥有被证实的跨职能专业技能，包括咨询、运营、市场营销和应用程序投资管理。她将精力运用在激励敏捷精益团队在各自的功能中发挥最佳水准。她这些年在各个方面身兼数职，包括咨询、指导、训练、团队管理、质量保证以及市场营销。Bhoomi的动力来源于使能够建立精益的、自立的、热情的和有效的团队。她所有努力的基础上是一个清晰的理念：“团队不是好的或者是坏的来判断的。一个项目或是任务的成功结果与指导、工具和相信你自己可以成功完成直接成正比的。”

查看英文原文：When your ‘Agile’ Team Moves at Snail Pace: 5 Key Roadblocks and How to Overcome Them