Kanban как основа для производства software
Привет! Я Сергей Алексеев и в этой статье расскажу о формировании базы, для использвоания 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. Это очень субъективно и неправильно.
К слову, многие проектные менеджеры, которых я собеседовал, считают такие таблички нормальной реальностью.
Эта доска была промежуточным этапом между Excel и Jira и прожила около 3 недель. Через 2 недели после ее создания я попросил команду перенести все в Jira и дал на это неделю. Через неделю информация была стерта с доски, и те, кто не успел перенести, заполняли пробелы из своей головы. И так наступила эра цифровизации.
Структура сущностей в 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 автоматически показывает в календаре сабтаск по определенному сотруднику, учитывая выходные дни, количество рабочих часов и загрузку сотрудника в этот период.
Результаты
По моему мнению, этот раздел будет самым интересным в статье. Ниже приведены примеры из реальных проектов и команды.
Я начну показывать примеры полученного результата.
Этот отчет построен по структуре, которую я описывал выше в статье. Он позволяет выгрузить эту структуру в Excel с декомпозицией до сабтаска, в которых указано 3 параметра времени (Planned Estimate / Original Estimate / Remaining Estimate). Информация такого характера позволит вам рассчитать рентабельность вашего проекта почти в реальном времени, сравнить, почем продали и за сколько сделали, ну и еще много разных и полезных вещей.
Этот отчет позволяет увидеть загрузку не только каждого человека по отдельности, но и команды целиком. Желтым цветом выделены те места, где загрузка превышает 100%.
Благодаря этому срезу вы сможете увидеть, сколько часов доступно у конкретного человека или команды в целом. Считается на основе планового времени в сабтасках, в которых assignee — конкретный пользователь.
Это представление дает возможность визуально определить, кто из ваших коллег загружен более, чем нужно, а у кого есть время поиграть в теннис :) Более детально о том, как это работает, вы можете почитать в документации или же спросить у комьюнити в этом чате.
Так выглядит интерфейс для проектного менеджера, чтобы планировать задачи на людей. О том, как идет процесс планирования, я напишу отдельную статью, а пока что вы можете попробовать сами или же написать, позвонить и спросить у меня лично.
Так выглядит планирование одного человека, все это основано либо на реально созданных сабтасках в Jira или же на фейковых (плановых) задачах для человека.
Так выглядит сейчас информация о прогрессе работы над релизом внутри проекта.
А вот так выглядят те же релизы, если их добавить на дашборд через гаджет.
А вот так выглядит релиз изнутри. То есть нажав на название релиза, вы можете попасть в его карточку и посмотреть, что конкретно реализовано, а что нет.
Тут я вам хотел показать, как выглядят поля в самой Jira внутри User Story. Эти поля заполняются бизнес-аналитиком при создании, а все позже созданные сабтаски наследуют значения этих полей автоматически через автоматизацию Jira.
Зеленым показаны User Story, в которых прописана бизнес-функциональность. Синим цветом показаны таски.
Вот так вот выглядит view для разработчика.
Итоги
Я не могу сказать, что мы идеально или оптимально используем Kanban в нашей повседневной работе. Мы всего лишь перешли из каменного века в эпоху промышленной революции, но еще не дошли до информационной революции.
Нам еще многому стоит научиться и придется со многим столкнуться. Спустя 5 месяцев мы только начали придерживаться принципов, которые были внедрены. А еще нам предстоят анализ и оптимизация.
В Kanban есть много разных отчетов и показателей, основываясь на которых можно делать выводы и улучшать процесс, но на это нужно время.
Спасибо, что дочитали до конца.
