В какой-то момент непрерывная итеративная разработка Agile-приложений превращается в их сопровождение, и CIO должны быть к этому готовы, пишет на портале InformationWeek Мэри Шеклет, президент консалтинговой компании Transworld Data.

К концу 2022 г. более 72% компаний использовали методологию Agile для разработки ПО. В этом нет ничего удивительного. Agile заменяет последовательный и зачастую трудоемкий пошаговый процесс традиционной водопадной разработки. Эта методология задействует междисциплинарные команды разработчиков приложений из ИТ-отделов и отделов конечных пользователей, что позволяет им пересматривать и переразвертывать приложения на лету. В этом духе выдержан и манифест Agile — доктрина, состоящая из четырех пунктов:

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

Звучит неплохо. Но в какой момент должен появиться план, включающий подход к сопровождению Agile?

Поиск путей оптимизации Agile

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

Harvard Business Review признает наличие аналогичных проблем: «Фундаментальная проблема Agile в том виде, в котором его используют многие компании, заключается в том, что ее неумолимый темп сбивает разработчиков с толку. Они хотят получить минимально жизнеспособный продукт всего за несколько недель, поэтому они экономят на определении того, что именно должен делать продукт... Они принимают существующие ограничения, что автоматически ограничивает потенциал для создания быстрорастущего предложения... Вместо серьезного прорыва они стремятся лишь к постепенному улучшению существующих предложений».

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

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

Что значит поддерживать Agile-приложение

При водопадной разработке приложение переходит в цикл сопровождения и усовершенствования после того, как оно развернуто в производстве. По мере появления новых изменений они последовательно кодируются, тестируются, вставляются, повторно тестируются и затем развертываются. Это конвейерный подход к разработке Model T компании Ford, которого Agile стремится избежать.

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

Тому есть ряд причин.

Организациям необходимо бороться с расточительством в области ПО. Zylo, поставщик ИТ-решений, сообщает, что в компаниях не используется до 51% ПО. В отчете Zylo рассматривалось лицензионное ПО, но CIO знают, что расточительство распространяется и на приложения, которые разрабатываются внутри компании, а затем становятся невостребованными.

Для приложений, созданных по принципу «водопада», ИТ-отдел отслеживает и анализирует статистику использования и рекомендует прекратить работу или ликвидировать приложения, которые не используются в течение определенного периода (например, не используются никем более одного года). Затем эти неиспользуемые приложения удаляются.

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

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

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

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

Не говорит ли это о том, что пришла пора перевести приложение в режим сопровождения, в котором будут устраняться только программные ошибки?

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

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

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

По сути, это превращает первоначальное Agile-приложение в водопадное приложение и подчиняет его рекомендациям по сопровождению водопадного ПО.

Заключительные замечания

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

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