资源工作模式通过下拉按钮可以很容易地在资源的标题上找到
Original Estimate'模式
选择此选项时，考虑到资源的工作量计划，在任务的持续时间内均匀分配任务的原始估计。
让我们来看看Angela Hambleton的任务分配作为一个例子。她会帮助我们理解事情的工作方式。
Angela被分配到'EVIX-17'任务，估计需要1w 2d（7d 或者56h）
正如我们在下面的截图中可以注意到的，'EXIV-17'的原始估计值均匀分布在该任务持续时间7天内，即每天8个小时，共计7天。
“Original Estimate”模式下，如果任务没有Original Estimate值，则会显示警告（用于勾画任务的红线），当然显示“显示警告”功能要启用。
“Remaining Estimate”模式
在此模式下，会有几种情况
a）工作尚未记录时
如果没有记录任何工作，过去几天的分配将显示为“0”。这些日子在计算工作时是不做计算的。
从当天（3月31日）开始，分配将显示为剩余估计值（在剩余的天数内）均匀分布。在这种情况下，数学可能是：56h / 2d = 24.0h
b）记录工作时
在这种情况下，过去日子的分配将显示为日志工作（1w 1d = 6d = Angela登记了48小时）除以所经过的天数（过去了5天，包括当天）：48h / 5d = 9.6h
从当日（3月31日）开始，分配将显示为剩余天数（4月2日和4月3日）均匀分配的含义：8h / 2d = 4.0h
我们可能想知道为什么我们决定不显示与输入完全一致的日志工作条目 - 为了简单起见。没有任何东西阻止用户在开始日期 - 任务结束日期之外的日子里记录他们的工作。
如果是这种情况，那么此功能该如何知道显示这些条目的方式？例如：
该任务于1月25日开始，但1月20日甚至12月份有一些日志工作条目。如果用户仅在资源的网格中显示1月份，则用户仅会错过12月份的所有条目。
这就是为什么我们决定在过去几天中对所有条目进行求和并将它们平均分配的主要原因，我们相信这样的功能可以为用户提供一个很好的概述，即在任务中投入的平均工作量是多少。
“Remaining Estimate”模式的边缘案例：
- 如果任务没有剩余估计值，则使用原始估计值（如果可用）
- 如果任务完全在将来（开始日期> =今天），则仅显示剩余估计值（均匀分布在任务的持续时间内）
- 如果没有登录工作，则会显示警告- 考虑到“显示警告”功能已启用
- 如果任务完全在过去（今天>结束日期），那么我们只显示日志工作
'Story Point'模式
JIRA估计'EVIX-17'任务将在7个故事点完成，如下面的截图所示：
当选择这种努力模式时，故事与选择“原始估计”模式时相同。这意味着分配在任务的持续时间内均匀分配。
考虑下面的例子，这是一个非常简单的计算公式： 7个故事点/ 7d = 1.0个故事点
虽然故事点速率（Story Point velocity）已经有定义：09-故事点速率，但在我们允许自己在其配置中为“客观释放大量创意（Objectively unleash extensive ideas）”计划（Program）覆盖此值。这这每一个Programs可定义不同的故事点速度时让团队更为的灵活。
“Story Point”模式的边缘情况：
- 如果任务没有Story Point值，则显示警告 - 需要开启“显示警告”选项
我们应该了解在“Story Point”努力模式中选择“显示所有Programr的任务”功能可能会导致收到有关资源容量和分配过多/不足的误导性信息。
以上是可能的，因为根据program，相同的资源可能具有在故事点中表达的不同容量（这反过来是可能的，因为故事点中的容量是基于故事点速度计算的，其可能对于每个Program具有不同的值）。
因此，在显示来自其它Program数据时，每个资源的故事点可能有不同的容量可供选择。在这种情况下，BigPicture总是根据当前Program选择容量，但这时我们需要注意，这可能会导致用户对其他Program的资源分配过多/分配不公平。