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