敏捷方法是否为牛仔提供了太多方便的借口

我认为，敏捷方法最适合需求模糊且需要大量交互以帮助塑造最终用户想法的项目。

但是...在我的专业工作中，我一直不停地被那些使用“敏捷”方法作为为什么不花精力在前期设计上的公司作为最终结果。当要求很容易理解时。

我忍不住想，如果没有敏捷方法，我会坐在这里，拥有一个很好的高级规范，而不必在第二天左右出现其他问题时隔天重新访问相同的屏幕和功能所以没有想到这一点。

敏捷方法学的好处真的足以超过给牛仔技术领导者带来la脚的借口吗？

更新：具有讽刺意味的是，我现在是一名认证的Scrum Master。在Scrum课程上发表的一篇论文指出，最好的开发过程是只有一个专家或专家来进行设计决策的过程，但是它存在明显的弱点。Scrum将生产高质量软件的责任转移到“团队”，这意味着不合格的团队可以摆脱意大利面条的困扰，我想这与其他敏捷和非敏捷开发流程没有什么不同。

我相信，如果您以敏捷开发作为牛仔风格编程的借口，那么您并不是真的在关注敏捷开发。牛仔将永远是牛仔，无论您采用什么程序。

敏捷不应该再归咎于BDUF。问题出在实践的纪律上或缺乏纪律。BDUF做法的目的是确定项目方向并事先确定风险。敏捷实践的目的是保持开发状态足够灵活以快速改变方向。敏捷项目可以准备高度详细的用户故事，因此团队可以知道未来的发展方向，并且每次迭代仅选择2或3个就可以完全实施。无论使用哪种方法，问题都保持不变：管理让牛仔们无所适从。

[BDUF：前端大设计]

像其他任何东西一样，敏捷可以用来掩盖不良行为或尝试解决团队认为自己不负责的问题。

但是，某些敏捷方法（如Scrum）的魔力在于它们将为组织内的问题提供很多可见性。包括团队内部的问题！

然后，您将有机会在它们出现时解决它们。

如果问题出在牛仔身上，那么在第一次迭代之后就很明显了。如果问题出在其他地方，您很快也会看到它。

奇怪的是，在我参与的“敏捷”项目中，似乎更像是管理人员的一个借口，跳过了需求收集阶段，而不是像牛仔一样渴望简单地开始编码。我的项目已经非常令人沮丧，因为我们不具备任何最终用户进行交互。取而代之的是，我们有一个主管与销售人员进行交谈，以找出他们认为客户想要的东西，然后召开会议并向经理进行描述，然后经理开始向开发人员分配任务。在一个“好的”项目中，我们可能要引用PP演示文稿，但是通常我们会结束日常的Scrum会议，询问某些功能的工作原理，经理写下问题并询问主管。这是浪费时间，但是却很“敏捷”！

我不会说我是Waterfall的粉丝，因为我也处理令人沮丧的示波器蠕变问题，但是我一直认为敏捷是解决该问题的一种让步，而不是有效的解决方法。具有早期迭代测试和大量纸张原型的良好设计似乎更加有效。

我看到敏捷开发的辩护说它对牛仔造成的失败不负责。敏捷成功需要勤奋和智慧。

只要您对其他方法应用相同的让步，这似乎是一个合理的位置。如果不能将牛仔造成的项目失败归咎于敏捷，那么就不能将牛仔导致的项目失败归咎于非敏捷方法。

然后我们可以争论敏捷与牛仔之间是否存在关联（不是因果关系！）。我相信只有轶事证据。这是否被认为是不被管理层发现的与牛仔习俗相处的好方法？

当然，如果我们接受牛仔可能不会在各种方法中平均分布，并且我们接受牛仔破坏了流程的成功使用，我们将很难测试流程是否成功。关于一个过程更好（在上下文中）的说法几乎是不可证伪的。这是使我对自己的职业感到羞耻的问题之一-许多主张缺乏科学依据。

