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


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

Осознав важность скорости, такие компании, как 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.

Комментарии (6)


  1. Ivan22
    04.04.2016 18:01

    А какие стадии у задачи при данной методологии?


    1. pan_KOST
      05.04.2016 11:54

      Думаю, одна из задач — обеспечить стабильный выпуск продуктов, уровня Enterprise, когда есть несколько крупных продуктов, состоящих из десятков-сотен зависимых и взаимосвязанных продуктов, над которыми кропят тысячи сотрудников ( владельцев, аналитиков, разработчиков, тестировщиков, инженеров и т.д. )
      Хотя я могу и ошибаться в своём мнении.


      1. Vkuvaev
        05.04.2016 16:01

        Если говорить о верхнеуровневой задаче то да, это одна из них. По-сути идея стоящая за этим фреймворком- перенести все прелести работающих гибких методик на масштаб крупного разработчика ( крупного это где-то более чем 100 разработчиков). Есть и другие подходы к масштабированию, но SAFe, на мой взгляд, один из самых проработанных, хотя при этом и несколько сложный в восприятии. Сравнение их — это другая тема.


    1. Vkuvaev
      05.04.2016 15:57

      SAFe, корректнее назвать фреймворком, который под собой собрал несколько методик: Scrum, Kanban, практики XP, Lean Software Development и связал их вместе.
      А вот вопрос можно ли поподробнее раскрыть? Какие задачи У этого фреймворка? Или какие стадии задачи (на разработку, к примеру) в рамках этого фреймворка? И все равно нужно будет пояснить более конкретно сам вопрос.


  1. valis
    05.04.2016 09:08

    1. Все что я узнал из данной статьи -"Существует еще одна методология, которая подходит к одной абстрактной предметной области" (к которой, в частности, можно отнести все что угодно)
    2. Количество разнородных систем, а не количество разработчиков влияет на сложность проекта. 10 разработчиков, потеющих над фронтом не равно 10 ти разработчикам, 2 из которых пилят БД, 2 интеграцию, 2 бек офис и т.д. Вот тут действительно — разные команды, разное мировоззрение, не возможность коммуникаций.
    3. Имхо, лучшая методология решающая проблему пункта 2 SADD от Microsoft — за счет спирали можем делать короткие итерации в разработке, при этом существует роль бизнес и системного архитектора, который и налаживает коммуникации и контролирует качество всего продукта.


    1. Vkuvaev
      05.04.2016 16:47

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

      2. расширю, что речь про организацию, процессы и технологии ( проект это частность), далее, усложняющие факторы, навскидку:
      — Количество разработчиков (настаиваю:) и их структура подчинения
      — Иерархия организации
      — Количество систем и их архитектура
      — Зрелость организации и каждого сотрудника в частности
      — Степень автоматизации существующих процессов

      Я, кстати, думаю, что основной трэш для гибкого подхода как раз не 2 на БД, 2 на API, 2 на бек офис.., а те самые 10 на фронт :)

      3. с IMHO не буду спорить.
      Скажу лишь, что если по структуре команд и по архитектуре софта вообще ничего не менять, то, разумеется, переход к коротким итерациям (каскад или спираль) позволит хоть как-то улучшить ситуацию, в сравнение с долгими релизами.

      Речь в статье про переход именно на гибкий подход, с очень короткими итерациями и быстрым фидбэком, с возможностью часто выкатывать изменения в продуктив, ( 2 недели к примеру) и уйти от модели постановки требований, она, в среднем по больнице, плохо работает.

      Есть ведь задачи когда lead time должен составлять недели, дни или даже часы, минуты. Это и есть двигатель изменений. Тут вопрос не в том какая методика нравится. А в том, какая подходит под текущую бизнес ситуацию и под конкретные задачи. У каждой есть зона(ы) применимости и зона(ы) непригодности. Точка.