Agail что такое

Что такое agile. Объясняем простыми словами

Agile (Agile software development) — гибкий подход к разработке программного обеспечения, который часто применяют в небольших командах и больших организациях.

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

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

Agile-подходы используют разработчики Google, Netflix, Spotify и других компаний. В России об «agile-трансформации» объявил «Сбер».

В последнее время сфера использования agile расширилась и вышла за пределы IT. Теперь методику использует, например, компания Saab для производства новых истребителей.

Пример употребления на «Секрете»:

«Не работают жёсткие иерархии, изменения происходят слишком быстро, и от скорости зависит размер убытков. Работают гибкие agile-структуры и самоорганизованные команды, которым делегированы полномочия».

(Директор Школы новой экономики MACS Юрий Филатов — о трансформации бизнеса.)

Нюансы

Термином Agile называют и систему подходов к разработке, и целую философию, которая базируется на четырёх главных ценностях:

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

Факт

Agile-манифест написала группа энтузиастов-программистов в 2001 году. Сегодня это главный документ всех «гибких» разработчиков.

Обзор Agile. Что это: методология, метод или философия?

В русскоязычных книгах и статьях Agile (Аджайл) часто называют гибкой методологией разработки. Если считать методологией семейство разных методов и методик разработки программного обеспечения, то это почти правда: Agile действительно создан как обобщение разных подходов к разработке ПО. Однако …

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

Этот обзор Agile предназначен скорее для «чайников», которые начинают свое знакомство с темой. Но если вы уже знакомы с Аджайлом, используйте эту статью как навигатор: в каждом ее разделе есть ссылки для углубления: детальные статьи, учебные видео, литература.

→ Аудио-версию этой статьи вы можете прослушать на канале Listen IT

Чем Agile отличается от методологий

Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.

Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий. RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

Методология — это совокупность методов и приемов, которые используются в разных сферах деятельности.

Метод — это способ достижения какой-либо цели.

Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:

• Например, в гибкую методологию XP (экстремальное программирование) входят такие приемы как парное программирование и игра в планирование, которые указывают вполне конкретные алгоритмы действий.
• И даже гибкий фреймворк Scrum, который по определению «не является процессом, техникой или методом», все же предписывает применять несколько ролей, мероприятий и артефактов. Каждый элемент Скрама является обязательным для его успешного использования.

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

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

Показанная выше условная схема гибких подходов взята из книги Бориса Вольфсона «Гибкие методологии разработки». Этот краткий справочник по огромному числу гибких управленческих инструментов весьма неплох для своего времени (2012), когда Agile применялся лишь в той индустрии, где он появился — в разработке программного обеспечения. Если же вы не связаны с этой индустрией, для углубления читайте более современные книги без IT-специфики.

Ценности Agile простыми словами

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

1. люди,
2. работающий продукт,
3. сотрудничество с заказчиком,
4. готовность к изменениям.

Посмотрим, зачем нужны эти ценности Agile.

1. Люди и их взаимодействие важнее процессов и инструментов

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

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

2. Работающий продукт важнее исчерпывающей документации

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

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

3. Сотрудничество с заказчиком важнее согласований условий контракта

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

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

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

4. Готовность к изменениям важнее, чем следование плану

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

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

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

Agile — философия, Scrum — ее реализация

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

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

Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.

Также встречается термин «гибкий образ мышления» (от английского Agile Mindset), который означает понимание человеком ценностей Agile.

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

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

• Если Agile-мышление не свойственно людям, Scrum приводит лишь к удорожанию разработки, поскольку нужно больше времени выделять на коммуникации и обратную связь, требуются новые роли, нужны ресурсы на обучение, на повышение взаимозаменяемости сотрудников и т.д.
• И наоборот: без конкретного подхода (вроде Scrum) Agile останется лишь красивой философией — абстракцией, которую большинство людей не смогут превратить в руководство для повседневной работы.

Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.

Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.

Agile сложнее, чем 4 ценности

Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов, которые уточняют и дополняют ценности.

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

