Agile фреймворк что это

Что такое SAFe?

Узнайте о платформе SAFe, ее принципах и чем она отличается от других agile-платформ.

Автор: Jessica Piikkila

Просмотр тем

Scaled Agile Framework ® (SAFe ® ) — это набор организационных шаблонов и шаблонов рабочих процессов для реализации agile-методик в масштабе всей компании. Эта платформа представляет собой совокупность знаний, куда входят структурированное руководство по ролям и обязанностям, способы планирования работы и управления ею, а также соответствующие ценности.

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

SAFe предоставляет структурированный подход к масштабированию agile-методик по мере роста бизнеса. SAFe имеет четыре конфигурации, подходящие для различного масштаба применения: Essential SAFe, Large Solution SAFe, Portfolio SAFe и Full SAFe.

Дин Леффингвелл и Дрю Джемило выпустили платформу SAFe в 2011 году, чтобы помочь организациям разрабатывать более эффективные системы и программное обеспечение, которые лучше соответствовали бы меняющимся потребностям клиентов. В то время для поставки программного обеспечения команды использовали традиционные процессы управления проектами. Поскольку потребность в быстром реагировании на изменяющиеся условия рынка стремительно нарастала, появлялись новые платформы, помогающие бизнесу улучшать поставку решений в масштабах всей компании, в том числе и платформа SAFe. На сегодняшний день SAFe является одной из самых популярных масштабируемых agile-платформ поставки, а всемирное сообщество пользователей SAFe продолжает развивать ее.

Основные принципы и ценности

Основные ценности

Основные ценности SAFe описывают культуру, которую должно продвигать руководство, и поведение людей в этой культуре для эффективного использования данной платформы.

Соответствие

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

Встроенное качество

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

Прозрачность

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

Выполнение программы

Выполнение программы лежит в основе SAFe и поддерживает все остальное на платформе. Команды и программы должны на регулярной основе доставлять качественное, работающее программное обеспечение и коммерческую ценность.

Руководство

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

Принципы SAFe

Принципы Scaled Agile Framework предусматривают улучшение компании в целом за счет принятия гибких и бережливых решений с охватом всех функциональных и организационных единиц. Эти принципы влияют не только на решения руководителей и менеджеров, но и на решения каждого сотрудника организации; они обуславливают необходимость перехода от традиционного мышления к мышлению, опирающемуся на методы гибкого и бережливого управления, которые применяются, к примеру, в практиках Lean Portfolio Management.

Принцип № 1. Смотрите с точки зрения экономики

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

Принцип № 2. Применяйте системное мышление

Платформа SAFe создает условия для применения системного мышления в трех основных областях: собственно решение, компания, которая занимается разработкой системы, и потоки создания ценности. Решениями могут быть продукты, услуги или системы, поставляемые клиентам, как внутренним, так и внешним по отношению к предприятию.

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

Принцип № 3. Допускайте вариативность; сохраняйте варианты

По умолчанию проектирование систем и программного обеспечения является занятием с неопределенным исходом. Данный принцип решает проблему неопределенности путем введения концепции вариативного проектирования (Set-Based Design), которое требует сохранять в цикле разработки множество требований и вариантов разработки на протяжении длительного времени. Вариативное проектирование опирается на эмпирические данные, чтобы к окончательному варианту разработки можно было переходить на более поздних этапах.

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

Принцип № 4. Выполняйте инкрементальные сборки с быстрыми циклами обучения, интегрированными в процесс

Как и принцип № 3, этот принцип направлен на устранение рисков и неопределенности с помощью контрольных точек обучения. Недостаточно, чтобы работоспособность доказала каждая составляющая часть системы. Необходимо рассмотреть систему в целом, чтобы оценить возможность технической реализации текущих вариантов разработки. Чтобы ускорить циклы дальнейшего обучения, необходимо регулярно планировать последовательности точек интеграции. Эти точки интеграции являются примером цикла Уолтера Э. Шухарта планируй — делай — проверяй — корректируй, который является схемой для постоянного улучшения качества и механизмов контроля вариативности разработки. В SAFe часто используются работа Шухарта и другие работы, вдохновленные его трудами.

