如何让失败的项目重回正轨？

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

这个问题似乎与帮助中心中定义的范围内的编程无关。

10 年前已关闭。

Answer 1

在艰难的情况下，您的客户信任度为零，并且在这种情况下基本上无法成功，无论如何。

出于所有意图和目的，该项目需要重新启动； 不幸的是，现有商店通常没有机会重新开始并重新评估现有的一切。

我不想这么说，但你需要停止开发并花一个月的时间找出问题所在......

结果需要是一个可行的 6 个月至 1 年交付计划，真正让他们专注于必须具备的内容，并且对第三方组件的真实贸易研究。 废弃代码库需要成为一种选择； 启动一个新的源代码控制项目，当您到达某个特定的模块端口时，它会有意义并留下垃圾。

敏捷是伟大的，一旦你制定了真正的计划，它就是一种有效的方法； 但这并不能修复与客户之间破裂的关系……或者已经存在的所有垃圾。

Answer 2

以下是阅读您的经验后的关键学习摘要：

Maxim
1：确保这不是“死亡行军”

Ellie
2：确保交付的内容有效
3：重构& Realgin 代码库到架构/最佳实践
4：看看真正的问题是什么：团队在技术上是否有能力交付？

肯德尔
5：确保技术领导力

Bill K
6：实施敏捷流程（如果不是 TDD，至少要进行自动化单元测试，短迭代可以使进度可见）
7：获得客户认可
8：准备好扔掉那些不起作用的东西（抛开一厢情愿的想法）

沃伦
9：确保留下的团队成员有机会重新开始

蒂姆
10：激励团队并随着明显的改进奖励他们

jsl4980
11：你需要你的团队（最重要的）按计划进行支持& 顾客
[这引发了更多问题。 如果您的客户询问团队是否有足够的能力遵守您的时间表怎么办？ 如果您自己知道团队提出的时间表只是表明他们缺乏理解，该怎么办]

Ather
12：团队有承诺吗？
13：你们正式进行质量检查吗？

帕特里克
14：重新开始、重新设计并重新符合尚未开发的模块的架构/设计最佳实践。

Answer 3

摘要共有 14 项。 你无法全部完成。 那么，第一步是什么？

这是你首先要做的——改进一件事。

