Обычная практика при работе с госами - это долгосрочное планирование, тщательное проектирование, разработка по детальным спецификациям, тестирование и релиз раз в три-четыре месяца. Вроде все логично и понятно но, по моему опыту, в современном быстро меняющемся мире работает далеко не идеально. Многие технологические компании (Amazon, Facebook, Netflix и др.) уже отказались от такого каскадного подхода: формируют гипотезы, проводят множество маленьких экспериментов для их быстрой апробации в бою. Думаете, чтобы разработать ракету нужен детальный техпроект, план и далее сборка по чертежам? Тогда вы сильно удивитесь, если прочитаете, как это делается в SpaceX. С таким же недоумением со стороны коллег я сталкиваюсь, когда говорю, что мои команды на госпроектах делают каждый день релизы, организуют частые показы заказчику или пользователям. А еще мы не пишем детальных спецификаций и постоянно развиваем инженерные практики. Почему такой подход имеет место быть и приводит к хорошим результатам, расскажу на примере проекта по созданию ГИС Открытый контроль.
Как же вы планируете без диаграмм Ганта? Почему ваши разработчики не оценивают задачи? Зачем вы делаете частые релизы и частые показы? Что делаете, если прилетела срочная задача от заказчика? Какие инженерные практики вам пришлось внедрить, чтобы делать релизы каждый день? Ответы на эти вопросы, а также то, почему мы отказались от Scrum вы найдете в статье.
Мои команды занимаются разработкой ПО под заказ для государственных структур. Такие проекты имеют свою специфику. Как правило, их отличает сложная предметная область (регулируется десятками нормативно-правовых актов), большое количество пользователей по всей России и зачастую принципиально разные взгляды заинтересованных лиц на конечный результат. При этом технологически проекты непростые. Системы, о которых мы говорим, функционируют под высокой нагрузкой 24x7x365, обрабатывают сотни терабайт структурированной и неструктурированной информации, персональные данные, а еще должны быть устойчивыми к хакерским атакам.
На первый взгляд, самый логичный ответ на эти сложности - следование принципам каскадной разработки. А это анализ требований конкурсной документации (КД), детальная проработка технического задания (ТЗ), спецификации несколько месяцев, далее проектировка системы, разработка, тесты. Итог - сдача и внедрение в эксплуатацию. Подход логичен и известен со знаменитой статьи Винстона Ройса. Только почему-то очень часто через пару месяцев вся команда уже работает в режиме цейтнота: приходится жонглировать сотнями задач одновременно и выдерживать сроки ценой героизма и постоянных переработок. Что же тогда не так?
Думаю, основная причина - невозможность принятия многих решений без апробации в условиях, приближенных к реальной эксплуатации (какие функции будут пользоваться популярностью; какой из вариантов организации UI окажется удобнее; как поведет себя аппаратная или программная платформа при реальной нагрузке; не вскроется ли какой-нибудь особый сценарий, не вписывающийся в предлагаемое решение; будет ли работать система, с которой мы интегрируемся, так, как мы предполагаем и т.д.). Другая причина - изменение внешних обстоятельств, к примеру, приоритетов заказчика или условий труда (кто знал, что наступит пандемия?). Чем релизный цикл длиннее, тем больше вероятность ошибок и тем трудозатратнее и дороже вносить изменения. Если в конце цикла обнаруживается, что мы ошиблись где-то на этапе проектирования, то это может привести к большим переделкам на которые уже, как правило, не хватает времени.
В итоге гайки закручиваются сильнее - пишутся и согласовываются с заказчиком еще более детальные спецификации, готовятся планы, внедряются регламенты, усложняющие заказчику внесение изменений, а для задач вводится дополнительное согласование. Уходит еще больше времени на "проектирование" , но это, как правило, не помогает, так как не решается корневая проблема. Качество решений не становится лучше, а времени остается все меньше. Да и что делать с внешними непредвиденными обстоятельствами?
Мы пошли другим путем, сделав ставку на производственную систему, позволяющую выпускать доработки очень маленькими частями. Решаются обе упомянутые проблемы: мы можем часто проводить эксперименты для апробации наших решений и снизить для себя стоимость изменений. К счастью, нам есть на чей опыт опираться. Многие ведущие технологические компании (Amazon, Facebook, Netflix и др.) работают по этой схеме, имеется много книг, курсов и других материалов ([УскоряйсяКим2018, РукDevOpsХамбл2018, KanbanGuide2018, FlowReinertsen2009] и др.), разработан необходимый инструментарий и технологии (например, мы используем GitLab, Ansible, Docker, Spring Boot, ELK, Prometheus, Graphana, Jaeger и т.д.).
Наша производственная система основывается на идеях Канбан-метода, применяется философия и инженерные практики DevOps. Сегодня мы пришли к тому, что при тех же (или меньших) накладных расходах, можем выпускать сколь угодно мелкие доработки (а значит, проводить мелкие эксперименты и оперативно реагировать, вплоть до того, чтобы поменять цвет кнопки), выпускать релизы каждый день и регулярно организовывать показы заказчику или пользователям. Ниже я расскажу, как у нас это работает на примере проекта по созданию ГИС Открытый контроль.
По этой же теме я недавно выступал на конференции DevOps Pro Moscow 2021. Запись доклада можно посмотреть здесь.
О проекте
В России достаточно много разных контролирующих органов. И каждый предъявляет предпринимателю список требований в зависимости от его вида деятельности.
Рис. 1 Реестр обязательных требований
(пощупать самому)
Почти все можно найти в федеральных законах и других нормативно-правовых актах, однако разобраться в них довольно сложно. Поэтому у правительства Москвы появилась идея сделать сервис, в котором все требования сведены в один актуальный реестр. Чтобы можно было сразу получить доступ ко всем необходимым правовым актам и информационным материалам, смоделировать, какие требования контрольные органы будут предъявлять бизнесу, а еще взаимодействовать с ними онлайн: писать обращения, задавать вопросы, записываться на прием и т.д.
В начале 2020 года мы начали работать над созданием сервиса «ГИС Открытый контроль». Контракт подразумевал разработку большой функциональности примерно за один год в три этапа. В настоящее время система успешно построена и открыта для общего доступа.
Метрики
Для контроля нашей работы мы ориентировались на указанные в таблице 1 метрики. Многие авторы считают [Vacanti2015, УскоряйсяКим2018, KanbanGuide2018], что данные метрики хорошо коррелируют с высокой эффективностью, прогнозируемостью и продуктивностью команд разработки ПО.
Табл.1. Основные метрики и их типичные значения на госпроектах (по моему опыту)
Метрика | Обычно на госпроектах | Значение |
Частота релизов (шт/в мес) | <1 | Больше - лучше |
Частота показов (шт/в мес) | <1 | Больше - лучше |
Время производства (дней, медиана) | >40 | Меньше - лучше |
Метрики направлены на оценку нашей способности быстро проводить эксперименты для апробации наших решений и получения обратной связи. По моему опыту, если мы прибегаем к каскадному подходу при организации работы, то релизы выпускаются раз в два-три месяца (первая и вторая строки таблицы), а время производства значительно превосходит 40 дней (третья строка). Производственная система, как правило, не приспособлена для частых показов.
Когда же мы изменили сам подход к работе (увеличили частоту релизов) было важно не увеличить издержки производства. Иначе бы мы превратились в очень эффективную, но совершенно экономически не конкурентоспособную команду. Поэтому мы всегда держим и этот показатель в уме и стараемся его оценивать хотя бы субъективно.
Ниже я расскажу, какие основные практики Канбан-метода и DevOps мы внедрили и как это повлияло на улучшение отслеживаемых метрик.
Структура производственной системы
На начальном этапе мы определили основные рабочие элементы - «Новая фича», «Улучшение», «Дефект», «Техулучшение», «Инфраструктурная задача». Потом добавились дополнительные - «Интеграционная задача», «Документация». Задачи стали формулировать в терминах заказчика так, чтобы из них можно было составить описание релиза.
Для всех типов рабочих элементов определили основные этапы и свели их к единой последовательности. Этапы немного уточнялись по ходу проекта. В итоге наш процесс выглядит так: «ToDo», «В анализе», «Готово к разработке», «В разработке», «Готово к тестированию», «В тестировании», «Готово к проду», «Готово к релизу», «Выполнено». Договорились считать работу выполненной, когда она продемонстрирована заказчику и выпущена в опытно-промышленную эксплуатацию.
Названия всех этапов говорят сами за себя, кроме двух, которые связаны с поставкой. Мы работаем так, чтобы наша основная ветка Git (Master/Trunk) была в любой момент времени готова к выпуску. При этом разработчики работают частично прямо в мастере, используя Trunk Based Development (TBD), а частично - в короткоживущей feature-ветке. В последнем случае тестирование задачи выполняется на специальном review-стенде (т.е. рабочем окружении, позволяющем «поиграться» с отдельной задачей). Задача переходит на этап «Готово к проду», когда она уже полностью протестирована, но еще не смержена в мастер. Статус «Готово к релизу» означает, что задача уже протестирована, смержена в мастер и будет выпущена в продуктив со следующим релизом.
При этом TBD/CI у нас появился эволюционно, когда мы заметили, что стали часто возникать конфликты при параллельной работе над близкими задачами. Например, на статусном митинге выясняется, что два разработчика одновременно внесли изменения в один и тот же фрагмент кода, и теперь им нужно эти изменения смержить. Или выясняется, что оба работают в ветке: один разработал то, что необходимо второму, и второй хочет подмержить часть изменений в свою ветку. На следующий день оказывается, что еще и третий разработчик нуждается в этих изменениях, и мержит их в третью ветку. В итоге уже первому разработчику нужны изменения второго или третьего - круг замкнулся. Все это приводит к существенному увеличению координационных издержек. Гораздо проще, если бы все сразу работали только с мастером. Конечно, TBD/CI требует определенных навыков и использования фича флагов, но, на мой взгляд, это окупается.
У нас реализована вытягивающая система. Например, как разработчик сделал задачу, он ее передвигает на этап «готово к тестированию», а сам может взять другую задачу из очереди «готово к разработке». Таким образом, он сам (а не менеджер-кооординатор) определяет свою загрузку. Снижается многозадачность, улучшается производительность.
Рис. 2. Визуальная доска позволяет в любой момент времени видеть статус работ. Это в том числе минимизирует управленческие расходы.
Визуальную Канбан-доску мы построили в JIRA. И в ходе проекта неоднократно убеждались, насколько практика визуализации помогает во многих аспектах работы. Например, визуальная доска показывает актуальный статус по проекту в любой момент. Посмотрев на доску, можно заметить «застрявшие» задачи, упущения или несоответствия. Это улучшает синхронизацию членов команды и сокращает управленческие и координационные расходы.
Формулировка и уменьшение размера задач
Мы используем два уровня задач - «эпики» для задач уровня заказчика и «истории» для задач, которыми оперирует производственная команда. Подзадачи мы используем только на этапе разработки для визуализации, если несколько разработчиков работают над одной задачей: кто-то делает frontend, а кто-то backend. При этом истории мы формулируем так, чтобы они были как можно меньше, но понятны заказчику и приносили ему какую-то ценность.
Фокус на ценности для заказчика важен, т.к. это позволяет приоритезировать задачи естественным образом и легко понимать статус, что реализовано, а что нет. Такая функциональность, как возможность задать вопрос в КНО представителям бизнеса и получить ответ, у нас распалась на 28 историй, например: «ЛК Бизнеса. Просмотр списка тем вопросов», «ЛК Бизнеса. Просмотр переписки по теме», «ЛК Бизнеса. Отображение плашки Превышен срок рассмотрения» и т.д. А вот так формулировать не надо: «Запилить backend для вопросов в КНО», «Запилить frontend ЛК Бизнеса для вопросов в КНО» и т.п.
Что дает фокус на уменьшении размера задач? Во-первых, возможность быстро делать MVP и получать обратную связь. У нас в работе, как правило, одновременно несколько «эпиков». Каждый раз, когда мы берем новые «истории» в работу, то из всех «эпиков» выбираем только самые приоритетные. В итоге ресурс команды используется максимально эффективно, а заказчик получает в первую очередь самую важную функциональность. Во-вторых, это позволяет выравнивать загрузку команды. У нас почти не бывает такого, чтобы одна из ролей (аналитики, разработчики, тестировщики, инфраструктура) была перегружена. Все загружены более менее равномерно. В-третьих, это позволяет оценивать этапы работ. В-четвертых, сократить среднее время производства. В-пятых, обеспечивает частый выпуск функциональности в продуктив (или демонстрируем заказчику), а это дает большой психологический эффект. Команде приятно осознавать, что работа каждого из них заметна, а, возможно, уже приносит пользу людям. Подобные положительные эффекты от сокращения размера «историй» можно перечислять очень долго (рекомендую обратиться к главе №5 замечательной книги Дональда Рейнертсена).
Что делать если “прилетает” срочная задача от заказчика
Из-за того, что мы фокусируемся на уменьшении размера задач, то среднее время производства задачи уменьшается (у нас медиана - 13 дней). Поэтому прилагать дополнительные усилия для обработки срочной задачи часто не нужно, т.к. она и так будет выпущена достаточно быстро. Если требуется сделать какую-то доработку еще быстрее, то берем ее в производство вне очереди, приостанавливая некоторые текущие работы если это нужно. Интересно отметить, что тот факт, что время производства у нас мало, привел к тому, что прямо срочных задач у нас практически не бывает. Нам даже не пришлось вводить какой-то особый класс обслуживания или регламент для работы со срочными задачами.
Ограничение объемов незавершенной работы
Для того, чтобы обеспечить прогнозируемость, мы обозначили точку принятия обязательств (далее - ТПО) и ограничили систему с помощью WiP-лимитов (перевод с англ. Work-In-Progress - объем незавершенной работы). Это позволило начать собирать критичные метрики по производству: время производства (англ. термин Lead Time или LT), производительность (количество сделанных задач за период времени), отслеживать количество задач в работе. Метрики позволяют отслеживать тренды и проводить улучшения, основываясь на измерениях, а не на интуиции (см. обоснование).
Рис. 3 Основные метрики. Позволяют отслеживать тренды и проводить улучшения, основываясь на измерениях, а не на интуиции
Конечно, WiP-лимиты - это одна из ключевых практик, без которой невозможно построить прогнозируемый сервис. Надо сказать, что это одна из самых трудных практик для внедрения. Тем, кто долго работал в рамках «традиционного» менеджмента, сложно понять, почему свободный разработчик не может взять новую задачу. Что он будет делать?
Обычно есть два аспекта при внедрении WiP-лимитов.
Как правило, менеджеры считают, что нужно заставить команду взять задачу, даже если у нее нет достаточных ресурсов. В реальном мире такой проблемы нет, так как обычно есть физические ограничения. В коробку не поместится больше деталей, чем позволяют ее размеры, на автомагистраль не заедет больше автомобилей, чем она может вместить. В умственном труде такого ограничения нет, и менеджер может дать работнику столько задач, сколько захочет (некоторые считают, что это ограничено тем на какое количество курсов по убеждению и агрессивному ведению переговоров он сходил). Но надо отдавать себе отчет, что если производственная система не ограничена, то она не будет прогнозируема (и вообще см. закон впихивания).
Второй аспект - сами сотрудники часто не осознают, что нет никакого смысла делать задачи, если они попросту не получат логическое продолжение. Например, если разработка может переварить только 10 задач/неделю, то нет смысла делать постановок на 20 задач/неделю. Очевидно, что очередь перед разработкой будет с каждой неделей только накапливаться и никогда не будет разобрана.
Мы подстраиваем WiP-лимиты под текущие условия. В августе и декабре отпускали сотрудников в отпуск, а, значит, уменьшали WiP-лимиты. В мае-июне расширяли команду - увеличивали WiP-лимиты. Кроме того, руководитель производства может их регулировать. Если он замечает на доске задачи, находящиеся долгое время в одном статусе (например, больше недели), то распознает это как сигнал, что стоит уменьшить WiP-лимит в этой колонке. Если WiP-лимит не сократить, то “зависшие” задачи начинают ухудшать работу всей команды: тратится время на их постоянное обсуждение на статусных митингах, с течением времени эти задачи могут становиться неактуальными и надо тратить силы на их переделку, увеличивается время производства, а, значит, снижается прогнозируемость и т.д.
Поток работ
Один из главных показателей любой производственной системы - это количество ценности, которая она выдает за единицу времени. Поэтому часто менеджеры настаивают на максимальной загрузке людей. Поначалу это покажется конструктивным, однако увеличение загрузки людей после некоторого предела ведет только к ухудшению результата.
Давайте рассмотрим простой пример. Вернемся к сравнению с автомагистралью. Пропускная способность дороги существенным образом зависит от плотности и скорости трафика. На самом деле эти показатели связаны между собой, т.к. обычно при увеличении плотности падает скорость и наоборот. График пропускной способности автодороги в зависимости от изменения скорости/плотности имеет форму параболы. Таким образом, при некотором значении плотности (скорости) дорога будет иметь максимальную пропускную способность, а по краям - пропускная способность будет минимальной.
Рис. 4. График изменения пропускной способности автомагистрали типичным американским утром утром
(Источник)
На рисунке приведены графики изменения скорости потока автомобилей и пропускной способности автомагистрали. Начиная с шести утра скорость потока максимальная, а пропускная способность - минимальная (очевидно, что и плотность при этом минимальная). Затем с течением времени на автомагистраль выезжает все больше автомобилей, скорость начинает уменьшаться, а пропускная способность растет. Примерно через 75 минут наблюдений пропускная способность достигает своего пика и дальше начинает резко падать. Для того, чтобы автомагистраль функционировала на максимальном уровне пропускной способности, используются специальные светофоры, которые ограничивают поток въезжающих на автомагистраль автомобилей (если не верите, то можете сами поиграться здесь).
Мы также заинтересованы в том, чтобы максимизировать поток ценности нашего производственного сервиса. Поэтому используем похожие подходы для этого. Один из главных приемов - это использование вытягивающей системы. Проще говоря, задачи берутся в работу тогда, когда у команды для этого есть ресурсы. Кто же тогда определяет степень загрузки? Все просто: она определяется состоянием WiP-лимитов в соответствующих статусах. Например, если количество задач в статусе «в анализе» >= WiP-лимиту для этого статуса, то мы не берем новые задачи (с некоторым исключением для багов). Также мы всегда стараемся выделять 10-15% ресурса команды на технические улучшения. Это время служит некоторым буфером, который позволяет выравнивать загрузку команды, т.к. в случае возникновения дефекта ими можно пожертвовать на какое-то время для того, чтобы решить срочную проблему. На статусных митингах мы обсуждаем не текущую загрузку команды, а задачи. Что еще предпринять, чтобы задача была выполнена? Уменьшение размера задач (т.е. тот факт, что производственная команда работает с «историями», а не с «эпиками») также направлено на улучшение потока, т.к. не позволяет какому-то одному «эпику» заблокировать надолго ресурсы команды в ущерб другим «эпикам».
Естественно, если возникает авария или поломка на трассе, то это приводит к резкому уменьшению пропускной способности, а самое главное к ухудшению потока из-за перестроений автомобилей для объезда опасного участка. В проектах аналогом аварий/поломок являются так называемые блокеры, т.е. задачи, над которыми работа не может быть продолжена по какой-либо причине (сломалась инфраструктура, не сделана задача, от которой есть зависимость и т.д). Для того, чтобы минимизировать возникновение блокеров и снизить их влияние, полезны практики TBD/CI, фича-флаги, инфраструктура-как-код, автоматизированные тесты и др. Ну и в общем, главная задача менеджера команды - это смотреть за потоком и стараться разрешать все проблемы как можно скорее, если вдруг он начинает тормозить по какой-то причине. Цель - сделать все возможное и невозможное, чтобы работа никогда не блокировалась.
Почему мы не используем Scrum
Многие ИТ-команды используют Scrum. Мы же считаем, что Scrum полон излишеств. Если мы умеем делать задачи параллельно, не связывать старт работ с поставкой, то нам не требуются итерации и связанные с ними процедуры планирования и оценки. На это еще обращал внимание Д. Андерсен в своей статье в 2014 году. По его мнению, если мы хотим улучшить нашу гибкость, то нужно уменьшить длину итераций. Да, это влечет необходимость в еще более детальной проработке задач и планировании спринтов. Д. Андерсен отвечает на это, что лучше инвестировать в практики, позволяющие отделить принятие обязательств от поставки, и таким образом отказаться от более детальной оценки и планирования. Хочу добавить, что в реальной жизни как бы детально и качественно мы не планировали, все равно возникают проблемы и накладки. Наша производственная система становится хрупкой: одна проблемная задача может задержать весь релиз.
Если мы используем DevOps-практики непрерывной интеграции и непрерывной поставки, то просто берем задачи в работу on-demand (с учетом WiP-лимитов), делаем их параллельно и выпускаем задачу в продуктив тогда, когда она готова. Однако внедрение этих практик - не самая простая вещь. Нам потребовалось перейти на постановку задач в виде «маленьких» пользовательских историй, внедрить автоматизированное тестирование (unit и интеграционные тесты), обеспечить возможность полностью автоматизировано и быстро (15-20 мин.) разворачивать review-стенды, автоматизировать пайплайн-развертывания, освоить фича-флаги и др.
Рис. 5. Пайплайн-развертывания на базе GitLab. Позволяет автоматизировать этапы сборки и деплоев и таким образом улучшить поток работы и уменьшить LT
Эволюционные улучшения и обратная связь
Важный элемент как Канбан-метода, так и философии DevOps - это постоянное совершенствование своей работы. Как мы ищем источники улучшений?
Анализируем:
инциденты с демо-окружений и продуктива;
инциденты в ходе работы, например, если сломалась сборка;
тренды важных метрик;
время производства;
скорость производства;
среднее время сборки;
задачи, занявшие больше всего времени, выявление причин (см. рисунок ниже);
регрессионные дефекты.
Выводы обсуждаем на еженедельных ретроспективах.
Рис. 6. Контрольная диаграмма в JIRA позволяет находить задачи, которые выполнялись гораздо дольше других и анализировать их
Индусский синдром
Однажды я заметил, что один из разработчиков дольше других делает истории. Оказалось, что в ходе тестирования частенько возникают улучшения или какие-нибудь дефекты, которые не связаны с разрабатываемой функциональностью, но вот «лежат рядышком». Разработчик на все эти улучшения и дефекты соглашался и исправлял их в рамках этой же задачи. Он объяснил это так, что он - не какой-то индус, который старается спихнуть работу. Ему хочется сделать максимально хорошо, поэтому он все делает. Мы вместе посмеялись, назвали такое поведение «индусским синдромом» и договорились, что надо с ним бороться. Ведь каждый раз, когда мы принимаем решение сделать очередное улучшение в рамках той же задачи, то подменяем собой продакт-менеджера и принимаем вместо него решение о приоритизации фич.
С самого начала мы фокусировались на том, чтобы отказываться от лишних активностей, не приносящих ценности. Мы избегаем детальных спецификаций (вместо этого делаем макеты экранов в Figma, пишем короткие пояснения и активно коммуницируем внутри команды), разработчики больше не делают оценок по задачам, у нас нет митингов по планированию и грумингу бэклога, мы не разрабатываем инфраструктуру, которая не нужна для текущих фич и т.п. (например, messaging у нас появился через три месяца, а двигаться в сторону микросервисов мы начали через полгода, когда у нас значительно выросло время сборки монолита и т.д.).
Для того, чтобы быстрее обнаруживать проблемы на стендах, мы настроили развитую систему мониторинга, анализа логов, алертов (технологии - ELK, Prometheus, Graphana, Jaeger и др.).
Рис. 7. Система мониторинга инфраструктуры позволяет быстро обнаруживать проблемы и реагировать на них
Мы заметили, что идеальные решения редко рождаются с первого раза. Наш подход - сделать быстрый минимальный прототип на основании той информации, которая у нас есть уже сейчас, и потом при необходимости доработать или переделать его. Некоторые части системы мы рефакторили три раза, чтобы сделать максимально качественное решение. При этом один из главных критериев качества решения - это его простота и удобство дальнейшего развития.
Каждый день мы проводим статусный митинг на 15 минут, чтобы все синхронизировались и увидели, нет ли потенциальных проблем. Если фича находится больше двух-трех дней в разработке, то это означает, что нужен общий мозговой штурм. Обычно так проблема и решается. Ежедневный статус у нас проходит в одно и то же время так, чтобы наши координационные издержки были минимальными.
Дефекты исправляем в приоритетном режиме. Во главе угла - качество системы. В течение проекта у нас было в среднем семь открытых дефектов. Медиана времени производства по дефектам - 4 дня.
Рис. 8. Гистограмма времени производства по дефектам. Медиана - 4 дня. По оси абсцисс - время производства, по оси ординат - количество дефектов
По функциональным задачам, новым возможностям и улучшениям, мы смогли в целом по проекту выйти на уровень медианы - 13 дней.
Рис. 9. Гистограмма времени производства по функциональным задачам. Медиана - 13 дней. По оси абсцисс - время производства, по оси ординат - количество задач.
В итоге 15 разработчиков, три аналитика и три тестировщика за неделю могли взять в работу 60-70 задач всех типов. Среднее количество релизов - четыре раза в неделю.
Взаимодействие с заказчиком и планирование работы
Заказчик для моей команды был новый. Мы не знали, примет ли он наш стиль.
Сначала мы предложили, что будем демонстрировать результаты каждую пятницу - устраивать Skype-конференции на 30-50 минут. На первых встречах присутствовали представители от основных направлений проектной команды - эксперты, менеджеры проекта, заинтересованные лица и т.д. Мы предложили всем активно критиковать то, что мы сделали и предлагать свои решения. Выразили готовность их максимально быстро реализовывать.
Подход может показаться рискованным. Ведь у нас контракт с фиксированными требованиями и бюджетом. А что делать, если исправлений будет слишком много? Или улучшения будут предлагаться каждый день? Однако практика показала, что это не так. В результате обсуждений с заказчиком решения получались гораздо элегантнее и проще, чем мы бы придумали сами. И целесообразнее получать обратную связь раз в неделю и своевременно устранять замечания, чем их копить.
Заказчик наш подход воспринял настороженно, но уже через пару месяцев сомнения были развеяны. Ведь прогресс был не на бумаге, а в виде реализованных фич. Мы сразу обсуждали все проблемы и особенности, которые вскрывались в ходе реализации и решали, что с ними делать. Старались их устранить уже к следующему показу. Также мы собирали на показы вышестоящее руководство и потенциальных пользователей. В среднем мы в какой-то момент вышли на семь показов в месяц.
Мы отказались от традиционного планирования этапов с помощью диаграмм Ганта и оценок задач с привлечением разработчиков. Теперь используем прогнозирование с помощью имеющейся статистики. Главный аналитик оценивает количество историй, которые нужно реализовать для каждого блока функциональности, техлид смотрит, нет ли особенно рискованных требований - сопоставляем имеющиеся у нас возможности с потребностями заказчика. Если видим расхождения, то обсуждаем сами задачи и ищем решение, как уменьшить объем (предпочитаемый способ). Если так не получается, то тогда думаем над тем как увеличить команду.
Способ долгосрочного планирования и оценки
К. Климов во время обсуждения данной статьи обратил внимание на интересный способ оценки длительных проектов, описанный в статье Димитара Бакарджиева. Объяснить этот метод легко на примере. Допустим, у нас есть сад с яблонями, и требуется оценить урожай. Считаем количество деревьев в саду, отбираем случайным образом Х-деревьев, определяем количество яблок на каждом из деревьев. Далее небольшая математическая задачка - высчитываем среднее арифметическое количество яблок на деревьях нашей случайной выборки. И получаем, что среднее количество яблок на дереве, умноженное на количество деревьев в саду, дает нам оценку урожая. Очевидно, что метод позволяет снизить трудозатраты на оценку урожая и обеспечить необходимую точность результата.
В заключение
Наша схема производства, основанная на Канбан-методе, инженерных практиках и философии DevOps позволила выполнить все требования госконтракта. Мы соблюли сроки, создали всю необходимую проектную и эксплуатационную документацию и т.д.
Таблица 2
Метрика | Обычно на госпроектах | ГИС ОК |
Частота релизов (шт/в мес) | <1 | 17 |
Частота показов (шт/в мес) | <1 | 7 |
Время производства (дней, медиана) | >40 | 13 |
Мы смогли значительно улучшить целевые метрики (сравните с первой таблицей по метрикам). За время проекта мы сделали 155 релизов, 74 показа и по их итогам исправили 85 замечаний (кстати, на их устранение было достаточно времени ведь мы их получали каждую неделю по чуть-чуть в течение полугода, а не все разом на сдаче). И главное - мы предоставили продукт, не просто соответствующий требованиям контракта, а прошедший несколько десятков итераций и обсуждений с различными экспертами и реальными пользователями.
Кроме этого, каждые пару месяцев мы проводим опрос сотрудников и анализируем результаты. Показатель eNPS (индекс лояльности) на проекте растет и достиг 80%. Среди позитивных факторов сотрудники отмечают отсутствие авралов, пристальное внимание к качеству, современные технологии и используемые инженерные практики. Оценили и разнообразие задач, а также хорошие отношения в коллективе.
Считаем, что сократились и производственные затраты. С одной стороны, у нас появились некоторые дополнительные активности - мы стали писать автоматизированные тесты, делать частые показы и т.п., но с другой стороны, отказались от написания детальных спецификаций (если нужно по контракту, то мы пишем постфактум). Излишними оказались спринты и связанные с ними активности по планированию и оценке трудозатрат. А значит, можно говорить об уменьшении еще и координационных и управленческих расходов.
Большой респект нашему РП за то, что поддержал внедрение новых практик на проекте, а также всем, кто работал и работает сейчас на проекте ГИС Открытый контроль. Несмотря на то, что большинство в первый раз столкнулись с Канбан-методом и DevOps - все оказались максимально открыты к изменениям и благодаря этому мы смогли очень быстро встать на новые рельсы. Все время пока мы работали, я получал максимальное удовольствие от работы с вами.
Также хочу поблагодарить К. Климова и А. Пименова за их классные курсы по Kanban-методу. Ваши курсы, без сомнения, одни из лучших!
Мы ищем таланты
В данный момент мы работаем над новым проектом. Создаем e-commerce интернет-площадку для продажи государственного имущества. Ее можно сравнить с Amazon, но только на месте продавцов - государственные организации. Они будут выставлять на торги свое имущество (земельные участки, здания, автомобили и многое другое), а пользователи площадки примут в них участие. Важно обеспечить максимальную прозрачность и открытость торгов, чтобы покупатели могли найти то, что нужно именно им, а государство продать имущество по адекватной цене. Проект интересен и с технической точки зрения. Система будет функционировать под высокой нагрузкой - 24x7x365. Для реализации системы используются самые продвинутые технологии.
Если кому-то интересно поработать в высокотехнологичной команде, исповедующей принципы Канбан-метода и DevOps, то пишите мне в личку или к нашим рекрутерам.
