敏捷软件开发最常见的风险是什么？

任务技术项目的最大风险都是扩大用户的需求。功能蔓延，也称作需求渐变，在大部分项目中都很常见，无论是方法论还是域，而且任何时间我都没有看到这一问题消失。

软件项目需求渐变会导致几个结果：项目超出预算、交付延迟或取消。有记得最近有一个软件项目，它的团队购买了最强有力的敏捷工具，实现了SOA。这看起来似乎他们做所有他们应该做的，就如同父母教育子女和烘烤苹果派一样，但实际他们并没有。

产品经理有一个愿景就是他们从示测试过市场。如果他和他的团队真的在做“敏捷”，那么他们将会事先做一个模型，在发布给用户之前进行测试，并在开发计划的关一个用中进行。相反，如果项目超出预算，就必须取消。恢复他们的成本大约500万美元。

有时，我们会陷入这样的软件开发团队中，这个团队已经工作了一段时间，但在项目的进行时，他们不会停下时行评估。几年前，我帮助了一个软件和服务公司做一些产品路线图。不幸地，该公司两年中都没有更新计划，而世界和他们的竞争对手却在改变。他们不能清晰地看到项目的真正价值在哪里、不了解愿景是什么，不知道利益相关者必须获得什么。即使是成熟的团队也会掉入这个陷阱中。他们还会停下来进行评估，然后在再全力追赶。

重要的是不要混淆需求渐变和故意而为的技术债务。在敏捷项目中，有些团队可能会故意引发债务，因为向市场交付胜过这一解决方案的质量和完整性。开发人员必须把事情做完，因为他们竞争对手有的一些功能，是他们的产品欠缺的。

也就是说，开发人员必须对于需求渐变有计划，即使他们故意引发技术债务。有了策略，如改进日程，那么团队就可以向着实事求是且相关的目标前进了。敏捷开发是一种平衡的行为，需要用户代言人或产品经理使用Scrum来管理。产品经理需要在团队(这一团队中包括用户和业务人员)中建立信任，并诚实对待已经发布产品的错误和不足，花点时间清理债务。尽管如此，如果在清理时做了太多的迭代的话，该项目就会留下一种气味，这意味着技术实践（如测试和持续集成）就会被忽略。

在敏捷中团队合作很重要。还记得我前面提到的500万美元的损失吧。这是一种产品管理团队把技术债务拖欠太多的情况。他们把这一实践传到了技术组织中，把技术人员变成了办公室人员。在这一案例中，我们为所有参与都订制了一个工作间，这些人包括CIO、产品主管、技术团队领导和用户。我们向他们展示了路线图，阐述了背后的工作原理。我们讨论了所有工作，所有我们帮助他们完成产品愿景和主题的工作。我们定义了项目中的关键角色。后来产品经理说，“我们以前从来没有这样工作过。”我们只是微笑着。这正是他们需要意识到。敏捷需要整个团队参与，并且对待团队成员就像合作都一样。这是摆脱功能划算的第一步。