• 你有根本性的质量问题。 (#2-5)
• 您遇到了架构和组件问题。 (#6, 7)
• 你遇到了日程安排问题。 (#1,8,9)

您可以解决质量问题。 正式的单元测试，走向 TDD 会有所帮助。 这可能很困难，因为架构问题会减慢测试速度。

你可以解决建筑问题。 这可能会更困难，因为它可能会涉及看起来无法交付的返工。 但它可能会解决质量问题。 或者，它可能因基本的测试问题而变得更加复杂。

您可以解决日程安排问题。 如果没有其他修正（即质量或架构），您可能无法解决时间表问题。

我认为，人们态度的整体改善来自于尽早开始一次成功（任何成功）。 最容易实现的目标是什么？

• 一个长期存在的错误？ 一个单元测试套件可以找到并修复该错误？
• 一项主要的建筑特色？ 每个人都可以在自己的多维数据集中发布的图表会有帮助吗？ 一个演示如何澄清事情？
• 一个新的用例？ 一项真正有效的新功能？

Answer 4

这是一本关于这个主题的好书：

灾难解脱：让软件项目重回正轨

Answer 5

首先，要下定决心，你可能会失败——如果你不能接受这一点，就不要接受挑战。 这包括成为替罪羊（确实发生过）。 管理层不会用这些术语来看待它（即他们不是有意/有意识地“陷害你”）。 但这是企业环境的现实； 如果你承担了责任（通常比那些不承担责任的人工资更高），那么如果事情进展不顺利，你就会陷入困境。 你也必须准备好长期坚持下去。 我曾经被安排在一个客户网站工作 8 个月，以修复一个日渐衰退的项目。 正如您所看到的，这里的另一位博主花了 9 个月才准备好发布版本。

现在，假设您同意尽管您付出了努力，但事情可能会变成梨形，这就是我的建议：

• 错误跟踪系统将成为您最好的朋友，它将使您能够重新获得表面上的控制。 你不能指望从整体上理解一个复杂的系统，所以“分块”它会有所帮助。 错误跟踪系统可以让您将问题统一起来，并将其分发给与您一起工作的其他人。错误跟踪系统

• 您需要应对技术和政治挑战。 技术通常不会那么糟糕，因为你是一名编码员并且你知道如何做到这一点。 政治因素要棘手得多，你掌舵着一艘完全偏离航线的船，而且你身处百慕大三角。 最大的挑战往往是遏制客户之间的负面情绪（例如客户：“这些牛仔不知道他们在做什么”，“他们向我承诺了这一点但没有兑现”，“我没有信心”在这些人中更多”）。

• 首先，向客户道歉，并具体告诉他们您正在做什么来重新调整他们的项目，例如您：“我对您的项目延迟感到抱歉，我陷入困境现在我已经查看了项目历史，就我个人而言，如果我为这个系统付出了很多钱，我要解决的第一件事是......”<-宾果，你。刚刚承担了该项目的责任，这意味着没有回头路 - 现在要么全有要么全无。

• 其他一些人已经说过了，我同意； 停止添加新功能。 他们没有提到的是，您可能必须这样做才能让客户满意（请记住，挑战有技术和政治方面）。

• 尽可能了解业务领域。 仔细阅读您可以获得的任何需求文档。 由于您不知道最初讨论的内容，因此迟到才开始该项目，您将处于巨大的劣势。 魔鬼在于细节。 这就是我在无法挽救的后期项目中陷入困境的原因，每个人都处于紧张状态，而我错过了一个小要求。 在当时来说，这没什么大不了的，可以很容易地纠正，但从政治上来说，这是压垮骆驼的最后一根稻草。 一种可能有帮助的策略是在客户网站上呆几个星期。

• 了解时间就是金钱。 这不仅仅是一个技术问题。 客户支付了不正确或尚未交付的东西。 你的公司已经消耗了资源，可能已经用完了所有的项目预算——公司现在正在亏损。 这就是新功能问题再次出现的地方，是的 - 人们说不要添加它们，要稳定。 但添加新功能可能是一种政治上有用的策略，管理层会很高兴，因为新资金将用于不合格的工作。

• 我建议您或您的编码人员不要长时间工作来交付。 如果您通常下午 5 点出发，请改为下午 6.30 或 7 点出发。 你和你的编码男孩可以连续多周坚持一两个小时的额外工作，周末可能额外工作 4-5 个小时。 每晚工作到晚上 9 点或 10 点会在大约 2 周内导致倦怠（有些可能会持续更长时间）。 在那之后，你在项目上的额外时间弊大于利。 万一你的老板对此提出异议，请做出选择； 做他们要求的事情（即增加工作时间），或者说“我已经投入了额外的时间来完成这个项目——我会在这里长期工作，如果我死了，我也会完成这个项目。但这是我愿意投入的时间的限制。我在工作之外还有其他承诺要保留”<- 但要做好应对后果的准备（请记住，政治局势同样重要）作为技术方面）。

• 这里有人说“停下来写一个规范，停下来做这个......” - 对不起，伙计们，我只是不能同意你们的观点，这是不现实的。 项目已经停滞不前，管理层或客户最不想做的就是“我们必须停止一切……”。 我以前尝试过这种方法，我对客户和管理层说过“错误会不断出现，直到我们停下来，我写出一份详细的系统测试计划。这需要我两周的时间”——客户不希望为此，管理层不愿意承担这笔费用。 事实上，错误不断出现。

• 学会“杂耍”——你必须提前制定任务，这样程序员就不会等着你了。 这通常意味着您自己编写的代码会减少。 通常，最好通过在编码开始之前制定项目时间表来实现这一点。 程序员在完成当前正在做的事情后应该知道他们下一步要做什么，并且他们不应该来问你“我下一步做什么？”，他们应该已经知道了。

• 内置恢复实用程序，特别是当软件反复出现难以确定的问题时。 例如; 可能需要 12 小时才能找到错误并修复它，可能需要 2 小时才能投入实用程序（阅读“黑客”）来暂时解决问题。 时间和动力是关键，不幸的是可能需要创可贴修复。 内置

• 要密切关注客户的情绪。 他们需要知道你“站在他们一边”（例如客户：“该产品是不可接受的”，你：“我同意，如果我处于你的位置，我会踢我们的屁股。我能告诉你的是我在这方面）并且在一切正常之前不会休息”）。 当客户回到您的网站时，他们实际上会开始为您提供帮助。 例如，他们可能会保护您免受管理层的压力。

• 以身作则。 类似于“我要留下来处理这个项目，如果你也愿意留下来，我会很感激你的帮助”和“我知道这不是我们的烂摊子，但我们仍然会清理”无论如何，我希望客户得到一些高质量的软件”。 程序员通常不太关心让他们陷入这种情况的公司，但他们可能关心的是他们自己的公司还是客户（“可能”）。

我在这里看到的许多建议都假设了相当高的权力（例如“停止项目以正确重新启动它”或“对新功能说不”）-您正在启动已经受到阻碍的项目，并且作为一名程序员，传统上，与真正的管理者相比，你影响变革的权力要小。 这并不意味着“放弃/不尝试”——它只是意味着你必须发挥创造力，做你通常不做的事情（即使用“软”或人际交往能力）。

这里很多人都在说放弃这个项目，逃之夭夭。 迄今为止，我已经完成了 3 个无可救药的迟到项目。 我成功修复了 2 个，还有 1 个无法修复。 就我个人而言，承担一个迟到的项目并不困扰我。 毕竟，最糟糕的情况就是你被解雇了:)

Answer 6

如果你从一开始就参与了这个项目，我不想这么说，但公司应该取代你（以及整个团队）。

应该由具有实际项目管理流程的称职团队重新分析，并由具有这种情况经验的项目经理领导。

任何原始编码员都不应该致力于保存它的“新项目”。 他们可以转移到其他项目（他们不必被解雇），但为了重新审视该项目，每个人都应该被替换。

当然，管理层必须理解并接受该项目将比预期晚得多的事实。 如果管理层不同意这一点（更换团队、寻找经验丰富的领导层、后退一步并重新开始），那么 @Maxim 是对的 - 离开那里。

Answer 7

1）我首先要评估的是团队中的人是否致力于该项目？ 如果没有的话，做任何其他事情都是没有意义的。 除非我有一个专注且忠诚的团队，否则没有什么可以阻止灾难的发生。
2）我会确保团队中有质量保证人员。
3）向客户提出合理的迭代增量发布计划。 由于我们所处的混乱局面，客户不可能很快得到所有东西。 根据客户的优先级，我们将经常向他提供较小的功能增量。 这将使客户保持参与，因为他看到了正在发生的事情，所以不会那么急躁。

Answer 8

做什么事情，都要一步一步来。

首先，这不是关于添加功能，而是关于修复应用程序。 不要添加任何新内容。 只需重构即可。 对有人要求你在系统中引入的任何新东西说不。

不要尝试改进整个应用程序。 让您的团队利用最佳实践，使其专注于某一方面，尤其是使用单元测试。

仅使用测试驱动开发。 在这种情况下，它会立即向您显示您不理解行为的哪一部分（如果您不知道要测试什么，则无法编写测试代码。

因此，这是路线图：

1. 确定您需要的关键部分更改
2. 隔离暗示此行为的代码
3. 在代码的其余部分中查找此代码的任何出现
4. 使用这些知识和大量 TDD
5. 进行重构 集成、测试和修复，直到此特定部分正常工作
6. 返回步骤

向您的老板明确情况：这需要时间、金钱，而且会很痛苦。解释一下为什么，你会做什么，并且你没有其他办法，否则它会再次失败。

首先，不要尝试第一次就将其清理干净。您可以，但不要指望第一次更改您正在处理的部分的整个架构。您将不得不在整个应用程序上迭代该过程，这

只是方法。和耐心。

Answer 9

在那里，遵循以下步骤：

稳定

• 收集真实的故事：代码库有多好/坏，开发人员有多好/坏，真正需要完成什么（最基本的），什么时候它需要通过
• 减少加班来完成（疲倦的人，无论好坏，都不能很好地工作）
• 删除坏的，输入新的/好的 - 错误地进行替换（许多人可能会精疲力尽，甚至欣赏被迫的改变）
• 删除对不良/不需要的代码的访问（重点关注提供 80% 价值的 20% 代码库）
• 将基本代码实践落实到位，确保只有好的代码才能进入（不再损坏基础代码）

控制

• 实施团队专注于应用程序组件（尽可能解耦），
• 代码管理、发布管理、风险管理、质量保证等落实到位（构建您的环境，以便您能够成功）
• 将 客户/赞助商好的一面 - 交付胜利，即使它是一个相当稳定的非常小的版本 - 然后进行变更管理（控制所要求的内容）

继续

• 制定计划（计划是必不可少的，根据艾克的说法，计划是无用的 -你需要计划找出缺失的东西并设定目标，但不要指望能告诉未来） - 需要持续计划
• 积极管理你的员工 - 优秀的人创造出好的产品 - 确保你获得并保留最好的
• 重构随着时间的推移 - 边走边清理代码 - 你可能没有能力立即修复所有内容，所以加班加点以提供更干净的代码库
• 勇敢地前进 - 加班更积极地进行交付测试（但不要压力）团队

Answer 10

敏捷重构。 确定客户的需求并确定其优先级，然后在短时间内从现有代码中创建最重要的内容。 祝你好运，伙计:)

Answer 11

维亚斯，我觉得我可以写这个问题。 我之前的工作涉及复兴一个经过一年开发而失败的 KVM 项目。 规格采用用户手册和开发人员使用类似产品的经验的形式。 我最终向 3 名汇编程序员教授 C，并从头开始重新架构。 我们在 4 个月内将产品成功推向市场。 （然后我辞职了。想想吧。）

我会再次做的一些事情，特别是在一个缺乏经验的团队中：

1。 一群缺乏经验的程序员 24x7 工作
10。 没有技术领导/或牛仔编码员可以解决技术问题

• 让他们从项目中休息一下以“充电”。 也许是一天，也许是一个下午，或者也许是一顿丰盛的午餐。 它将标志着“旧”项目的结束和成功的开始。
• 让他们同意他们回来后会全力以赴，并保证你将成为他们的首选人物、拉拉队长和防弹衣。 你们是一个团队，你们的工作就是为他们开辟道路、消除干扰并领导他们。
• 计划立即取得成功，无论多么小，并保持“我能做到”的态度。

8. 错过了一个又一个里程碑
9. 团队无法确定交付日期，因为没有人就实际需要完成的工作量达成一致
3. 客户尖叫着说他甚至不能做基本的事情（保存/查询）等。

• 小口吃！尽可能分解每个部分，然后处理小组件。 您将尽早发现“陷阱”，并能够更好地确定整个项目的范围。
• 定义你的接口。任何时候你可以隔离一个块，去做。这允许并行开发，因为你已经决定了参数、先决条件、假设、内部发生的情况，和返回值。 您可以将其存根，然后独立构建其他模块和测试。
• 确定优先级。首先关注影响客户的缺陷和问题。 新功能排在最后。 如有必要，推迟功能而不是提供有错误的代码。
• 分配职责。志愿者是首选，每个人都在他/她的专业领域，但每项任务必须有一个人负责。
• 跟踪缺陷并记录有助于您重现、定位和修复缺陷的所有内容。 记录交付时剩余的所有内容，这样客户就不会感到惊讶。

4。 习惯于将规范下达的程序员很难即兴发挥
6。 纸面上看起来不错的架构文档在实践中并未得到遵循

• 您将在需要时随时创建规范详细信息，每个部分都在需要之前创建。 它不需要很漂亮、完整，甚至不需要写得很清楚，只要每个人都理解当前的任务并且你有全局观即可。
• 当开发人员准备好编码时，一次一小部分地讨论实现。 如有必要，自己编写框架，然后让团队填写“内容”。 您想让他们专注于每项任务，而不是“即兴发挥”。
• 随时回答出现的问题。 您的主要目标是保持团队的生产力。

2. 修复错误只是为了引入新错误
5. 没有自动化的单元测试会使情况变得更糟 尽快

• 计划并开始单元测试。 如果可能，争取团队外部的资源。
• 在小问题变得更大或被隐藏之前解决它们。 对每个小部分的信心可以建立对整体的信心。

7. 使用的第三方组件首先没有经过适应性测试就成为瓶颈

• 当您不编码时集思广益解决方案。 如果可能的话，不要让他们阻止你的进步。 您可以封装它们或围绕它们编写代码吗？ 替换他们？

一般建议：

• 保持团队领先。在团队遇到问题之前预测并尝试解决问题。 在需要之前收集任何必要的信息。
• 不断沟通。明确表示您不希望出现任何意外，并在每天中征求疑虑、问题、状态、障碍等。 鼓励整个团队协作并分享“发现”。
• 庆祝每一次成功。称赞巧妙的解决方案、在问题解决时带上甜甜圈、展示新的工作功能……任何可以向团队表明您欣赏他们的事情。
• 完成每项任务，然后继续前进。不要浪费时间调整、增强或返工任何不直接阻碍成功的事情。
• 信守对团队、客户和管理层的承诺。

祝你好运——请随时通知我们！

Answer 12

逃跑或者找新工作。 这是一场死亡行军，他们需要一个替罪羊。

死亡行军通常会涉及
拼命尝试纠正路线
通过询问团队成员来了解该项目
工作时间特别辛苦，
周末，或者尝试“扔
（足够）机构解决问题”
结果不同，常常导致
倦怠。

Answer 13

冻结版本，并开始修复程序问题......按优先级处理客户投诉（公司业务方可以优先考虑）并让程序运行。 一旦解决了最大的问题，就开始清理代码。 将任务分配给其他开发人员，并开始在所有新代码上实施编码实践。

如果你可以做任何你想做的事，那么看看真正的问题是什么并解决它们。 如果这意味着组建一个新团队从头开始开发软件，那就这样吧。 但您至少应该尝试修复主要错误。 不要费心引入新功能，它们只会使问题更加复杂，而一个不起作用且问题没有得到解决的程序会失去您的客户。

Answer 14

第 10 个问题显然是最严重的问题，或者至少是所有其他问题的根源。 找到具有一定创造力和能力来交付项目的人，并让他们自由地做任何事情 - 包括重新开始。

Answer 15

我希望你能得到很好的报酬。 无论如何，我的计划将类似于以下顺序的步骤：

0）停止在整个团队中添加特性或功能。 在执行以下步骤直至步骤 5 时允许解决错误，然后停止错误修复和修复。 恢复功能开发：

1）应用我所说的“逆向人员配置法”：较弱的团队成员会拖慢更好更快的团队成员的速度，并且通常后期的软件项目需要删除人员，而不是添加人员。 因此，您需要评估团队成员作为个人贡献者的质量。 从团队中剔除实力较弱的员工，因为可能有一些。 最好的方法是检查他们的代码并检查他们的错误修复，找出谁使代码变得更糟或更好，然后为团队砍掉它们。 现在不是指导的时候，你需要最好的人来改变，在最佳的时间内“解决”这种情况。 如果你无法解雇他们或重新分配他们，请让他们为剩下的其他人提供咖啡或其他东西。

2) 评估代码本身。 识别代码中构造得不好和/或抽象得不好的区域。 如果区域代码构建得不好和/或在其应做的事情上明显很脆弱，则将其作为重写的目标。 此时这感觉很痛苦，但从长远来看它会节省你的时间。 反复出现的错误和/或修复历史记录将有助于识别无法挽救的代码。 如果一个代码区域或模块从根本上构建得很好，但在接口级别上没有很好地抽象，那么它应该适合重构。 这将节省大量时间并且是有用的代码。 保留重写区域、重构区域和合适区域的列表。

