Программа последовательной реализации действий компании это

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

Содержание

В этой статье:

История Scrum

О методе узнали в 1986 года, когда в Harvard Business Review (HBR) вышла статья Хиротака Такеучи и Икудзиро Нонака «Игра в разработку нового продукта». В статье описывается, как компании Honda, Canon и Fuji-Xerox, используют командный подход в разработке продуктов. Вывод статьи был в том, что небольшие команды из специалистов различного профиля, обычно добиваются лучших результатов.

Эту идею развили, и в 1993 году Джефф Сазерленд и его команда в Easel Corporation создали метод Scrum, чтобы использовать его в разработке программного обеспечения. Ещё через два года Кен Швабер и Джефф Сазерленд написали «Руководство по Scrum». Книга подробно объясняет, что такое Scrum, в чём его преимущества, основные артефакты и принципы работы. Если вы руководитель отдела или менеджерите небольшую команду, то советуем книгу к прочтению. А если читать не хотите, но нужно быстро разобраться в чём суть подхода, не переключайтесь.

Что такое Scrum?

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

Чтобы разобраться в методе, определим действующих лиц и разберёмся с основными элементами:

Владелец продукта— клиент или заказчик. Он ставит цель перед командой и даёт список характеристик, которые хочет видеть в конечном результате. В Scrum эти характеристики называются пользовательскими историями. Это краткое описание, как выглядит выполненная цель с точки зрения пользователя.

Примеры:

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

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

Основная забота Scrum-мастера — вести команду к непрерывному совершенствованию и регулярно искать ответ на вопрос «Как нам делать ещё лучше то, что мы уже делаем хорошо?».

Джефф Сазерленд, Scrum

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

Элементы Scrum

Артефакты Scrum призваны гарантировать прозрачность и понятность ключевой информации при принятии решений.

Бэклог продукта— это список, в котором собрано всё, что нужно продукту для удовлетворения потенциальных клиентов. Его готовит владелец продукта, и задачи расставляются по приоритетам в соответствии с тем, что более и менее важно для бизнеса. Задача владельца продукта — ответить на вопросы «Что нужно сделать?» и «Что более ценно для бизнеса?».

Бэклог спринта— это подмножество элементов бэклога продукта. Команда вибирает задачи, которые выполняет в течение установленного спринта. Этапы выполнения отображаются на Scrum-досках, что делает процесс разработки видимым для всех, кто входит в проектную команду.

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

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

Рабочий процесс по Scrum выглядит так:

1. Уточнение бэклога. Владелец продукта встречается с командой, чтобы обсудить истории, находящиеся в бэклоге. Он разделяет приоритет каждой истории и определяет критерии «сделано», т. е. когда историю можно считать законченной.
2. Планирование спринта. Команда выбирает истории, которые она обязуется представить в конце спринта. Этот выбор делается с учетом приоритетов, установленных владельцем продукта.
3. Спринт. Во время спринта команда работает над разработкой пользовательских историй. В конце каждого спринта ценность историй (обычно измеряемая в очках историй) помогает оценить команду скорости. Определенное количество сюжетных очков соответствует определенному количеству часов, которые, по расчетам, потребуются команде, чтобы закончить историю.
4. Ежедневные Scrum-встречи. Scrum-мастер встречается с командой каждый день на 10-15 минут, все участники отвечает на три вопроса:
   1. Что я сделал вчера?
   2. Что я собираюсь делать сегодня?
   3. С какими препятствиями я столкнулся вчера во время работы?
5. Обзор спринта. Команда показывает владельцу продукта, что они сделали во время спринта. Как правило, эта встреча включает в себя демонстрацию новых функций, реализованных в продукте.
6. Ретроспектива спринта. Scrum-мастер встречается с командой и определяет, что команда делает хорошо, что должна делать, чтобы улучшить производительность, а что нужно прекратить.

Недостатки традиционного подхода к управлению проектами

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

Джефф Сазерленд, Scrum

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

Главные недостатки таких подходов:

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

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

Таблица: Scrum vs. Традиционный подход

