19

在我公司的每个项目中，我们通常有 1-4 名开发人员/艺术总监/文案，您建议使用什么方法？敏捷？经验？Scrum？还有什么？（我知道它们都是本质上相同概念的变体，是的）

4

6 回答 6

11

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

然后你将你喜欢的想法应用到你的项目中。不用担心名字和流行语，反正明年它们都将“过时”。一开始要保持简单，采用更有意义、最划算的想法，不要试图解决尚不存在的问题。这将是一个非常好的开始。

于 2008-11-27T15:04:47.840 回答
5

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

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

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

于 2008-11-27T15:15:15.883 回答
2

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

于 2008-11-27T19:14:41.907 回答
1

我的 3 开发团队简单地使用看板 + 持续部署，它使我们保持快速移动。我看过 Scrum 和其他人，我们的小团队有太多的开销。

于 2013-08-14T16:09:40.507 回答
0

他们非常接近业务方面，这是一件坏事，因为程序员通常不能很好地理解会计、时间或风险管理等方面的含义，即使他们认为他们知道。他们将商业视为提高其复杂技术技能的另一个有吸引力的机会。由于公司规模较小，在开发团队内部实施复杂的方法可能有点矫枉过正。他们可以自己轻松处理技术问题。他们无法处理的是，如果他们接近商业环境并不意味着他们不再是程序员。

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

于 2008-11-27T15:50:01.693 回答
0

答案是，众所周知，这取决于...

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

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

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

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

于 2008-11-27T16:32:19.067 回答