在谈论敏捷时，有无数关于生产力，成功案例🎉和光荣失败🙊的文章
在这个故事中，我想分享一下桶的概念，我们在团队中的使用方式以及从桶中获得的收益。
无论您是练习Scrum，看板还是定义自己的敏捷都没关系-桶系统可以使您受益。
不要与桶估计敏捷实践相混淆 ，我们在这里谈论的是问题类型桶。 您将一路明白我的意思。
我们如何工作？
- 我们是一个小组，负责2种主要产品，每种产品都有：
10个开发人员（包括团队负责人），1个UI / UX，2个QA（自动和手动），1个PO和1个PM。 - 我们正在用2周的冲刺练习Scrum（但是如上所述，它也可以用于看板）。
- 我们的发布训练也是每2周一次，这意味着我们每2周就会将我们所做的工作发送给用户（但冲刺完成与发布并没有耦合）。
- 在开始冲刺之前，团队负责人负责创建新冲刺的范围。
- 我们使用JIRA作为我们的问题跟踪系统。 使用系统，我们将其配置为对每种工作类型都有一个问题类型，就像通常那样：
哪里疼？ 🤕
当我们还是一个很小的团队并且产品还很新时，一切都很好。 大多数事情通常都是这样。 直到我们成长并吸引更多用户时，我们才开始感到在计划冲刺时工作的痛苦。
- 重要任务永远不会完成。
当您处于快速发布状态并且客户总是需要新功能时，留下诸如OR（操作就绪-监视，性能，可伸缩性，弹性等），UX改进，错误，技术负担以及更多。
因为没有适当的系统来定义我们应该花费的时间，所以我们发现自己处于一种需要充斥所有错误或充满技术债务的冲刺中，只是为了确保积压不会被它们阻塞。
结果还导致我们的发展速度变慢，因为每个领域的改进都无法有条不紊地进行。 - 准备下一个冲刺需要很多时间。
团队负责人花费大量时间确定下一个冲刺的优先级。
它涉及与PO进行交谈以了解对他/她而言更重要的事情，然后前往UX来获得其最高优先级，不要忘记QA，因为QA知道我们的最高优先级是什么错误。 所有这些只是在最后一刻从UX听到，以更改sprint，因为他们只是在被询问时才开始考虑自己的优先级，现在他们改变了主意。
简而言之，团队领导做到了所有这一切，这使我们付出了很多！ - 大多数时候，所有利益相关者都感到被忽视。
UX生气的是，对他们而言重要的事情没有落伍，开发人员希望承担更多的技术债务，以便他们可以从系统中删除旧代码，而PO则拉动最终的名片来“赢得”讨论。
猜猜谁从所有人那里得到the？ 你猜对了，可怜的团队领导😢
救援桶🚀
那么什么是问题类型存储桶系统？
- 每个问题类型代表一个存储桶。
存储桶将作为其自己的单个待办事项进行维护。
使用JIRA，我们用适当的名称将每个存储桶表示为未启动的sprint。 - 每个存储桶都有一个存储桶所有者。
例如，PO是用户故事存储区的存储区所有者，而团队负责人是技术债务存储区的所有者。
存储桶拥有者的工作是对自己的存储桶进行积压整理。 这样一来，铲斗始终处于最佳状态并处于优先状态 。 - 始终按照每个存储桶中商定的百分比工作。
我们每次冲刺（或在每次看板积压的梳理会议中看板）都试图保持小组所有利益相关者事先同意的每个工作桶中一定比例的工作。
例如，用户故事应占工作量的50％，技术债务仅占工作量的20％，错误占20％，用户体验改进应占10％。 - 使用您的存储桶进行规划。
将最后2分结合起来可以轻松地准备冲刺，因为团队领导只需要从每个桶的顶部拿走X张顶级门票。
在票证的计划和估算过程中，我们看到在每个铲斗中投入的工作量确实是根据铲斗的百分比确定的。 如果在该冲刺中桶的工作量过多，则将某物踢出，反之亦然。
得到它了！ work它起作用了吗？
好的，现在我们知道了存储桶的定义，存储桶拥有者及其在实际中的工作方式。 现在让我们了解如何解决我们所讨论的问题。
1.准备下一个冲刺需要时间。
在计划需要几秒钟之前准备冲刺！
由于每个存储桶都有优先级，并且团队负责人知道每个存储桶的百分比，所以这只是从每个冲刺中获得X张热门门票的一种方式。
在sprint计划会议之后，将确定在sprint中要处理的最终票证，在那里将对票证进行估算。
这也节省了团队领导的时间，因为每个存储桶都有自己的存储桶所有者，因此并非所有工作都落在糟糕的团队领导上（现在这很高兴🕺）。
2.不同的利益相关者之间总是有被忽视的感觉。
不再！
现在，组中的每个利益相关者都是存储桶的所有者（开发人员由其团队负责人代表），并且是决策的一部分。
由于所有人都接受了所有存储桶的百分比，因此，如果不从存储桶中执行任务，团队就不会再犯错了—存储桶所有者只是没有将其优先级过高，因此，他们决定做某事除此之外，还有给他们的大量工作。
现在每个人都开心happy
3.重要任务永不完成。
好吧，这很明显。
在某些方面，您的运行速度可能会比您希望的慢，但是您仍在加快每个冲刺的进度，因此您知道最终将要做最紧迫的事情。
要注意什么？
💣 不要交易
有时我们发现自己陷入了“交易”的境地。
例如，后端需要完成一项艰巨的任务，这是由于PM提出的新要求而导致的体系结构更改，但是这也有助于加快整个系统的运行速度。
总理来找我们说：
由于确实是为了支持此功能而进行的体系结构更改，并且它使我们获得了更好的性能，因此，如何将“用户故事”存储区中的工作分50％，将“技术债务”存储区中的工作分50％？
最初，它运作良好，我们对自己的行为就像在市场上讨价还价一样making之以鼻。
但是后来事情变得一发不可收拾，太多的任务开始以相同的方式起作用。
我们停止了。
💣不要在人们的脸上扔数字
别忘了，百分比只是建议，是一种指导您进行适合每个人的工作划分的路线。
准备好继续前进，如果您发现数字不符合您的需求（我们已经对其进行了两次更改），则可能需要调整数字。
在某些特殊情况下，可能需要一段时间才能进行更改。 这样的例子可能是市场营销活动，其中急需某些功能，否则您最终将失去重要的客户（只是每次都不相信这个故事）。
结论
问题型水桶对我们来说非常有用！
它使每个人都参与其中，为团队领导节省了时间，并确保您处理工作的各个方面。
这并不意味着它将对您有用。
但是，如果您觉得自己正在处理类似的问题（如我们所遇到的问题），请尝试此工作流程数个冲刺/月，它可能对您有用。
我希望能对某人有所帮助，这就是about的全部内容。
