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

Сегодня ИТ – это не нечто единое, всегда работающее по единым правилам, как минимум, двухскоростное образование:

  • традиционное, с приоритетами в безопасности и минимизации рисков;
  • гибкое, которые должно быть отзывчиво на новые требования рынка.

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

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

Возможно, Waterfall, Kanban или методы Agile просто устарели, не годятся для ведения масштабных проектов, и их надо заменить на нечто другое? Устарела ли водопадная модель? Нет, поскольку такие основополагающие для бизнеса системы, как биллинг, процессинговые системы банка, меняются медленно, однако нарушение их работы грозит уничтожить бизнес. Для достижения максимальной стабильности таких систем и применяется водопадная модель. Системы конкурентного преимущества, образующие средний уровень ИТ-ландшафта компании, могут быть построены как на классических, так и на гибких подходах (Scrum). Наконец, системы инноваций, например мобильный банк или портал, постоянно меняются, непосредственно взаимодействуя с конечными пользователями, и для их разработки используются Agile и DevOps.

При решении масштабных задач неизбежно потребуются разные подходы при условии обязательного следования политикам компании и готовности в ответ на внешние требования изменять один или несколько подходов. Но как в крупной компании масштабировать Kanban, Waterfall, Scrum для синхронизации всех уровней разработки и обеспечения слаженной работы коллективов из сотен программистов, тестировщиков, дизайнеров и архитекторов?

Подразделения исследований и разработки компании HP на протяжении десятилетий использовали и Kanban, и Waterfall, и Scrum, но ни одна из них в отдельности не позволяла поддерживать масштабные разработки – требовалась какая-то объединяющая идея, методология. Такой методологией поддержки выполнения внутренних проектов в компании стал фреймворк SAFe (Scaled Agile Framework, (http://www.scaledagileframework.com) на платформе из пула собственных инструментов автоматизации. В результате сегодня, благодаря связке HP Codar, Jenkins, HP ALM, HP Agile Manager, HP UFT и т. п., весь процесс сборки, развертывания и тестирования проходит в автоматическом режиме.

SAFe – база знаний, фреймворк [www.scaledagileframework.com], позволяющий в онлайн-режиме в масштабах корпорации следовать моделям разработки в стиле Lean-Agile (en.wikipedia.org/wiki/Lean_manufacturing).

Как известно, различные Agile-технологии направлены на организацию процесса приближения к цели проекта путем проведения циклов испытаний с корректировкой последующих, основанных на анализе результатов предыдущих, и если Scrum — это инструмент циклического наращивания функциональности и корректировки хода разработки в масштабах небольшой группы программистов, то SAFe – инструмент масштаба корпорации. В SAFe интегрированы классические и гибкие подходы к разработке с добавлением нового качества: из Scrum берется методика построения команд разработчиков, умеющих сообща решать отдельные подзадачи, из “экстремального программирования” (XP) взяты правила быстрого создания качественного программного кода; Kanban привносит, в частности, идею того, что команды и сотрудники не могут выполнять чрезмерный объем работы. Отличительная особенность SAFe – «бережливая разработка» (Lean), помогающая минимизировать издержки устранением любых препятствий на пути выпуска новых версий.

Архитектура SAFe

Рисунок. Архитектура SAFe

Главное преимущество SAFe – поддержка крупномасштабных разработок, иначе говоря, работа большой команды идет не по спринтам (двухнедельным циклам), как в Scrum, а с минимальной итерацией (product increment) длительностью десять недель. При этом во встрече участвует не одна небольшая команда, а группа из сотен разработчиков, занятых в одном проекте. В течение десяти недель могут выходить версии, без привязки к каким-либо планам, что отличает SAFe от водопадной модели, в которой бюджет предоставляется на проект, а не на постоянно финансируемую программу выполнения всех работ.

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

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

Утверждается, что SAFe позволяет на 20–50% увеличить производительность труда разработчиков, на 50% - качество решения и на 30–50% сократить время вывода продукта в свет. Благодаря SAFe повышается удовлетворенность от проекта всех его субъектов, и проект уже не рискует превратиться в «черную дыру» бюджета, а быстро начинает приносить результаты. Как следствие, сегодня более 60% компаний Fortune 100 уже имеют в своем штате, сертифицированных по SAFe специалистов (http://www.scaledagileframework.com/about), помогающих сформировать единую картину «ИТ для ИТ», в которой согласуются процессы разработки ПО, инженерных решений и организации эксплуатации.

Почему все это стало возможным:

1) SAFe задает такт движения не только разработчикам, но и всем службам корпорации: маркетинг, плановый отдел, сервисные подразделения и пр.
2) SAFe устраняет «бутылочные горла»: если менеджеры продукта вовлечены во все детали разработки, участвуя в принятии каждого решения, то они становятся узким местом. Делегирование полномочий командам позволяет этого избежать.
3) SAFe не только позволяет наладить коммуникации между отдельными разработчиками, но и поощряет взаимодействие команд и подразделений.

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

Улучшить мир хотят сегодня многие отечественные компании, хорошо знакомые с методологиями Kanban, Waterfall, Scrum и получившие с их помощью первые успешные результаты, однако теперь перед ними остро стоит вопрос масштабирования. В России уже достаточно много крупных организаций, заинтересованных в гибких методиках управления проектами разработки, но отсутствует опыт масштабирования методик разработки. большие коллективы и здесь может помочь SAFe .