您一定听说过失败/失败项目的典型故事：
现在，如果你被带入＃10那么你的第一步是什么？
更新：首先：感谢大家的谢绝。好吧......我被带进＃10。当我们向客户提出建议时，我是最初的建筑师。然后，不幸的是，由于我被分配到其他地方，我无法承担交付责任。 :)
假设它是现有桌面应用程序的Web化。我现在被带进＃10。遗憾的是，逃跑不是一种选择。我确信这仍然可以通过遵循敏捷的最佳实践来逆转，并且只是想挖掘社区的想法。
更大的问题可能是：如果开发团队没有规范，只有运行应用程序的（基线）代码，原始解决方案要求查看代码并动态提取业务规则。现在，没有经验的程序员不愿意看VB 6.0代码并想要文档！那么如果你要实现敏捷流程，你如何解决这个问题呢？
Vyas，我觉得我可以写下这个问题。我之前的工作涉及恢复一年后开发失败的KVM项目。规格以用户手册和开发人员使用类似产品的形式出现。我最后教C到3个汇编程序员并从头开始重新构建。我们在4个月内将产品成功推向市场。 （然后我辞职了。去看看。）
我要做的一些事情，特别是对于缺乏经验的团队：
1.一支缺乏经验的程序员团队全天候工作 10.没有能够承担技术问题的技术领导/牛仔编码员
8.里程碑错过后的里程碑 9.由于没有人同意实际需要完成的工作量，团队无法提出交付日期 客户尖叫他甚至不能做基本的东西（保存/查询）等。
程序员过去常常按照规范进行即兴创作 6.在实践中没有遵循在纸上看起来不错的架构文档
2.修复错误只是为了引入新的错误 5.没有自动化的单元测试会对情况产生影响
7.使用的第三方组件首先成为未经过健身测试的瓶颈
一般建议：
祝你好运 - 请让我们发布！
如果你真的必须让它走上正轨（如果不能选择bailing）
首先接受管理层的失败。然后，您可能希望继续实施严格但轻量级的流程。
我建议采用某种形式的敏捷，因为没有GURU最容易成功实施，但你必须非常严格，包括配对，无情重构，评论，尖峰功能，可视性，TDD，一周周期， 8小时工作日（是的，超过8小时往往会伤害生产力而不是帮助，正如您似乎注意到的那样）......
也不要削减任何东西。敏捷的部分依赖于其他部分 - 没有配对，重构和测试，你无法消除前期设计（最大的敏捷失败之一）。
不要忘记它的管理方面。一周的迭代开始（每周演示）。不断适应。每天都很短的站立来解决问题。 （保持最多15分钟，表更长的问题等）Burndown图表，核心团队与客户端。
你不能每周都有15分钟的会议和2周的迭代，并称之为敏捷，但如果你做得对，它可能会给你一个机会。您可能会有一位优秀的敏捷顾问为您提供入门培训。
此外，不断评估哪些有效，哪些无效。准备好修复不起作用的东西。每周会议分析那几周的发展成功和失败。
总体而言，它可以发挥作用，并且可以让一支岌岌可危的团队投入使用，但这并非易事。最好的部分是你可以实现它而不需要从你当前的开发中抽出大量的时间。你只是继续发展，但你做得更好。
严峻的形势，你没有客户信任，在这种情况下基本上无法成功，无论如何。
对于所有意图和目的，项目需要重新启动;令人遗憾的事实是，工厂通常不会让这个机会重新开始并重新评估那里的一切。
我不想这么说，但是你需要停止开发并花一个月的时间来解决出错的问题......
结果需要成为一个可行的6个月 - 1年交付的计划，真正使他们专注于必须具备的东西以及对您的第三方组件的真实贸易研究。并且破坏代码库需要是一个选择;启动一个新的源代码控制项目，当你到达一个特定的模块端口peices有意义并留下垃圾。
敏捷是伟大的，所有的，一旦你得到一个真正的计划，一个有效的方法;但它不会修复与客户的破坏关系...或者已经存在的所有垃圾。
阅读完您的经历后，这是关键学习的总结：
格言 1：确保这不是“死亡之月”
埃莉 2：确保交付的内容有效3：重构和Realgin代码库到架构/最佳实践4：了解真正的问题：团队在技术上是否具有竞争力？
肯德尔 5：确保技术领导力的可用性
比尔K. 6：实施敏捷流程（至少自动化单元测试，如果不是TDD，短期迭代可以使进度可见）7：让客户买入8：准备抛出不起作用的东西（一厢情愿）
养兔场 9：确保仍有机会重新开始的团队成员
蒂姆 10：激励团队，并且随着改进变得明显奖励他们
jsl4980 11：您需要从您的团队（大多数人）和客户那里按期购买[这会引发更多问题。如果您的客户询问团队是否有足够的能力坚持您的日程安排怎么办？如果你自己知道团队提出的时间表只是表明他们缺乏理解，那该怎么办？
粥 12：团队是否承诺？ 13：你正式QA吗？
帕特里克 14：重新开始，重新设计并重新构建尚未开发的模块的架构/设计最佳实践。
摘要有14项。你无法做到这一切。那么，第一步是什么？
这是你必须先做的事情 - 改进一件事。
你可以解决质量问题。正式的单元测试，走向TDD可以提供帮助。这可能很难，因为架构问题导致测试速度变慢。
你可以解决架构问题。这可能会更难，因为它可能会涉及无法交付的返工。但它可能会解决质量问题。或者，它可能因基本的测试问题而复杂化。
你可以解决时间表。如果没有其他更正（即质量或架构），您可能无法解决修复计划问题。
我认为人们态度的整体改善来自于一次成功 - 任何成功 - 尽早开始。什么是最低挂的水果？
首先，要解决你可能会失败 - 如果你不能接受，不要接受挑战。这包括成为替罪羊（确实发生了）。管理层不会用这些术语来看待它（即他们没有故意/有意识地'让你起来'）。但这是企业环境的现实;如果你承担责任（通常比那些没有承担更多的工资），那么如果事情没有成功，那么你的头脑是为了阻止。你必须准备好长期坚持下去。我曾经被安置在一个客户网站上8个月来修复一个渐弱的项目。正如您所看到的，其中一个博客海报在发布版本准备好之前花了9个月。
现在，假设你可以在不顾你努力的情况下全部呈梨形，这就是我的建议：
我在这里看到的许多建议都假设了相当高的权力（例如“停止项目正确地重新启动它”或“对新功能说不”） - 你正在启动已经陷入困境的项目，并且作为一名程序员，传统上你会有更少的权力影响变革，然后是真正的经理人。这并不意味着“放弃/不要尝试” - 它只是意味着你必须要有创造力并做一些你通常不做的事情（即使用'软'或人的技能）。
很多人都在这个项目上保释，为山丘奔跑。到目前为止，我已经完成了3个无可救药的迟到项目。我设法修复2，1我无法解决。就个人而言，我不会打扰一个迟到的项目。毕竟，可能发生的最糟糕的事情是你被解雇了:)
如果你从一开始就参与了这个项目，我讨厌说出来，但公司应该取代你（以及整个团队）。
应该由具有实际项目管理流程的合格团队重新分析，并由具有这种情况经验的项目经理领导。
原始程序员都不应该在保存它的“新项目”上工作。他们可以转移到其他项目（他们不必被解雇），但要重新审视项目，每个人都应该被替换。
当然，管理层必须了解并参与项目将比预期更晚的事实。如果管理层不同意这一点（更换团队，找到经验丰富的领导，退后一步，重新开始）那么@Maxim是对的 - 离开那里。
1）我要评估的第一件事是团队中的人是否致力于项目？如果没有，那么做任何其他事情都是毫无价值的。除非我有一支敬业且忠诚的团队，否则没有什么能阻止这场灾难。 2）我会确保团队中有质量保证。 3）为客户提出合理的迭代和增量发布计划。随着我们陷入困境，客户无法很快获得所有东西。根据客户的优先级，我们会经常向他提供较小的功能增量。这将使客户保持参与，因为他看到了一些事情发生了一点点前卫。
首先，它不是关于添加功能，而是关于修复应用程序。不要添加任何新内容。只是重构。对有人要求你在系统中引入的任何新东西说不。
不要试图改进整个应用程序。带上你的团队，让它专注于当时的一个方面，尽可能采用最佳实践，特别是使用单元测试。
仅使用测试驱动开发。在这种情况下，它会立即显示您不理解的行为的哪一部分（如果您不知道要测试什么，则无法编写测试代码。
让老板明白这个情况：这需要时间，金钱，而且会很痛苦。解释为什么，你将做什么，以及你没有别的办法，否则它将再次失败。
最重要的是，不要试图让它第一次清洁。重构你能做到的，但不要指望你第一次改变你正在工作的部分的整个架构。您将不得不多次在整个应用程序上迭代该过程。
没有奇迹。只是方法和耐心。
去过那里，按照以下步骤：
稳定
控制
向前走
逃跑或找一份新工作。这是一个death march，他们需要一个scape山羊。
通常情况下，死亡游行将涉及通过要求团队成员特别艰苦地工作，周末或者试图“在问题上抛出（足够的）身体”而不同的结果，通常导致职业倦怠的绝望尝试来纠正项目的进程。
敏捷重构。确定并优先考虑客户需求，然后在现有代码的简短冲刺中创建最重要的东西。祝你好运男人:)
冻结版本，并开始修复程序问题....优先处理客户投诉（公司的业务部门可以优先处理）并使程序运行。一旦解决了最大问题，请开始清理代码。将任务分配给其他开发人员，并开始对所有新代码实施编码实践。
如果你可以做任何你想做的事情，那么看看真正的问题是什么并处理它们。如果这意味着组建一个新团队从头开始全面开发软件，那就这样吧。但你应该尝试至少修复主要的错误。不要费心引入新功能，它们只会使问题复杂化，并且一个不起作用的程序和不处理问题会导致客户失败。
10号显然是最严重的问题，或者至少是所有其他问题的根源。找一个具有创造力和能力来交付项目的人，让他们自由地做任何事情 - 包括重新开始。
我希望你收到的报酬非常好。无论如何，我的计划将按以下顺序执行：
0）停止在整个团队中添加功能或功能。在执行以下步骤并执行步骤5时，允许解决错误，然后停止错误修复和恢复功能开发：
1）应用我称之为逆向人员配置法：较弱的团队成员会减慢速度越来越快的团队成员，一般来说，迟到的软件项目需要移除，而不是添加。因此，您需要评估团队成员作为个人贡献者的质量。消除团队中较弱的员工，因为可能有一些人。最好通过查看他们的代码并检查他们的错误修复并找出谁使代码变得更糟而不是更好并将其切割为团队来完成。现在不是指导的时候，你需要最好的人来改变在最佳时期“固定”情况。如果你不能解雇他们或重新分配他们，让他们喝咖啡或其他人留下的东西。
2）评估代码本身。识别代码中未构造良好和/或未被很好抽象的区域。如果区域代码构造不好和/或显然对它应该做的是脆弱的，则将其作为重写目标。这一点感觉很痛苦，但从长远来看，它会节省你的时间。重复出现的错误和/或修复历史将有助于识别无法挽救的代码。如果代码区域或模块从根本上构建得很好，但在接口级别上没有很好地抽象，那么它应该适合于重新分解。这将节省大量时间并且是有用的代码。保留重写区域，重新考虑区域和合适区域的列表。
3）定义一个新的合理架构，您相信这将为您最终在功能和特性中的位置提供强大而完整的解决方案。该架构可能不是最佳的开始清洁，但实际上与您希望的位置相匹配。
4）与利益相关者合作，决定什么将使可接受的第一个版本试图为“后期”版本提供尽可能多的功能。也许你不能削减任何东西，但如果可以，现在是时候做了。
5）停止后台错误修复工作并将定义的工作分配给（剩余）团队，以估计其余功能的合理新实施计划。他们需要拥有时间表。汇总时间表并保持相当保守。现在，您可以合理地预测何时可以实现可行且可靠的功能。
6）实现剩余的功能，然后通过解决剩余的错误来加强发布。我假设在这里观察所有正常的良好软件开发实践，如源代码控制，单元测试等。
7）尽可能多地移除障碍物，以尽可能快地让团队摆脱困境。
8）监控问题，并尽可能地将手弄脏。提供在您可以提供帮助的范围内承担更糟糕的问题，并使团队中的所有成员保持高效。
祝好运！
这不再是技术领导，而是现在的项目管理。
你作为技术主管将只是在泰坦尼克号上转移躺椅。所以，如果我是事实上的项目经理，我会怎么做。
1）确定项目发起人和利益相关者 - 包括官方赞助商和实际利益相关者。
2）去他们并要求项目“变暗”一个星期。
3）如果他们不同意，请离开这个项目。
4）如果他们同意，请将项目暂停一周 - 一切都停止。
5）花一周时间与项目中的重要人员交谈，以确定真实的项目状态。
6）在参与这些讨论的同时，开始制定项目恢复计划，强调范围，进度，预算和人员之间可能的权衡。
7）在本周末，确定哪些（如果有的话）可能的项目方案是可行的。
8）将这些场景中的最佳状态反馈给项目发起人和利益相关者，并开始谈判。
9）当商定前进方向时，重新启动项目并祈祷 - 可能不按此顺序。
马克西姆已经指出了常识（退出死亡之旅）。但如果由于未知的原因你想坚持下去，让我用我在类似情况下的经验来谴责你 - 也许它可能会有用。
这是我在一个沉睡的老城区的第一份工作，那里有很好的电脑工作，很难找到，而且大学毕业后我很快就需要一份。我被雇用了因为管理层认为我足够热情并且可能比什么都没有好（我提议带来我自己的补偿，以节省他们给我一台PC的费用，并提供单独工作的经验）
由于死亡行军的情况，该项目已被其创建者抛弃，并在删除代码中的所有注释并执行其他混淆后消失。没人知道win32 / MFC的东西。
我只是开始研究旧纸和铅笔上的代码（大量的摩擦和修正），直到20天之内，我才知道整个代码，包括变量，心脏以及发生的事情。
有了这些知识，我就能够制作一个关键的作品，以前所有人都没有。当然，这只不过是海洋中的一滴水，但它让管理层能够为客户赢得信心“聪明的家伙 - 让他非常困难 - 已经有了x工作 - 你的工作时间会很长”。
一旦客户确信并且我们能够购买一些时间，就会带走一些压力。这给团队带来了一些希望，我们开始好好地挣扎。 6个月后，我晋升为项目负责人，9个月后，我们获得了修复发货（许多进度演示和明显越来越满意的客户）。
如您所见，成功的要素不是直接可复制的。但我总结一下，你需要首先对项目充满希望 - 展示一些进步并赢得信心 - 同行，管理层和客户。一旦到位，技术内容也应该得到纠正 - 没有什么可以取代这部分方程式。
如果这似乎不太可能，那么辛苦工作（哦，是的 - 很多很多像你从未想象过的工作 - 为什么你认为它被称为死亡游行）将是一种浪费，你甚至可以在开始之前放弃。
我别无选择，我热血沸腾，迫切需要一份工作。技术细节，其中某些东西可以发挥作用，并且只是点击到位。我真的通过这项工作赢得了很多善意和自尊，但从长远来看，这只是一个我可以充分沉着地讲述的故事，除了那些知情人士之外别无其他。
对你而言可能会有所不同，但它可供你决定。
祝好运
如果可以的话，逃跑吧。
如果没有，您需要停止所有使项目不稳定的活动 - 包括编码和修复缺陷。
评估你的位置
将需求分解为更小的“里程碑”
阅读一些实用的书籍（Mcconnell的“软件项目生存指南”浮现在脑海中。
找出所有问题和风险。向所有参与者传达所有这些信息。
每件作品一件。
在达到目标时庆祝改进和里程碑。
祝好运。你的情况听起来很糟糕。它可能无法挽救 - 事情必须改变才能变得更好。