Kanban как основа для производства software

Привет! Я Сергей Алексеев, автор пяти, на мой взгляд, интересных статей из мира IT. В этой статье расскажу о Kanban с примерами и описанием. Это поможет вам внедрить методологию у себя или немного улучшить то, что есть у вас сейчас.

Предисловие

Задайте себе вопрос: по какой методологии или фреймворку мы ведем разработку программного обеспечения? Наверняка многие из вас ответят: Scrum. Это можно объяснить несколькими фактами:

• Scrum у всех на слуху как в интернете, так и в офлайне. Kanban, Waterfall или другие подходы менее популярны.
• Количество курсов по Scrum просто зашкаливает. Курсы не только об основах фреймворка, но и о разных ролях в нем, таких как Product Owner или Scrum Master. Их названия зачастую начинаются c «Как стать...», «Что делать...» или «Agile...». Зайдите, например, на scrum.ua, там о Kanban всего 2 курса.
• Опрос среди аналитиков и проектных менеджеров в чате дал цифру в 34% в пользу Scrum. Опрос был проведен в апреле, тогда в чате было около 500 человек.

Убедил? А теперь задайте еще несколько вопросов себе или своему менеджеру:

• Устраивает ли нас нынешний подход в разработке программного обеспечения?
• Насколько эффективно работает наша команда? (О том, что я считаю эффективным, написано в другой моей статье.)
• Выполняются ли поставленные задачи вовремя?

И так далее обо всем, что связано с метриками и процессами.

Давайте я немного расскажу о том, как я вижу картину мира, где есть 3 подхода в разработке software, и о том, для чего нужен каждый из них (мое скромное мнение):

• Waterfall;
• Scrum;
• Kanban.

Конечно же, их больше, но пока что поговорим об этих.

Проблематика

Эту статью я начал писать не для того, чтобы рассказать примитивные вещи о Kanban. Наша команда столкнулась с разного рода задачами, и я хочу поделиться способом решения некоторых из них.

Конечно же, этот список проблем был сформирован спустя время в тот момент, когда я писал эту статью. В реальности задачи появлялись одна за одной по мере решения предыдущих.

Размышления

Кейс. Есть одна команда, на которую необходимо планировать разные проекты. Когда я говорю «разные», это означает разной сложности, продолжительности, контекста и клиентов.

До 2019 года я работал в проектах двух типов: Waterfall и Scrum. Я думал, что так работают все и другого пути нет, но я ошибался. Ошибался не только в том, что нет другого пути, но и в том, что многие работают по Scrum. Я утверждаю это, потому что много общаюсь с ребятами из разных компаний, мы обсуждаем моменты взаимодействия между членами проекта, методики и принципы, по которым работают команды.

Пример. Часть людей, с которыми я пересекался, думали, что работают по Scrum, хотя на самом деле это был Kanban. Такая иллюзия была обусловлена тем, что они создавали тип проекта Scrum в Jira, помещали в активный спринт Story, Task, Sub-Task и никогда не закрывали этот спринт.

Когда я пришел в компанию, то все мои знания о Scrum и Waterfall не вкладывались в реальность, с которой я столкнулся. Мне срочно нужно было принять решение, как я буду делать delivery проектов, ибо состояние дел было примерно такое же, как у нас в государстве с медициной.

Проанализировав структуру моих проектов, состав команды и необходимость быть гибким, я четко осознал, что мне нужно идти по пути Kanban вместо Scrum.

Несколько недель все работало так, как до моего прихода. Я пытался вникнуть в то, что происходит, и проанализировать ситуацию. Я ничего не трогал, дабы не сломать :) Сидел вечером на работе и думал над тем, как бы решить эту задачу, вывести все в понятный и прозрачный процесс, где каждый понимает свою роль и происходящее вокруг. Я вспомнил, что совсем недавно читал вот эту статью, где ребята поделились своим подходом к организации процесса разработки. Мне понравилась идея с кросс-продуктовыми командами, где есть общие сервисы (Design/Dev/QA). Меня эта идея более чем устраивала, поскольку количество ресурсов было небольшим, а продуктами для меня были проекты. Я тоже решил привязаться к релизам и запустить работу по Kanban. В тот момент я практически ничего не знал о Kanban, кроме общих принципов, которые звучат следующим образом: To Do => In Progress => Done.

