From this case study, you will find out about the difficulties of working with legacy projects, what to do in the early stages, and how to organize teamwork effectively.
The term “legacy” is very close in meaning to “heredity.” People inherit not only positive but also negative traits from their ancestors. In the same way, project managers often inherit problems from their predecessors. At one time or another, almost every specialist will have to undertake a project with an outdated code written by unknown programmers. It is also common practice to hand over legacy projects to new PMs with no documentation.
In such cases, historical projects become hysterical, causing untold stress and inconvenience. With no clear way to bring a legacy project into order, the PM and other team members must make titanic efforts to figure it out.
When undertaking a legacy project, in addition to obsolete code, you may also inherit the following:
- outdated technology;
- non-uniform architecture;
- dearth or even complete absence of documentation.
Our company undertook a large project that had been created long ago by other developers. The Clever team had to replace old software with new programs that corresponded to the latest trends in design and technology.
Getting Acquainted With the Project
Our first task with this large and old project was to collect initial data:
- Documentation and initial technical assignment.
- Access to Git or other code storage.
- A bug report showing all the weaknesses, potential problems, and elements that could break or that had not yet been fixed.
After we retrieved our data, the next step was to conduct a technical audit of the project, to identify bottlenecks, and determine which faulty decisions were made by our predecessors and when. We also had to study the third-party services and libraries that were used within the project. At this stage, we created a document to record the actualization of library and third-party service versions.
The next step was to check for the availability of Unit / Automation tests, which could greatly facilitate further development.
The customer and all key stakeholders were notified that the first 3-4 weeks would be spent on code review and small fixes.
Estimate and Prioritization
Sometimes a situation arises when it is critical to implement a certain feature. To do this, we evaluate the task development and allocate time for refactoring, if necessary, for the implementation of this feature. Developers work thoroughly on new functionality and refactor the code.
As the team is just beginning to understand the project, it becomes acquainted with the feature and introduces it into the work, starting with understandable tasks and gradually increasing the level of complexity. Each feature should be documented and agreed upon with the customer.
Developers do not like to refactor code in the early stages. Since each specialist thinks they can create something better, you should make sure they do not rewrite what already works well.
At this point, it is important to strike a balance between bugfix, software upgrade, and feature implementation. To do this, we evaluated bugs and critical drawbacks, prioritized them on a par with features, and started using these features. This was an effective way to remove significant blunders and deficiencies.
We established a straightforward workflow for all team members, as well as effective communication with the customer.
In legacy projects, it is important to establish a clear process for accepting requests for feature implementation and changes. We decided to work on Agile. Once stakeholders brought us an idea, a PM was the first person to process it and ask questions to clarify basic requirements. After it became clear exactly what the customer wanted, the feature was documented, evaluated, and entered into the project backlog. After that, prioritization took place.
Tasks of various kinds (refactoring, bug fixing, feature implementation, etc.) were taken into a sprint as needed.
Testers were present at team meetings during the sprint planning. They took an active part in the discussion and studied the documentation for future changes. The specialists were not allowed to hold tests without having studied the documentation.
To maximize the comfort and fruitfulness of project activities, we deployed the following types of work environments:
- Development – initial development environment.
- Testing – the environment where features and fixes get from the Development environment.
- Stage – the environment that is fully relevant to production. It ensures the prevention of non-working functionality or bugs in final production.
- Production – a live version of the site.
Working with legacy projects is always difficult and tedious. But the Clever team has derived a formula for success that can greatly facilitate the process. The following steps should be taken in order to bring your legacy projects to the next level:
- Collect the initial data: documentation and initial technical assignment, access to Git or other code storage, a bug report showing all weaknesses, potential problems, elements that could fail or have not yet been fixed.
- Evaluate available features.
- Conduct a project audit to find deficiencies and bugs.
- Prioritize tasks with the customer.
- Work passionately according to the agreed-upon strategy.