政府项目对敏捷方法的挑战

前面的敏捷讨论在这里有很好的答案，指出了对于在软件开发中成功实施敏捷方法学至关重要的因素。大多数要点是典型的组织和管理挑战，但我要担心的一点是，在整个过程中必须让客户参与。

客户是您无法实际控制的一件事，也许您的商业模式使您适应政府签约的工作，例如，严格的合同迫使公司必须：

• 完全按照要求提供X功能

• 功能请求将被扔在墙上，不要打扰我们，我们不想听到它。

• 客户心中没有优先功能的概念，它们都很重要，或者我们不会要求它们。

• 无论超支或截止日期如何，该项目的成本都不会超过Y，且不得低于Y。

• 完全交付所有工作的绝对，严格，最终和不可协商的截止日期。

我们以前从未与这样的客户合作过，但是该项目的资金实在太可惜了。我们需要这项工作。

我来到这里工作是在HARD上更改流程，以朝着敏捷开发方向发展，在这里，我不知道如何协调该项目适合我们新流程的位置。我从来没有像现在这样拥有过开放式的手动管理能力，这使我相信可以领导开发团队并沿着这条道路前进，而现在我们在这里，我不能诚实地告诉自己，这个项目将真正在敏捷的方式。我觉得管理层相信我可以带领这条路走下去，并且让他们失望，因为我们现在所处的这种情况非常明确地要求瀑布。恐怕如果我现在回溯，我可能会失去他们的信任。

其他答案，例如这里所说的，对于这种客户来说，敏捷是不可能的，您同意吗？你们有没有遇到过类似的情况并使它工作？您实施了哪些策略来使敏捷成功实现？

我认为首先要意识到的是，敏捷与敏捷之间是有区别的。缓慢推出敏捷技术和特性-跨职能团队，自适应计划，渐进式/增量交付，有时间限制的迭代，甚至从精益中引入概念与引入极限编程，Scrum或Crystal都大不相同。

您明确提到了客户参与。是的，许多敏捷方法都要求客户参与，但这并不是敏捷所必需的。在每个与政府/国防相关的计划中，我始终都有与客户联系的计划或项目经理。此人成为“客户的声音”。在他们进行电话会议，电子邮件或打电话和澄清时，可能会减慢速度，但是您可以由一个人（或一组，如果您还有副PM）来代表团队。诚然，情况并不完全相同。但是，不是要灵活地应对变化吗？

您还提到了一些关键概念：预定义的需求，具有“丢在墙上”的功能请求，由于“它们都很重要”而缺乏优先级，以及固定成本和/或固定进度的项目。每个问题都可以通过不同的方式解决。

如果您认为自己已经满足了所有要求，那么您可能没有。要求确实有所变化。仅仅因为您有一个“完成并签字”说明，并不意味着它是一成不变的。给定您拥有的任何需求文档，捕获他们的感觉和/或以合同规定的方式，并交付需求，设计和体系结构。另外，看看您是否可以将它们当作活文档（我今天在工作中看到的设计文档标记为Revision G，这意味着它是第8次更新）。询问在任何给定的迭代中可以保留多少作为TBD，以及现在需要确定多少-可能会有一些让步。

敏捷地处理您的文档。不要在“您的团队想要什么”和“客户想要什么”之间重复工作。例如，如果您的客户想要一个传统的软件需求规范，而您的团队想要使用用户案例，请尝试适应传统的SRS，并使用操作项和滚动操作项列表来代替用户故事，以免浪费时间制定“系统应...”和“必须能够做到，因为”。但是，这确实需要团队的纪律来适应项目之间的差异。捕捉反思中的问题。

一旦进行开发，您可能会运行5或6次迭代，然后邀请您的客户到您的设施中查看实现的子集。冲洗并重复此过程。这不是某些方法要求的持续参与，但是您确实具有高可见性的优点。如果您的客户拒绝，则至少您尝试过。如果他们回答“是”，您可以启发他们敏捷。在我参与的一个项目中，客户每隔几个月（通常为3-5个月）访问该站点。他们会看着我们进行质量检查，会与工程师讨论问题，并与计划/项目办公室进行业务往来。这是每个人都可以进入同一页面的机会。

测试和维护与其他敏捷项目相同。创建测试程序并以适当的方式记录缺陷，跟踪每个合同义务的度量标准，并记录测试结果。如果您想遵循TDD，那就去吧。持续集成是另一个好主意。在项目状态会议期间，您的项目经理可以使用此信息说“我们实施了N个要求，有M个测试，X个测试通过”，并向有钱人提供了项目健康状况和状态更新。

说到钱，我们有固定成本和/或固定时间表的问题。

处理固定的时间表非常简单。根据您的要求，您知道可以完成多少次迭代。就实现，测试和集成的功能而言，每次迭代的工作量几乎都是固定的。这可能很困难，但是要分解特征并将它们预先分配给迭代并不是不可能的。这可以追溯到我邀请客户的时候-如果您有一年并且正在使用2周的迭代，则也许每季度邀请一次客户（并每季度邀请他们一次）并向他们展示以前的工作结果。让他们看到您对需求的优先顺序，您的未来计划以及计划进度。