Характеристика	Scrum подход	Традиционный подход
Организационная структура	Итеративная	Линейная
Масштаб проектов	Небольшие проекты	Масштабные проекты
Требования пользователя	Интерактивный ввод	Чётко определено перед внедрением
Вовлеченность владельца продукта	Высокая. Клиенты вовлечены с начала выполнения работ и в течение всего проекта	Низкая. Клиенты вовлекаются в проект на ранней стадии, но не после начала его выполнения.
Управление эскалацией	Когда возникают проблемы, вся команда работает вместе, чтобы решить их	Эскалация менеджерам при возникновении проблемы
Фокус на процессе/продукте	Меньше внимания к формальным и директивным процессам	Более серьезно относится к процессам, чем к продукту
Тестовая документация	Тесты планируются по одному спринту за раз	Комплексное планирование тестирования
Отзывы и одобрения	Обзоры делаются после каждой итерации	Чрезмерные отзывы и одобрения со стороны лидеров

Принципы работы Scrum

Хотя они официально не упоминаются в руководстве по Scrum, существует шесть принципов подхода:

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

Преимущества методологии Scrum

Сейчас Scrum считается самым надежным и популярным подходом в управлении проектами. Всё благодаря его преимуществам:

• Фокус: процессы Scrum итеративные и управляются в течение определенных рабочих периодов, что позволяет команде без усилий концентрироваться на конкретных функциях каждого спринта. Нет многозадачности и переключения внимания. Сотрудники могут работать в «потоке», а это даёт большую эффективность и качественные результаты.
• Соответствие ожиданиям: клиент устанавливает свои ожидания, демонстрируя ценность, которую приносит каждое требование или история проекта, команда оценивает их, и с помощью этих данных Владелец продукта назначает свой приоритет. Регулярно в демонстрациях спринта Владелец Продукта убеждается, что потребности были удовлетворены, и сообщает команде обратную связь.
• Гибкость к изменениям: быстрая реакция на изменения в требованиях, вызванные потребностями клиентов или развитием рынка. Методология разработана с учетом меняющихся потребностей, которые часто возникают в масштабных проектах. Высокая скорость внедрения изменений позволяет получить продукт, который точно удовлетворит потребности клиентов.
• Сокращение времени выхода на рынок: клиент может использовать наиболее важные функции проекта до того, как продукт будет полностью готов.
• Своевременный прогноз и снижение рисков: в scrum мы знаем среднюю скорость команды по спринту, также во время планирования спринта члены команды оценивают сложность выполнения задач. На основе этого можно оценить, когда конкретная задача, которая находится в работе, будет выполнена. Вероятность сорвать дедлайны снижается.

Недостатки Scrum

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

• Scrum требует подготовки. Хотя использование фреймворка Scrum потенциально может дать быстрые и качественные результаты, для его правильной реализации требуется хорошо обученная и квалифицированная команда. Прежде чем перейти к Scrum, каждый в команде должен понять преимущества и особенности этого подхода, чтобы проект был успешным.
• Сложность масштабирования. Использование подхода Scrum для крупных проектов может оказаться сложной задачей — реализация в больших масштабах требует интенсивного обучения и точной координации.
• Может потребоваться реорганизация. Принятие фреймворка Scrum иногда означает, что компании необходимо пройти некоторые организационные преобразования. Для некоторых проектов нужно, чтобы разные отделы сотрудничали и работали в команде. При этом компании необходимо организовать это сотрудничество таким образом, чтобы удобно было всем.
• Тяжело интегрировать с классическим подходом к управлению проектами. Несмотря на то, что Scrum подходит для проектов, требующих постоянных корректировок, он может не подойти для проектов, требующих предсказуемости и четкого плана. В таких случаях понадобится гибридное решение, которое включает в себя некоторые преимущества классического долгосрочного планирования и фреймворка Scrum.
• «Расползание» сроков проекта. Scrum включает в себя короткие спринты, но не предполагает никаких дедлайнов для всего проекта. Здесь все участники работают в меру своих возможностей, поэтому Владельцам продукта важно постоянно держать «руку на пульсе», чтобы не уходить от запланированных сроков.
• Работает только с небольшими командами. Методология Scrum лучше всего работает с командами, состоящими не менее чем из трех человек, но не более чем из 10. Команды с большим количеством участников сложнее координировать.
• Профессионализм членов команды. Принятие методологии Scrum предполагает длительные периоды интенсивной работы, и каждый участник должен иметь опыт и навыки, чтобы быстро и успешно выполнять задачи. Каждый в команде должен быть в состоянии выполнить и предоставить обоснованную обратную связь о результатах и общем процессе.

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

