小团队的项目方法

Question

我们公司的每个项目通常都是1-4位开发人员/艺术总监/撰稿人，您建议使用哪种方法？敏捷？ XP？争球？别的什么？ （我知道它们都是基本相同概念的变体，是的）

Answer 1

我认为没有一般的答案，问题太宽泛了，你不能只是“采用一种方法论”，好像它是一个你开箱即用的产品，它是你的东西随着时间的推移而发展......但无论如何，我强烈建议你获得这本书的副本：Head First Software Development

然后，您将自己喜欢的想法调整到项目中。不要担心名字和流行语，无论如何它们将在明年全部“过时”。 保持简单一开始，采用更有意义的想法并给予最大的回报，而不是试图解决尚不存在的问题。这将是一个非常好的开始。

Answer 2

对于结对编程，至少，最好有一个偶数个程序员......; P

小团队的一个好处就是你不需要需要许多支持系统来进行内部沟通（bugtracker或多或少会成为你自己的待办事项列表，但它对你来说很好。无论如何）。如果与整个团队会面只是转过你的charir并说“嘿，鲍勃和卡尔，看看这个！”，你真的不需要所有正式的方法规则。但敏捷方法一般非常适合中小型团队，但他们需要自我激励的团队成员。

我会说从不同的方法中选择你喜欢的任何想法，无论如何它们都可以被认为是建议。

Answer 3

对于这样的小团队，我肯定会看到敏捷的软件开发方法。就个人而言，我可能会使用XP，Scrum和Lean的混合物，因为我知道那些最好的。特别是如果您是敏捷新手，XP提供了一个很好的起点，您可以从中找到特定项目的适应性。我强烈推荐“敏捷发展的艺术”一书。

Answer 4

我的3开发团队只使用看板+连续部署，它让我们快速行动。我看过Scrum和其他人，我们的小团队开销太大了。

Answer 5

他们非常接近业务方面这是坏事，因为程序员通常不了解会计，时间或风险管理等方面的影响。即使他们认为他们这样做。他们认为商业是另一个提高其复杂技术技能的有吸引力的机会。由于公司很小，在开发团队内部实施复杂的方法可能有点过分。他们可以轻松处理技术问题。他们无法理解的是，如果他们接近商业环境并不意味着他们不再是程序员了。

我建议实施一些简单的政策，确保纪律并专注于技术方面，而不是与客户讨论技术主题，这是一些程序员非常喜欢的。

Answer 6

答案是，顺便说一下，这取决于......

每个团队都融合了个性和能力，每个团队成员都是不同的。我建议您专注于每个团队成员需要的成功，并将其与项目成功所需的内容相结合，而不是专注于寻找“方法论”本身。您将在这两个考虑因素之间找到正确的方法和流程组合。

作为一个例子，在过去的七个月里，我一直领导着一个小团队（三个全职开发人员和一些兼职UI设计师）。我发现以下做法/程序对我们有用......

• 采用短期（60-90天），定义明确的螺旋式，使团队专注并以交付为导向，帮助我们将风险降至最低。
• 采用迭代生命周期，我们在螺旋式过程中向客户进行一些增量交付，并讨论我们已经完成的工作。这样做可以让我们和客户确保我们满足他们的需求。
• 为每个团队成员量身定制任务和方向。例如，一个团队成员是一个更低级的开发人员，而另一个团队成员是一个非常好的开发人员，但不能很好地处理开放式任务。他们需要不同的方法。

当然，我还根据项目和团队的需求量身定制了CM流程和测试实践。