敏捷方法的适用性和不适合性？

Question

每个人都在谈论敏捷以及这有多好。敏捷有几个优点和缺点。我从理论上研究了它们。由于这里有专家在许多项目中工作过，我想知道真正的两个两个场景，其中敏捷是不合适和适合的。感谢

Answer 1

在以下情况下，

敏捷可能不适合

• 它有可能暴露出过度繁荣的管理层（某些职位突然变得非常过分）
• 人们实际上并不想玩得开心，做出创造性的事情，从而摆脱了平凡的工作模式（维护传统的蹩脚软件，等不及要处理）
• 政治而不是专业主义经营公司
• 人力资源管理公司（敏捷是关于人类，人力资源将它们视为事物）
• 客户希望你能弄清楚他需要什么（敏捷会让你问他不想回答的问题）
• 敏捷应该是一个魔杖，可以在没有人改变习惯的情况下解决问题（另一个流行语，时尚）
• 开发分布在远离彼此的多个位置，在不同的时区（通信受到影响）
• 你有一个尖头发的老板;）

或一般情况下：

• 被误解了
• 组织被严重虐待
• 没有人真正想要它

Answer 2

如果能够很好地做好敏捷，那么我相信这总是一件好事。如果不能做得好，那么我相信它可能是有害的。并不是因为敏捷有任何本质上的危险，而是因为它意味着使用功能失调的过程。

因此，当没有良好的条件时，敏捷是不合适的。

有些事情可能会破坏敏捷的采用：

• 团队成员不理解这个过程，没有时间或倾向于学习它
• 团队成员没有经验或成熟度来承担对自己流程的更多控制
• 管理层需要详细的长期计划作为可交付成果
• 客户不愿意在最终发货前提供有关增量发布的反馈
• 团队中有很多成员
• 使用中的技术不允许有用长度的构建和测试周期（我已经完成了三小时构建和测试周期的敏捷;这非常痛苦但只是可行），或者不允许它在所有
• 问题域不承认解决方案的增量开发（我不确定这是否真实;最接近我的是在处理加密时，事情要么完全有效还是不成功工作）

在某种程度上，这些可以得到纠正。一个不知情或缺乏经验的团队可以由一群知情或有经验的成员领导。团队领导可以编写一份长期计划，然后让团队忽略它，并希望交付工作代码能够平息管理层。业务分析师或QA可以充当代理客户，提供有关增量版本的反馈。分支策略和构建服务器可用于将构建和测试与提交和合并分离。但是，这些补救办法当然不能保证成功，如果问题仍然无法解决，敏捷就不会成功。

Answer 3

我曾与许多不同的团队合作，试图转向敏捷。一些成功，另一些没有成功。根据我的经验，我可以这样说：

• 当软件创建者希望提高产品质量（无论其在上下文中的意思是什么）以至于他们甚至准备好工作时，转向敏捷是合适一个实现它的团队。

• 当每个人都对当前的质量水平感到满意和/或不想以团队形式工作时，转向敏捷是不合适。

Answer 4

排序答案： 当IT公司制造自己的产品时，敏捷是合适的。例如视觉工作室以敏捷方式制作几年。你可以看到更好的“交付时间的想法”。 敏捷不适合网上银行。另一个例子是客户端在美国和开发团队或其部分在azia。时间延迟使事情变得复杂。

答案很长： 首先，如果您想运行敏捷项目，您的管理层应该了解它，并且您公司的流程应该接受它。如果您尝试解决它们，您将失败。了解管理和内部流程在这里的重要性：https://www.youtube.com/watch?v=4u5N00ApR_k管理层和团队负责人比程序员更了解敏捷流程。通常情况恰恰相反。

其次，您的客户的管理和流程应该包含敏捷流程。银行或金融机构永远不会签署敏捷合同。他们的流程需要在多个层面进行深入规划和批准。了解客户对敏捷的误解如何导致失败：https://www.youtube.com/watch?v=lAf3q13uUpE

我完全同意汤姆安德森的观点，认为项目本身的类型更为重要。例如，如果您签署了固定合同（由于您的管理层或客户），您可能有详细的要求。如果你有详细的要求，你不会运行scrum而是“SCRUM BUT”。它反对敏捷哲学。

可能会发生该项目既不适合敏捷也不适合瀑布。 有时最好在内部使用敏捷，将产品所有者角色分配给贵公司的某个人，他们最了解域名。

Suitability and Unsuitability of Agile methods?