敏捷出问题时[关闭]

我正在为最近刚入职的一些新手编写敏捷课程，并且我想补充一个警告性的故事，以便他们理解敏捷并不适用于所有项目。

我的问题是，由于到目前为止与我合作的项目的性质一直很好，所以我不能坦诚地说出可能出问题的原因以及在错误类型的项目中使用它的原因。

敏捷项目出错时要注意什么？

“敏捷”团队最大的失败是所谓的货运培训的结果。本质上，团队希望获得成功的敏捷团队的影响，以便他们模仿可见的行为

• 每日站立（持续一个小时左右）
• 将工作分成冲刺
• 用户故事（通常只不过是一个句子，但可以预计）

这是您在这些环境中始终看到的“三个”应用，但几乎没有致力于实际敏捷。实际上，您会听到管理层说我们正在“敏捷”。（逃避这两个词是一个不好的信号。）

您还会听到很多关于技术债务的信息，但是他们对技术债务的定义是“快速而肮脏，也许我们稍后会努力改善它”。（翻译：听起来好像我们在乎可维护性，但实际上我们会保持相同的锅炉房心态，因为过去这就是我们的工作）。

其他关键短语：“我知道这些故事还没有完全定义，但是我们正在做敏捷的事情，因此我们可以随时修复它们。”

“我们正在进行敏捷开发，因此您应该能够在我确定的冲刺中适应我的需求。”

“我们无法在冲刺开始时就锁定我们的承诺故事，因为需求在冲刺中不断变化。”

敏捷项目是否成功的关键指标是项目负责人（Scrum主管或任何角色）是否具有领导敏捷项目的经验或正式培训。我经常看到人们在一本书中读到有关敏捷的知识，或者参加为期2天的课程，成为一名Scrum管理员，并认为他们掌握了成功实现敏捷的能力。对不起，这不是机长。

根本不了解敏捷是什么的人们并将其应用于以下方面：

• 在截止日期之前无法发表评论的客户
  ... 随后威胁要采取法律行动；

• 经理，使开发人员远离客户（可能是因为他们的薪水略低，并且可能会跳船，去为所述客户工作）并拼命（尽管通常是成功的）尝试玩“ 电话断了”的游戏看起来忙碌而有用

  另请参阅：蘑菇管理， 又名“保持晦涩，饲喂粪便”和尖头的老板。:)

• 太大而无法前往任何地方的团队；

• 那些一直保持薪资水平的著名系统架构设计师，他们通过过度设计宏伟，不切实际，难以实现的UML 圣家族教堂，彻底转移了对他们完全看不见实际编码技巧的关注。

敏捷不适用于固定期限或固定价格合同。一旦注册了这样的野兽，就必须交付。当客户改变主意并“阐明”他们的需求时，敏捷非常擅长永续发展。这对钱用光的那天没有帮助，但仍然必须完成工作。

但是，当您进行增量更新和错误修复时，敏捷对于项目后阶段非常有用。

敏捷失败的另一个方面并不是敏捷的错，这是人们坚持所有旧事物（如完整的项目文档，前期设计和沟通不畅）的错。（半激的敏捷宣言）。

下面的一些问题可能有助于寻找答案，以寻找敏捷尝试可能失败的示例：

• 敏捷是新的微观管理吗？
• 敏捷过程：应如何记录以及记录什么？
• 新项目的规划和编程的正确组合

您听说过“伪敏捷”吗？这是关于它的几个博客条目：

• 从伪敏捷到瀑布–一家小型和新软件公司的道路
• 伪敏捷！

对于可能会采取自己的看法的公司来说，可以说些什么，然后将其屠杀成其他事物。

我曾在一个非常成功的敏捷团队中工作，还有一些尝试敏捷的人，但未能成功。

成功者具有以下要素：

• 真正做到“敏捷”的要求。有用户故事，我们从中编写了代码。
• 可用的产品负责人。如果我编写的用户故事不完整，我可以轻松地联系产品负责人，询问他应该在哪里，添加它，然后完成代码。
• 致力于这个过程，并意识到这是一个学习曲线。
• 专注的团队。
• 经理们了解并理解敏捷的工作方式，并致力于使其工作。

成功的团队表现出色，并且表现出色。我认为，如果您没有以上几点，那么您很容易失败。第一和第二件事是相辅相成的，如果您没有这些，那么敏捷将无法工作。

我所在的团队在敏捷方面做得不好，也有一些要素：

• 管理层缺乏承诺。管理层不相信这种哲学，结果犹豫不决。
• 需求记录在用户故事以外的其他地方。有关管理承诺，请参见上文。同样，我们有高薪的需求分析人员和昂贵的昂贵需求工具，有人需要证明其使用的合理性。

我将在已经发布的出色答案中补充说，以我的经验，敏捷，特别是Scrum仅在管理人员和团队愿意对正在发生的事情具有高度可见性时才起作用。

这意味着在上市公司（例如政府）中，很难使其正常运行。

我认为敏捷就是实践团队的文化。如果文化糟透了，团队成员就不会相处，并且人们没有合作来满足冲刺承诺，那么文化或团队就会缺乏。

但是，我不一定要说Waterfall将在这样的环境中工作，这不是黑白情况，很少是真正的黑白。

一个好的敏捷团队是共同的。他们具有部落的社区精神，所有成员都朝着相同的目标努力。团队一起成功或失败。他们共同致力于解决问题。团队成员将停止执行任务以帮助陷入困境的团队成员。一切都沉没或游泳。

如果不是这种情况，那么很快就会发现问题出在哪里。如果团队成员坐下来，在笔记本电脑上打字，发短信或在日常站立时进行分区，那么您就没有一支优秀的敏捷团队。如果您的项目经理正在执行所有Scrum程序，定义和术语，但每个人都只是保持脚踏实地，并口口相传，那么这只是敏捷的真实表现，这在许多方面会导致团队失灵，效率低下。 ，错过了截止日期和项目失败。

失败的敏捷在许多方面要比中等水平的Waterfall团队更糟糕，并且项目成功率可能更低。

我从个人经验中不知道这一点，但是假设在很多情况下，敏捷不是最佳选择。

• 产品对生命或财产至关重要的项目-例如，您不想使用敏捷来开发运行起搏器的软件。为什么？因为您对错误的容忍度几乎为零。考虑有关Therac 25的医学编程错误的经典示例。当然，它并不是敏捷构建的，但重点是：开发生命或财产至关重要的地方无处说“我们将在下一个冲刺阶段清理它”或“我们不需要伟大，只需要良好”就可以了。足够。”

• 初级开发人员过多的项目-敏捷期望参与团队具有一定的自治权。如果团队中没有足够的经验，那么这种自主权会对您不利。

• 与传统上敏捷提供的项目相比，需要更高程度的控制或规划的项目。

我假设其他任何人都可以加入进来并提供更好的示例帮助，或者反对我所写的这部分牛肚;-)。

请记住，当您仅有的工具是锤子时，每个问题都像钉子。并非所有项目都是钉子。