Мы уже упомянули, что Scrum сейчас считается одним из самых эффективных подходов в управлении проектами. Тогда почему, когда мы пытаемся внедрить его, то терпим неудачу? На то есть разные причины:

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

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

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

Как внедрить Scrum-методологию в организации?

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

Важность Scrum-мастера

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

Междисциплинарность. Как собрать Scrum-команду?

Следующий вопрос, на который должен ответить специалист по внедрению Scrum:
Есть ли в компании люди, которые вместе могут стать самодостаточной междисциплинарной командой?

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

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

Scrum-ритм и защита Scrum-команды

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

Коучинг и изменение мышления

Использование Scrum или других подходов Agile требует изменения мышления и привычек. Мы знаем, что мозг прибегает к старым привычкам, особенно в условиях стресса. Чтобы команда развивалась и становилась гибкой важно обучать их. Коучинг нужен больше всего в первые пару спринтов. В среднем, после 4-6 спринтов команды способны к самоорганизации и продолжают развиваться и совершенствоваться. Здесь им может понадобиться лишь небольшое руководство. Однако именно в первые несколько спринтов людям нужна поддержка, чтобы изменить свое мышление и привычки. Обычно коучингом команды занимается Scrum-мастер — ещё одна причина нанять на эту роль профессионального человека.

Пилотный переход от традиционного подхода к SCRUM может быть выполнен за 10-12 недель. Но для полноценной трансформации организации может уйти от шести месяцев до года и более.

Какие сферы применяют Scrum

Scrum наиболее популярен в сфере IT и разработки программного обеспечения. Со многими компаниями, которые работают по scrum-методу, вы регулярно взаимодействуете: Google, Apple, Facebook, Netflix.

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 называют спринтами

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

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

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

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

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

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

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

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

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

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

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

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

• Команда является «кросс-функциональной»: она должна включать всех необходимых для разработки данного продукта специалистов.
• При этом число разработчиков должно быть небольшим: до 9 человек. (А для больших продуктов есть дополняющие Scrum подходы к организации разработки одного продукта несколькими командами: например, Large-Scale Scrum.)
• В идеале, все участники команды выделены на 100% для работы по этому продукту, не отвлекаясь на что-либо другое.
• По возможности, состав команды не меняется по протяжении всей разработки продукта.
• Scrum не признает различия ролей между разработчиками, чтобы стимулировать кросс-функциональность и обмен компетенциями между ними. Это делает команду независимой от внешних специалистов и более готовой к таким неизбежным ситуациям как болезнь, отпуск или уход одного из членов команды.
• Scrum устроен так, чтобы стимулировать разработчиков работать совместно и помогать друг другу закончить каждый взятый в спринт элемент бэклога.
• Это в конечном итоге приводит к тому, что разработчики не нуждаются в руководителе (team lead), который распределял бы задачи между членами команды и контролировал бы передачу их результатов по цепочке.

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

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

•  Например, для SMS с именем-отчеством нужно было бы сделать интеграцию с базой личных данных. Было предложено вместо «Иван Васильевич» писать просто «Уважаемый клиент».
• Также в ТЗ было требование сводить в отчете вместе разные данные: базу личных данных, базу получивших SMS, базу переходов по ссылкам из 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 был выгоден, нужно немало условий. В частности:

1. Должно быть поле для экспериментов и исследований. Если задачу можно просчитать от начала до конца, а полезность результата зависит от точного выполнения плана или алгоритма, то смысла работать по Scrum нет никакого. Это просто будут неоправданные расходы на формирование выделенной под продукт команды, на Scrum-мастера, на проведение встреч этой командой и т.д.
2. Стоимость ошибки не должна быть слишком большой. Scrum изначально предполагает, что мы многого не знаем на старте и в процессе работы. Поэтому работа идет итерациями: сделали шаг, проверили наше понимание потребности заказчика, и если все хорошо, идем дальше. Если нет — переделываем. То есть, переделки заложены в самом процессе, ради быстрого движения в правильном направлении. По Scrum нельзя, например, построить ядерный реактор или сделать хирургическую операцию, так как цена ошибки будет слишком большой.
3. Заказчик должен быть готов вовлекаться в процесс и давать обратную связь. Если он просто ставит ТЗ, затем отстраняется и появляется только в конце, чтобы принять работу, то ничего не получится. Scrum построен на плотном общении с заказчиком и вовлечении его в корректировку направления движения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Нередко эта роль сохраняет функции тим-лида с распределением задач между разработчиками и контролем над их выполнением (такого человека в шутку называют «Scrum-менеджером»).
• Более частый пример: функции распределения задач у Scrum-мастера уже нет, но его «ответственность за процесс» понимается слишком буквально. Тогда Scrum-мастер организует и ведет все Scrum-встречи (включая Ежедневные Скрамы, которые должны проводиться разработчиками), всегда записывает и высылает команде их решения. А заодно и сам устраняет все препятствия: например, самолично убеждает «сложных» членов команды не саботировать ее решения.
• Наконец, некоторые организации ради экономии предлагают одному скрам-мастеру вести не менее 4-х команд.

