Почему «Додо Пицца» стала использовать Kaiten вместо связки Trello и Jira
Как и многие компании, которые разрабатывают софт, мы использовали одновременно два самых популярных трекера для задач — Jira и Trello.
Команды у нас всегда имели большую степень свободы в использовании инструментов для работы. Менеджеры продуктов использовали Trello для работы над бэклогом и его обсуждения с бизнесом. Разработчики декомпозировали крупные проекты из Trello в пользовательские истории и вели работу в Jira. Инженеры и QA в своё время выбрали Trello и так на нём и остались.
Используя Trello и Jira одновременно, мы столкнулись с двумя проблемами
Во-первых, приходилось синхронизировать два бэклога для одного продукта. В Trello жил бэклог крупных проектов, а в Jira неизбежно возникала своя жизнь — мелкие баги, недоделки, технически задачи.
Во-вторых, никто кроме менеджеров продуктов не понимал, как по-настоящему работает весь процесс «от идеи до продакшна» здесь и сейчас. Переходы задач из бизнес-анализа в разработку, а из разработки в QA приходилось дирижировать на специальных синхронизациях, иначе информация просто терялась.
Мы смотрели на эти проблемы как на неизбежное зло в течение многих лет. Они неприятные, но вполне себе управляемые. В апреле 2018 года у нас заканчивается контракт с компанией Atlassian (владеет Jira и Trello), и мы решили осмотреться — есть ли на рынке один продукт, достаточно удобный для всех команд, который бы решал в том числе и эти проблемы.
Ключевым фактором отбора для нас стала способность инструмента визуализировать все особенности нашего рабочего процесса as is, без сложных настроек и подгонки своего рабочего процесса под сам инструмент.
Для начала мы попытались перетащить друг друга в Jira и Trello.
Готовы ли менеджеры продуктов полностью переехать в Jira
Работа разработчика гораздо проще укладывается в workflow из Jira, она действительно похожа на конвейер — задача путешествует по окружениям разработки, пока не доходит до продакшна.
Задачи в бэклоге, над которым работает менеджер продукта, всегда очень разные. Некоторые очевидны и требуют просто описать требования. Другие требуют предварительного дизайна. Третьи предполагают предварительные глубокие исследования пользователей.
Работа над четвёртым типом задач не заканчивается в момент, когда она доведена до продакшна — в этот момент начинается её анализ. Наконец, большинство задач сочетает в себе некоторые из этих качеств в произвольном порядке.
Это заставляет менеджера продукта постоянно перестраивать свой рабочий конвейер в поисках оптимального способа управлять задачами так, чтобы все участники понимали, что происходит, просто глядя на доску. И это занимает немало времени.
Jira может дать какую угодно гибкость, но эта гибкость достигается с помощью конфигурирования настроек workflow. Любой, кто настраивал себе workflow в Jira, знает, что это реально, но долго и сложно. В Trello это делается на лету, а любые правила работы с доской проговариваются, а не автоматизируются. Это буквально вынуждает команду чаще обсуждать доску и оперативно менять её правила. И это круто.
Менеджеры продуктов оказались не готовы к переезду в Jira.
Готовы ли команды девелоперов переехать полностью в Trello
Trello и доступные к нему интеграции с лихвой покрывают все потребности одной достаточно изолированной девелоперской команды. Он интуитивный, быстрый и понятный. Именно поэтому его у нас выбрали более автономные команды инженеров и QA.
Однако сложности начинаются, когда несколько девелоперских команд работают над одним продуктом, при этом каждая развивает своё измерение бэклога (одни работают над любыми проектами, другие поддерживают внутренний сервис, третьи развивают конкретный блок функциональности).
Именно проблемы комплексных связей решает Jira, где можно собрать любое представление задач в виде доски, используя ярлыки (labels). В Trello по ярлыкам можно делать только фильтрацию. Сделать удобную визуализацию больших проектов не получилось.
Команды девелоперов оказались не готовы к переезду в Trello.
Решением для нас стал российской продукт Kaiten, в центре которого находится канбан-метод
Во-первых, Kaiten позволяет видеть сразу несколько досок, которые работают по разным принципам в одном пространстве. Это даёт возможность визуализировать процесс практически любой сложности в одном месте — без необходимости переходить куда-то, чтобы увидеть всю картину.
Подобная визуальная гибкость есть у обычной офлайновой пробковой доски, но Kaiten обладает и классическими трекинговыми функциями (статусы, дочерние задачи, оценки, сроки, описания), без которых работать над большим проектом очень трудно.
Все видят однозначную и понятную картину того, как устроен процесс. При этом, если мы захотим изменить его, нам достаточно создать ещё одну доску в этом же пространстве и перетащить туда, куда нужно.
Доской можно управлять так, как удобно, с помощью простого drag-n-drop
Во-вторых, Kaiten позволяет вкладывать пространства друг в друга. Именно эта функциональность позволила визуально представить весь рабочий процесс от customer development идеи, через продакшн и до пост-продакшн-аналитики.
С пространства, где для каждой команды мы видим только три колонки, мы можем провалиться в доску любой из команд. Там будет отражён уже реальный процесс, по которому команда работает
В-третьих, Kaiten позволяет иметь в своём пространстве чужие доски в актуальном состоянии (считай — рабочие процессы). Если вам нужно быть в курсе того, как идёт работа над связанным проектом, вам не нужно никуда переходить — вы просто добавляете чужую доску себе в пространство и можете работать с ней так же, как если бы она была вашей.
Владелец продукта видит в своём пространстве вложенную доску разработки. Задачи связаны с теми, что двигаются по внутреннему процессу разработчиков, но без избыточной детализации
В-четвёртых, Kaiten позволяет на полную катушку использовать приёмы канбан-метода. Выставлять лимиты work in progress, подсвечивать заблокированные карточки, выставлять политики для колонок и дорожек, анализировать время доведения карточек до статуса «Готово». При этом Kaiten не вынуждает вас подстраивать свой процесс под свою модель — вы адаптируете Kaiten под свой процесс.
Отдельно скажу, что в моём опыте не было более безболезненного перехода команды из семидесяти человек на новый инструмент для управления проектами. Мы выбрали по канбан-евангелисту из каждой команды и перетащили задачи, а в день Х просто увидели привычные сущности в привычном процессе в новом инструменте.
Есть и минусы — быстродействие приложения при большом количестве досок и карточек в пространстве. Здесь разработчикам ещё есть над чем поработать. Не вызывает восторга и дизайн — он далёк от высоких потребительских свойств того жe Trello.
В прошлом не было смысла хорошо оформлять карточки, ведь приходилось делать тройную работу, переводя их из одной системы в другую, информация постоянно терялась. Сейчас мы видим, что люди инвестируют время в поддержание хорошего качества описаний и проставление связей между карточками, потому что это начало приносить участникам процесса ценность.
А это приводит к тому, что мы можем наконец начинать доверять нашим доскам и полагаться на них, принимая решения без необходимости уточнять друг у друга: «А эта задача точно сейчас на регрессионном тестировании?»
Мы в «Додо Пицце» работаем на Kaiten уже больше двух месяцев. Инструмент, на наш взгляд, представляет очень эффективную альтернативу связки Trello и Jira.
#инструменты
© vc.ru
