“Agile Development”: Agile Methodologies Summary
Software development is a job that requires making the right decisions in a timely manner. CTOs, architects, tmlids, and the developers themselves regularly make a choice in favor of various tools, platforms, and frameworks.
But all decisions must be somehow "synchronized". One of the residents of Hacker News noted that he had to watch as five hundred developers in one large company were allowed to make some decisions on their own in isolation from the team. According to him, it was chaos. And although the team began to work faster, it moved nowhere, because later there were problems at the stages of software support.
To avoid such situations, a family of agile development processes is used. Their implementation allows the company management to increase the interest and motivation of employees, as well as to accelerate the delivery of the product to the customer. Recently, this topic has become increasingly popular, because the heads of the largest corporations pay attention to some Agile methodologies.
')
Therefore, we decided to start a series of posts on “flexible” methodologies in order to once again review their features, compare the options and help your companies optimize their processes. Today we are talking about scrum, kanban and extreme programming.
/ Flickr / Sebastian Sikora / CC
Scrum is a flexible software development framework that is considered the “default” methodology. For many, is a synonym for Agile. According to statistics for 2016 provided by VersionOne, Scrum is used by 58% of “flexible” companies. At the same time, it is supported by many SaaS platforms. For example, the ServiceNow solution, of which Agile Development is a part.
The methodology was developed in the late 80s - early 90s. The management process consists of fixed short iterations - sprints.
Using the Scrum methodology, a customer representative works closely with the development team, prioritizing the list of product requirements (Product Backlog). This list consists of bug fixes, functional and non-functional requirements - from everything that needs to be done to implement a working application.
The functional elements added to the backlog are called stories. Each task is estimated at a certain number of points. Points are an abstract metric and a variety of scales can be used to evaluate it ( for example , the Fibonacci series or powers of two).
Based on the list of customer requirements, the team determines the functions that it wants to implement, and begins its sprint. It usually lasts 30 days. At the end, the total points scored by the team for the sprint (speed) are calculated. This allows you to more clearly plan the following sprints.
Over the past ten years, programmers Ken Schwaber, Mike Beedle and Jeff Sutherland have made great efforts to develop Scrum. Ken Schwaber is the most active supporter of the framework, and his site is a good place to start his acquaintance with the methodology. He also released a book .
Scrum has gained immense popularity over its lifetime and is used by development teams, even in large companies. However, the community during this time revealed some of its shortcomings.
For example, among them they note an excessive focus on scoring. When planning, the team selects stories that it can complete by the end of the sprint, guided by the speed of the previous stage. The main purpose of these points is to make planning more reliable and provide a clear perspective.
However, there is a problem here: since the work of developers is estimated in points, they will try to earn more and optimize their activities for it. What does not lead to an improvement in the code base does not make it easier.
Another problem is lengthy mitapes. Moreover, meetings are held synchronously with all the participants in the development, which becomes a problem for specialists working remotely. People have to build many hours of meetings into their schedule for sharing information that can be transferred in a different way.
As for the immutability of stories during the sprint, on a large scale, this also leads to problems. Programmers do not have the ability to redistribute work when they discover new features. Scrum does not allow rebuilding the ship during sailing, so you have to wait until the end of the session to make changes.
A feature of Scrum is that this framework pays little attention to development practices. Therefore, some agile companies (about 10%) combine it with extreme programming (XP).
Extreme programming attracted attention in the late 90s. The concept originated in the Smalltalk community, and its authors are the developers Kent Beck (Kent Beck) and Ward Cunningham (Ward Cunningham), who wanted to form new software development practices made for people.
The first project created using the Extreme Programming methodology was the Chrysler Comprehensive Compensation (C3) payment control system in the mid-nineties. The term "extreme programming" appeared in 1997.
The concept is based on twelve methods:
XP strongly resembles Scrum and assumes that the customer interacts closely with the development team, setting priorities (stories). Programmers also evaluate, plan, and implement tasks in short iterations.
However, Extreme Programming places a strong emphasis on testing, which distinguishes it from Scrum. The methodology states that the developer cannot say that the code is written correctly until all the unit tests have passed. Therefore, XP often goes hand in hand with the Test Driven Development (TDD) development technique when a test is first written and then the logic for passing it.
But such a “test orientation” is also a lack of approach. To adapt XP, you need to invest in building an automated test infrastructure and continuous software deployment.
At the same time, if in the case of Scrum the company can send project managers to two-day courses, then in the case of extreme programming it is necessary to train the entire development team. Which is much more expensive. It is necessary to change the culture in the organization, combining several departments: XP requires testers, UI-designers, programmers, architects and users to work together.
/ Flickr / us army / cc
Scrum is still an effective methodology that is popular. Especially in combination with extreme programming. Together, their percentage of use among Agile teams reaches 68%.
However, today many teams are considering other options and pay attention to other methodologies. One of them was Kanban. CTO ConvertKit Grant Ammons (Grant Ammons) says that companies first adapt Scrum, which teaches them the necessary disciplines for software development, and then look for a more convenient alternative and turn to kanban.
Kanban is a technology for managing development, where the development process is viewed as a pipeline with requests for the implementation of functions from which advanced software comes.
Kanban originated as part of Toyota’s production system “just in time”, so the methodology eliminates unnecessary accumulation of tasks. For example, if testers test five functions in a week, and developers and analysts implement ten, then the “total throughput of the pipeline” is limited to five functions. This is necessary to avoid the accumulation of work with the QA-team, otherwise they may begin to “cut corners” and inadvertently pass a poor-quality product to the market.
In this case, you can also redistribute resources: when programmers and analysts have completed their standard, they can help with testing and writing automated tests. In the future, this will increase the capacity of the conveyor.
And kanban easily exposes such bottlenecks. In its simplest implementation, it is a large board with lined columns in which stickers-cards are placed. Bars are the stages of the development process, and stickers are work tasks. The numbers at the top of each bar show how many cards it is allowed to “save” in it.
However, as noted in the HN community, this approach also has certain disadvantages. In the same Scrum short sprints have a positive effect on the motivation of developers. Programmers know that the work on the product will end when the entire list of requirements for 30 days is completed. In the case of kanban, this is a constant and endless stream of tasks. However, there is a way out - a brief discussion of the task lists for the week (or two).
Also, due to its specificity, kanban is poorly suited for long-term planning and is inconvenient in work for large development teams (more than five people).
Finally, we note that the use of Agile methodologies imposes serious requirements on the experience of team members and their ability to effectively interact with each other. In addition, each more or less common methodology has its own strengths and weaknesses, as well as areas of application. For this reason, new frameworks appear and the “old” ones are being finalized.
PS A few more articles from our corporate blog:
But all decisions must be somehow "synchronized". One of the residents of Hacker News noted that he had to watch as five hundred developers in one large company were allowed to make some decisions on their own in isolation from the team. According to him, it was chaos. And although the team began to work faster, it moved nowhere, because later there were problems at the stages of software support.
To avoid such situations, a family of agile development processes is used. Their implementation allows the company management to increase the interest and motivation of employees, as well as to accelerate the delivery of the product to the customer. Recently, this topic has become increasingly popular, because the heads of the largest corporations pay attention to some Agile methodologies.
')
Therefore, we decided to start a series of posts on “flexible” methodologies in order to once again review their features, compare the options and help your companies optimize their processes. Today we are talking about scrum, kanban and extreme programming.
/ Flickr / Sebastian Sikora / CC
Scrum
Scrum is a flexible software development framework that is considered the “default” methodology. For many, is a synonym for Agile. According to statistics for 2016 provided by VersionOne, Scrum is used by 58% of “flexible” companies. At the same time, it is supported by many SaaS platforms. For example, the ServiceNow solution, of which Agile Development is a part.
The methodology was developed in the late 80s - early 90s. The management process consists of fixed short iterations - sprints.
Using the Scrum methodology, a customer representative works closely with the development team, prioritizing the list of product requirements (Product Backlog). This list consists of bug fixes, functional and non-functional requirements - from everything that needs to be done to implement a working application.
The functional elements added to the backlog are called stories. Each task is estimated at a certain number of points. Points are an abstract metric and a variety of scales can be used to evaluate it ( for example , the Fibonacci series or powers of two).
Based on the list of customer requirements, the team determines the functions that it wants to implement, and begins its sprint. It usually lasts 30 days. At the end, the total points scored by the team for the sprint (speed) are calculated. This allows you to more clearly plan the following sprints.
Over the past ten years, programmers Ken Schwaber, Mike Beedle and Jeff Sutherland have made great efforts to develop Scrum. Ken Schwaber is the most active supporter of the framework, and his site is a good place to start his acquaintance with the methodology. He also released a book .
Scrum has gained immense popularity over its lifetime and is used by development teams, even in large companies. However, the community during this time revealed some of its shortcomings.
For example, among them they note an excessive focus on scoring. When planning, the team selects stories that it can complete by the end of the sprint, guided by the speed of the previous stage. The main purpose of these points is to make planning more reliable and provide a clear perspective.
However, there is a problem here: since the work of developers is estimated in points, they will try to earn more and optimize their activities for it. What does not lead to an improvement in the code base does not make it easier.
Another problem is lengthy mitapes. Moreover, meetings are held synchronously with all the participants in the development, which becomes a problem for specialists working remotely. People have to build many hours of meetings into their schedule for sharing information that can be transferred in a different way.
As for the immutability of stories during the sprint, on a large scale, this also leads to problems. Programmers do not have the ability to redistribute work when they discover new features. Scrum does not allow rebuilding the ship during sailing, so you have to wait until the end of the session to make changes.
Extreme programming
A feature of Scrum is that this framework pays little attention to development practices. Therefore, some agile companies (about 10%) combine it with extreme programming (XP).
Extreme programming attracted attention in the late 90s. The concept originated in the Smalltalk community, and its authors are the developers Kent Beck (Kent Beck) and Ward Cunningham (Ward Cunningham), who wanted to form new software development practices made for people.
The first project created using the Extreme Programming methodology was the Chrysler Comprehensive Compensation (C3) payment control system in the mid-nineties. The term "extreme programming" appeared in 1997.
The concept is based on twelve methods:
- Test-driven development
- Planning game
- Customer is always there (Onsite customer)
- Pair programming
- Continuous integration
- Refactoring (Design improvement)
- Frequent small releases (Small releases)
- Ease of design (Simple design)
- System metaphor
- Collective code ownership
- Coding Standard
- 40-hour work week (Sustainable pace)
XP strongly resembles Scrum and assumes that the customer interacts closely with the development team, setting priorities (stories). Programmers also evaluate, plan, and implement tasks in short iterations.
However, Extreme Programming places a strong emphasis on testing, which distinguishes it from Scrum. The methodology states that the developer cannot say that the code is written correctly until all the unit tests have passed. Therefore, XP often goes hand in hand with the Test Driven Development (TDD) development technique when a test is first written and then the logic for passing it.
But such a “test orientation” is also a lack of approach. To adapt XP, you need to invest in building an automated test infrastructure and continuous software deployment.
At the same time, if in the case of Scrum the company can send project managers to two-day courses, then in the case of extreme programming it is necessary to train the entire development team. Which is much more expensive. It is necessary to change the culture in the organization, combining several departments: XP requires testers, UI-designers, programmers, architects and users to work together.
/ Flickr / us army / cc
Kanban
Scrum is still an effective methodology that is popular. Especially in combination with extreme programming. Together, their percentage of use among Agile teams reaches 68%.
However, today many teams are considering other options and pay attention to other methodologies. One of them was Kanban. CTO ConvertKit Grant Ammons (Grant Ammons) says that companies first adapt Scrum, which teaches them the necessary disciplines for software development, and then look for a more convenient alternative and turn to kanban.
Kanban is a technology for managing development, where the development process is viewed as a pipeline with requests for the implementation of functions from which advanced software comes.
Kanban originated as part of Toyota’s production system “just in time”, so the methodology eliminates unnecessary accumulation of tasks. For example, if testers test five functions in a week, and developers and analysts implement ten, then the “total throughput of the pipeline” is limited to five functions. This is necessary to avoid the accumulation of work with the QA-team, otherwise they may begin to “cut corners” and inadvertently pass a poor-quality product to the market.
In this case, you can also redistribute resources: when programmers and analysts have completed their standard, they can help with testing and writing automated tests. In the future, this will increase the capacity of the conveyor.
And kanban easily exposes such bottlenecks. In its simplest implementation, it is a large board with lined columns in which stickers-cards are placed. Bars are the stages of the development process, and stickers are work tasks. The numbers at the top of each bar show how many cards it is allowed to “save” in it.
However, as noted in the HN community, this approach also has certain disadvantages. In the same Scrum short sprints have a positive effect on the motivation of developers. Programmers know that the work on the product will end when the entire list of requirements for 30 days is completed. In the case of kanban, this is a constant and endless stream of tasks. However, there is a way out - a brief discussion of the task lists for the week (or two).
Also, due to its specificity, kanban is poorly suited for long-term planning and is inconvenient in work for large development teams (more than five people).
Finally, we note that the use of Agile methodologies imposes serious requirements on the experience of team members and their ability to effectively interact with each other. In addition, each more or less common methodology has its own strengths and weaknesses, as well as areas of application. For this reason, new frameworks appear and the “old” ones are being finalized.
PS A few more articles from our corporate blog:
Source: https://habr.com/ru/post/341924/
All Articles