Принцип № 5. Контрольные точки должны основываться на объективной оценке работающих систем

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

Принцип № 6. Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей

Ограничение объема незавершенной работы помогает заинтересованным сторонам четко увидеть, как идет процесс.

Три элемента этого принципа демонстрируют основные способы максимального увеличения объема и скорости поставки ценности, т. е. реализации «потока». Как говорится, слона лучше есть по кусочкам.

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

Этот принцип служит ориентиром в оптимизации этих задач для достижения наилучших результатов.

Принцип № 7. Применяйте каденции, выполняйте синхронизацию с помощью кросс-доменного планирования

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

Принцип № 8. Раскройте внутреннюю мотивацию работников умственного труда

Этот принцип создан под влиянием идей консультанта по управлению Питера Друкера и автора Дэниела Пинка, и мы его очень любим! Речь идет о раскрытии потенциала команд и замене командно-административного мышления руководства на обучающий и помогающий подход к работе с командами.

Принцип № 9. Децентрализуйте принятие решений

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

Как работает SAFe?

Организации, готовые внедрить платформу SAFe, обычно обладают поддержкой на уровне руководства, сильным намерением измениться и фундаментом в виде scrum.

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

1. Достичь переломного момента.
2. Обучить менеджеров по организационным изменениям, которые будут использовать принципы бережливости и agile.
3. Обучить руководителей, менеджеров и ведущих специалистов.
4. Создать центр передовых технологий, соблюдающий принципы бережливости и гибкости.
5. Определить потоки создания ценности и поезда agile-релизов (ART).
6. Создать план реализации.
7. Подготовиться к запуску ART.
8. Обучить команды и запустить ART.
9. Научиться реализации ART.
10. Запустить больше ART и потоков создания ценности.
11. Расширить схему до уровня всего портфеля.
12. Поддерживать и улучшать.

Чем SAFe отличается от других масштабируемых agile-платформ?

Несмотря на то, что платформа Scaled Agile Framework® (SAFe®) широко распространена среди предприятий с большими командами разработчиков программного обеспечения, с течением времени набрали популярность и другие масштабируемые agile-платформы. Все платформы для масштабирования agile объединяют пять основных компонентов: вдохновение от 12 принципов манифеста agile-методологии, последовательность действий, синхронизация, scrum и методы качественной разработки. Понимание происхождения других платформ, основных отличий и условий их успешного применения поможет организациям выбрать структуру, которая оптимально соответствует их потребностям.

Хотите познакомиться с предысторией некоторых основных масштабируемых agile-платформ? Прочтите обзор Agile-подход при любом масштабе на странице тренера по agile.

SAFe и Scrum@Scale

В Scrum@Scale (S@S) каждый сотрудник является частью взаимозаменяемой scrum-команды. В зависимости от целей сети scrum-команд объединяются, образуя экосистему. Платформа S@S предназначена для создания сети scrum-команд с помощью «немасштабируемой архитектуры», т. е. основные роли и события scrum масштабируются линейно, без введения в процесс новых движущих сил. Например, для очень сложного продукта с 25 scrum-командами одного Scrum of Scrum (SoS) может оказаться недостаточно, и тогда понадобится Scrum of Scrum of Scrums (SoSoS) и Scrum of Scrum of Scrums Master (SoSM).

Несмотря на то что платформа S@S в целом носит менее директивный характер, для определения готовности организации к масштабированию она предлагает ответить на один наводящий вопрос: если в систему добавить больше людей, производительность резко возрастет или ухудшится?

Как и SAFe, платформа S@S предлагает справочные материалы, доступные онлайн, в том числе набирающее популярность подробное руководство Scrum@Scale.

S@S приносит наибольшую пользу, когда:

• используется объектно-ориентированный технологический стек (т. е. поставка вертикальных пользовательских историй может быть осуществлена в течение двух недель);
• функциональные команды организации имеют Т-образные навыки, продукториентированные ценности и минимальный уровень бюрократии;
• инструмент управления agile или Agile Lifecycle Management (ALM) не является обязательным, пока практика прочно не войдет в привычку;
• команда руководителей намерена применять scrum и устранять препятствия в организации.

