Наша команда занимается разработкой интерфейсов для четырех крупных проектов: Яндекс.Картинки, Яндекс.Видео и их версий для смартфонов. Разработка верстки поисковых сервисов в Яндексе обладает своей спецификой. Задачи стекаются с разных сторон: от менеджеров, разработчиков бэкэнда, поиска, проявляются баги и т.д. Внедряются новые фичи, требующие отображения в верстке. Все это стекается в наш таск-трекер (JIRA).

При этом задач всегда больше, чем ресурсов. Всем заказчикам нужно сделать задачи как можно раньше, все поднимают приоритеты своих задач. У разработчиков уходило слишком много времени на то, чтобы разобраться, какие из этих неотложных задач самые неотложные. Это очень тормозило развитие, и нужно было что-то предпринимать. Сделать так, чтобы каждый разработчик знал, какими именно задачами ему заниматься сегодня, а какие можно отложить на завтра, следующую неделю, месяц.

В конечном итоге большинство наших проблем удалось решить при помощи Agile Board и Scrum, но пришли мы к этому далеко не сразу, а поэтапно.

Первым делом мы завели фильтры. Нередки случаи, когда менеджер сначала утверждает, что задача суперсрочная, в продакшене все сломалось и т.д. А когда начинаешь выяснять, сколько пользователей эта проблема затрагивает, оказывается, что этой конкретной фичей пользуется три человека в день, да и воспроизводится баг далеко не каждый раз. Соответственно, задачу можно решить через месяц. Мы также разделили задачи на те, что затрагивают исключительно верстку (поправить цвет, отступы и т.п.) и инфраструктурные, к решению которых нужно привлекать также разработчиков бэкэнда.

Назвали мы все это компонентами. Стало более понятно, какие задачи, когда делать. Благодаря фильтрам удалось сократить количество задач, висящих каждый день на разработчике примерно до 20. Ориентироваться в них стало гораздо легче.

Но все же с наглядностью по-прежнему была проблема. И решать мы ее сначала попробовали при помощи дашборда. Решение оказалось далеко от идеала. В первую очередь дашборду не хватало интерактивности. Например, чтобы поменять статус задачи или поменять исполнителя, приходилось открывать новую страницу. Да и работало все это не очень быстро, JIRA есть JIRA.

Несмотря на все эти изъяны, было ясно, что движемся мы в правильном направлении, просто нужно пойти еще дальше. И тогда мы решили попробовать Agile Board. У нас в JIRA уже был установлен прекрасный плагин Green Hopper, который умеет делать Scrum и Kanban.

Как гласит Википедия, Scrum — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.

Там же есть очень хорошая картинка, которая это все объясняет:

У нас есть какое-то количество задач в проекте, которое требует предварительной фильтрации для спринта. Спринт — повторяющийся процесс разработки, в рамках которого мы внедряем новые фичи и чиним баги.

Готовим рабочее место

Начали мы с малого — навели порядок в JIRA. Вместо кучи компонентов и версий, мы оставили:

• компонент «Верстка: инфраструктура»;
• компонент «Верстка: интерфейс»;
• опциональные продуктовые или технологические компоненты, например: платформа – iOS, продукт – подвал;
• версия backlog;
• продуктовые версии для запусков.

Кроме этого мы ввели некоторый набор правил про написания и компоновку задач:

• краткий и четкий заголовок, лучше с глаголом;
• минимально необходимое и четкое описание задачи со всеми необходимыми данными, желательно без ссылок на внешние источники;
• должны быть указаны компонент и версия
• задача измеряема и конечна;
• отказываемся от гигантских родительских задач, вроде «Запуск нового интерфейса картинок»;
• родительские задачи используются для задач, которые можно сделать за неделю;
• все сабтаски у родительских задач действительно являются декомпозицией задачи;
• используем механизм линковки задач, если они связаны друг с другом.

Настраиваем Agile Board

Прежде всего, надо выбрать тип: Scrum или Kanban.

