在截止日期之前添加新的开发人员太可怕了。但是不是吗？

#1 楼

从历史上我们一次又一次地看到，有两种结合软件发行版的两个基本约束的有效方法和两种无效方法：日期和功能。

固定的日期，灵活的功能（又称为“发行版”）准备好了”：您在预定的日期发布，但您只发布有效的发布。这是一种模型，已在Ubuntu，Windows，Linux和许多其他版本中成功使用。
固定的功能，灵活的日期，又称“准备就绪时释放”或“完成时完成”：您确定功能集事先，然后您只需进行工作，直到功能完成即可。一些开源项目以这种方式工作。
固定日期和功能。
灵活的日期和功能。

＃1和＃2在许多不同的项目中都能很好地工作。例如，Ubuntu和Windows均以固定的6个月节奏发布，并具有及时准备发布的所有功能。如果您将节奏进行得足够快，即使某个功能错过了发布，客户也不必等待很长时间才能发布下一个版本。
Linux实际上使用了两个有趣的阶段：是一个新版本，有两个星期的固定时间“合并窗口”，在此期间添加了新功能。当此合并窗口关闭时，到该点为止的所有合并功能部件将被固定，并开始一个“稳定期”，在此期间，固定的功能部件组将被稳定，所有错误都将得到修复，等等。 ，没有截止日期。当一切稳定后，将发布一个新版本，然后重新开始该过程。事实证明，这实际上导致了6-8周的相当稳定的发布节奏，但关键是这种节奏没有得到强制执行，而是自然而然地出现。
请注意，这不会使我的断言＃3无效无法正常工作：Linux开发无法解决日期和功能。他们执行＃1，然后设定截止点并切换到＃2。
＃3始终是一个大问题，尤其是功能列表较大且时间范围较长时。预测未来几乎是不可能的（许多人已经尝试过），因此您的估计几乎总是不正确的。您要么完成了所有功能，要么无聊地坐在那里，不停地晃动手指，或者更有可能的是，您赶在最后期限之前疯狂地尝试在地狱般的死亡行军中完成所有功能。
如果您这样做，它确实可以工作保持功能列表和时间框架足够短。例如。这本质上就是敏捷方法论中的Sprint：在固定时间范围内的一组固定功能。但是，时间范围相当短（通常一个Sprint为一两个星期），并且可以确保快速，即时的反馈和调整。通常，每个Sprint之后都要进行一次Sprint回顾，在此您可以收集Sprint的所有问题和成功经验，并将学到的知识整合到下一个Sprint中。当然还有一次Sprint计划会议，团队将与客户讨论下一个Sprint并商定在该周内要实施的一系列功能。
每周（或每两周一次）Sprint回顾仍然不快尽管有足够的反馈，所以还有一个每日站立会议，其目标与Sprint回顾会议的目标基本相同，除了能够更快地做出反应：检查是否达到了前一天的目标，如果没有达到，请弄清楚什么问题是并解决它。 （请注意，我写的是“什么”问题，而不是“谁”！）
每个Sprint都以有效产品发布为结尾，这一点也很重要，以便客户可以立即开始使用新功能，与他们一起玩耍，对他们有感觉，并为下一个Sprint提供反馈，哪些是好的，什么不是，应该更改的内容，等等。
＃4几乎总是导致功能蠕变的永无休止的发行。 Debian 3和Windows Longhorn是著名的例子，它们有趣地发生在同一时间。两者都没有固定的发布日期，并且两者都没有固定的功能集。 Longhorn用了5年时间，Debian 3.1用了3年时间。在这两种情况下，发生的都是他们不想削减功能，因为较长的发行版意味着人们将不得不等待更长的时间才能在下一个发行版中出现这些功能。但是由于没有削减功能，发布日期进一步下滑，所以他们增加了更多功能，因为否则用户将不得不等待更长的时间，但这导致发布日期下滑，依此类推。甚至更著名的示例可能是ECMAScript4。
那么，您在实际情况中可以做什么？好吧，您目前处于情况＃3，这根本行不通。您必须放宽发布日期或删除功能，以将您的情况＃3变成＃1或＃2。您根本无能为力。
损坏是6个月前造成的，无法神奇地修复。您处于无法在一段时间内交付大量功能的情况，而这两个功能中的一个必须提供。
IFF您可以设法移动发行版，那么您可能有机会扩展团队，但事实是，一旦您拥有5-10名成员，您的速度实际上将不会更快。然后，您必须将其分为两个或多个项目，每个项目都有其自己的功能集，发布日期和团队，但同时还必须协调它们，并在项目和软件可交付成果之间定义稳定的接口。 br />请注意，就罪责而言，问题中提出的三种情况非常不同：

