在什么情况下——如果有的话——将程序员添加到团队中实际上会加速已经延迟的项目的开发?
16 回答
确切的情况显然对您的项目非常具体(例如开发团队、管理风格、流程成熟度、主题的难度等)。为了更好地界定这个范围,以便我们可以用任何东西来谈论它,而不是过于简单化,我将重申你的问题:
在什么情况下(如果有的话),将团队成员添加到延迟运行的软件开发项目会导致实际交付日期的减少,其质量水平与允许现有团队工作直到完成的质量水平相同?
我认为有很多事情是必要的,但还不够,这会发生(没有特别的顺序):
- 拟添加到项目中的个人必须具备:
- 至少对项目的问题域有一个合理的理解
- 精通项目语言以及他们将用于完成任务的特定技术
- 他们的熟练程度必须/不/分别比最弱或最强的现有成员少得多或多得多。软弱的成员会因第三个问题而耗尽现有员工,而过于强大的新成员会因为他们所做和正在做的一切都是错误的而扰乱团队。
- 具备良好的沟通能力
- 积极主动(例如能够独立工作而无需刺激)
- 现有团队成员必须具备:
- 高超的交流技巧
- 优秀的时间管理能力
- 项目负责人/管理层必须具备:
- 良好的优先级和资源分配能力
- 现有团队成员的高度尊重
- 高超的交流技巧
- 该项目必须具有:
- 一个好的、完整的和文档化的软件设计规范
- 已经实现的东西的良好文档
- 模块化设计,允许划分明确的责任块
- 足够的自动化流程来保证所需缺陷级别的质量。这些可能包括:单元测试、回归测试、自动化构建部署等)
- 团队当前就位并正在使用的错误/功能跟踪系统(例如 trac、SourceForge、FogBugz 等)。
首先应该讨论的事情之一是是否可以推迟发布日期,是否可以削减功能,以及两者的某些组合是否可以让您满足现有员工的发布。很多时候,它的几个功能确实占用了团队的资源,而这些资源无法提供与投资相等的价值。因此,请先认真审查您项目的优先事项。
如果上一段的结果还不够,请访问上面的列表。如果你提前发现了进度表,那么在正确的时间添加正确的团队成员可能会挽救发布。不幸的是,您越接近预期的发货日期,添加人员时出现的问题就越多。在某一时刻,您将跨越“不归路”,没有任何更改(除了发布当前的开发分支)可以保存您的发布。
我可以继续说下去,但我认为我达到了要点。在项目之外,就你的职业生涯、公司未来的成功等而言,你绝对应该做的一件事就是弄清楚你迟到的原因,如果有什么事情可以提前提醒你,以及你需要什么措施采取以防止它在未来。延迟项目通常是因为您是:
- 在你开始之前迟到了(比时间更多的东西)和/或
- 滑倒了 1 小时 1 天。
希望有帮助!
只有当您有一个资源驱动的项目时,它才会有所帮助。
例如,考虑一下:
你需要画一张大海报,比如 4 x 6 米。这么大的海报,你大概可以放两三个人在它前面,让他们平行画。但是,将 20 个人放在它前面是行不通的。此外,除非您想要一张糟糕的海报,否则您将需要熟练的人。
但是,如果您的项目是用现成的打印信件塞入信封(就像您可能赢了!),那么您添加的人越多,进度就越快。分发一堆工作会产生一些开销,因此您无法在只有一个人的情况下获得福利。信封,但您可以从不止 2 或 3 个人那里获得好处。
因此,如果您的项目可以很容易地分成小块,并且如果团队成员可以快速上手(比如……瞬间),那么在一定程度上增加更多的人会使其进展得更快。
可悲的是,在我们的世界上没有多少项目是这样的,这就是为什么 docgnome 关于 Mythical Man-Month 书的提示是一个非常好的建议。
也许如果以下条件适用:
- 新程序员已经了解该项目,不需要任何启动时间。
- 新程序员已经精通开发环境。
- 无需管理时间即可将开发人员添加到团队中。
- 团队成员之间几乎不需要沟通。
当我第一次看到所有这些时,我会告诉你的。
根据 Mythical Man-Month,将人员添加到延迟项目使其延迟的主要原因是 O(n^2) 通信开销。
我经历过一个主要的例外:如果一个项目只有一个人,它几乎总是注定要失败的。几乎每次添加第二个都会加快速度。那是因为在这种情况下,沟通不是开销——这是一个澄清你的想法并减少愚蠢错误的有用机会。
此外,正如您在发布问题时显然知道的那样,神话人月的建议仅适用于后期项目。如果您的项目还没有迟到,那么添加人员很可能不会迟到。当然,前提是你做得正确。
如果现有的程序员完全不称职,那么增加称职的程序员可能会有所帮助。
我可以想象这样一种情况,你有一个非常模块化的系统,而现有的程序员甚至还没有从一个非常孤立的模块上开始。在这种情况下,将项目的那一部分分配给新程序员可能会有所帮助。
基本上神话人月的参考是正确的,除了像我编造的那样人为的情况。Brooks 先生进行了扎实的研究以证明,在某个时间点之后,将新程序员添加到项目中的网络和通信成本将超过您从他们的生产力中获得的任何好处。
- 如果新人专注于测试
- 如果您可以隔离不创建新依赖项的独立功能
- 如果您可以正交化项目的某些方面(尤其是非编码任务,例如视觉设计/布局、数据库调整/索引或服务器设置/网络配置),以便一个人可以从事该工作,而其他人则可以继续使用应用程序代码
- 如果人们彼此了解,技术、业务需求和设计,足够了解他们何时会踩到对方的脚趾以及如何避免这样做(这个,当然,如果不是这样的话,就很难安排了)
只有当你在那个后期阶段有一些独立的(与项目其他部分的交互几乎为 0%)尚未被任何人解决的任务时,你才能在团队中引入该领域的专家。增加一名团队成员必须尽量减少对团队其他成员的干扰。
与其增加程序员,不如考虑增加管理帮助。任何可以消除干扰、提高注意力或提高动力的方法都会有所帮助。这包括系统和管理,以及更平淡无奇的事情,比如吃午饭。
我认为在工作结束时增加人员可能会加快速度,如果:
这项工作可以并行完成。
增加资源所节省的时间比让有项目经验的人向没有经验的人解释所损失的时间要多。
编辑:我忘了提,这种事情不会经常发生。通常它是相当直截了当的东西,比如对表格进行简单 CRUD 的管理屏幕。如今,这些类型的工具大多可以自动生成。
不过要小心那些寄希望于这种工作的经理。听起来不错,但实际上通常没有足够的时间来减少项目的任何重要时间。
显然,每个项目都是不同的,但大多数开发工作可以确保在开发人员之间进行一定程度的协作。在这种情况下,我的经验是,新资源实际上可能会无意中减慢他们赖以加快速度的人的速度,在某些情况下,这可能是您的关键人员(顺便说一下,通常是“关键”人员会占用教育新手的时间b)。当他们赶上进度时,无法保证他们的工作将与团队其他成员一起符合既定的“规则”或“工作文化”。再说一次,它弊大于利。因此,除此之外,这些是可能有益的情况:
1) 新资源的任务很紧张,需要与其他开发人员进行最少的交互,并且需要具备已经展示的技能。(即将现有代码移植到新平台,从外部重构当前锁定在现有代码库中的死模块)。
2) 项目的管理方式可以让其他更高级的团队成员的时间可以共享,以帮助新手加快速度并在整个过程中指导他们,以确保他们的工作与已经完成的工作相兼容。
3)其他团队成员非常有耐心。
- 尚未启动的独立模块
- 缺乏可以集成的开发工具(例如自动构建管理器)
首先,我正在考虑让他们远离当前正在发展的人们的方式。我确实同意 Mythical Man-Month,但我也认为一切都有例外。
我认为将人员添加到团队中可能会比将人员添加到项目本身更能加快项目速度。
我经常遇到并发项目太多的问题。如果我可以单独专注于那个项目,那么其中任何一个项目都可以更快地完成。通过添加团队成员,我可以过渡到其他项目。
当然,这假设您雇佣了有能力、有上进心的开发人员,他们能够继承大型项目并独立学习。:-)
如果额外的资源补充您现有的团队,它可能是理想的。例如,如果您要设置生产硬件并验证数据库是否经过实际调整,而不是仅仅返回良好的结果(您的团队作为领域专家知道的),然后向接下来从事该项目的优秀 dba 借时间对你来说可以加速团队而不需要太多的培训成本
简单的说。它归结为比较剩余时间和从某人那里获得的生产力,不包括额外资源加快速度和提高生产力所需的时间,并减去现有资源投入的教学时间。关键因素(按重要性排序):
- 资源在拾取方面有多好。最好的开发人员可以在几乎没有帮助的情况下进入一个新站点并几乎立即高效地修复错误。这种技能很少见,但可以学习。
- 任务的可分离性。他们需要能够处理对象和函数,而不会绊倒现有的开发人员并减慢他们的速度。
- 项目和可用文档的复杂性。如果它是一个普通的最佳实践 ASP.Net 应用程序和常见的有据可查的业务场景,那么优秀的开发人员可能会立即陷入困境。这个因素比任何其他因素都更能决定现有资源需要投入多少时间在教学上,从而决定新资源的初始负面影响。
- 剩余时间。这也经常被错误估计。通常情况下,我们只剩下 x 周的时间,而且需要 x+1 周的时间才能让某人跟上进度。实际上,该项目将会失败,并且实际上还有 2 周的开发时间要进行,并且尽早而不是稍后获得更多资源会有所帮助。
如果一个团队已经习惯了结对编程,那么添加另一个已经擅长结对的开发人员可能不会减慢项目的速度,尤其是在以 TDD 风格进行开发的情况下。
随着新开发人员对代码库的了解越来越多,他们将慢慢变得更有效率,任何误解都会被他们的搭档或在每次签入之前运行的测试套件很早就发现(理想情况下应该有一个检查至少每十分钟一次)。
但是,需要考虑额外通信开销的影响。重要的是不要过多地淡化项目的现有知识。
当额外开发人员贡献的生产力超过培训和管理这些开发人员所损失的生产力时,添加开发人员是有意义的。