Системный IT - интегратор
Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages
+7 (499) 755-54-96
info@itbconsult.ru
По будням с 9:00 до 20:00 (МСК)
ИТБ Консалтинг
+7 (499) 755-54-96

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages
МЕНЮ

SCRUM

By admin Рубрика Блог, Интересное

30

Июл
2019

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

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

Где и когда появился SCRUM

Его родоначальниками считают Хиротаку Такэути и Икудзиро Нонака, именно представили первое описание метода в своей статье Тhe New Product Development Game (Harvard Business Review, январь-февраль 1986). По их мнению, над проектами должны работать небольшие команды специалистов из разных областей. Такой подход в стиле регби дает более оптимальные результаты. ДеГрейс и Шталь в своей книге «Нечестивые проблемы, праведные решения» назвали этот метод толкотней, схваткой, а по-английски SCRUM. Так и появилось название данного подхода к управлению проектами. Хотя изначально термин SCRUM считался спортивным. Первым использовал метод SCRUM в своей компании Кен Швабер в начале 90х. Он же впервые задокументировал методологию подхода, подробно описал его и представил мировому сообществу совместно с Джефом Сазерлендом на конференции OOPSLA’95 в Остине. В дальнейшем Швабер и Сазердленд продолжили свое сотрудничество по данной теме. Они описывали свой опыт, отбирали лучшие практические примеры и включали их в свою методологию использования OOPSLA’95. Также со Швабером начал работать Майкл Билд в 2001 году, последний описал результаты данного сотрудничества в книге «Agile Software Development with SCRUM»

Все это привело в 2002 году к созданию Швабером Альянса SCRUM и серии его сертифицированных аккредитаций. В конце 2009 года Швабер покинул Альянс и основал Scrum.org, которая контролирует аккредитации Professional Scrum.

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

Базисные понятия Scrum