Мне пришлось немного поменять организационную структуру департамента, чтобы новые правила вступили в игру.

Новая организационная структура

Head of Department — формирование бюджета. Формирование delivery процессов в департаменте. Развитие существующих клиентов (up-sell и cross-sell), ответственность за прибыльность департамента. Отчетность напрямую владельцам компании.

PM — корректировка процессов delivery. Ответственность за соблюдение сроков реализации проектов. Планирование ресурсов. Участие в решении вопросов, которые требуют эскалации. Формирование понимания того, как будут идти процессы взаимодействия между клиентом и компанией (change management, payments, product shipment и т. д.).

Product Manager — ответственность за формирование скоупа продукта. Выполнение активностей в разрезе инициатив Sales & Marketing (например, рассылка писем участникам презентаций продуктов, встречи с клиентом при продаже). Ежедневная работа с командой. Видение и стратегия оставались на собственниках.

Pre-Sales BA — формирование коммерческого предложения клиенту на основе скоупа и оценки проекта. Коммуникация с клиентом до подписания контракта.

Account Manager — контроль над документооборотом (оформление контрактов, выставление счетов и закрытие актов). Коллаборация с проектным менеджером, чтобы понимать, когда и что будет сдано, для выставления счетов и корректировок в плане оплат.

Corezoid BA — ведение нескольких проектов с точки зрения формирования требований и написания документации. Управление ожиданиями клиента в разрезе функциональности, которую планируется реализовать. Имплементация автоматизации бизнес-логики с помощью специальной платформы Corezoid. Демонстрация выполненной функциональности клиенту.

BE Developer — каст заклинаний и магия. Пополнение маны из кофемашины.

FE Developer — каст заклинаний и магия. Пополнение маны из кофемашины.

QA — отдельный сервис по тестированию без привязки к конкретному проекту.

Почему я не выбрал Scrum?

Ответ для меня показался очевидным из-за разношерстности проектов, их дедлайнов и неопределенности. Основная неопределенность была в том, что я мог подписать проект продолжительностью 3 недели, который надо начинать делать уже сегодня, потому что клиент подвязан под публичное событие (например, фестиваль или рекламу на ТВ/YouTube). Такого рода задачи подразумевают гибкость в планировании и реализации.

Scrum подразумевает четкую итеративность и фиксированную функциональность в итерации. К сожалению, я не мог и пока не могу так делать — как минимум из-за небольшой продолжительности проектов (1–3 месяца) и, конечно же, из-за отсутствия возможности выделить отдельную команду под каждый проект.

Внедрение

Задача: оцифровать все, что происходит в департаменте, и объяснить команде правила игры.

Поскольку все проекты были связаны с чат-ботами, а их продолжительность была невелика, я принял решение не вести отдельный проект в Jira под каждый из них, а создать один проект под названием Chat Bots, в котором будут все проекты.

Мне необходимо было иметь стандартизированный процесс выполнения работ командой и общепринятые правила в разработке программного обеспечения. Первым делом я решил создавать минимальный процесс и настроить интерфейсы для работы команды. В глубине души я понимал, что ребята из команды Atlassian уже решили почти все мои боли, осталось только найти это решение и собрать все вместе, не нужно изобретать велосипед. Первым делом я пошел на официальные ресурсы Atlassian и почитал user guides по Jira и Tempo.

