我一个月内就要这个孩子,给我九个女人!

在什么情况下(如果有的话)将程序员添加到团队中实际上会加速已经迟到的项目的开发?

11773 次浏览

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

我可以想象这样一种情况: 您拥有一个非常模块化的系统,而现有的程序员甚至没有在一个非常孤立的模块上使用 开始了。在这种情况下,将项目的这一部分分配给新的程序员可能会有所帮助。

基本上,神话人月的参考是正确的,除了在人为的情况下,像我编造的一个。布鲁克斯先生做了扎实的研究,以证明在某一点之后,为项目添加新程序员的网络和沟通成本将超过你从他们的生产力中获得的任何好处。

  • 尚未启动的自包含模块
  • 缺乏可以集成的开发工具(如自动化构建管理器)

首先,我在思考一些事情,让他们远离当前发展中国家的道路。我同意神话人月,但我也认为有例外的一切。

也许,如果以下条件适用:

  1. 新的程序员已经理解了这个项目,不需要任何提升时间。
  2. 新程序员已经精通开发环境。
  3. 将开发人员添加到团队中不需要管理时间。
  4. 团队成员之间几乎不需要沟通。

我第一次看到这些的时候会告诉你的。

只有当您有一个资源驱动的项目时才会有帮助。

例如,考虑以下情况:

你需要画一张大的海报,比如4米乘6米。一张这么大的海报,你可以让两三个人站在前面,让他们平行画。然而,让20个人站在它前面是行不通的。此外,你需要有技术的人,除非你想要一个蹩脚的海报。

然而,如果您的项目是塞满信封准备打印的信件(如 你可能会赢!) ,那么您添加的人越多,速度就越快。发放成堆的工作是有一定的开销的,所以你不可能在一个人公关的情况下获得福利。信封,但你可以得到的好处远远超过只有2或3人。

因此,如果你的项目可以很容易地分成小块,如果团队成员可以很快地跟上进度(比如... 瞬间) ,那么增加更多的人将使它更快,在一定程度上。

遗憾的是,在我们的世界里,没有多少项目是这样的,这就是为什么 docgnome 关于人月神话的建议是一个非常好的建议。

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

只有当你有一些独立的(几乎0% 的互动与项目的其他部分)任务尚未处理的任何人,你可以把团队的人是该领域的专家。增加一个团队成员必须尽量减少对团队其他成员的干扰。

我认为在工作快结束的时候增加人手可以加快进度,如果:

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

  2. 增加的资源所节省的时间比让有项目经验的人向没有经验的人解释事情所损失的时间要多。

编辑: 我忘了说,这种事情不是经常发生的。通常它是相当直接的东西,像管理屏幕做简单的 CRUD 到一个表。如今,这些类型的工具大多是自动生成的。

尽管如此,还是要小心依赖这种工作的经理们。这听起来很棒,但实际上通常没有足够的时间来削减项目的任何重要时间。

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

在什么情况下(如果有的话) ,将团队成员添加到一个迟到的软件开发项目中,会导致实际发货日期的减少,其质量水平与允许现有团队工作到完成时的质量水平相同?

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

  • 拟议加入项目的个人必须:
    • 至少对项目的问题领域有一个合理的理解
    • 熟练掌握项目的语言以及他们将用于指定任务的特定技术
    • 他们的熟练程度必须/不/远远低于或远远高于最弱或最强的现有成员分别。弱小的成员会用第三级的问题耗尽你现有的员工,而一个太强大的新成员会用他们所做的和正在做的一切都是错误的来扰乱团队。
    • 有良好的沟通技巧
    • 积极性高(例如能够独立工作而不受刺激)
  • 现有团队成员必须具备:
    • 优秀的沟通技巧
    • 优秀的时间管理技巧
  • 项目主管/管理人员必须具备:
    • 良好的优先排序和资源分配能力
    • 得到现有团队成员的高度尊重
    • 优秀的沟通技巧
  • 该项目必须具备:
    • 一个好的、完整的、有文档的软件设计规格
    • 对已经实现的内容进行良好的文档记录
    • 一个模块化的设计,让明确的大块责任可以分割出来
    • 对于所需的缺陷级别,有足够的自动化过程来保证质量。这些过程可能包括: 单元测试、回归测试、自动化构建部署等等
    • 一个 bug/特性跟踪系统,目前已经被团队使用(例如 trac、 SourceForge、 FogBugz 等)。

首先应该讨论的事情之一是,是否船期 可以被推迟,功能是否可以削减,如果两者的一些组合将允许您满足发布与您现有的工作人员。很多时候,一些特性确实占用了团队的资源,并且不能带来与投资相等的价值。因此,在做任何事情之前,应该认真审查项目的优先级。