1. Потребности клиента понятны всем. Важно, что при Agile-подходе на нуждах клиента фокусируется не только бизнес и менеджер продукта, но и вся команда. То есть, каждый из разработчиков понимает: кто клиенты, что им нужно и какие их проблемы решает новый продукт. Это помогает находить более адекватные решения.
2. Процессы и оргструктуры максимально упрощены. Правила и процессы, по которым работают Agile-команды, должны быть простыми, чтобы люди смогли сфокусироваться на клиентах и на создаваемом продукте.
3. Работа короткими циклами (итерациями). Продолжительность цикла — порядка недели или месяца, за это время разработчики выдают какой-либо полезный для клиента результат.
4. Системное получение и использование обратной связи. Разработчики демонстрируют продукт заказчику, получают обратную связь на продукт и сведения об изменениях планов заказчика, затем дорабатывают, добавляют что-то полезное и так далее по циклу. Но также цикл обратной связи работает и для совершенствования самого процесса разработки: для избавления от потерь, задержек и иных препятствий, мешающих повышению производительности.
5. Максимум полномочий у исполнителей. В идеале, люди самостоятельно принимают решения и несут за них ответственность. Когда команда или даже отдельный сотрудник сам(а) может, хочет и имеет право решить какую-то проблему без ожидания действий извне, это значительно ускоряет работу.
6. Внутренняя мотивация вместо «кнута и пряника». Agile-методы помогают настроить процессы таким образом, что сотрудники становятся более свободны и счастливы на работе, видят востребованность своего труда клиентами, ценят доверие и предоставленные им возможности для саморазвития. Люди с такой внутренней мотивацией эффективнее справляются с работой, особенно если это сложная творческая работа.

Эти 6 признаков характерны для многих гибких подходов, если они правильно применяются. Рассмотрим теперь чуть подробнее, что это за гибкие подходы.

Кратко о том, что входит в Agile сегодня

К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию Agile в России, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).

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

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

Kanban — это метод повышения качества сервиса: набор принципов и практик, которые делают сервис (или разработку продукта) более быстрым и лучше соответствующим ожиданиям потребителей.

Канбан отличается от Скрама по многим параметрам, в частности:

• имеет более широкую область применения (не только новые продукты, но и поддержка, операционка);
• в отличие от Scrum, внедряется постепенно (без одномоментного изменения текущих процессов) и более просто (без изменений оргструктуры, например);
• нацелен не только на ускорение, но и на равномерность процессов;
• имеет сильно отличающиеся от Скрама метрики, не требующие оценки трудоемкости задач (например, время прохождения задачи в системе);
• отличается отсутствием фокуса на самоорганизацию команды и отсутствием прямой связи Kanban-практик с Agile-ценностями (у Канбана есть свои ценности, многие из которых вполне согласуются с ценностями Agile, например: клиентоориентированность, сотрудничество, прозрачность).

Наиболее широко применяется первая из 6 практик Kanban: визуализация процесса — в том числе, с помощью так называемой Канбан-доски. Это физическая или электронная доска со стикерами, обозначающими разные задачи. В отличие от Скрам-доски с 3-мя столбцами, в Канбане принято визуализировать на доске каждый этап процесса, а также делить каждый столбец на две части — «в работе» и «готово к следующему этапу»:

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

Речь про проблемы крупных организаций, которые вынуждены конкурировать со стартапами как по скорости вывода новых продуктов на рынок, так и по скорости принятия решений. Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России.

Отличительные особенности всех сколь-нибудь популярных в России подходов, имеющих отношение к Agile (а также к более широкому понятию Business Agility), вы можете посмотреть на одном экране, скачав нашу карту гибких подходов для бизнеса в виде картинки и в виде пригодного к печати плаката.

Область применения Agile

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

Судя по числу участников исследования Agile в России 2019, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.

Agile — это уже давно не только про разработку программного обеспечения.

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

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

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

Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:

Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из бесплатных видеоуроков про Agile (11 видео, 65 минут).

Книги об Agile по-русски

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

Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban.

Авторы: Роб Коул, Эдвард Скотчер

Книга ориентирована в первую очередь на тех, кто планирует переходить от классического проектного менеджмента к гибкому.

Эпоха Agile. Как умные компании меняются и достигают результатов.

Автор: Стивен Деннинг

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

Scrum. Революционный метод управления проектами.

Автор: Джефф Сазерленд

Книга от основателя фреймворка Scrum. В русском переводе название книги неточное (Scrum — не про управление проектами), но все равно она считается обязательной для прочтения скрам-мастерами. Книга хорошо читается и раскрывает пользу от каждого элемента Cкрама.

Scrum и Kanban: выжимаем максимум.

