敏捷出错时

Question

我正在为我们最近加入的一些新人编写敏捷课程，我想增加一个警示性的故事，这样他们就会明白敏捷并不是所有项目的目标。

我的问题是，由于我与敏捷一起工作的项目的性质，到目前为止，我不能诚实地指出什么会出错，以及当您在错误的项目中使用它的原因。

当敏捷项目出错时，需要注意的事情是什么？

Answer 1

“敏捷”团队最大的失败是所谓的货物运输。从本质上讲，团队需要成功的敏捷团队的影响，因此他们模仿visibile的行为。

• 每天的停顿(持续一个小时左右)
• 将工作分解为冲刺
• 用户故事(通常只是一个句子，但估计值)

在这些环境中，您将始终看到这三个方面的“应用”，但对于真正的敏捷几乎没有什么承诺。事实上，你会听到管理层说我们在“做敏捷”。(听了这两个字就跑掉了，这是个坏兆头。)

你也会听到很多关于技术债务的说法，但是他们对技术债务的定义是“快速而肮脏地做，也许我们以后会做得更好。”(翻译:我们会使它听起来像我们关心的可维护性，但在现实中，我们将保持同样的锅炉房心态，因为这是我们在过去的工作)。

其他关键短语：“我知道这些故事并没有被完全定义，但我们正在进行敏捷，所以我们可以在我们开始的时候修复它们。”

“我们正在进行敏捷开发，因此您应该能够在我识别出来的sprint中容纳我所需要的东西。”

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

敏捷项目是否成功的关键指标是项目负责人(scrum master或其他角色)是否有过领导敏捷项目的经验或正式培训。我经常看到人们在一本书中读到关于敏捷的内容，或者参加为期两天的关于成为scrum大师的课程，并认为他们已经掌握了成功实现敏捷的方法。很抱歉没发生船长。

Answer 2

不了解敏捷是什么的人(是吗？)并将其应用于：

• 客户在截止日期前不能发表评论， ...and威胁事后采取法律行动；
• 让开发人员远离客户的管理人员(可能是因为他们的薪水略低，可能会跳槽，为所谓的客户工作)，在一次让开发人员看起来忙碌和有用的绝望(通常是成功的)尝试中玩一场"断电话“游戏，也可以参见：蘑菇管理，也就是”保持晦涩的，被喂饱的粪肥“和头尖的老板。:)
• 球队太大了，不能去任何地方；
• 那些一直在发薪的公司，曾经是著名的系统架构设计师，通过过度设计华丽、不切实际、难以实现的UML sagrada家族，把人们的注意力从他们完全忽略了实际编码技术的事实中转移开。

Answer 3

敏捷不适用于固定期限或固定价格的合同.一旦你注册了这样的野兽，你就得去送货。敏捷非常擅长于永远地持续开发，因为客户改变了他们的想法并“澄清”了他们的需求。在钱用完的那一天，这对你没有帮助，但仍然必须完成这项工作。

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

敏捷失败的另一个方面并不是敏捷的错误，它是那些坚持完整项目文档、前期设计和糟糕的沟通方式等老东西的人的错。( 半精练敏捷宣言)。