与挨饿的开发团队怎么办？[关闭]

作为普通开发人员，这很关键，特别是在您迟到的时候。当您是高级开发人员时，团队正在寻求领导才能，那就更糟了。

当大部分团队的工作停滞不前，等待一些关键任务时，其余团队应该怎么做？我们访问关键部分的机会有限，因此无论我们做什么，其他人都将一直在等待。当其他人在寻求关于如何做的建议时，什么是好的答案？

改进单元测试，功能测试，文档，工具等。在等待关键路径赶上之时，有很多事情可以在停机期间完成。

虽然我喜欢关于改善测试，文档等的答案，但它也是一个不错的选择，您还可以查看：

• 协助关键路径部分，团队/伙伴编程会更快吗？
• 将关键组件重组为每个人都可以使用的几个子组件。
• 用一些可能粗糙的东西来模仿关键部件，这些东西基本上可以完成相同的工作，但可能不够快以至于无法生产。
• 为关键组件建立一个API，或多或少地加以修复，并帮助实现该组件的基本功能（取决于实现的变化，但不受API的影响）。
• 查看是否可以使用关键组件的早期已知问题版本在系统的其余部分上正常工作，而该系统的其余功能“目前已经足够好”。

最好现在就开始“吸取经验教训”，方法是记录这些关键组件需要在开发过程中较早地启动，可能要在团队其余成员组装之前就开始。

您需要后期备份的备份计划

如果关键片段已经迟到，则无法保证它不会继续滑动。然后怎样呢？你只是永远等待？这不是您要告诉高层管理人员的答案。

建立一个模拟器

一种管理风险的方法是开始在模拟器上进行工作（线束，垫片，桩头，无论您要称呼什么），以代替丢失的关键零件。

它有定义的接口吗？实施它。

它有详细的文档吗？尽可能地模仿它。

这只是一个人的主意吗？看看是否可以获得原型。

然后，当他们再次拖延时间表时...

这样，当他们再次拖延日程时，您的后口袋就会有一张王牌来缩小差距。不仅您的团队不受阻碍（他们可以与模拟器集成），而且您将获得宝贵的软件资产。

如果他们拖延进度，请花点时间编写自动化集成测试（暂时针对您的模拟器）。这样，当他们交付真实的东西时，您可以运行测试并检测模型与交付物之间的任何行为差异。这将使您在必须修改的位置归零。作为奖励，您会很快了解到随着时间的流逝，他们偷工减料的程度。

如果关键组件具有已知的接口，并且如果没有希望在短时间内完成该接口，那么为什么不构建一个测试倍数（例如模拟）呢？

尽管测试结果的意义不大，但这将允许团队进行编码。

除了显而易见的“要做到目前为止您没有做过的所有事情”，听起来您和您的团队都缺乏安心去做任何与后期项目无关的事情。这是可以理解但没有帮助的。

因此，真正的问题可能是对此有所放松。我并不是说冷漠。意识到自己的责任，可以做些什么来帮助自己，如果这让您腾出时间来，请尽情享受。您既不能也不必一直保持警惕。如果您是领导者，我想这应该是您的信息。重要的是，将您的紧张感传递给团队不会使团队更有生产力。

您没有说您使用的是哪种方法，很难准确地提出建议。

如果有阻滞剂，我在哪里工作，竭尽全力加速发展。

考虑一下您是否可能遇到更广泛的问题，因为牵头承担的过多。是的，人们会向您寻求技术领导，但这并不意味着您的一些更有能力的团队成员如果受到指导，就无法分担工作量。

除此之外，还有其他非关键工作可以继续吗？此外，他们是否完成了可以进一步完善的任何工作（重构，消除技术债务，文档，添加测试等）。

如果真的没有什么，给他们一些东西-遍历日志，构建，文档，测试计划，设计，图表，编写议程，安排会议，举行会议，分享知识等。总有事情要做。如果人们愿意坐在公司的硬币上不做任何事情，那应该是逐步升级的，因为他们显然不是团队合作者。