我正在为 8 月的会议准备一个简短的演讲，我正在寻找在内部使用敏捷方法或过去尝试过这些方法的开源项目。
我的目标是讨论哪些事情行得通，哪些行不通，并稍微推广敏捷方法，因为我认为某些敏捷技术非常适合，但在实际开发中似乎并不常见。
那么有谁知道以前尝试过敏捷方法和技术的项目吗？我想就一些问题与他们联系。
更新： 感谢您的回答，我将在接下来的几周内联系团队。:-)（我首先要准备问题和介绍...）
我仍在关注这个问题，所以请随时添加更多答案/项目/...
当然，敏捷更喜欢面对面的交流，大多数开源项目都有分布式成员，距离并不能简化交流。这是否意味着您不能在 OSS 项目上实现敏捷？我不这么认为。
首先，我需要说，现代工具可以帮助减少由距离带来的通信开销：Skype、电话、电话会议、视频会议、协作编辑和审查工具、邮件、书面文件，（甚至旅行）等。如果你可以避免距离，那就去做吧。但这不是拦截器问题。
其次，在我看来，敏捷不是结对编程或站立会议……这些只是实践，实践不是目的，它们只是一种手段。敏捷更多是关于原则：最大化交付的价值同时最小化浪费以提供最佳的投资回报率（好吧，最后一部分可能不适用于 OSS 项目，但您仍然希望向您的用户交付有价值的工作软件，否则达尔文会让您消失）。来自给定方法的实践是在给定上下文中实现这一目标的一种方式，但对我来说，敏捷仍然更多地是关于持续优先排序、限制在制品（即短周期和时间盒）、增量交付、反馈循环、高质量（感知和概念），停止线文化、建立防错流程、足够的规范、足够及时的文档等等。换句话说，不进行结对编程并不意味着你不能成为敏捷。
回到问题，我认为 Ubuntu 是一个很好的例子（严格来说可能不是一个编程例子，但它涉及开发）：固定日期发布周期（每 6 个月一次，在这 6 个月内有几次更短的迭代），对要做的事情进行严格的优先排序，没有日期转换（范围各不相同）、可工作的软件，以及所有这一切都由高度分布式的贡献者和大量的技术和语言组成。检查Ubuntu Development，我很确定可以联系“某人”。
我想到的另一个例子是声纳。有一段时间，他们每个月都在交付他们很棒的软件（尽管节奏似乎不再那么规律了）。您可以在SonarSource联系开发团队与他们讨论。