一个公共组织要求我举办一个有关敏捷开发101的非正式研讨会，解释Scrum，看板等的术语和概念。我已经在敏捷环境中工作了大约五年，但是我不认为我是Scrum的传播者。

研讨会结束后，他们喜欢这个主意。但是，他们解释说，这种方法可能不适用于他们，因为他们需要委托外部软件公司为他们开发软件（他们自己只有很少的开发人员）。这项活动需要在公开招标过程中完成，描述结果，价格和时间范围。这是为该组织（公共研究机构）申请预算的法律要求。

这些约束似乎与敏捷开发的基本原理矛盾，不是吗？

在这种环境下Scrum只是不兼容吗？

您对这个组织有什么建议？

Scrum可能不适用于该组织。

在《 Scrum指南》中，“ Scrum是用于开发，交付和维持复杂产品的框架。” 它还设计用于由3-9个成员组成的产品开发团队，产品所有者和Scrum Master（可能或可能不在开发团队中）组成的团队，总共4-11人。

关于内部开发，您提到他们只有几个开发人员。如果没有足够大的团队来组成Scrum团队，那么使用所有Scrum都是没有意义的。但是，某些Scrum实践可能对组织有用。

对于合同开发，外部方之一可以使用Scrum。在这种情况下，对于研究机构了解Scrum的实践并了解其角色及其工作方式很有用。他们可能仍然需要了解外部开发组织如何使用Scrum实践以及其他实践的细节，但是它可以帮助他们理解它的工作方式。例如，了解需要参加Sprint评论或与组织（可能是他们的产品负责人）合作订购产品待办清单。

18F是美国政府内部的数字服务机构，它在政府如何撰写合同以允许以符合法律的方式使用敏捷方法的工作方面做了很多工作，并规定了总体结果，而不是工作方式的详细要求要做。他们的一些资源包括：

• 通过敏捷合同格式改善政府成果
• 敏捷毯子购买协议
• 模块化承包（通过敏捷开发将大型项目分解为较小的模块化项目）
• 您的项目是否使用“敏捷下降”？

敏捷工作方法的一个优点是，它们专注于在授予合同后即在授予合同后执行过程中发现问题的解决方案，而不是像第15部分那样预先指定详细的解决方案。敏捷合同试图指定需要详细解决方案的问题，通常是描述高级合同交付领域的产品待办事项。

了解此问题后，管理与预算办公室和联邦采购政策办公室指示各机构停止使用SOW，而转而使用绩效工作声明（PWS）来获取服务。PWS“应该以一般的方式陈述要求（结果）的要求，而不是如何（方法）的要求。”优秀的签约人员建议代理商通过购买专家服务，这意味着您不是最了解知识的人。在“如何”完成工作中。作为任务负责人，您是必须完成任务的专家，但是将两者混为一谈会使您的任务面临风险，使合同更难提供价值。

从根本上讲，该方法更像是雇用服务提供商与您一起设计解决方案，而不是事先列出详细规格的页面。该机构不会通过列出“设计必须为四层，屋顶间距为37º。天花板上的感应灯开关。” 相反，他们将与建筑师签订合同，与客户协商提供设计服务，并依靠他们的供应商（该领域的专家）来生产最终的可交付成果。

虽然细节将取决于机构以及适用的采购政策和法律，但它的确表明，在大型政府IT项目的所有失败中，有一些团体正在努力将软件开发的公开招标转换为更现代的敏捷方法，有足够的政治意愿和可信赖的发展伙伴。此类项目的构思和管理方式确实发生了重大变化（包括在整个过程中为用户提供反馈的大量持续时间），组织可能对此感兴趣，也可能不感兴趣。

听起来确实很典型。招标一旦写好，要约就中了，其中一个竞争者已被授予合同……就公共组织的代表而言，该项目已经完成。

这就是为什么许多此类项目失败的原因。在他们超出预算之后。

他们所缺少的（或至少没有觉得与他们无关）的要点是，他们是应该参加会议和演示的利益相关者。

因此，与敏捷或Scrum毫无冲突。人们没有承担起自己的角色。政府工作的方式导致了这一点。

