确定元素的交货日期是否是“敏捷”的工作方式？

我们一直被告知，我们将由高级管理层以敏捷的方式开展新项目。他们设置了站立式，冲刺计划，回顾展等。但是，他们现在想出了一个计划，详细说明了他们希望我们针对每个要素提供的所有工作，并再次展示了日期，并在每个要素中进行了演示。一。该计划将于2017年第二季度发布。

在我看来，这似乎是最糟糕的瀑布，一个没有技术团队投入的计划已经草拟，其中计划中的某些故事还不清楚，开发团队也没有估计。

但是，我知道他们的论点是“高级利益相关者必须有日期并且必须有计划，我们不能仅仅从积压的工作中进行。” 在我看来，似乎高级利益相关者还没有购买敏捷，因此我们注定无法在较低的水平上实施它。

这是公平的判断还是我对这个计划反应过度了？

满足最后期限和满足所有要求之间是有区别的。它就像古老的格言“快速，好还是便宜，选两个”。

因此，您在这里有固定的交付日期-很好，这意味着您受到时间限制，因为最后一次冲刺结束时交付的将是最终产品。您要记住，每次冲刺结束时，您总是必须发布可用的软件，不是吗？

可能发生的情况是最终软件将缺少某些功能。嗯，这发生在所有开发方法上，包括瀑布。将会发生的一切是，您将被要求在事后制作补丁程序发行版或版本2。这假定您的最终交付当然足够好！

因此，固定日期并不是一种敏捷的工作方式。敏捷并不意味着您有无限的预算来使用新的计划工具。这确实意味着您必须专注于交付，这绝不是一件坏事。

不。这是非软件公司倾向于做的一类确切的事情。有计划，截止日期和预算。由于人类不愿预测未来，因此它将不可避免地失败。

让我们在这里浏览各点：

我们一直被告知，我们将由高级管理层以敏捷的方式开展新项目。

如果您是敏捷的人，那么您将拥有一支自组织的团队，而不是被管理层告知如何工作。

但是，他们现在想出了一个计划，详细说明了他们希望我们针对每个要素进行的所有工作，并再次展示日期以及每个要素将要演示的日期。

不。这几乎就是迭代开发的对立面。将会发生某些事情（有人生病，有人离开，忘记了某些要求，服务器死机等等），然后您错过了其中一个目标。现在，管理层要么重新计算整个计划，要么破解开发计划。

开发团队尚未估算出任何数据。

那么，如何管理知道，这个计划是可行的，在所有？在敏捷中，工作是谈判。业务说：我们想要这样。工程说：好的，假设XYZ，将需要3周。您所描述的没有客户合作。没有个人和互动。

在我看来，似乎高级利益相关者还没有购买敏捷，因此我们注定无法在较低的水平上实施它。

您不一定注定要失败，但如果不是，那只是一个巧合。当由于管理层看不到未来而出现所有工作时，您会错过约会（或生成伪劣代码，或需要比预期更多的资源）。那将是你的错。然后，管理层可能会迫使您花费更多的时间来约会，或者使人们陷入困境。

最好的情况是，管理实际上是敏捷的，并且足够聪明以减小范围。意味着他们只是花了所有时间来制定一个毫无价值的详细计划。

如果期望在特定日期交付特定功能集，那么不能，这不是敏捷项目管理。敏捷项目管理本质上是经验性的。做出预测并非基于高管的意愿，而是基于对先前绩效的分析。

您的描述与我认为的货运敏捷型相符。重点是特定的过程和仪式，而不是基于证据的项目管理的核心概念。如果您将此与精益或TPS相关联，您可能会有些运气，使商人了解。您需要在这里解决的真正问题是让管理人员摆脱对未知事物的恐惧。对高管的正确答案是：“我们现在无法告诉您何时完成工作，但是一旦我们开始交付价值，就可以根据我们的经验进行预测。” 开发人员倾向于说“完成时完成”和“我不知道何时完成”。经理们不会对高管说这样的话，这听起来像是nincompoops。

