敏捷软件开发中的沟通——我们真的在会议上花费了太多时间吗？

[suchona.kani.z]

“软件开发人员三分之一的工作时间都花在会议上，”网上头条新闻 heise 引用了一家日程安排软件提供商的研究。我还一次又一次地注意到，在我的团队中，会议时间通常被认为太长且压力很大。远程工作似乎加剧了这种现象。但这真的意味着我们在会议上花费了太多时间吗？对此我想与大家分享一下我的想法。

很快就能找到建议的解决方案：需要有无会议时间甚至几天的时间，为了让我们坚持下去，必须有一个全公司范围的规定。尽管尝试了这些解决方案，但问题并没有消失。这是一个明确的迹象，表明我们还没有完全理解这个问题，只是解决了症状。

首先，需要注意的是，会议通常是表达合理的沟通需求。防止这种情况的发生就像停止时钟以节省时间或关闭汽车内的机油警告灯（如果它一直亮着）一样有效。

为了不让我误解，会议当然应限于必要的范围，并尽可能有 分时度假业主名单 效地安排、准备和进行。然而，敏捷软件开发中有一些众所周知且经过验证的解决方案，我将在下面解释。然而，效率并不是我们需要回答的第一个问题。因为这只是确保我们正确地做事。如果我们想要高效，我们就必须以正确的方式做正确的事情，并且有很多事情需要考虑。

为了解决这个问题，我们首先应该区分在什么情况下需要进行沟通。我们谈论的是团队内部还是团队之外的协调和讨论，例如与同一部门的其他团队、这些团队的管理层或完全不同的部门的协调和讨论？

敏捷团队的内部沟通
在我们的敏捷团队中，我们依赖典型的会议形式，例如日报、细化、计划、审查和回顾。其目的是在正确的时间以正确的格式可靠地讨论正确的事情。

如果我们的团队不超过建议的八到十人规模，我们只需要注重高效的调度、准备和执​​行即可。个人责任、自组织、拉动原则和时间拳击等敏捷原则对我们有很大帮助。此外，维护良好的冲刺/产品积压或看板与每个人都接受的透明议程一样重要。是的，在我看来，敏捷会议也应该有一个议程，即使它有时看起来微不足道。一些有用的工具，如 Jira、Confluence、Webex、Teams 或物理看板也很有帮助，至少如果我们正确、仔细地使用它们并且可靠地工作的话，如果我们定期进行有价值的回顾，我们就可以不断改进。

通过将预约移至非高峰时间可以提高效率。例如，会议可以安排在早上、午餐之前或之后，或者一天结束之前。但是，您应该确保会议之间有足够的休息时间。您还应该考虑在一天举行与冲刺变更相关的会议，而不是将它们分散在几天内。