scrum less что это

Переход от Scrum к LeSS и SAFe

Скрам (Scrum) — фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов. Он работает эффективно в рамках одной команды, но при масштабировании могут возникнуть проблемы. Проект слишком большой и у владельца продукта возникают сложности с управлением бэклогом? Над проектом работает много команд и появляются проблемы с интеграцией отдельных решений? Не хватает системности и синхронизации между командами? Тогда вам следует обратить внимание на SAFe или LeSS.

Согласно 13th Annual State of Agile Report от VersionOne, SAFe является самым популярным фреймворком для масштабирования скрама — 30 % компаний используют его. LeSS используется только в 3 % случаев.

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

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

Одним из принципов LeSS является «получать большее за счёт меньшего», что значит не создавать бюрократии и обходиться без лишних ролей, процессов и артефактов.

Организация работы по LeSS

Таблица 1. Отличия LeSS от Scrum

Когда количество команд превышает 8, то требуется дополнительная структура, используется LeSS Huge:

Организация работы по LeSS Huge

Таблица 2. Отличия LeSS Huge от Less

Если LeSS является масштабированной версией Scrum, то SAFe — это комбинация Lean, Agile и DevOps. SAFe расшифровывается как Scaled Agile Framework, или масштабированный гибкий фреймворк. Это открытая база данных, на официальном сайте можно найти подробную информацию по каждому элементу SAFe — по ролям, обязанностям, артефактам и событиям, необходимым для внедрения концепции Lean-Agile в масштабе предприятия.

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

Essential SAFe

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

Portfolio SAFe

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

Large Solution SAFe

Подходит организациям, занимающимся разработкой одного большого, комплексного решения несколькими командами команд. Создаются планы работ на 12–36 месяцев, проводится анализ экономической целесообразности изменений.

Full SAFe

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

Базовая конфигурация состоит из двух уровней — уровня команды и уровня программы. На уровне команды работа осуществляется по Scrum, Kanban, XP.

На уровне программы вводятся новые роли.

Таблица 3. Роли SAFe на уровне программы

Отвечает за координацию и организацию процесса работы не отдельной команды, а программыART (Agile Release Train)Команда команд (50–125 человек), которая постепенно разрабатывает и поставляет решения в потоке ценностиSystem Architect / EngineerЧеловек, отвечающий за общее техническое и архитектурное видение разработки продукта. Нет аналога, так как в скраме сама команда отвечает за архитектуру

Используется много терминологии, связанной с поездами: ART (Agile Release Train), RTE (Release Train Engineer). Это связано с тем, что работа команд в какой-то мере похожа на работу поезда — имеется стабильное расписание. Если вы не успеваете на один поезд, то всегда можно сесть на следующий. Если в текущий инкремент не получается уместить какие-то цели, то их можно поместить в следующий.

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

Таблица 4. Сравнение этапов работы в Scrum и SAFe на уровне программы

События SAFe Essential

Заключение

В статье были рассмотрены основные отличия LeSS и SAFe от скрама. У каждого фреймворка свои особенности.

LeSS более простой и понятный. Не требует таких сильных изменений, как SAFe.

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

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

Источник

Фреймворки масштабирования Agile на компанию

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

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

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

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

И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.

Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.

Однако, бывают ситуации, когда одна команда не может обеспечить развитие продукта в требуемой темпе, ее мощности не хватает. Ведь размер команды ограничен, эффективно работает команда в 7-9 человек, а если их становится сильно больше, то необходимо дополнительное структурирование. Есть относительно простой способ нарастить команду до 15-20 человек, представленный на схеме. Это конструкция из мини-команд, каждая из которых состоит из опытного сотрудника и 1-2 стажеров, для которых опытный является наставником для стажеров. При этом операционные вопросы взаимодействия решаются командой из руководителей мини-команд.

Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.

Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.

