Методология, технология Scrum (метод управления проектами)

Это руководство для разработчиков ПО и тестеров поможет понять гибкую методику SCRUM и начать работать по ней.

Узнайте базовые, но важные термины, используемые в процессе Agile Scrum вместе с реальным примером полного процесса.

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

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

Некоторые из ключевых особенностей SCRUM:

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

Чтобы хорошо понять эту методику, важно понимать ключевые термины SCRUM.

Важные термины SCRUM:

1. Scrum-команда

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

2. Спринт

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

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

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

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

4. Scrum-мастер

Scrum-мастер является координатором команды scrum. Он/она следит за тем, чтобы команда scrum была продуктивной и прогрессивной. В случае каких-либо помех scrum-мастер находит и устраняет их для команды.

5. Пользовательская история

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

Как <тип пользователя>

я хочу <доступная цель>

для достижения <результат/причина>

Например:

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

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

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

6. “Эпопеи”

Эпопеи являются неясными пользовательскими историями. Или же, можно сказать, что это пользовательские истории, которые не определены и хранятся для будущих спринтов. Просто попробуйте связать это с жизнью, представьте, что вы уходите в отпуск. Так как вы уезжаете на следующей неделе, у вас все распланировано: бронирование номера в отеле, осмотр достопримечательностей, собрана дорожная сумка др. Но что насчет вашего отпуска в следующем году? У вас есть только смутная мысль, что вы можете пойти в место XYZ, но у вас нет никакого детального плана.

“Эпопея” – она как ваш отпуск в следующем году: вы знаете, что вы можете поехать, но куда, когда и с кем – пока что нет мыслей на этот счет.

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

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

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

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

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

9. Очки за пользовательскую историю:

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

Каждой пользовательской истории определяется балл из ряда Фибоначчи (1, 2, 3, 5, 8, 13, 21). Чем выше число, тем сложнее история.

Если точнее, то

• Если вы ставите 1 / 2 / 3 очка, это означает, что история небольшая и имеет низкую сложность.
• Если вы даете 5 / 8 очков, то это средняя сложность и
• 13 и 21 очко – история очень сложная.

Здесь сложность заключается в разработке и в объеме тестовых работ

Чтобы решить, сколько очков дать, scrum-команда начинает мозговой штурм коллективно это решает. Может случиться так, что команда разработки даст конкретной истории 3 очка, потому что для них это может быть 3 строки кода замены, но команда тестирования даст 8 очков, потому что им кажется, что эта замена кода будет больше влиять на модули, поэтому объем работы при тестировании будет больше. Но сколько бы очков вы ни дали, вы должны обосновать свое решение. Таким образом, происходит мозговой штурм и команда решает, сколько очков поставить.

Всякий раз, когда вы решаете сколько очков поставить, учитывайте следующие факторы:

• Отношение истории к другим приложениям/модулям,
• Набор навыков ресурса
• Сложность истории
• Повествовательное обучение,
• Критерии приемки пользовательский историй

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

10. Диаграмма сгорания задач

Диаграмма сгорания задач представляет график, который показывает предполагаемые v/s реальных усилий задач scrum.

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

Пример: Чтобы понять это, посмотрите на рисунок:

Я выбрал:

• Двухнедельный Спринт (10 дней)
• 2 ресурса фактической работы спринта.

«История»-> колонка показывает пользовательские истории, взятые для спринта. «Задача»-> столбец показывает список задач, связанных с пользовательскими историями.

«Объем работы»-> колонка показывает объем работы. Сейчас эта мера является общим объемом работы для завершения задачи. Она не изображает объем работы какого-то конкретного человека.

«День 1 – день 10»-> – столбец (столбцы) показывает/-ют время, оставшееся до завершени истории. Обратите внимание, что это НЕ то время, что уже прошло, НО время, которое еще остается.

«Предполагаемый объем работы»-> показатель общих объема работы. Для «Старта» это просто итог всей задачи: СУММА (C5: C15)

Общий объем работы, который должен быть выполнен за 1 день, составляет 70 / 10 = 7. Таким образом, в конце первого дня объем работы должен уменьшиться до 70-7 = 63. Аналогичным образом это рассчитывается для всех дней до 10го, когда предполагаемый объем работ должен равняться нулю (строка 16)

————

«Оставшийся объем работы»-> исходя из названия, это – объем работы, оставшийся до завершения истории. Также может случиться, что фактический объем работы становится больше или меньше, чем предполагалось.

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

Этапы диаграммы сгорания задач:

1. Введите все истории (колонка A5 – А15)
2. Введите все задачи (колонка B5-B15)
3. Введите дни (1-день – 10-й день)
4. Введите начальный объем работы (суммируйте задачи C5-C15)
5. Примените формулу для расчета «предполагаемого объема работы» на каждый день (от дня 1 до дня 10). Введите формулу в D15 (с16-$C$ 16/10) и перетяните ее на все дни.
6. На каждый день введите фактический объем работы. Введите формулу в D17 (СУММА (D5:D15)) суммировать оставшийся объем работы и перетащите ее на все остальные дни.
7. Выберите это и создайте диаграмму следующим образом:

11. Скорость команды

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

Например: Для конкретного спринта: общее количество пользовательских историй – 8. Каждая из них имеет определенное количество очков

Таким образом, скорость – это сумма очков = 30

12. Определение “готово”:

История СДЕЛАНА в Scrum, только тогда, когда есть развитие, полное обеспечение качества и возможность попасть в производство.

Деятельность в SCRUM:

#1: Совещание по планированию

Совещание по планирования является отправной точкой SCRUM. Это совещание, где собирается вся scrum-команда. Владелец продукта на основе приоритета выбирает пользовательские истории из журнала пожеланий по продукту и команда начинает мозговой штурм. Во время обсуждения scrum-команда определяет сложность истории и измеряет ее согласно ряду Фибоначчи. Команда определяет задачи, а также объем работы (в часах), которые могли бы быть сделаны для завершения реализации пользовательской истории.

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

#2: Выполнение задач спринта

Исходя из названия, это работа scrum-команды для выполнения своей задачи и перемещения пользовательской истории в статус “готово”.

#3: Ежедневное scrum-совещание (звонок)

Во время цикла спринта, каждый день scrum-команда встречается не более чем на 15 минут (это может быть звонок, который рекомендуется проводить в начале дня). На собрании ставится 3 вопроса:

1. Что сделал член команды с момента прошлой встречи
2. Что член команды планирует сделать сегодня
3. Имеются ли какие-нибудь препятствия для команды

Над решением этих проблем работает Scrum-мастер. В том случае столкновения участника с любого рода трудностями, scrum-мастер помогает их решить.

#4: Обзор итогов

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

#5: Ретроспективное совещание

Ретроспективное совещание происходит после обзора итогов. SCRUM-команда собирается, обсуждает и документирует следующие моменты:

1. Что было сделано хорошо в предыдущем спринте (наилучшая практика)
2. Что было сделано не очень хорошо
3. Извлеченные из этого уроки
4. Элементы действий.

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

Как выполняется процесс? Пример!

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

Шаг #1: Представим SCRUM-команду из 9 человек, в составе которых 1 владелец, 1 Scrum-мастер, 2 тестера, 4 разработчика и 1 администратор базы данных.

Шаг #2: Спринт цикл, например, будет длиться 4 недели. Итак, у нас 1 месяц спринта: с ⁵ июня по ⁴ июля.

Шаг #3: Владелец продукта имеет приоритетный список пользовательских историй в журнале пожеланий по продукту.

Шаг #4: Группа решает провести ⁴ июня совещание «Предварительного планирования».

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

После обсуждения члены команды возвращаются на свои рабочие места и

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

Общее количество рабочих часов = 9

Минус 1 час для перерыва, минус 1 час для встреч, минус 1 час для писем, обсуждений, устранения неполадок и др.
Таким образом, фактические рабочие часы = 6

Общее количество рабочих дней во время спринта = 21 день.
Общее количество доступных часов = 21 * 6 = 126

Участник находится в отпуске 2 дня = 12 часов (это варьируется для каждого члена, некоторые могут взять отпуск, некоторые не могут.)
Количество фактических часов = 126-12 = 114 часов.

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

Шаг #5: ⁵ июня вся Scrum-команда проводит «Встречу планирования».

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

Шаг #6: После начала спринта, каждый участник команды начинает работать над назначенными задачами.

Шаг #7: Команда ежедневно встречается на 15 минут и обсуждает 3 вопроса:

• Что они делали вчера?
• Что они планируют сделать сегодня
• Есть ли какие-нибудь помехи?

Шаг #8: Scrum-мастер ежедневно отслеживает прогресс с помощью «Диаграммы сгорания задач»

Шаг #9: В случае каких-либо помех Scrum-мастер решает их.

Шаг #10: ⁴ июля команда собирается вновь для обзора итогов. Каждый член команды демонстрирует реализованную пользовательскую историю владельцу продукта.

Шаг #11: ⁵ июля команда собирается снова для ретроспективного совещания, где они обсуждают

• Что прошло хорошо?
• Что прошло не хорошо
• Элементы действий.

Шаг #12: ⁶ июля команда снова встречается для совещания предварительного планирования следующего спринта, и цикл продолжается.

(Нажмите, чтобы увеличить изображение)

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

Есть много инструментов, которые могут широко использоваться для отслеживания деятельности scrum. Вот некоторые из них:

• Jira
• XPlanner
• VersionOne
• Sprintometer
• ScrumNinja

Заключение:

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

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

Похожие статьи:

• Лучшие книги по интернет-маркетингу.
• Instagram user id.

Источник перевода