Проведя несколько десятков часов ресерча после работы, я понял, что рано или поздно мне понадобится информация, которую я планирую собирать в Jira. Я не спешил и хорошенько подумал над структурой, ведь это то, чем я занимался последние несколько лет в своей работе. Через несколько дней я придумал, как мне реализовать нужную мне структуру в Jira, которая позволит анализировать данные не только в конце проекта, но и в реальном времени.

После того как я все обдумал и создал проект в Jira, я попросил команду перенести информацию по всем проектам в эту структуру. Конечно же, изначально я рассказал ребятам, как это будет работать и зачем нужны такие усилия, и предоставил им инструкцию.

Ниже приведены примеры того, как выглядела информация изначально и на промежуточном этапе.

Вот так выглядела информация для принятия операционных решений вначале:

Эта таблица не несла никакого смысла, кроме агрегирования всех проектов в одном месте. Процент выполнения проставлялся исключительно на калькуляциях и формулах в голове PM. Это очень субъективно и неправильно.

К слову, многие проектные менеджеры, которых я собеседовал, считают такие таблички нормальной реальностью.

А так выглядела информация до внедрения Jira и после таблицы в Excel

Эта доска была промежуточным этапом между Excel и Jira и прожила около 3 недель. Через 2 недели после ее создания я попросил команду перенести все в Jira и дал на это неделю. Через неделю информация была стерта с доски, и те, кто не успел перенести, заполняли пробелы из своей головы. И так наступила эра цифровизации.

Структура сущностей в JIRA

Entities relationship in Jira

Эта структура показывает зависимость между сущностями Jira внутри одного проекта. По факту у меня было 3 проекта.

• Chat Bots — совокупность всех аутсорсинговых проектов, которые были проданы нашей командой.
• Product — работы, выполняемые в разрезе будущего продукта, а также задачи типа R&D.
• Administrative — поскольку я перестраивал процессы или выстраивал их с нуля, мне необходимо было отслеживать административные задачи и время на их выполнение. Примеры:
• QA — формирование внутренней документации или настройка service desk.
• Pre-Sales — понимание затраченного времени на каждый из этапов работы аналитиком в pre-sales-процессе.

Также хочу отметить, что все аналитики ведут свой backlog. Несмотря на то что все User Story находятся в одном проекте, функциональность Jira позволяет достаточно легко визуально разделять данные между людьми. Это возможно благодаря фильтрам.

Давайте перейдем к тому, почему же я все-таки решил строить отдельную структуру зависимостей и почему мне не хватило стандартной схемы. Вся структура была создана, чтобы корректно строить отчетность и понимать, куда потрачено время в конкретном разрезе времени. Те, кто строил WBS, поймут меня ;)

Project Type — позволяет разделить время (planned/fact) на уровне проекта:

• product;
• outsourcing.

Account
Эта сущность была создана, чтобы обозначать клиентов, по которым ведется работа. Потому что по одному клиенту могут быть разные проекты. Например, у одной компании проекты могут быть разбиты по брендам.

Component
Предназначены, чтобы описывать проект. У меня компонент — это название проекта. Соответственно, у одного аккаунта могут быть разные компоненты в один промежуток времени. Если бы вы вели проекты по Scrum, это были бы отдельные проекты в Jira. У меня это отдельные компоненты внутри одного проекта.

Fix Version
Используются, чтобы обозначать релизы в отдельных проектах (компонентах). В одном проекте может быть несколько версий. Соответственно, в одном проекте может быть несколько релизов. Они могут быть проданы как одним, так и разными контрактами, но это все равно будет один и тот же проект.

Task
Служит для фиксации времени, описания документации аналитиками или выполнения работы дизайнером.

Story
Является агрегатом бизнес-функциональности. Более подробно я рассказываю об этом в своем видео User Story canvas.

