19

You must have heard the archetypical story of a failing/failed project:

  1. A team of inexperienced programmers work 24x7
  2. Bugs are fixed only to introduce new bugs
  3. Customer is screaming that he could not even do the basic stuff (Saving/Querying) etc.
  4. Programmers used to having the spec handed down struggle to improvise
  5. No automated unit tests aggravate the situation
  6. Architecture document that looked nice on paper was not followed in practice
  7. Third party components used become bottlenecks not having been tested for fitness in the first place
  8. Milestone after milestone missed
  9. The team is not able to come up with a delivery date as nobody agrees as to the quantum of work actually needs to be done
  10. No technical leadership / or a Cowboy Coder that can take on the technical issues

Now, If you were to be brought in as #10 what would be your first steps?

Update: First of all: Thanks to you all for chipping in. Well... I'm being brought in as #10. I was the original Architect anchoring the solution when we made the proposal to the client. Then, unfortunately, I couldn't take on the delivery responsibilities as I was assigned somewhere else. :)

Let's say it's a webification of an existing desktop application. I'm now being brought in as #10. Running away, sadly, is not an option. I'm sure this can still be reversed by following agile best practices and just wanted to tap the community for ideas.

The larger question perhaps is this: If the development team does not have specs but only the (baselined) code for a running application, the original solution called for looking at the code and extracting business rules on the fly. Now, the inexperienced programmers are reluctant to look at VB 6.0 code and want documents! So how do you fight this if you were to instate Agile processes?

4

20 回答 20

22

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

我会再做一些事情，尤其是在经验不足的团队中：

1. 一个缺乏经验的程序员团队 24x7 全天候工作
10. 没有技术领导/或 Cowboy Coder 可以处理技术问题

  • 给他们一个（短暂的！）从项目中“充电”的休息时间。也许是一天，也许是一个下午，也许是一顿漫长的午餐。它将标志着“旧”项目的结束和成功的开始。
  • 让他们同意在他们回来时努力工作，并承诺你将成为他们的首选人、啦啦队长和防弹夹克。你，集体，是一个团队，你的工作是开辟他们的道路，消除干扰，并领导他们。
  • 计划立竿见影的成功，无论多小，并保持“可以做”的态度。

8. 错过里程碑后
的里程碑 9. 团队无法提出交货日期，因为没有人同意实际需要完成的工作量
3. 客户尖叫说他甚至无法完成基本工作（节省/查询）等。

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

4. 习惯于将规范传下来的程序员很难即兴发挥
6. 在纸上看起来不错的架构文档在实践中没有被遵循

  • 您将随时创建规格详细信息，每件都在需要之前。只要每个人都理解当前的任务并且你有大局，它不需要漂亮、完整，甚至是书面的。
  • 当开发人员准备编写代码时，一次一个地讨论实现。必要时自己写骨架，让团队填“胆”。你想让他们专注于每项任务，而不是“即兴发挥”。
  • 随时可以回答出现的问题。您的主要目标是保持团队的生产力。

2. 修复错误只是为了引入新的错误
5. 没有自动化单元测试会加剧这种情况

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

7. 使用的第三方组件成为瓶颈，一开始没有经过适应性测试

  • 不编码时头脑风暴解决方案。如果可能的话，不要让他们阻止你的进步。你能围绕它们封装或编码吗？替换它们？

一般建议：

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

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

于 2008-10-26T06:27:43.397 回答
11

Run away or find a new job. This is a death march and they need a scape goat.

Often, the death march will involve desperate attempts to right the course of the project by asking team members to work especially grueling hours, weekends, or by attempting to "throw (enough) bodies at the problem" with varying results, often causing burnout.

于 2008-10-24T17:53:03.413 回答
9

Freeze releases, and start fixing issues with the program.... deal with the customer complaints by priority (the business side of the company can prioritize) and get the program running. Once you get the biggest issues out of the way, start cleaning up the code. Assign tasks to other developers, and start enforcing coding practices on all new code.