SAFe и Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) применяет минималистический подход к ролям, структуре и артефактам. Там, где SAFe предлагает четыре конфигурации размещения все более крупных команд со все более сложными решениями, LeSS предлагает две: LeSS для организаций с 2–8 командами и LeSS Huge для организаций более чем с 8 командами. Согласно LeSS, владельцы продуктов должны обладать всеми полномочиями и стратегическим влиянием на контент, тогда как SAFe предлагает более демократичный подход. В то время как в SAFe многие факторы влияют на стратегию, LeSS опирается на клиентоориентированный подход с фокусом на клиентах, оплачивающих услуги.

Как и S@S, LeSS масштабируется на основе событий, артефактов и ролей scrum. И SAFe, и LeSS придают особое значение системному и бережливому мышлению, а также схожим руководящим принципам. Однако LeSS уделяет большое внимание сокращению отходов во всей организации с целью постоянной оптимизации.

LeSS приносит наибольшую пользу, когда:

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

SAFe и DA

В отличие от остальных описанных платформ, платформа Disciplined Agile (DA) представляет собой набор инструментов, который позволяет организациям решать, какой способ работы подходит им лучше всего. Она предлагает упрощенное agile-управление на основе scrum и kanban, а также способствующие трансформации знания в таких областях, как управление персоналом и финансами, менеджмент, DevOps, управление портфелем и многих других. DA предполагает ситуационное использование различных уровней масштабирования для каждого проекта и акцентирует внимание на том, что для определения стратегического направления необходимо создать условия для принятия решений.

DA приносит наибольшую пользу, когда:

• организации хотят определить собственный путь масштабирования agile;
• требуется сохранить гибкость по всей компании;
• нужно оставить возможность выбора процесса и (или) платформы.

SAFe и Spotify

«Модель» Spotify — это автономный набор практик с акцентом на людей, который можно применять для координации agile-команд. Она не задумывалась как модель или платформа, но некоторые компании внедрили ее именно в таком варианте. Модель Spotify ориентирована на самоорганизующиеся многофункциональные команды, расположенные в одном месте; их называют «отрядами» (эквивалент scrum-команд). Для сравнения, в SAFe нет оговорки по поводу совместного нахождения команд, которое рекомендуется для проведения PI-планирования.

Отряды организованы в более крупные подразделения, называемые «кланами». Проблемы, вызванные немногочисленными зависимостями между отрядами, при необходимости разрешаются на основе принципов Scrum of Scrums. Обмен знаниями происходит через «отделы» и «гильдии»; такие неформальные группы организуются на основе наборов навыков и интересов.

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

Spotify приносит наибольшую пользу, когда:

• идеи применяются в контексте собственного бизнеса;
• в центре организационной культуры лежит обучение, разрешение совершать ошибки и идти на контролируемые риски;
• команда и продукт «слабо связаны и тесно согласованы», что позволяет избежать конфликтов зависимости.

SAFe 5.0

Основным принципом SAFe является то, что эта платформа продолжает развиваться совместно с сообществом своих пользователей по всему миру. Совсем недавно компания Scaled Agile, Inc. выпустила SAFe версии 5.0. Основными изменениями стали добавление принципа № 10 «Организация происходит вокруг ценности» и изменение шага 12 с «Поддерживайте и улучшайте» на «Ускоряйте». На самом деле изменений гораздо больше. Хотите узнать подробности? Ознакомьтесь со статьей о том, что появилось и что изменилось в SAFe 5.0, в нашем блоге.

Заключение

Платформы типа SAFe и рассмотренных выше предоставляют компаниям экономически приемлемый способ эффективного масштабирования методики agile в организациях и достижения конечных бизнес-результатов. Но не менее важны и инструменты, которые они выбирают для укрепления существующих методов работы и реализации всех преимуществ этих методов. Используйте Jira Align от Atlassian, платформу для корпоративного agile-планирования, созданную для SAFe. С помощью Jira Align вы сможете повысить наглядность, стратегическое соответствие и адаптивность предприятия для ускорения цифрового преобразования.