Sub-Task
Основная задача — аккумулирование времени — планируемого и фактического — на выполнение стори. Также сабтаски используются для выделения отдельных типов работ. Последнее время я делаю достаточно просто: у меня в стори создается всего несколько сабтасков (BE/FE/CRZ/QA/BA). Они аккумулируют время, потраченное на реализацию функциональности. Если ваша команда достаточно сплоченная, можно разбивать стори на более детальные сабтаски — так они будут давать более точные данные.

Tempo Time
Поскольку у меня есть приложение Tempo в Jira, в сабтасках есть возможность планирования и отслеживания времени их выполнения с использованием Tempo. Когда вы планируете сабтаски, задавая время и дату начала, Tempo автоматически показывает в календаре сабтаск по определенному сотруднику, учитывая выходные дни, количество рабочих часов и загрузку сотрудника в этот период.

Результаты

По моему мнению, этот раздел будет самым интересным в статье. Ниже приведены примеры из реальных проектов и команды.

Я начну показывать примеры полученного результата.

Tempo report — work time tracking

Этот отчет построен по структуре, которую я описывал выше в статье. Он позволяет выгрузить эту структуру в Excel с декомпозицией до сабтаска, в которых указано 3 параметра времени (Planned Estimate / Original Estimate / Remaining Estimate). Информация такого характера позволит вам рассчитать рентабельность вашего проекта почти в реальном времени, сравнить, почем продали и за сколько сделали, ну и еще много разных и полезных вещей.

Capacity report — planned time

Этот отчет позволяет увидеть загрузку не только каждого человека по отдельности, но и команды целиком. Желтым цветом выделены те места, где загрузка превышает 100%.

Capacity report — resource availability

Благодаря этому срезу вы сможете увидеть, сколько часов доступно у конкретного человека или команды в целом. Считается на основе планового времени в сабтасках, в которых assignee — конкретный пользователь.

Tempo — resource planning view

Это представление дает возможность визуально определить, кто из ваших коллег загружен более, чем нужно, а у кого есть время поиграть в теннис :) Более детально о том, как это работает, вы можете почитать в документации или же спросить у комьюнити в этом чате.

Tempo — resource planning timeline

Так выглядит интерфейс для проектного менеджера, чтобы планировать задачи на людей. О том, как идет процесс планирования, я напишу отдельную статью, а пока что вы можете попробовать сами или же написать, позвонить и спросить у меня лично.

Tempo — resource planning view (by person)

Так выглядит планирование одного человека, все это основано либо на реально созданных сабтасках в Jira или же на фейковых (плановых) задачах для человека.

Планирование и отслеживание прогресса по релизам

Так выглядит сейчас информация о прогрессе работы над релизом внутри проекта.

А вот так выглядят те же релизы, если их добавить на дашборд через гаджет.

А вот так выглядит релиз изнутри. То есть нажав на название релиза, вы можете попасть в его карточку и посмотреть, что конкретно реализовано, а что нет.

User Story card

Тут я вам хотел показать, как выглядят поля в самой Jira внутри User Story. Эти поля заполняются бизнес-аналитиком при создании, а все позже созданные сабтаски наследуют значения этих полей автоматически через автоматизацию Jira.

User Story flow

Sub-Task flow

Business Analyst view

Зеленым показаны User Story, в которых прописана бизнес-функциональность. Синим цветом показаны таски.

Developer view

Вот так вот выглядит view для разработчика.

Итоги

Я не могу сказать, что мы идеально или оптимально используем Kanban в нашей повседневной работе. Мы всего лишь перешли из каменного века в эпоху промышленной революции, но еще не дошли до информационной революции.

Нам еще многому стоит научиться и придется со многим столкнуться. Спустя 5 месяцев мы только начали придерживаться принципов, которые были внедрены. А еще нам предстоят анализ и оптимизация.

В Kanban есть много разных отчетов и показателей, основываясь на которых можно делать выводы и улучшать процесс, но на это нужно время.

Спасибо, что дочитали до конца.

Читайте также: Чому варто спробувати Kanban & Monday для організації робочого процесу