在敏捷/scrum中战斗票证驱动的开发？

Question

我们的团队有一个非常顽固的项目经理的问题(和好处)。他坚持说，所有关于门票的讨论都是在梳妆过程中进行的。他是根据业务需求从待办事项中选择哪些门票的人，开发人员没有关于哪些方面得到整理的投入。然而，他也不会提前分享关于什么票将被讨论的信息，所以我们将要讨论的总是令人惊讶的。我们不做用户故事票，我们做的‘任务’风格的票，通常细分为UI和API任务内的一个史诗。

这是复杂的事实，我们是一个单一的团队，支持十几个不同的应用程序。

我已经打过了，也输了，让他提前送出他想要覆盖的门票，这样开发者就有时间提前考虑门票和架构的影响。

这就造成了票证驱动开发的问题。最后，我们用很少的体系结构思想和一个代码库来承诺入场券，这个代码库是杂乱无章的，实现细节也在不断变化。

在这种情况下，你会改变什么？

Answer 1

拒绝过早地犯罪。

在你准备好之前，你永远不应该做出承诺。你应该相信你能按时完成这张票。如果你不这么做，那就不要承诺。如果这让你没有票那就去吧。不要比你知道你能做的更多。

你好像在权力斗争中。最好的反应是坚持理性。这支队伍可以同意推迟入场券，直到他们有时间研究它们。但你要明白，你不能决定你在做什么。在Scrum下，您可以决定您愿意在sprint时间框中放什么。即使这只是评价。

回顾是一次会议，在会上正式介绍了这些变化，但要提前与您的团队成员讨论这个想法。如果你不是唯一提出问题的人，那么解决问题就更容易了。

否则，如果你做故事点，计划扑克牌允许这种情况。弹奏？获得提问机会的卡片和强制将故事提升为史诗的∞卡片，直到它以评估故事开始。

如果这样做看起来很长，那么你的冲刺时间可能就太长了。我更喜欢一周的短跑，但你并不总是能得到你想要的。

如果你是唯一一个有问题的人，这一切都行不通，所以和你的队友谈谈