The role of techir in Agile - Tetris game
You discussed with the Customer and agreed to release in the next release important features for the product, which are so long and impatiently waiting for Users. You're on the wings rushing to PlanningPoker, the assessment begins and the ...
- Let's not go into this module. The code is undocumented, everything will start to fail and crumble, especially billing.
- A team of fools worked before us, they learned to program on this project. If you climb here, the team will drop motivation ...
- How it works ... It is necessary to look at the code. The people who wrote have already left, there is no documentation. Month at least.
- We uploaded the data, and everything began to slow down. We must devote a sprint to the study of causes. (and so several sprints in a row)
You understand that something strange is happening, that the project is “sick”, that you could probably avoid it if you knew in advance ...
')
We will try to understand to whom “to beat the face” now and to otmutuzit whom prophylactically when the next project comes to us - to avoid such a collapse.
Old project
The situation is predictable. When we inherited a project, it often happens that the code is incomprehensible, but there is no documentation or it is hopelessly outdated. Developers at the mention of the name of the project begin to spit.
PlanningPoker identifies a problem - colleagues try to understand how a particular module is arranged to evaluate, HOW MUCH TIME TO ADD A FEATHER to this module, but - everything is so confusing that we understand with horror: in order to give an adequate assessment you need to spend several weeks analyzing this city ... okoda And to rewrite / rigidly refactor it will take months, if not more.
And still it is necessary to be able to refactor not only the code, applying design patterns with an understanding of their essence, but also successfully pull out the logic from the undocumented database with the internals.
Need a systematic approach. Who to charge with whom to agree?
New project
But this could be a real surprise for ProductOwner beginners! A new project - which is starting to decompose.
While the project is just beginning, there is no reason for concern. Grades on PlanningPoker are gradually becoming more accurate, team speed is increasing, regular demonstrations increase the mood and faith in achieving the goal of release. Clear peppy rhythm.
Symptom 1: Technical backlogs began to grow
Gradually, however, more and more tasks begin to appear in the technical backlog - there the developers put features to refactor. Yes, we know that the project code is not “rotten”, developers should be allowed to detect curves / complex points in the code, talk about them in retrospectives, and register this class of tasks in order to work with them in the background.
Sometimes it is a sign of ... the beginning of the end. The team, realizing that it went wrong, complicated the code that began to crumble before our eyes, trying to start overwriting it again and again - trying to allocate time for it at the next task distribution:
- We discussed here ... We wrote a module, used the ORM library - but it does not suit us, it is too complicated, we want to write requests to the database directly (2 months spent)
- We have complicated the object hierarchy of inheritance, the devil will not understand. It is necessary to rewrite (new project!, Give Kalash).
Symptom 2: “Unstable” sprints
Another sign of a possible end - the functionality written in the previous sprints for some reason ... does not stabilize :-). He rolls bugs and it takes more and more time to fix them. Yes, at some point the flow of bugs seems to stop - but with a minimal change in functionality - it opens with a new force. We should, in theory, accept changes in demands with open arms, and here it is scary to cough.
Symptom 3: "Brakes"
Things went swimmingly. But here we downloaded test data into the system and ... it went down. It turns out that not all programmers understand that the code should work practically “independently” of the amount of data; you cannot select all records from the table and process them in code, turning hundreds of megabytes into the memory, etc.
Often, to teach the system to work with the expected amount of data will require a serious rewriting, which can stretch into months (!). And then test, test ...
Symptom 4: The Matrix of "Independence"
There is also a terrible thing that only experienced fighters who have completed major projects know about. While the project is placed in the team in the head - there is no cause for concern. It is easy to add a feature - we are going and understand what will happen and where it will be reflected in the system, if we change the logic here and here.
But when the system / website becomes big, then ... people start to get lost. A simple example from life:
PO: Colleagues, you need to add support for an additional discount application algorithm .... Evaluate.
Developers: To do this, you need to fix the library here, fix the output template there. Probably (!) Everything.
So here. It turns out after the introduction of features ... flew several payment systems. Moreover, this was immediately recognized by the Clients and “positively” reacted.
And we know that there are dependency tracking tools, and they are used in “adult” development processes, because without them, the word "probably" in the team will be repeated more and more often.
Automated tests ... yes, they will test the code, and even then, if you write them right away and COMPETENTLY. And how do they test complex business requirements, dependencies between algorithms? We need other tools, already for analysts.
Complication - the cunning enemy
It seems that the larger the project, the more unmanaged and running it becomes - both for developers and for ProductOwner, and for the Customer.
Kashi is getting bigger.
The worst thing is that there is (in secret) a “point of no return”, so to speak, after which it is very and very difficult to return the project to a manageable state and it is cheaper to close it to hell. all are confused and everything is immensely buggy and smelly spreading.
To beat the face?
When you launch dozens of projects, you begin to analyze the causes of failures in a natural way and, following the spirit of retrospectives, draw conclusions. Years pass and an instinct is produced on the balance of the production process, which can probably be compared with the musical ear.
IMHO in a company using Agile should be a strong technical director, the spinal cord feeling BALANCE of the used methodologies and tools. Reading books on the development process will help in part - it is necessary instinct.
Moreover, the more complicated the projects, the more knowledge, experience and will is needed so that they do not pass the “point of no return”. Tehdir will sleep a little and a couple of projects will pass the point of no return - you can of course create a semblance of six months or a year of work, smile and show that everything is all right and under control, and then suddenly quit for an abstract reason.
Key tasks tehdir
So, we saw that in agile-development, the techirc should constantly win in Tetris - how many projects do not descend from above, PRODUCTION should be balanced and the complexity should not go off-scale. Always O (1) and good mood ;-):
- The architecture remains simple, due to the competent use, when necessary, of design patterns (Simple Design in XP). If tech-trained developers see complications in the spinal cord, refactoring begins. Or techirr puts strong experienced architects on complex projects.
- The project code is not “fainting” - developers, taught by technical support, have developed a sense of smell and set tasks for cleaning out the bad code in technical backlogs.
- The code is ready for large amounts of data - the developers are qualified, they understand what they write. Nevertheless, the technician prescribed mandatory load testing in the checklist of the project readiness.
- Either units and other types of autotests are immediately used, or they are used for complex parts of the project. Here it is also possible, sometimes, to fasten a kind of Continuous Intergration.
- The project must be correctly divided into modules and they are as independent as possible from each other - therefore, the change in one module most likely will not affect the rest of the system.
- Technical documentation is conducted either using automated tools (such as phpdoc), or a business process is set up and changes go to the documentation department.
- Analytical documentation, charts, database schemas and everything that analysts do - broken down into modules placed in the head and neatly maintained by them up to date. Analysts do not look at the code, but they must clearly understand all the business processes in the system / module in order to be able to design something further.
- Talented people remain in the team, because they are given to engage in interesting and challenging tasks. The teams have a respectful professional atmosphere that Tehdir is following, not allowing non-professional careerists to meet with people.
If such a person cannot be found - one thing remains, to build a complex megaformalized process with interchangeable employees. It will probably be more expensive and longer.
Total
In order for ProductOwner to be happy, to make features on an estimated time and to keep a confident movement on the release plan, so that a living creature called “Software Product” doesn’t erupt out of the fountains of sewage at the most unexpected moments, especially before customers - you need to find a competent and experienced technical director working according to the variety of the above-mentioned checklist, who senses the balance of processes and tools by the spinal cord.
Otherwise, you can't ride the agile horse.
- Let's not go into this module. The code is undocumented, everything will start to fail and crumble, especially billing.
- A team of fools worked before us, they learned to program on this project. If you climb here, the team will drop motivation ...
- How it works ... It is necessary to look at the code. The people who wrote have already left, there is no documentation. Month at least.
- We uploaded the data, and everything began to slow down. We must devote a sprint to the study of causes. (and so several sprints in a row)
You understand that something strange is happening, that the project is “sick”, that you could probably avoid it if you knew in advance ...
')
We will try to understand to whom “to beat the face” now and to otmutuzit whom prophylactically when the next project comes to us - to avoid such a collapse.
Old project
The situation is predictable. When we inherited a project, it often happens that the code is incomprehensible, but there is no documentation or it is hopelessly outdated. Developers at the mention of the name of the project begin to spit.
PlanningPoker identifies a problem - colleagues try to understand how a particular module is arranged to evaluate, HOW MUCH TIME TO ADD A FEATHER to this module, but - everything is so confusing that we understand with horror: in order to give an adequate assessment you need to spend several weeks analyzing this city ... okoda And to rewrite / rigidly refactor it will take months, if not more.
And still it is necessary to be able to refactor not only the code, applying design patterns with an understanding of their essence, but also successfully pull out the logic from the undocumented database with the internals.
Need a systematic approach. Who to charge with whom to agree?
New project
But this could be a real surprise for ProductOwner beginners! A new project - which is starting to decompose.
While the project is just beginning, there is no reason for concern. Grades on PlanningPoker are gradually becoming more accurate, team speed is increasing, regular demonstrations increase the mood and faith in achieving the goal of release. Clear peppy rhythm.
Symptom 1: Technical backlogs began to grow
Gradually, however, more and more tasks begin to appear in the technical backlog - there the developers put features to refactor. Yes, we know that the project code is not “rotten”, developers should be allowed to detect curves / complex points in the code, talk about them in retrospectives, and register this class of tasks in order to work with them in the background.
Sometimes it is a sign of ... the beginning of the end. The team, realizing that it went wrong, complicated the code that began to crumble before our eyes, trying to start overwriting it again and again - trying to allocate time for it at the next task distribution:
- We discussed here ... We wrote a module, used the ORM library - but it does not suit us, it is too complicated, we want to write requests to the database directly (2 months spent)
- We have complicated the object hierarchy of inheritance, the devil will not understand. It is necessary to rewrite (new project!, Give Kalash).
Symptom 2: “Unstable” sprints
Another sign of a possible end - the functionality written in the previous sprints for some reason ... does not stabilize :-). He rolls bugs and it takes more and more time to fix them. Yes, at some point the flow of bugs seems to stop - but with a minimal change in functionality - it opens with a new force. We should, in theory, accept changes in demands with open arms, and here it is scary to cough.
Symptom 3: "Brakes"
Things went swimmingly. But here we downloaded test data into the system and ... it went down. It turns out that not all programmers understand that the code should work practically “independently” of the amount of data; you cannot select all records from the table and process them in code, turning hundreds of megabytes into the memory, etc.
Often, to teach the system to work with the expected amount of data will require a serious rewriting, which can stretch into months (!). And then test, test ...
Symptom 4: The Matrix of "Independence"
There is also a terrible thing that only experienced fighters who have completed major projects know about. While the project is placed in the team in the head - there is no cause for concern. It is easy to add a feature - we are going and understand what will happen and where it will be reflected in the system, if we change the logic here and here.
But when the system / website becomes big, then ... people start to get lost. A simple example from life:
PO: Colleagues, you need to add support for an additional discount application algorithm .... Evaluate.
Developers: To do this, you need to fix the library here, fix the output template there. Probably (!) Everything.
So here. It turns out after the introduction of features ... flew several payment systems. Moreover, this was immediately recognized by the Clients and “positively” reacted.
And we know that there are dependency tracking tools, and they are used in “adult” development processes, because without them, the word "probably" in the team will be repeated more and more often.
Automated tests ... yes, they will test the code, and even then, if you write them right away and COMPETENTLY. And how do they test complex business requirements, dependencies between algorithms? We need other tools, already for analysts.
Complication - the cunning enemy
It seems that the larger the project, the more unmanaged and running it becomes - both for developers and for ProductOwner, and for the Customer.
Kashi is getting bigger.
The worst thing is that there is (in secret) a “point of no return”, so to speak, after which it is very and very difficult to return the project to a manageable state and it is cheaper to close it to hell. all are confused and everything is immensely buggy and smelly spreading.
To beat the face?
When you launch dozens of projects, you begin to analyze the causes of failures in a natural way and, following the spirit of retrospectives, draw conclusions. Years pass and an instinct is produced on the balance of the production process, which can probably be compared with the musical ear.
IMHO in a company using Agile should be a strong technical director, the spinal cord feeling BALANCE of the used methodologies and tools. Reading books on the development process will help in part - it is necessary instinct.
Moreover, the more complicated the projects, the more knowledge, experience and will is needed so that they do not pass the “point of no return”. Tehdir will sleep a little and a couple of projects will pass the point of no return - you can of course create a semblance of six months or a year of work, smile and show that everything is all right and under control, and then suddenly quit for an abstract reason.
Key tasks tehdir
So, we saw that in agile-development, the techirc should constantly win in Tetris - how many projects do not descend from above, PRODUCTION should be balanced and the complexity should not go off-scale. Always O (1) and good mood ;-):
- The architecture remains simple, due to the competent use, when necessary, of design patterns (Simple Design in XP). If tech-trained developers see complications in the spinal cord, refactoring begins. Or techirr puts strong experienced architects on complex projects.
- The project code is not “fainting” - developers, taught by technical support, have developed a sense of smell and set tasks for cleaning out the bad code in technical backlogs.
- The code is ready for large amounts of data - the developers are qualified, they understand what they write. Nevertheless, the technician prescribed mandatory load testing in the checklist of the project readiness.
- Either units and other types of autotests are immediately used, or they are used for complex parts of the project. Here it is also possible, sometimes, to fasten a kind of Continuous Intergration.
- The project must be correctly divided into modules and they are as independent as possible from each other - therefore, the change in one module most likely will not affect the rest of the system.
- Technical documentation is conducted either using automated tools (such as phpdoc), or a business process is set up and changes go to the documentation department.
- Analytical documentation, charts, database schemas and everything that analysts do - broken down into modules placed in the head and neatly maintained by them up to date. Analysts do not look at the code, but they must clearly understand all the business processes in the system / module in order to be able to design something further.
- Talented people remain in the team, because they are given to engage in interesting and challenging tasks. The teams have a respectful professional atmosphere that Tehdir is following, not allowing non-professional careerists to meet with people.
If such a person cannot be found - one thing remains, to build a complex megaformalized process with interchangeable employees. It will probably be more expensive and longer.
Total
In order for ProductOwner to be happy, to make features on an estimated time and to keep a confident movement on the release plan, so that a living creature called “Software Product” doesn’t erupt out of the fountains of sewage at the most unexpected moments, especially before customers - you need to find a competent and experienced technical director working according to the variety of the above-mentioned checklist, who senses the balance of processes and tools by the spinal cord.
Otherwise, you can't ride the agile horse.
Source: https://habr.com/ru/post/122091/
All Articles