想要改善这个问题吗？更新问题，以便将其作为on-topic用于堆栈溢出。
5年前关闭。
Improve this question
我正在为八月份的一次 session 做简短的演讲，我正在寻找内部使用敏捷方法或过去曾尝试过这些方法的开源项目。
我的目标是谈论一些行之有效的方法以及哪些行不通的方法，并稍微推广敏捷方法，因为我认为某些敏捷技术很合适，但在实际开发中似乎并不那么普遍。
那么，有谁知道曾经尝试过敏捷方法和技术的项目吗？我想联系他们几个问题。
更新:
感谢您的回答，我将在接下来的几周内与团队联系。 :-)
(我首先必须准备问题和简介...)
我仍在监视此问题，请随时添加更多答案/项目/...
最佳答案
当然，敏捷支持面对面的交流，大多数开源项目的成员都是分布式的，距离并不能简化交流。这是否意味着您不能在OSS项目上敏捷？我不这么认为。
首先，我要说的是，现代工具可以帮助减少距离带来的通信开销:Skype，电话，电话 session ，视频 session ，协作编辑和审阅工具，邮件，书面文档(甚至旅行)等。如果可以避开距离，那就去做。但这不是阻碍因素。
其次，在我看来，敏捷不是要进行结对编程或站立 session ……这些仅仅是实践，实践不是目的，它们只是一种手段。敏捷更多地是关于原则的:最大化交付的值(value)，同时最小化浪费以提供最佳的ROI (好吧，最后一部分可能不适用于OSS项目，但是您仍然希望向用户或Darwin提供有值(value)的工作软件会让你消失)。给定方法论的实践是在给定背景下实现此目标的一种方式，但对我而言，敏捷还更多地涉及持续优先级，限制Work In Process(即短周期和时间框)，增量交付，反馈循环，高质量(可感知和可实现)。概念上的)，Stop-the-Line文化，构建mistake proof process，足够的规范，足够的及时文档等等。换句话说，不进行结对编程并不意味着您不能敏捷。
回到问题，我认为Ubuntu是一个很好的例子(也许不是严格的编程例子，但它涉及开发):固定日期发布周期(每6个月一次，在这6个月中有几次较短的迭代)，严格地确定要做的事情，没有日期转换(范围会有所变化)，可运行的软件以及所有这些都具有高度分布的贡献者以及大量的技术和语言。检查Ubuntu Development，我很确定可以联系“某人”。
我想到的另一个示例是Sonar。在某个时候，他们每个月都会交付其出色的软件(尽管节奏似乎不再那么规律了)。您可以在SonarSource与开发团队联系，与他们讨论。
关于open-source - 使用敏捷方法或已经尝试过的开源项目，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/3023183/