Станет ли SAFe отраслевым стандартом в Enterprise Agile?

    6 го мая 2014 года Scaled Agile, Inc. был назван финалистом 2014-го года в номинации Red Herring Top 100 в США. Эта новость стала вполне ожидаемой для специалистов в Enterprise Agility и для консалтинговых фирм, предоставляющих услуги в организационной трансформации компаний. Причина в этом проста — потребности рынка серьезно изменились.

    Ряд глобальных компаний, таких, как ING, TomTom, T-Mobile и IBM уже давно проявляют интерес к SAFe. Швейцарские компании такие как Swisscom, SwissPost, Kuoni и Credit Suisse также успешно внедряют SAFe силами собственных сертифицированных и внешних консультантов.

    Нерешенная проблема

    Одной из причин стремительного распространения Scaled Agile Framework’a (SAFe) является фиаско, которое потерпели гибкие подходы у управлению разработкой ПО в глазах программных менеджеров и VP крупных компаний. Несмотря на условное соответствие ценностям и принципам из Agile Software Development, большинство все же стремилось к предсказуемости сроков поставки продукта и проверенном подходе, который можно «развернуть» для R&D отдела в несколько сотен, а то и тысяч человек.

    Тогда как небольшие компании могут позволить себе роскошь перекликающихся ролей и другие формы процессной девиации, компании размера Enterprise в своем управлении рассчитывают на четкую структуру и эффективную модель распределения ответственности.
    Особенно актуальным это становится на компаний, в которых нужно увязать решения по управлению портфелем проектов (основанные на «олдскульных» и не лучшим образом подходящим под эту задачу подходах вроде PRINCE2) и динамичную разработку в самих командах через Scrum.

    Представьте на мгновение, что вам нужно увязать между собой выпуск портфолио из более чем 20 продуктов, каждый из которых имеет 5-10 ключевых stakeholder'ов, разрабатывается в 4 разных странах силами 7-10 команд. Задача такого уровня заставляет напрячься даже весьма матерых CTO или VP по разработке.

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

    SAFe ликбез

    Изящество SAFe и его ключевое преимущество для больших компаний, заключается в выведении простой и прозрачной организационной структуры в паре с четкой моделью распределения ответственности. Обе идеи корнями уходят в RUP (Дин Леффингвелл, автор SAFe, отвечал за разработку и коммерциализацию RUP в Rational Software).

    Модель SAFe разбивает любое предприятие на три уровня: портфеля, программы и команды, а модель управления в SAFe представлена двумя вертикалями:

    1) вертикаль «контента» (что компания будет выпускать) продукта, которую представляют команда менеджеров продукта, UX и Архитекторы
    2) вертикаль «поставки» (Каким образом компания будет выпускать продукт на рынок) в лице проектных и программных менеджеров.

    image

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

    Самый сок кроется в запуске Agile программ

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

    Подходы, вроде Scrum, принесли «трудные времена» для разного рода PMO. Классически, инициативы от бизнеса, сформированные на уровне портфеля, находили свое выражение в виде проектов, для которых создаются отдельные, временные проектные команды. Непрерывное создание проектов под нужны очередной инициативы от бизнеса происходит при ярко выраженной компонентной структуре организации (т.е. есть команды, которые отвечают за фичу, технологический пласт, или компонент системы).
    Scrum же начал «требовать» от руководителей PMO добиться кросс-функциональности на уровне фиксированных команд, состав которых не меняются на протяжении 6-12 месяцев. Это и стало для многих компаний камнем преткновения в переходе на Agile-рельсы.

    SAFe предлагает элегантное решение этой проблемы путем переноса модели Scrum до уровня реализации программы. Давайте посмотрим, как это работает.

    Представьте себе группу, состоящую из 5-7 человек: разработчики, QAs и DevOps работающие над конкретными компонентами платформы (или представляют команду работающую над отдельными функциями программного продукта: функциональные команды). Предположим, платформа имеет еще 5-7 компонентных команд, которые организованные подобным образом. Все команды синхронно работают, используя 2-х недельные спринты и вполне предсказуемо поставляют рабочий функционал после каждого спринта. Теперь, представьте себе, что каждая ваша команда это «супермен». Если вы объедините всех ваших «суперменов» в одну команду — вы получите команду, которая охватывает всю платформу. А что, если мы запустим Agile процесс разработки для нашей “команды суперменов", но в большем масштабе? Так как каждый «супермен» производит поставку каждые 2 недели продолжительность нашей итерации (цикла) будет 2-3 месяцев

    Давайте, назначим менеджера продукта (ака супер Product Owner) и менеджера управляющего поставкой (ака супер Scrum Master) в нашу команду. Команда суперменов делает планирование и берёт на себя обязательства в начале итерации, определяет и решает зависимости между «суперменами». Еженедельные (или раз в две недели) встречи (ака Scrum of Scrum) имеют важное значение для синхронизации «команды суперменов». В конце 2-3 месячной итерации, команды делает демонстрацию результатов работы и производят ретроспективу для улучшения своей работы в будущем. А теперь давайте опять вернемся назад и преобразуем индивидуальных «суперменов» в компонентные команды или в команды работающие над отдельной функцией ПО. Таким не хитрым способом, мы только что создали слой программного менеджмента в Agile стиле.

    image

    Гхм, простите, а что с архитектурой?

    Как мы уже знаем, Agile подход к разработке бизнес-функционала отлично работает в масштабе предприятия. А что, если предприятие имеет сложное решения (как правило, так и есть в реальной жизни) которое включает в себя ряд устаревших модулей или компонентов, которые требуют новую архитектуру или “рефакторинг” для создания новой функциональности?

    Ранние приверженцы Agile принципов иногда заходили слишком далеко, отрицая необходимость разработки архитектуры для будущего функционала впрок, делая ставку только на эволюционные принципы проектирования. Этот подход, может работать для “стартапов” и средних предприятий, но, скорее всего, потерпит фиаско в больших масштабах в связи с большим количеством команд и необходимостью в синхронизации между ними.

    Принимая во внимание всё выше сказанное, SAFe предлагает концепцию, которая называется «Архитектурное русло” (Architecture runway). На самом деле, в этом подходе нету никакой магии — он основан на простой логике. Команда отвечающая за архитектуру, работает, по крайней мере, на один двух-трехмесячных цикл впереди остальных команд, создавая архитектурный задел для функциональных / компонентных команд, который позволит эффективно разрабатывать бизнес функционал во время последующих циклов.

    image

    Такой подход связывает архитектурную команду с вертикалью управления контентом и решает дилемму, которая, кажется, всегда существуют на предприятиях: кому подчиняется архитектурная команда: продуктовым менеджерам или менеджерам ответственным за поставку продукта?

    Резюме
    Статья оказалась длиннее, чем мы изначально планировали, поэтому завершаем ее кратким резюме из основных идей по Scaled Agile Framework (SAFe):

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

    Каких результатов ждать

    Упомянутые выше аспекты, далеко не полный список потребностей больших компаний, которые хотели бы перейти на рельсы Agile или получить от уже осуществленного перехода нечто большее, чем просто набор новых ролей и терминов.

    Авторы SAFe говорят о следующих результатах, ссылаясь на своих клиентов:
    • Сокращение времени выхода продукта на рынок на 27 недель
    • Увеличение удовлетворенности клиентов на 25 процентов
    • Сокращение расходов на разработку продукта на 50 процентов

    Наш опыт более скромен, и тем не мене, ряд клиентов, путём внедрения принципов из SAFe подхода говорят о сокращении времени на выпуск продукта на рынок до 20 процентов, а также отмечают возросшую степень прозрачности и управляемости процесса, большее удовлетворение сотрудников.

    Проведя немало дискуссий с другими консультационными фирмами и частными консультантами, мы видим похожие результаты от внедрения SAFe. Ряд наших партнеров разделяют мнение, что SAFe это не “серебряная пуля”, но позволяет решить очень много проблем в различных областях разработки ПО. Это мнение подтверждается быстро растущим списком международных компаний, которые своим примером подтверждают успешность внедрения SAFe и заставляют нас рассматривать SAFe, как один из подходов к внедрения Agile для больших организаций, у которого есть все шансы стать отраслевым стандартом.
    Ciklum
    Компания
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 3

      0
      Я вот из тех, кто всегда с удовольствием читает о новых идеях в управлении проектами.
      И, видимо, точно так же попадаю в 90% тех, кого 90% статей на эту тему удивляют.

      Scrum же начал «требовать» от руководителей PMO добиться кросс-функциональности на уровне фиксированных команд, состав которых не меняются на протяжении 6-12 месяцев.

      Даже приблизительно не могу представить себе, как методика, выросшая из Бековского манифеста может требовать фиксированности команд.

      Ну, в любом случае, чтобы прояснить:

      я правильно понимаю, что новая аббревиатура подразумевает проектную программу, в которой мы просто соглашаемся в обязательном порядке иметь такие проекты, как «Архитектурные решения (ядро?)», «Поставка контента» и «Функциональные модули» (видимо каждый предлагается оформить в отдельный проект с выделенной под него командой?)
        0
        Добрый день africaunite,

        Благодарим за Ваш комментарий и с интересом отвечаем на вопрос.

        Scrum способствовал тому, что команды разработчиков сместили свой фокус с технических решений в сторону бизнес результатов, дающие именно такие решения. Такое изменение фокуса подразумевает способность команды «обеспечить» бизнес результаты, вследствии чего появилось понятие кросс-функциональности. Попытка сделать 100% команд кросс-функциональными, с нашей точки зрения, была не совсем удачной и не представляла оптимальное решение. В условиях больших компаний, такое изменение выглядело слишком радикальным.

        И так фантазируем…
        Представьте себе, что Вы разрабатываете CRM решение и у Вас есть пять команд разработчиков. Если они все кросс-функциональные, то Вы очень свободны в выборе той команды, которая будет реализовывать тот или иной функционал. Но это идиллия. Изначально, у вас 5 команд, каждая из которых отвечает за свой модуль. Проблема и возникающие при этом вопросы в следующем: как эти команды эффективно объединить одной целью для выпуска нового релиза в срок, как быстро определить ограничения и зависимости между командами и как оптимально интегрировать решения всех команд в продукт.

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

        Надеюсь, мы ответили на Ваш вопрос и с интересом готовы продолжить общение по другим не менее актуальным и спорным вопросам.

          0
          Уважаемый ciklum_dev,

          мда…

          ну ладно я какой-то бред в вопросе написал (навеяло), но вы-то, зачем время тратили?

          спасибо!

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

      Самое читаемое