В дирекции по техническому развитию и качеству (ДТРК) «Российской стали» приступили к внедрению новой методологии по управлению проектными командами под названием SAFe.Подход основан на принципах Agile и призван систематизировать взаимодействие между командами, которые объединены одной общей целью. В отличие от классической методологии Agile, которая рассчитана на управление процессами внутри команд, SAFe представляет собой гибкий метод управления на уровне организации. Agile – это гибкий подход к управлению проектами и продуктами, ориентированный на динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. SAFe – Scaled Agile Framework. Как следует из названия SAFe – это фреймворк, т.е. архитектурный каркас, платформа для масштабирования Agile на уровень корпорации или достаточно большой организации.

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

Сейчас методология внедряется для пяти команд ДТРК, которые занимаются развитием направления под названием «цифровая аттестация продукции» в рамках цифровой трансформации «Северстали». Специалисты занимаются развитием программы автоаттестации на базе системы «Шерлок», разработкой измерительных систем в качестве, созданием прогнозных моделей и собственных систем машинного зрения. Перед коллегами стоят общие цели – измерять наличие на продукции 100 процентов дефектов, которые появляются у клиентов; прогнозировать 80 процентов дефектов внутри производства, в том числе на предыдущих переделах и принимать 80 процентов решений по аттестации продукции на всех переделах на основе алгоритмов.

Участники команд используют специальную доску, где ленточками отмечают зависимости между задачами

– Достижение целей зависит от слаженности взаимодействия команд. Например, разработать прогнозную модель по дефекту «Коррозия ЦТМ» невозможно, пока не будет выполнена настройка системы видеоинспекции поверхности Parsytec. Сам подход помогает не только получить эффекты от синергетического взаимодействия, но и грамотно использовать внешние ресурсы, которые нам предоставляют коллеги из «Северсталь-Диджитал», «Северсталь-инфоком» и Центра автоматизированных систем, – поясняет старший менеджер Центра развития Бизнес-системы «Северстали» Аким Алешин.

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

Справка:

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

Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?

Одним из важных преимуществ и недостатков SCRUM-а я считаю предписываемый размер команд — 7+-2 (или 3-9 более свежие данные из Scrum Guide) включая Product Owner.

Безусловно 9 высококлассных и хорошо замотивированных профессионала способны на многое, но иногда бывает необходимость все-таки построить что-то большим количеством рук, голов, глаз и мозгов в конце-концов. Раздувать команды — плохо, значит их количество надо наращивать, а тут возникает проблема коммуникации между командами, синхронизация работы и сам по себе SCRUM никакого решения для этих задач не предлагает. Есть попытки использовать SCRUM на уровне управления SCRUM командами (так советует делать Jeff Sutherland — один из авторов Agile manifesto), есть Large Scale Scrum, есть Disciplined Agile Delivery, есть много еще что, но еще есть SAFe — Scaled Agile Framework.

SAFe — это фреймворк для управления компанией в которой требуется координация работы над некоторым проектом или связанными проектами для 5 или более SCRUM командами. Т.е. это некая надстройка над SCRUM позволяющая управлять коллективами из 100 и более человек.

Выгода?

В первую очередь, разумеется методология нужна тем, кто ее продает и занимается тренингами. На эту тему неплохо высказался Dave Thomas (еще один из авторов Agile manifesto) На GOTO 2015 в своей презентации Agile is Dead

Во-вторую очередь отделы управления программами. Те, кто раньше занимался управлением проектами, получали PMP сертификации, рисовали диаграммы Гантта и реализовывали концепцию твердо-мягкого управления (мягкой стороной к руководству и твердой к исполнителям). Дело в том, что в типичном SCRUM для них нет функции, в SAFe — есть. То же самое относится к разного рода архитекторам. В SCRUM для них нет функции в SAFe — есть карьерный путь.

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

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

В целом индустрии. Т.к. количество разработчиков удваивается каждые 5 лет (см. uncle bob’s future of programming), следствием чего является то, что в каждый момент времени по крайней мере половина разработчиков обладают опытом работы менее 5 лет. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.

