你好，
我本周想到瓶颈。 瓶颈是软件交付过程中任何可能卡住的点。 想象一下，一个由五个开发人员组成的团队每周都会产生五个新功能。 每种功能在发布之前都必须经过产品所有者的批准，但是他们经常忙于开会，因此每周只能查看一次。 那里我们有一个瓶颈-五到一个瓶颈。
我的大部分工作都涉及解决瓶颈问题，并且有几种解决问题的方法。
选项A-减速
与其让开发人员每周生产五个功能，不如让他们只生产一个功能。 这样，产品所有者就不会感到不知所措，积压的订单也将消失。 从表面上看，这听起来很疯狂，因为这意味着开发人员的生产力明显下降了80％。 但是，当然，如果某个功能没有发布，那么它可能根本就不会开发出来，那么它真的下降了80％吗？ 这个5对1的瓶颈是一个极端的例子，但是通常会减慢您的交付渠道以使其达到最慢的速度，实际上可以使您的交付速度大大提高 。 想象一下一家直通车餐厅。 最终，拿到订单的家伙比最后交出一包汉堡的家伙没有什么意义，您只是阻塞了系统。
选项B-保持瓶颈繁忙
如果我们的产品所有者很少有，那么对于他们来说他们会发现自己有足够的空闲时间，但是对于我们的开发人员来说，还没有为他们准备的一切，那将是绝对的悲剧。
保持瓶颈繁忙意味着增加工作量，以便在有限的资源可用时总能做好准备。 这称为缓冲区。 拥有缓冲区并不意味着我们可以忽略问题并不断堆积东西-我们需要一个可持续的上限，这样我们的产品所有者才有可能实际上偶尔清除积压的商品。
保持足够但不是太充分的缓冲区是平稳，及时交付的关键方面。 需要练习！
选项C —消除瓶颈
我们是否真的需要产品所有者批准所有内容？ 那给我们什么价值？ 一个有用的问题可能是“产品负责人实际上多久拒绝发布一次功能？”如果答案是“从不”，那么他们参与其中的意义何在？
通常，这种人为瓶颈会以变更批准委员会的形式出现，或者对每项变更都进行全套回归测试。 再说一次-他们实际上多久更改一次结果？
希望这给您一些想法，以消除您自己的一些瓶颈。
链接
- 我本周与您分享了一些有趣的链接-敏捷超级明星艾伦·凯利（Allan Kelly）一直在博客中讨论软件的成功是否可能仅仅是随机的。 事实证明可能如此，但这实际上并不重要。 当然值得深思。
- 如果您要启动一个新项目并且对使用哪种技术感到困惑，那么您可能只想使用其他所有人正在使用的任何东西。 关于职位发布中的技术趋势的文章引人入胜。 基本上，答案是“只使用React”。 对我来说似乎是一个可靠的选择。
这就是本周的全部内容-下一次会更多。
耶兹
加快步伐：软件开发顾问Jez Halford每周都会提出有关加速软件团队的想法，该团队帮助团队更快地交付更好的软件。
Jez在 Twitter ， Medium 和 jezhalford.com 上还有更多 内容
