Алексей Ионов: В бизнесе становится все меньше предсказуемости, а в разработке ПО ее нет уже давно

Мир вокруг нас радикально изменился, однако подход к ИТ-разработке остается прежним. Это приводит к тому, что продукты создаются не в срок, а их качество частенько оставляет желать лучшего. О том, как решить эту проблему, рассказал Алексей Ионов, управляющий партнер, Lean-Agile коуч организаций и первых лиц, «Ионов и Партнеры».

CNews: Какие проблемы возникают у разработчиков ИТ-решений?

Алексей Ионов: Мы живем в быстро меняющемся, турбулентном мире. На первое место в 21 веке вышли цифровые технологии, программное обеспечение, существование которых сильно отличается от мира физических продуктов и проектов. В бизнесе вообще становится все меньше и меньше предсказуемости, но в разработке ПО ее нет уже достаточно давно. Основная проблема заключается в том, что в этом «новом мире» мы продолжаем использовать старые методы управления и подходы к разработке, которые не позволяют проводить эту самую разработку эффективно. Менеджеры продолжают управлять постановкой задач по-старому, а разработчики остаются вне понимания бизнес-задач организации и сосредотачиваются только на своем узком домене ИТ-разработки.

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

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

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

Совместно эти три компонента нового подхода к разработке помогут повысить качество и эффективность создания ИТ-решений и двигаться в сторону построения Lean-Agile компании.

CNews: Как ускорить процесс разработки и не потерять при этом в качестве?

Алексей Ионов: Любая работа, связанная с повышением качества, замедляет процесс разработки, по крайней мере на первой стадии, пока мы внедряем новые подходы управления качеством. По-другому просто не бывает.

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

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

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

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

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

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

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

CNews: Как организовать работу команд разработки?

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

Зоны ответственности в Agile команде помогают эффективно организовать работу внутри команды. Владелец продукта отвечает за содержание разработки, скрам-мастер отвечает за повышение эффективности процесса разработки, а все участники Agile команды отвечают за способ достижения результата и сам результат.

В зависимости от специфики, Agile команды могут использовать разные Agile методы. Обычно это Scrum, Kanban и практики встроенного качества, во многом пришедшие из Экстремального программирования (XP).

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

Все участники поезда, так же, как и участники одной команды, регулярно договариваются между собой, с внутренними заказчиками, заинтересованными лицами, внешними контрагентами о том, какие результаты могут быть достигнуты. Очевидно, что такая договоренность будет осуществляться реже, чем на уровне одной команды. Обычно один такт ритма работы команды команд составляет от 2 до 3 месяцев, в кризисные времена или во время «продуктовых прорывов» он может сокращаться примерно до 1 месяца. Один такт ритма работы нескольких команд называется «Инкремент программы».

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

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

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

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

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

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

За поездом также всегда закрепляется представитель бизнеса организации, который внутри выступает как главный заказчик, а на уровне менеджмента компании является представителем поезда. Роль называется «Владелец бизнеса», её обычно выполняют высокопоставленные руководители, также несущие ответственность за какие-либо направление бизнеса компании.

Таким образом, наилучшим способом организации команд разработки является объединенная команда Agile-команд, которая вместе с другими заинтересованными лицами инкрементально разрабатывает, доставляет и, в некоторых случаях, эксплуатирует и поддерживает один или несколько продуктов в интересах бизнеса своей компании.

Более подробно узнать об особенностях гибкой разработки на русском языке можно на нашем сайте, а также на мероприятиях, которые мы регулярно проводим как в открытом, так и в корпоративном формате с 2017 года, имея на своем счету несколько успешных Lean-Agile трансформаций в крупных российских организациях.