-1

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

4

4 回答 4

2

在以下情况下，敏捷可能不适合：

  • 它有可能暴露过度的管理（一些职位突然变得明显多余）
  • 人们实际上不想玩得开心，不想做有创意的事情，更喜欢朝九晚五的日常工作模式（维护迫不及待要处理的旧式蹩脚软件）
  • 政治而不是专业精神经营公司
  • 人力资源管理公司（敏捷是关于人的，人力资源将他们视为事物）
  • 客户希望你能弄清楚他需要什么（敏捷会让你问他不想回答的问题）
  • 敏捷有望成为一根神奇的魔杖，无需任何人改变习惯即可解决问题（另一个流行词，一种时尚）
  • 开发分布在彼此相距很远的多个地点，在不同的时区（通信受到影响）
  • 你有一个尖头发的老板；）

或一般来说：

  • 被误解了
  • 组织被严重的病态吞噬
  • 没有人真正想要它
于 2013-01-27T03:59:03.237 回答
2

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

因此，当不存在做好它的条件时，敏捷是不合适的。

有些事情可能会阻碍敏捷的采用：

  • 团队成员不了解流程，也没有时间或意愿去学习它
  • 团队成员没有经验或成熟度来承担对自己流程的更多控制
  • 管理层需要详细的长期计划作为可交付成果
  • 客户不愿意在最终发货之前提供有关增量版本的反馈
  • 团队成员流失率高
  • 正在使用的技术不允许构建和测试周期的有用长度（我已经完成了敏捷的三个小时构建和测试周期；这非常痛苦，但几乎可行），或者根本不允许
  • 问题域不承认解决方案的增量开发（我不确定这是否正确；我最近遇到的情况是在处理密码学时，事情要么完全工作，要么根本不工作)

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

于 2013-01-27T12:03:33.547 回答
1

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

  • 当软件创建者非常想提高他们的产品质量（无论它在他们的环境中意味着什么）以至于他们甚至准备好作为一个团队来实现它时，转向敏捷是合适的。

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

于 2013-01-27T11:36:44.923 回答
0

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

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

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

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

项目可能既不适合敏捷，也不适合瀑布。有时最好在内部使用敏捷，将产品负责人角色分配给公司中最了解该领域的人。

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

于 2014-10-09T12:05:14.773 回答