灵活的开发方法是一个太复杂的好主意。 敏捷精简版试图简化这种情况。 您不需要书籍或研讨会来解释Agile Lite。 只需要一点点的小文本。 这是正文。

敏捷精简版非常简单。 只要将工作分为较小的任务（问题），它就可以应用于任何项目。 像其他敏捷方法一样，它使用较短的开发周期-冲刺。 但是与它们不同的是，Agile Lite清楚地认识到软件开发行业中的倦怠现象很普遍，并试图通过引入三周的开发/一周的休息周期来直接缓解这种倦怠。

基本规则：

• 在每个周期的第一周，项目经理，开发人员和其他利益相关者确定即将发生的冲刺。 尽管已经预留了一周的时间，但sprint计划将不超过两个小时，而如果组织得当，则大约需要45分钟。 这是本来就很容易的一周：许多人可以只是放个假去冲浪，绘画或其他。
  
• Sprint会在剩余的三周内运行。 在此期间，工程师从事计划期间分配给他们的任务。 由于员工可以在远程和跨时区分布，因此现场会议并不频繁，并且大多数通信都通过跟踪器（比电子邮件更快地进行）。 像Trello这样的常见看板板很好，而电子表格不太可能。 不鼓励使用日常滑翔机：跟踪器更新完全跟踪了项目的整体脉搏。
  
• 冲刺开始后，您无法将任务添加到冲刺中，但可以将其删除。 这减少了上下文切换，这很好。
  
• 未完成的任务将在下一个sprint计划会话中考虑-并决定将任务移至下一个sprint，将其返回到愿望清单，或将其重新分配给其他开发人员。
  
• 每个任务都在愿望清单或当前的Sprint中。 每个任务需要4到8个小时才能完成。
  
• 如前所述，建议开发人员在计划周内休息，以使大脑从上一个冲刺中恢复。 这不是十字军东征。 开发人员在周末不工作。 所有这些都有助于避免倦怠，这对每个人都很有用。

尽管可以计划sprint中的主要工作，但有时会发生一些意外情况。 这些意外问题称为支持问题。

在sprint计划期间，我们建议分配时间来解决不适合计划的支持任务。 例如，“在下一个冲刺期间，将给戴夫12个小时来解决支持任务（其细节将在以后确定）”。 保持轮换通常很有用，因为负责支持问题的开发人员在每次冲刺时都会发生变化。

为了提高预测的准确性，在每个sprint计划会话中，将分析上一个sprint中实际执行的支持工作量，并决定是否需要花费更多或更少的时间来支持下一个sprint。

实际上，不同的组对支持任务有不同的定义。 也许这意味着客户/客户支持。 也许是其他开发商的支持。 由您决定此通用方法中的哪些元素最适合您的团队。

通过消除不必要的复杂性，Agile Lite是开发软件的最佳，更可持续的方式。 它有助于开发，同时确保始终如一的高水平生产力。

开发人员敏捷精简版

如果您不是这个行业的新手，那么您可能会经历倦怠。 这有很多原因，但是描述倦怠的最简单方法是在太重的压力下长时间努力工作的结果。

这一切都始于一个项目。 每个项目都有详细的规范和截止日期。 规格更改时，截止日期不变。 最后，最后期限到了，规范变得与开始时有所不同。 当然，这被认为是您的错，要求您待到很晚或“延展目标”。 结果，您每个周末都在工作，但是无论您付出什么努力，经理总是会感到不满意，并且该项目总是“落后于进度”。

想要去度假或休假，您会看起来像个懒汉，不支持团队。 您可能在开放式办公室工作； 每个人都知道有人进出的时间，每个人都签署一份不言而喻的合同，以不比别人做得少。 因此，人们知道如何忙碌。 当有人问你好吗，你只要回答：“忙！ 我很忙！”

但是最后，还是发生了一些事情。 您可以换工作，但是这些通常是软件行业中的其他公司。 也许您会全力以赴完成破坏，然后公司放手，因为您已经“不适应文化”。 也许您退出并开始交易汽车，因为编程太令人沮丧了。 俗话说，如果您想失去一种爱好的乐趣，请尝试从中赚钱。

我提供一个解决方案。 这是一种明确设计用于避免倦怠的敏捷形式：Agile Lite。 没有加班工作。 工程工作正在进行中，开发人员有足够的时间来充实自己的大脑。 管理开销最小。

上面的六点几乎描述了整个系统。 可以根据您的目标进行更改。 但我想强调一下敏捷精简版的一项功能。 在这里，我们明确地说：“嘿，灵活的团队会像其他开发方法一样枯竭。 写下明确的规则以防止发动机过热是值得的，这是工程团队。”

