我经常在不同的对话中看到这个问题。 最近，我们在团队内部对此进行了很好的讨论。 主要问题是如何与社区公开沟通，以及如何拥有建立团队和团队合作的空间。 这可能具有挑战性； 例如，当一家公司或赞助商支付一部分贡献者全职从事项目时。
在本文中，我将解释为什么敏捷适用于开源开发模型。
通过透明性构建敏捷性
我对敏捷的理解是它是一种心态，而不是一套流程和工具。 正如引言所说，“不要做敏捷，而是要敏捷。” 那么这种心态的核心价值是什么？
对此问题的答案是 敏捷之心。 这一倡议旨在使敏捷更简单，更人性化。 它强调以下四个价值观
- 协作
- 交付
- 反思
- 改进
图片来源：heartofagile.com
这些与开源价值观兼容——开源的全部意义在于协作和交付协作的成果。 反思和改进有助于我们适应变化，并提供诚实地审视自己的机会。
现在，透明度又如何呢？ Scrum 经常与 三大支柱——透明性、检查和适应一起呈现，尽管这些不仅限于 Scrum，而且可以应用于整个敏捷。
我们可以将这些支柱应用于开源吗？ 当然可以，我甚至可以说这是这些价值观付诸行动的最佳范例之一。
开源开发在开发人员和软件用户之间提供了直接链接。 讨论公开进行，欢迎所有人发表意见。 这使用户感到自己的价值得到体现，从而使他们更多地参与到项目中。
敏捷和开源的核心价值观重叠，那么为什么我们仍然认为敏捷不适用于开源呢？
构建社区就是创造价值
在敏捷中，我们经常谈论创造价值，其主要思想是简化流程并专注于交付。 这样做的一个潜在缺点是，它可能导致团队只专注于交付新功能，而不投入足够的时间来偿还技术债务或构建自动化以促进项目的未来增长。 避免这种情况的一种方法是让团队参与定义创造价值对项目的实际意义。
图片来源：Perry Grones via Unsplash
这与开源有什么关系？ 对于在开源社区中工作的任何团队来说，至关重要的是要理解，构建和关爱该社区可以创造价值。 在开源中，社区是项目的心跳——它提供重要的反馈、支持和文档，并以许多其他方式做出贡献。
因此，无论团队使用什么流程，重要的是为社区建立时间和空间。 邀请人们审查您的用户故事； 毕竟，您的社区中确实有用户。 花时间审查贡献、回答问题、提供支持等。 所有这些都应成为团队活动的一部分，并被视为有价值。
“默认开放”并不意味着 100% 开放
建立团队还需要在其成员之间建立信任。 为了让这种信任增长，团队需要一个安全的空间来进行对话。 在大多数情况下，为了使这个空间安全，它不能向更广泛的社区开放。 这样的空间可以让团队成长、讨论可能的改进并加强良好的内部实践。 如果需要，它也可以用来提供建设性的反馈。
但是，一个重要的警告是——小心不要过度使用那个安全空间。 如果所有对话都默认进入那个安全空间，那么团队就会失去透明度。 团队应提醒自己默认使用开放的沟通渠道，并且仅在需要时使用安全空间。 拥抱“默认开放”的座右铭，可以让团队在何时使用或不使用该安全空间时挑战自己。
因此，当团队认为合适并同意时，您应该考虑与更广泛的社区分享这些对话的输出。 这将维护透明度的实践，同时确保团队和社区之间持续的信任。
您如何看待敏捷和开源的合作？ 在评论中分享您对该主题的经验和想法！
评论已关闭。