Как бережливое производство и prince2 ускорили разработку в 1.5 раз (лонгрид)

Всем привет! Не GPT единым, поэтому сегодня хочу поделиться своим опытом из 2021г. по применению подходов бережливого производства (lean production) в управлении командой разработки.

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

Проект, который приводится в пример – это заказная разработка внутри дочки одного зеленого банка, для самого зеленого банка :) - разрабатываемый продукт b2b сервис.

Команда разработки в большинстве своем аутстаф, состав команды был – 6 backend разработчиков, 3 qa (1/3 времени qa было 2), 3 frontend разработчика и 1 бизнес-аналитик.

Архитектурно – проект использовал тенанты микросервисов уже существующих в компании + новые, специфические для проекта, в качестве основного движка бизнес-процессов использовалась camunda.

Проект длился порядка 11 месяцев и состоял из 2-х крупных релизов. Конкретных фреймворков Agile не использовали, в основном базовые техники – спринт 2 недели, ретро, дейли. Я присоединился к команде на третьем месяце проекта в качестве руководителя команды разработки, за два месяца до первого релиза.

Основной посыл подхода бережливого производства заключается в обеспечении непрерывности потока создания ценности при максимальном сокращении издержек.

Если рассматривать разработку программного обеспечения как производственный процесс, то можно провести прямые аналогии с обычным производственным циклом:

Основная стоимость процесса разработки связана с фондом оплаты труда (т.е. трудочасы). Поэтому особенно важным становится устранение лишних временных затрат на всех этапах цепочки поставки ценности.

Выделим 8 основных видов потерь в бережливом производстве и их аналогии в разработке программного обеспечения:

Для работ с выделенными вариантами потерь применялись следующие принципы проектной методологии Prince2:

Так же применялся паттерн классического PDCA цикла.

Детальнее рассмотрим каждый вид потерь и меры предпринимаемые для их минимизации в проекте X (здесь и далее это кодовое название проекта :) ).

Это баги возникающие на этапе тестирования задачи

На проекте был выработан подход к тестированию с учетом специфики конкретного МС:

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

Стоит разделить на 2 типа багов:

Компенсирующие меры:

В нашем проекте из-за высокой скорости разработки и большой вовлеченности QA в процессы тестирования camunda из 3х QA удалось выделить на покрытие автотестами менее 1.0 QA (Здесь и далее цифры показывают степень загрузки на спринт в среднем).

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

Для полного покрытия автотестами, включая UI – для команды 3 FE+ 2.5 camunda + 3.5 BE необходима минимум 2 ручных QA, при среднем количестве 60 задач за спринт (без задач camunda) и 2 QA автоматизатора, с целевым снижением до 1 (в случае отсутствия массового расширения функционала МС или появления новых МС).

Как следствие, проводили ручное регрессионное тестирование при каждом релизе, по моим оценкам это занимало от 3 часов до 1-2 рабочих дней QA в зависимости от объемов релиза. Что дополнительно влияло на невозможность тестирования новых задач на время регрессионного тестирования сборки для релиза.

Это баги, когда использование продукта идет не совсем так как запланировано

Учет портрета ЦА при разработке, использующих сервис с учетом опыта эксплуатации реальными пользователями, предварительная оценка 1-2 спринта доработок связанных с корректировкой реализованного UX под ожидания пользования.

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

Разработка не устойчивой архитектуры кода или отсутствие планирования архитектуры при разработке.

Для планирования архитектуры необходимы следующие факторы:

При работе в жестких ресурсных ограничениях и при перегрузе команды разработки проработка архитектурных вопросов решения затруднена, что может привести к потерям, связанным с быстрым превращением кода в legacy и проведению рефакторинга в кратчайшие сроки

Для фиксации ответственных и более качественного планирования архитектуры на проекте были использованы принципы уровней управления из Prince2 и выделены следующие роли и зоны ответственности:

Архитектор сервиса

В разрезе архитектуры отвечает за:

Тимлид команды по МС

В разрезе архитектуры отвечает за:

Благодаря объемному бэклогу 2-го релиза было понятно целевое состояние на момент проектирования основных механик 2-го релиза. В 2-м релизе все архитектурное планирование с 6 месяца проекта мы осуществляли в рамках команды, без привлечения архитектора компании.

Выделение уровня управления и ответственных позволило практически избежать архитектурных потерь в 2-м релизе, за исключением переработок механик, разработанных в режиме перегрузки команды в конце 1-го релиза (около 1 спринта работы uni-coop) без аффекта на общую производительность и сроки. Накопленный техдолг относится к механикам 1-го релиза.

Возникает если производственных мощностей команды проекта (речь идет о качественно- количественных показателях) больше, чем есть готовых задач для команды разработки. Есть 2 варианта планирования мощности команды:

Лучше всего будет комбинирование обоих вариантов, с учетом стоимости и рисков, в том числе временных, связанных с изменением объема команды(онбординг, адаптация и т.д.) или критичности выполнения тех или иных работ в заданные сроки.

На проекте с данным видом потерь почти не сталкивались. На это повлияли следующие факторы:

Один из наиболее частых и объемных факторов временных потерь на проектах разработки. К этим потерям можно отнести все время, которое разработчик работает, но непосредственно не решает задачи

Ожидания можно разделить на следующие типы:

Рассмотрим подробнее каждый тип

Ожидание ответов на вопросы по задаче сильно зависит от ряда факторов:·

Распределение зон ответственности – крайне важный параметр, если каждому члену команды понятно к кому обращаться по какому вопросу это сокращает потери на лишних коммуникациях - как и для человека с запросом, так и для всех остальных вовлеченных в коммуникации

В нашем проекте с разделением на уровни управления и команды по МС было максимально прозрачное распределение зон ответственности, что приводило к минимуму «лишних» коммуникаций по поиску крайнего.

До внедрения распределенной зоны ответственности разработчики теряли в среднем от 30 минут в день на «лишние» коммуникации, что в разрезе команды высвободило на 10 человек 5 трудочасов в день и 50 трудочасов в спринт в сравнении положением дел в команде на момент моего прихода в команду (3й месяц работ по проекту)

Скорость реакции отвечающих– ещё один важный параметр, крайне сильно влияет на все коммуникации (согласование, поиск ответственного) и зависит от налаженности каналов коммуникаций. На то время пока идет согласование того или иного вопроса (циклов вопросов- ответов) – выполнение задачи ставится на паузу. Поэтому крайне важно чтобы команда была коммуникативная и проактивная

В нашем проекте мы добились крайне высокой скорости реакции за счет следующих моментов:

Как показывало ретро – все члены команды отмечали крайне высокую скорость коммуникаций и вовлеченности команды (особенно те, кто недавно присоединился к команде, их оценки обычно выше оценок ребят, уже состоящих в команде, под высокими оценками подразумевается «10» из 10 балов термометра эмоционального состояния в первых 2 спринта)

Немного цифр: Средняя скорость ответа PM до 4го месяца проекта до 1 часа - с 5го 2-5 минут

Средняя скорость ответа членов команды – от 1 до 15 минут, в зависимости от плотности проработки вопросов

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

На нашем проекте из-за отсутствия роли PO от заказчика и отсутствие архитектора (с 6го месяца проекта) в режиме плотного контакта с командой привело к принятию локальных продуктовых и архитектурных решений на уровне команды. Что в совокупности с глубоким погружением бизнес- аналитика в бизнес-логику разрабатываемого функционала и разработку дизайна интерфейсов и уровнями управления привело к значительному ускорению решения вопросов, выходящих за рамки уровня принятия решения разработчиками.

Для внутренних вопросов используем такие механики:

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

В проекте X:

За коммуникации в проекте Х отвечал PM, в том числе за горизонтальные коммуникации между членами команды. С ростом уровня зрелости и проактивности команды, члены команды перехватили на себя инициативу по коммуникациям у PM.

Тимлидеры по командам – управляют коммуникациями внутри команды. Так же QA вносили существенный вклад в скорость прохождения задач с этапов тестирования до этапов готовности, приходя к исполнителям с конкретными местами ошибок и рекомендациями по их исправлениям, с последующими напоминаниями о необходимости исправлений (в случае необходимости)

SLA по каждому каналу коммуникаций не формализованы и учитываются на уровне эмпирической оценки PM.

Следующим вариантом потерь при ожидании является ожидание задач.Ключевым критерием здесь является скорость работы продуктовой\бизнес-команды по проекту\продукту.

Скорость наполнения бэклога и поддержания его в актуальном состоянии должна быть несколько выше скорости реализации задач командой разработки, для достижениия эффекта потока поставки ценности. При этом важно не забывать, что задачи в бэклоге ради задач не нужны, у всех задач попадающих в бэклог должно быть бизнес-ценность(выгода) предварительно оцененная(хотя бы эмпирически) и стоимость закрытия задач не должна быть выше бизнес-ценности от самой задачи, поэтому продуктовая команда и команда разработки должны быть хорошо сбалансированы по емкости, чтобы поставлять на рынок(в том числе внутренний J ) ту ценность которая необходима, с достаточной скоростью и в достаточном объеме, не добавляя просадок по себестоимости поставляемой ценности.

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

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

Правила, позволяющие повысить эффективности встреч:

И немного про встречи в цифрах – 1 встреча на 10 участников длительностью в 1 час, при проведении ради встречи – 10 трудочасов потраченных не на результат, можно ещё добавить в расчет недополученную прибыль от того что сотрудники эти 10 трудочасов не занимались другими задачами, стоимость переключения на встречу и после встречи обратно на задачи, размывание фокуса и цифра по трудочасам может вырасти до 20, что слишком большие потери для команды в рыночных условиях.

Применяя правила, перечисленные выше, удалось сократить количество встреч внутри команды до 0-2 в день (на этапах реализации) и повысить скорость решения вопросов, без потери фокуса и уровня синхронизации внутри команды

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

Ритуалы команды на проекте:

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

Ретро – многие процессы улучшили в результате обратной связи на ретро, для сокращенных спринтов (6-8 дней) смысла проводить ретро скорее всего нет

Демо – несмотря на дорогую стоимость ритуала (почти пол дня разработчиков на сборки демонстрационных веток, занимание uat на время подготовки и показа = пауза по тестированию задач и сопровождение демо 1-м QA) оцениваю ритуал как положительный. Именно с появлением демо мы перешли на полноценное планирование спринтов, у команды стало лучше с фокусом и приоритетами, стал понятен скоуп спринта, появилась дополнительная точка синхронизации команды разработки и бизнес-заказчика.

Применяя правила эффективности коммуникаций оптимизировали затраты на ритуалы:

Что для команды в 10 разработчиков высвободило 10 разработчиков * 10 дейли в спринт и 0.45 часа(27 минут) – 45 трудочасов в спринт, только на дейли и ещё дополнительно 5 трудочасов на ретро. Потери, сэкономленные на внутренних встречах, не рассчитывали.

Все вышеперечисленные меры дали следующее улучшение динамики продвижения:

Статистка собрана на основе данных YouTrack

Безусловно просто по количеству задач измерять производительность нельзя, т.к. задачи могут быть разные. Но в текущий момент в команде не используется полноценная оценка задач командой с использованием story point поэтому это единственный доступный инструментарий сравнения, который на цифрах показывает степень ускорения, при этом визуально случайно выбранных 10 задач из сравниваемых промежутков были сопоставимы по объему и сложности

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

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

Здесь необходимо максимально реализовывать софт- скилы менеджмента – адаптировать процессы под исполнителей, для максимального синергетического эффекта.

Выделим основные моменты требующие адаптации под разработчиков:

Рассмотрим на примерах проекта Х каждый из пунктов:

Построение связок(мини-команд) в проекте – внедрение уровней управления назревало относительно долго, но было внедрено достаточно быстро в результате просадок связки ребят работавших с основным микросервисом. При его рефакторинге потребовались дополнительные усилия по микроменеджменту и было принято решение выделить локального лидера административным решением (для команды этого МС) для camunda и front лидеры были получены уже органически, но после переключения на новую схему управления – инцидентов больше не было и просадки производительности прекратились. Спустя несколько спринтов ребята с этого микросервиса притерлись и стали отличной связкой, где каждый из 3-х разработчиков компенсирует слабые стороны других и ребята стали именно командой.

По фронту после нескольких спринтов перехода на новую схему удалось полностью передать управление FE, вплоть до нарезания задач для FE на лида фронтов.

По camunda – ребята изначально пришли командой и в целом командой и работали, но отлично интегрировались в общекомандный ритм и атмосферу.

Использование сильных сторон сотрудников - можно разделить на 2 подтипа:

Подбор задач под психотип и навыки члена команды:

Развитие членов команды – здесь примеров будет больше:

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

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

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

На проекте такой подход позволил практически полностью избежать потерь ресурсов PM на микро-менеджмент, переложив эту опцию на самих членов команды и иногда (при необходимости) лидеров по командам, что высвободило дополнительные ресурсы на продуктивные коммуникации и позволило привлекать при необходимости к сверхурочным работам на добровольной основе (иногда даже без дополнительной оплаты J причем по инициативе самих ребят).

Управлять фокусом и приоритетами команды – очень важная составляющая, команда разработки должна не закрывать задачи, а генерировать ценность необходимую бизнесу, в тот момент, когда это необходимо бизнесу. Одна из основных задач PM в самоорганизованной команде это именно поддержка фокуса и приоритетов, для того чтобы создавался поток поставки ценности.

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

Результаты компенсирующих мер по управлению командой:

В последние 5 спринтов команды – удалось перейти на модель самоуправляемой команды, которая нуждалась в постановке бизнес-задач и поддержке фокусов и приоритетов и оптимальной конфигурацией

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