If you can do whatever you want, then look at what the real issues are and deal with them. If that means putting together a new team to develop the software all over from scratch, so be it. But you should try to at least fix the major bugs. Don't bother introducing new features, they only compound the problem, and a program that doesn't work and the problems aren't dealt with lose you clients.

于 2008-10-24T17:56:42.550 回答
5

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

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

1) 应用我所说的逆人员配备法则：较弱的团队成员会放慢更好和更快的团队成员的速度，通常后期的软件项目需要移除人员，而不是添加人员。因此，您需要评估团队成员作为个人贡献者的质量。从团队中淘汰较弱的员工，因为大概有一些。这最好通过审查他们的代码并检查他们的错误修复来完成，并找出谁让代码变得更糟和更好，并为团队砍掉它们。现在不是指导的时候，您将需要最好的人在最佳时间段内改变“修复”情况。如果你不能解雇他们或重新分配他们，让他们为剩下的其他人喝咖啡或其他东西。

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

3) 定义一个新的合理架构，您认为该架构将为您最终希望的特性和功能提供强大而完整的解决方案。该架构在开始时可能不是最佳的，但实际上与您想要的位置相匹配。

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

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

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

7) 消除尽可能多的障碍，以使团队尽可能快地完成工作。

8) 监控问题，并通过尽可能多地弄脏您的手来提供帮助。提出在您可以提供帮助的范围内解决更棘手的问题，同时保持团队所有成员的工作效率。

祝你好运！

于 2009-01-11T01:18:50.910 回答
5

Number 10 is obviously the worst problem, or at least the root of all others. Find someone with some creativity and ability to deliver a project, and give them free reign to do anything - including start over.

于 2008-10-24T17:54:12.460 回答
3

这不再是关于技术领导力，而是关于项目管理。

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

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

2) 去找他们，要求项目“黑掉”一周。

3）如果他们不同意，离开这个项目。

4）如果他们同意，就叫项目暂停一周——一切都停止了。

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

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

7) 在一周结束时，决定哪些（如果有）您的可能项目方案是可行的。

8) 将这些场景中最好的情况反馈给项目发起人和利益相关者，并开始谈判。

9) 当一个前进的方向达成一致时，重新启动项目并祈祷——可能不是按照那个顺序。

于 2008-10-25T18:31:12.220 回答
2

Maxim（退出死亡行军）已经向您指出了常识。但是，如果出于未知的原因你想坚持下去，让我用我在类似情况下的经历来招待你——也许它可能会有用。

这是我在一个昏昏欲睡的老城区的第一份工作，那里很难找到好的计算机工作，而我在大学毕业后迫切需要一个。我被录用了，因为管理层认为我足够热情，可能聊胜于无（我提出带上我自己的薪酬，以节省他们给我一台 PC 的费用，并提出独自工作）

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

我只是开始在好的旧纸和铅笔上研究代码（大量的摩擦和更正），直到在 20 天内我知道整个代码，包括心脏的变量以及发生的事情和发生的地方。

有了这些知识，我就能够制作出以前所有人都无法理解的关键作品。当然，这不过是沧海一粟，但它使管理层能够赢得客户的信心“聪明的家伙 - 很难让他 - 已经让 x 工作 - 你将在 y 时间内让你的东西工作”。

一旦客户被说服并且我们能够争取一些时间，一些压力就被消除了。这给团队带来了一些希望，我们开始全力以赴。6 个月后，我被提升为项目负责人，9 个月后，我们收到了修复货物（大量的进度演示和明显越来越满意的客户）。

如您所见，成功的要素不能直接复制。但我想总结一下，您需要首先为项目注入一些希望 - 展示一些进展并赢得信心 - 您的同行、管理层和客户的信心。一旦到位，技术内容也应该得到纠正——没有什么可以代替这部分等式。

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

