Читать книгу Agile Transformation in IT-organizations - - Страница 3

Let's see what approaches also exist in the world of software development besides the agile approach. First of all, this is the previously mentioned cascade methodology, also called "waterfall". We have already learned that in 1970 Dr. Winston Royce defined Waterfall methodology and suggested its basic principles:

• Program design comes first. Program designers work on the design of the system, not developers. Designers allocate e data processing models: database scheme, resources, some kind of non-functional requirements, interface, etc. Then an overview document must be prepared. The document should be understandable, informative, and current. Each team member must have an understanding of the system, and at least one person must have a deep understanding.

• Document the design. Some (in fact most) developers may wonder how much documentation is needed. Royce gives a simple answer: “Quite a lot”. Moreover, he says: “If the documentation is in serious default, my first recommendation is simple. Replace the project management. Stop all activities not related to documentation. Bring the documentation up to acceptable standards.”

Why documentation is important? Royce gives some points:

• documentation is a way of effective communication;

• during the early phase, the documentation is the specification and is the design;

• during the testing phase, the documentation can be considered as acceptance criteria;

• the documentation help newcomers to understand the system better.

• Do it twice. If your system is original, you want to verify your ideas or concept. Royce recommends creating some kind of MVP (Minimum Viable Product)11 of your product to check the ideas. Then, the second version of your product will be finally delivered. The first version may not be provided to final customers/users, but stakeholders12 want to see a prototype of the product. It may lead to requirement changes, and it is an effective way of the development process. The final version of the product will be closer to market needs.

• Plan, control, and monitor testing. Testing is one of the most important phases of the SDLC (Software Development Life Cycle)13. You check your ideas and concepts, verify implemented system comparing it with system design. Royce recommends inviting the other persons to verify your system. He says that it would be more effective to give a big part of the testing to people who did not contribute to the system during the previous phases. The documentation will help them to test the system better.

• Involve the customer. Your project customer and stakeholders should be involved in all phases of the development. They will help to design and implement a system that will meet their needs closer. Moreover, the stakeholder may change their opinion about the system and give new requirements. As a Project Manager you should meet the changes with pleasure because after all your customer will be satisfied.

Waterfall is based on a logical sequence of steps that must be taken throughout the software development lifecycle. Each stage is coordinated by competent employees, documented and passed on.

Although the popularity of the Waterfall model has waned in recent years, but the nature of the sequential process used in the waterfall method is intuitively close to developers.

The model proposed by Dr. Royce is extremely simple and clear. It consists of several blocks, each of them covers its own area of responsibility.

Let's look closer at the difference between Agile and Waterfall methodologies.

In management, there is a concept of a project management triangle14:

It includes the amount of work, time and quality. It is important to note that the balance in any methodology is created due to a system of assumptions, so in cascade approach quality can be reduced, and in Agile the amount of work can easily grow.

The project management triangle clearly displays the so-called triple limitation problem associated with the need to balance the scope of the project, its cost and time for implementation without compromising the quality of the final product. Taking into consideration the concept of project management triangle, the difference between approaches will look like this:

In recent years, the waterfall model has been losing its leading position to more flexible methodologies. This is due to the general dynamics in IT, when teams of 5-9 people are responsible for software development, and the deadline can be easily shifted due to the increase in functionality.

Nevertheless, the cascade model is still relevant for large projects and organizations:

• It is resistant to personnel changes. Developers can come and go throughout the life cycle of the project, but thanks to detailed documentation, this practically does not affect the timing of the project;

• Waterfall model forces developers involved in the project to be disciplined and to stay within the plan. If necessary, a management body responsible for decision-making is added to the general model, while performers are required to work within the system framework15;

• Flexibility in the early stages. Changes in early phases can be made immediately and with minimal effort, since they are not backed up by code. Thus, the customer and the contractor have a significant time margin for a radical change in the concept of software work;

• Focus on deadlines and finances. Due to the fact that each stage completely outlines the contour of the future software, all developers understand their role, the boundaries of work and deadlines. This allows you to cooperate with the customer knowing the real cost of development and makes, therefore, the project model attractive.

In the 1970s, Royce's ideas were relevant. But after almost 50 years, the cascade development method is less and less suitable for IT:

• non-adaptive software structure. At the first stages, the waterfall model can be flexible, but if problems in the overall structure are identified during the testing phase, this entails deplorable consequences in the form of disrupted deadlines and even customer failures;

• ignores the end user. The lower the process progresses in the waterfall, the less the role of the customer in it, not to mention the users he represents. Making any changes to the functionality of the software starts the entire chain of stages anew, so the products obtained by the cascade model are far from targeting the mass user;

• later testing. It is here that mistakes made at each of the stages are most often identified. More flexible methodologies use testing as a fundamental operation that occurs continuously. Waterfall, on the other hand, admits low qualifications of employees at each stage and poor quality of execution, because with late testing, problems cannot be solved fundamentally, only with the help of "patches".

Let's fix both approaches pros and cons:

Everything seems to be transparent, but in practice the question often arises which methodology to apply in each specific case. This scheme helps us mostly to make the right choice:

It turns out that the cascade methodology is an excellent solution in terms of deadlines and reporting, but very weak in terms of quality.

Despite the fact that these 3 points are increasingly rare in real practice, the cascade model will be popular and in demand for a long time because of its clear organization. This means that any professional developer should understand its basic principles and be ready to exist within the framework of this approach.

LET'S SUMMARIZE WHAT WE’VE LEARNED IN THIS CHAPTER:

Agile and Waterfall are the most common but opposite to each other software development approaches. While commending the waterfall methodology, it is necessary to move forward and look ahead, addressing contemporary challenges here and now. Agile is just what you need for this. We have also learned, that:

• software development methodologies should be evaluated using project management triangle;

• Agile methodology gained great popularity and changed software development forever by now;

• Waterfall or Cascade methodology is still in demand, so developers should be ready to exist within this approach.