Суть

SAFe — это слоеный пирог из различных методик Agile. На нижнем уровне находится практически традиционный SCRUM, с типичными двух-трех недельными спринтами, командами по 3-9 человек включая Product Owner. Все типичные ритуалы, начиная от ежедневной планерки — standup и заканчивая разбором полетов на restrospective. Хотя есть одно ключевое отличие. Команда перестает быть полнофункциональным независимым модулем. И спринт перестает быть независимым отрезком времени с полным жизненным циклом. Спринты объединяются в Program Increments состоящие из обычно 5 спринтов. Т.е. если в классическом SCRUM мы построили не то, что клиенту нравится — то мы производим коррекцию курса в следующем спринте, то в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment в худшем случае следующие 4 спринта (разумеется я утрирую).

На следующем уровне у нас поезда — так называемые Agile Release Train. Для управления 5 спринтовыми отрезками появляются новые функции — системный архитектор (тот, кто владеет архитектурой — т.е. это больше не команда), product manager (тот кто управляет продуктом, а не Product Owner, последний ходит за советом к PM) и RTE — тот самый PMP из далекого мира waterfall. Здесь применяются некоторые наработки из Kanban в частности доска, способ назначения приоритетов и в целом остается принцип измерения исторической производительности команд (velocity) и проецирование того, что будет построено в конце временного отрезка в противовес подходу с оценками и назначением сроков выполнения для уже зафиксированного функционала (scope). Одним из нововведений становится то, что последний спринт из 5 объявляется организационным и во время него проводятся огромные собрания (все команды вместе — а это 100 и более человек), проводится анализ технического долга, строятся планы по проработке архитектуры и синхронизируется работа всех команд.

Над уровнем поездов у нас координация между отделами, директорами, и клиентом. Тут больше идет заимствование из Lean Agile, но сохраняются те же инструменты из Kanban. Здесь проводится анализ экономической целесообразности изменений. В идеале любые изменения проходят через предварительный анализ где выдвигается измеримая гипотеза о предстоящем изменении (например если мы произведем онлайн магазина из датацентра в облако, то быстро наращивая мощности в пик сезонных распродаж сможем увеличить количество сделок на 10%) и далее эта гипотеза либо подтверждается либо нет. Для компаний менее миллиарда долларов — это может быть самый последний этаж. Здесь же создаются планы работ на 12-36 месяцев (привет пятилетки качества, количества и т.д.)

Над уровнем больших систем идет управление портфолио. Распределяются средства на различные направления в бизнесе. Используется lean portfolio management, используя стратегию развития компании выбираются направления от которых можно получить отдачу. Здесь принимаются решения о покупке или слиянии с другими компаниями. Создание новых направлений бизнеса, закрытие старых. Регулярно проводится корректировка и прере назначение бюджета (в противовес квартальными или годовым планам). Для каждого компонента портфолио устанавливается набор более-менее стандартизированных метрик и далее все оцениваются по ним. Так же как и на 3 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами. Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.

Плюсы

1. Значительно количество весьма неплохих инструментов (WSJF, Kanban, Gemba, etc)
2. Формализируются и прописываются шаги для SDLC начиная от написания кода (предписывается TDD) заканчивая выполнения статического сканирования и CI/CD и feature toggle. Хороша каждая из практик или нет — другой вопрос, но по крайней мере есть план и все ему следуют.
3. Процесс можно понять, объяснить и внедрить.
4. Каждый человек в рамках этого процесса, получает достаточно строго определенную функцию.
5. Повышается прозрачность компании для тех, кто в ней работает.

Недостатки

1. Достаточно длительное время реагирование на несоответствие реальности ожиданиям
2. Огромное количество средств и денег тратится на коммуникацию и собрания
3. Часто рекомендуемые решения в рамках фреймворка уже устарели

Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.

Авторы: Юлия Муравьева, boblenin
Источники: http://www.up-pro.ru/, https://habr.com/

Понравилась статья? Тогда поддержите нас, поделитесь с друзьями и заглядывайте по рекламным ссылкам!