敏捷开发失败的五个原因以及解决方案

敏捷开发是一个可以改变软件交付方式的框架且效果十分惊人，但鉴于需要反复不断规划、测试、集成以及其他进行中的开发方式，敏捷开发在某些情况下行不通。下文将对常见的敏捷开发失灵以及相应的解决方案展开讲解。

敏捷开发是一种迭代型软件交付方式

敏捷开发的目标是根据反馈来逐步构建和交付软件，而不是一次性交付整个解决方案。标准软件开发生命周期（SDLC）和瀑布式开发等传统开发方法已经无法快速、高效地交付解决方案。耗费数年完成的瀑布式开发项目在结束时所交付的解决方案，也未必能完全满足当下的用户需求。每个IT部门和软件开发公司都会遇到这个问题，这就是为什么在需要灵活性的项目中，敏捷软件开发正在成为新趋势。

敏捷开发包含四种主要角色：产品负责人、敏捷教练（ScrumMaster）、开发人员和终端用户或业务团队。

• 产品负责人的作用是推动解决方案愿景的实现，他们需要知道建立哪些核心流程。
• 敏捷教练的作用是排除开发团队所遇到的障碍，并通过各种可能的方式提供协助。
• 开发团队包括软件工程师、质保团队和任何其他参与解决方案构建的人员。
• 终端用户是使用最终敏捷应用的人。

敏捷开发失败的五个原因

根据我与医疗保健、金融、教育、政府等垂直行业公司的合作经验，每家公司都对敏捷开发有着不同的理解。虽然每家公司都会根据自己特有的用户群体来自定义流程，但他们总会犯一些常见的错误。以下是进行敏捷开发时的五大常见错误以及我的避免方法建议。

• 缺乏信任

缺乏信任会扼杀团队项目，对工作环境会产生巨大的不良影响。由于涉及到大量机动的任务和人员，再加上每1-2周就要交付新功能的压力，在敏捷开发流程中必然会出现沟通不畅的情况。

因此，保持开发过程中的透明性十分重要。也就是说，所承诺的最后期限和交付内容必须合理，让每个人都感到他们在为一个共同的目标而努力。

• 沟通不畅和任务分配不合理

敏捷教练需要为团队服务，包括排除开发团队可能遇到的障碍、为产品负责人和其他相关方提供建议与辅导，以及防止开发团队受到其他因素的干扰。

在一些项目中，我见过试图支配团队工作的敏捷教练，他们事无巨细地管理所有活动。这种领导方式不仅损害了团队的士气、表现出不信任，而且还妨碍团队实现目标。我也见过相反的情况，也就是敏捷教练对工作不闻不问，可能只参加会议，对团队的工作毫无头绪，甚至一无所知。

敏捷教练应该平易近人、能够快速地意识到问题并及时解决。他们应该了解正在构建的技术并尽自己所能提供帮助。下图展示了敏捷教练应该如何工作：

图1 敏捷教练对于管理互动和团队来说至关重要。

• 范围蔓延和领导不力

产品负责人需要具备相关领域的专业知识、了解技术和业务需求并制定产品愿景，其作用是对用户反馈进行把关、提供明确的指导并管理期望。该角色需要与终端用户和开发团队互动交流，指导大家开发出所需要的业务解决方案。

图2  理想的产品负责人

在我最初接触的一个项目中，客户需要在2-3周内投产，并在用户验收阶段帮助修复bug。我们迅速解决了出现的bug，但发现很多用户的实际反馈是对功能的请求。用户在投产最后期限前的2-3周提交功能要求并希望都能够得到满足。产品负责人没能管理终端用户的期望，也没有明确功能与bug的区别，只是将信息传递给开发团队，并指望他们搞定一切，该项目的最后期限自然越拖越长。

产品负责人必须理解业务目标并推动项目愿景的实现，同时还需要保持坚定并明确管理用户的期望。否则就连项目的第一阶段都有可能永远无法完成，这就是范围蔓延所带来的影响。

• 项目过度复杂

一个项目越复杂，花费的时间就越长，出现的问题也就越多。在处理复杂的需求时，开发团队和敏捷教练应尽可能一起规划和设计解决方案，将复杂的需求分解成更小的需求并逐渐进行迭代。

如果团队遇到任何障碍，或者敏捷教练注意到任何可能在将来成为障碍的问题，应该提前提出并制定解决方案。我们必须清楚在迭代过程中，对应用作出的每一个改变都是有成本的。

• 使用错误的工具

有些工具专为敏捷交付而生，比如西门子低代码，相当于有了所有用于敏捷迭代规划和项目交付的工具。团队开发服务器能够处理所有用户故事和迭代。下图就是一个用户故事和迭代开发的示例。

图3 当前迭代用户故事截图

图4 用户故事的流程和燃尽图

敏捷开发是整个团队的事情

总之，如果团队存在信任、有“理想的”敏捷教练和产品负责人愿意共同努力解决问题，而且能够组合式使用正确的工具和方法来简化流程，那么敏捷开发就会非常有效。每家公司的情况不同，都有自己的文化和IT架构。公司内部和团队成员之间的信任以及必要时的培训与支持，对于项目的成功至关重要。