А был ли scrum*?

Интересные Scrum-проекты

eduScrum

То, что скрам используется не только в IT сфере, демонстрирует проект  — инициатива учителя химии в школе нидерландского городка Алфен-ан-ден-Рейн. При поддержке делового сообщества в Голландии был создан фонд eduScrum, который обучает учителей использовать скрам на уроках. Школьники, работающие в скрам-командах, учатся лучше и с большим удовольствием, чем сверстники.

Проект «Страж» для ФБР

Внедрение скрам методологии спасло от краха многомиллионный проект американского правительства — единую базу данных «Страж» для ФБР. «Страж» был второй попыткой разработать единую информационную систему для ФБР. Первая провалилась, не проработав и дня.

«Страж» начал создаваться в 2005 г. по каскадной модели. На проект было выделено 4 года и 450 млн дол. В начале пятого года компания-подрядчик выполнила половину работ и израсходовала 95% бюджета. По оценкам экспертов ей бы потребовалось еще 350 млн. и 6-8 лет для завершения проекта.

Когда в начале 2010 г. каскадную модель сменила работа в скрам-командах, производительность разработчиков увеличилась втрое и 2 июля 2012 года «Стражем» пользовались сотрудники ФБР во всех штатах.

Определения

Скрам-процессы

Scrum

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

Спринт

Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно скрам-стандарту компании Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец продукта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объёма работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта.

Журнал пожеланий проекта

Журнал пожеланий проекта (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items)

Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса.

Журнал пожеланий спринта

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

Диаграмма сгорания задач (Burndown chart)

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

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

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

Существуют два вида диаграммы:

• диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте.
• диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

Дополнительные совещания SCRUM

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

SCRUM of SCRUMs

Если коллектив больше 11 человек, то команда больше рекомендуемого SCRUM размера. Для расширения SCRUM предложена методика SCRUM of SCRUMs.

Тогда коллектив разбивается на несколько SCRUM-команд. В каждой cвой менеджер-мастер и владелец продукта.

Команды проводят Daily SCRUM.

После ежедневного совещания SCRUM проводится митинг SCRUM of SCRUMs (SoS). Это значит следующее. От каждой команды выбирается по представителю. Представители разбиваются по 5-9 человек. Каждой группе назначается главный менеджер-мастер (Chief SCRUM Master) и главный владелец продукта (Chief SCRUM Product Owner) из числа менеджер-мастеров и владельцев продукта, участвующих в проекте. Команда представителей из разных SCRUM Team называется SCRUM of SCRUMs Team. В таком составе проводят 15-минутный стоячий митинг SCRUM of SCRUMs (SoS) или Meta SCRUM или Scaled Daily SCRUM(SDS).

Кен Швабер рекомендует проводить SCRUM of SCRUMs каждый день.

Однако некоторые команды SCRUM of SCRUMs проводят не каждый день, а 2—3 раза в неделю. Это нарушает базовые принципы SCRUM и является классическим примером SCRUMbut. Это не позволяет в полной мере использовать все преимущества SCRUM.

SCRUM of SCRUMs позволяет нескольким SCRUM Teams обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Главный менеджер-мастер задает всем членам SCRUM of SCRUMs-команды четыре вопроса, три первых вопроса повторяют вопросы Daily SCRUM:

• Что каждая команда сделала с момента предыдущего совещания SCRUM of SCRUMs для достижения цели спринта?
• Что каждая команда сделает к следующему ежедневному совещанию SCRUM of SCRUMs для достижения цели спринта?
• Есть ли проблемы, мешающие команде достичь цели спринта?
• Нужно ли другой команде сделать что-то из задач вашей команды для того чтобы помочь ей достичь цели спринта?

Если SCRUM of SCRUMs не охватывает весь коллектив, может быть проведен митинг SCRUM of SCRUM of SCRUMs (SCRUM-3, SoSoS), SCRUM of SCRUM of SCRUM of SCRUMs (SCRUM-4, SoSoSoS), и так далее. Последний MetaSCRUM называется Executive Meta SCRUM(EMS) или Executive Action Team(EAT). Такой подход позволяет всего за час организовать работу 4096 человек.

Порядок проведения SCRUM of SCRUMs такой же как у Daily SCRUM —

