Будьте Agile!

В компаниях сегодня применяется множество инструментов управления проектами разработки ПО, как на базе классических каскадных моделей, Kanban, Agile, так и разнообразные доморощенные методики. Однако для цифровой трансформации предприятий требуется не автоматизация разрозненных процессов, а их выстраивание заново. В этом уверены участники тематической сессии «Agile/DevOps на практике», проведенной в рамках традиционного ежегодного форума IT Management Forum, уже в 14-й раз организованного издательством «Открытые системы».

«Перестаньте внедрять Agile. Будьте Agile!», — призвал в своем докладе Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка». Для успеха в цифровой трансформации необходимо продвигать в направлении Agile всю компанию, а не только подразделения, отвечающие за ИТ. Адаптация подобных практик означает масштабную трансформацию. Это сложное и длительное «путешествие», многие моменты которого лежат за пределами ИТ, и, как и всякое путешествие, оно должно быть тщательно подготовлено. Но главное, став Agile, можно охватить весь жизненный цикл выпуска продуктов или услуг, составляющих бизнес компании. За редким исключением, в массе своей российские организации неспособны собрать воедино разрозненные команды, чтобы быстро реализовать в программной системе нужный функционал и выпускать ее новые версии с частотой, требуемой бизнесу. Неспособны они и работать в тесной связке с другими подразделениями, например с отделом маркетинга, которому надо быть готовым с той же частотой оповещать клиентов о новом функционале, обновлять пресс-релизы и выполнить другую работу, необходимую для ввода нового сервиса в эксплуатацию.

Алгоритмы с жесткими связями нежизнеспособны, а в цифровую эпоху и подавно, однако по-прежнему, как подтверждают доклады форума, каждое подразделение или филиал компании стремится к обособлению. «Организации, проектирующие системы, неизбежно воплощают в них свою собственную структуру», а «культура ест стратегию на завтрак» — с этих цитат из Мела Конвея и Питера Друкера начал свое выступление Иван Евтухович, управляющий партнер компании «Экспресс 42». В цифровую эпоху новые бизнес-возможности для предприятия возникают непрерывно, однако способно ли ИТ-подразделение обеспечить их поддержку, своевременно разработав новые сервисы и приложения или изменив уже имеющиеся? Как организовать деятельность разработчиков таким образом, чтобы при неизменном качестве можно было существенно увеличить скорость изменений?

Для процессов с разным уровнем рисков и потенциальной прибыльностью может быть предпочтительна как система Kanban, позволяющая хорошо управлять потоком заявок командам разного уровня, так и Agile. Методы быстрой разработки позволяют быстро обнаружить ошибку и исправить ее. «Ошибись как можно раньше, зафиксируй качество, быстро выпусти версию с реализацией критичного для заказчика функционала, отбрось до поры второстепенный функционал» — вот основные принципы Scrum. Однако для проектов, в которых задействованы большие группы, подходы в стиле Agile уже не годятся: хорошо решая сиюминутные потребности проекта, при росте масштабов следование Scrum грозит целостности архитектуры.

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

Корпоративный ландшафт до цифровой эпохи был полярным — разработчик и бизнес не умели общаться друг с другом. Сегодня картина начинает меняться — ценятся уже не замкнутые в себя всезнайки, а экстраверты, способные выяснять, что именно нужно бизнесу, который начал платить проектным командам не за соответствие процессу, а за выпуск работоспособного ПО, приносящего прибыль. Вряд ли при решении масштабных задач целесообразно отказываться от одной или всех упомянутых концепций и методологий — скорее всего, нужна поддержка разных подходов, но при этом нужно обязательно следовать основным политикам компании, а также быть готовыми к неизбежным изменениям одного или нескольких подходов в ответ на внешние требования. Именно такая связка решает одну из ключевых проблем ­ITIL, DevOps, Lean и Agile — передачу знаний от бизнеса разработчикам и обратно через эксплуатирующие подразделения.