Jessica Piikkila

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

Agile фреймворк что это

Это пятая статья из серии «Введение в Agile». В ней мы расскажем о самом популярном подходе в области Agile – фреймворке Scrum.

До этого мы разбирались в отличиях гибких и классических подходов к управлению, области применения Agile-подходов, характеристиках Agile-команды и способах перехода на Agile:

• Часть 1. Agile и классическое проектное управление: в чем разница?
• Часть 2. Как определить, что вашему проекту нужен Agile?
• Часть 3. Почему Agile не «внедряют», или как «вырастить» Agile?
• Часть 4. Хочу быть Agile! Но как?

Что такое фреймворк

Первый вопрос, который возникает при виде словосочетания «фреймворк Scrum»: а что такое фреймворк и чем он отличается от стандарта или методологии?

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

Немного истории

Scrum (Скрам) был разработан в 1995 году Джеффом Сазерлендом и Кеном Швабером. Перед Сазерлендом была поставлена задача: менее чем за 6 месяцев разработать замену основному программному продукту компании «Easel Corporation». Прочитав все, что смог найти о повышении производительности команд, Джефф предложил свой подход. Он объединился со своим коллегой Кеном Швабером для формализации подхода и в 1995 году Scrum был представлен всему миру.

Почему «Скрам»?

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

Преимущества Скрама

Скрам широко известен, так как его применяет большинство команд, работающих по Agile. По результатам 13-го ежегодного исследования State of Agile – 2019, Scrum остается самым популярным фреймворком. Однако следует понимать, что, как у любого подхода, у Скрама помимо сильных сторон есть и ограничения.

Среди преимуществ Скрама – четкость, простота и наличие единого официального источника информации. Все требования изложены в официальном Руководстве по Скраму (Scrum Guide) .

Ограничения Скрама

В то же время с применением Скрама связаны определенные сложности. В одной из предыдущих статей мы рассказали, что для работы в Agile нужна особая команда: небольшая, профессиональная, плоская (без иерархии и руководителей), которая сама принимает решения о способе достижения результата.

Эти же требования применимы и к командам, которые работают по Скраму: ответственность за результат в них распределена между участниками команды (у всех одна роль – «разработчик»), которые заведомо мотивированы на достижение этого результата. Этим сотрудникам не нужно каждый день ставить задачи и контролировать выполнение, они самостоятельно договариваются о том, как выстроить работу, и нацелены не на выполнение отдельных задач, а на создание законченного продукта или части такого продукта (инкремента), имеющих ценность для заказчика.

Структура фреймворка

Скрам состоит из 3 ролей, 5 событий и 3 артефактов (носителей информации о продукте). Каждый элемент Скрама взаимосвязан с другими и обязателен для применения. Общая схема фреймворка представлена на рисунке ниже. Мы кратко опишем весь процесс, а затем подробнее остановимся на каждом элементе.

Владелец продукта формирует Бэклог продукта – приоритизированный список требований. В дальнейшем Владелец продукта отвечает за соответствие разрабатываемого продукта требованиям пользователей.

Работа команды разработки делится на равные промежутки времени – спринты. Рекомендуемая длина спринта – от 1 до 4 недель. Количество спринтов не ограничивается. Проект может быть завершен когда Владелец продукта получил требуемый функционал, когда дальнейшая работа над продуктом не требуется или экономически не востребована.

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

Объем или количество требований, которые Команда может выполнить за спринт, определяется на основе опыта: в течение нескольких спринтов анализируются обязательства, которые взяла на себя Команда разработки при Планировании спринта, и фактический объем выполненных требований. Такой подход называется эмпирическим. В результате устанавливается условно-постоянный объем, который Команда стабильно прорабатывает за Спринт – производительность Команды.

После Планирования спринта запускается процесс Разработки, в ходе которого Команда разработки работает над требованиями из Бэклога спринта.

