О чем статья и зачем это вам
Хочу описать мой опыт про внедрению Kanban-системы для процессов разработки программных продуктов. Наш старый процесс разработки был Scrum, и я решил от него отказаться и сильно упростить весь процесс, чтобы от задачи контроля процесса (согласно установленным Scrum-правилами) перейти на парадигму Kanban. А именно, как предлагает его автор, сделать визуализацию процессов и фокусироваться на их совершенствовании.
Возможно, у Вас сейчас есть свой собственный процесс разработки ПО или вы "скрамитесь", и вы найдете мои советы интересными, что сподвигнет вас на изменения. Наши результаты внедрения Kanban-системы можно найти в самом конце статьи.
Мои идеи основаны на книгах про Lean в общем и 2-х книгам в частности:
Главное, что нужно помнить. Как говорит David Anderson, Канбан это не процесс разработки, не процесс управления проектами, и точно не методология. Это система для визуализации процессов и их оптимизации. И только.
С этим знанием и начнем.
Визуализация процессов
Для визуализации процессов мы используем 2 типа досок.
Есть физическая доска в комнате, где располагается основная часть команд. На обычной доске разрисованы столбцы и строки согласно текущему процессу. При появлении задачи мы пишем на бумажной карточке название задачи от руки. Как предлагает Майк Кон, чем сложнее прочесть название User story, тем выше вероятность что член команды вчитается в ее название полностью. На гибкие магниты наклеены аватарки членов команды - и карточки держатся и люди видны. У карточки отмечаются аналитик, который ее курирует, и разработчик(и), который ее реализует.
Если карточка долго висит в разработке (долгие задачи в аналитике не дают нам проблем, потому не отслеживаем) или на текущий момент над задачей никто не работает (разработчик из Ruby Team реализовал всю логику на клиенте и сервере, и Java Team должна доделать финансовый расчет), то это Blocker и на нее вешаем красный стикер.
Так как часть Java Team не в Москве, да и хочется иметь доступ к доске в любое время, в любом месте, есть электронная копия доски в Agile Jira. Вернее, Jira это мастер-источник данных, и физическая доска - это копия данных.
В Jira для удобства создано сразу несколько досок. Единые статусы позволяют легко их вести в Agile Jira:
- Есть "Product Backlog" Scrum-доска, где создаются новые задачи, и в рамках беклога происходит их приоритезация. Это удобно делать в рамках плоского списка. Как Product Owner я использую ее.
- Есть "Research" Kanban-доска, которая содержит беклог и статусы задачи по аналитике до статуса готовности к разработке. Она удобна в аналитике, так как видны самые приоритетные задачи из беклога, понятно что брать, согласно классу и владельцу задачи. Видно сколько задач находится в аналитике, и соответствует ли WIP. Использую ее.
- Есть "Develop" Kanban-доска, которая содержит статусы от готовности к разработке до закрытия задачи. Это часть общей Kanban-доски по разработке. Мне в работе она не нужна.
- Есть "Kanban all" Kanban-доска, которая является копией физической доски. Это все статусы задач без беклога. Так как беклог бесконечен, то он сильно влияет на отображение досок, и потому я его исключил. Для работы с ним есть "Research".
В Jira Blocker-задачи я отмечаю приоритетом "1+" для визуальности. Увидить такие задачи можно через Quick filter - "
(status changed from "Ready" to "Ask OP" before -4d) AND (status = "Ask PO" OR status = "In progress")".
В начале у нас были раздельные доски для Ruby Team и Java Team. Из-за проблем в их совместной работе мы объединили их в рамках одной доски. Зачем я разделил физическую доску на 2 части по-вертикали - чтобы визуально разделить их задачи, но оставить прозрачность их задач друг для друга.
В Jira это сделать нельзя потому я создаю для Java Team и Ruby Team разные типы задач и выделяю их различным цветом. Синие задачи для Java Team, Зеленые - для Ruby Team. Названия задач на карточках на физической доски так же различных цветов. Задача принадлежит Java Team если основной функционал должен быть разработан на их стороне. При этом очень часто там есть функционал для Ruby Team, который нужен чтобы полностью закрыть задачи. Это нормально - задачи не разбиваются на модули. Задача - это полезный Impact для Заказчика.
Устанавливаем Work-In-Progress
Чтобы убрать хаос в процессе и позволить людям уходить домой во время, ограничиваем Work-In-Progress по статусам задач. Jira не позволяет это сделать правильно, потому реализуем это на физической доске, и помним для электронной.
Есть 3 аналитика, потому ограничим до 3-х общее число задач на все статусы по аналитике. Я делаю аналитику по задачам когда аналитики перегружены по документам, потому вписываюсь в это ограничение.
Пусть "Ask Business" будет ограничен до 6 задач - странно если здесь будет большая очередь. Надо часто общаться с Бизнесом.
Мы фокусируемся на том, чтобы снизить Cycle time потому обязаны МАКСИМАЛЬНО ограничивать очередь перед нашим "ограничением" (см. Теорию ограничений). "Ограничение" в нашем процессе это разработка, потому фокусируемся на WIP для статуса Ready, то есть "готово к разработке". David Anderson предлагает WIP на очередь = (WIP на следующий статус + размер буфера). Для нас это будет 8 = 5 + 3. Но мы еще вернемся к ограничению на Ready.
В Ruby Team и Java Team у нас 6 разработчиков. Половина задач требует совместной работы обеих команд, потому ограничим WIP на оба статуса по разработке равным 5. Это заставит команды сильнее совместно взаимодействовать и общаться.
Ограничение на "Тестирование/Code Review" в 3 задачи не делает процесс тестирования ограничением, потому проблем здесь нет.
Беклог и "Done" бесконечны, потому измеряем Cycle Time всей Системы между ними.
Определяем политику процессов
Для примера опишу наши процессы разработки и политику на них. Нам важно определить "Definition of Done" для перехода между статусами, чтобы избежать жульничества и заставить наш WIP работать не только на благо команды, но и на благо менеджмента.
У нас есть беклог задач (в качестве задач я использую Job Story) на разработку, которые отсортированы по приоритету. В нем назначается ответственный за задачу аналитик. В нужный момент аналитик берет задачу в работу, и задача появляется на Kanban-доске.
Наши статусы по аналитике следующие:
- Скетчи. Обсуди с Product Owner задачи, синхронизируй с ним vision по задаче через скетчи на бумаге или доске. Договорись про объем задачи. Тут важно чтобы vision PO, у которого есть vision на все и вся, совпал с vision аналитика, который будет вести задачу до завершения.
- UI/UX. Если в задаче есть новый UI или это улучшение в части UX, то нарисуй UI-прототип формы для разработки. Обсуди с РО, провалидируй UI на use cases, реши как можно больше проблем, чтобы разработчикам было проще.
- Спеки. Мы стараемся писать много SpecByExample, и здесь необходимо это сделать. Спеки мы пишем на финансовые расчеты, сложные расчеты или мутную логику.
По завершению аналитики если мы не уверены с полной корректности наших результатов, мы передаем задачу на согласование с Бизнесом. Это согласование vision, так как в процессе аналитики мы нашли различные проблемы, и vision уже "поплыл". Или согласование спецификаций. Или согласование прототипов новых сложных форм, так как при визуализации задачи Бизнес может поменять vision и начать генерировать идеи.
Задачи, готовые к разработке, попадают в статус "Ready". Сложные задачи я отдельно проверяю, чтобы вернуть в аналитику при необходимости.
Когда разработчик берет задачу, она попадает в "Ask PO". Да, мы обсуждали эту задачу на WorkShop, но все равно, подойди в владельцу задачу, уточни скетчи/прототипы, уточни scope. Сейчас это самое дешевое что можно сделать - потом это будет дороже.
Статус "In progress" - это обычная разработка. Только здесь есть более формальный "Definition of Done" - разработчик должен получить в Skype OK от владельца задачи. Сейчас так как многие говорят OK просто так (и бывает что разработчик понял что "все хорошо", а аналитик говорил что это все замечания что я нашел - исправляй и посмотрим снова), заменили его на получение определенного Skype-смайлика.
Статус "Test/CodeReview" означает что наш QA Lead делает исследовательское тестирование по задаче, а команда ревьюит код перед слитием в ветку "develop".
Из командных встреч у нас остались следующие. Мы перешли с 2-week Sprints на 1-week releases, и теперь все основные встречи проходят 1 раз в неделю:
- Daily - вместо 3-х скрамовских вопросов смотрим на доску и обсуждаем задачи справа налево. Стало живее и быстрее. Смогли наконец-то сделать общей daily для Java и Ruby team. Впервые увидел как после daily разработчики группами обсуждают общие задачи.
- Planning - мы отменили его. Мы не оцениваем задачи - УФФ!
- Grooming - общаемся с аналитиками, обсуждаем задачи и проблемы, смотрим беклог.
- Workshop - обсуждаем задачи, которые готовы к разработке и которые грумятся в текущий момент. Цель - это обсудить задачи с командами в общем виде чтобы все понимали куда гребем.
- Demo - смотрим что готово на релиз и планируем его.
- Retro - встречаемся реже чем раз в неделю. Скорее On-demand
Измеряем и оптимизируем поток
Jira рисует хорошо кумулятивную диаграмму потока и считает Cycle time за разный период. Я раз в неделю проверяю как оно идет и в какую сторону есть изменения.
Отдельно от этого я считаю в Google Drive кол-во задач, которое мы релизим каждую неделю и время ожидания для статуса "Ready". Наше время цикла скачет от 5 до 7 дней. Из них 3-5 дня - это время ожидание в Ready. Отсюда можно вычислить нашу эффективность.
И это знание времени ожидания мотивирует на изменение. Если я смогу его уменьшить, то для текущего состояния процессов снижение времени цикла в 1 день может на 10-20% увеличить нашу эффективность.
Управляем через числа и переходим с PUSH на PULL
Но как можно уменьшить время ожидания?
К сожалению, я очень долго шел к понимаю принципа PULL для своих процессов. То есть как PULL работает в "Цели" у Голдрата или у Тойоты было понятно, но как мне его использовать у себя в процессе.
Оказалось, что просто. Каждое утро я проверяю свою очередь перед "ограничением", то есть статус "Ready". WIP равен 8. Пусть в Ready лежит 5 задач и в статусах по аналитике есть еще 2 задачи. Значит я могу стартовать аналитику по еще одной задаче, и если даже разработчики ничего нового не возьмут в работу, мы не превысим WIP если завершим всю аналитику. Какая 1 самая важная задача в беклоге, с учетом того, что она будет готова через 5-7 дней (зависит от текущего времени цикла) и потому попадет в ближайщим релиз. Это можно спросить у Бизнеса, но сейчас я как РО определяю приоритеты.
В результате разработка каждый день закрывает 1-2 задачи. Каждый день я могу стартовать аналитику по 1-2 задаче из беклога. В рамках такого предсказуемого и плавного потока мне уже не нужен большой буфер задач и я могу снизить WIP на "Ready" до (5+1) с буфером в 1 задачу по отношению к разработке.
Если я сделаю это, то
- Время ожидания упадет на ~ 1 день.
- Время цикла упадет на тот же 1 день. Мы будет "деливерить" почти за 4 дня!
- Эффективность процесса вырастет на 10-20%
К сожалению сейчас есть высокая загрузка аналитиков по написанию документов, что не позволяет груммить быстро и эффективно. Потому я жду изменений.
Устанавливаем приоритеты задач
David Anderson предлагает устанавливать классы сервисов по типам задач чтобы иметь по ним разный Cycle time. Но есть время цикла на доработки у нас 30 дней, но зато время цикла по багам - 3 дня, например.
У нас такой проблемы нет - я фокусируюсь на снижении общего Cycle time. Но я применил классы задач в другом виде. Кроме разделения задач по типу - Java team и Ruby team, я указываю их приоритеты:
- Приоритет +1 - это Blocker. Фокус на него - он может не попасть в релиз, а мы бы хотели.
- Приоритет 1 - это Backbone задача. Она самая важная чтобы закрывать основной функционал релиза.
- Приоритет 2 - это то, что Заказчик очень хочет видеть. Он уже говорил нам, что это ему нужно, но так же он понимает, что backbone-задачи важнее.
- Приоритет 3 - это beefup, что мы нашли в рамках обратной связи. Заказчик явно не говорил про это, но все понимают что это нужно в продукте.
- Приоритет 4 - это idea. Нам показалось, что с этой фичей будет лучше. Просто Заказчик не знает что так можно. Когда мы не успеваем в рамках нашего Road map и release map, то до этих задач мы не доходим. Но раньше случалось что писали новые фичи так быстро, что было время на эти идеи.
Визуализация этих приоритетов позволяет
- проще планировать эти задачи в беклоге
- видеть что у нас Ready забит beefup-ами, и из-за того что мы не успеваем сделать аналитику по backbone-задаче, разработчики возьмут их и в текущий релиз основные задачи уже не попадут.
Главное для меня это различать backbone и beefup. Это важно для следования по плану релизов.
Поддерживаем изменения
Для меня визуализация и цифры - лучший инструмент для поиска новых идеи по изменениям.
Для команды - пока не замечаю. Изменения все таки происходят больше после ретроспективы. Но я верю что визуализация влияет на их мышление и будет приводить к кайдзен культуре. Чтобы этому способствовать:
- я снизил нагрузку на них
- по ночам мы давно не работаем
- пробуем в пятницу тратить время на свои проекты, которые улучшают или продукт, или его процесс разработки.
Результаты внедрения
Какие результаты перехода на систему Kanban я могу указать:
- Мы стали больше поставлять. Если раньше делали по 8 задач за 2 недели, и казалось что это мало. То теперь мы делаем 8 задач за 1 неделю, и все равно кажется мало.
- Cycle time уменьшился с 43 дней (во времена Скрама) до 5 дней. А значит мы выкинули из процесса большой WASTE.
- Раньше мы фокусировались на velocity, который на самом деле ничего не означает. Теперь мы фокусируемся на Cycle time, и мне понятно почему он важен.
- Мы перестали оценивать. Все, нет оценок! Баста! И это в условиях заказной разработки. А это дает нам следующее
- Мы сильно снизили Coordination costs, которые тратили на планирование. Это был полный waste.
- Избавившись от планирования, стало возможным сократить релиз с 2-х недель до 1 недели. А частая поставка - это всегда хорошо. Быстрее можно сделать прототип сложной фичи, получить feedback и доделать ее в новом релизе.
- Мы перестали фокусироваться на оценках. Нет постоянных споров, что команда не может сделать этот функционал в рамках текущей оценки, так как иначе сорвет спринт.
- Теперь мы фокусируемся на взаимодействии участников команд между собой.
- Теперь мы фокусируемся по поставке, на том чтобы была ценность, impact. Чтобы все было офигенно!
- Теперь нет 2-х беклогов для Java team и Ruby team, и больше не нужно искуственно бить задачи.
- Появилась большая гибкость в улучшении процессов. Теперь и правда можно управлять не людьми, а процессом.
- Полагаю, что из-за уменьшения времени релизов, увеличилась общая Ценность поставок, но пока не могу это явно посчитать.
Что думаете?
