您需要什么才能成功实现敏捷？

在某些组织中，采用敏捷可能会失败，我什至在一家公司（瀑布式）是唯一（真正）方法的工作，但这仅仅是因为他们在项目上尝试了敏捷并失败了。

当我问那些仍然记得（我还是大三）的人时，我很难过，就像我提醒他们一场噩梦一样，这确实发生了。

我不知道为什么项目失败了。网上可以找到一些资源，为什么有些公司会导致Agile失败，但原因主要是经济上的。所以我想在此先提出一些反馈。

在某些组织中，敏捷采用失败的原因是什么？或者，另一种表达方式。.要使敏捷成功，您需要做什么？

您需要管理层，客户和开发人员各自来理解和支持敏捷思维方式和敏捷方法。更详细地：

• 管理层必须对事实真相感到满意，而不是传统上希望听到的事实（即“是的，项目按计划进行”了11个月……然后突然“糟糕了，我们需要将截止日期延迟几周） ……嗯，几个月……嗯……”。他们还必须让每一方都做（并为自己的工作承担责任）。最突出的是，开发人员应做出技术决策和估算。因此没有严格的控制和微观管理。
• 客户必须了解，敏捷需要他们在开发过程中不断深入的参与，而不仅仅是“下订单”，然后在几个月后提货。他们还必须感到满意，因为他们没有大的固定需求规范，而且开发团队显然没有做出交付最初要求的承诺。
• 开发人员必须对承担责任，做出决定，公开交流和团队合作感到满意。即没有“代码所有权”，没有“孤独的牛仔”，也没有为团队本身可以解决的问题而责怪他人。

以我的经验，这是失败的敏捷项目背后最常见的第一点，但其他两个方面也会引起问题。

更新资料

“管理”不仅指直接的项目经理，还指更高的级别。正如@Michael非常正确地指出的那样，或多或少的外部参与者（例如QA或外部任务分配器）也可能影响敏捷项目的成功/失败，但我想只有在各自领导允许的情况下，这才有可能或者组织内部的职责和指挥范围不清楚。

你需要：

• 愿意开放诚实的人。可见性就是一切，因为您需要跨各种层边界的信任。
• 真正想听到真相的客户和经理。
• 愿意并且能够重新定义角色以适应当前需求的人们。
• 自由改变不能工作流程现在。
• 愿意承认错误并扭转错误的人。
• 的能力，以构建和测试环境拼凑随意。（这比人们给予的认可更重要，更昂贵。）
• 您可以使用尽可能多的白板填充墙壁。

看起来很简单，但是其中很多都是这个行业的大要求。

当关键人物拒绝敏捷时，或者（更糟的）当某人对项目的成功不诚实或完全破坏成功时，敏捷项目通常会失败。后者可以杀死任何项目（就像许多其他事情一样），但是敏捷过程使人们拥有更大的灵活性，其中包括进行破坏性政治活动的灵活性。

例子：

• 质量检查人员坚持认为，除非经过一个月的手动测试周期，否则客户无法看到该软件
• 管理层强加了不切实际的期限
• 客户拒绝优先处理需求（“它们都具有最高优先级！”）
• 并非直接的利益相关者但具有政治影响力的人不断为冗长的无关任务分配给关键团队成员，而项目经理无法阻止这一点。

我只能根据自己的亲身经历给出建议。

我在敏捷开发方面完全失败的一位雇主。工作是临时完成的，不存在测试，要求已记录在电子邮件和会议记录中。使用的唯一开发方法是无政府状态，即“即发即忘”编码。由于开发人员过于劳累而无法建立某种故事跟踪项目管理软件，因此实施某种软件工程方法将是不可能的。

在另一位雇主处，我们的团队有一位英勇的成员，他拼命试图建立一些敏捷最佳实践-我们拥有看板委员会，问题跟踪，我们使用了TDD和BDD（虽然本身不​​是敏捷的，但它们往往出现在敏捷团队中） 。不幸的是，我们缺少诸如故事要点，估算会议，能力计划，燃尽图，速度图之类的东西，而这些东西却是使工作顺利进行的有用的敏捷项目管理内容。作为敏捷出现错误的典型症状，当我们的看板太满时，我们买了一个更大的板：/

