长期规划和敏捷？

我的团队最近完成了为我们的工作制定近一年计划的过程。我们将该计划分为三个阶段。每个阶段将包括几次启动。

从您的敏捷角度来看，我想知道这是错误的吗？我认为这不是一个坏主意，因为除了前几个步骤，我们没有花太多时间来设计任何东西。我们有可能改变方向。同时，很高兴我们不要在短期内采取行动。

对项目的去向有一个愿景是Good Thing ^TM。

相信那正是会发生的事情。

“在准备战斗时，我总是发现计划没有用，但是计划是必不可少的。”

-德怀特·艾森豪威尔

敏捷方法论采取的方法是将事物分解为可消化的片段，并在消化完每一片段后重新调整视力。

这意味着您从现在起一年后的终点将不会完全像您现在想的那样。但是，您应该解决清单上所有高价值的项目，并在前进的过程中保持利益相关者的参与度和满意度。

好的，管理层已经提出了一个计划神话。我希望，为您着想，他们不会让您坚持下去。因为看不见，所以我愿意打赌，您的团队将无法完成长期计划所说的任何事情。实际上，如果您达到行业平均水平，您将损失大约2倍。在大多数组织中，一旦给出估计，他们就会成为俱乐部，他们可以随意击败您。

您可能以为我只是愤世嫉俗。毕竟，您只是针对模糊的时间交流了一些未指定的功能，每个人都知道，这些功能的发生可能比预期的慢或快得多，对吧？抱歉，其中大多数可能是正确的，但这并不是人们倾向于听到这些数字的方式。他们听说过约会，而且曾经说过的约会听起来比您说的要扎实得多。此外，如果有沟通链，它将变得更加牢固。一旦外部客户根据您所说的话向销售商承诺了某些东西，您会突然发现这些数字的灵活性远不如预期。而且我保证您低估了所需的时间。

有了明显的提示，我建议您阅读软件估算，以了解一些有关如何真正进行软件估算的知识。您将学到很多关于您做错了什么，以及下次如何做得更好的事情。（在此过程中，您将了解到为什么我如此自信，以至于您高估了自己的工作。）

也就是说，敏捷主要是将流程减少到适合小型团队的程度。通常，减少流程的一个好方法是尝试减少大规模的长期规划，而在短期内规划较小的事物。它还倾向于更诚实-因为您不知道将来会发生什么。但是，这通常不适合较大的业务需求，因此，无论您是否声明自己是敏捷的，有时都需要制定更长的计划。

话虽如此，我强烈建议您发现有关您所沟通的日期的一个关键事实，不幸的是，这些日期很可能会在最后期限被您咬伤后再次出现。事实就是这样。人们关心什么，日期或功能集？这就是我的意思。通常，组织具有重要的特定日期。例如，为会议做准备或在假期高峰之前做些事情。在那种情况下，重要的是释放一些东西，而不是释放某件事是否完整。在其他时候，确实需要一起发布一组功能，而完整性比真正发生时要重要得多。如果您能发现自己所处的状况，那么您的团队将可以更好地计划如何处理（几乎）不可避免的紧急情况。

只要您认为计划仍在进行中，而不是一成不变的，就可以有一个计划。

关键是要定期发布（至少每月一次），收集用户的真实反馈并更新计划根据该反馈。

这意味着您的计划将在项目范围更改时更改。这是一件好事，因为这意味着您的用户已经了解了更多他们想要的东西。

假设由project-management和agile你的意思是Scrum的，这不会是要走的确切方式。

在里面 Scrum角度来看，如果您制定了一个年度计划，则至少应拥有与一年中几个月相同数量的Sprint。因此，您的一年计划变得更加敏捷，因为它可以在两个Sprint之间进行更改。

A的Sprint时间不得超过一个月，在此期间，Team提交将Sprint Backlog Items变为状态Done。

Done在这里是一个重要的词，每个Scrum Team必须有一个完成的定义，即没有要做的工作。当Sprint Backlog Item被完成，这意味着分析，架构和技术文档编写，并且该功能已被彻底的测试（单元测试，集成测试，功能测试...）。