（顺便说一句，我讨厌将敏捷的替代方法称为“瀑布”，因为瀑布过程似乎是每个人都在攻击的稻草人，但很少有人实际使用而没有任何迭代。）

只要对您的团队有用，敏捷就可以了。

太多的人出售它是为了将一个糟糕的团队变成一个好的团队，而这种方式是行不通的。您不能容忍坏人，而要采取措施突然使他们有用。

我喜欢敏捷背后的许多想法，但是我一次又一次地看到失败是，经理们在推动一套严格的“敏捷过程”，这些过程面对整个敏捷概念，即团队应该是自我-组织。

就“牛仔”而言，我发现对于我所参与的所有敏捷团队来说，这些流程不仅会使他们放慢脚步，而且使他们放慢脚步。我从来没有遇到过敏捷启用 “牛仔编码器”的情况。

对于一支优秀的团队，它似乎运作良好（然后，当您拥有一支优秀的团队时，大多数流程似乎都运作良好，有趣的是，不是吗？）。

根据我的经验，对于其他团队来说，它永远不会帮助坏人做得更好，但是有时它 会使生产人员陷入困境。

总的来说，我认为重要的是建立一个好的团队，告诉他们您需要什么，然后避开。我不认为使用任何流行语都可能解决团队不佳的问题。

（如果您还没有从上面弄清楚，那么我至少不喜欢“ Capitol-A Agile”。另一方面，我也不认为这会鼓励牛仔。）

如果做得好，敏捷应该可以控制“牛仔”技术主管和“英雄”程序员。如果您没有观察到这种效果，则可能表明您的敏捷实现中缺少重要的东西。

我想补充一点，“敏捷”实际上是一个接口（我在这里使用的是面向对象的隐喻），您无法实例化它。如果您的具体实现是XP，那么您必须遵循大量的技术惯例，而这对于牛仔编程几乎没有余地。另一种可能是，组织良好的Scrum团队的团队合作将使其受到控制。

牛仔编码人员也倾向于编写测试性很差的代码，并且他们倾向于不喜欢编写测试。我认为让每个人都进行TDD可以有助于保持牛仔的态度，并使开发人员对体系结构的思考更多。当然，没有方法是完美的。

我目前在这种情况下在一家商店里工作，除了与组织文化有关，而不是与特定的个人牛仔有关。

该组织始终采用相对宽松的“非正式敏捷”方法。我不会说它是真正的敏捷，而是“名称上的敏捷”，而只是实践中不存在的简单方法。不同的团队运作方式不同，但是由于整个组织文化除了非常松散的“仅以名字命名的敏捷”流程之外没有其他方法可利用-这是相对牛仔般的总体混乱情况-尤其是在整合方面（其中有很多）。

这个故事的寓意是-是的，这确实发生了。如果我现在正在找工作，我会非常小心。如果一家商店声称自己是敏捷公司，那么我会在面试中问一些非常棘手的问题，以确保实际遵循的不仅仅是敏捷的误称。

我发现，只有拥有可以使用的应用程序以及可以在其上输入数据的屏幕，用户才能向我们提供反馈。只有这样，他们才能真正理解我们在需求文档中要说的内容（客户签名，但每个人都有自己的意思版本）。如果它不是敏捷开发，那将是一个超出预算的瀑布式项目，但是一旦交付，应用程序就会发生变化。您的第一个版本只不过是供用户讨论要求的原型。因此，我宁愿称其为敏捷，也不愿超出预算。

我认为这是真的，在某些环境中，敏捷是没有纪律的借口。真正的问题是，我们没有意识到为什么要使用任何方法。就我个人而言，我认为该方法论是体系结构问题，因为系统的体系结构应该解决非功能性，质量属性，该方法论应该解决某些相同的属性（可维护性，开发生产力，知识转移，等）。

将方法论视为对过程属性的控制意味着两件事：1）没有度量标准，我们无法将一种方法论的有效性与另一方法论进行比较； 2）需要就哪些属性很重要（交付时间与代码）做出积极的决策质量与知识转移）。

