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.

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

Название	Мое мнение
Waterfall	Видел и участвовал при внедрениях в госпроектах. Это были решения на разных платформах типа CRM, ERP от мощных поставщиков, таких как IBM, SAP, Microsoft. Неприменим в текущих реалиях украинского IT-рынка и требований западных клиентов. Особенность: каждый следующий этап SDLC не выполняется до тех пор, пока текущий этап не закончится и не сдастся под подпись. Уже давно не встречал.
Scrum	Лучшее применение находит в случае, когда есть команда или несколько команд, которые работают только над одним проектом. Например, у вас есть 2 и более полноценные команды, один Project Manager и один проект. Пример состава команд: FE — 2 FTE; BE — 2 FTE; QA — 1 FTE; BA — 1 FTE. Повышения производительности можно достичь при масштабировании количества команд и накоплении доменной экспертизы. Основной принцип — итерационность.
Kanban	Используется, когда нет определенного количества проектов: они то появляются, то исчезают. Есть более или менее стабильная команда. Соответственно, есть просто поток задач, которые необходимо сделать, основываясь на приоритетах проектов. Приоритетом может служить дедлайн или негодование клиента. Повышения производительности можно достичь увеличением пропускной способности сервиса (QA/BE/FE) или формированием скоупа для разработки с горизонтом 2–4 недели вперед.

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

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

Stakeholder	Проблема	Статус
Менеджмент	Сдвиги в сроках по взаиморасчетам с клиентами	In Progress
	Отсутствие понимания соотношения выполняемых работ в проекте (BE/FE/CRZ/QA/BA)	Done
Project Manager	Нет понимания загрузки команды в цифрах. Есть понимание на уровне gut feeling и только на сегодня	In Progress
	Отсутствие понимания готовности проекта в определенную точку времени	Done
	Все проекты сдаются не вовремя	In Progress
Команда разработки	Нет четкого понимания процесса взаимодействия между участниками команды (кто, с кем, когда и что делает)	Done
	Нет понимания, какая разница между Task/Story/Sub-Task	Done
	Нет понимания, какие задачи необходимо делать сегодня и каков план на завтра	In Progress
	Плохо описаны или отсутствуют User Story	In Progress

Проблема	Причины	Причины второго уровня	Решение
Нет четкого понимания процесса взаимодействия между участниками команды (кто, с кем, когда и что делает)	Отсутствие лидера с видением процесса delivery		Нанят лидер с таким видением и всеми полномочиями
Нет понимания, какая разница между Task/Story/Sub-Task	Отсутствие правил ведения backlog		Была рассказана идея ведения backlog и надобности каждого типа в нем. Проведены воркшопы
Нет понимания, какие задачи необходимо делать сегодня и каков план на завтра	Отсутствие утвержденного backlog с горизонтом хотя бы на неделю вперед		Проведены воркшопы с BA на тему утверждения User Story в кратчайшие сроки, а также удержания backlog-горизонта. Были созданы Kanban-борды, которые позволяли видеть задачи в разных группировках: by assignee; by project
Плохо описаны User Story	Низкая квалификация BA		Воркшопы/лекции/менторинг
Нет понимания загрузки команды в цифрах. Есть понимание на уровне gut feeling и только на сегодня	Отсутствие созданных сабтасков. Отсутствие плановых оценок в часах		Планирование в Tempo
Отсутствие понимания, насколько выполнен проект/релиз в определенную точку времени	Нет оцифрованных данных		Ведение всех задач через сабтаски + настройка дашбордов в Jira
Все проекты сдаются не вовремя	Плохое планирование	Плохое понимание доступности ресурсов	Планирование в Tempo
Сдвиги в сроках по взаиморасчетам с клиентами	Несвоевременная сдача проектов	Плохое планирование	Планирование в Tempo
		Плохой контроль выполнения	Дашборды в Jira
		Плохое понимание доступности ресурсов на период (неделя / две недели / месяц)	Отчеты в Tempo
	Несвоевременная оплата клиентами	Ошибки персонала на стороне клиента	...
		Ошибки персонала на нашей стороне	...
Отсутствие понимания соотношения выполняемых работ в проекте (BE/FE/CRZ/QA/BA)	Нет оцифрованных данных	Никто не знал, как оцифровать данные	Создана специальная структура в Jira, которая позволяет увидеть количество запланированных и затраченных ресурсов по каждому из видов работ (BE/FE/CRZ/QA/BA)

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

Размышления

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

До 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 для організації робочого процесу