Как настроить Канбан в Jira для разработки своих продуктов, на примере Meetville
18 сентября 2017 года мы запустили Hygger.io — систему управления проектами для IT-компаний, которая состоит из 4х типов досок: Kanban, Sprint, Backlog и Roadmap. Заходите, регистрируйтесь, изучайте!
В этой заметке я рассказываю к какому финальному процессу разработки в Jira мы пришли в Meetville. Также кратко описываю путь, который мы проделали до дня сегодняшнего. Читатель получит готовый регламент с описанием процесса и правилами разработки. Бери и внедряй, нам не жалко.
Начало
Начиналось все с банального списка issues и фильтрации с помощью JQL (2010 год). Для расстановки приоритетов мы использовали поле priority, которое позволяет разбить приоритеты задач на 5 групп (trivial, minor, major, critical, blocker). Также использовали Agile плагин Jira Agile (раньше он назывался Green Hopper). Задачи внутри группы делались в произвольном порядке. Например, было 10 задач с приоритетом major и программист брал любую задачу, которая имеет приоритет major, но после того, как все задачи с более высшими приоритетами были готовы. На тот момент мы работали в спринтах, поэтому порядок в целом был не важен. Важен был конечный результат, то есть принятые тестировщиком и залитые на продакшн фичи.
Минусы
Но у этого процесса было много минусов. Вот лишь самые основные:
- тестеры проверяли фичу не тогда когда программист ее закончил, а спустя длительное время. Программист успевал забыть эту фичу и тратил много времени на то, чтобы снова погрузиться в задачу. Сейчас, в канбане, тестер проверяет фичу практически сразу после того, как ее сделал программист;
- фичи заливались на production только в конце спринта, примерно раз в месяц/полтора — сейчас мы их заливаем практически сразу после приемки тестировщиком;
- код фичи попадал в мастер с большим опозданием — в итоге приходилось часто разруливать конфликты. Сейчас код попадает в мастер сразу после приемки тестером, то есть достаточно быстро;
- непонятно чем занят программист в настоящий момент — приходилось заниматься постоянным опросом вида “что делаешь?” и раздачей директив вида “после этой задачи делай вот эту”;
- непонятно, в целом, насколько команда была загружена задачами — кто при задаче, а кто филонит;
- программисты не знали чем заняты коллеги;
- программист мог делать сразу несколько задач параллельно, что повышало издержки на переключение контекста;
- приходилось тратить много времени на оценку фич перед стартом спринта, сейчас потребности в оценке нет — когда сделаем фичу, тогда и сделаем;
- срочные задачи по исправлению багов или по доработке фич на продакшне ломали все сроки спринта — сроки постоянно плавали, что приводило к негативу со стороны “внутренних” заказчиков продукта.
Канбан — спасение
В один прекрасный момент я решил попробовать методологию Канбан, которую как раз добавили в плагин Jira Agile (ранее — Green Hopper). И, практически сразу, пропускная способность команды разработки выросла на порядок. Мы стали выпускать намного больше полезностей в единицу времени. Все были довольны: пользователи продукта стали получать в первую очередь более полезные фичи причем намного быстрее. “Внутренние” заказчики перестали давать кнута за срыв сроков и своими глазами увидели как выросла скорость поставки софта.
Если вы совсем не знакомы с методологией Канбана, то я рекомендую прочитать вот эту статью — http://habrahabr.ru/post/64997/.
Плюсы
Вот плюсы, которые мы получили от внедрения Канбана:
+ мы сразу увидели узкие места — в колонке Testing скапливалась большая очередь задач — наш тестировщик не справлялся с проверкой задач. В итоге программисты успевали хорошенько подзабыть задачи, которые им переоткрывал тестировщик спустя неделю или две. Раз забыли, значит надо смотреть код и вспоминать о чем там шла речь. Решение — взяли второго тестировщика. Бинго.
+ менеджер продукта стал точечно управлять порядком выпуска фич. В этом мире бушующем все ж таки порядок имеет значение. Задача по определению приоритетов — одна из самых важных задач для менеджера в Канбане. Требования, как и реальность, постоянно меняются. Какие-то задачи, полежав в очереди, теряют свою значимость и уходят вниз, туда, где их никто никогда не увидит. Какие-то задачи наоборот из грязи в князи — поднимаются наверх. Се ля ви.
+ мы стали делать только то, что реально добавляло ценности продукту. Мы смогли упрятать подальше от программистов тонны бесполезных багов и доработок. С глаз долой из сердца вон. Тестировщики — молодцы, находят баги, но баг Багу рознь. Отличить баг от Бага — задача для человека, который может и учитывает как интересы пользователей продукта, так и интересы бизнеса. Это работа менеджера продукта.
+ программисты перестали тратить свою энергию на выбор следующей задачи — “взять в работу вот этот баг, или вот эту задачу?”. Этот выбор осложнялся тем, что у обоих задач был одинаковый приоритет. Если тебе вернули задачи, то есть переоткрыли в терминах Jira, будь добр взяться за нее сразу после текущей задачи, а не через 2 недели. Теперь эту энергию программист может тратить на бизнес-логику и программирование. И на чтение новостей на reddit.
+ вся картина — на ладони, можно зайти на доску и увидеть кто чем занят, что уже готово к отправке на продакшн. Большие вещи видятся на расстоянии.
+ мы стали более гибкими — мы стали менять требования “на лету”, причем без какого-либо сопротивления со стороны программистов. Раньше программист не хотел делать “левые” задачи, боясь “завалить” сроки по спринту. С Канбаном программист работает как процессор — тактами, один такт — одна задача. Главное — не трогать его внутри такта. Кстати, чем чаще такты, тем гибче команда разработки. Идеальный такт для нашей команды — 8 часов.
Регламент на процесс
Теперь я покажу вам нашу структуру и правила, которые мы соблюдаем в своей команде. По сути это готовый регламент на разработку. Бери и внедряй в своем продукте.
Вот главная и единственная иллюстрация — наша структура в Jira.
Вертикальный приоритет задач
Задачи разбиты на три уровня:
1) Уровень Blockers — выполняются в первую очередь.
2) Tasks and Bugs — выполняются при отсутствии задач в группе Blockers.
3) Someday — выполняются при отсутствии задач в группах Blockers и Tasks and Bugs. То есть — никогда :)
Правила:
- Приоритет и порядок выполнения всем задачам задает менеджер продукта.
- Выполняя задачи на уровнях Tasks and Bugs или Someday, при появлении задачи на уровне Blockers, в комментариях к Block-задаче, разработчик указывает время, через которое он сможет приступить к выполнению. Менеджер отвечает на данный комментарий согласием или не согласием. Если ответ положительный, то разработчик приступает к Block-задаче не позднее оговоренного времени, если же ответ отрицательный, разработчик приступает к Block-задаче немедленно, остановив текущую задачу на другом уровне. Если комментарий от менеджера не получен, то разработчик действует, как если бы получил положительный ответ. Также данный вопрос можно решить в устной форме с менеджером проекта.
- Пока не будут выполнены все задачи на более высоком уровне приоритета, разработчик не имеет права приступать к задачам находящимся на более низком уровне приоритета.
- Задачи внутри уровня выполняются по порядку — сверху вниз.
- Разработчик не имеет права по своему усмотрению менять приоритет задач.
Горизонтальное движение задач
Команда выполняет задачи и проходит все колонки слева направо.
To Do
- В колонке To Do представлены задачи для разработчика, имеющие статус Jira open.
- Разработчик обязан взять одну верхнюю задачу, при отсутствии задачи в Reopened и присвоить ей статус In progress. То есть перенести задачу в колонку In progress.
- За наполнением задач и их порядком в To Do и их приоритетом следит и отвечает менеджер продукта.
- Если задачу вешает один разработчик другому разработчику, то суть задачи, исполнитель и ее статус должны быть согласованы с менеджером продукта.
In Progress
- В колонке In Progress находятся задачи, имеющие статус Jira in progress.
- Если у разработчика в колонке In Progress нет задачи, то это считается простоем.
- У разработчика в In Progress должна быть только одна задача.
- Максимальное число задач в In Progress равно числу разработчиков, если же число задач превысило максимум, колонка выделяется красным цветом, что сигнализирует о нарушении процесса.
- Разработчик должен проверить, не открыл ли он сразу несколько задач, если лишние задачи есть, разработчик обязан оставить только одну задачу.
- Если разработчик выполнил задачу, он обязан выложить ее для тестирование на закрепленный за ним dev-сервер и присвоить задаче статус Resolved, то есть перенести ее в колонку Testing.
In Testing
- Задачи на этом этапе имеют Jira статус Resolved и проходят тестирование на dev-сервере.
- Тестировщики работаю с задачами из данной колонки до 14.00, если отдельно не оговорен порядок тестирования с менеджером продукта, затем тестировщики обязаны переключиться на колонку Deployed.
- Если задача успешно прошла тестирование, ей присваивают Jira статус Closed, то есть переносят в колонку Ready 4 deployment.
- Если задача не прошла тестирование, ей присваивают статус Reopened, то есть переносят в колонку Reopened.
- Если в данной колонке находиться задача, которую вешал одни разработчик другому, то проверить данную задачу согласно пунктам выше должен разработчик, который создал задачу.
- Если в данной колонке находится под-задача, относящаяся к большой, общей задаче, то менеджер продукта обязан спрятать эту подзадачу с доски (мы прячем так — ставим версию Fake version в поле Fix Version, а эта версия была давно зарелижена, поэтому таск исчезает с доски), а в будущем тестировщики будет проверять эту задачу в рамках общей/корневой задачи.
Reopened
- В данной колонке представлены задачи с Jira статусом Reopened и требующие исправления.
- Разработчик не имеет права брать новую задачу из To Do, пока у него есть задачи в Reopened.
Ready 4 Deployment
- В данной колонке представлены задачи имеющие Jira статус Close и требующие заливки на продакшн или же задачи, которые будут включены в финальный билд и залиты в AppStore/Google Play.
Deployed
- В данной колонке представлены задачи, имеющие Jira статус Deployed и залитые на продакшн или же включенные в билд мобильного приложения, который уже отправили на ревью в магазин.
- менеджер продукта обязан включить задачи, относящиеся к мобильным приложениям, в road map .☆ Apps Versions для последующего контроля версий, а далее убрать их с доски, поставив Fake version.
- Также менеджер продукта обязан актуализировать состояние задач на доске Production в Trello, то есть перенести выполненные задачи из колонки Developing в Live. В этот момент все заинтересованные лица получают уведомление о выпуске новой фичи.
- Задачи, не связанные с мобильными приложениями, обязаны быть приняты отделом тестирования на продакшне.
- Если тестировщики приняли задачу, то ей устанавливается Jira статус Accepted.
- Тестировщики работают с данной колонкой после 14.00, если отдельно не оговорен порядок тестирования с менеджером продукта.
- Технические задачи, которые создают разработчики, обязаны быть приняты авторами и им должен быть присвоен статус Accepted.
Accepted — В данной колонке представлены задачи, имеющие Jira статус Accepted, данный статус тестировщики выставляют после проверки данной задачи на продакшне.
- Менеджер продукта переодически очищает, то есть прячет (ставит Fake version) задачи из данной колонки.