• в одно и то же время, в одном и том же месте,
• все могут наблюдать, но только «свиньи» говорят,
• в митинге участвуют Chief SCRUM Master, Chief SCRUM Product Owner и SCRUM of SCRUMs Team,
• длится ровно 15 минут,
• все участники SCRUM of SCRUMs стоят (митинг в формате Daily Standup).

Груминг беклога (Grooming)

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

• Добавить, убрать или разбить элементы беклога продукта (PBI).
• Уточнить или дать новые оценки.
• Изменить порядок следования элементов беклога продукта.
• Обсудить и прояснить требования.

На чем стоит Scrum: роли, элементы и другое

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

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

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

Роли в Scrum

В Scrum всего 3 роли:

1. Скрам Мастер. Это бизнес-аналитик, руководитель проекта. Его задача – организовывать и проводить совещания и следить за тем, чтобы соблюдалась технология Scrum. Еще он снимает противоречия и направляет команду. 

1. Product Owner. А это уже владелец проекта, его функциональный заказчик. Он отвечает за разработку продукта и ставит задачи команде. Это всегда один человек, а не группа лиц.
2. Development Team. Команда из профильных специалистов – программистов, дизайнеров, аналитиков и т.д. Работает по принципам самоорганизации и самоуправления. Типичный размер команды – 7 человек (плюс/минус 2). За результат команда отвечает как единое целое. 

Артефакты (элементы) Scrum

В Скрам задействуется всего 4 артефакта.

Product Backlog

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

Sprint Backlog

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

Sprint Goal

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

Sprint Burndown Chart

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

Ритуалы (процессы) в Скрам

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

Sprint Planning Meeting

Это встреча по планированию спринта, на которой команда выбирает требования из Product Backlog и создает Sprint Backlog. На этой встрече Product Owner отвечает на вопросы участников команды.

Daily Meeting

Ежедневная встреча всей команды – она обязательно должна проходить каждый день, причем в одно и то же время. Интересный момент: на встрече все стоят (потому встречи еще зовут стендапами), потому длительность мероприятия не более четверти часа. В таком коротком временном промежутке каждый должен ответить на 3 вопроса:

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

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

Sprint Review

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

Retrospective

Это ритуал по обмену опытом в коллективе команды и конструктивное улучшение процесса разработки. На встрече обязательно присутствие всей команды, вместе со Скрам Мастером, а вот Product Owner сам решает – приходить или воздержаться. На встрече озвучивают ответы на ряд вопросов:

• Какие решения нужно принять, чтобы сделать процесс еще более предсказуемым?
• Какие проблемы мешают выполнять обязательства, возложенные на команду?
• Как еще лучше работать и взаимодействовать с Product Owner’ом?
• Какие ошибки допускаются в команде и почему это происходит?

История

Термин «scrum» пришёл из регби, где он означает схватку. Здесь запечатлена схватка в регбийном матче клубов «Ньюпорт» и «Лондон Уэлш» 1904 года