我别无选择，我很热血，迫切需要一份工作。可以在其中发挥作用的技术细节，一切都刚刚到位。我真的通过这部作品赢得了很多善意和自尊，但从长远来看，它只是一个故事，我可以非常沉着地讲述，除了那些知道的人之外，仅此而已。

事情可能对您有所不同，但由您决定。

祝你好运

于 2008-10-24T18:31:05.583 回答
1

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

首先要承认这是管理上的失败。然后，您可能希望继续实施严格但轻松的流程。

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

也不要剪掉任何东西。敏捷的一部分依赖于其他部分——没有配对、重构和测试，您无法消除前期设计（最大的敏捷失败之一）。

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

你不能仅仅每周开 15 分钟的会议和 2 周的迭代就称之为敏捷，但如果你做得对，它可能会给你一个机会。您可能会得到一位优秀的敏捷顾问来培训您入门。

此外，不断评估哪些有效，哪些无效。准备好修复不起作用的东西。每周召开会议，分析这几周的开发成功和失败。

总体而言，它可以工作，并且可以使一个摇摇欲坠的团队陷入困境，但这并不是微不足道的。最好的部分是您可以在不占用当前开发的大量时间的情况下实现它。你只是不断发展，但你做得更好。

于 2008-10-24T18:08:55.193 回答
1

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

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

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

结果需要制定一个可行的 6 个月 - 1 年交付计划，真正让他们专注于必备品和对第三方组件的真实贸易研究。并且垃圾代码库需要成为一种选择；开始一个新的源代码控制项目，当你到达一个特定的模块端口时，这些端口是有意义的，并留下了垃圾。

敏捷非常棒，一旦你制定了真正的计划，它也是一种有效的方法；但它不会修复与您的客户的破裂关系......或所有已经存在的垃圾。

于 2008-10-24T19:01:28.817 回答
1
  • Make sure you aren't the scapegoat
  • Cut scope creep
  • Trim functionality "requirements"
  • Implement a faster dev cycle (maybe Agile/Scrum/XP/whatever)
于 2008-10-24T17:55:38.650 回答
1

首先，要下定决心，你可能会失败——如果你不能接受，就不要接受挑战。这包括成为替罪羊（确实会发生）。管理层不会以这些方式看待它（即他们不是有意/有意识地“设置你”）。但这是企业环境的现实；如果您承担责任（通常比不承担责任的人获得更多报酬），那么如果事情没有解决，您的头脑就会被阻止。你也必须准备好长期坚持下去。我曾经在一个客户网站上待了 8 个月，以修复一个衰落的项目。正如您所看到的，这里的其他博客发布者之一花了 9 个月的时间才准备好发布版本。