Для оперативного планирования и решения проблем ежедневно проводятся Скрам-встречи, или «летучки». На них участники Команды разработки обсуждают, что удалось сделать за прошедший день, что планируется на следующий, и какие возникли проблемы. Важная характеристика Скрам-встречи – ее жесткая ограниченность по времени. «Летучка» не должна занимать более 15 минут.

Отслеживание соблюдения ограничений процесса, помощь команде при выстраивании работы и разрешение конфликтов внутри команды – основные задачи Скрам-мастера.

После окончания Спринта проводится Обзор спринта. Это встреча, в которой могут участвовать все лица, заинтересованные в создании продукта, включая конечных пользователей и руководство организации. Цель встречи – продемонстрировать пользователям Инкремент продукта и получить обратную связь: насколько этот результат соответствует требованиям и ожиданиям. Термином «инкремент» в Скраме обозначается результат Спринта – работающий фрагмент продукта.

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

Agile (метод, методология)

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

Какие задачи решает методология Agile

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

Адаптация к меняющимся требованиям. По сути, вся методология управления проектами AGILE создана именно для этого: чтобы компания не превратилась в тяжеловесную бюрократизированную структуру, где каждое отступление от первоначального плана долго согласуется и затягивает процесс. Задачи в Agile могут меняться каждый спринт, а команда использует петли обратной связи и ретроспективы, чтобы учиться на своем опыте и улучшать процессы.

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

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

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

Манифест и принципы Agile

Манифест Agile – это перечень принципов и ценностей гибкой разработки ПО, который создала группа разработчиков в 2001 году.

Вот 4 ценности Agile:

1. Личность и взаимодействие важнее процессов и инструментов. Это означает, что Agile-команды ценят человеческое общение больше, чем жесткие процедуры;
2. Рабочее ПО важнее исчерпывающей документации. Важнее как можно быстрее предоставить заказчику функциональный продукт, чем готовить множество документов или бездумно следовать плану;
3. Сотрудничество с заказчиком важнее договора. В Agile ценится работа с заказчиком как с партнером;
4. Реагирование на изменения важнее следования плану. Способность справляться с неопределенностью и изменениями важнее, чем следование жесткому первоначальному плану.

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

1. Высший приоритет – это удовлетворение потребностей заказчика за счет создания функционального ПО;
2. Изменения требований – это хорошо, даже на поздних этапах разработки;
3. Работающее ПО нужно поставлять в короткий срок – от нескольких недель до нескольких месяцев;
4. Заказчики, менеджеры и разработчики должны ежедневно работать вместе на протяжении всего проекта;
5. Члены команды разработки в Agile должны быть высокомотивированными. Для этого им нужно обеспечить комфортные условия работы и поддержку;
6. Самый эффективный метод передачи информации в Agile-команде – это общение лицом к лицу;
7. Работающее программное обеспечение является главным мерилом прогресса;
8. Применение принципов управления проектами в Agile – залог устойчивого развития. Заказчики, спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп работы неограниченное время;
9. Нужно постоянно уделять внимание техническому совершенству и хорошему дизайну продукта;
10. Крайне важна простота, которая помогает ускорить работу и не зацикливаться на мелочах;
11. Команды должны быть самоорганизующимися. В них рождаются лучшие архитектуры, требования и проекты;
12. Команда регулярно обдумывает, как стать эффективнее, а затем корректирует свое поведение в соответствии с этим.

Авторы принципов Agile-манифеста

Этапы работы по Agile

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

Схематичное представление этапов Agile от StecPoint

Этап 1. Планирование

Заказчик составляет техническое задание – описание назначения, целей продукта, нужных результатов и сроков выполнения. Внутри команды проекта назначаются роли и распределяются обязанности. ТЗ должно быть не только четким, понятным и выполнимым, но и адаптируемым к изменениям, которые могут произойти в будущем. Часто на этом этапе Agile-проекта закладывается бэклог – список всех функций, которые нужно реализовать. Впоследствии какие-то задачи из него будут исчезать, а какие-то добавляться.

