我们最多有几个团队成员不能 100% 地在我们的团队中工作。您可能会争辩说这首先是一个坏主意，但假设我们对此无能为力。我与其他团队成员之一进行了讨论，我的论点是燃尽图对我们“撒谎”。让我给你举个例子。
假设我们有一个 sprint，持续 2 周。我们有 6 名成员，其中 2 人只工作 50%。如果两个兼职成员第一周工作 100%，第二周工作 0%，我的论点是 1 周后，燃尽看起来会比实际情况好很多。Scrum 说现在是为 sprint 添加功能的时候了。
我已经看到了另一种方法来做到这一点，你事先输入你有空的日子，然后有一个非线性的理想线。我的第一个建议是即使你不在，也要让占位符被烧掉，但这很快就被击落了。
所以我想知道；我们应该对燃尽图做些什么吗？图表还有用吗？还有其他好的做法可以克服这种障碍吗？
我们目前正在使用 Urban Turtle
关于兼职开发人员 - 显然，这不是一个理想的情况，但实际上并没有太大问题。如果您的一名团队成员想请一天假，并且一周内 40 小时中只有 32 小时有空，Scrum 会失败吗？如果圣诞节期间没有人工作，Scrum 会失败吗？不 - 在两个帐户上。
这是处理您的情况的最简单（也是我认为最好的）方法：您只需将所有团队成员在该 Sprint 中可用于工作的时间加起来，例如，如果您有一个3人的团队，其中一名成员在100%，两个 50%，sprint 是一周，加起来是 40 + 40/2 + 40/2 = 80。这就是团队必须承诺的工作时间。这与您有两个全职成员没有什么不同。
关于燃尽图——我认为绘制一个非线性的“理想”燃尽图既是浪费精力，也是误导。它被称为理想是有原因的。这不是因为你必须努力在这条线上工作，而是为了展示如果你（可以）以恒定的速度工作，燃烧会是什么样子。
请记住该图的功能 - 它用于指示开发中可能存在的问题。并非每一次偏离理想都是坏事。生活并不理想，如果你为差异而烦恼，你就是在自欺欺人（并伤害自己）。事实上，试图解释每一个偏差正是瀑布式著名的失败预测方法，而敏捷方法试图摆脱这种预测方法。
您可能想要做的是记录您所拥有的每一个主要偏差，了解它们并查看您是否可以对它们做些什么，然后调整您的流程。这比尝试对当前状态进行建模要好。
所以要回答最后一个问题——是否有其他好的做法来克服障碍——答案是它不是障碍。通过接受你的现实来克服它，忽略那些是浪费的。
您的情况非常适合在数小时内使用故事点。完成一个故事的相对综合努力对于您的团队随着时间的推移交付价值的能力更有意义，无论历史上在类似故事上花费了多少时间。
关于这种情况，有一个众所周知的轶事使情况发生了翻天覆地的变化。想象一下，您有一个全职团队，并且您确切地知道他们可以工作的时间。想象一下，您的团队拥有最好的 scrum 实践，并且您达到了每个人都同意他们满意的速度。他们现在是否永远受限于这种速度？是否可以想象，如果您为同一团队设定在更短的时间内提供相同速度的目标，并提供简单的提早回家的激励，是否可以实现？
答案是肯定的。事实上，像这样的现实生活场景发生在美国一家主要的软件公司，该团队实际上将他们的工作时间缩短到 16 小时！！是的，16小时！！他们通过不断微调他们对努力的看法来做到这一点。毕竟，如果你花几个小时来比较故事而不是比较复杂性，你如何考虑诸如可重用组件之类的因素或应对从一个功能到下一个功能的意外需求变化？
切换到故事点，你永远不会回头:0)