Ответственность команды не ограничивается выполнением основных производственных задач, она имеет много планов и фокусов, и логично, когда это реализуется через отдельные организационные структуры. Это мы видели на примере Scrum of Scrum, который организует две структуры управления – продуктовую и организационную, иногда дополняемую третьей, технологической. Более сложной конструкцией является Spotify фреймворк, который заслуживает отдельного рассмотрения.

Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).

Конструкция – очень сложная и многоплановая и во многом обусловленная контекстом компании. Spotify ей делится, но с предостережением: «используйте наши опыт, но не пытайтесь тупо скопировать, оно не взлетит, мы это точно знаем, потому что у нас самих конструкция развивается и растет». Но много попыток именно механического копирования, обычно неудачных. А вот идеи заложены плодотворные.

При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkava на Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.

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

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

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

Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.

Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.

Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.

На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…

Источник

Scrum: что это и зачем нужно

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

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

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

Что такое Scrum

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

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

Однако такое «чисто процессное» определение Scrum не вполне соответствует роли этого подхода в современном управлении (на это и намекает вышеприведенное определение из Scrum Guide 2020). Scrum глубже, чем процессы.

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

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

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

Зачем нужен Scrum, и чем он отличается от прежних методологий разработки

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

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

Водопадная модель

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

— формирование первичных требований;
— анализ требований;
— оценка;
— формирование ТЗ;
— разработка;
— тестирование;
— приемка;
— поставка.

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

Итеративная модель

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

Основная проблема всех подобных методологий и методов разработки — в неполноте и несвоевременности обратной связи от клиентов. Это приемлемо для типовых продуктов, когда потребности клиентов во многом известны по прошлому опыту. Но неприемлемо в ситуации высокой неопределенности требований, которая имеет место для новых инновационных продуктов.

Фреймворк Scrum – эмпирический подход

В середине 1990-х годов Кен Швабер и Джефф Сазерленд создали фреймворк Scrum, который помогает разрабатывать новые продукты быстрее и с постоянной обратной связью от клиента. В его основе – эмпирический подход к управлению. Это означает, что видение продукта и даже процесс его разработки не детерминированы заранее, а адаптируются к данным, поступающим в ходе разработки. Это недешево, но выгоднее полной переделки неудачных продуктов, созданных по обычному детерминированному процессу в условиях неопределенности.

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

Основы работы по Scrum

Выделим 3 главные особенности процесса разработки, основанного на Scrum.

Работа ведется итерациями, которые в Scrum называют спринтами

Результатом работы может считаться лишь то, что готово к использованию

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

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

Продукт разрабатывает самоуправляемая команда

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

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

Состав Scrum-команды

Разработчики

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

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

Разработчики в Scrum не имеют каких-либо персональных обязанностей, они рассматриваются как единая команда. Вот особенности Scrum-команды, которые связаны именно с разработчиками (а не с владельцем продукта и Scrum-мастером, которые рассматриваются в следующих разделах):

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

Владелец продукта

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

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

С другой стороны, владелец продукта работает с разработчиками, отвечает на их вопросы по элементам бэклога, своевременно уведомляет об изменениях, приходящих со стороны бизнеса/клиентов. Никто не имеет право ставить задачи разработчикам в обход владельца продукта. Как член Scrum-команды, он участвует в мероприятиях Scrum: в планировании, обзоре и ретроспективе спринта.

Иногда владельца продукта путают с менеджером проекта. Это совсем не одно и то же:

Подробнее об отличиях владельца продукта и менеджера проекта смотрите в 4-минутном видео от Дмитрия Кустова:

Scrum-мастер

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

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

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

В чем заключается повседневная работа Scrum-мастера — смотрите в видео от Василия Савунова:

А как директивные руководители постепенно превращаются в Scrum-мастеров — подробно рассказывает статья Василия «От контроля к самоорганизации в команде».

Agile и Scrum: в чем разница и что общего

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

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

Основную цель Agile и Scrum часто формулируют как сокращение Time2Market — времени выпуска на рынок новых продуктов / времени их поставки потребителю.

