为什么时间限制对你的新敏捷团队来说很糟糕

以前有没有听团队说过这些限定吗?

• "我们所做的不适合两周的时间"
• “我们的工作性质对于时间来说太有创意了”
• <<<在这里填写变量>>>

如果您与敏捷团队一起工作，这些语句的一些变体将是熟悉的。当我组建新团队时，我总是听到新团队一遍又一遍地说这句话。

事情是这样的，问题不在于时间。事实上，时间盒是暴露您需要解决的问题!

让我们来看看上面团队抱怨时间限制的一些例子。

"我们所做的不适合两周的时间"

一个可能存在这个问题的例子是一个被纪律隔离的团队。我目前正在与一组符合这种模式的敏捷数据团队合作。团队成员都是专家。

他们有:

• 通过建模和数据流的数据体系结构
• ETL
• 数据分析
• 用Scala和Java编写代码
• 数据分析
• 数据仓库
• 存储过程
• 测试和自动化
• 报告
• 部署
• 也许还有一些我不知道的事

总的来说，这些能力构成了一个跨职能团队。在团队内部，他们通常按顺序完成这些任务，等待彼此完成。难怪他们不能在冲刺中加入任何东西!

为了解决这个问题

这个团队正在寻找并行工作的方法。这感觉很像为这些连续项中的每一个进行契约式设计。

让它更快

团队将更广泛地围绕着那些不能通过契约方法分解到设计中去的工作。

群集将要求团队成员学习如何保持他们的专长，同时学习如何帮助团队所需的另一种能力。这并不意味着你要同时成为这两方面的专家，保持你的理智。所以，“如果我知道ETL，我可以学习帮助数据分析或存储过程吗?”

让我们来看看另一个常见的。

“我们的工作性质对于时间来说太有创造性了”

关于创意，人们普遍认为产品开发中的每一个学科都具有创造性。

我们都是这样看待自己的。我们有一种自然的倾向，想去某个地方，有创造力，然后带着我们的创作回来。然而，在真正具有创造性的环境中，反馈的重要性是最明显的。

让我们考虑一个公司创建自己的品牌标识。的品牌会对客户如何选择公司或竞争对手产生重大影响。即使在这样的环境下，我们也不希望有一支团队离开，然后带着一些镀金的标志在3个月后失去目标而复出。

为了解决这个问题

相反，我们希望看到朝着成功稳步前进。通过保持真正的创造性资产的透明性，同时围绕着它进行协作，我们可以保持所创造的价值的可见性，并决定何时才算足够好。

让小

因为没有人愿意承诺一件事，两周后就错过了。这风险太大了，所以他们将其分解成更小的可交付内容。这有利于“创意”和客户。

总结一下

时间限制不是问题。时间限制暴露了问题，并鼓励创新以找到新的解决方案。从我们的“冲刺”到日常承诺，再到发布计划，你会发现敏捷系统中到处都有时间盒。如果你使用番茄工作法这样的方法，你每天的每一部分都会用到它。对于团队来说，这是一个至关重要的部分，应该作为一个好处而不是一个问题来实现。