该计划很可能会失败，需要进行修订。对于团队来说，最大的风险是要在最后期限前大刀阔斧，质量会受到影响。在某些时候，您不会达到目标（很可能是第一个截止日期），并且会努力达到该日期。可能会加班，并且会有偷工减料的压力（跳过单元测试，代码审查等）。这是一个滑坡，一旦您沿着这条路走，就会有点下降，而且事情会变得难看。随着项目以这种方式继续进行，生产率将变差。

如果您可以让开发团队提出一个统一的阵线，那么您确实应该坚持并坚持质量方针。我的经验是项目经理倾向于认为软件输出是线性的。也就是说，每个期间X都会产生Y个“完成百分比”。就是说，如果在允许的时间中途您还没有“完成50％”的任务，克拉克松开始大放异彩。实际上，如果您做得对，那么第一个功能往往要比第50个功能（具有类似大小）花费的时间长得多。如果您可以度过最初的危险危机时期（“发生了什么？”，“我不知道”看不到任何事情完成！”）您可能会没事的。

欢迎来到真实的业务。

有一种较旧的业务样式，我倾向于嘲笑为“传统发展”，然后有一种新样式，即“敏捷开发”。如果我尝试将这些视为对立的理想，我们会发现中间存在一个直接的分歧：计划和需求放在传统专栏中，发现和进化放在敏捷专栏中。它是整齐，整洁和错误的。

实际上，业务是在两者之间寻找快乐的媒介的搜索。可以很容易地表明，任何一个极端实际上都平放在其表面上。热爱敏捷的我们热切地展示了传统发展的纯粹理想的所有问题，并且有很多人可以展示出纯敏捷崩溃的许多方式。 成功的敏捷公司是在两者之间找到特定平衡的公司。成功的传统公司是在两者之间找到自己特定平衡的公司。你不能没有一个。

甚至我们有福的SCRUM流程也显示出两者之间的平衡。尽管已经尝试了最大程度地提高敏捷性的尝试，但仍需要进行一些关键的权衡。例如，产品负责人为所有客户提倡艰巨的工作。SCRUM故意不指定交互作用的方式。每个人都需要在一天结束时获得报酬这一事实故意引起了人们的注意。制造无关紧要的错觉是产品负责人的工作。

（有趣的是，只要您不生产产品之前就不会获得报酬，并且在获得授权之前就无法访问专有信息，那么纯敏捷就可以很好地工作。我认为唯一感到满意的软件工程师从事这项交易的是企业家）

因此，管理层决定了其中将包含哪些功能以及何时需要使用这些功能。没关系。我听到的一句话是“顾客选择什么和何时，生产者选择谁和方式”。 您已经注册了“什么”和“何时”。除了向您提供使用“敏捷”作为您的方式的机会以外，他们没有说明谁是谁或方式。剩下的就是帮助管理层了解他们需要雇用多少人来满足他们的需求。

在理想的环境中，您的公司从外部就可以敏捷。它以敏捷的方式与客户互动，从而使开发人员能够为他们敏捷开发。 但是，公司通常必须在与外界进行敏捷开发的同时与外界互动。 两者之间总是存在着一系列复杂的权衡，这对每个公司都是唯一的。

就我个人而言，我认为这种情况是任何认为自己了解敏捷开发的人的测试用例。在将来的某个时候，您将必须在截止日期之前开发产品，并且该产品/最后期限对将相对固定。 如果固定产品/最后期限破坏了您的流程，那么您真的可以说自己首先是敏捷的吗？

我的建议：不要将其视为瀑布。您仍然可以控制“操作方式”。您仍然可以进行敏捷而闻名的所有快速冲刺和灵活的原型制作。 您只需要知道橡胶会碰到道路，就必须交付。这是现实世界，而不是理想世界。首先让他们问您更好吗？当然。可能不是您的电话。您可能根本不完全了解，可能有数千种与业务相关的原因以其方式进行。随时拒绝他们，但要了解他们可能有充分的理由去做。

