小团队的项目方法

我们公司的每个项目通常有1-4名开发人员/艺术总监/撰稿人，您推荐使用哪种方法？敏捷？ XP？争球？还有别的吗？（我知道他们都是基本相同的概念的变体，是的）小团队的项目方法

来源

2008-11-27 thr

我不认为有一个普遍的答案，它的问题太广泛了，你不能只是“采用一种方法论”它是一种您开箱即用的产品，它随着时间的推移而变化......但无论如何，我强烈建议您获取本书的副本：Head First Software Development

然后您将您喜欢的想法修改为你的项目。不要担心名字和流行语，明年他们会全部“过时”。 首先保持简单，采取更有意义的想法，给予最大的回报，而不要试图解决尚不存在的问题。这将是一个非常好的开始。

来源

2008-11-27 15:04:47 rodbv

更新：这是2012年，Scrum和敏捷尚未过时。 – 2012-02-01 20:09:40

更新：2016年至今，仍然没有过时 – Kevin 2016-09-21 12:44:20

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

一个关于小团队的好东西是你不需要很多的支持系统在内部进行通信（错误跟踪器变得或多或少是你自己的待办事项列表，但无论如何都是好事）。如果与整个团队开会只是让你的战车转过身来，并说“嘿，鲍勃和卡尔，看看这个！”，那么你不需要任何正式的方法规则。但总的来说敏捷方法非常适合中小型团队，但他们需要自我激励的团队成员。

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

来源

2008-11-27 15:15:15

根据我的经验，如果实施得当，敏捷方法*创建*自我激励的团队成员。 – 2008-11-27 19:07:55

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

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

来源

2008-11-27 15:50:01 Din

答案是，如谚语所说，这取决于...

每支队伍是个性和能力的混合，每个团队成员是不同的。我建议您不要专注于找到“方法论”本身，而是专注于每个团队成员需要什么才能取得成功，并将其与项目成功的要素结合起来。您会在这两个考虑之间找到正确的方法和流程组合。

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

采用短（60-90天），定义明确的螺旋，这让球队集中精神和交付为导向，帮助我们减少风险。
采用迭代生命周期，在这个生命周期中，我们在螺旋过程中向客户端交付一些增量交付，并讨论我们所做的事情。这样做可以让我们和客户确保我们满足他们的需求。
适合每个团队成员的任务和方向。例如，一个团队成员是一个更初级的开发人员，而另一个团队成员是一个非常优秀的开发人员，但不能很好地处理开放式任务。他们需要不同的方法。

当然，我也定制了CM流程和测试实践以适应项目和团队的需求。

来源

2008-11-27 16:32:19

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

来源

2008-11-27 19:14:41

我的3开发团队只是简单地使用看板+连续部署，它使我们快速移动。我看过Scrum和其他人，而且我们的小团队的开销太大了。

来源

2013-08-14 16:09:40

小团队的项目方法

回答

相关问题