处理固定预算是相似的。您知道您有多少时间，项目有多少资源，花费了多少，因此每个迭代每个人可以工作多少小时。这只是确保每个人都认真跟踪此事的问题。如果您的公司可以负担加班的费用，那就去加班。否则，请确保每个人都在适当的时间长度上工作，并使用良好的时间管理技能和时间拳击来保持每个人的生产力。您需要降低工作时间来降低成本-提供更多的增值文档和软件，而无需花费会议和开销。

归根结底，这并不一定是要敏捷，而是要应用使敏捷变得更好且敏捷的事物。能够响应需求的变化，即使客户不想要它也能够交付频繁的软件，仅生成增值文档（以及合同中规定的所有义务），等等。

是的，敏捷不适用于这样的项目，因为听起来要求已经完成并固定下来，这可能是昂贵的顾问，委员会会议和政治妥协多年分析的结果。如果客户的纪律性很强，以至于他们可以准确地告诉您他们想要什么，那么Waterfall就会很好地工作。他们可能是错的，但至少您是书面的，如果您提供了书面证明，您将获得报酬。（当然，这并不能说明客户满意度。您有可能会交付他们实际上不需要的东西。）

创建敏捷是为了解决您没有的问题：需求不确定性带来的风险。

确实，客户可能会要求更改请求，但您可以遵循以下两种方法之一：

1. 这笔钱实在是太可贵了，以至于您知道您可以在项目的各个阶段吸收X数量的新功能，而且仍然可以在不损失您的衬衫的情况下出现，或者
2. 您一开始就向客户明确表示，由于他们协商了一个严格的价格，因此每个新功能请求都将生成一个变更单，该变更单的价格必须由他们批准，并附带一个采购订单（或原始采购订单），以便您实施。变更单将阐明对功能或时间表的任何影响。如果他们说不能更改截止日期，那么随着项目的进行，变更单的成本就会成倍增加，因为以后进行变更的成本更高。

在第一种情况下，这种关系感觉很友好，但是事实是，很少有采购部门不会压低您的价格，因此，在大多数情况下，您处于第二种情况。这意味着这种关系是对抗性的，但是如果您想在企业中生存下去，就必须在保持关系的同时善于管理这种关系。这是项目经理工作的很大一部分。

听起来您可能处在情况＃1中，这很好。我想，政府合同，他们不在乎钱的唯一的地方，因为，毕竟，他们不花自己的钱，他们花费你的钱。

...政府签约的工作，例如，严格的合同规定公司必须：

第一。严格 但这不是僵化的。它只需要注意细节和一长串的变更单。

实际上，政府机构以缓慢，低效的方式敏捷。您必须始终编写（和协商）正式，详细的变更单。

完全按照要求提供X功能

直到被变更单修改。

功能请求将被扔在墙上，不要打扰我们，我们不想听到它。

沟通的渠道就是变更单。预算和进度影响。

在客户心中没有优先功能的概念，它们都很重要，或者我们不会要求它们。

这很难解决。即使是花费大量金钱用于“需求分析”的非政府企业，也不想被告知，大量的，扁平的，蒸蒸日上的需求没有被优先级和权衡信息所束缚。他们付出了很多钱来满足所有要求。您想如何获得更多信息？

这是一个难题。

无论超支或截止日期如何，该项目的成本都不会超过Y，且不得低于Y。

除了变更单。其中修改Y和截止日期。

完全交付所有工作的绝对，严格，最终和不可协商的截止日期。

“不可转让”通常是不正确的。这是可以商量的。谈判很痛苦。

与政府机构进行谈判的重要部分是，您需要“律师级别的证据”来进行成本和计划变更。带有精美幻灯片的一些仔细的技术演示并不是“证据”。您需要大量文档来论证。

政府人员需要提供无懈可击的证据，表明他们已尽其所能，力求做到尽可能便宜和有效。他们知道，每个决定都会在公众媒体上重播，并在事后审查中进行审查。

软件开发的复杂性以及政府工作的事后事实，即“星期一早晨的四分卫”，使他们不愿在没有大量证据的情况下对合同进行变更。

这使得适当的敏捷方法变得困难。

“在流程和工具上的个人和交互”很难。您不是与个人一起工作，而是工作的政府代表受制于流程。

在这样的项目中，他们束缚了您的范围，资源和时间。您唯一需要管理的就是质量。所以...

您将无法从敏捷方法中获得大部分您可能会从中获得的最大收益，但是您可以尽最大的努力来减轻质量风险，并能够将问题提前通知客户，而不是稍后。

因此，请尽可能敏捷：

1. 仔细检查需求，并根据技术风险对它们进行优先排序。将优先需求设置为待办事项。
2. 完成sprint中的待办事项-设计，测试和编码sprint的功能。您缺少客户端交互，因此需求文档必须代表此活动的客户端。
3. 邀请客户参加每次冲刺审核-他们可以说“不”，但他们可能会说“是”。而且，您很快就会收到反馈，而不是稍后。

如果您开始按时完成任务，那么您将能够展示已完成的工作，也许到那时，客户知道他不会得到所有东西，便会优先考虑您想要做的事情。您也应该完成最冒险的工作，这意味着在截止时间完成任务最容易加班。