如果适用法律发生变化，则完全有可能在约定的时间交付约定的功能。只是商定的功能对客户没有用。 （这是保持敏捷的另一个很好的理由。）在这种情况下，重新协商项目实际上符合客户的利益，因为如果您仅遵守约定的合同，则他们将不得不支付完全无用的结果。因此，这本质上是一个全新的项目，或者是现有项目的需求变更，都意味着新的价格和新的时间表。
如果首席开发人员被公交车撞到了，罪魁祸首就在项目经理身上。确保总线系数> 1是PM的主要职责。可以提高总线系数的方法包括：集体代码所有权，配对编程，混杂配对，Mob编程，代码评论。
“障碍”有点糊涂。这个问题并没有真正定义这是什么障碍。如果事实证明供应商大大低估了复杂性，那么显然是他们的错。例如，可以通过添加或原型来缓解这种情况。

但是，无论谁搞砸了，我们仍然在同一个地方：我们拥有一套约定的功能，这些功能无法在约定的范围内提供时间，所以绝对没有办法绕开两个必须付出的事实。根本没有“非恐怖”的解决方案。

#2 楼

尽管我在需要与客户合作以及类似的事情上与其他人达成共识，但是如果出于某种原因您真的认为您需要雇用新人-不要雇用开发人员。
您需要做的是与开发人员交谈，找出可以减轻工作负担的其他任务和负担，从而提高他们的生产力：

如果他们上下班时间较长，可以将它们放在附近的一家旅馆中，以便他们减轻了压力。或如果有家人，可以租用汽车送他们去办公室/
协调他们为他们买食物，这样他们就不必担心
减少他们开会的次数和/或时间参加
请确保对更改所需的任何签核都可以进行管理，而不是因为他们不得不等待一天而失去动力。
如果他们既在编写新代码又在支持旧版本，让其他人接管支持任务。 （或至少将它们分类），因此并非全部归开发人员所有。

目标不是增加更多的人员，而是使现有的开发人员在紧要关头尽可能多地工作
但是不要在没有询问的情况下为他们做，因为您需要向开发人员解释您对他们及其工作的重视。如果某人的午餐或通勤时间缓慢，这是在他们思考问题并提出创新解决方案时可能适得其反……因此，如果他们觉得自己没有工作，您还必须给他们灵活性，以取消事情。
如果您确实引进了新的开发人员，则没有时间让他们加快项目速度，因此最好将他们与程序员配对。可能没有足够的时间来使新员工加速项目的真正“配对编程”，但是他们可以提供许多功能-例如行政助理，筛选呼叫和/或访客，获取小吃或为人办事，为“泰迪熊调试”提供一些额外的反馈，作为有经验的程序员的打字员来指导，或者甚至是其他人在编写代码时对其进行审查。
您可以雇用非程序员，但即使他们不懂编程语言（即使是使用IDE），打字技能也没什么用。找到能很好地融合在一起的个性也很重要-您不希望有人拖慢主程序员的速度，问他们“为什么要做（X）”并使他们发疯。您可能需要拥有一个潜在的奴才库，以便程序员可以轮流浏览，直到找到适合的奴才为止。
如果程序员不希望影子/奴才/结对/实习生/助理能帮到您，想调用它，不要强加于他们...但是，如果他们认为它对小组中的其他人很好，他们可能会改变主意。

