SAFe или Scaled Agile Framework

    Что такое SAFe?


    Что такое 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 лет. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.


    Суть


    image


    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. Часто рекомендуемые решения в рамках фреймворка уже устарели

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

    Only registered users can participate in poll. Log in, please.

    SAFe стоящая вещь?

    • 23.2%Да22
    • 12.6%Нет12
    • 30.5%Возможно29
    • 32.6%Agile вообще ерунда. Работать некому, одни SCRUM мастера в стране.31
    • 1.0%Не надо ничего организовывать. Сами как-нибудь все напишем1
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 6

      0

      Внедрили некоторое время назад. Теперь работаем вообще без выходных, затыкая 100500 неведомо откуда валящихся при финальных тестированиях багов. А ведь как все прекрасно выглядело: CI/CD, мириады интергационных тестов. Но продукт уже должен быть готов, а конь еще не валялся.
      При старом добром waterfall продукт всегда выпускали с опережением и без авральных переработок.
      Вывод: вся эта трихомудия Scrum, Safe и прочее говно-agile нужны только компаниям, которые лепят эту чушь и потом дерут три шкуры за тренинги.
      Все вокруг, включая большинство менеджмента скрипят зубами поминая топ-менеджмент, поддавшийся на этот фейк-тренд.

        +2
        Почему продавцы Scrum, Agile не рассказывают про результат, а рассказывают про то, какой у них красивый и правильный процесс в картинках?
        Сначала результат, а потом уже процесс. Без результата обсуждать процесс нет смысла.
          0

          Ну почему же. Тот же Jeff Sutherland вполне себе рассказывает, и приводит цифры с ростом внедрения SCRUM от года к году. Ну и toyota (отцы — прародители) тоже рассказывает.


          Другое дело, что результат для них и для вас может быть разным. Например для продавцов SCRUM или SAFe или Lean — результатом будет количество внедрений, но вам-то это скорее всего не так интересно, так? Но вообще когда придут вас обучать и тренировать — то все расскажут, если не вам лично, то как минимум вашему руководству.


          Я ни то ни другое ни третье не продаю, а вот ссылкой могу поделиться, я ее нашел в буклетах SAFe — там говорят, что внедрение DevOps (одна из рекомендаций SAFe) — обещает снижение дефектов в 96 раз, в 2 раза снижает время затрачиваемое на исправление проблем с безопасностью, в 46 раз повышает частоту релизов (лучше time to market), на 29% повышает количество времени когда работники занимаются чем то новым (в противовес поддержки старого). Верить этому или нет? Вам решать. Но если интересно — скачайте отчет, посмотрите.

          0
          Jeff Sutherland вполне себе рассказывает,
          А какие продукты он написал?
          что внедрение DevOps (одна из рекомендаций SAFe) — обещает снижение дефектов в 96 раз, в 2 раза снижает время затрачиваемое на исправление проблем с безопасностью, в 46 раз повышает частоту релизов (лучше time to market), на 29% повышает количество времени когда работники занимаются чем то новым (в противовес поддержки старого).
          На такое даже здравомыслящий гумманитарий не купится, не говоря уже про технаря.

          Вот дедушка Брукс, который управлял разработкой семейством OS/360, говорит что производительность зависит от уровня программиста, нет?
            0
            Работала в компании, где safe процессы были очень грамотно поставлены. Шли по планам и даже с опережением, 5ая итерация была на подтягивания хвостов, 6ая организационная. PIP каждые 3 месяца, где определяли scope разработки и тестирования.
            Верю, что такой подход не каждой компании подходит, но при правильно поставленных процессах недостатки нивилируются достоинствами:
            Достаточно длительное время реагирование на несоответствие реальности ожиданиям

            Были выделенны специальные люди, кто достаточно быстро реагировали на такие ситуации и доносил до бизнеса
            Огромное количество средств и денег тратится на коммуникацию и собрания

            Полностью окупалось тем, что релизный цикл шел по расписанию, соответственно time to market было минимальным
            Часто рекомендуемые решения в рамках фреймворка уже устар

            Не очень понятный для меня минус, почему уже устаревают? Как так?
              0

              Отзыв Н.Алмименкова о книге Боба Мартина "Clean Agile: Back to Basics"
              Еесть немного в том числе про SAF: https://t.me/xpinjection_channel/311

              Only users with full accounts can post comments. Log in, please.