之前是否从团队那里听说过关于 时间盒的 这些？
- “我们所做的不适合 2 周的窗口”
- “我们的工作性质对时间限制来说太有创意了”
- <<<在此填写您的变体>>>
如果您与敏捷团队一起工作，就会熟悉这些陈述的某些变体。当我组建新团队时，我总是听到新团队一遍又一遍地这样说。
事情是这样的，问题不在于时间限制。事实上，时间盒正在暴露你需要解决的问题！
让我们看看上面团队的时间限制投诉的一些例子。
“我们所做的不适合 2 周的窗口”
一个可能遇到此问题的示例团队是一个因纪律而孤立的团队。我目前正在与一组适合这种模式的敏捷数据团队合作。团队成员非常专业。
他们有：
- 通过建模和数据流的数据架构
- ETL
- 数据分析
- 在 Scala 和 Java 中编码
- 数据分析
- 数据仓库
- 存储过程
- 测试与自动化
- 报告
- 部署
- 可能还有一些我什至不知道的事情
总的来说，这些能力构成了一个跨职能团队。在该团队内部，他们通常按顺序执行这些任务，等待彼此完成。难怪他们无法将任何东西放入冲刺中！
解决这个问题
该团队正在寻找并行工作的方法。这感觉很像这些连续项目中的每一个的合同设计。
为了使这更快
团队将进行更多概括，将无法通过合同方法分解到设计中的工作集中起来。
蜂拥而至需要团队成员学习如何保持他们的专长，同时学习如何利用团队所需的另一项能力来提供帮助。这并不意味着要成为两者的专家，保持理智。所以，“如果我了解 ETL，我可以学习帮助数据分析或存储过程吗？”
我们再来看一个常见的。
“我们的工作性质对时间盒来说太有创意了”
关于创意……人们普遍认为，产品开发中的大多数学科都是该学科的创意。
我们都这样看待自己。有一种自然的倾向，想去某个地方，发挥创造力，然后带着我们的创造回来。然而，反馈的重要性在真正的创意环境中最为明显。
让我们考虑一家创建其品牌标识的公司。该 品牌 将对客户如何挑选公司或竞争对手产生重大影响。即使在这种环境下，我们也不希望有一支球队在 3 个月后带着一些错失目标的镀金标志离开并卷土重来。
解决这个问题
相反，我们希望看到稳步走向成功。通过在围绕它进行协作的同时保持实际的创意属性透明，我们可以保持正在创建的价值的可见性，并决定何时足够好。
变小
多个创意将被纳入时间盒，因为没有人喜欢承诺一件事并在两周后错过它。风险太大，因此他们将其分解为更小的可交付成果。这有利于“创意”和客户。
总结
时间盒不是问题。时间盒暴露问题并鼓励创新以寻找新的解决方案。从我们的冲刺到日常承诺，再到发布计划，您会发现敏捷系统中到处都有时间框。如果你使用类似番茄工作法的方法，那么它几乎无处不在。这是团队实现收益而非问题的关键部分。
