Почему я не веду разработку ПО в Trello?
Я давно являюсь поклонником Trello. Чтобы вы понимали, я пользовался Трелло с 2011 года — именно тогда он вышел на рынок. В этой статье я хочу рассказать о том, чего не хватает в Трелло разработчикам ПО и что с этим можно сделать.
Долгий путь к Trello
Но прежде чем перейти к сути, хочу отдать должное уважение другим системам управления, которыми я пользовался и которые повлияли на мое мировозрение.
Первая моя система управления проектами — Mantis. Потом был Rational Clearquest, потом был Acunote. Потом было много чего еще, пока я не встретил Jira. Jira покорила меня — это был лучший продукт в свое время на рынке — на мое imho. Потом в Jira появился плагин Greenhopper, который добавил Скрам и Канбан в Jira. Это была революция — переход от обычного списка задач к Канбан доскам. Visibility поднялся на новый уровень. Благодаря WIP-лимитам мы нашли узкие места в процессе. Swimlanes позволили фиксить блокеры в режиме реального времени. Об этой революции я не мог не написать — Как настроить Канбан в Jira для разработки своих продуктов.
Но оставалась одна проблема — непрограммисты (маркетологи, редакторы, продакты, менеджеры) НЕ ПОНИМАЛИ Jira и не хотели там работать. И поэтому приходилось все время держать две системы. Вспоминается Сomindwork и еще какие-то там штуки. Но тут появился Trello. Мой кумир Джоэл Спольски запилил очередную бомбу, которая подсадила все офисы мира на Канбан, в том числе и мой офис.
Я сразу же перевел всех right-brainers на Trello. Своим счастьем я поделился в Сети — Как мы используем trEllo при разработке Meetville.
От Jira к Trello
Мы с моим партнером в далеком 2010 начали разработку нового стартапа. Для программистов я по умолчанию выбрал Jira. Но возник вопрос —, а где работать остальной команде? Им ведь тоже нужен тул для управления задачами. Мой партнер по бизнесу (со специализацией в маркетинге) наотрез отказался работать в Jira — она вызывала у него страх и ненависть. Ну, а что еще ожидать от bug tracking tool — именно с такого позиционирования начиналась Jira? Она не была тогда предназначена для обычного управления нетехническими задачами. В принципе и в конце 2017 Jira осталась тулом только для программистов. Поэтому мой партнер нашел Comindwork и мы (UX, product team, дизайнеры, маркетологи, офисные сотрудники) пошли туда.
Потом в 2011 году появился Trello и я перевёл всех гуманитариев нашего проекта с Сomindwork на Trello. На фоне Джиры и любой другой системы управления проектами Trello выделялся своей простотой, минимализмом, скоростью работы и конечно же Канбан досками. Взять хотя бы mentions — насколько классно они их сделали. Другие системы спамили ящики всякой несущественной ерундой. А вот Trello как-то удалось сделать мега-удобные и ненавязчивые уведомления о mentions. По сути они сделали из mentions новый стандарт для систем управления.
Короче, я попробовал на вкус Trello и захотел вооружить им не только гумов, но и всех программистов. Однако я не смог, и вот почему.
Чего не хватает программистам в Trello для полного счастья?
Дальше я буду считать, что команда работает по Agile — по Канбану или по Скраму.
Вот чего не хватает для полноценной поддержки Scrum и Kanban в Trello:
1. Swimlanes
Впервые я их увидел в Jira. Представьте себе вертикальные колонки на доске, представили? Так вот Swimlanes — это горизонтальные колонки. Как правило на доске для разработчиков мы делаем три swimlanes: Blockers, Tasks & Bugs и Someday.
99% времени люди делают задачи из Tasks & Bugs. В Someday мы откладываем те задачи, до которых скорее всего никогда не дойдет очередь. Как правило «правильные» тестировщики находят много багов, большинство которых нужны для полировки, а не для мойки машины. Поэтому кстати команду тестировщиков нужно подтягивать к тому, чтобы они могли сами решать какой баг критичен, какой можно взять в долг (и сделать в обозримом будущем), а какой стоит отложить на «когда-нибудь» в Someday.
В blockers попадают те задачи или баги, которые необходимо сделать прямо сейчас, в режиме реального времени. Примеры таких задач: упал сервер, сломались платежи или регистрация, новые exceptions из crashlytics/rollbar/sentry. По соглашению в нашей компаний программист должен немедленно переключиться на решение блокирующего бага. Важно следить за тем, чтобы в blockers попадали действительно блокирующие баги, в противном случае у людей выработается слепота к блокерам и они перестанут придавать им должное значение.
2. WIP лимиты
WIP лимиты позволяют ограничить число задач сверху и снизу, которое может находится в какой-то колонке. Если задач становится больше или меньше, то колонка сообщает об этом «вслух», например фоновым цветом.
Для чего это нужно? Например для того, чтобы определить узкие места в процессе. Например, программисты сделали 10 задач и они находятся в очереди на тестирование. Тестировщиков всего два. Налицо проблема — у тестировщиков скопилась очередь, они не справляются с проверкой задач. Мы ставим WIP лимит на очередь задач для QA в 2 и при превышении лимита узнаем об этом. И решаем проблему, например, берем на работу еще двух тестировщиков.
3. Time tracking
Trello так и не сделал нативный time tracking. Причина понятна — у них широкая аудитория и не всем он нужен. А тем, кому нужен, могут купить дополнительный софт, например, everhour или toggl. Но это — дополнительные расходы, причем не маленькие — от 5$/за юзера до 49$/за юзера (toggl жжжет напалмом).
4. Версии и релизы
Не представляю как можно вести разработку софта без версий и релизов. Версия — по сути это тег, который мы вешаем на пачку задач. Когда все задачи из версии готовы, мы релизим эту версию. Этот же тег вешаем на коммит в гите. И дальше мы можем откатиться в случае большой беды или найти концы — определить по exception версию кода, достать его из истории коммитов и пофиксить баг.
5. Burndown chart
Нет time tracking — нет burndown chart. Нет burndown chart — нет спринтов. Burndown chart — это dashboard для команды, которая пилит спринт. Он является мотиватором (или демотиватором в запущенных случаях — когда команда сильно переоценивает свои возможности).
6. Проекты и коллекции
Без проектов и коллекций в дереве досок начинается хаос. Проект приходится кодировать в название доски. Коллекции в Trello есть, но они доступны только в Trello Business Class.
7. Типы колонок
Колонка может быть одного из трех типов: To do, in progress или done. Когда задача попадает в колонку типа done, она считается сделанной. Без такого разделения невозможно сделать спринты — потому что нам нужно знать когда задача была сделана, чтобы отразить это в Burndown chart.
Hygger — Трелло на стероидах
Все эти нюансы и легли в основу нашего продукта под названием Hygger.
Hygger — образовано от датского hygge (произносится как «хьюга» или «хуга») и означает жизненную философию, которая строится на домашнем уюте, душевном общении и чувстве безопасности. Hygge описывает гамму эмоций и чувств, которые человек испытывает от встречи с близкими, хорошей компанией или от прикосновения к мягкому свитеру. По сведениям Мирового индекса счастья, в Дании живут одни из самых счастливых людей на планете, в чем Hygge сыграло не последнюю роль.
Феномен Hygge стал настолько популярен в мире в 2016 году, что Оксфордский словарь назвал «Hygge» — словом года, наряду с двумя другими словами: brexit и Trumpism.
Надеюсь, что Hygger сделает ваше рабочее место более уютным и позитивным.
И чтобы еще сильнее разогреть ваше любопытство, вот список фишек, которых нет в Трелло, но которые есть у нас в Hygger:
Backlog доски
Backlog доски используются для сбора и приоритезации идей и фич. У каждой карточки на backlog доске есть поля value и efforts. С помощью этих полей вы можете сильно облегчить процесс выбора фич для разработки.
Value — то, как идея влияет на продукт (например, улучшает UI, увеличивает конверсию в регистрации, или увеличивает ARPD). Efforts — это трудозатраты на разработку.
Далее вы можете на графике Priority Chart увидеть 4 квадранта: quick wins, big bets, maybes и time sinks. И решить, что вам стоить отдавать в работу на ближайший спринт, а что стоит отложить. Выбранные идеи можно пушнуть на доску разработки — создается таск на разработку, который линкуется с оригинальной идеей.
Roadmap доски
Основой для Roadmap досок служит диаграмма Ганнта. Вы можете спланировать в больших квадратах ваш проект или целую группу проектов. Причем вы может добавлять на доску задачи из других досок — они будут вставлены по ссылке.
Inbox
Все важные уведомления (когда вам упомянули в обсуждении, когда на вас назначили задачу, etc.) приходят в Inbox, который отображается на главной странице. По сути Inbox — это обычные notifications, но в духе Mailbox или Google Inbox — вы можете свайпнуть сообщение вправо и оно уйдет в архив.
Activity stream
В любом туле по управлению задачами есть такая лента активности. Но благодаря разделению колонок по типам (to do/in progress/done) мы знаем, когда задача была сделана или когда ее начали делать. И поэтому можем показать задачи, которые были реально сделаны. Также тут можно посмотреть над какими задачами работают люди или какие задачи уже просрочены.
Two-Level Comments
Двухуровневые комментарии упрощают ведение дискуссий. В рамках одной задачи можно обсуждать различные вопросы в разных ветках.
Под-колонки
Например, у колонки Programming могут быть под-колонки: In progress и Done.
Умные ссылки
Когда вы вставляется ссылку в текст задачи или в комментарий и вместо ссылки выводится название доски, название задачи, название колонки и свимлейна. Также выводится ее текущий статус.
Hygger.io абсолютно бесплатен для команд до 5 человек. Рецепт датского счастья — в hygge, рецепт счастья для agile-команд — Hygger. Приходите к нам за своим рецептом!