让我们停止发动机过热。 我们有很多工作。 实际上，这是一个无底洞。 但是生活太短了，无法将其完全花费在工作，压力和最终的倦怠上。

经理精简版

贵公司的开发人员有问题吗？ 项目是否经常错过最后期限？ 您是否与开始完美，然后逐渐退化然后消失的开发人员合作？ 也许这是一位精疲力尽的程序员。

倦怠在软件行业中非常普遍，这是许多软件项目失败的关键原因。 倦怠最好被描述为与给定项目或组织相关的创伤后应激障碍的症状。 例如，大脑似乎关闭了，仅提及某个项目就会感到极度焦虑。 这是精疲力尽。 处于这种状态的开发人员很可能将无法继续从事该项目，并且在后续项目中将无法充分发挥作用。 倦怠会削弱职业。

这类似于在不添加油或燃料的情况下长时间高速运行汽车发动机。 最后，该引擎将发生故障，很难将其重新组装。

上面已经描述了Agile Lite的基本原理，这些原理可能会根据您的目标进行更改。

常见问题解答+典型声明

敏捷开发领域的唯一一般规则是，每个人都做错事。 @fwip

那么，工程师每年可以休12周的冲浪和绘画时间吗？ 在一个每周六天从9-00到21-00工作成为标准的世界中，这将如何工作？

我认为您的开发人员应尽可能多地休息。

我注意到每周工作40小时曾被认为是一个激进的想法。 谷歌从大型项目的工作时间的80％开始，现在我们有75％的工作时间，我希望到2020年代末将其减少到10％（费里斯法）。

系统996（每周6天从上午9点到晚上9点）是相反的方法，它试图将每周40小时的工作时间延长到72小时。 我认为这是一种回归，我认为我们应该停止迷恋加班。 实际上，它不会提高生产率。

此外，您可以决定在“休息周”该做什么：休假，减轻工作量或其他事情。 答案可能取决于特定的一周。

对于人们而言，“轻松周”也许比“休息周”更容易。 使用对您来说更方便的东西。

冲浪和绘画绝不是强制性的；仅作为示例给出。 我本人甚至不冲浪和绘画。

人们是分配任务还是自己预测要得到什么？

他们预言。 如果您的估计错误，也可以。 这是整个过程的一部分，并且是一个团队。

可以将其称为迭代而不是sprint吗？

当然可以！ Sprint适合我。

是否可以以看板样式进行滑动迭代，其中开始日期和结束日期会有所不同并取决于具体情况？

我真的很感激具有特定开始和结束日期的工作周期的概念，该工作周期由一个任务块定义。 与特定循环不同步的滑动迭代会破坏它。

为什么要冲刺三周？

因为开发和恢复每年放置在13个插槽中。 循环完成后，将开始一个新的循环。 一周的“休息”时间使您可以在开始新的Sprint之前重新启动。 这是为了获得节奏和清晰，一致的时间间隔。

这是否意味着冲刺的开始日期和结束日期通常在日历月的中旬？

是的

开发人员是否参与冲刺计划？

是的 他们不被禁止参加会议。 只是没有必要，特别是如果任务跟踪器运行良好，并且团队在上一个冲刺中讨论了下一个冲刺的一些要点。

我希望减少会议次数。 很少有人喜欢他们。 如果您是其中之一，请不要指望我。

计划冲刺需要一周时间吗？

不，这就是重点。 这是容易的一周。

站起来真的有问题吗？

以我的经验，是的。 通常每个人都围成一个圈，听一个人听20分钟。 当然，这是“错误的”方法，但我从未见过有人做对，而是宁愿完全放弃日常滑翔伞。 当您的团队在地理位置上分散时，这样做甚至更加困难（或至少不方便）。 但是，如果它们对您非常有价值，请不要让我阻止您。

我们应该这样吗？

不行 没有人强迫你做任何事情。 这些是建议，而不是规则。

这不是宗教。

这些规则只有在每周40小时的工作宣传是政治性的意义上才具有政治性。

对您有效的方法可能对其他人无效。 你知道吗

我敢肯定！

经常索赔

您无需对时间进行预测，因为不可能进行估算。

预测被视为预测，而不是血液中签订的合同。 因此，如果不尊重他们，这是正常的。 尽一切努力并尝试以4小时为增量进行预测。

开发人员不能被信任，您需要跟踪他们的所有时间，因为这是完成工作的方式。

我确实不同意，但我无法迅速解释原因。 我们在世界观上存在根本分歧。

这不是敏捷。

当然，敏捷是他的头衔。

这是不现实的。

但是它有效。

您在执行敏捷错误。

不幸的是，敏捷的问题在于它无法正确完成。