3) 定义一个新的合理架构，您相信该架构将产生一个健壮且完整的解决方案，满足您最终想要的特性和功能。 该架构在开始时可能不是最佳的，但实际上将您所拥有的与您想要的相匹配。

4) 与利益相关者合作，决定什么是可接受的第一个版本，尝试为“以后”的版本提供尽可能多的功能。 也许你不能削减任何东西，但如果可以的话，现在就是这样做的时候了。

5) 停止后台错误修复工作，并将已定义的工作分配给（剩余的）团队，以估算出其余功能的合理的新实施计划。 他们需要掌握时间表。 滚动日程并相当保守。 现在您可以合理预测何时可以真正拥有可行且可靠的东西。

6) 实现剩余的功能，然后通过解决剩余的错误来强化版本。 我假设这里遵守了所有正常的良好软件开发实践，例如源代码控制、单元测试等。

7) 消除尽可能多的障碍，以使团队尽快开发出东西。

8) 监控问题，并尽可能亲自动手提供帮助。 在你能提供帮助的范围内主动承担更棘手的问题，同时仍然保持团队所有成员的工作效率。

祝你好运！

Answer 16

这不再是技术领导力的问题，而是项目管理的问题。

作为技术主管，您将只是在泰坦尼克号上移动躺椅。 如果我是事实上的项目经理，我会这样做。

