Agile Board. How do we plan in Yandex. Pictures and how did we come to this?
Our team develops interfaces for four large projects: Yandex.Kartinki, Yandex.Video and their versions for smartphones. Development of the layout of search services in Yandex has its own specifics. Tasks flock from different angles: from managers, backend developers, search, bugs, etc. New features are being introduced that require display in the layout. All this is drained into our task tracker (JIRA).
At the same time, there are always more tasks than resources. All customers need to do tasks as early as possible, all raise the priorities of their tasks. Developers took too much time to figure out which of these pressing tasks are the most urgent. This slowed down the development, and something had to be done. Make it so that each developer knows what tasks he will be engaged in today, and which ones can be postponed for tomorrow, next week, month.
')
In the end, most of our problems were solved with the help of Agile Board and Scrum, but we arrived at this far from immediately, but in stages.
The first thing we got filters. There are often cases when a manager first asserts that the task is super-urgent, everything is broken in production, etc. And when you start to find out how many users this problem affects, it turns out that this particular feature is used by three people a day, and the bug is not played every time. Accordingly, the task can be solved in a month. We also divided the tasks into those that affect only the layout (correct color, indents, etc.) and infrastructure ones, which also require backend developers.
We called it all components. It became more clear what tasks, when to do. Thanks to the filters, it was possible to reduce the number of tasks hanging on the developer to about 20 each day. It became much easier to navigate them.
But still, with clarity, there was still a problem. And we solved it first with the help of dashboard. The solution was far from ideal. First of all, dashboard lacked interactivity. For example, in order to change the status of a task or change an artist, you had to open a new page. Yes, and all this did not work very quickly, JIRA is JIRA.
Despite all these flaws, it was clear that we were moving in the right direction, we just need to go further. And then we decided to try the Agile Board. We have already installed a wonderful Green Hopper plugin in JIRA that can do Scrum and Kanban.
As Wikipedia says, Scrum is a project management methodology that is actively used in the development of information systems for flexible software development. Scrum clearly emphasizes quality control of the development process.
There's also a very nice picture that explains it all:
We have a certain number of tasks in the project, which requires pre-filtering for the sprint. Sprint is a recurring development process, in which we introduce new features and fix bugs.
We started small - put things in order in JIRA. Instead of heaps of components and versions, we left:
In addition, we introduced a set of rules about the writing and layout of tasks:
First of all, you need to choose the type: Scrum or Kanban.
Then you need to fill it with data.
We made a filter that is a data source for our Agile Board. This filter selects project tasks with a layout component, with a backlog version. Backlog means we have to do this task in the next couple of sprints.
In accordance with the workflow of work on the tasks, it is necessary to add new columns and assign corresponding statuses to them.
By default, there are three columns: to do, in progress, done. We have more of them:
The last two columns can be combined in one. For example, now in one of our projects there is no “testing” column, but there is “done” right away.
Customize task grouping. By default, they are grouped by assignee. It suited us well.
Adjust the colors of the cards so that you can visually distinguish bugs from features.
Customize quick filters. Very handy thing. When there are many tasks, it allows you to quickly filter them by different parameters. Filters can be combined.
Estimation, working days and issue detail view we do not use yet.
We took a sprint duration of one week. Accordingly, at the first project synchronization, we recruit tasks for the week and take them to work. This happens on the Plan tab.
There are two ways to fill the sprint:
Tasks in the backlog can be sorted as you like by simple drag and drop. We do this once a week with project managers - see you about synchronization.
When filling the task, you can click on any task, and the task description will appear in the right column:
When the sprint is full - start it. Then you can work with the Work tab.
This is a very cool thing, where you can track the status of all tasks, as well as the employment of people. Grouping, avatars and color differentiation of pants makes this process as convenient and enjoyable as possible.
In this mode, you can also view a detailed description of any task, change the status of the task by drag & drop (drag from in progress to on review). We view this tab on mid-week sync, discussing the progress of tasks.
At the beginning of the new week we finish the sprint and go to the Report tab. At the same time, we immediately see how many tasks we have done and how many we have not. Incomplete tasks get to the top of the backlog, they will be made in the next sprint in the first place. In addition, there are several reports, for example:
The second chart gives us an understanding of how much time we have on average the tasks before closure. The graph shows that there is a surge:
This is a long-running task about performance measurements. Specifically for this task, everything is OK, but for other tasks it is a clear signal that the formulation of the task is incorrect and / or it requires decomposition. With this schedule, as well as the Sprint fields for each task, we can track the deadlines for the tasks, and if they hang, take action.
Following us, the teams of several more Yandex services switched to such a task scheduling format. We recommend this approach to all large development teams. If you have more than one source of tasks, and you need to involve programmers from other teams in their solution, in our opinion, the Agile Board is the best option.
At the same time, there are always more tasks than resources. All customers need to do tasks as early as possible, all raise the priorities of their tasks. Developers took too much time to figure out which of these pressing tasks are the most urgent. This slowed down the development, and something had to be done. Make it so that each developer knows what tasks he will be engaged in today, and which ones can be postponed for tomorrow, next week, month.
')
In the end, most of our problems were solved with the help of Agile Board and Scrum, but we arrived at this far from immediately, but in stages.
The first thing we got filters. There are often cases when a manager first asserts that the task is super-urgent, everything is broken in production, etc. And when you start to find out how many users this problem affects, it turns out that this particular feature is used by three people a day, and the bug is not played every time. Accordingly, the task can be solved in a month. We also divided the tasks into those that affect only the layout (correct color, indents, etc.) and infrastructure ones, which also require backend developers.
We called it all components. It became more clear what tasks, when to do. Thanks to the filters, it was possible to reduce the number of tasks hanging on the developer to about 20 each day. It became much easier to navigate them.
But still, with clarity, there was still a problem. And we solved it first with the help of dashboard. The solution was far from ideal. First of all, dashboard lacked interactivity. For example, in order to change the status of a task or change an artist, you had to open a new page. Yes, and all this did not work very quickly, JIRA is JIRA.
Despite all these flaws, it was clear that we were moving in the right direction, we just need to go further. And then we decided to try the Agile Board. We have already installed a wonderful Green Hopper plugin in JIRA that can do Scrum and Kanban.
As Wikipedia says, Scrum is a project management methodology that is actively used in the development of information systems for flexible software development. Scrum clearly emphasizes quality control of the development process.
There's also a very nice picture that explains it all:
We have a certain number of tasks in the project, which requires pre-filtering for the sprint. Sprint is a recurring development process, in which we introduce new features and fix bugs.
Preparing a workplace
We started small - put things in order in JIRA. Instead of heaps of components and versions, we left:
- component “Layout: infrastructure”;
- component “Layout: interface”;
- optional product or technological components, for example: platform - iOS, product - basement;
- backlog version;
- product versions for launches.
In addition, we introduced a set of rules about the writing and layout of tasks:
- short and clear heading, better with a verb;
- minimum necessary and clear description of the task with all the necessary data, preferably without reference to external sources;
- the component and version must be specified
- the task is measurable and finite;
- we refuse giant parental tasks, like “Launching a new interface of pictures”;
- parent tasks are used for tasks that can be done in a week;
- All subtasks for parental tasks are really a task decomposition;
- We use the mechanism of linking tasks if they are related to each other.
Customize Agile Board
First of all, you need to choose the type: Scrum or Kanban.
Then you need to fill it with data.
We made a filter that is a data source for our Agile Board. This filter selects project tasks with a layout component, with a backlog version. Backlog means we have to do this task in the next couple of sprints.
In accordance with the workflow of work on the tasks, it is necessary to add new columns and assign corresponding statuses to them.
By default, there are three columns: to do, in progress, done. We have more of them:
- to do - tasks that we have to do in the current sprint;
- in progress - the tasks we are doing right now;
- on review - tasks in which we are reviewing the implementation right now;
- commited - tasks that are already programmed but not ready for testing;
- testing - tasks that are ready for testing or are being tested at the moment;
- done - completed tasks.
The last two columns can be combined in one. For example, now in one of our projects there is no “testing” column, but there is “done” right away.
Customize task grouping. By default, they are grouped by assignee. It suited us well.
Adjust the colors of the cards so that you can visually distinguish bugs from features.
Customize quick filters. Very handy thing. When there are many tasks, it allows you to quickly filter them by different parameters. Filters can be combined.
Estimation, working days and issue detail view we do not use yet.
- Estimation is needed to evaluate tasks at the planning stage in order to better plan further.
- Working days allows you to set working days for the project.
- Issue detail view helps to display additional fields in the task preview.
We use Agile Board
We took a sprint duration of one week. Accordingly, at the first project synchronization, we recruit tasks for the week and take them to work. This happens on the Plan tab.
There are two ways to fill the sprint:
- just stretch the block down, capturing the necessary tasks from backlog;
- dragging and dropping a task from the backlog to the sprint.
Tasks in the backlog can be sorted as you like by simple drag and drop. We do this once a week with project managers - see you about synchronization.
When filling the task, you can click on any task, and the task description will appear in the right column:
When the sprint is full - start it. Then you can work with the Work tab.
This is a very cool thing, where you can track the status of all tasks, as well as the employment of people. Grouping, avatars and color differentiation of pants makes this process as convenient and enjoyable as possible.
In this mode, you can also view a detailed description of any task, change the status of the task by drag & drop (drag from in progress to on review). We view this tab on mid-week sync, discussing the progress of tasks.
At the beginning of the new week we finish the sprint and go to the Report tab. At the same time, we immediately see how many tasks we have done and how many we have not. Incomplete tasks get to the top of the backlog, they will be made in the next sprint in the first place. In addition, there are several reports, for example:
- sprint report;
- control chart.
The second chart gives us an understanding of how much time we have on average the tasks before closure. The graph shows that there is a surge:
This is a long-running task about performance measurements. Specifically for this task, everything is OK, but for other tasks it is a clear signal that the formulation of the task is incorrect and / or it requires decomposition. With this schedule, as well as the Sprint fields for each task, we can track the deadlines for the tasks, and if they hang, take action.
Following us, the teams of several more Yandex services switched to such a task scheduling format. We recommend this approach to all large development teams. If you have more than one source of tasks, and you need to involve programmers from other teams in their solution, in our opinion, the Agile Board is the best option.
Source: https://habr.com/ru/post/207316/
All Articles