Open source 使用敏捷方法或尝试过敏捷方法的开源项目

我正在为8月份的一个会议准备一个简短的演讲，我正在寻找在内部使用敏捷方法或在过去尝试过敏捷方法的开源项目

我的目标是讨论哪些工作得好，哪些不好，并稍微推广一下敏捷方法，因为我认为某些敏捷技术非常适合，但在实际开发中似乎并不常见

那么，有人知道以前尝试过敏捷方法和技术的项目吗？我想联系他们问几个问题

更新： 感谢您的回答，我将在未来几周与团队联系。：-） （我首先要准备问题和介绍…）

---

我仍在关注这个问题，所以请随意添加更多答案/项目/…

我本以为开源开发模式与敏捷开发模式完全相反。大多数敏捷实践（例如结对编程、站立会议）都要求开发人员在同一地点。在大多数自由和开放源码软件项目中，开发人员在地理上相隔甚远。

Twisted项目使用XP以及一些附加程序，称之为最终质量开发系统：

---

您可以尝试联系XWiki团队

---

他们有一个很棒的产品，它是开源的，Vincent Massol非常了解敏捷实践（尤其是测试），团队是分布式的。你可以试着问他们一些“秘方”；-）

当然，敏捷喜欢面对面交流，大多数开源项目都有分布式成员，这种距离并不能简化交流。这是否意味着你不能在OSS项目上保持敏捷？我不这么认为

首先，我需要说的是，现代工具有助于减少距离带来的通信开销：skype、电话、会议电话、视频会议、协作编辑和审查工具、邮件、书面文档（甚至旅行）等。如果你可以避免距离，就这样做。但这不是一个拦截器问题

第二，在我看来，敏捷不是关于结对编程或站立会议。。。这些只是实践，实践不是目的，它们只是一种手段。敏捷更多的是原则：最大化交付的价值同时最小化浪费，以提供最佳的投资回报（好的，最后一部分可能不适用于OSS项目，但您仍然希望向您的用户交付有价值的工作软件，否则达尔文会让您消失）。给定方法中的实践是在给定环境中实现这一目标的一种方式，但对我来说，敏捷更多的是持续的优先级划分、限制（即短周期和时间框）、增量交付、反馈循环、高质量（感知和概念）、文化、构建足够的规范，只是足够和及时的文档，等等。换句话说，不做结对编程并不意味着你不能敏捷

回到这个问题，我认为Ubuntu是一个很好的例子（也许不是严格的编程例子，但它涉及开发）：固定的数据发布周期（每6个月，在这6个月内有几个更短的迭代），要做的事情要有严格的优先次序，没有日期转换（范围不同），工作软件，所有这些都有高度分布的贡献者和大量的技术和语言。检查一下，我很确定可以联系“某人”

---

我想到的另一个例子是。有一段时间，他们每个月都在交付他们的优秀软件（尽管看起来节奏不再那么有规律了）。你可以联系开发团队与他们讨论。

@Pascal碰巧我是一个多站点项目（阿姆斯特丹/伦敦/新泽西）的项目经理，时间差真的是个杀手——我认为像站立会议这样非正式的会议不可能奏效。结对编程也有同样的问题，只是更糟。我不是说距离容易，我只是说这不是阻塞问题。但是我在评论框里没有足够的空间，所以我在写我自己的答案（还要注意，结对编程不是敏捷的强制性要求，没有什么强迫你使用XP）。@Neil agile不仅仅是结对编程和/或站立会议。当你抽象出这些技术的精髓时，你可以找到帮助ypu实现目标的替代品，比如同行评议和预定的语音或IRC聊天。当然，这不是“通用的敏捷方法”，但即使对于分布式开源项目，您也可以获得许多优势。顺便说一句：马克·夏特沃斯（Mark Shuttleworth）参加了linuxtag，我看到了他的演讲，他希望更多的项目采用更注重质量和发布的方法，这也是我今年在froscon演讲中试图接受的。@Patrick Mark Shuttleworth在我看来是一位伟大的“元产品所有者”当前位置他知道该去哪里，并且在传达他的愿景方面取得了真正的成功（这正是Ubuntu成功的原因）。你能参加他的演讲真是太好了，你要讨论的话题也是如此。祝你演讲好运。我见过一些开发人员和经理使用敏捷/scrum作为规范的完全替代品。这永远不会有好结果。@David我见过一些开发人员和管理人员使用“珍贵”的规范作为工作软件的完全替代品。这永远不会有好结局。顺便说一下，敏捷！=Scrum和敏捷！=没有规范或文档。@Pascal我知道。几年前，我还参与了一个电信项目，花了25万美元以上为一个从未开发过的系统编写规范。我不认为我们需要对每一行奇怪的代码都进行规范，但对我们正在尝试做的事情有一个明确的描述有助于让每个人都保持一致，特别是在一个地理位置不同的团队中。@David我的观点是，敏捷不提倡没有规范，只提倡足够和及时的规范（每个项目之间的差异刚好足够）。所以