it-swarm.cn

一个月我需要这个宝宝 - 给我九个女人!

在什么情况下 - 如果有的话 - 确实为团队添加程序员实际上加快了已经很晚的项目的开发速度?

185
Ed Guiness

确切的情况显然对您的项目非常具体(例如开发团队,管理风格,流程成熟度,主题难度等)。为了更好地解决这个问题,我们可以在任何事情上谈论它,但是过于简单化,我将重申你的问题:

在什么情况下,如果有的话,可以将团队成员添加到迟到的软件开发项目中,导致实际发货日期减少,质量水平等于现有团队允许工作直到完成的水平?

我认为有很多事情是 必要 ,但不足以让这种情况发生(没有特定的顺序):

  • 要添加到项目中的拟议个人必须:
    • 至少对项目的问题领域有一个合理的理解
    • 精通项目的语言以及他们将用于执行任务的具体技术
    • 他们的熟练程度必须/不会/分别比最弱或最强的现有成员少得多或多得多。弱势成员会耗尽现有员工的第三级问题,而新人过于强大则会破坏团队,他们所做的一切和所做的事情都是错误的。
    • 有良好的沟通技巧
    • 积极主动(例如能够在没有刺激的情况下独立工作)
  • 现有团队成员必须:
    • 高超的交流技巧
    • 出色的时间管理技巧
  • 项目负责人/管理层必须:
    • 良好的优先级和资源分配能力
    • 现有团队成员的高度尊重
    • 高超的交流技巧
  • 项目必须:
    • 一个好的,完整的,有文档记录的软件设计规范
    • 对已经实施的事物的良好记录
    • 采用模块化设计,可以分割出明显的责任
    • 针对所需缺陷级别的质量保证的足够自动化流程这些可能包括以下内容:单元测试,回归测试,自动构建部署等。
    • 一个错误/功能跟踪系统,该系统目前就位并由团队使用(例如trac,SourceForge,FogBugz等)。

应该讨论的首要问题之一是发货日期 can 是否会被滑动,是否可以削减功能,以及两者的某些组合是否允许您满足现有员工的发布。很多时候,它的一些功能确实占用了团队的资源,而这些资源无法提供与投资相等的价值。因此,首先要对项目的优先级进行认真审查。

如果上段的结果不充分,请访问上面的列表。如果您及早发现了时间表,那么在合适的时间添加合适的团队成员可以节省发布时间。不幸的是,越接近预期的发货日期,添加人员就越多。在某一点上,您将跨越“不归路”,其中没有任何变化(除了运送当前的开发分支)可以保存您的版本。

我可以继续,但我认为我达到了重点。在项目之外,在你的职业生涯,公司未来的成功等方面,你应该做的事情之一是找出你迟到的原因,如果有什么事情可以提前告知你,你需要什么样的措施为了防止将来发生这种情况。通常会发生一个迟到的项目,因为你要么:

  • 在你开始之前(比时间更多的东西)和/或
  • 1小时滑倒,1天。

希望有所帮助!

87
Zach Burlingame

只有拥有资源驱动的项目才有用。

例如,考虑一下:

你需要画一张大海报,比如4乘6米。一张大的海报,你可以把两三个人放在它前面,让它们平行地涂上油漆。但是,在它前面放置20个人是行不通的。此外,你需要熟练的人,除非你想要一个糟糕的海报。

但是,如果你的项目是填充带有现成字母的信封(比如 你可能赢了! )那么你添加的人越多,它就越快。挖出一堆工作会有一些开销,所以你无法获得收益,直到你有一个人的优势。信封,但你可以从不仅仅2或3人获得好处。

因此,如果您的项目可以轻松划分为小块,并且如果团队成员可以快速加速(例如......瞬间),那么添加更多人将使其更快,达到一定程度。

可悲的是,在我们的世界中没有多少项目是这样的,这就是为什么docgnome关于神话人月书的提示是一个非常好的建议。

29

可能符合以下条件:

  1. 新程序员已经了解该项目,不需要任何加速时间。
  2. 新程序员已经熟练掌握了开发环境。
  3. 将开发人员添加到团队中不需要管理时间。
  4. 团队成员之间几乎不需要沟通。

我第一次看到所有这些时都会让你知道。

17
Lost in Alabama

根据神话人月,将人们添加到后期项目的主要原因使得它后来成为O(n ^ 2)通信开销。

我经历过一个主要的例外:如果项目中只有 one person,它几乎总是注定失败。添加第二个几乎每次都会加速。那是因为沟通不是 开销 在这种情况下 - 这是一个有用的机会来澄清你的想法并减少愚蠢的错误。

另外,正如你在发布问题时明显知道的那样,神话人月的建议仅适用于 late projects。如果你的项目还没有迟到,那么添加人员很可能不会在以后制作。当然,假设你做得恰到好处。

11
apenwarr

如果现有的程序员完全不称职,那么添加有能力的程序员可能会有所帮助。

我可以想象一种情况,你有一个非常模块化的系统,现有的程序员甚至没有 在一个非常孤立的模块上启动 。在这种情况下,将项目的这一部分分配给新的程序员可能会有所帮助。

基本上神话人月的参考是正确的,除了像我编造的那样的人为案例。布鲁克斯先生做了可靠的研究,证明在一定程度上,将新程序员添加到项目中的网络和通信成本将超过您从他们的生产力中获得的任何好处。