Во всех таких случаях времени у 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.

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

Чаще всего scrum применяют в IT-разработке

Краткосрочность итераций обеспечивает предсказуемость разработки и одновременно гибкость процесса.

Scrum как часть agile

Scrum (скрам) относят к agile-подходам. Такие подходы часто называют фреймворками. Их суть состоит в использовании набора инструментов для ускоренной разработки.

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

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

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

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

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

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

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

Scrum — это фреймворк. Он определяет порядок организации процессов, однако предполагает уникальное содержание для всякого отдельного проекта. То есть изначально команда не знает, что будет делать, но знает, как это сделать. 

Как работает scrum

Как методология управления проектами, scrum предполагает, что самоорганизованная команда представляет законченный продукт в фиксированный временной отрезок (спринт).

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

Главное правило: scrum строится по принципу «3-5-3»: 3 роли, 5 событий, 3 артефакта. Если хоть один из этих элементов отсутствует, то технологию нельзя называть scrum. 

Роли scrum

Scrum-команду образуют владелец продукта, команда разработчиков и scrum-мастер. При этом разработчиками выступают маркетологи, программисты, верстальщики и иные специалисты. Это определяется потребностями разработки.  

Владелец продукта. Отвечает за общий список задач (бэклог продукта) и определяет их приоритетность.

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

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

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

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

Команда разработчиков. Команда scrum отвечает за исполнение работ из бэклога спринта. Без согласия скрам-команды никто не вправе вносить поправки в бэклог. 

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

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

Scrum-мастер. Отвечает за соблюдение командой правил и структуры работы. Он обучает остальных участников нюансам scrum-процесса и ищет  возможности оптимизировать работу. Всё общение разработчиков с людьми извне происходит через scrum -мастера.

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

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

События scrum

Основой scrum выступают спринты — чёткий ритм работы команды. Продолжительность спринта варьируется от одной до четырёх недель. Любые scrum-события связаны со спринтом. 

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

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

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

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

Планирование спринта. Команда разработчиков совместно со scrum-мастером планирует на общем собрании объём работ для предстоящего спринта и устанавливает цели. 

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

Ежедневное совещание (стендап). Краткосрочное совещание, максимум до 15 минут, проводят ежедневно. Обычно в начале рабочего дня команда подводит итоги выполненных работ, обменивается мнениями, уточняет неясные моменты. Каждый участник получает свой рабочий план на период до очередного стендапа. 

Обычно участники стендапа рассказывают: 

• Что было сделано за вчерашний день. 
• Что планируется делать сегодня.
• Какие препятствия могут возникнуть. 

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

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

На основе обзора владелец дорабатывает бэклог продукта и это может стать началом планирования последующего спринта. Без проведения обзоров работа над продуктом будет вестись «вслепую» — без учёта мнения заказчиков. 

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

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

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

Посмотрим, как будут выглядеть мероприятия у нашей бригады строителей, которая работает по scrum:

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

Далее бригада переходит к следующему этапу работ (следующий спринт) и порядок мероприятий повторяется. И так до полного завершения строительства и передачи готового дома заказчику.

Артефакты scrum

Это работы, которые надлежит сделать для завершения спринта. Они обеспечивают прозрачность проекта для всех участников. 

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

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

Бэклог спринта. В состав этого скрам-артефакта включены рабочие задачи, реализуемые в рамках спринта. 

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

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

Ну и снова наша scrum-бригада строителей. Разберём, как будут выглядеть артефакты в данном случае:

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

