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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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