如果上面段落的结果还不够,那么访问上面的列表。如果您及早发现了日程表错误,那么在正确的时间添加正确的团队成员可以保存发布。不幸的是,越接近预期的发货日期,增加人员就会出现越多的问题。在某一点上,您将跨越“无法返回的点”,即任何数量的更改(除了发送当前的开发分支)都不能保存您的发布。

我可以一直说下去,但我想我已经说到重点了。在项目之外,就你的职业生涯、公司未来的成功等等而言,你一定要做的事情之一就是找出你迟到的原因,如果有什么事情可以早点提醒你,以及你需要采取什么措施来防止它的发生。一个迟到的项目通常是因为:

  • 在你开始之前迟到了(更多) 物而非时间)及/或
  • 下滑1小时,1天的时间。

希望能帮上忙!

显然,每个项目都是不同的,但是大多数开发工作可以确保在开发人员之间有一定数量的协作。在这种情况下,我的经验是,新鲜的资源实际上会无意中拖慢他们所依赖的人的速度,在某些情况下,这可能是你的关键人物(顺便说一句,通常是“关键”人物会花时间来教育一个新手)。当他们跟上 的速度时,并不能保证他们的工作能够与团队的其他成员一起适应既定的“规则”或“工作文化”。所以,它可能弊大于利。除此之外,这些情况也许是有益的:

1)新的资源有一个紧张的任务,需要与其他开发人员的最低限度的互动和一套已经演示过的技能。(即。将现有代码移植到一个新平台,从外部重构当前锁定在现有代码库中的死模块)。

2)该项目的管理方式是,其他更资深的团队成员可以分享时间,以帮助提高新手的速度,并指导他们一路上,以确保他们的工作与已经完成的工作兼容。

3)其他队员都很有耐心。

根据人月神话,将人员添加到后期项目中会使项目推迟的主要原因是 O (n ^ 2)通信开销。

我经历过一个主要的例外: 如果一个项目中只有 人员,那么它几乎总是注定要失败的。加上第二个,几乎每次都会加快速度。这是因为在这种情况下,沟通不是 在头顶上——这是一个有益的机会来澄清你的想法,减少犯愚蠢的错误。

另外,当你发布你的问题时,你显然知道,来自人月神话的建议只适用于 很晚了项目。如果您的项目还没有迟到,那么很有可能增加人员不会使项目迟到。当然,前提是你做得对。

我认为将人员添加到团队中可能比将他们添加到项目本身更能加快项目的速度。

我经常遇到有太多并发项目的问题。如果我能专注于那个项目,任何一个项目都可以更快地完成。通过添加团队成员,我可以过渡到其他项目。

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

简单来说。它归结为比较剩下的时间和生产力,你将得到从某人不包括额外的时间资源,以提高速度和生产力,减去投入教学的时间用现有的资源。关键因素(按重要性排序) :

  1. 这种资源在采摘方面有多好 最好的开发者可以走路 转移到一个新的网站上,并且富有成效 几乎可以立即修复错误 一点帮助。这个技能是 稀有但可以学习。
  2. 任务的分离性,他们需要 能够在物体上工作 函数,而不会被 现有的开发商和放慢他们 放下。
  3. 项目的复杂性 和文件可用。如果它是 一个普通的最佳实践 ASP.Net 适用范围及常见问题 详细记录的业务场景 那么一个好的开发者就可以 这个因素 比任何人都重要 现有的资源 将不得不投资于教学和 因此初始的负数 新资源的影响。
  4. 剩下的时间,这是常有的事 估计错误。经常 逻辑上来说,我们只有 X 周的时间 需要 x + 1周的时间 让某人跟上进度,实际上 这个项目将会失败 实际上有2周的开发 离开去得到更多 尽快开始资源分配工作 以后会有帮助的。

可以考虑添加管理帮助,而不是添加程序员。任何能够消除干扰、提高注意力或者提高动力的事情都是有帮助的。这包括系统和管理,以及更平凡的事情,如得到午餐。

如果一个团队已经习惯于结对编程,那么添加另一个开发人员 他已经很擅长配对了可能不会降低项目的速度,特别是在使用 TDD 风格进行开发的情况下。

随着新开发人员对代码基础的理解越来越深入,他们的工作效率也会慢慢提高,任何误解都会很快被他们的同伴或者在每次签入之前运行的测试套件发现(理想情况下应该至少每十分钟进行一次签入)。

然而,额外通信开销的影响需要加以考虑。重要的是不要过多地稀释现有的项目知识。

如果额外的资源 互补你现有的团队它可以是理想的。例如,如果您准备设置您的生产硬件并验证数据库是否已经调优,而不是仅仅返回好的结果(您的团队称之为领域专家) ,那么从旁边项目的优秀 dba 那里借用时间可以加快团队的速度,而不需要太多的培训成本

当额外开发人员提供的生产力超过培训和管理这些开发人员所损失的生产力时,增加开发人员是有意义的。