Как применять scrum удалённым командам

Если продукт разрабатывает удалённая команда, то ведение проекта по scrum можно организовать в специальных сервисах. Например, Scrum-доска в Jira от Atlassian позволяет объединить все данные по проекту.

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

Например, так может выглядеть скрам-доска в Jira — список задач с указанием исполнителя и срока выполнения и несколько столбцов со статусом задач:

Для решения каких задач можно использовать scrum

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

С начала 90-х гг. scrum активно применяют для таких целей, как: 

• Разработка продуктов и их улучшение.
• Исследования рынков. 
• Поддержка и регулярное обновление продуктов. 
• Поиск новых технологий. 

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

• Создание и запуск рассылки.
• Доработка писем с учётом реакции аудитории.
• Улучшение конверсии рассылки.

В конце каждого спринта будет готов полноценный продукт — макет рассылки. Но при этом письма дорабатывают: улучшают оформление текста, совершенствуют верстку email-письма, меняют содержание, добавляют или убирают различные элементы. И так до достижения конечной цели scrum-проекта — создания эффективной рассылки с высокими показателями конверсии.

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

Главные мысли

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

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

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

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

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

В отличие от классической схемы разработки, в которой все делается последовательно в соответствии с четким техзаданием, в Scrum никакого ТЗ не предполагается вовсе. Вместо него есть Backlog (бэклог) — список требований к продукту и главный источник информации для команды разработки.

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

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

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

История появления Scrum

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

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

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

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

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

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

В 2001 году они детально описали принципы своей методологии и выпустили книгу «Agile Software Development with SCRUM». На сегодняшний день этот подход считается одним из самых популярных среди разработчиков.

Базовые принципы Scrum

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

Базовые принципы Scrum:

Scrum-команда

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

Состав

В команде есть три основные роли:

Рассмотрим все роли подробнее.

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

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

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

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

Примерный перечень обязанностей владельца:

Скрам-мастер

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

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

Скрам-мастер отвечает за взаимодействие всех членов команды между собой, поддержание работоспособности на высоком уровне, устранение проблем, следованием намеченному графику работ.

Примерный перечень обязанностей скрам-мастера:

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

Разработчики — те, кто отвечают за техническую реализацию продукта. Как правило, на одну команду приходится 5-9 разработчиков. Первая задача — постановка реально достижимых, прогнозируемых, интересных и значимых целей для каждого спринта.

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

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

Примерный перечень команды разработчиков:

Принципы работы Scrum-команды

Успешная работа по методологии Scrum возможна при соблюдении трех принципов:

Процесс работы Scrum-команды

Работа команды, руководствующей методологии Scrum, условно делится на несколько этапов.

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

После этого на основе бэклога оговаривается объем работ и длительность цикла. Также заранее определяют результат: что должны получить по итогам спринта.

2. Проведение регулярных совещаний. Ежедневно или еженедельно команда проводит короткие совещания (не более 15-30 минут). В них участвуют владелец продукта, скрам-мастер и все разработчики. Цель встреч — получить от каждого ответы на три вопроса:

Scrum-мастер в ходе совещания выявляет текущие проблемы и помогает команде решить их.

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

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

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

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

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

Артефакты Scrum

Scrum-проекты включают в себя три важных документа, их еще называют артефактами:

Каждый из них имеет определенные особенности, о которых поговорим далее.

Журнал продукта

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

Бэклог продукта должен включать в себя не только технические аспекты, необходимые для реализации, но и функциональные. Для каждого требования определяется приоритет (например, от 1 до 5). Самые приоритетные описываются детально, чтобы команда смогла оценить их и протестировать.

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

Журнал спринта

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

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

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

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

График спринта

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

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

Как правильно внедрить Scrum-методологию

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

Если вы решились на изменения, проводите внедрение поэтапно:

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

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

Подведем итоги. Scrum — это методология гибкой разработки, основанная на принципах Agile. Ее разработкой занялись в 90-х годах прошлого столетия, а широкую известность она начала обретать в начале 00-х годов. На сегодняшний день скрам используют многие команды, чья деятельность тесно связана с проектами.

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

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

Ещё больше о методологиях эффективной работы команды вы узнаете, если запишетесь на наш шестимесячный онлайн-курс «Профессия: Продакт» 👉 Узнать подробности!