Scrum Pitfalls - Motley Frames
I want to share practical experience in implementing flexible methodologies on high and medium complexity web development projects and warn against insidious risks.
In most simple Internet projects, the “simplification” of classic development processes worked well, flexibility helped, but in relatively large and complex, high-voltage sparks were observed with a partial lethal outcome.
Go.
')
There are flexible development methodologies (Agile), such as Scrum, simple and comprehended in a couple of days. And there are “tough”, weighty, requiring many months of immersion, such as RUP.
Flexible methodologies convince us to “believe” that because the requirements are constantly changing, you can fuck off the many years of experience in developing software absorbed by classical methodologies, the same “waterfall”, simplify everything drastically and throw yourself in the arms of “communist” freedom, honesty and equality.
Why be afraid of something? Crazy bearded experts talk about processes, artifacts, dependency matrices (Requirements Traceability Matrix) - and we are in a shirt, barefoot, once and ... let's program any Internet project for 3 sprints! Cheers, comrades, to victory.
So, the “simplification” offered by flexible methodologies is very conditional and insidious. “Relaxed” on the one hand, you will have to do a good deal on the other.
The worst thing that I had to contemplate in the field of software development is the senseless implementation of simple Scrum-type management frameworks with almost complete disregard for the necessary in such cases engineering practices of extreme programming (XP), leading to disastrous consequences both for the quality of the implemented projects and their deadlines execution.
Projects quickly turned into a dustbin and immediately went to a nursing home to die, without starting a full life.
It is tough, developed by blood and then XP practices, the practices of survival in chaos, and only able to balance the situation and run a successful, leading to the goal development process!
In the light of the above “horrors”, I want to speak in portions about the risks that lie in flexible software development methodologies using the example of Scrum and the methods of reducing them that are known to me.
Let's start with the team recruitment in real conditions of harsh reality.
Consider typical roles in a PHP / MySQL web development project.
In addition to general technical education and knowledge of the foundations of applied mathematics, an employee needs to thoroughly understand the technology / programming language, and not to google for any reason.
Unfortunately, there are no specialized higher educational institutions that train web developers.
Mostly self-taught, not possessing the necessary minimum. Sometimes these are former designers / testers who want salary increases - colleagues often do not understand why you need to add indexes to SQL tables, and there is nothing to say about relational algebra, OOP and theory of algorithms. At the same time, people "confidently" write "object-oriented" g ... code, sometimes associated with the processing of financial transactions, and quickly :-)
There is only one way out - to teach on your own, attach to a knowledgeable theory and a developer hardened in projects, send to Zend certification.
Good, experienced programmers, often knowing other, "complex" programming languages ​​like java, C # and passing PHP who have learned PHP in passing, are of course sometimes encountered, but rarely. There it is necessary to get hold of a team, then I will tell you why.
To control the quality of the work of “mostly inexperienced” programmers, I strongly recommend that you audit the code by an experienced, expensive programmer who is well versed in security issues and use auxiliary tools for partial checking for code tests.
If the code is not checked, then object-oriented perversions will arise and multiply, and the code, if not born, will become rotten.
Took in quotes. In general, the programmer should at least once in his life read the SQL standard and confidently design and work with the DBMS, but unfortunately this rarely happens. As a rule, a developer may know one DBMS well, but float heavily in another DBMS.
Therefore, sometimes they distinguish a special role of a SQL specialist, who can be both an analyst, and an architect, and a system administrator, if only they can be well versed in relational theory and specific DBMS.
There is no university for web designers either. Self-taught. The declarative theory of “mastering” is much simpler than programming, but it requires knowledge of a large number of features and subtleties, and therefore it became a special craft.
To control the quality of work, in principle, you can partially use automated means of checking for compliance with web standards (w3c) and inspect visually in different browsers.
A coder can, over time and after reading a few weighty books on software development theory and hard work, become a programmer, but this is rare.
A special role for the "particularly intelligent and thoughtful." Requires an analytical mind, attention to detail. Quite good analysts are obtained from physicists and mathematicians, but other specialties are also found. If the analyst learns UML or any other design methodology, then he will have a super analyst capable of expressing requirements in a language that the developer understands.
A very responsible role that requires in-depth knowledge of design patterns, serious development experience and, importantly, support for software systems. Unfortunately, architects are becoming only empirically, having failed more than one project. And to determine that the system problems with the architecture laid down sometimes can be not immediately, but after a certain time, when it is too late to change anything.
Some people think that the tester does the stupid and thankless job in the projects. Actually it is from ignorance. A good tester (there are no specialized universities, too) engaged in self-education can create a qualitative test plan and write automated tests, and a bad one will sluggishly and aimlessly poke through the pages of the site, leaving bugs alive.
There are courses from some vendors, such as RedHat, training system administrators, but without in-depth practice, a real system administrator is unlikely to succeed. And, as a rule, you can check the quality of work only after a serious accident when restoring data from a backup.
Now let's apply the practical knowledge about the roles in the team to the techniques declared in Scrum / XP and try to get a working solution.
As we see, the roles are all very different, requiring deep specific knowledge and experience. In practice, employees only partially mutually enrich each other with knowledge from different areas, but the cross-functionality that Scrum tells us does not smell. With a stretch we can talk about interchangeability only among representatives of one role, but even there people with different qualifications and experience do not always work.
If an expert is inexperienced, he must be followed by the more experienced. I do not recommend planting together (XP practice) two inexperienced people - they will make it 2 times worse.
It turns out that representatives of each role, in an amicable way, should be monitored by the “senior mentor”. This may be a functional manager (head of department) or a senior specialist (lead developer / analyst / system administrator) who has the necessary competence and is directly responsible for the quality of the work of the controlled person.
We understand that if you do not ensure the proper level of quality control of the work of specialized employees, we will get bad and expensive support in code, surface analytics, stupid architecture and leaky testing.
So we got “semi-pair” from pair programming, with the presence of specialized responsible specialists, and from the cross-functional team only a ghostly exchange of experience (who decides to give the coder to correct the billing code).
So, some practical risks considered. In the future post, we will talk about management risks - leadership, laxity in teams, collective irresponsibility, pseudo-progress and how to deal with it effectively.
In most simple Internet projects, the “simplification” of classic development processes worked well, flexibility helped, but in relatively large and complex, high-voltage sparks were observed with a partial lethal outcome.
Go.
')
Flexible and "tough"
There are flexible development methodologies (Agile), such as Scrum, simple and comprehended in a couple of days. And there are “tough”, weighty, requiring many months of immersion, such as RUP.
Flexible methodologies convince us to “believe” that because the requirements are constantly changing, you can fuck off the many years of experience in developing software absorbed by classical methodologies, the same “waterfall”, simplify everything drastically and throw yourself in the arms of “communist” freedom, honesty and equality.
Why be afraid of something? Crazy bearded experts talk about processes, artifacts, dependency matrices (Requirements Traceability Matrix) - and we are in a shirt, barefoot, once and ... let's program any Internet project for 3 sprints! Cheers, comrades, to victory.
So, the “simplification” offered by flexible methodologies is very conditional and insidious. “Relaxed” on the one hand, you will have to do a good deal on the other.
Agile is used, and XP practices are forgotten?
The worst thing that I had to contemplate in the field of software development is the senseless implementation of simple Scrum-type management frameworks with almost complete disregard for the necessary in such cases engineering practices of extreme programming (XP), leading to disastrous consequences both for the quality of the implemented projects and their deadlines execution.
Projects quickly turned into a dustbin and immediately went to a nursing home to die, without starting a full life.
It is tough, developed by blood and then XP practices, the practices of survival in chaos, and only able to balance the situation and run a successful, leading to the goal development process!
In the light of the above “horrors”, I want to speak in portions about the risks that lie in flexible software development methodologies using the example of Scrum and the methods of reducing them that are known to me.
Let's start with the team recruitment in real conditions of harsh reality.
HR risks
Consider typical roles in a PHP / MySQL web development project.
PHP programmer
In addition to general technical education and knowledge of the foundations of applied mathematics, an employee needs to thoroughly understand the technology / programming language, and not to google for any reason.
Unfortunately, there are no specialized higher educational institutions that train web developers.
Mostly self-taught, not possessing the necessary minimum. Sometimes these are former designers / testers who want salary increases - colleagues often do not understand why you need to add indexes to SQL tables, and there is nothing to say about relational algebra, OOP and theory of algorithms. At the same time, people "confidently" write "object-oriented" g ... code, sometimes associated with the processing of financial transactions, and quickly :-)
There is only one way out - to teach on your own, attach to a knowledgeable theory and a developer hardened in projects, send to Zend certification.
Good, experienced programmers, often knowing other, "complex" programming languages ​​like java, C # and passing PHP who have learned PHP in passing, are of course sometimes encountered, but rarely. There it is necessary to get hold of a team, then I will tell you why.
To control the quality of the work of “mostly inexperienced” programmers, I strongly recommend that you audit the code by an experienced, expensive programmer who is well versed in security issues and use auxiliary tools for partial checking for code tests.
If the code is not checked, then object-oriented perversions will arise and multiply, and the code, if not born, will become rotten.
"SQL Specialist"
Took in quotes. In general, the programmer should at least once in his life read the SQL standard and confidently design and work with the DBMS, but unfortunately this rarely happens. As a rule, a developer may know one DBMS well, but float heavily in another DBMS.
Therefore, sometimes they distinguish a special role of a SQL specialist, who can be both an analyst, and an architect, and a system administrator, if only they can be well versed in relational theory and specific DBMS.
Coder
There is no university for web designers either. Self-taught. The declarative theory of “mastering” is much simpler than programming, but it requires knowledge of a large number of features and subtleties, and therefore it became a special craft.
To control the quality of work, in principle, you can partially use automated means of checking for compliance with web standards (w3c) and inspect visually in different browsers.
A coder can, over time and after reading a few weighty books on software development theory and hard work, become a programmer, but this is rare.
Analyst
A special role for the "particularly intelligent and thoughtful." Requires an analytical mind, attention to detail. Quite good analysts are obtained from physicists and mathematicians, but other specialties are also found. If the analyst learns UML or any other design methodology, then he will have a super analyst capable of expressing requirements in a language that the developer understands.
Architect
A very responsible role that requires in-depth knowledge of design patterns, serious development experience and, importantly, support for software systems. Unfortunately, architects are becoming only empirically, having failed more than one project. And to determine that the system problems with the architecture laid down sometimes can be not immediately, but after a certain time, when it is too late to change anything.
Tester
Some people think that the tester does the stupid and thankless job in the projects. Actually it is from ignorance. A good tester (there are no specialized universities, too) engaged in self-education can create a qualitative test plan and write automated tests, and a bad one will sluggishly and aimlessly poke through the pages of the site, leaving bugs alive.
Sysadmin
There are courses from some vendors, such as RedHat, training system administrators, but without in-depth practice, a real system administrator is unlikely to succeed. And, as a rule, you can check the quality of work only after a serious accident when restoring data from a backup.
Now let's apply the practical knowledge about the roles in the team to the techniques declared in Scrum / XP and try to get a working solution.
Cross functionality in project teams is a myth
As we see, the roles are all very different, requiring deep specific knowledge and experience. In practice, employees only partially mutually enrich each other with knowledge from different areas, but the cross-functionality that Scrum tells us does not smell. With a stretch we can talk about interchangeability only among representatives of one role, but even there people with different qualifications and experience do not always work.
Quality control work - a hierarchy of responsibility
If an expert is inexperienced, he must be followed by the more experienced. I do not recommend planting together (XP practice) two inexperienced people - they will make it 2 times worse.
It turns out that representatives of each role, in an amicable way, should be monitored by the “senior mentor”. This may be a functional manager (head of department) or a senior specialist (lead developer / analyst / system administrator) who has the necessary competence and is directly responsible for the quality of the work of the controlled person.
We understand that if you do not ensure the proper level of quality control of the work of specialized employees, we will get bad and expensive support in code, surface analytics, stupid architecture and leaky testing.
So we got “semi-pair” from pair programming, with the presence of specialized responsible specialists, and from the cross-functional team only a ghostly exchange of experience (who decides to give the coder to correct the billing code).
So, some practical risks considered. In the future post, we will talk about management risks - leadership, laxity in teams, collective irresponsibility, pseudo-progress and how to deal with it effectively.
Source: https://habr.com/ru/post/118487/
All Articles