Организовали работу команды глубокой разработки в Kaiten. Опыт крупной IT-компании
Единое рабочее пространство для всех процессов команды инженеров — от декомпозиции задач до разработки решений и аналитики.
Мы пообщались с представителем направления по развитию бизнес-сервисов крупной IT-компании — Александром Давыдовым. Он выступал в роли Service Request Manager в команде, которая занималась обработкой узкоспециализированных задач поддержки бизнес-сервисов.
Вводные на старте работы
В компании запустили новый проект, связанный с глубокой разработкой и переписыванием сервисов с одной технологии на другую. Моей задачей было наладить все процессы в новой команде, то есть организовать бесперебойный поток работы, вести правила и наладить коммуникации с другими подразделениями.
А еще:
- Стандартизировать эпики и провести декомпозицию задач;
- Контролировать скорость выполнения работы;
- Получить понятную аналитику для внедрения улучшений.
Цель была такая: Настроить процесс таким образом, чтобы он двигался сам, даже если Service Delivery Manager и Service Request Manager какое-то время отсутствуют.
В итоге получилось организовать удобное рабочее пространство в Kaiten, которое не усложняет процесс и избавляет от лишней бюрократии. Сейчас работа над этим проектом уже завершена, но я думаю, этот кейс стоит взять на заметку небольшим проектным командам разработки.
Как организовали работу в Kaiten
Так выглядит пространство команды глубокой разработки. На нем собраны несколько досок, которые позволяют визуализировать все процессы на одном экране:
- планирование и декомпозиция задач;
- прием заявок от смежных подразделений;
- проработка инициатив;
- непосредственно разработка;
- вспомогательный дашборд со всеми необходимыми данными.
Бэклог
У этой команды не было как такового бэклога продукта. Был бэклог проекта. Для его проработки мы создали отдельную доску на пространстве. Она разделена на 3 дорожки, в каждой из которых находится очередь задач определенного типа:
- разработка и технические задачи;
- исследование / рефакторинг / нематериальное;
- и техдолг.
Такая визуализация позволяет не сваливать все идеи в одну кучу, а сразу разделять задачи по категориям.
Заявки от смежных команд
Несмотря на то, что в этой команде не предполагался большой объем входящих заявок, мы все же решили предусмотреть возможность приема задач от смежных команд. Чтобы такие запросы не отправлялись хаотично на доски нашей команды и не сбивали текущие приоритеты, мы завели для них отдельную гостевую доску.
Визуализация процесса разработки
Также на отдельной доске визуализировали непосредственно процесс работы команды, разделив его на этапы и стримы.
Основные этапы работы — это «Принято к выполнению», «В работе», «Приемка» и «Готово». В свою очередь, колонку «В работе» мы разделили на 3 подэтапа, через которые проходят все задачи: «Проектирование», «Разработка», «Ревью и тестирование».
Это дает нам больше прозрачности и позволяет быстро отслеживать статус задач и их количество на каждом из этапов.
Кроме этого доска делится на стримы (горизонтальные дорожки). На каждой дорожке ведется работа с определенным типом задач.
- Срочные — требуют незамедлительного решения и обладают наивысшим приоритетом.
- Общий поток — все что мы делаем в рамках запланированных работ.
- Для исследований, рефакторинга и каких-то дополнительных задач есть отдельная дорожка.
Все участники команды должны понимать алгоритм работы с задачами, поэтому мы закрепили правила в описании самой доски. Здесь подробно описано, сколько задач мы берем в работу, когда, откуда, по каким условиям передвигаются карточки и так далее.
Ограничение незавершенной работы
Чтобы равномерно распределять нагрузку, избегать узких мест в процессе и стимулировать команду к завершению начатых задач, мы используем WIP-лимиты — ограничение количества задач, которые могут одновременно находиться на этапе работы:
- Благодаря лимиту на этапе «Принято к выполнению», команда добавляет карточки соразмерно своим ресурсам и берет обязательство только по тем задачам, которые действительно сможет выполнить в срок.
- Этап «В работе» ограничен более широким лимитом, так как производительность разработчиков высокая, а узкое место в процессе возникает дальше — на этапе приемки.
- В «Приемке» может одновременно находиться не более 3-х карточек. У команды один тим-лид, а проверить нужно много задач. Чтобы они поступали равномерно, мы ограничили этот поток.
Раньше я использовал и другие канбан-сервисы, например Trello, Todoist и Workzen от МТС, но ни в одном из них не было возможности выставлять WIP-лимиты на досках. Kaiten в этом плане хорошо помогает.
Доска для работы с документацией
Еще одна доска играет роль информационного дашборда, чтобы важные данные всегда были под рукой. Здесь в отдельных карточках зафиксированы ценности и договоренности, документация и полезные ссылки, а также разные заметки для команды, например, график отпусков или регламенты проведения каденций.
Типизация задач
В Kaiten можно создавать шаблоны заполнения карточек для разного типа задач, чтобы можно было на входе и на выходе собрать нужную информацию под определенные стандарты и требования.
Мы использовали разные типы для эпиков, багов и тасков — под каждый из них был заготовлен специальный шаблон заполнения.
Чек-листы
Чек-листы внутри карточек значительно облегчили работу, потому что не нужно было создавать много дочерних карточек, привязанных к одной задаче. Достаточно было сделать наглядное распределение подзадач в виде пунктов чек-листа, на каждый пункт назначить ответственного и установить дедлайн.
Аналитика
Учитывая, что у нас была подробная визуализация процесса и все участники команды придерживались установленных правил, было легко отслеживать эффективность работы команды, глядя на два автоматических отчета:
- Накопительная диаграмма потока (CFD) — График показывает, насколько стабилен рабочий поток, подсвечивает текущие и прошлые проблемы, узкие места, а также позволяет рассчитать время цикла, пропускную способность и количество работы в процессе.
- Cycle time — автоматически подсчитывает одну из основных канбан-метрик. Показывает время, которое команда фактически тратит на выполнение задачи: от момента взятия в работу до поставки.
Накопительная диаграмма потока. Глядя на этот график можно легко определить количество работы в процессе, время цикла, время производства. А еще увидеть узкие места и другие проблемы в процессе.
Общие впечатления и сравнение с другими сервисами
Мы хотели организовать работу команды по kanban-методу. А Kanban — это не только про решение задач, а скорее и про построение процесса в целом. Kaiten в этом плане оказался подходящим универсальным инструментом, в котором можно собрать рабочее пространство любого вида, добавить на него несколько досок, построить взаимосвязи между задачами и менеджерить весь процесс, а не просто следить за задачами.
Для меня, с точки зрения удобства процессов, Kaiten выигрывает у Jira. Визуализация досок гораздо удобнее, появляется наглядность и ощущение духа командной работы.
Все основные метрики собираются автоматически, и их может посмотреть любой сотрудник. Это мотивирует участников команды работать на результат, чтобы не поехала общая статистика.
Если сравнивать с российскими сервисами, то я много лет работал в Битрикс24. И хотя разных инструментов в нем больше, Kaiten показался более адаптированным для пользователя, корпоративной работы и командных процессов.