#3 楼

问题出在其他地方。问题在于您有一个为期八个月的项目的最后期限。
相反，该项目应该是您和客户之间的协作。这意味着，您将无需再制定固定的要求集并尝试在8个月后交付产品，而是要制定动态的要求集，这些要求可以并且将定期更改，而客户可以通过定期部署发现，产品看上去如何现实。有多规律？它可能是每两到三周一次，或者一天可能是几次。
这也意味着您的首次分娩应该非常迅速。也许不是最初的两个星期，但是从项目开始的一个月之内，您仍然应该能够向客户展示一些东西。它不会有很多功能，但是应该有一些功能。对于某些基础设施可能很复杂的项目，显示简单的Hello World已经是一个不错的步骤。
一旦您首次交付，下一个关键时刻就是最小的可行产品或MVP。这是当您交付的内容不包含客户期望的所有功能时，但是如果出现某些完全错误的情况（团队无法继续从事此项目，或者客户没钱了），客户仍然可以使用它。 。例如，对于电子商务网站，MVP应该包括浏览产品并进行实际订购的可能性，但可能不包括创建喜欢的产品的自定义列表，共享产品或发表评论，或通过网络界面要求退款。
通过这种方法，当您终于到了第六个月时，发生了一些不好的事情，这仍然是一个问题，但是并不是一个非常重要的问题。毕竟，您的MVP已经在几个月前交付了；几个月以来，您定期添加了客户优先考虑的新功能（即最重要的功能）。然后，您所需要做的就是将问题告知客户，并在需要时让他确定功能的优先级。

法律发生变化或发现了隐藏的巨大障碍

如果法律的变更意味着要求的变更，则属于客户，通知您现在要求有所不同，并支付额外费用。这种情况在金融部门，医疗保健或会计部门中经常发生。
遇到障碍时，您需要重做项目的大部分，则需要与客户讨论以找到协议。有时，讨论将涉及律师的出席；但这超出了本网站的范围。

#4 楼

让其他开发人员尝试理解项目并编写代码显然会给新开发人员带来大量学习开销，并且需要花一些时间从当前开发人员那里帮助新开发人员充分发挥生产力。
当前开发人员在做什么？
如果不需要“别人”保持生产力，而只有在对当前开发人员有帮助的情况下才做些什么呢？
例如，
当前的开发人员必须：

建造自己的PC
花时间填写时间表
将汽车停在修理厂中
调查他们遇到的数据库性能问题还不知道要使用什么工具？
编写可在所有浏览器上使用的CSS
修复UI中的拼写错误
调查网络运行缓慢的原因
经理正在开会，又有一个特工打电话。
等。

#5 楼

如果“按时”是唯一的选择，则将功能切除，直到可以肯定地实现“按时”。仅在此部署后添加人员。如果它们真的很重要，让他们使用剪切功能。
如果“按时”灵活，那么就不要使用任意的截止日期来激励人们。
如果这些都不起作用，那么您需要一个不同的项目。越早告诉人们越好。

#6 楼

如果需要，您可以再雇用10个开发人员，但是入职时间将延迟他们的有效贡献，增加的团队规模将在事后增加协调工作，此外，如果您需要重新分配当前团队的稀缺时间来解决问题，则可能会放大最初的问题。知识转移。
这里没有神奇的解决方案：您不会及时交付期望的结果。您需要承认这种观点的转变，而不是坚持一个不可能的计划。分享这个现实，并开始与利益相关者讨论一个现实的解决方案：


可以推迟截止日期吗？信不信由你，大多数截止日期都是任意的。并留出一些灵活性。如果您需要加强团队，请考虑到寻找候选人的潜在延误以及建议实际截止日期的入职努力。

可以减少截止日期的范围吗？同意必须绝对及时准备就绪的功能，并考虑到推迟使用的功能暂时不可用的新过渡策略。警告：此选项可能会更加昂贵，因为可能需要进行其他工作（例如，与旧系统的临时接口？）。