Затем необходимо наполнить его данными.

Мы сделали фильтр, который является источником данных для нашего Agile Board. Этот фильтр отбирает проектные задачи с компонентами про верстку, с проставленной версией «backlog». Backlog значит, что мы должны сделать эту задачу в ближайшие пару спринтов.

В соответствии с workflow работы над задачами необходимо добавить новых колонок и назначить на них соответствующие статусы.

По умолчанию есть три колонки: to do, in progress, done. У нас их больше:

• to do – задачи, которые нам осталось сделать в рамках текущего спринта;
• in progress – задачи, которые мы делаем прямо сейчас;
• on review – задачи, в которых мы прямо сейчас ревьювим реализацию;
• commited – задачи, которые уже запрограммированы, но не готовы к тестированию;
• testing – задачи, которые готовы к тестированию или тестируются в данный момент;
• done – выполненные задачи.

Последние две колонки могут быть совмещены в одной. Например, сейчас у нас в одном из проектов нет колонки «testing», а есть сразу «done».

Настраиваем группировку задач. По умолчанию группируются по assignee. Нам это вполне подошло.

Настраиваем цвета карточек, чтобы можно было визуально отличать баги от фич.

Настраиваем быстрые фильтры. Очень удобная штука. Когда задач много, позволяет быстро их пофильтровать по разным параметрам. Фильтры можно совмещать.

Estimation, working days и issue detail view мы пока не используем.

• Estimation необходим для оценки задач на этапе планирования, чтобы более лучше в дальнейшем планировать.
• Working days позволяет задать рабочие дни на проекте.
• Issue detail view поможет выводить дополнительные поля в предпросмотр задачи.

Используем Agile Board

Мы приняли длительность спринтов в одну неделю. Соответственно, на первой проектной синхронизации мы набираем задач на неделю и берем их в работу. Происходит это на вкладке Plan.

Наполнить спринт можно двумя способами:

• просто растянуть блок вниз, захватывая из бэклога необходимые задачи;
• перетянув drag&drop’ом задачу из backlog в спринт.

Задачи в backlog можно сортировать как вам угодно простым перетаскиванием. Мы занимаемся этим раз в неделю с проектными менеджерами – до встречи про синхронизацию.

При наполнении задачи, можно ткнуть на любую задачу, и в правой колонке появится описание задачи:

Когда спринт наполнен — стартуем его. Далее можно работать с вкладкой Work.

Это очень крутая штука, на которой можно отследить статус всех задач, а также занятость людей. Группировка, аватары и цветовая дифференциация штанов делает этот процесс максимально удобным и приятным.

В этом режиме можно также посмотреть детальное описание любой задачи, изменить статус задачи drag&drop’ом (перетащить из in progress в on review). Эту вкладку мы просматриваем на синхронизации в середине недели, обсуждая прогресс задач.

В начале новой недели мы завершаем спринт и переходим на вкладку Report. При этом мы сразу видим, сколько задач мы сделали, а сколько нет. Незавершенные задачи попадают наверх backlog, они будут сделаны в рамках следующего спринта в первую очередь. Кроме этого, есть несколько отчетов, например:

• sprint report;

  

• control chart.

  

Второй график дает нам понимание, сколько времени у нас в среднем живут задачи до закрытия. На графике видно, что есть всплеск:

Это долгоиграющая задача про замеры производительности. Конкретно для этой задачи — все ОК, но для других задач — явный сигнал, что формулировка задачи неправильная и/или она требует декомпозиции. С помощью этого графика, а также поля Sprint у каждой задачи, мы можем отслеживать сроки выполнения задач, и если они зависают, принимать меры.

Вслед за нами команды еще нескольких сервисов Яндекса перешли на такой формат планирования задач. Мы рекомендуем этот подход всем крупным командам разработчиков. Если у вас есть более одного источника задач, а к их решению нужно привлекать программистов из других команд, по нашему мнению, Agile Board — самый оптимальный вариант.

Автор: sbmaxx

Источник