1) 确定项目发起人和利益相关者——包括官方的和真实的。

2）去找他们并要求项目“关闭”一周。

3）如果他们不同意，就放弃这个项目。

4) 如果他们确实同意，则将项目暂停一周——一切都停止。

5) 花整整一周的时间与项目中的重要人员交谈，以确定项目的真实状态。

6) 在参与这些讨论的同时，开始制定项目恢复计划，强调范围、进度、预算和人员之间可能的权衡。

7) 在周末，决定哪些（如果有）可能的项目场景是可行的。

8) 将这些方案中的最佳方案反馈给项目发起人和利益相关者，并开始谈判。

9）当就前进的方向达成一致时，重新启动项目并祈祷 - 可能不是按这个顺序。

Answer 17

常识已经被马克西姆（退出死亡行军）给你指出了。 但如果出于未知的原因你希望坚持下去，让我用我在类似情况下的经验来招待你——也许它可能会有用。

这是我在一个沉睡的老城区的第一份工作，那里很难找到好的计算机工作，大学毕业后我迫切需要一份工作。 我被录用是因为管理层认为我足够热情，可能聊胜于无（我提出带自己的补偿来节省他们给我一台电脑的费用，并提出只为体验而工作）

该项目已被放弃由于死亡行军的情况，它的创建者在删除代码中的所有注释并执行其他混淆后消失了。 也没有人了解 win32/MFC 的东西。