一旦Product Backlog到位，并且优先级较低的项目排在最底层，最重要的项目排在最上，（开发人员）团队Product Backlog Item将根据自己的经验确定每个项目应花多长时间。在这里，您可以确定该项目将需要一整年的时间。考虑到只有Product Owner应优先考虑项目，因为负责投资回报的是谁，或者知道什么对最终用户最重要。此外，团队应评估全面开发功能所需的时间，尽管此处可能存在可重复使用的代码段，并且这些代码可能满足此功能的需要，即避免进一步的复杂性并确定某个项目不应比小组要求的时间更长。产品待办事项不一定是完美的！在过程的这一步，我们可以想到要开发的系统的用户故事的简单枚举就足够了。

在此期间Sprint Planning Meeting，团队将致力于下一个将会发展的东西Sprint，从而创造出一个整体Sprint Backlog。在Sprint Backlog由基于该子集Product Backlog Items的Team在在Sprint年底完成提交。例如，考虑到一个产品待办事项列表包含50个项目，而所有50个项目都需要完成一年，那么团队可能要从产品待办事项列表中选择5个项目，然后用这5个项目创建Sprint待办事项列表。可以根据需要将这5个相同的项目扩展/分解为其他多个项目，从而使团队在修订后可能改变主意，并承诺只从产品待办事项列表中选择5个项目中的4个。

Sprint计划会议结束后，一个月的Sprint会持续不超过8个小时，在此期间，团队不仅致力于完成所选项目的工作，而且还计划如何完成工作为了使团队中的每个人都清楚地知道她/他必须做什么，Sprint应开始工作。为了项目的利益，团队必须具有跨职能职能。

就是说，在当前情况下持续一个月的每个Sprint结束时，Team承诺要做的所有项目都应是可交付的全功能部件，以从产品待办列表中选择的项目为目标。它必须是可交付的，但如果没有必要，则不必交付它Product Owner。

这是在Sprint Review Meeting其中Product Owner需要传唤该Team演示什么是Sprint的过程中完成，它需要知道为什么还没有做到，如果适用，所有的工作是致力于。然后将未完成的工作放回中，Product Backlog并在下一个中使用Sprint。确保这些未完成的项目应包括在下一个Sprint中，除非产品所有者另行通知，以防万一目标发生了变化。但最重要的是，尽管系统的目标在Sprint期间已更改，但除非绝对必要，否则请不要中断它。只有产品负责人有权中断Sprint。

一旦Sprint Review Meeting结束，这应该持续不超过4小时，每月斯普林特（如果我没记错的话），现在是时候去的Sprint Retrospective Meeting。这Sprint Retrospective是必需的Team，以便在Scrum管理员和产品负责人（可选）在场的情况下讨论出现了什么问题，Scrum团队如何提高性能等，并进行相应的调整。

当的时间Sprint Retrospective范围结束时，Sprint Planning Meeting将出现新的内容以计划下一个Sprint并创建新的内容Sprint Backlog。

请记住，Team负责维护，Daily Scrum这是一个15分钟的站立会议，每个团队成员都回答三个问题（不是按照特定的顺序）：

1. 自上次Daily Scrum以来，您做了什么？
2. 在下一个每日Scrum之前，您打算做什么？
3. 自上次Daily Scrum以来，您遇到了什么问题或障碍？

在Scrum Master没有义务在那里，但需要保证团队满足在每日Scrum和各成员正确回答三个问题。

Scrum主管负责其他Scrum团队成员（Scrum主管，产品负责人和团队）遵守Scrum规则。

最后，遵循这些简单的规则，您的开发团队将变得敏捷。敏捷性是指团队能够尽快赶上任何更改的能力，也就是说，在每个Sprint结束时，它都可以了解产品负责人为产品待办事项列表带来的更改。考虑到一个月只有大约20个工作日，如果发生完全灾难并完全改变方向，公司必须承担的最大损失是一个月的开发时间，这是可以忽略的。

如果您需要有关Scrum和敏捷软件开发的更多详细信息，请参考Scrum.org及其Scrum指南。

