Работа с бэклогом
Груминг бэклога
Бэклог нуждается в постоянном уходе, какие-то задачи устаревают и теряет актуальность, а какие-то наоборот становятся очень важными и требуют незамедлительной реакции. Поэтому, для управления бэклогом в скраме есть специальное событие — груминг бэклога.
Проводите его раз в 3−4 недели, чтобы:
Приоритизировать: переносите наверх важные и нужные задачи или задачи, которые принесут быструю пользу. Может быть она не такая важная, но зато прямо сейчас даст некое видимое улучшение, сиюминутный результат и продвижение в проекте. Такие задачки называются quick wins.
Уточнить детали: часто задачи фиксируются быстро, без деталей. Убедитесь на груминге, что деталей достаточно, чтобы передать задачу в анализ и проектирование или в разработку, если анализ и проектирование не требуются.
Декомпозировать: большие задачи сложно и дорого делать. В них легко зарыться, забуксовать, тяжело релизить и тестровать. Поэтому старайтесь декомпозировать задачи на более мелкие.
Оценить: постарайтесь примерно оценить трудозатраты.
Удалить неактуальные и устаревшие задачи.
Давайте посмотрим на наш бэклог и погрумим несколько задач.
Возьмем задачу по дополнению дизайн-системы паттернами:
Посмотрим на первый пункт — Справочники. Что такое справочники? Это набор данных, имеющих одинаковую структуру и списочный характер. Поищем справочники по системе, я сделаю это на примере банковского приложения:Пример реализации справочника «Телефонная книга»
- Страны
- Банки
- Организации
- Адреса
- Коды видов дохода
- Виды деятельности
- Телефонная книга
Кажется их довольно много и справочники отличный кандидат на декомпозицию. Удалим этот пункт из задачи и превратим его в эпик или milestones, а все найденные справочники заведем отдельными задачами:
Вот незадача, у нас же несколько платформ, значит эпика будет два: веб и мобайл. Ну и навесим соответствующие метки изменения будут в трех репозиториях: документации, ios и android.
Возмем следующую задачу:
Посмотрим из чего она состоит и декомпозируем при необходимости.
Определиться с движком: тут надо понять на какой платформе запустим сайт для размещения дизайнерской документации.
Навесить метрику: чтобы начать собирать какие-то данные.
Подключить домен и https: купить домен, ssl-сертификат и все настроить
Развернуть сайт на сервере и провести первоначальную настройку
Внедрить линтинг: мы явно захотим автоматизировать какие-то наши процессы, например, проверку орфографии, синтаксис и стиль, соответствие редполитике.
Эту задачу можно закрыть, а вместо нее создать эпик и несколько других задач:
Задачи декомпозированы, теперь их нужно оценить, для этого в scrum есть артефакт, который называется покер планирования. Оценивать задачи можно в часах и относительных единицах — Story Points. Почитайте про это отдельно, попробуйте разные подходы и выберите тот, который вам понравится больше.Покер планирования. Яндекс Трекер
В Github зафиксировать оценку можно только когда задача добавлена в проект, который мы создадим и настроим в следующей главе.
Планирование
Итак, у нас есть список задач готовых к передаче в работу, теперь нужно их запланировать.
Для этого существует еще одно событие в скраме — планирование спринта.
А какой будет длительность спринта? Обычно это от одной до четырех недель. Автор фанат недельных спринтов, если команда сыгралась, вы умеете грамотно декомпозировать задачи, каждый член команды понимает свою роль и ответственность, вы уверенно управляете командой, и система покрыта достаточным количеством тестов, то недельный срок позволяет сделать немало задач и увеличить количество полезных поставок в год. Может быть количество задач в год останется тем же, но появляться на проде они станут быстрее, а это увеличит пользу для бизнеса.
Выбирайте недельный цикл и проводите планирование раз в неделю, сразу после релиза.
Лучше всего релизиться в понедельник, а планироваться во вторник. Релизы по пятницам только кажутся логичными, на самом деле это шанс проработать все выходные, если релиз пойдет не по плану.
Планирование важный этап, поэтому руководитель дизайн-системы готовится к нему заранее:
- Анализирует результаты предыдущего спринта, успеют ли ребята закрыть задачи.
- Смотрит на наличие срочных багов или просьб от дизайн-сообщества.
- Сверяется с отпусками и больничными членов команды.
- Планирует какие задачи взять на следующий спринт, сверяется с Roadmap.
- Проверяет прошли ли эти задачи груминг, соответствуют ли они критериям передачи в проектирование или разработку.
На планировании кратко расскажите о результатах предыдущего спринта и представьте план нового, определите исполнителей, снимите все возникающие вопросы и стартуйте спринт.
Roadmap
Имея бэклог, принципы, а через принципы и видение развития дизайн-системы составьте роадмап. Для этого создайте отдельный проект в репозитории и набросайте крупные идеи и пользу, которую они принесут. Подсмотреть культуру ведения дорожной карты можно у Github:
