Как неправильно внедрить Agile. 10 главных ошибок
ПО Интеграция
15.10.2020, Чт, 12:34, Мск , Текст: Александр Тыренко
Методологию Agile, в том числе и «корпоративного масштаба», используют все больше компаний. И появляется база не только для обобщения «лучших практик», но и для выявления наиболее часто встречающихся ошибок при внедрении этой все более популярной методологии.
Agile становится все популярнее
В очередном анкетировании State of Agile, которое уже в 14 раз проводит сайт Digital.ai, приняли участие свыше 40 тыс. руководителей, специалистов и консультантов. Судя по результатам, по состоянию на конец прошлого года, Agile практиковали уже в 95% организаций, принявших участие в исследовании.
Наиболее широко среди Agile-фреймворков применяется Scrum — в 75% организаций. А для масштабирования практик Agile в организациях с большим числом команд разработки чаще всего используется система Scaled Agile Framework (SAFe), которой отдали предпочтение 35% респондентов.
Главные стимулы внедрения Agile — ускорение процессов разработки ПО, более легкая смена приоритетов (в чем, собственно, гибкость и состоит) и увеличение продуктивности. Можно отметить некоторые изменения по сравнению с предыдущим годом: в этот раз 26% ответили, что внедрили Agile в первую очередь ради снижения затрат на проекты, тогда как год назад аналогичный показатель составил 41%. Зато большее значение участники исследования придают возможности автоматизированного аудита соответствия требованиям — такой ответ дали 28%, что на 9% больше, чем в прошлом году. По мнению авторов отчета, это следствие более широкого внедрения Agile организациями из регулируемых отраслей.
Для чего внедряется Agile
(можно было давать более одного ответа)
Источник: Digital.ai, 2020
Важный показатель — функциональные подразделения, в которых, по сообщению респондентов, применяется Agile: 37% — разработка ПО, 26% — служба ИТ, 12% — отделы эксплуатации, 7% — маркетинг, 6% — кадровая служба, 5% — продажи. Пятерка главных причин внедрения — ускорение выпуска ПО, повышение адаптивности к изменению приоритетов, увеличение продуктивности, улучшение координации взаимодействия бизнеса и ИТ, повышение качества ПО.
Главное, «стратегическое», препятствие внедрению и масштабированию Agile, по мнению исследователей, все еще связано с трудностями изменения организационной культуры, которые обусловлены сопротивлением переменам, а также недостаточной поддержкой и финансированием со стороны руководства. Но оно не единственное. Мэри Пратт (Mary Pratt) собрала десятку наиболее часто встречающихся конкретных ошибок и заблуждений, которые встречаются при внедрении Agile.
1. Специалисты научатся всему сами
Некоторые ИТ-руководители убеждены, что их подчиненные смогут самостоятельно освоить технологии, которые внедряются для оптимизации деятельности, — в том числе инструменты DevOps и т. п. Как бы элементарно это ни звучало, но для освоения новшеств придется организовать соответствующее обучение, и понадобятся специальные стратегии по управлению изменениями. «Айтишники», конечно, любят пробовать нововведения, но для полной реализации потенциала технологий самостоятельного освоения достаточно далеко не всегда.
2. Все разработчики одинаковы
Также неправильно переоценивать универсальность разработчиков. К примеру, если в организации за счет внедрения Agile в компании хотят одновременно ускорить реализацию новой функциональности внутренних систем и повысить темпы модернизации сервисов, которыми пользуются клиенты, эффект может быть обратным, если разработчиков, знающих тонкости бэкофиса, слишком мало. Решением в этом случае может стать применение одних и тех же технологий в различных подразделениях, а также более активное обучение разработчиков смежным технологиям. Например, разрабатывать все новое на базе микросервисов и при этом применять одни и те же языки программирования в различных функциональных областях.
3. Свобода выбора инструментов и процессов обеспечит скорость работы
Важная особенность Agile — свобода выбора инструментов разработки. Не следует, однако, впадать в заблуждение, предполагая, что такая свобода сама по себе позволит ускорить темпы поставки. При наличии множества команд разработки в организации разнобой в применяемых ими средствах непрерывной интеграции и поставки может, на самом деле, ограничивать гибкость: часть команд будут справляться на отлично, а другие опаздывать. Если же принять общекорпоративный стандарт, сформировав единую для всех среду, это позволит обеспечивать более равномерный успех и уменьшит нагрузку по сопровождению на самих разработчиков.
Что дает внедрение Agile
(можно было давать более одного ответа)
Источник: Digital.ai, 2020
4. Для перестройки достаточно изменить процессы
Нередко на методах и процессах Agile зацикливаются так сильно, что игнорируют еще один важный аспект — потребность в реструктуризации системы управления в компании. Это непростое дело, поскольку любая реструктуризация затрагивает внутреннюю субординацию и, возможно, карьерные планы сотрудников. И тем не менее, изменение системы управления необходимо, поскольку «обычные» организации подчиняются статичной, жесткой иерархии, тогда как Agile характеризуется наличием сети команд, которые работают в режиме оперативного обучения и принятия решений.
5. Бюджетный процесс тоже наладится сам собой
Одно из типичных упущений — сохранение прежних практик бюджетного планирования, например, выбора инициатив для финансирования на ежегодной основе. Как следствие, когда открывается новая бизнес-возможность, на запуск соответствующей инициативы уходит слишком много времени, а когда очередной проект не приносит ожидаемых преимуществ, его продолжают еще долгое время.
Успешные Agile-организации переключились от ежегодного выбора объектов финансирования к более частому распределению денежных ресурсов в меньшем объеме среди реализуемых инициатив, которые доказывают свою пользу, — в чем-то это похоже на венчурное финансирование стартапов. Существует и другой действенный вариант — когда уполномоченным владельцам продукта предоставляется финансирование на определенный период времени, за который они должны обеспечить получение указанных бизнесом результатов.
6. Если мы используем термин Agile — значит мы гибкие
Еще одно, как ни странно, распространенное упущение — формальный переход на терминологию Agile с сохранением прежних практик. Например, руководителя проекта просто переименовывают в Scrum-мастера, а требования — в пользовательские истории. Очевидно, что без соответствующей реструктуризации отдела разработки это результатов не принесет. Недостаточно, опять же, просто внедрить конкретные процессы и инструменты — необходимо изменить принципы командной работы, что потребует культурного сдвига.
7. При Agile все встречи станут краткими. Сами собой
К примеру, один из принципов Scrum — ежедневные короткие совещания продолжительностью до 15 минут, которые проводятся вместо традиционных общих собраний. Однако от укоренившихся привычек не так легко избавиться — часто на Scrum-митингах начинают обсуждать все имеющиеся проблемы, из-за чего собрания сильно затягиваются. Задача реального Scrum-совещания — только обсуждение хода спринта и планирование работы на предстоящий день. ИТ-руководитель должен объяснить это подчиненным и следить за соблюдением правила.
Основные препятствия для внедрения Agile
(можно было давать более одного ответа)
Источник: Digital.ai, 2020
8. «Усовершенствование» Agile: это берем, это не берем…
В некоторых организациях избегают следовать каким-то из принципов Agile, полагая, что в конкретном случае они неприменимы. При этом «по неясной причине» обещанные преимущества не достигаются. Но лучшие практики потому и лучшие, что были выбраны как действенные в большинстве случаев. Например, в организации могут избегать внедрения Agile в каком-то конкретном отделе (нередко это маркетинг), полагая, что ввиду уникальности сложившихся там процессов гибкие методологии будут неэффективными. На самом деле подобный образ мышления зачастую просто маскирует капитуляцию — неспособность взяться за устранение имеющихся недостатков. Ясно, что у всех организаций своя специфика, но, если уж решено пойти на отказ от каких-то из принципов Agile, необходимо это аргументированно обосновать с учетом возможных последствий. И не удивляться, если что-то пошло не так.
9. Моим партнерам не нужно быть гибкими
Существует также заблуждение о том, что достаточно переориентировать на Agile собственную организацию и внутренние процессы, чтобы обеспечить необходимое бизнесу ускорение темпов работы. Но этого может не произойти, например, если по условиям контракта с партнером разработка должна осуществляться только по каскадной модели, поставщик важного компонента работает по жесткой иерархической модели или не внедрил DevOps.
Получить все преимущества Agile не удастся до тех пор, пока все партнеры тоже не «подтянутся» и не перейдут на гибкие методологии. В ИТ-контрактах с внешними поставщиками необходимо закрепить требование о том, чтобы все стороны применяли Agile с целью оперативного выпуска новой функциональности и инкрементальных усовершенствований. Соответственным образом нужно структурировать и схему оплаты
10. Мы уже внедрили Agile
И в заключение, не стоит забывать об одном из столпов Agile, непрерывной оптимизации. Внедрение Agile — это не разовый проект. Даже если организация перешла на принципы Scrum, само по себе это еще не будет значить, что в результате каждого спринта будет вовремя выпускаться нужный продукт. Если просто «внедрить и забыть», не предусмотрев процессы непрерывного совершенствования применяемых методов, то результатов можно так и не увидеть.
Полный текст статьи читайте на CNews