敏捷并不会阻止您计划里程碑（例如，我们将在3个月内发布V 1.0），但是无法确定每个里程碑的内容。

我认为您应该如何反应取决于项目的性质。如果该项目要在2017年第二季度之前将一个人送上月球，每个人都会同意它注定要失败。如果您认为可以在2017年第二季度末交付MVP，则应该逐个sprint地处理它。

如果管理层认为您的团队正在尽力而为，并且您可以在每次冲刺中显示进度，那么您应该能够进行更多的谈判。

每个与业务相关的项目都有其局限性：

• 时间
• 资源资源
• 预期的最低功能集

没什么 发展敏捷并不意味着“人们付钱给我们，所以我们可以在任何可能的时候开发我们想要的东西”-您将始终有一定的时限。总会有一些最低要求的日期，如果不满足最低要求，该项目将被取消并称为失败。它们有时可能是隐式的-因此经理知道“如果4周后如果我没有具有这些功能的可用UI，则该项目注定要失败”-或可能有股东设定了目标。

立法产生了许多项目。-如果政府决定您必须在2017年之前实施功能X才能遵守新法律，那么您将拥有不可商议的期限和一系列需要准备的功能。唯一的变量是管理人员可以分配给任务的资源量。-在这些项目中，最后期限是外部决定，他们将需要观察您的进度，听取您的预后，并组建团队或外包部分工作以实现其目标。

所有这些都不反对敏捷开发。您仍将获得冲刺，在自己的时间范围内开发功能。您将始终从客户端那里获得功能优先级-并且您将努力在截止日期之前交付尽可能多的这些功能。

如果实际可用的资源将在最后期限之前得到满足，那将是一个管理问题。您可以提供预后以及每周/每天的状态更新，他们可以决定是否需要更多资源。否则，您将继续进行sprint并交付可运行对象-与任何项目相同。

正如有人在宣言之前指出的那样：

个人和过程中的互动

我建议您看看所提出的计划并提出对它的修改建议。请记住，宣言说积压永远不会结束，它还在不断发展。

这样您就可以向团队提出建议。如果您有充分的理由并得到小组的同意，那么任何值得他/她投入盐分的产品所有者都将考虑这些理由，并撤消积压的订单，以反映整个团队的意见。

这是它可以通过两种方式进行的工作。

1. 产品负责人和企业都同意您的推理，并且可以选择在截止日期之前增加资源，或者他们可以选择删除某些功能以在截止日期之前完成。

2. 他们可能仍然希望坚持自己的观点，反对团队的集体意见。

如果结果是＃2，则这不是敏捷。

如果您排名第一，那么我会说团队走在正确的道路上，因为敏捷不仅是开发人员“响应变更”，还在于企业能够响应变更。

想象一下，要某人为您粉刷一堵墙，一所房子，然后为整条街道涂粉，您将给该人多少时间来完成？

无论您的答案是什么，您都会错的。而已。

如果他们不问需要做这项工作的人他们怎么想的话，就不可能正确地约会。

顺便说一句，如果您（作为一个团队）接受这些日期，那么您错了。

您应该花一些时间与利益相关者一起进行此计划，以便可以根据完成任务的便捷程度来确定优先级。

例如，也许最终的工作将花费他们认为两倍的时间，但是他们可能比预期的更快使用beta。

总而言之，您不能让别人认为您可以或不可以更快地在Y时间内完成X，这是您有责任在细节和时间方面弄清楚自己需要什么。

它不是敏捷的计划。

但是，如果您假装不知道计划，就只能逐个冲刺地工作。这可能是敏捷的工作。

总会有日期和预算。始终存在错过或超支的风险，一旦发生这种情况，您总是不得不退回到计划B。

如果您一直以敏捷的方式工作，那么计划B有望成为最后一个sprint的演示