近年来，来自市场的压力越来越大。客户要求灵活的交付方法。我之前的第12篇敏捷原则清单是关于真正的敏捷项目是什么样子的。不幸的是，并不是所有声称敏捷的人都是真正的敏捷。让我们看看一些巨大的警告标志，这些标志表明这个敏捷过程可能并不那么敏捷。
"大爆炸"交付
在项目结束之前，团队无法交付任何用户价值的产品增量。
敏捷项目在第一次迭代结束时交付小的增量。然后他们在整个项目中继续以这种方式进行。
他们控制变更
他们有一个正式的变更管理流程。
敏捷团队使用产品Backlog列出所有可能考虑开发的特性。产品负责人负责确定特性的优先级。在迭代计划会议期间，超算云，他与团队就迭代期间可以交付的内容达成协议。在整个项目期间，项目都会添加到backlog中。这个产品积压是一个活的文件，什么是软件企业，可以随时更改，直到项目结束。没有正式的流程来进行这些更改，也没有与之相关的额外成本。
一次发布
敏捷交付方法，就像业务中的一切一样，必须带来业务价值。如果团队声称自己是敏捷的，但无法将产品增量运送到生产中，那么它就不会给客户带来很多价值。
他们有独立的团队。
他们指的是他们的分析师、开发人员和测试人员团队。
敏捷团队在跨职能的环境中工作，团队成员拥有不同的专业领域。您将遇到分析师、程序员、设计师和测试人员每天密切合作。团队的组成不是基于他们的技能，而是基于他们所从事的用户价值特性。
决策由项目经理做出
项目经理做出决策并将任务分配给团队成员。
敏捷团队是自组织的，他们自己解决问题。他们得到了必要的支持，但不接受命令，也没有被他们的经理分配任务。
很多文档
有很多文档和签准，特别是在阶段结束时。
敏捷团队专注于面对面的沟通和讨论。他们利用捕获需求的用户故事格式来实现这个目标。它们在发展过程中没有阶段或顺序。一切都发生在迭代中。通过这种方式，交接很小，几乎没有明显的变化。
他们衡量活动的进度
他们告诉你，他们完成了20%的分析。
敏捷团队根据交付的特性来衡量进度。任何未完成且未被产品负责人接受的成品都不予考虑。任何对最终用户没有价值的东西都不被认为是进步。
放松的开始，大数据都学什么，紧张的结束。
他们在项目开始时放松，在项目结束时加强工作。
敏捷团队的目标是可持续的步伐。他们在每一次迭代中都是一致的，以交付高质量的产品。
交付所有的东西。
他们做前期分析，签核文档，大数据能做什么，然后交付里面指定的所有东西。
敏捷团队不进行大量的前期分析。它们处理以用户故事格式捕获的需求，并以迭代和增量的方式交付。产品负责人正在改变整个项目的优先级，以确保只开发最高优先级的项目。敏捷团队从不按预先计划的顺序工作，一切都是基于优先级的。
团队层次结构
他们有团队领导、测试领导或开发领导。
敏捷团队结构扁平，没有人分配任务。每个团队成员都是平等的，需要合作。
没有调整，没有行为改变。
即使有要求，团队也不会改变其过程或行为。
敏捷团队在每次迭代结束时使用定期回顾。他们反思自己的行为，如何做淘客，并为下一次迭代提交特定的更改以解决这些问题。