Этап 2. Проектирование

Команда разрабатывает архитектуру и дизайн продукта, используя принципы простоты, модульности и повторного использования. Это еще не разработка! Этот этап Agile-проектирования обычно включает большую исследовательскую работу: изучение целевой аудитории, создание прототипов, коммуникацию между разработчиками, Product Owner’ом и заказчиком.

Этап 3. Разработка

Всё начинается с прототипа – первого образца готового продукта, который показывает главные функции и интерфейс. Прототип может иметь низкую или высокую детализацию, в зависимости от цели и ресурсов команды. Его согласует команда и клиент, а затем прототип превращается в рабочее приложение, программу или сервис. Этап разработки в Agile делится на спринты, которые обычно длятся от 1 до 4 недель. Каждый спринт имеет свою цель и конкретные результаты, которых нужно достичь по итогу.

Этап 4. Тестирование

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

Этап 5. Обратная связь

На этом этапе методологии Agile команда получает обратную связь от заказчика и пользователей, учитывает ее и вносит необходимые изменения в продукт или бэклог. Специалисты проводят регулярные обзоры своей работы с заказчиком и демонстрируют результаты спринтов.

Этап 6. Запуск

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

Наглядная схема этапов Agile и вспомогательных элементов

Разные фреймворки в методологии AGILE

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

Scrum. Это метод организации работ со спринтами длительностью 1-2 недели. Ключевые элементы Scrum – это короткие дневные встречи, планирование спринта, ретроспектива и обзор спринта.

Kanban. В этом фреймворке делают акцент на визуализации рабочего процесса для максимизации выполняемых задач без перегрузки специалистов. Задачи обозначают карточками на специальной доске, чтобы показывать их статус и прогресс.

Реальный пример канбан-доски в компании Optimizely

DSDM. Здесь делают акцент на создании продукта в срок и в пределах бюджета, уделяя очень много внимания начальным исследованиям – реализуемости, применимости, экономической целесообразности.

Extreme Programming (XP). Это фреймворк, который ставит во главу угла скорость разработки, отзывчивость и качество кода. Он включает в себя такие инженерные практики, как написание тестов перед программированием, парное программирование и непрерывную интеграцию.

Петля планирования и обратной связи, в которой реализуются принципы управление проектами в Agile-фреймворке Extreme Programming

Роли и участники команды в AGILE

Роли в Agile-команде – это специальные функции, которые выполняют разные участники проекта. Вот основные из них:

1. Заказчик – это представитель бизнеса или клиента, который определяет требования к проекту и принимает решения о его разработке и приоритетах;
2. Владелец продукта (Product Owner) – это член Agile-команды, который отвечает за видение продукта, управление бэклогом, приоритизацию задач и повышение ценности продукта для заказчиков и юзеров;
3. Scrum-мастер или Agile-коуч – это сотрудник, который организует эффективное управление Agile-командой. Он помогает другим следовать принципам Agile-манифеста, координирует встречи и т. д.;
4. Члены команды разработки в Agile – это программисты, тестировщики, UX-дизайнеры, технические писатели и другие специалисты, которые выполняют основную работу по созданию готового продукта. Вопреки распространенному мнению, эту роль в Agile играют далеко не только разработчики;
5. Заинтересованные стороны – это люди, не входящие в команду, но имеющие интерес или влияние на результаты проекта (пользователи, менеджеры, акционеры и др.).

Если вы хотите узнать больше про роли, рекомендуем вам прочитать книгу Юргена Аппело «Agile-менеджмент. Лидерство и управление командами»

Пример внедрения AGILE

Давайте разберем пример применения методологии AGILE в конкретной компании – Ticketland. Это сервис по продаже билетов на концерты, в театры, на соревнования и т.д. В один прекрасный момент он столкнулся с рядом проблем в своей работе:

• устаревшее ПО и сложная система его замены;
• медленная разработка и наличие проблем в новых продуктах;
• сосредоточенность ключевой информации о продуктах в руках нескольких сотрудников и потеря данных при их увольнении;
• текучка среди разработчиков и др.