SCRUM (SCRibing Unified Methodology или SCRapbooking Unified Methodology или Sprint Continious Rugby Unified Methodology – это набор элементов с основой из скрайбинга и скрапбукинга, на которых строится Scrum-разработка. Последняя дает клиенту продукт, оснащенный наиболее приоритетными для клиента бизнес-возможностями. Все это происходит в кратковременных этапов или спринтов. В основу методологи легли лего-фасилитация, тактики и стратегии регби и спринта (бег на короткие дистанции). В качестве вспомогательных средств выступили артефакты и ритуалы скрайбинга и скрапбукинга. Возможности будущего спринта обсуждаются перед его началом на Sprint Planning Meeting (специальном совещании), при этом используется Planning Poker – метод планирования. Результаты совещания остаются актуальными на все время течения спринта. При этом ограниченность времени в каждом спринте позволяет процессу разработки быть гибким и предсказуемым. Итак, это определение самого Scrum. Как вы успели заметить, в нем много специфических понятий и терминов. Рассмотрим вкратце эти понятия, чтобы было понятно, о чем вообще идет речь.

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

Следующее понятие – это артефакты Scrum или диаграммы сгорания задач. Иными словам, это графическое изображение отчета о выполнении работ. График демонстрирует количество выполненных и невыполненных задач в текущем спринте.

Когда клиент обозначает свои требования к функционалу проекта, формируется список пожеланий, построенный в порядке значимости каждого требования. Каждое пожелание из списка называется пользовательской историей или элементом бэклога. Все эти элементы вносятся в журнал пожеланий клиента, который находится в свободном доступе для всех участников проекта Scrum. Project backlog ведется SCRUM Product Owner.

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

Статус каждой задачи отражается на канбан-доске (чаще электронной), состоящей из колонок (не менее 3): «сделать» (англ. to-do), «в процессе» (in progress), «сделано»(done). Для разработки ПО в  Scrum количество колонок увеличивается вместе с увеличением разновидностей статусов задач. Здесь добавляются такие колонки, как обсуждается (backlog), согласовано (ready), кодируется (coding), тестируется (testing), подтверждается (approval) и сделано (done). Также имеются канбан-карточки, прикрепляемые к соответствующей колонке. Иногда карточки могут заменяться магнитами, пластиковыми фишками, цветными шайбами или стикерами для обозначения наиболее приоритетных рабочих моментов. Каждый такой элемент обозначает этап, на котором находится реализация задачи. Соответственно, при измене статуса задачи, элемент тоже заменяется. Таким образом, Scrum-процесс производства движется по Burndown Chart вниз. Плюс ко всему, к канбан-доске и ее элементам предъявляется ряд требований:

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

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

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

Как уже говорилось ранее, требования пользователя, обозначенные в бэклоге, называют пользовательской историей, или User Story. Выглядит это примерно так: Я «тип пользователя» хочу сделать «действие», чтобы получить «результат». Благодаря такому построению требование понятно и команде разработчиков и заказчику.

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

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

  • последовательность Фибоначчи (1,2,3,5,8,13,21,34,55);
  • линейная шкала (1,2,3,4 … n);
  • двойная степень (1,2,4,8 … 2n);
  • размерный ряд одежды (XS, S, M, L, XL).

Еще к истории пользователя добавляются задачи истории спринта, или Sprint Story Tasks. Их реализация измеряется в часах, не более 12 часов на одну задачу. Однако, часто команда разработчиков старается выделить на реализацию задачи один рабочий день.

Этап разработки элемента, включенного в журнал пожеланий пользователя, обозначается критерием готовности или Definition of Done, DoD.

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

Методика Scrum предполагает использование определенных ролей в производственном процессе.  Условно эти роли обозначают как свиньи и куры. С одной стороны, такое обозначение может показаться обидным. Но на самом деле оно возникло из анекдота, в котором встретились курица и свинья. Курица предложила свинье открыть ресторан, на что последняя ответила: А как мы его назовем?». Курица подумала и сказала: Давай назовем «Яичница с беконом», на что свинья возмутилась «Нет, так не пойдет. Получается, что я полностью посвящу себя проекту, а ты только частично».

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

Итак, рассмотрим политику основных ролей в методологии Scrum более подробно. Как уже было сказано ранее, свиньи полностью вовлечены в проект. Scrum -мастер (SCRUM Master) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Таким образом, Scrum -мастер есть сервант-лидер (Servant Leader) команды.

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

Scrum -владелец продукта (SCRUM Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

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

Помимо основных ролей в  Scrum выделяют еще и дополнительные роли или Ancillary roles. По сути, мы до этого говорили о свиньях, теперь же переходим к курам. В эту группу у нас входят пользователи или Users и стекхолдеры или Stakeholders. Сразу обозначим, что стекхолдеры – это те самые заказчики проекта, которые инициируют его разработку, и для которых он будет иметь значение в дальнейшем.

В истории пользователя выделяют ряд обязательных полей:

  • ID— уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.
  • Название (Name) – краткая информация об истории пользователя. В ней должно содержаться лаконичное и однозначное описание требований, чтобы разработчики могли различать истории между собой.
  • Важность (Importance) отражает оценку важности конкретной истории на основе мнения хозяина продукта. Выражается иррациональным числом, иногда для обозначения применяют последовательность Фибоначчи. Показатель важности зависит от приоритета задачи.
  • Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов».
  • Как продемонстрировать (how to demo) – краткое описание презентации продукта в конце спринта. Данное поле может представлять собой код автоматизированного теста для приемо-сдаточного испытания.
  • Критерии приемки (acceptance criteria)— значимые детали реализации истории, уточняющие требования владельца продукта, собранные всеми участниками SCRUM-команды при планировании спринта.

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

  • Категория или track. Допустим, это панель управления или оптимизация, и они не в приоритете у владельца. Тогда с помощью поля Категория владелец может снизить приоритет данных элементов.
  • Компоненты или В данном поле можно обозначить компоненты, которые будут обработаны в процессе реализации истории.
  • Инициатор запроса (requestor) позволяет владельцу продукта сохранять информацию о своих заказчиках, которые имеют непосредственное отношение и интерес к реализуемой бизнес задаче. Это необходимо владельцу для того, чтобы заказчики всегда были осведомлены о ходе работ в процессе спринта.
  • ID в системе учета дефектов (bug tracking ID). Это все ссылки на допущенные в ходе разработок ошибки. Данное поле особенно понадобится тем, кто отслеживает ошибки в отдельной системе.

Теперь, когда мы рассмотрели большинство терминов, связанных с Scrum, поговорим о его ритуалах или совещаниях. Прежде всего, отметить что перед запуском спринта SCRUM Product Owner вносит в бэклог проекта новые пользовательские истории и удаляет завершенные. Далее проводятся совещания.

Планирование спринта (Sprint Planning Meeting)  

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

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

Покер планирования (Planning Poker)

Покер планирования представляет собой технику оценки сложности предстоящей работы или ее относительного объема. Она достигается через договоренность между заказчиком  разработчиком проекта при разработке ПО. Покер планирования проводится на совещании, описанном выше. Для его проведения необходимо заготовить набор карточек с числами 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, а также карточки со знаком вопроса и чашкой кофе. Карточка с вопросом означает, что участник совещания не понял смысла предоставляемой информации, а чашка кофе символизирует потребность в перерыве. Количество наборов карточек должно соответствовать числу участников совещания. Наборы должны быть идентичными друг другу.

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

Ежедневное стоячее SCRUM-совещание (Daily SCRUM)

  • Проводится в одном и том же месте в одно и тоже время;
  • Проводят его «свиньи», остальные могут выступать только в качестве наблюдателей;
  • Участниками митинга являются SCRUM Master, SCRUM Product Owner и SCRUM Team;
  • Длительность совещания составляет 15 минут;
  • все участники во время Daily SCRUM стоят (митинг в формате Daily Standup).

Во время совещания Scrum-мастер задает каждому участнику Scrum-команды три вопроса:

  • какие действия по достижению целей спринта ты предпринял до сегодняшнего дня?
  • Какие действия планируешь предпринять сегодня?
  • Есть ли что-то, что препятствует тебе в выполнении своих действий?

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

Скрам над скрамом (SCRUM of SCRUMs)

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

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

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

Если 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). Благодаря такой тактике можно всего за час организовать работу нескольких тысяч человек.

Порядок проведения SCRUM of SCRUMs ничем не отличается от Daily SCRUM, поэтому не будем заострять на нем внимания и двинемся дальше.

Обзор итогов спринта (Sprint review meeting)

Один из заключительных этапов спринта. Состоит из нескольких элементов:

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

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

На этом этапе бэклог отправляется на корректировку, в процессе которой Scrum-команда и владелец продукта проводят следующие манипуляции:

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

Ретроспективное совещание (Retrospective meeting)

Завершающий этап спринта, в процессе которого:

  • Участники Scrum-команды подводят итоги завершенного спринта, высказывают свое мнение о нем.
  • Scrum-мастер задает каждому участнику команды два вопроса:

— Что сделали хорошо в завершенном спринте?

— Над чем еще предстоит поработать в будущем?

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

Обучение и сертификация специалистов по SCRUM

В методе Scrum очень важно участие высококвалифицированных специалистов, мастеров и владельцев в частности. Для получения такой квалификации работникам достаточно пройти обучающие курсы с получением сертификата специалиста по Scrum. На данных курсах работники узнают всю необходимую информацию по Scrum от ее основателей и сертифицированных тренеров. В первую очередь, на данных курсах слушатели осваивают навыки Scrum-мастера. Далее идет специализация на SCRUM Master, SCRUM Product Owner и SCRUM Developer (член SCRUM Team). Успешно сдавшим экзамен выдаются сертификаты: Certified SCRUM Master (CSM), Certified SCRUM Product Owner (CSPO), Certified SCRUM Developer (CSD), Professional SCRUM Master (PSM), Professional SCRUM Product Owner (PSPO), Professional SCRUM Developer (PSD).

В будущем такой специалист тоже может стать сертифицированным тренером, пройдя соответствующий курс Certified SCRUM Trainer (CST) или Professional SCRUM Trainer (PST). К прохождению данного курса допускаются лица с сертификатами CSM или CSPO.

Сертификация PST подразумевает обучение Scrum -мастеров (PSSMT), Scrum -владельцев продукта (PSPOT) и Scrum -разработчиков (PSDT). Для допуска к курсам тренеров — train-the-trainer (TTT) и сертификации требуются:

  • на PSSMT — сертификат PSM III
  • на PSPOT — сертификаты PSM I и PSPO I
  • на PSDT — сертификаты PSM I и PSD I

 

SCRUMbut

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

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

Согласно проведенным исследованиям SCRUMbut может снижать ежегодные показатели прибыли с 400% до 0-35%. Думаю, что разница более чем очевидная. Что касается производительности, то по SCRUM она составляет 400%, а при работе по принципу SCRUMbut показатель снижается до 100%. Большое исследование причин и последствий SCRUMbut проведено в работе «ScrumBut in Professional Software Development». Данное издание наглядно и конкретно описывает все последствия неправильной или неполноценной работы по SCRUM. Да и в целом, не углубляясь в тему, можно сказать, что работая с любой методологией важно соблюдать ее принципы. Ведь эти принципы для того и разрабатывались, чтобы пользователям было легче работать по новому методу. И хотя формат нашей статьи не позволяет подробно описать все примеры SCRUMbut, озвучим самые популярные из них:

  • Нарушение графика Daily SCRUM или SCRUM of SCRUMs. Вместо того, чтобы проводить совещания ежедневно, они организуются 2-3 раза в неделю.
  • Отсутствие рестоспективного обсуждения спринта. Таким образом участники команды разработчиков упускают важные и недоработанные элементы спринта.
  • Увеличение длительности спринтов более 4 недель, следовательно, уменьшение их эффективности.
  • Отсутствие Definition Of Done.