我只是开始在旧纸和铅笔上研究代码（大量的涂改和修改），直到在 20 天内我知道了整个代码，包括熟记在心的变量以及发生的事情和地点。

有了这些知识，我就能够做出一个以前每个人都未能完成的关键作品。 当然，这只不过是沧海一粟，但它使管理层能够赢得客户的信心“聪明的家伙 - 费了很大的劲才把他搞定 - 已经让 x 工作了 - 你将在 y 时间内让你的东西工作起来”。

一旦客户被说服并且我们能够争取到一些时间，一些压力就被消除了。 这给团队带来了一些希望，我们开始努力奋斗。 6 个月后，我晋升为项目负责人，9 个月后，我们完成了修复交付（大量进度演示，期间客户明显越来越满意）。

正如您所看到的，成功的要素是无法直接复制的。 但我总结一下，你需要首先给项目带来一些希望——展示一些进展并赢得同事、管理层和客户的信心。 一旦到位，技术问题也应该得到纠正——没有什么可以替代等式的这一部分。

如果这看起来不太可能，那么所有的艰苦工作（哦，是的 - 很多很多工作，就像你从未想象过的 - 为什么你认为它被称为死亡行军）将是一种浪费，你最好在开始之前就放弃。

我别无选择，我热血沸腾，迫切需要一份工作。 技术细节可以让我发挥魔法，一切都按部就班。 我确实通过这部作品赢得了很多善意和自尊，但从长远来看，这只是一个我可以沉着地讲述的故事，除了那些少数知情者之外，仅此而已。

