Поделиться
К российским вендорам выстроилась очередь на разработку банковских сервисов
Перед финансовыми организациями стоит задача не просто создавать новые уникальные цифровые сервисы, но и обеспечить работоспособность имеющейся инфраструктуры. Для этого приходится искать альтернативу старым знакомым иностранным продуктам. К российским вендорам выстроилась очередь. О том, как организовать собственную разработку в таких условиях, и стоит ли немедленно запускать миграцию на отечественные продукты, говорили участники организованной CNews Conferences конференции «Цифровизация финансового сектора».
Алексей Ионов: В бизнесе становится все меньше предсказуемости, а в разработке ПО ее нет уже давно
Мир вокруг нас радикально изменился, однако подход к ИТ-разработке остается прежним. Это приводит к тому, что продукты создаются не в срок, а их качество частенько оставляет желать лучшего. О том, как решить эту проблему, рассказал Алексей Ионов, управляющий партнер, 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 трансформаций в крупных российских организациях.
Короткая ссылка