现在，假设您可以接受尽管您付出了努力但仍可能变成梨形的可能性，这就是我的建议：

  • 错误跟踪系统将成为您最好的朋友，它将让您重新获得控制权。您不能希望将复杂的系统作为一个整体来理解，因此“分块”会有所帮助。错误跟踪系统允许您将问题统一起来并将它们分发给您正在合作的其他人。

  • 你要应对技术和政治挑战。技术通常不是那么糟糕，因为您是编码员并且您知道如何做到这一点。政治问题要棘手得多，你掌舵的一艘船已经无可救药地偏离了航线，而你正处于百慕大三角地带。最大的挑战通常是阻止客户中负面情绪的浪潮（例如客户：“这些牛仔不知道他们在做什么”，“他们向我承诺过，但没有兑现”，“我没有信心在这些家伙中，不再有”）。

  • 首先，向客户道歉并具体告诉他们你正在做什么来重新纠正他们的项目，例如你：“我很抱歉你的项目延迟了，我现在陷入困境。我查看了项目历史，就个人而言，如果我为这个系统付出高昂的代价，我也会很生气。我要解决的第一件事是……”<-宾果游戏，你刚刚拿了对项目负责，这意味着没有回头路——现在要么全有，要么全无。

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

  • 尽可能了解业务领域。通读任何你能拿到的需求文件。由于您不知道最初讨论的内容，因此迟到该项目会使您处于极大的劣势。魔鬼在细节中。这就是让我在无法挽救的后期项目中陷入困境的原因，每个人都处于紧张状态，而我错过了一个次要要求。在当时，这没什么大不了的，可以很容易地纠正，但从政治上讲，这是压垮骆驼的最后一根稻草。一种可能会有所帮助的策略是在客户网站上停留几周。

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

  • 我建议您或您的编码人员工作荒谬的时间来交付。如果您通常在下午 5 点离开，请改为在下午 6.30 或晚上 7 点离开。您和您的编码男孩可以连续数周保持一两个小时的额外工作，周末可能会保持 4-5 小时。每晚工作到晚上 9 点或 10 点会导致大约 2 周内精疲力竭（有些可能会持续更长时间）。在那之后，您在项目上的额外时间弊大于利。万一您的老板对此提出异议，请做出选择；做他们要求的（即工作更多时间），或者说“我已经为这个项目付出了额外的时间——我是长期来这里的，如果这个项目我死了，我会完成这个项目。但这是我愿意投入多少时间的极限。但要为后果做好准备（请记住，政治局势与技术局势一样多）。

  • 这里有人说“停下来写一个规范，停下来做这个......” - 对不起，伙计们，我在这里不能同意你的看法，这是不切实际的。该项目已经停滞不前，管理层或客户想要在这里做的最后一件事是“我们必须停止一切并且......”。我以前试过这个，我对客户和管理层说“错误会一直出现，直到我们停止，我写了一个详细的系统测试计划。这需要我两个星期”——客户不想要要为此付出代价，而管理层不愿意承担这笔费用。正如它发生的那样，错误不断出现。

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

  • 内置恢复实用程序，尤其是当软件存在难以确定的反复出现的问题时。例如; 追踪错误并修复它可能需要 12 小时，可能需要 2 小时投入实用程序（阅读“hack”）来暂时修复问题。时间和动力是必不可少的，不幸的是，可能需要使用创可贴修复。

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

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

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

这里的很多人都说要保释该项目，奔向山丘。迄今为止，我已经完成了 3 个无可救药的迟到的项目。我设法修复了 2，而 1 我无法修复。就个人而言，承担后期项目并不困扰我。毕竟，可能发生的最坏情况就是你被解雇了 :)

于 2008-10-28T06:25:15.150 回答
1

Here's the summary of key learning after reading through your experiences:

Maxim
1: Make sure this is not a "Death March"

Ellie
2: Make sure what's delivered works 3: Refactor & Realgin codebase to Architecture / Best practices 4: Look at what are the real issues: Is the team technically competenet to deliver?

Kendall
5: Ensure availaibility of Technical Leadership

Bill K
6: Implement Agile Processes (At least automated unit tests if not TDD, short iterations that make progress visible) 7: Get customer buy-in 8: Be prepared to throw out what cannot work (wishful thinking aside)

Warren
9: Make sure the team memebers that remain given a chance to start over

Tim
10: Motivate team and as improvement becomes visible reward them

jsl4980
11: You need buy-in on schedule from your team (most imp.) & customer [This raises more questions. What if your customer asks whether the team is competent enough to stick to your schedule? What if you yourself know that the timelines the team is proposing just shows their lack of understanding]

Ather
12: Is the team commited?
13: Do you formally QA?

Patrick
14: Start over, redesign and reconform to Architecture/Design best practices for modules yet to be developed.

于 2008-10-24T21:25:47.417 回答
1

如果可以，就逃吧。

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

评估你在哪里

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

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

识别所有问题和风险。与所有相关人员进行沟通。

一次一个地处理每一件。

庆祝实现的改进和里程碑。

祝你好运。你的情况听起来很糟糕。它可能无法挽救 - 事情必须改变才能变得更好。

于 2008-10-24T18:02:22.740 回答
1

摘要有 14 项。你不能全部都做。那么，第一步是什么？

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

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

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

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