还是执行任务不可能？如果既不能质疑最后期限，也不能质疑范围，那么您就必须问自己，是否有必要承受巨大的压力来破坏健康。也许您应该考虑辞职。也许采取这样的决定性步骤甚至可以帮助利益相关者意识到情况的严重性并重新考虑以前的选择。

#7 楼

从过去在大型项目中不太愉快的经历来看：


最好有中间的截止日期（冲刺左右）来交付结果。这使供应商可以根据实际情况调整任何估算值。如果您将项目分为10个交付，而前两个交付延迟了一周，则可以合理地预期最终期限将偏移10个星期。对延迟一周的影响小于延迟十周，并且允许双方修改其计划。交付多个版本向客户展示了他们所得到的并调整了期望。


客户可能会敦促您就固定的期限/范围/质量/成本达成一致，并拒绝对其进行修改。但是，您必须有胆量将其拒绝。基本上，告诉他们我们要么现在修改计划以适合实际情况（例如，关键资源的消失，法律的变更或估计的减少），要么立即停止该项目。最好是半途而废地完成一个绝望的项目，而不是等到最后一分钟才意识到将无法实现目标。


一个巨大的挑战只能用一个巨大的挑战来解决力。项目经理的工作是避免积累巨大的挑战。一个只有一个关键人物的项目是一个问题。如果法律发生变化，由哪一方负责的责任不明确。 TD的积累是一个问题。正如其他人指出的那样，以协作的方式让客户参与项目是合理的。因此，这些问题成为共享解决方案的共享挑战。

#8 楼

众所周知，“为一个较晚的项目增加更多的人力将使它变得更晚”。但这过于简单了，其结果取决于多个因素：

您所拥有的开发人员的经验如何？
添加需要大量指导的初级开发人员与添加
经验丰富的开发人员，他们能够自行研究并弄清事物，并快速上手。
该项目的指定性和文件化程度如何？所有知识是否仅存在于当前开发人员的脑海中，还是新开发人员可以使用表单文档？
项目有多复杂和相互依赖？是否可以划分为更多单独的开发任务？
现有代码的质量如何？它是低耦合的模块化产品，还是一大堆意大利面条？

通过添加更多开发人员，您将获得越来越少的回报，但这并不意味着您不一定会获得零回报或负回报。如果延迟交付的成本很高，那么很值得进行投资。
仍然，增加更多开发人员并不是唯一的解决方案。主要杠杆是：

缩小范围（删除功能或将其推迟到更高版本）
增加时间（即，将截止日期移回）
添加开发人员
加班

每个人都有其风险。例如，加班会带来短期的提振，但收益会递减。增加开发人员是相反的-短期内会降低生产率，但会带来长期利益。
缩小范围绝对是最安全，风险最小的方法。如果您通过了这些要求，可能会发现某些功能不如最初想像的那么关键。与客户协商时，谈论推迟功能通常比放弃它们容易。然后重新考虑发布下一个版本。
您可能希望合并多个版本，例如缩小范围并推迟期限。
重要的是，您首先需要检查滑动的原因。您提到一位主要开发人员遭到公交车袭击。这是一个不可预测的事件，不太可能再次发生。但是在现实世界中，延迟项目的最常见原因是：

范围蠕变
规格不完整/含糊不清
时间估计过于乐观
许多错误和回归
/>
如果您遇到范围蔓延的问题，那么增加时间或更多开发人员将无济于事。这可能只会增加示波器的蠕变速率。因此，您需要先进行管理。
不完整的规范使管理有时限的项目非常困难。一些敏捷项目完全废除了规范，但是值得注意的是，它们没有固定的范围或固定的期限。如果您有固定的范围和截止日期，则还需要一个规范。
如果延迟是因为某些任务比预期的要耗时更多，那么您应该期望其他尚未完成的任务也会超出估计值。