Для поддержания синхронизации нужны удобные и понятные каналы коммуникаций и периодичность встреч. В зависимости от уровня управления можно варьировать периодичность встреч. Для оперативного управления оптимальным является 1 раз в день или чаще (при необходимости по конкретным горящим вопросам). Чем выше уровень управления, тем реже есть необходимости во встречах. т.к. больше масштаб задач и тем менее они динамические.

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

Хорошей практикой для команд разработки является проектирование и согласование контрактов ДО разработки кода, обеспечивающего поддержку контрактов.

Без синхронизации – высокий риск реализации не актуальных задач или реализации в виде, не представляющем нужной ценности, снижение скорости поставки ценности.

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

Высокий уровень синхронизации поддерживался :

Как анти-паттерн в проекте могу привести решение задач, связанных с информационной безопасностью(в проекте было много персональных данных) – максимально НЕ прозрачная и не эффективная история, которая так и не получила единственное ответственное лицо и качественных коммуникаций, в результате чего за статусом задач по КБ, в том числе по инфраструктурным требованиям за статусами приходят к PM команды разработки, причем первые задачи по КБ заводились несколько месяцев назад.

Результаты компенсирующих мер:

Практически полное отсутствие потерь из-за рассинхронизации внутри команды в последние 5 спринтов.

За последние 5 спринтов сэкономили не менее 1 спринта на распараллеливании работ и не менее половины спринта сэкономили на ускорении тестирования по готовым контрактам и благодаря наличию swagger на каждый метод всех BE мс.

Большой объем релизов в prod ведет к большому объему зависимостей между различными МС, обновления по которым планируются к релизу. Большое количество зависимостей и большой объем изменений неизбежно ведет к увеличению длительности и сложности тестирования, в том числе регрессионного, и увеличивает шансы разного рода багов.

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

В проекте Х не было фиксированного релизного цикла, часть функциональности поставлялась на prod по мере готовности. Был 1 большой релиз, когда размещали на Prod большое количество функционала, потери на тестировании и стабилизации релизной сборки были порядка 2-х дней регресионного тестирования. Несколько багов было предотвращено благодаря покрытию автотестами backend сервисов.

В проекте следующая цепочка поставки на prod – разработка - >UAT контур + тесты- >мердж в основную ветку(master) кода -> установка на UAT стабильных версий мастер-ветки, тестирование сборки -> размещение на prod

Результаты компенсирующих мер:

Особых компенсационных мер в проекте не применялось. Потери на релизы (недоступность тестового стенда и QA для тестирования) составляют от 4-х часов при умеренном релизе (например, 1 новый БП) до 2-3 дней при подготовке значительного релиза.

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

Хорошей практикой является выделение разработчику определенной зоны ответственности, чтобы большинство новых задач были из одной предметной области и желательно касались одного микросервиса. Порционная выдача разработчику задач, чтобы в его списке что брать в работу было не больше 4-5 задач с понятными приоритетами, позволяет поддерживать фокус у разработчика. При накоплении на доске задач большого количества вероятность что разработчик будет сфокусирован и делать самое важное и нужное сильно снижается.

В проекте Х мы выделяли ответственных за определенные МС, которые занимались вопросами связанными именно этими МС и распределяли похожие задачи внутри команды МС, что позволило поддерживать фокус.

Результаты компенсирующих мер:

На протяжении рядя последних ретро команда отмечала, как позитивный момент что удается поддерживать фокус (в том числе, благодаря мерам, перечисленным в пунктах выше), что позволило минимизировать потери на переключениях между задачами и ускорить разработку

Достаточно сложно формализуемый, но существенный вид потерь. Означает слишком сложное и дорогое (по срокам\стоимости) решение задачи исходя из потребностей бизнеса сейчас и в обозримом будущем. Минимизировать подобные потери можно погружением команды в потребности бизнеса относительно реализуемой ценности, как и зачем планируется её использовать и о планах на ближайшее будущее, чтобы текущая реализация закладывала перспективные изменения, но не более. Так же крайне важна работа PM в этом направлении для поддержания фокуса и контроля за объемом реализации, при необходимости проведения разъяснений

В проекте Х мы сталкивались с подобными проблемами, решали путем менторинга, объяснений что мы делаем и зачем, что такое продуктовая разработка и mvp. Ситуацию облегчали:

Результаты компенсирующих мер:

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

В проекте Х удалось минимизировать многие потери, только прямых потерь в трудочасах минимизировано более чем на 100 часов в спринт на команду. Это удалось благодаря:

Как следствие за 11 месяцев существования команды производительность повысилась в 1.5-1.7 раза в количественном выражении закрываемых за спринт задач. При этом:

На этом все, спасибо за внимание, надеюсь материал будет полезен) Пишите свое мнение в комментариях и используете ли вы prince2 или lean подходы в своей работе