你可以处理时间表。如果没有其他更正（即质量或架构），您可能无法解决进度问题。

我认为，人们态度的全面改善来自于尽可能早地从一次成功——任何成功——开始。挂在最低点的水果是什么？

  • 一个长期存在的错误？一个单元测试套件来查找和修复该错误？
  • 一个主要的建筑特征？每个人都可以在他们的多维数据集中发布的图表会有帮助吗？演示文稿如何澄清事情？
  • 一个新的用例？一项真正有效的新功能？
于 2008-10-25T01:53:09.093 回答
1

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

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

于 2009-01-06T11:40:31.413 回答
0

1）我要评估的第一件事是团队中的人是否致力于项目？如果没有，做任何其他事情都是毫无价值的。除非我有一个敬业的团队，否则没有什么能阻止灾难。2) 我会确保团队中有 QA。3) 为客户制定合理的迭代和增量发布计划。由于我们所处的混乱局面，客户不可能很快得到所有东西。根据客户的优先级，我们会经常向他提供较小的功能增量。这将使客户保持参与度，因为他看到一些事情正在发生，所以不那么紧张。

于 2008-10-24T18:20:58.350 回答
0

敏捷重构。识别并优先考虑客户的需求，然后在现有代码的短冲刺中创建最重要的东西。祝你好运：）

于 2009-01-11T00:38:52.363 回答
0

If you were involved in the project from the beginning, I hate to say it, but the company should replace you (and the entire team).

It should be reanalyzed with a competent team with real project management processes and lead by a project manager with experience in this situation.

None of the original coders should work on the 'new project' of saving it. They can move to other projects (they don't have to be fired) but to get a fresh look at the project, everybody should be replaced.

And of course, management has to understand and be on board with the fact that the project is going to be much later than expected. If management doesn't agree with this (replace team, find experienced leadership, take a step back and start again) then @Maxim is right - get out of there.

于 2008-10-24T17:58:29.707 回答
0

Been there, followed these steps:

Stabilize

  • gather the real story: how good/bad is the codebase, how good/bad are the developers, what really needs to get done (bare bone min.), when it needs to get done by
  • reduce overtime (tired people, good or bad, don't work well)
  • remove the bad, input new/good - err on the side of replacement (many could be burnt out and appreciate even a forced change)
  • remove access to bad/un-required code (focus on the 20% of the code base that provides the 80% of the value)
  • put base code practices in place ensuring only good code is getting in (don't damage the base anymore)

Control

  • implement teams focused on the app components (decouple as much as possible)
  • put code management, release management, risk management, QA, etc. in place (build your environment so you can succeed)
  • get on your clients/sponsors good side - delivery a win, even if it's a somewhat stable very very small release - and then put in change management (control what gets requested)

Move forward

  • develop a plan (planning is essential, plans are useless according to Ike - you need to plan to find what is missing and to set a target, but don't expect to tell the future) - continuous planning is required
  • aggressively manage your people - good people make good product - make sure you get and retain the best
  • refactor over time - clean up code as you go - you may not have the luxury to fix everything at once so do it overtime to provide for a cleaner code base
  • move forward bravely - overtime be more aggressive with your deliveries test (but not stress) your team
于 2009-01-10T23:50:54.397 回答
0

不管你做什么，一步一步去做。

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

不要试图改进整个应用程序。带上你的团队，让它在当时专注于一个方面，尽可能地使用最佳实践，尤其是使用单元测试。

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

所以这里是路线图：

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

向你的老板说明情况：这需要时间、金钱，而且会很痛苦。解释为什么，你会做什么，你别无选择，否则它会再次失败。

A 最重要的是，第一次不要试图让它干净。重构你能做的，但不要期望第一次改变你正在处理的部分的整个架构。您将不得不在整个应用程序上多次迭代该过程。

没有奇迹。只是方法和耐心。

于 2008-10-26T09:39:41.857 回答