Подход впервые описали и в статье The New Product Development Game (Harvard Business Review, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «регбийный подход».

В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения» называли подобный подход словом «scrum» (буквальный перевод — «толкотня», в регбийной терминологии — схватка), спортивный термин, приведенный в статье Такэути и Нонакой. в начале 1990-х использовал подход, который привел SCRUM в его компанию. Впервые методология SCRUM была представлена на общее обозрение задокументированной, четко сформированной и описанной совместно Швабером и на OOPSLA’95 в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь свой опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как SCRUM. Швабер объединил усилия с в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM».

С 2009 года публичный документ под названием The Scrum Guide официально определяет Scrum. Он был пересмотрен 5 раз, с текущей версией в ноябре 2017 года. В 2018 году Schwaber и сообщество Scrum.org вместе с лидерами сообщества Kanban опубликовали Руководство по Kanban для групп Scrum.

Как закалялся scrum: происхождение и применение методологии

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

В скрам-командах ключевые позиции занимаютscrum-master и product owner,итерация начинается планированием,на котором члены команды «играют»в покер планирования,и завершается демо с ретроспективой.

Scrum методология создана американцами Джеффом Сазерлендом, исследователем и бизнес-консультантом, и Кеном Швабером, практикующим программистом, в 1993 году. В 1995 году авторы концепции официально представили ее подходы на научной конференции Ассоциации вычислительной техники в Остине, Техас.

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

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

Применение скрама в IT и не только

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

И действительно, по данным Scrum Alliance за 2016 г. 21% проектов, выполненных по скраму, не имели отношения к сфере IT. Посмотрите, какие подразделения успешно используют scrum:

Как и зачем появилась scrum-методология

До появления Scrum в мире разработки программного обеспечения было принято использовать «водопадный подход». Работа над продуктом велась по следующему плану.

1. Определить требования к продукту.
2. Спланировать весь проект от начала до конца.
3. Написать код.
4. Протестировать продукт.

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

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

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

Манифест гибкой разработки ПО 

 1. Люди важнее инструментов. 2. Качество продукта важнее документации. 3. Взаимодействие с заказчиком важнее контракта. 4. Готовность к изменениям важнее установленного плана.

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

12 принципов Agile

 1. Главное — хорошее ПО и довольный заказчик. 2. Готовность к изменениям в любой момент. 3. Полностью рабочее ПО — как можно чаще. 4. Встреча команды — лучше всего для обмена информацией. 5. Заказчик и команда разработки должны работать вместе. 6. Доверять людям делать свою работу. 7. Есть рабочее ПО — есть прогресс. 8. Гибкие процессы — непрерывное развитие. 9

Внимание к качеству способствует гибкости. 10

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

Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.

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

Счастье

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

1. Оцените свою роль в компании по шкале 1…5.
2. Оцените компанию в целом по той же шкале.
3. Почему вы так считаете.
4. Назовите вещь, которая может сделать вас счастливее в следующем спринте.

Падение уровня счастья происходит за несколько недель раньше падения динамики производительности. Следя за «индексом счастья» вы предупреждены о проблеме и сможете с нею разобраться как можно быстрее.

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

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

К чёрту тайны в команде! Все должны знать всё. Запутывание следов нужно только тем, кто ищет собственную выгоду.

История зарождения Agile

Изначально термин Agile относился к ИТ-индустрии и употреблялся в контексте гибких методологий разработки программного обеспечения: экстремального программирования (XP), Crystal Clear, DSDM, Feature driven development (FDD), Scrum, Adaptive software development, Pragmatic Programming, быстрая разработка приложений (RAD) и других адаптивных методов, суть которых состоит в ускорении процессов создания продукта путем микропланирования, коротких производственных циклов и оперативного реагирования на изменения. Ключевой смысл этих Agile-практик отражен в манифесте гибкой разработки программного обеспечения (Agile Manifesto), который был выпущен инициативной группой программистов в феврале 2001 года в американском штате Юта . Эта дата считается началом повсеместного распространения эджайл как практики управления проектами и организации бизнес-процессов не только в ИТ-отрасли, но и в других прикладных областях. Дополнительным драйвером развития Agile-подходов является микросервисная архитектура приложений, когда весь проект состоит из набора независимых слабосвязанных модулей, которые взаимодействуют друг с другом через открытые API-интерфейсы . Популярность облачных технологий (SaaS-, PaaS-, IaaS- и других сервисных моделей) также стимулирует распространение эджайл.

Книги Scrum, которые стоит прочитать

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

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

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

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

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

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

Книги по Scrum будут полезны:

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

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

В них собраны ответы на самые распространенные вопросы:

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

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

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

Здесь можно скачать лучшие книги по скраму бесплатно для ознакомления, почитать онлайн или купить полную электронную версию в форматах FB2, PDF, EPUB, TXT, DOC, MOBI.

Только легальный контент от правообладателей!

Мини-справочник Scrum

ScrumProduct Owner

• определение элементов бэклога продукта;
• правильное расположение элементов для оптимизации достижения цели;
• обеспечение понятности и прозрачности Product Backlog;
• обеспечение прозрачности и понятности требований, над которыми предстоит работать всей Scrum Team;
• общая оптимизация для достижения наибольшей ценности работы Development Team;
• ответственность за понимание бэклога командой разработки.

Scrum TeamScrum MasterDevelopment TeamStakeholdersUserProduct BacklogEpicUser StoryTaskSprintSprint GoalSprint Planning MeetingScrum PokerStory PointsDaily Scrum MeetingSprint ReviewSprint Retrospective MeetingDefinition of Done (DoD)VelocityBurndown ChartBurnup ChartAbnormal Termination