10
JosephStyons
  • 如果新人专注于测试
  • 如果您可以隔离不创建新依赖项的独立功能
  • 如果你可以正交化项目的某些方面(特别是非编码任务,如可视化设计/布局,数据库调优/索引或服务器设置/网络配置),以便一个人可以处理,而其他人继续使用应用程序代码
  • 如果人们彼此了解,技术,业务要求和设计,那么就足以让他们知道什么时候他们会踩到对方的脚趾以及如何避免这样做(这,当然,如果不是这样的话,很难安排)
5
Leigh Caldwell

可以考虑添加管理帮助,而不是添加程序员。任何可以消除干扰,改善焦点或提高动力的事情都会有所帮助。这包括系统和管理,以及更多平凡的事情,如午餐。

4
JXG

只有当你在最后阶段有一些独立的(几乎与项目的其他部分有0%的互动)时,任何人都没有解决任务,你可以把团队中的某个人带到那个领域。团队成员的加入必须尽量减少对团队其他成员的干扰。

4
Daniel

我认为,如果出现以下情况,那么在工作结束时添加人员可以加快速度:

  1. 这项工作可以并行完成。

  2. 通过添加资源节省的金额超过了让项目经验丰富的人向缺乏经验的人解释事物而损失的时间。

编辑:我忘了提,这种事情不会经常发生。通常它是相当直接的东西,比如管理屏幕可以对表格进行简单的CRUD。如今,这些类型的工具无论如何都可以大部分自动生成。

但要小心那些依靠此类工作的管理人员。这听起来很棒,但实际上它通常没有足够的时间来减少项目的任何重要时间。

3
Giovanni Galbo

显然,每个项目都不同,但大多数开发工作可以保证在开发人员之间进行一定程度的协作。在这种情况下,我的经验是,新鲜的资源实际上可能无意中减慢了他们所依赖的人的速度,使他们加快速度,在某些情况下,这可能是你的关键人物(顺便提一下,这通常是'关键'人教育新词的时间。当他们 正在 达到速度时,无法保证他们的工作将与团队的其他成员适应既定的“规则”或“工作文化”。再说一次,它可能弊大于利。除此之外,这些是可能有益的情况:

1)新资源的任务紧张,需要与其他开发人员进行最少的交互,并且已经证明了这一技能。 (即将现有代码移植到新平台,从外部重构当前锁定在现有代码库中的死模块)。

2)项目的管理方式可以让其他更高级的团队成员分享时间,以帮助新人加快速度并在整个过程中指导他们,以确保他们的工作与已经完成的工作兼容。

3)其他团队成员非常耐心。

3
screenglow
  • 尚未启动的独立模块
  • 缺乏可以集成的开发工具(如自动构建管理器)

我主要想的是让他们远离当前正在发展的人的方式。我同意神话人月,但我也认为一切都有例外。

2
Tom Ritter

我认为将人员添加到团队可能会加速项目,而不是将其添加到项目本身。

我经常遇到太多并发项目的问题。如果我可以单独专注于该项目,那么这些项目中的任何一个都可以更快地完成。通过添加团队成员,我可以转换其他项目。

当然,这假设您已经聘请了有能力,自我激励的开发人员,他们能够继承大型项目并独立学习。 :-)

2
Matthew Cole

如果额外资源 补充 您现有的团队,它可能是理想的。例如,如果您要设置生产硬件并验证数据库是否实际调整,而不仅仅是返回良好的结果(您的团队知道为域专家),那么从下一个项目工作的优秀dba借用时间对你来说,可以在没有太多培训费用的情况下加速团队

2
Oskar

简单的说。它归结为比较剩余的时间和从某人获得的生产力,不包括额外资源加速和提高生产所需的时间,并减去现有资源教学所花费的时间。关键因素(按重要性排序):

  1. 资源捡起来有多好。最好的开发人员可以走进一个新的站点,并在几乎没有任何帮助的情况下立即高效地修复错误。这项技能很少见,但可以学习。
  2. 任务的可分离性。他们需要能够处理对象和函数,而不会绊倒现有开发人员并降低速度。
  3. 项目的复杂性和可用的文档。如果它是一个Vanilla最佳实践ASP.Net应用程序和常见的记录良好的业务场景,那么一个优秀的开发人员可能会立即陷入困境。这个因素将决定现有资源投入教学的时间,以及新资源的初始负面影响。
  4. 剩下的时间。这也经常被错误估计。通常逻辑是我们只剩下x周,并且需要x + 1周来让某人加快速度。事实上,项目IS将会滑落并确实有2个星期的开发时间,并且尽早获得更多资源将有所帮助。
1
JackCorn

当额外开发人员贡献的生产力超过培训和管理这些开发人员所损失的生产力时,添加开发人员是有意义的.

1
Caleb

如果团队已经习惯配对编程,那么添加另一个开发人员谁已经熟练配对可能不会减慢项目速度,特别是如果开发正在进行TDD风格。

新开发人员将逐渐变得更有效率,因为他们更了解代码库,并且任何误解都会很快被他们的对或者每次签到之前运行的测试套件捕获(理想情况下应该是检查至少每十分钟一次)。

但是,需要考虑额外通信开销的影响。重要的是不要过多地淡化项目的现有知识。

1
Bill Michell