Lecture
Actually, there is nothing new and not invented. Once every two weeks we have a day to do a retrospective, in which we all in turn tell about what has been done, what problems have arisen in the course of development and what has pleased, about the achievements of the past iteration. Immediately along the way, problems and planning tasks are written out, but attention is not focused on them, they will be discussed later. We are not yet doing big demonstrations with art and other things (the customer is usually not present, so there is no special meaning at the current stage). What is a retrospective for: so that everyone was aware of what was done in the project after the fact, not on the tasks closed in Djir, could ask questions, clarify certain points. Verbally, you can transfer much more and more quickly than with the tracker. Thus, everyone sees progress (if there is one). If problems and difficulties arise, they will also be revealed and the whole team will be aware of them, they will have in mind and can be collectively offered the best solution. After a retrospective, which takes from an hour to two, a break of 10-15 minutes. Then planning begins.
The main planning tool is backlog, compiled earlier. If someone does not know, then all major top-level tasks are included in the backlog. Ideally, it is compiled by the customer first when he describes what he wants to see in the project. Further, it is detailed by the producer or another responsible person, or who is *** on planning. We have it quite detailed, currently 95 tasks in it, most of which are high-level features. High-level features are those that still need to be disclosed, divided into subtasks (of which there may be hundreds), each of them to describe, and so on. That is, these 95 tasks can turn into both 950 and 9500. For example, at the moment since writing this article, the number of features has grown to about a thousand. Features are added to backlog as they are developed or discussed (as well as bugs).
On planning, the feature is taken and evaluated: who will do it better; who is involved in it and how long it will take to implement it. We estimate time not in story points, but so far in ideal hours with the subsequent transition to points (parrots), but for some internal reasons, now for us is better hours. If the time to complete the task exceeds 16 hours (two days), then the task is divided into subtasks. This allows you to better understand what needs to be done within this task, what will take time and more accurately assess the task without having to put on it extra time and not flying past the deadlines.
For one person, we recruit from 70 to 80 perfect hours - the time that he needs, if he correctly assessed the task and no one will distract him. The number of hours depends on the previous iterations, on how each has completed its iteration. For example, if a person closed his tasks ahead of time, then he underestimated his strength; if he did not have time. it means he overestimates his strength (or underestimates the complexity of the tasks). The main thing is not to use speed (velocity) as an indicator of productivity: this is a vicious path that from a tool for improving accuracy in planning turns into a whip and buries the essence and meaning of the Ajile. Here you can argue that people will try not to close their tasks on time, as they are completed. Yes, it can be; but we employ adults, responsible employees who do not need to do so. On retrospectives and planning it is also very easy to identify overstatements, timing. With underestimation of terms it is more difficult, here you need to understand the person, what he has to do, bear in mind his results from past iterations and the human factor.
Adjail Poker is a great tool for clarifying dates and identifying misunderstandings. Plus, it's fun enough. The essence of agile poker is that everyone has cards with a clock: 1, 2, 4, 8, 16, and also? and "break". When a task is evaluated, everyone who can evaluate it, put the cards on the table with numbers down and then break them. If the time is up, the task is estimated at that time. If not, and even more so if the difference is large, then it begins to figure out why such different estimates. I know from the previous project that it works very well and I would recommend everyone to use this game element. Sometimes additional tasks are opened that would be missed and not included in the iteration. In this team, we do not use poker because of the very narrow specialization of each employee, and also because everyone has very different fronts of work: there is some dissynchronization in tasks. In an ideal world, the whole com *** takes one feature and does it together. For example, everyone makes the feature "shooting": server synchronization of bullets and packet transfer, logic - hits and defeats, client - display on the client, interface - changing states and bars, artists - fire of a shot and effects of falling. We are wrong: now we are finishing tails (the sad legacy of the banished fiend) and we are only getting closer to synchronous work. Therefore, poker with such diverse tasks that our team has to solve, is not suitable. By the way, the poker team liked the team that had never worked like this before, when, for the sake of experiment, we iterated this way.
A very fast flyzig where everyone says what he did yesterday, what he will do today and what problems he has (if any). Programmers do not like these meetings because it seems to them that this is some form of report, as if they are being called to a blackboard at school. It is rather difficult to explain that rallies are needed to increase motivation, synchronize work and identify problems, but over time this understanding comes and, if the rally is missed, then some people ask why they missed it and whether we will be scared today. For teams that are just starting to work on the Ajaila, I (personal opinion, which goes against the Ajail canons), I recommend making rallies no more than once every 2-3 days, or even 3-4 days and gradually hold them more and more often, without violence against *** The main task of Scrum Master / PMA is to make someone *** start to perceive the meetings as a tool, and not as a whip. With the mentality of Russian developers, this is probably the hardest thing in the Ajaila.
Jira is good for everyone, and especially because she knows how to work in the Ajaila regime. She has a form of displaying backlog, she works with cards, builds a burndown chart, sets up in any way and for whom *** in 10 people costs only $ 10 monthly. Another plus - OnDemand version does not require the purchase of hosting, domain and installations, in these $ 10 monthly everything is already included. Just register and create a project, the rest will be done in 5 minutes.
In the backlog of Jira there is such a thing as an epic, that is, the key feature of the project. In epics, you can include the usual features, bugs, stories, tasks and in general everything else. However, now it is more convenient for me to use epiki as development headings: for example, server architecture, game logic, or art. Why, because the key features that the whole com *** would have worked on at the same time, or everything has already been implemented, or before them even before China. Probably, when a certain stage is reached, there will be epic command, which will combine tasks from different components. For example, it could be “flight in space,” and there will be tasks for the server, client, art, logic, game design, sounds, and something else. But it’s better to see once than to re-read a hundred times, so our backlog looks like this (having gone with the screenshot, I won’t reveal any secrets):
The picture is clickable
What can be seen here: on the left - epics (task categories), in the center - tasks in the backlog (already quite small and detailed), on the right - detailed information on the tasks and the ability to edit them. The screenshot did not get tasks from the current sprint, but it is not very important - there is the same, only Sprint X is written instead of the Backlog and the completed tasks are crossed out.
Instead of cards stuck to the board, the board of the Jira is used. It is configured as you like. We use the default view - three columns: to run, to work and complete. Tasks are dragged back and forth; can be completed in different ways: done, impossible to do, and canceled for testing. You can add any other statuses or columns. The current sprint looks like this (the picture is also naturally clickable):
Well, in the course of the play, you can watch the development progress on the burndown chart (probably, it can be translated as "performance graph", but its essence is that the tasks are burned during the development process). The gray line is an ideal development, if every second the developers notice progress, but of course this does not happen. The red line is the execution of tasks, where each point is a successfully completed task. The perfect sprint looks like a screenshot when the red line at the bottom right meets the gray at the same point. The screenshot below shows that the sprint ended a few hours later (actually, the sprint was completed a little ahead of time, but not Moscow time was set up in Djir - if you work in Djir, do not forget to put the correct time zone right away):
As I wrote above, this chart is built every minute and any team member can monitor the actual progress at any time. There is an extra peak on the sprint on October 23rd - these are tasks that were mistakenly not missed from the sprint at the time of its launch and then added. Thus, to add imperceptibly tasks simply will not work. Everyone will see it, but sprint will have to complete it anyway, or there will be a very ugly picture: the gray line has long reached the finish line, and the red line is somewhere much more to the right by itself. So if you are working with a hellish manager, slip him Djiru in ajail mode and he will have to complete sprints (if he doesn’t want a team riot). Or if you are a business owner, then the same thing, but in a compulsory manner, the benefit is to monitor the development in this way without any special knowledge and programming skills. Of course, this is not a panacea, but a very good tool. There are many other tools in Djir for visualizing progress - by speed, by epic, by volume, and so on, but this is for those who are a little familiar with Jira and Ajile.
In conclusion, I will say that at first Jira seems scary, complex and very sophisticated. But to get into it the matter of one day, to deal with the settings about the same. Sometimes, when specific tasks will arise (for example, to make two different projects and to limit access to different commas ***) you will have to read the documentation, but also everything is done in half an hour. The benefits that brings Jira, in my opinion definitely worth these modest efforts and a very short time.
https://jira.atlassian.com/projects/DEMO/
Comments
To leave a comment
Quality Assurance
Terms: Quality Assurance