ТОП просматриваемых книг сайта:
Agile Transformation in IT-organizations. Алиса Олеговна Бобовникова
Читать онлайн.Название Agile Transformation in IT-organizations
Год выпуска 2023
isbn
Автор произведения Алиса Олеговна Бобовникова
Издательство Автор
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.
CHAPTER 3. IMPLEMENTING AGILE APPROACH IDEAS INTO PRACTICE. LET'S BREAK DOWN THE INSTRUMENTS AND TECHNIQUES
Let’s look at frameworks that are used to implement Agile Approach ideas into real practice, but first let’s explain what a framework is.
Framework is a ready-made set of tools that helps the developer to create a product quickly: a website, an application, an online store, a CMS system.
Imagine that you decided to assemble a toy car: it should drive and look almost like a real one. Obviously, there are several ways to solve this problem:
• the car can be assembled independently, from scratch: create all the parts manually or with machining equipment, do electronics and electrics, paint everything. So you can control the whole process, but it will take a lot of time;
• a similar car can be assembled from ready-made kits: body parts, engine, electronics will become modules that are important to choose and connect correctly. If desired, you can improve any module, but generally this is not necessary, everything will work right out of the box.
The framework is the same ready-made set, only for the developer. It saves the time and effort of a specialist who would have spent on creating basic things and correcting simple mistakes.
The most common Agile framework is Scrum.
Scrum is a set of rules allowing the team to establish a flexible workflow. Development is carried out in iterations, the goals of each iteration and the tasks of each team member are clearly outlined. Due to Scrum, companies can apply the principles and values of Agile and work on projects of any complexity. Agile and Scrum concepts are regularly confused, considering that Agile and Scrum are the same.
The difference lies in the scale of two approaches: Agile is a special way of thinking, a mindset. Scrum is an instruction for use. A clear plan describing each step of Agile implementing in product development. This is a methodology with specific stages, in which roles and events are clearly defined.
Scrum is based on empiricism and lean thinking.
EMPIRICISM asserts that the source of knowledge is experience, and decision-making is based on observations. Lean thinking reduces
14
This is a model, illustrating the three constraints interdependence: time, money and scale, as well as how changing one factor requires changing others.
15
A ready-made set of tools that helps a developer to quickly create a product: a website, an application, an online store etc.