这不像“我们希望拥有这个系统，我们愿意在其中付出一些努力，看看我们能走多远”。

不会。这就像“我们的民主国家决定到那时我们将拥有这个系统”。在一方面100％成功与另一方面100％失败之间没有余地。从一开始就注定了。

这也是向市场要求高价的邀请。因为成本太高而不能执行该项目不是一种选择，在撰写招标之前已经做出了执行该项目的决定。

公平地说，即使利益相关者担当起他们的角色，他们也将完全无能为力。出于相同的原因，他们没有人会相信这些演示。

不，SCRUM与公开招标不兼容。您需要明确说明公开招标中要购买的商品。

“购买者希望从一个经验丰富的SCRUM团队那里购买10个为期2周的开发冲刺，该团队包含5个开发人员和一个经过认证的SCRUM管理员（购买者将担任利益相关者角色）。冲刺将在2018年3月至2018年7月进行”招标开始。当然，您需要列出必要的团队技能，并给出有关他们将从事的项目的想法，但是通过招标来聘请团队完全可以接受。

当然，您在这里放弃了“固定范围”。毕竟，这对于SCRUM是很典型的。在招标中增加一些用语（但我们这里要进入合法领域），您可以允许进行较小的范围扩展，即少量的其他冲刺。但是，如果您决定在最初的10个冲刺之后再增加10个冲刺，则可能需要重新招标。

很难。

您显然无法以无限制的预算来投标工作。因此，您必须查看需要完成的工作以及需要付出多少努力。

现在，许多软件项目失败的原因是由于这样的事实：预先确定，花费时间，精力和范围很容易出错。例如，招标书中给出的规范几乎总是含糊不清。

因此，不仅存在敏捷性问题，而且存在软件开发的公开招标概念。在您指定的时间内，有人离开并准确创建所需内容的机会很小。

如果允许一些灵活性，则可以对此进行改进。

听起来像进行公开招标的过程并不灵活。但是，一旦赢得合同，您可能会发现有麻烦的余地。例如，您可以允许敏捷工作，但您必须接受（并获得法律许可）这可能会影响范围。

现在，我相信这将带来更好的产品，因为您将早日了解正在发生的事情，并在将其烘焙到产品中之前进行更改。紧密的反馈回路和迭代开发可以使产品更好地符合实际需求（可能是招标的也可能不是）。

这取决于，但可能是。

我愿意打赌，任何与任何政府合作开展过任何与IT相关的项目的人都将知道，实际上，招标中描述的“硬性限制”永远都不会得到满足。事情往往会超出预算，被延迟和/或范围改变。通常是这些的倍数。如果政府愿意承认这是事实，并愿意像对待他们的指导方针那样对待它们，那么scrum就能发挥出色的作用。

从个人经验（包括我自己和我的专业网络）中，我知道大多数政府项目的要求经常变化。负责的委员会在项目结束时最终参与其中时，往往也会得到很多反馈。这些是Scrum非常适合的问题。

但是，这将需要政府及其机构的观念发生根本变化。在大多数国家，这种变化极不可能发生。在此之前，公开招标将继续与Scrum合作。（就此而言，我个人认为公开招标将继续与任何可持续的软件开发实践不兼容，但这是另一回事……）

您对这个组织有什么建议？

在这一点上什么都没有。

这里缺少的是有关其当前流程导致它们的问题的故事。不要盲目推荐Scrum。有一点。这不是一种适合所有人的尺寸。

询问他们，他们当前的流程导致了什么问题。听。仅推荐解决其实际问题的方法。他们将偏向于当前的过程。修补程序似乎决定了开发过程，但事实并非如此。他们规定了交付过程。但这是该团队以前可能从未做过的区分。

当需求在项目的整个生命周期内变化超过3％时，敏捷工作效果最佳。否则瀑布仍然非常有效。今天它仍然在许多地方使用。当然，许多成功的开发人员从未以任何一种方式使他们的过程正式化。当棘手的问题是技术问题而不是人事问题时，非正式工作会很好。

因此，请与他们讨论他们当前的流程以及存在的问题。告诉他们这些方法有什么帮助。但是，如果没有破裂，请不要修复它。