How to avoid a zoo or give users working buttons ...
I consider starting this article with various introductory materials about the “Great Power of SCRUM” and the “Wrongness of Waterfall Methodology” as a waste of time, since there are already many resources on the Internet that allow you to learn everything: from the history of the prerequisites for creating technologies to all current implementations. As the saying goes: "He who seeks will always find ..." (c) :-).
I want to share some experience and even most likely my opinion on the "existing software zoo" in some IT companies, namely approaches and implementations.
So, let's begin…
')
Naturally, in order to write a new or improve an existing product, you first need to research the market, analyze the need of customers, write a bunch of some ridiculous concepts and TK, in which for “more fear and power of the system” it is necessary to apply such expressions as: based on existing artifacts, the developed meta model will help real users ... ", it is necessary to use only terms and abbreviations, and of course the description of" spherical horses in vac mind. " Then it is necessary to analyze in detail all these concepts, to acquire millions more models: from simple IDEF-diagrams to huge UML-models with all sorts of associations, aggregations and other "attributes". The result is more and more new "spiders". End users do not care for these models, diagrams, etc., they need working buttons ...
After this, development begins directly, programmers begin to "rivet" what was intended, as was written in the statement of work. Let's skip the documentation and testing ... let's go straight to the exit of the product to the market. Marketers have developed a bunch of pieces of paper about the release of the product “SuperMegaSystemPro”, which allows not only to be “a system that automates so-and-so”, but also (and without too much modesty) ... she ... she ... she generally allows you to "automate the whole world" :-). It seems all is well, the system is powerful, modern, but for some reason the customers are unhappy ... like the system is about everything, and in fact there is nothing. As a result, the existing products begin to scold all those who feel like it, and the implementers in Tikhory using the SDK (if they have one) “rivet” more and more new plugins, if only the customer was satisfied. The consequence, the zoo is growing ...
Existing software problems are directly "on the surface", they do not need to be sought, and even more so to pull out of the depths. But nevertheless, new discussions begin, new concepts ... as a result, "who is in the forest, who is on firewood" ... but most importantly, the existing flaws are veiled by succinct terms and as a result, the new system has only become more complicated and incomprehensible. Sorry for the time spent (2-5 years), and even more so sorry to throw out "tons of code", because programmers are not to blame.
After the demagogy about the “waterfall approach” I divorced :-) it makes sense to move on to a real working technology SCRUM. This technology really helps to revitalize products and contributes to the development of new and high-quality products.
The initiative development team decided to work on SCRUM, trying to correct the existing state of affairs. A team was formed consisting of: programmers, analysts and testers, in which, as it should be, the technology was ProductOwner with its ProductBacklog and SCRUM-master.
Process
We combined the practice of SCRUM with some XP practices (eXtreme Programming). SCRUM allows you to solve issues of management and organization, and XP specializes in engineering practices. We borrowed from XP: pair programming, refactoring, CodeReview, and a style description of the code. Also on retrospectives, we have identified for ourselves a number of rules that we follow. For designing a quality GUI, we use the practice of using characters.
We use only lightweight documentation: the DB diagram and the UML model, which grow only during development, respectively, are not such terrible spiders as described above.
Planning
The sprint planning in our team lasts almost the whole day, BUT, if you poorly plan a sprint, the iteration can simply be overwhelmed. Therefore, planning is the most important part of any SCRUM project.
To calculate the ideal clock, we use a focus factor of 0.4. In principle, such an indicator is average for all iterations and is optimal, since we usually manage to complete planned tasks on time.
Planning usually takes place near the “wall of design” (boards with markers) or at a table with a computer, where you can visually see the previous functionality and the GUI. Some dialogues are drawn immediately on the board and photographed, then these photos will be involved in the actual execution of tasks. To assess the complexity we use PlanningPoker, almost all tasks are tested, which allows you to immediately identify all the errors.
SCRUM - rally
Daily meetings are held 2 times a day near the SCRUM board. After the meeting is a mark on the graph of combustion. The task is considered completed, i.e. transferred to "Done", only after testing. The programmer can take the next task in “InProgress” only after the analyst has approved the previous task that was taken for execution. The combustion diagram is "hammered" by the Scrum Master. In order not to exceed the 15-minute time limit, the meeting is held standing. At the meeting, we determine what we have done, what we will do next, what problems. We try not to discuss technical details, but it does not always work. Usually the meeting lasts no more than 10 minutes. If some technical problems were identified at the meeting, they are discussed after a scrum meeting near the “design wall” (a board with markers).
SCRUM - board
As a scram-board we use an ordinary cork board. We divided the board area into three parts: ToDo (what needs to be done), InProgress (Done), Done (Done).
However, we also conduct an electronic version of the board (UserStory, tasks,% participation of involved team members, etc.) in the program. This is done “for history”, in work we use only the board.
Combustion schedule
The combustion schedule is a clear indicator of progress. The X axis is the time axis. Y axis - the complexity of outstanding tasks. The task is considered completed if it is verified by the tester, in all other cases the task is not completed.
Completed tasks are transferred to the “Done” section of the board. Thus, the graph displays the sum of the complexity of the tasks located in the “ToDo” and “InProgress” sections. After the daily rallies, the combustion diagram is “matched”, taking into account the tasks performed during the day. Also information on the implementation is recorded in the program, which clearly displays the date of the task in “InProgress”, the date of the task. The product automatically calculates the average command speed, focus factor. This information can sometimes help in reassessing the complexity of the tasks and focus factor of the team.
Demonstration
The demonstration usually takes place in the afternoon. We try to invite as many interested people as possible, to take into account their wishes.
Retrospective
We usually carry out a retrospective immediately after the demo with something tasty, although many SCRUM gurus offer to conduct a retrospective in bars, pubs, etc. We think that we can somehow consider this idea.
At a retrospective, each team member tells about the moments that he liked or didn’t like, offers ideas for improving the process in the team. Also discussed are some organizational issues, teamwork.
For a retrospective, we use a board with markers, which is conditionally divided into 4 blocks: cons, pros, ideas, and a plan. After all the participants have spoken and all ideas have been written down, we vote by placing magnetic chips. Virtually everything that was recorded in the block "Plan", we try to subsequently respect.
As a result of the work on SCRUM, our team was able to solve many of those problems “on the surface” quickly and efficiently (although the system was not revived, they wrote from scratch).
Let the “great power of SCRUM” be with us and give users working buttons !!!
I want to share some experience and even most likely my opinion on the "existing software zoo" in some IT companies, namely approaches and implementations.
So, let's begin…
')
Naturally, in order to write a new or improve an existing product, you first need to research the market, analyze the need of customers, write a bunch of some ridiculous concepts and TK, in which for “more fear and power of the system” it is necessary to apply such expressions as: based on existing artifacts, the developed meta model will help real users ... ", it is necessary to use only terms and abbreviations, and of course the description of" spherical horses in vac mind. " Then it is necessary to analyze in detail all these concepts, to acquire millions more models: from simple IDEF-diagrams to huge UML-models with all sorts of associations, aggregations and other "attributes". The result is more and more new "spiders". End users do not care for these models, diagrams, etc., they need working buttons ...
After this, development begins directly, programmers begin to "rivet" what was intended, as was written in the statement of work. Let's skip the documentation and testing ... let's go straight to the exit of the product to the market. Marketers have developed a bunch of pieces of paper about the release of the product “SuperMegaSystemPro”, which allows not only to be “a system that automates so-and-so”, but also (and without too much modesty) ... she ... she ... she generally allows you to "automate the whole world" :-). It seems all is well, the system is powerful, modern, but for some reason the customers are unhappy ... like the system is about everything, and in fact there is nothing. As a result, the existing products begin to scold all those who feel like it, and the implementers in Tikhory using the SDK (if they have one) “rivet” more and more new plugins, if only the customer was satisfied. The consequence, the zoo is growing ...
Existing software problems are directly "on the surface", they do not need to be sought, and even more so to pull out of the depths. But nevertheless, new discussions begin, new concepts ... as a result, "who is in the forest, who is on firewood" ... but most importantly, the existing flaws are veiled by succinct terms and as a result, the new system has only become more complicated and incomprehensible. Sorry for the time spent (2-5 years), and even more so sorry to throw out "tons of code", because programmers are not to blame.
After the demagogy about the “waterfall approach” I divorced :-) it makes sense to move on to a real working technology SCRUM. This technology really helps to revitalize products and contributes to the development of new and high-quality products.
The initiative development team decided to work on SCRUM, trying to correct the existing state of affairs. A team was formed consisting of: programmers, analysts and testers, in which, as it should be, the technology was ProductOwner with its ProductBacklog and SCRUM-master.
Process
We combined the practice of SCRUM with some XP practices (eXtreme Programming). SCRUM allows you to solve issues of management and organization, and XP specializes in engineering practices. We borrowed from XP: pair programming, refactoring, CodeReview, and a style description of the code. Also on retrospectives, we have identified for ourselves a number of rules that we follow. For designing a quality GUI, we use the practice of using characters.
We use only lightweight documentation: the DB diagram and the UML model, which grow only during development, respectively, are not such terrible spiders as described above.
Planning
The sprint planning in our team lasts almost the whole day, BUT, if you poorly plan a sprint, the iteration can simply be overwhelmed. Therefore, planning is the most important part of any SCRUM project.
To calculate the ideal clock, we use a focus factor of 0.4. In principle, such an indicator is average for all iterations and is optimal, since we usually manage to complete planned tasks on time.
Planning usually takes place near the “wall of design” (boards with markers) or at a table with a computer, where you can visually see the previous functionality and the GUI. Some dialogues are drawn immediately on the board and photographed, then these photos will be involved in the actual execution of tasks. To assess the complexity we use PlanningPoker, almost all tasks are tested, which allows you to immediately identify all the errors.
SCRUM - rally
Daily meetings are held 2 times a day near the SCRUM board. After the meeting is a mark on the graph of combustion. The task is considered completed, i.e. transferred to "Done", only after testing. The programmer can take the next task in “InProgress” only after the analyst has approved the previous task that was taken for execution. The combustion diagram is "hammered" by the Scrum Master. In order not to exceed the 15-minute time limit, the meeting is held standing. At the meeting, we determine what we have done, what we will do next, what problems. We try not to discuss technical details, but it does not always work. Usually the meeting lasts no more than 10 minutes. If some technical problems were identified at the meeting, they are discussed after a scrum meeting near the “design wall” (a board with markers).
SCRUM - board
As a scram-board we use an ordinary cork board. We divided the board area into three parts: ToDo (what needs to be done), InProgress (Done), Done (Done).
However, we also conduct an electronic version of the board (UserStory, tasks,% participation of involved team members, etc.) in the program. This is done “for history”, in work we use only the board.
Combustion schedule
The combustion schedule is a clear indicator of progress. The X axis is the time axis. Y axis - the complexity of outstanding tasks. The task is considered completed if it is verified by the tester, in all other cases the task is not completed.
Completed tasks are transferred to the “Done” section of the board. Thus, the graph displays the sum of the complexity of the tasks located in the “ToDo” and “InProgress” sections. After the daily rallies, the combustion diagram is “matched”, taking into account the tasks performed during the day. Also information on the implementation is recorded in the program, which clearly displays the date of the task in “InProgress”, the date of the task. The product automatically calculates the average command speed, focus factor. This information can sometimes help in reassessing the complexity of the tasks and focus factor of the team.
Demonstration
The demonstration usually takes place in the afternoon. We try to invite as many interested people as possible, to take into account their wishes.
Retrospective
We usually carry out a retrospective immediately after the demo with something tasty, although many SCRUM gurus offer to conduct a retrospective in bars, pubs, etc. We think that we can somehow consider this idea.
At a retrospective, each team member tells about the moments that he liked or didn’t like, offers ideas for improving the process in the team. Also discussed are some organizational issues, teamwork.
For a retrospective, we use a board with markers, which is conditionally divided into 4 blocks: cons, pros, ideas, and a plan. After all the participants have spoken and all ideas have been written down, we vote by placing magnetic chips. Virtually everything that was recorded in the block "Plan", we try to subsequently respect.
As a result of the work on SCRUM, our team was able to solve many of those problems “on the surface” quickly and efficiently (although the system was not revived, they wrote from scratch).
Let the “great power of SCRUM” be with us and give users working buttons !!!
Source: https://habr.com/ru/post/52107/
All Articles