Авторы: Хенрик Книберг, Маттиас Скарин

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

Резюме. Место Agile среди родственных управленческих подходов

Итак, Agile — это не методология, не свод рецептов, не доски со стикерами и не стандартизованный набор встреч команды, предписанный в Scrum.

Это слово сейчас имеет два основных значения:

• Agile — это система ценностей (или образ мышления, или философия, если вам так больше нравится), которая способствует быстрой разработке новых продуктов, максимально отвечающих потребностям клиентов.
• Agile — это также собирательное название очень разных подходов к управлению разработкой, некоторые из которых даже не разделяют все 4 ценности Agile (пример — Kanban). Так уж исторически сложилось.

Agile фокусируется именно на разработке — точнее, на реализации и поставке готовых продуктов. Тогда как для генерации и проверки идей новых продуктов Agile следует дополнить различными продуктовыми подходами: Customer Development, Design Thinking и т.п.

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

1. сократить время вывода продуктов на рынок / время их поставки потребителю;
2. ускорить принятие решений на уровне команд и выше.

Для подходов к ускорению на уровне программ и портфелей проектов (в крупных организациях) грамотнее применять термин Enterprise Agility, хотя во многих контекстах их тоже относят к Agile.

Что же касается подходов к повышению гибкости/скорости принятия решений на уровне всего бизнеса, то это намного шире Agile. Так что для обозначения таких подходов следует использовать термин Business Agility, получивший распространение в конце 2010-х годов. В гибкость бизнеса входит не только быстрая поставка ценности клиентам и быстрая реакция на изменения, но также гибкость целеполагания и распределения ресурсов в организации.

Среди 12 доменов бизнес-гибкости, показанных на рисунке, Agile полностью покрывает домен «Гибкость процессов», но также связан в той или иной степени с 5-ю другими доменами, по меньшей мере.

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

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

��Что такое Agile-маркетинг и при чем тут манифест?

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

Agile-маркетинг – это современный подход, цель которого сделать маркетинг эффективнее через сокращение Time To Market (скорости запуска), увеличения ROI (возврата на инвестиции) и повышения прозрачности процессов. Также с помощью Agile-маркетинга компании могут оперативно реагировать на изменения на рынке и корректировать свою маркетинговую стратегию.

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

Agile-маркетинг, напротив, как можно быстрее доносит контент до потенциальных клиентов и позволяет понять, какой канал/контент/креатив работает лучше всего и, следовательно, приносит больше всего денег. Такой подход позволяет маркетинговым командам двигаться быстрее и результативнее как минимум на 30-40% согласно отчету McKinsey. Вот четыре ключевых отличия Agile-маркетинга от традиционного маркетинга:

— Бежим быстро (итерации)
Традиционный маркетинг состоит из серии кампаний (годовых и ежеквартальных). Акцент делается на придуманной идеи коммуникации, которую нужно детально проработать и запустить с размахом (Big Bang campaigns).

В Agile-маркетинге при работе по Scrum, команда работает короткими итерациями (спринтами) продолжительностью 1–2 недели. Акцент делается на том, чтобы создать за короткий срок «достаточно хорошую» идею, протестировать ее c помощью коммуникаций, а затем постепенно совершенствовать.

— Используем короткие циклы (инкремент)
Каждый спринт завершается инкрементом — передачей промежуточной (но уже рабочей) версии продукта, который используется для сбора обратной связи у Заказчика. На основе обратной связи появляется новый набор задач у команды на следующий спринт, тем самым начинается новый цикл.

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

-Обеспечиваем прозрачность и самоорганизацию
Agile устраняет характерные для традиционного маркетинга разобщенность и информационную изолированность (information silos). Члены небольшой кросс-функциональной agile команды разделяют всю ответственность и более автономно принимают решения.

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

-Польза для клиентов и бизнес-показатели важнее количества реализованных задач и активностей

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

-Эксперименты и обратная связь важнее заблаговременного проектирования

Маркетологи, которые стремятся сделать субъективно «идеальный» продукт (к примеру, контент план) вынуждены слишком много тратить ресурсов на процесс анализа и разработки. Agile-маркетинг учит передавать промежуточную (но уже рабочую) версию продукта, и использовать ее для сбора обратной связи у Заказчика. Тем самым, перестать галлюцинировать и не лишать себя возможности узнать, что действительно нужно клиентам, и дать им именно это.