Для решения этих проблем Ticketland решил внедрить методологию Agile. Вот как компания применила основные принципы Agile:

• рассталась с традиционными руководителями, вместо них в каждой команде назначили и обучили Product Owner’ов;
• внедрили ретроспективы – встречи, посвященные анализу ошибок и выявлению направлений работы;
• начали оценивать предложения по фичам и функциям с финансовой точки зрения;
• приняли 3 принципа принятия новых людей в команду: наличие знаний и умений, мотивация работать именно в этой компании, соответствие ценностям компании;
• ввели кросс-дисциплину t-shape для получения знаний в смежных с основным полем деятельности сотрудника областях;
• начали рассматривать каждое обновление с точки зрения пользовательских историй;
• перешли с монолита на микросервисную архитектуру.

Переход на принципы Agile-управления позволил Ticketland решить обозначенные в самом начале проблемы, успешно нарастить штат и обороты, войдя в Forbes с оценкой компании в 84,2 млн долларов.

Разница Agile и Waterfall

AGILE и Waterfall – это противоположные подходы к управлению проектами.

Waterfall («водопад») – это традиционный метод, основанный на линейной и последовательной работе по шагам, установленным до старта проекта. Следующая стадия работы не начинается, пока не закончится предыдущая. По сравнению с Agile, Waterfall требует очень тщательного предварительного планирования и строгого соблюдения первоначального объема работ, иначе сроки рискуют непредсказуемо затянуться.

Agile отличается от Waterfall тем, что она более гибкая. В ее основе лежит не линейная работа, а итеративный обновляющийся процесс, деление проекта на более мелкие части и выполнение спринтами. Декомпозиция задач в Agile помогает гибко адаптироваться к изменениям и не так тщательно планировать все в начале.

Agile vs Waterfall на наглядной схеме от Hackr.io

Плюсы и минусы AGILE

Преимущества Agile

Гибкость при изменениях. Это главное преимущество Agile и DevOps – еще одной популярной гибкой методологии. Их часто используют вместе при разработке ПО. В Agile новые условия, вызовы или требования – это не угрозы всему проекту, а возможность совершенствоваться. Команда может быстро реагировать на действия конкурентов, изменение потребностей заказчика или рыночных условий.

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

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

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

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

Недостатки Agile

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

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

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

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

Что такое Agile-фреймворки? (Плюс как выбрать)

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

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

Что такое Agile framework?

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

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

Типы Agile-фреймворков

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

Scrum

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

Канбан

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

Scrumban

Как следует из названия, Scrumban сочетает в себе элементы Scrum и Kanban. Идея состоит в том, чтобы объединить структуру Scrum с потоком и визуализацией Kanban. Этот подход позволяет командам уделять первоочередное внимание оптимизации и согласованности. С помощью этой структуры команды стремятся получить структуру, гибкость и производительность.

Nexus

Структура Nexus предоставляет методологию планирования и управления крупными и сложными проектами разработки программного обеспечения и продуктов. Как правило, это проекты, в которых участвуют несколько Scrum-команд. Nexus позволяет командам, занимающимся различными аспектами проекта, объединить свою работу и обмениваться отзывами и другой информацией в рамках более крупной рабочей организации. Проект Nexus обычно включает в себя от трех до девяти Scrum-команд.

SAFe

Scaled Agile Framework (SAFe) представляет собой систему внедрения принципов Agile на предприятии. Команды внедряют SAFe для объединения работы многих Agile-команд в рамках большой организации. SAFe поощряет команды принимать решения на основе экономики проекта.

Как выбрать Agile-систему

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

1. Определите свои цели

Понимание желаемого результата вашего проекта — ключевой шаг в выборе Agile-фреймворка. Определите свои цели, различные требования проектов и сильные и слабые стороны каждой структуры. Эти факторы могут помочь вам принять решение.

2. Обзор потенциальных рамок

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

3. Соберите информацию от вашей команды

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

4. Решайте и внедряйте вместе

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

5. Оцените свою систему

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

Ключевые слова:

• indeed.com