如果既没有指标又没有明确的目标，我们只是选择一种方法作为我们的“魔术羽毛”，只要坚持下去，我们就可以交付软件。

现在，敏捷，XP，Scrum等的反对者都在谈论这种特定方法论的脆弱性。争论是：为什么要使用一种可以被缺乏纪律的个人破坏的方法来遵循所有规则？这个问题是有效的。但是，这只是症状，而不是原因。如果定义，测试和及时反馈一组准确而有意义的（这是困难的部分），我认为我们会发现特定的方法论与成功无关。（有趣的是，我看到过使用无数方法论的成功项目，而使用相同方法论的失败则是两倍）

那么指标是什么？它们因项目而异，因团队而异，有时也不尽相同。当交货时间表很重要时，这很有用，我个人使用的是估算技能和质量。大多数开发人员可以准确地估计为期一周或更短的任务。因此，一种方法是将项目划分为一个开发人员一周的任务，并跟踪谁进行估算。随着项目的进行，他们可能会更改其估算。任务完成后，如果关闭超过10％（每天1/2），我们将其视为错误-我们确定为什么关闭估算（即未考虑数据库表），确定纠正措施（即将DBA包括在估算中），然后继续进行。利用这些信息，我们可以创建指标，例如每周的估计错误数，每个开发人员的错误数，

所以呢？那就是方法论的来龙去脉-如果您的预测模型无法满足流程质量，则可以选择添加或删除方法论的某些方面，并查看其如何影响模型。当然，没有人会因为担心失败而愿意参与开发过程，但是我们已经以持续高且可预测的速度失败了。通过进行单独的更改并衡量结果，您可能会发现敏捷是您团队的理想方法，但是您可以轻松地找到RUP，瀑布式或最佳实践的杂烩。

因此，我的建议是让我们不再担心我们所说的流程，进行与我们的开发流程目标相关的检查，并尝试使用不同的技术来改进该流程。

我会坐在这里，那里有一个很好的高级规范，而不必每隔一天就要重新访问相同的屏幕和功能，因为其他东西突然出现了，所以没有想到这一点。

这似乎与我的同事在他所从事的“敏捷”项目中的经历相吻合（我自己从来没有参与过）：要求他为某些规范编写一段代码，然后在完成测试并准备提出一项新要求，要求他进行更改并重新测试。他发现这很令人沮丧。

我不是在抨击敏捷，我怀疑团队没有正确地进行敏捷-但是，正如您所说，牛仔有时可以使用“敏捷”一词来说服尖锐的领导层管理者半熟的设计是积极的，而不是消极的。

有趣的是，没有人认为自己是牛仔编码员。我打赌很多海报是或曾经是;）

牛仔编码员很好，因为他们喜欢快速完成工作。他们通常不关心大图问题或代码质量，这就是为什么“牛仔编码器”通常是一个绰号。他们的方法减轻了项目后期交付的机会成本风险。

非牛仔编码员喜欢以安全，有纪律和有序的方式进行工作。他们喜欢正确地构建它并构建一次。他们以永远收集信息，考虑假设条件，产生没人阅读的大文件以及迟到或迟到交付系统而闻名。他们的方法试图减轻劣质软件的风险。

敏捷方法的卓越之处在于，它们通过强制进行短时限的工作迭代来利用这两种类型的编码器的优势，这些迭代要求编码人员快速生成高质量的小型作品。而且每次迭代都减轻了延迟交付的机会成本风险和质量低劣的软件的风险。

敏捷很少强调前端设计/规范的原因不仅仅是因为需求可能会发生变化。更深层的原因是，即使需求稳定，规格仍趋于：

• 错误-无法捕获需求。

• 不一致-充满矛盾，因为它们包含足够的信息，以至于作者/阅读者无法抓住它们。

• 分离-它们没有合并来自正在运行（尽管已退化）的系统的有价值的反馈。