好吧，这是一个很好的答案！我希望这至少可以帮助您完成项目管理。

编辑＃1

当您计划进行三个或四个阶段时，正如您所说的那样，从主要目标的角度来看，您的团队很可能会失去重点。如果仅在第一季度之后演示您的团队所做的工作，则可能需要进行一些重要的更改，这些更改将需要重新设计和重新思考软件的体系结构，从而可能会损失20多个工作日。敏捷性的原则是能够在变更发生后或在合理的时间内（即对于Scrum而言）在Sprint的时间范围内尽快赶上变更。

1. 我认为您应该拥有尽可能多的发射器。软件开发进度的唯一真实反馈/指标是生产中部署的代码。因此，无论您使用什么过程，实时部署的频率越高，您获得的敏捷性就越高。即，您可以更早地从真实用户那里获得真正的反馈，并且能够更早地适应。

2. 虽然您不应该进行Big Design的前期设计，但我认为每次调整和补充待办事项时都应该考虑全局，这对于Scrum（用于下一个Sprint）和Kanban / flow（如果有空间）在WIP限额内）。如果您考虑整体（产品，服务等），则更容易考虑哪些工作项将为您带来更多的价值。

3. 请注意，全局会发生变化。当您考虑积压，调整优先级等时，还经常考虑对全局的更改。事情会随着时间而变化，包括特定客户甚至整个市场的需求。您的总体情况应该反映出这一点，以便您每次补充积压时都可以将优先事项与现实保持一致，而不仅是在制定计划之初。

总而言之，我认为您检查和适应的越多，您就越敏捷。

大图规划不会花那么长时间，对于大型项目，在定义sprint时要牢记大图至关重要，否则在sprint中采用的快捷方式可能会在以后造成问题。

你应该：

1. 有一个总体规划（最好没有最后期限），随着您的发展，它会不断发展。

2. 定义冲刺时，请确保该冲刺与总体情况一致。这并不总是意味着您改变了对冲刺的期望。有时，您在定义sprint时会发现应该调整全局。总的来说，总体规划和冲刺应该以一种方式相互一致。

3. 总体规划应随您进行调整。您将在工作中学习东西。新机会将出现，计划中的冲突点将出现。您可以随时进行总体规划的调整。但是几乎总是您应该在各个Sprint之间重新访问它-吸收上一个Sprint的经验教训，并确保下一个Sprint与总体情况保持一致。

我认为最好将待办事项和大型项目计划分开构造。大项目所有者将总体规划保持在分级大纲格式中，以维护上下文，然后可以从中提取功能/任务以提供积压，从而积压下一个冲刺。

与总体计划不同，未完成的订单可以由其他团队成员添加。由主要项目负责人确保积压的项目和总体计划保持一致-有时调整积压的项目，有时还要调整总体计划。

这种方法可以保持敏捷的力量，并可以通过总体规划在给定的时间尽最大可能调整项目所有元素的力量。

吉姆

我将在此处添加我的抗敏捷性ant的简短形式。

对于大型项目，敏捷性可能会造成很大的破坏，尤其是在构建将成为未来开发基础的库和框架时。在早期阶段，一个真正重要的问题是“我的设计是否支持我们明年需要交付的功能？”。大多数敏捷策略都不允许这种前瞻性思考，因此会造成项目失败点。

在这一点上，我有点不舒服，因为我自己被这件事烧死了。我们正在重写一些核心库。第一阶段已经完成，并且达到了冲刺的目标。一切都非常敏捷。然后，我被邀请加入一些动态加载功能。但是，我停滞了大约六个星期，因为在假定永远不会动态加载之前编写的内容被浪费了，我浪费了很多时间来重写和处理已经存在的内容。最糟糕的是，动态负载一开始就在规范中。牢记所有未来的需求，并完成了敏捷实践认为不好的“大型设计工作”，我可以在几天内实现我的功能。

课程是，将敏捷用于您愿意丢弃的小事情。有时候可能很棒。但是，这不是一种真正的软件开发方式。在编写具有高风险或使用寿命长的基础代码时，请进行大型设计。