事情对你来说可能会有所不同，但由你决定。

祝你好运

Answer 18

• 确保你不是替罪羊
• 削减范围蔓延
• 修剪功能“需求”
• 实施更快的开发周期（也许是敏捷/Scrum/XP/其他）

Answer 19

如果可以的话，就逃吧。

如果不是，您需要停止所有导致项目不稳定的活动 - 包括编码和修复缺陷。

评估你所处的位置 将

需求分解为更小的“里程碑”

阅读一些实用书籍（我想到了麦康奈尔的“软件项目生存指南”。

识别所有问题和风险。将所有这些问题和风险传达给所有相关人员。

在 你

庆祝进步和里程碑，祝

好运。它可能无法挽回 - 事情必须改变才能变得更好。

Answer 20

如果你真的必须让它走上正轨（如果保释不是一个选择），

那么首先要接受这是管理上的失败。 然后，您可能想继续实施严格但轻松的流程。

我建议采用某种形式的敏捷，因为它是最容易在没有专家的情况下成功实施的，但你必须对此非常严格，包括配对、无情重构、评论、尖峰功能、可见性、TDD、一周周期、每天工作 8 小时（是的，超过 8 小时往往对生产力的损害大于帮助，正如您似乎已经注意到的那样）...

也不要删除任何内容。 敏捷的某些部分依赖于其他部分——如果没有配对、重构和测试，你就无法消除前期设计（最大的敏捷失败之一）。

不要忘记它的管理方面。 开始一周迭代（每周演示）。 不断适应。 每天都有很短的站立会议来解决问题。 （最多保持 15 分钟，列出更长的问题等）燃尽图，核心团队与客户。

你不能只是每周举行一次 15 分钟的会议和两周的迭代并称之为敏捷，但如果你做得正确，它可能会给你一个机会。 您可能会聘请一位优秀的敏捷顾问来培训您入门。

另外，不断评估什么有效，什么无效。 准备好修复不起作用的地方。 每周召开一次会议，分析当周的开发成功和失败。

总体而言，它可以发挥作用，并且可以使一个摇摇欲坠的团队恢复正常，但这并不是微不足道的。 最好的部分是您可以实现它，而无需在当前的开发中花费大量时间。 你只是不断发展，但你会做得更好。