我认为这类客户不是常态。您正在与一个之前请求过类似项目的小组打交道，因此他们确实知道他们想要什么。您永远不会说他们的规格会改变。

完全按照要求提供X功能

如果我按建议含糊地提供了X功能，并且随时准备更改它，我很幸运。

功能请求将被扔在墙上，不要打扰我们，我们不想听到它。

如果您知道他们想要什么，请构建它。

在客户心中没有优先功能的概念，它们都很重要，或者我们不会要求它们。

您不能输给这一个。根据需要构建它们。

无论超支或截止日期如何，该项目的成本都不会超过Y，且不得低于Y。完全交付所有工作的绝对，严格，最终和不可协商的截止日期。

如果您从未为政府部门建立过一个项目，那将是一个艰难的过程。如果您有一些历史记录，则可以确定是否可以交付。这并不意味着他们没有支付好（他们以支付10美元的锤子支付50美元而臭名昭著）或抱有不合理的期望。有了这些规范，与规范相比，您团队中的某人应充当客户并批准工作。即使您发现了一个漏洞并恳求他们更改要求，他们也可能不会。

令人遗憾的是，您所描述的是典型的客户观点，即应如何解决软件项目。这并不是说客户不合理；毕竟-这不是人们如何执行其他任何建筑（例如房屋）的方法。话虽这么说，但我提供的除了我们已经知道的以外，还没有提供更多其他服务。您要问的是...在这种情况下应用敏捷实践是否可行？

我受益于刚刚完成一个项目，该项目在很多方面都与您所描述的情况相似，即

1. 固定（一成不变，来之不易）。
2. 功能需求文档（“圣经”）。不足为奇。
3. 传统角色：项目经理，业务分析师。
4. 参与度低的业务用户（您可以说“没有产品赞助商”吗？）。

...当然，具有上述远见的开发团队将尽力以敏捷的方式工作，尽管存在以下情况：

1. 2周的迭代；
2. 站起来;
3. 回顾；
4. 配对编程；
5. TDD；
6. 持续集成。

但是，这对业务有何远程意义？否。在截止日期的两个月之前，直到疯狂仔细观察到的反复无常的反复会议和计划会议都被无头的鸡发炎所取代。

上面其他人提供的答案或多或少都是妥协的。我认为，当我们妥协时，敏捷（无论是“敏捷”还是“敏捷”）以一种有害的方式“完成”。在我看来：

没有妥协或敏捷。

敏捷的精神就是要追逐，消除浪费，对自己残酷诚实。现在，有据可查且不可否认的事实是，对大型项目的软件评估充其量只是一场赌博。作为软件专业人员，我们有责任教育潜在客户吗？如果客户不愿意接受我们是专家，那走出我们的职业责任不是吗？

当我开始在现在的地方工作时，我发现自己在问与您问过很多相同的问题。对于政府签约的瀑布，有话要说。具有讽刺意味的是，敏捷现在已成为政府客户（实际上以瀑布式方式工作）的流行语，因此现在我们不得不更加努力地与基本没有弹性的客户一起实施敏捷过程。

我们拥有一个被描述为“ Scrummerfall”，“ Agilefall”或“一团糟”的系统，但是在许多方面，随着这个（gargantuan）项目多年来的发展，我们已经逐渐能够采用越来越多的敏捷过程。 。我们这样做的方法之一是从根本上寻找与我们系统的用户（而不是我们的用户）的沟通渠道。我们的客户是一个闷闷不乐的部门，由任命的官员领导，他们永远不会在工作中接触过我们的软件，也不想了解它。我们的用户是试图完成重要任务的常规政府人员。对我们而言，建立通信反馈环路以使我们像以前一样敏捷的关键是必须进行UAT（用户接受测试）。

在我们项目的早期，我们决定在这里聚集来自政府广大客户各个办事处的ACTUAL USERS代表小组，在此过程中，我们将与他们进行数周的面对面交流测试脚本来测试我们的软件。作为非正式的事情，需求团队把这次变成了从实际最终用户那里获得反馈的宝贵方法。同时，政府内部的UAT测试团队通过其官僚机构，对包括变更单在内的正式需求流程产生了越来越多的影响。最终结果是，像我这样的BA充当嵌入Scrum团队的替身产品所有者，并且能够与真正的客户获得宝贵的面对面时间，从而使我们能够以非常敏捷的方式运作。

显然，有很多问题，我们仍然还没有真正敏捷，但是我们足够敏捷，足以作为一个大型敏捷项目的示例，该项目实际上是在政府合同部门中使用该方法的。

总结一下：利用您在组织内部的敏捷传道者的经验来渗透您的客户。与他们一起学习，与他们身边的关键人物建立起基于信任的合作伙伴关系，并围绕他们不可避免的正式，僵化的需求流程开展工作。地面人员会感谢您，他们必须实际使用您开发的内容！

您假设需求写得很好，并且您认为它们表示了他们认为的含义。敏捷过程的来回过程将有助于确保他们除了获得所需的东西以外，还能得到他们想要的东西。