Достижение этой цели может быть под угрозой как в силу нарушения Конституции (т.е. по причине работы вопреки 4-м ценностям и 12-ти принципам Agile), так из-за нарушения конкретных законов (например, в результате удаления из Scrum каких-либо мероприятий).

Ценности Agile:

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

Agile и Scrum: конкретный пример

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

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

Scrum предполагает встречи разработчиков с заказчиком вместо общения через документы, и на такой встрече Scrum-мастер предложил обсудить: а для какой цели вообще затевается этот проект?

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

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

В итоге, поговорив с заказчиком, разработчики предложили довольно много оптимизаций, и сообща выработали внятное видение MVP требуемого функционала. И этот MVP (Minimum Viable Product) был сделан всего за 2 недели.

Какие компании применяют Scrum

В первом десятилетии XXI века Scrum стал самым популярным среди гибких подходов к разработке новых программных продуктов. Однако сейчас фреймворк успешно используется во многих других индустриях: в материальном производстве (например, Северсталь, SOKOLOV), в маркетинговых агентствах и дизайнерских студиях, в телеком-компаниях (Tele2, МТТ), в фармакологии (BIOCAD), в розничных сетях (X5 Retail Group, МВидео) и др.

Наиболее известные в мире кейсы внедрения Agile и Scrum — Google, Amazon, Zappos.

Российские кейсы применения Scrum вы можете найти в видеозаписях докладов ежегодной конференции AgileDays от руководителей из таких компаний как UnitedTraders, Технологический Центр Дойче Банка, SEMrush, Uniscan-Research, QIWI, Банк Агророс, Додо Пицца и от десятков других.

Например, в 2016 году у компании Северсталь появилось желание ускорить выпуск на рынок новых марок стали. Изначально этот процесс занимал в среднем 2-2,5 года и иногда к моменту появления их на рынке, они часто не находили спроса, или оказывалось что конкуренты (в частности, Китай) уже закрыли потребность рынка в этой марке стали. Компания запустила первые пилотные команды для разработки продуктов по Scrum. Они оказались успешными — срок разработки новой продукции сократился с 2,5 лет до 4 месяцев.

Другие кейсы применения Agile и Scrum в российских компаниях вы можете почитать в разделе Истории клиентов.

Scrum — это не для всех

Чтобы Scrum был выгоден, нужно немало условий. В частности:

Сколько времени нужно, чтобы перейти на Scrum

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

А через год работы по Scrum, при условии постоянства состава и отсутствии непреодолимых внешних препятствий, Scrum-команда вполне может стать своеобразным «‎спецназом», самостоятельно решать проблемы и как орехи щелкать сложные задачи — в разы быстрее такой же команды до перехода на Scrum.

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

Почему работа по Scrum может быть неэффективной

Попытка внедрить Scrum там, где он не подходит

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

Неверное понимание зон ответственности

Типичный пример: владелец продукта не наделен полномочиями формировать видение и состав продукта, он скорее является бизнес-аналитиком, поэтому не может сказать «нет» заказчику.

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

Не меньше проблем бывает и с зоной ответственности Scrum-мастера.

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

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

Scrum без Agile: карго-культ Scrum

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

Другими словами, в компании есть все атрибуты Scrum: бэклог, доска, ежедневные встречи и что-то похожее на демонстрацию результата в конце спринта. Формально все вроде бы соблюдают методику, но вот про ценности Agile забывают. Дмитрий Павлов в своей статье Антипаттерны Agile-команд называет подобное поведение «Scrum-турбацией».

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

Что касается Scrum-доски:

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

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

Подробнее об Agile-ценностях и карго-культе смотрите в 5-минутном видео Артемия Анцупова:

Как правильно применять Scrum в вашей ситуации

Вы уже разобрались, как должен работать Scrum в теории? И эта статья не разубедила вас в том, что Scrum подходит вашей команде / вашей компании?

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

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

Кейсы и материалы для статьи предоставил Василий Савунов, Agile Coach, партнер ScrumTrek. Их дополнил и оформил Алексей Евдокимов, владелец продукта из ScrumTrek.

Источник