我在业余时间在一个小团队中从事一些项目。我们遇到了一个问题，我们似乎在兜圈子，无法开发我们的产品——但这在我的日常工作中不是问题。缺乏面对面的交流似乎对生产力产生了真正的影响。
开源开发社区使用的软件或方法的任何示例都将受到赞赏。
问问题
1872 次
6 回答
4
如果您阅读大多数开源项目的历史，就会发现它们都是从一个人完成大量初始工作开始的。如果有一个团队，它很小，一个人实际上领导团队。
举一个例子。在 Python 社区中，他们将 Guido van Rossum 称为终生仁慈的独裁者 (BDFL)。他的话（或多或少）是最终的。在许多情况下，有些人不同意他的观点——但为了 Python 社区——他们似乎默认了他的判断。
我认为每个开源项目都有一个（单一的）首席程序员，他确保做出决定并以一致的方式做出决定。
回到过去，Fred Brooks（The Mythical Man Month）描述了“首席程序员团队”。相同的概念。有人负责技术内容。强调一个。如今，我们称其为“建筑师”或类似的术语。
于 2009-04-06T15:05:10.670 回答
3
这里没有真正的方法论，但我认为有两件事很重要：
- 有明确的目标和责任。
- 让每个开发人员对他们分配的部分应该如何完成拥有最后的发言权。
在开源项目中，唯一真正和最强烈的动机是对产品进行编码的乐趣。关于上面的#2，如果人们被告知要做什么，但他们不同意，就会开始缺乏动力。当然，就像在任何其他类型的关系中一样，总会有一些让步。
另外关于面对面的时间，Skype 非常适合举行面对面的会议，我建议至少每周或每月一次（取决于项目的规模和势头）
于 2009-04-06T14:08:04.193 回答
2
我的猜测是您的私人项目都是由开发人员运行和编码的。众所周知，开发人员...继续开发。以我的经验，最大的区别在于，一家公司拥有经验丰富的经理，他们可以定义事情何时完成。我建议让某人负责定义目标并决定何时完成。
于 2009-04-06T14:00:03.760 回答
2
我参加过一些项目，我们的谈话者比开发人员多得多。我的倾向是忽略谈话者并听取编码人员的意见。即使这样，通常也有一个人负责接受补丁。他们可能不得不轻描淡写地处理政治问题，但出于所有意图和目的，他们拥有最终决定权。
Linus 遇到了一些相当著名的问题。请注意 2006 年的这个帖子：Talk is Cheap。给我看代码。
还有一件事。由于您在评论中说您确实有代码，只是进行了很多重写，因此我强烈建议您阅读 Eric Raymond 的The Cathedral and the Bazzaar。Eric 实际上有点疯狂，但这篇文章对于任何想要运行自由软件项目的人来说都是无价之宝。
于 2009-04-06T14:15:05.237 回答
2
这是一个很难回答的问题，因为“开源项目”是一个非常广泛的项目选择。我认为定义特征是项目有一个统一的目标（也许是一组相关的目标）。
你在任何开源邮件列表上吗？我订阅了我最喜欢的发行版的邮件列表，并且开发人员每天都会互相发送多次电子邮件。此外，还有其他沟通渠道，例如 IRC / Instant Messenger。
我不是 RoR 开发人员，但我建议浏览Getting Real以获得一些灵感。
于 2009-04-06T14:22:57.667 回答
1
我会考虑一下你和你的队友在这个项目中的动机和目标。他们是否：
a）创造一个很棒的产品
或者
b) 玩弄软件，学习一些新东西
这两个答案同样有效，我猜这将是一个倾向于其中一个的混合体。
如果更多的是（a），那么请查看有关方法等的建议。甚至可以考虑围绕您的绝妙想法组建一家公司。因为制作这样的东西需要工作......而且你可能会在工作中得到足够的。
如果主要是（b），那么您将很难制作出出色的产品，但会更容易，因为您可以原谅自己没有立即到达那里并遭受多次重写。每次你看到它并一起工作时，你们都会学习新技能，这非常适用于你的长期职业生涯。
首先，我建议你们彼此清楚自己为什么在那里。然后考虑缩减你计划做的事情，尽早发布并经常发布。如果您的项目由三个组件组成并且一个是完整的，那么将其作为一个单独的组件发布并开始构建一个用户社区。这将得到回报，因为这些用户可能会帮助您编写代码，并为完整产品形成坚实的用户核心，并让您尽早而不是稍后评估您的进展情况。
祝你好运。
于 2009-04-08T07:50:48.420 回答