我目前所处的位置将故事点用作规划能力的一种方式，其中包括两周的迭代，TDD，每日站立，逐迭代迭代的时间框回顾和对大多数事物的配对编程。这是总体管理支持和客户培训的结果。

它认为，要使敏捷在公司中取得成功，您需要满足以下条件：

• 了解敏捷并且将适当使用工具的项目经理。
• 懂得敏捷的开发人员，他们坦诚诚实，并遵循敏捷要求
• 从客户那里买进。他们需要认识到敏捷的好处，并愿意听取开发人员的建议，以了解在给定时间内可以开发的内容。

编辑：确保您对-为何-日常站立和短暂迭代之类的事情很有用也很重要。

我对敏捷失败的经验与经济学无关，而与公司/部门/个人政治相关。

就个人而言，只有一些人的性格会发生冲突。迫使他们加入敏捷团队，甚至更糟的是配对的编程团队，将会使他们对彼此的不满上升到沸点。这会变得非常讨厌，非常迅速，并导致诸如破坏活动之类的事情值得进行真人秀，从而将会议集会变成循环责备甚至更糟糕的循环。

除此之外，还有开发管理。我已经看到这有两种不同的用法。

首先是“货运邪教”，管理者坚持遵循宣言以及他们准确阅读的任何班级/书籍/网站，却不了解为什么以及何时使用它们以及何时即兴创作的原因。就像敏捷管理者正在等待魔法发生一样，因为他们正在完全遵循该咒语。这种敏捷的敏捷实施可能导致许多问题，这些问题将导致项目失败。

另一个是“仅以名字命名的敏捷”，其中使用了诸如sprint和scrum之类的术语，但实际上只是诸如微观管理，在命令链上上下下的不诚实行为，冗长的无用状态会议等其他老标签的标签。 。项目像以前一样失败了，但是现在可以将其归咎于敏捷，而不是管理不善。

除此之外，该项目的客户/客户也缺乏购买力。这些人将有自己部门的优先事项，并且会拒绝与开发团队合作，除非管理层明确表明这是他们工作的重要组成部分。部门政治或公司政策会使情况变得更糟。例如，运营和市场营销都已投入到一个项目中，由于双方无法就任何事情达成共识，因此您的团队最终无法自拔。另一个例子是，公司的时间管理和计费政策引起冲突。实际上，我发现外部客户比内部客户更容易处理。他们喜欢从过程中获得的关注，并且知道自己正在获得金钱的价值。

如果没有大规模认可这些做法，则IMO“敏捷”失败。我的意思是，敏捷依赖于“客户”（通常是另一个部门或经理）理解：

1. 即使他们认为自己愿意，他们也不知道100％他们想要软件做什么
2. 他们不知道要花多长时间，即使他们认为自己做了
3. 他们将被告知需要多长时间，并且必须接受它或减少功能以满足最后期限
4. 他们将不得不在每次迭代中选择功能，并且一次也无法获得完整，100％完整的应用程序。

所有这些对于大多数管理人员来说都是非常困难的事情，而IMO是很难做到敏捷的第一原因-经理习惯于说“它将在x日期之前完成”，并在“日期之前”完成它（在开发人员投入了80小时的工作时间之后），要意识到开发团队将告诉您该项目将在3个月内完成，则需要180岁，您唯一的选择就是接受该项目或降低获得该项目的要求它做得更快。

其次，必须信任开发团队。与上面的＃1并驾齐驱，几乎没有经理真正相信被聘用为专家的人的观点；如果开发人员说一个项目将花费x的时间，并且x比管理层认为的要多，则绝不会出现“我不知道如何编写软件，所以开发人员可能是对的”，这是更多的情况。那些毫无用处的开发人员想在工作中变得愚蠢，所以他们说这将需要3个月的时间。”

第三，您的开发团队需要支持敏捷。这意味着不要偷工减料，也不要忽略不断的反馈和“这是正确的吗？当x发生时Y应该怎么做？”的问题。即使您不遵循TDD或结对编程，您的开发团队也需要具备足够的能力来遵循敏捷过程（例如sprint，迭代）。这涉及到有一位负责人/经理，他可以适当地估计任务，并了解您不需要将每个功能都放在优先位置，可以积压工作，也不要过度劳累人员。