-Тестирование и данные важнее мнений и условностей

Когда мы экспериментируем, мы собираем данные. Эти данные и полученные результаты позволяют нам принимать более эффективные маркетинговые решения. Если мы игнорируем данные и полагаемся только на чье-то мнение или устаревшие договоренности, то мы делаем совсем не, то что нужно нашей аудитории и тратим время и деньги на ненужные вещи. Agile-маркетинг – это про data-driven подход и использования цикла «Build-Measure-Learn», а не следования спонтанным решениям, на основе мнения самого высокооплачиваемого человека в офисе (HIPPO).

-Вовлеченность и прозрачность важнее официальной риторики

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

-Готовность к изменениям важнее следования изначальному плану.

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

What is Scrum?

If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time, with continuous experimentation and feedback loops along the way to learn and improve as you go. Scrum helps people and teams deliver value incrementally in a collaborative way. As an agile framework, Scrum provides just enough structure for people and teams to integrate into how they work, while adding the right practices to optimize for their specific needs. You may be thinking, that sounds great! But, how do I get started?

It starts with understanding the Scrum framework which is defined in The Scrum Guide and was first introduced to the world in 1995 as a better way of team collaboration for solving complex problems. The Scrum framework is fairly simple being made up of a Scrum Team consisting of a Product Owner, a Scrum Master and Developers, each of which have specific accountabilities. The Scrum Team takes part in five events and produces three artifacts. Scrum co-creators Ken Schwaber and Jeff Sutherland wrote and maintain The Scrum Guide, which explains Scrum clearly and succinctly. The guide contains the definition of Scrum, describing the Scrum accountabilities, events, artifacts and the guidance that binds them together.

So, why is it called Scrum? People often ask, “Is Scrum an acronym for something?” and the answer is no. It is actually inspired by a scrum in the sport of rugby. In rugby, the team comes together in what they call a scrum to work together to move the ball forward. In this context, Scrum is where the team comes together to move the product forward.

Scrum is an empirical process, where decisions are based on observation, experience and experimentation. Scrum has three pillars: transparency, inspection and adaptation. This supports the concept of working iteratively. Think of Empiricism as working through small experiments, learning from that work and adapting both what you are doing and how you are doing it as needed.

One critical Scrum Team characteristic that binds all of the elements together is Trust. If Trust is not present on a Scrum Team, there will likely be tension and bottlenecks in the way of getting work done. The Scrum Values are also critical for Scrum Teams to adhere to as they help to guide how you work and drive trust. The Scrum Values of Courage, Focus, Commitment, Respect, and Openness, are all important elements that Scrum Team members must consider when working together. The Scrum Values are particularly important in environments where experimentation is core to making progress.

In a nutshell, Scrum requires an environment where:

• Increments of valuable work are delivered in short cycles of one month or less, which are called Sprints. Ongoing feedback occurs during the Sprint, allowing for inspection and adaptation of the process and what will be delivered.
• The Scrum Team has a Scrum Master, a Product Owner and Developers, who are accountable for turning the selection of the work into an Increment of value during a Sprint.
• The Scrum Team and other members of their organization, business, users or customer-base known as stakeholders, inspect the results of the Sprint and adjust for the next one.

If this is Scrum, what is by Professional Scrum?

To be effective with Scrum requires something more than just following the mechanics and fundamentals of the framework. Sometimes Scrum Teams fall into the habit of simply going through the motions. Professional Scrum requires mindset changes for ways of working and thinking, and an environment that supports it including trust. It also requires you to embrace the Scrum Values in your work. We call this Professional Scrum.

Learn more from the Scrum Community

There are many books, presentations, videos and other resources to help you learn Scrum, but it all starts with The Scrum Guide, which is considered the definition of Scrum.

We recommend that you read insights from the experiences of Professional Scrum Trainers (PSTs) who are experts in their field as well as expertise from Scrum.org staff on the Scrum.org Blog. Articles, white papers, videos, webinars and other materials are published regularly by the community and are available in the Resources section of our website as well. Lastly, if you have questions or want to learn from what questions others have had, check out the Scrum Forum as an additional way to connect with and learn from the community.

In this 18 part series of short Scrum Tapas videos, Professional Scrum Trainer Ryan Brook walks viewers through the Scrum Framework piece-by-piece, explaining each area and providing insights into how Scrum is used.