Are we agile or agile us?
What is the main problem in software development (and maybe in general in any work)? When I asked a question to my colleagues, I received different answers: changes in requirements, mismatches of expectations, quality of code, interaction with other teams ... summing up for myself - communication is one of the most important problems.
During communication, everyone understands everything in his own way, interprets something differently than what was said. The customer has a certain image in his head that he is trying to convert into words and pictures, the developer, hearing these words, converts them in his head into some kind of his own image. And in this chain there can be many links.
Trying to solve this problem, people write a detailed statement of work. But does this solve the problem? The same questions, as I see it, were asked by Bob Martin and Martin Fowler together with their colleagues when they wrote Agile Manifest in February 2001. Let's try to understand this issue together, and the Agile manifesto itself.
In the winter of 2000 there was a meeting of the leaders of the so-called Extreme Programming, they discussed development methodologies and as a result began to propose some Light methodologies. Few people are interested (I do not want to offend anyone), most likely they made more jokes on this topic. However, several outsiders of that meeting a year later organized their own. It all started with the fact that Bob Martin (he wrote a well-known book about the quality of the code), did a mailing to the leaders of the last meeting - let's get together and talk. Actually nothing concrete. They sparred for a while about the place and time. As a result, gathered on February 11, 2001, in the state of Utah, at a ski resort. 17 people from the development field, including Bob Martin, Martin Fowler, and others. They drank, Fowler went skiing, and after discussions, Agile Manifest was born.
')
In principle, all the most important can be transferred literally by a page of text that can be read here .
But like everything short and meticulously thought out, it was not easy for me personally to understand this just by reading. Therefore, let us consider in detail what those people who signed the Agile manifest had in mind.
At first glance, this may seem like a call to throw away all Jira projects, bug trackers, time loggers and other tools and all configured processes. What could be simpler is someone who does what is verbally discussing with colleagues. If only everyone was happy. But it looks somewhat utopian, right?
This principle suggests that when building the process of developing anything, it is important to remember what it is done for, for whom and for what purpose. It makes little sense to create a process for the sake of the process itself. Because the work will eventually be done by people, we are with you. What will happen if the whole spark, the whole interest in our eyes is replaced by a task in yutrek or bugs in jire? A penny worth a coherent process that provides complete security to the customer, but does not solve the real problems of development. Bureaucratic (formal) details can easily lead to the loss of people on a project. I tend to think the same goes for planning. When was the last time you did planning, which in the end at least 60-70 percent turned out to be accurate?
In my opinion, this principle of the manifesto could sound like this:
What is the team developing at all? Product for customer.
If interpreted as it is, in the forehead, I think many will agree. But what else do you see here? Personally, I see here that working, and working on time product, is more important than perfectly written code. These are cruel and terrible words in many ways, I shouldn’t say that. But all my career I, learning from different people, became more and more convinced of the thought - if I choose a project that is ideal in terms of code and architecture and a project that is not very beautiful inside, but which benefits the world. And yes, I will improve it as much as I can.
And then you should think for a minute. And what can you do to make these problems less frequent? So that we do not have to choose between refactoring the module and developing a new feature?
Pay attention to the item about technical excellence. Keeping the code in good (necessary) and sufficient quality, we transfer changes in requirements and, accordingly, changes in code much more easily.
All principles, I remind you, this is not denial. One does not exclude the other. This is about setting priorities. Everything is important - and the product, and the quality of the code, and documentation. But what to choose, when to choose? Working in a certain balance between quality and product, it is easier to put a product in priority without denying quality.
As an example of life, I recall the work on a banking project for a Russian customer. The work was carried out with the participation of analysts and strictly volume TK. Every six months, the manager went to the head office of the customer and showed the results of the work. It is not difficult to guess that, as a rule, the results differed significantly from the customer's expectations. The accountant of the customer, who saw the new system for the first time, and generally found out that it is being created, was in a state of horror - there was nothing similar to his usual process of working in the new system. Which brings us to the next topic.
With this statement you need to be very careful. And again, remember that the right side of the statement is not denied. On the contrary, we say that the contract is important. Just when we weigh the terms of the contract and cooperation, the right long-term partnership, the relationship will be more important. Without denying the second. I focus on this kind of attention because we live in the real world and we sometimes have to work with very different customers. There are cases when the customer can use naivety to get rid of the conditions that are unacceptable for developers due to his contract.
Nevertheless, if we talk about a certain abstract good customerin a vacuum , then maintaining long-term relationships that will lead to new projects is more important.
How to achieve understanding and compliance expectations throughout the project?
At the same time, of course, you should not forget about confirming the agreements for your own safety. There are by the way (fortunately rarely) customers who refuse to pay at all after the agreements.
Whatever the customer, the activity of the developer is always useful.
I would add from myself that this should work in both directions.
This leads us to a logical continuation - changes in work and plans. Few people like to make changes, it is in human nature, if you think about it. Any system tends to a certain point of balance and immutability. But it is development that is always associated with movement and change.
The existence of a plan as such is not denied. On the contrary - the plan is important. But it is even more important to be ready to change it, if at some point we understood that this plan no longer works in the current conditions.
An example from the practice of my colleagues is a project for the tax inspection of one of the CIS countries. The state project is essentially TK, legislation, and there is no talk of ajaila. But the team had to show flexibility at the moment when the state in the customer’s country changed its tax legislation so that the project would have no meaning at all in the form in which it was planned. I had to change the TZ and redo the almost finished project so that the customer could use it. Otherwise - there would be no point in the work, well, except perhaps earnings as such.
Perhaps this is not the most illustrative example, since the changes were triggered by external factors. On the other hand, the customer can, again due to external factors, simply come to the need for changes in requirements. Otherwise, he will not get a competitive advantage.
This all affects a little sore subject for me. And what if we are doing a project for a whole year, and then a year later the customer says - ok, you are great, and now we put all this in the archive, we will not use it and start a new project. I am rather painful to this, I had a similar experience. But really - what happened? The work done has helped the customer to understand that the chosen path is incorrect. Or ineffective. To gain a competitive advantage, you need to work differently, to do another project. And he got this knowledge with our help.
What aspects of our work will help smooth out these corners and make flexibility not so frightening?
At the same time, we live in the real world, with real people, where no judgment, including this, should be raised to an absolute. Yes, changes are welcome when they lead to adding value to the final product. But it is important to observe the balance. If we make endless changes, we will never release a product in production. Therefore, at some point you should say - stop, we release the product, check everything in practice, and begin to make version two, which will contain these changes. Each time specifying the customer - what value he sees in a particular change.
Recently read a phrase on Facebook,
The creators of the Agile Manifesto do not prescribe any rules, in some ways even the opposite. But they raise important issues in our work - interactions of people, developers and customers, readiness for changes. These principles are important in nature. With the indisputable importance of documentation, contracts, processes and planning, human interaction, readiness for valuable changes and bringing something useful to the world is more important.
During communication, everyone understands everything in his own way, interprets something differently than what was said. The customer has a certain image in his head that he is trying to convert into words and pictures, the developer, hearing these words, converts them in his head into some kind of his own image. And in this chain there can be many links.
Trying to solve this problem, people write a detailed statement of work. But does this solve the problem? The same questions, as I see it, were asked by Bob Martin and Martin Fowler together with their colleagues when they wrote Agile Manifest in February 2001. Let's try to understand this issue together, and the Agile manifesto itself.
Story
In the winter of 2000 there was a meeting of the leaders of the so-called Extreme Programming, they discussed development methodologies and as a result began to propose some Light methodologies. Few people are interested (I do not want to offend anyone), most likely they made more jokes on this topic. However, several outsiders of that meeting a year later organized their own. It all started with the fact that Bob Martin (he wrote a well-known book about the quality of the code), did a mailing to the leaders of the last meeting - let's get together and talk. Actually nothing concrete. They sparred for a while about the place and time. As a result, gathered on February 11, 2001, in the state of Utah, at a ski resort. 17 people from the development field, including Bob Martin, Martin Fowler, and others. They drank, Fowler went skiing, and after discussions, Agile Manifest was born.
')
In principle, all the most important can be transferred literally by a page of text that can be read here .
But like everything short and meticulously thought out, it was not easy for me personally to understand this just by reading. Therefore, let us consider in detail what those people who signed the Agile manifest had in mind.
Agile Principles
That is, without denying the importance of what is right,This is a very important aspect that must be constantly kept in mind, reading the manifesto, and indeed in the work every day. Let's discuss the main statements of the manifesto.
we still value more that left.
People and interaction is more important than processes and tools.
At first glance, this may seem like a call to throw away all Jira projects, bug trackers, time loggers and other tools and all configured processes. What could be simpler is someone who does what is verbally discussing with colleagues. If only everyone was happy. But it looks somewhat utopian, right?
This principle suggests that when building the process of developing anything, it is important to remember what it is done for, for whom and for what purpose. It makes little sense to create a process for the sake of the process itself. Because the work will eventually be done by people, we are with you. What will happen if the whole spark, the whole interest in our eyes is replaced by a task in yutrek or bugs in jire? A penny worth a coherent process that provides complete security to the customer, but does not solve the real problems of development. Bureaucratic (formal) details can easily lead to the loss of people on a project. I tend to think the same goes for planning. When was the last time you did planning, which in the end at least 60-70 percent turned out to be accurate?
In my opinion, this principle of the manifesto could sound like this:
Processes for people, not people for processesHow does the manifesto suggest we get closer to the implementation of this principle?
- The project should work motivated professionals.
- Direct communication is the most practical and effective.
- The best requirements and architectural solutions are born from self-organizing teams.
- The team must constantly analyze their work and optimize the process.
What is the team developing at all? Product for customer.
A working product is more important than comprehensive documentation.
If interpreted as it is, in the forehead, I think many will agree. But what else do you see here? Personally, I see here that working, and working on time product, is more important than perfectly written code. These are cruel and terrible words in many ways, I shouldn’t say that. But all my career I, learning from different people, became more and more convinced of the thought - if I choose a project that is ideal in terms of code and architecture and a project that is not very beautiful inside, but which benefits the world. And yes, I will improve it as much as I can.
And then you should think for a minute. And what can you do to make these problems less frequent? So that we do not have to choose between refactoring the module and developing a new feature?
- A working product should be released as often as possible.
- A working product is the main indicator of progress.
- Constant attention to technical excellence and quality increases project flexibility.
- Simplicity and minimization are needed.
Pay attention to the item about technical excellence. Keeping the code in good (necessary) and sufficient quality, we transfer changes in requirements and, accordingly, changes in code much more easily.
All principles, I remind you, this is not denial. One does not exclude the other. This is about setting priorities. Everything is important - and the product, and the quality of the code, and documentation. But what to choose, when to choose? Working in a certain balance between quality and product, it is easier to put a product in priority without denying quality.
As an example of life, I recall the work on a banking project for a Russian customer. The work was carried out with the participation of analysts and strictly volume TK. Every six months, the manager went to the head office of the customer and showed the results of the work. It is not difficult to guess that, as a rule, the results differed significantly from the customer's expectations. The accountant of the customer, who saw the new system for the first time, and generally found out that it is being created, was in a state of horror - there was nothing similar to his usual process of working in the new system. Which brings us to the next topic.
Cooperation with the customer is more important than negotiating the terms of the contract
With this statement you need to be very careful. And again, remember that the right side of the statement is not denied. On the contrary, we say that the contract is important. Just when we weigh the terms of the contract and cooperation, the right long-term partnership, the relationship will be more important. Without denying the second. I focus on this kind of attention because we live in the real world and we sometimes have to work with very different customers. There are cases when the customer can use naivety to get rid of the conditions that are unacceptable for developers due to his contract.
Nevertheless, if we talk about a certain abstract good customer
How to achieve understanding and compliance expectations throughout the project?
- Throughout the project, developers and representatives of the business of the customer should work together every day.
- Direct communication is the most practical and effective.
At the same time, of course, you should not forget about confirming the agreements for your own safety. There are by the way (fortunately rarely) customers who refuse to pay at all after the agreements.
Whatever the customer, the activity of the developer is always useful.
I would add from myself that this should work in both directions.
This leads us to a logical continuation - changes in work and plans. Few people like to make changes, it is in human nature, if you think about it. Any system tends to a certain point of balance and immutability. But it is development that is always associated with movement and change.
Readiness for change is more important than following the original plan.
The existence of a plan as such is not denied. On the contrary - the plan is important. But it is even more important to be ready to change it, if at some point we understood that this plan no longer works in the current conditions.
An example from the practice of my colleagues is a project for the tax inspection of one of the CIS countries. The state project is essentially TK, legislation, and there is no talk of ajaila. But the team had to show flexibility at the moment when the state in the customer’s country changed its tax legislation so that the project would have no meaning at all in the form in which it was planned. I had to change the TZ and redo the almost finished project so that the customer could use it. Otherwise - there would be no point in the work, well, except perhaps earnings as such.
Perhaps this is not the most illustrative example, since the changes were triggered by external factors. On the other hand, the customer can, again due to external factors, simply come to the need for changes in requirements. Otherwise, he will not get a competitive advantage.
This all affects a little sore subject for me. And what if we are doing a project for a whole year, and then a year later the customer says - ok, you are great, and now we put all this in the archive, we will not use it and start a new project. I am rather painful to this, I had a similar experience. But really - what happened? The work done has helped the customer to understand that the chosen path is incorrect. Or ineffective. To gain a competitive advantage, you need to work differently, to do another project. And he got this knowledge with our help.
What aspects of our work will help smooth out these corners and make flexibility not so frightening?
- Regular and early software delivery.
- Changes are welcome even in the later stages.
- Changes help provide a competitive advantage to the customer.
At the same time, we live in the real world, with real people, where no judgment, including this, should be raised to an absolute. Yes, changes are welcome when they lead to adding value to the final product. But it is important to observe the balance. If we make endless changes, we will never release a product in production. Therefore, at some point you should say - stop, we release the product, check everything in practice, and begin to make version two, which will contain these changes. Each time specifying the customer - what value he sees in a particular change.
Recently read a phrase on Facebook,
if you are not ashamed of your product, then you entered the market too lateQuite accurately reflects the essence of the above. We must look for a certain balance point in which the product will already be sufficiently ready for the next release in terms of changes, and in which we have not yet begun to spend too much effort on minor changes.
Instead of summing up
The creators of the Agile Manifesto do not prescribe any rules, in some ways even the opposite. But they raise important issues in our work - interactions of people, developers and customers, readiness for changes. These principles are important in nature. With the indisputable importance of documentation, contracts, processes and planning, human interaction, readiness for valuable changes and bringing something useful to the world is more important.
Source: https://habr.com/ru/post/443842/
All Articles