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

Аннотация: Анализируется методология Scrum, рассматриваются рабочие элементы шаблона MicrosoftVisualStudioScrum 2.2, элементы задела работы продукта, элементы работы, спринты, организация команды в методологии Scrum, жизненный цикл проекта ПО, управление работами по продукту, рабочий процесс элемента невыполненной работы, связи между рабочими элементами.

Презентацию к данной лекции Вы можете скачать .

Цель лекции:

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

Введение

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

Рабочие элементы

Рабочие элементы используются для отслеживания, наблюдения за состоянием хода разработки ПО и создания отчетов. Рабочий элемент - это запись , которая создается в Visual Studio Team Foundation Server для задания определения, назначения, приоритета и состояния элемента работы. Для шаблона MicrosoftVisualStudioScrum 2.2.определяет следующие типы рабочих элементов :

• невыполненная работа по продукту;
• ошибка;
• задача;
• препятствие;
• тестовый случай.

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

Цикл выпуска продукта в Scrum состоит из ряда итераций, которые называются спринтами . Спринт имеет фиксированную длительность, как правило, 1-4 недели. Элементы работы, включенные в очередной спринт, не подлежат изменению до его окончания. Хотя спринт завершается подготовкой работоспособного программного продукта, его текущей функциональности может быть недостаточно для оформления выпуска, имеющего ценность для заказчика. Поэтому выпуск работоспособного программного продукта, который заказчик может использовать, включает, как правило, несколько спринтов.

Организация команды

Организация команды в методологии Scrum определяет три роли :

• владелец продукта (Product owner);
• руководитель (ScrumMaster);
• члены команды (Team members).

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

• определение и приоритезация требований/функций, то есть элементов работ и задач;
• планирование спринтов и выпусков;
• тестирование требований/функций.

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

• проведение ежедневных Scrum-собраний;
• привлечение сотрудников вне команды:
• стимулирование эффективного общения членов команды;
• определение размера команды.

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

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

Инструментальная и методическая поддержка гибкого подхода к созданию программных продуктов Scrum, реализованная в VisualStudio 2012, позволяет управлять жизненным циклом проекта ПО ( рис. 16.1) .

Рис. 16.1.

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

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

Для элементов работ владелец продукта совместно с командой проекта расставляет приоритеты. При планировании спринта в него включают наиболее значимые, с точки зрения владельца продукта, пользовательские требования - ЭР, которые характеризуются наибольшей потребительской ценностью. Выбранные элементы работ перемещают в список "Незаконченная работа " (SprintBacklog). Список Незаконченная работа (НЗР) отражает состав работ планируемого спринта. Список НЗР является результатом процесса планирования спринта.

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

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

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

Управление невыполненной работой

Список Невыполненная работа по продукту является одним из ключевых артефактов в методологии Scrum. Успех Scrum-команды во многом определяется качественным содержанием данного списка. Список НВР обычно включает пользовательские описания функциональности - элементы работы, а также может включать нефункциональные требования. Для создания списка НВР в TFS могут применяться различные клиентские сервисы ( рис. 16.2):

• командный обозреватель Visual Studio;
• веб-доступ черезTeam Web Access;
• Microsoft Office Excel;
• Microsoft Office Project.

Рис. 16.2.

Владелец продукта на основе требований и пожеланий клиентов формирует список функций продукта в виде элементов задела работы продукта, которые помещает в список Невыполненная работа по продукту . При создании нового элемента невыполненной работы для него устанавливается состояние "Новый" ( рис. 16.3).

Рис. 16.3.

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

Список Невыполненная работа по продукту является главным документом для Scrum-команды. На основе данного списка команда создает другие рабочие элементы, составляющие спринты и выпуски. Для Элементов невыполненной работы команда создает задачи и тестовые случаи. Задачи детализируют элемент работы и определяют конкретную реализацию требований пользователя. Тестовые случай необходимы для проверки соответствия функциональности кода требованиям пользователя. Если тестовый случай не проходит, то создается рабочий элемент "Ошибка". При блокировании задачи из-за невозможности её выполнения в текущем спринте создают рабочий элемент "Препятствие". Scrum- команда может создавать вспомогательные рабочие элементы (ошибки и препятствия) в отношении элементов, на которые они влияют (задачи и тестовые случаи) и связывать эти элементы ( рис. 16.4).

Рис. 16.4.

Для отслеживания хода выполнения проекта, можно создавать отчеты, отражающие наиболее важные данные для текущего проекта. В процессе создания ПО можно пользоваться стандартными отчетами или создавать собственные отчеты. Отчеты можно создавать, настраивать и просматривать с помощью Excel , Project или служб Reporting ServicesSQL Server .

Методология Scrum имеет следующие положительные стороны:

• пользователи начинают видеть систему спустя всего несколько недель и могут выявлять проблемы на ранних стадиях разработки программного продукта;
• интеграция технических компонентов происходит в ходе каждого спринта и поэтому проблемы проекта (если они возникают) выявляются практически сразу;
• в каждом спринте команда фокусируется на контроле качества;
• гибкая работа с изменениями в проекте на уровне спринта.

Ключевые термины

Что представляет собой спринт в методологии Scrum.

Какие роли определены в организации команды в методологии Scrum.

Кто отвечает за качественный выпуск программного продукта в методологии Scrum.

Поясните содержание жизненного цикл проекта ПО в методологии Scrum.

Поясните содержание рабочего процесса элемента невыполненной работы.

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

Упражнения

1. Проведите исследование (поиск по интернету) применимости методологии Scrumдля проектирования программных систем.
2. Проанализируйте причины распространения методологии Scrum для создания эффективных программных решений.
3. Проведите исследование (поиск по интернет) программного инструментария методологии Scrum для платформ отличных от Microsoft.Net.

Что такое Scrum методология? Как ее применять в разработке и не только? Почему гибкость не всегда хороша?

Учеба продолжается, три раза в неделю я знакомлюсь с новыми знаниями из области разработки и понимания digital продуктов изнутри. Для маркетолога, это новый мир. Ты слышишь про какой-то там Agile, понимаешь, что связано это с разработкой и вполне можешь поддержать беседу в общих красках. Но как только дело доходит до деталей, “поплыл”.

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

Что такое Scrum

Scrum – гибкая методология разработки или гибкий управленческий фреймворк (т.е. структура) с акцентом на качество процессов.

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

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

Как Scrum устроен на самом деле смотрите ниже.

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

Структура Scrum

Давайте посмотрим из каких элементов состоит Scrum.

Роли

• Владелец продукта (product owner/manager). Ставит задачу, определяет приоритеты по задачам, взаимодействует с заказчиком.
• Скрам-мастер – человек, который отвечает за процессы внутри команды, координирует работу, следит за внутренней атмосферой. Планирует спринт, организует скрам митинг, участвует в демонстрации результатов в конце каждого спринта.

Скрам митинг – ежедневная планерка, летучка, где разбирается ход работы спринта. Что сделали, есть ли проблемы, что планируется сделать. Не более 15 минут на собрание. Все участники команды должны высказаться. Скрам-мастер следит за таймингом и выступлением каждого.

• Команда – 7±2 человек, которые реализуют требования владельца продукта.

Артефакты

• Беклог продукта. Список требований с расставленными приоритетами и трудозатратами.
• Беклог спринта. Часть беклога спринта, то есть несколько задач, которые реально уместить в один спринт.
• Инкремент продукта. Готовая часть продукта для демонстрации. В digital проектах, это может быть функциональность. К примеру, рабочая форма регистрации на сайте, которую можно показать.

Процессы

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

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал . Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Пример Scrum

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

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

Выбираем, для примера, важную задачу или историю пользователя (user story) в рамках создания сайта: “Регистрация клиента/пользователя”. И раскладываем ее на более мелкие части. Формируем беклог продукта.

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

На практике, историй пользователя (типа “Регистрация пользователя”) гораздо больше. Сервис/продукт может включать множество таких историй, поэтому приоритезация строится сверху вниз, слева направо. В верхней левой части располагаются самые важные user story (Активность) и самые важные задачи.

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

Понятно, что управлять такой “махиной” в реальном времени просто невозможно, поэтому для удобства работы, вся эта стена переезжает в специальный софт/программу (Jira, Trello, Redmine и прочие трекеры управления проектами). Там вы можете назначать ответственных за задачи и исполнителей, изменять статусы задач и прочее.

Стена работает тоже хорошо, так как на этапе создания вся команда увлечена и чувствует свой вклад в общее дело. Но после ее нужно перенести в подходящий инструмент.

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

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

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

Ретроспектива: анализ спринта

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

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

Как расставлять приоритеты

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

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

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

Оценка историй пользователей внутри беклога

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

Мы берем одну user story из беклога за образец и присваиваем ей ценность единицу (story point). Дальше оцениваем другие истории пользователя с точки зрения выбранной.

Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.

В примере выше “Фото галерея с довольными клиентами” стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.

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

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

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

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

Можно ли применять Scrum не только в разработке

И да и нет. До того, как я начал понимать, что означают эти 5 букв (Scrum), часть принципов уже использовал в работе. Планирование, с помощью различных инструментов и выстраивание своего так называемого “спринта задач” уже было.

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

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

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

Когда применять Scrum

В основном в небольших проектах и старт-апах. Можно и в больших, типа Mail.ru, но там должна быть определенная свобода действий и отдельные функциональные команды со своим владельцем продукта. Не забывайте, что Scrum про гибкость и изменения. Команды не должны быть больше 7±2 человек, иначе невозможно будет эффективно организовать коммуникации.

Нюансы

Если вы решили внедрить Scrum у себя в проектах, то учитываете следующие нюансы:

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

Завершим

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

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

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

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

• Владелец продукта (Product owner) представляет интересы конечного пользователя.
• Скрам-мастер (Scrum master) следит за соблюдением принципов Scrum-разработки, координирует процесс, проводит ежедневные собрания (Scrum Meetings) .
• Скрам-команда (Scrum team) участвует в разработке продукта. В скрам-команду входят программисты, тестировщики, аналитики и прочие специалисты.

Итак, давайте рассмотрим основные этапы разработки, характерные для Scrum.

Шаг 1. Создание бэклога продукта

Бэклог продукта (Product backlog) представляет собой упорядоченный по степени важности список требований, предъявляемых к разрабатываемому продукту. Элементы этого списка называются Пользовательскими историями (User story). Каждой истории соответствует уникальный ID. Вот пример пользовательских историй из бэклога продукта, использованного во время работы над XB Staff Manager :

ID	User Story
a-001	Как менеджер, я хочу добавлять, удалять, редактировать задачи, чтобы управлять занятостью сотрудников
a-002	Как менеджер, я хочу добавлять новые задачи и изменять продолжительность, а также конечную и начальную даты текущих задач с помощью drag-and-drop
a-003	Как менеджер, я хочу назначать сотрудникам 2 типа задач: -Part-time task -Full-time task чтобы обозначить постоянную/временную занятость сотрудника

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

• Важность (Importance) . Степень важности задачи по мнению владельца продукта. Описывается произвольным числом.
• Предварительная оценка (Initial estimate) . Предварительная оценка объема работ. Измеряется в story point’ах.
• Как продемонстрировать (How to demo) . Описание способа демонстрации завершенной задачи.

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

• Категория (Track) служит для того, чтобы владелец продукта мог выбрать все пункты определенной категории и установить им низкий или высокий приоритет. Примером такой категории может быть «Панель управления».
• Компоненты (Components) состоит из списка компонентов продукта, которые будут изменены во время работы над историей. Такими компонентами могут быть модули приложения, как например, аутентификация или поиск.
• Инициатор запроса (Requestor) -заказчик, заинтересованный в реализации определенной функциональности. Это поле необходимо, если нужно держать заказчика в курсе текущего положения дел.
• ID в системе учёта дефектов (Bug tracking ID) содержит ссылки на обнаруженные дефекты, относящиеся к истории с определенным ID.

После того, как составлен бэклог проекта, можно приступить к следующему шагу — планированию спринта.

Шаг 2. Планирование спринта и создание Бэклога спринта

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

Во время планирования спринта команда выбирает самые приоритетные пользовательские истории из бэклога продукта и решает, каким образом будут решаться поставленные задачи. Истории, выбранные для реализации в течение данного спринта составляют Бэклог спринта (Sprint backlog) . Количество историй, попадающих в бэклог спринта зависит от их длительности в story point’ах, присвоенных каждой истории на этапе предварительной оценки. Это количество выбирается так, чтобы каждая история была успешно реализована к концу спринта.

Шаг 3. Работа над спринтом. Scrum meetings

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

Для визуализации процесса разработки удобно использовать учетные карточки. Они могут иметь вид больших карточек с названием конкретной истории и маленьких стикеров, описывающих отдельные задачи, необходимые для реализации истории. После начала работы над определенной задачей, ее стикер перемещается из поля «Запланировано» в область «В работе». По завершении работы над задачей, стикер перемещается в поле «Тестирование» и затем, при успешном выполнении тестирования, в поле «Готово». Расположив истории согласно их важности, можно получить представление о текущем состоянии проекта:

Также может быть использовано программное обеспечение, предназначенное для такого рода задач. Примером такого ПО может служить, например, Atlassian JIRA .

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

Результатом каждого совещания также является burndown-диаграмма . По оси X на ней откладываются дни работы над спринтом, а по оси Y — общее количество story points для данного спринта. После завершения задачи, требовавшей определенного количества story points для ее решения, можно отметить на диаграмме точку, в которой на данный момент находится проект. Пример такой диаграммы, построенной в JIRA, приведен ниже:

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

Шаг 4. Тестирование и демонстрация продукта

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

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

Шаг 5. Ретроспектива. Планирование следующего спринта

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

Заключение

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

The following two tabs change content below.

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

Scrum (Скрам) — это не аббревиатура, этот термин взят из регби, который обозначает схватку вокруг мяча.

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

Основные термины, которые используются в методологии:

Владелец продукта (Product owner) — человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как это продукт должен выглядеть/работать. Этот человек не работает в команде, он работает на стороне заказчика/клиента (это может быть как другая компания, так и другой отдел), но этот человек работает с командой. И это тот человек, который расставляет приоритеты для задач.

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

Scrum-команда — это команда, которая принимает все принципы Scrum и готова с ними работать.

Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность определяется командой один раз).

Бэклог (backlog) — это список всех работ. Можно сказать, что это ежедневник общего пользования 🙂

Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог.

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

Спринт-бэклог — это список работ, который определила команда и согласовала с Владельцем продукта, на ближайший отчетный период (спринт). Задания в спринт-бэклог берутся из product-бэклога.

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

Попробую объяснить все это на примере работы PR-агентства, как бы это могло выглядеть, если бы они работали по Scrum.

Компания клиент «Икс» хочет провести через 2 месяца масштабное мероприятие для своих партнеров и журналистов. Услуги по организации такого мероприятия компания «Икс» заказала у агентства «Зет». Компанию «Икс» представляет PR-менеджер, который отвечает за организацию мероприятия со стороны клиента. В терминологии Scrum — этот человек называется Владелец продукта . Со стороны агентства за организацию мероприятия отвечает account-менеджер (Scrum-мастер ), в подчинении которого находится команда (Scrum-команда ). На совместном совещании (планировании спринта ) компания и агентство решают, что они будут отчитываться-планировать каждые 2 недели (длина спринта ). На первые 2 недели они запланировали список задач (спринт-бэклог ), однако команда оценила, что не все из этого списка они успеют выполнить. Тогда PR-менеджер (он же Владелец продукта ), говорит какие из этого списка задач более приоритетные на ближайшие 2 недели, после чего команда берется за выполнение заданий. Единственное что здесь должно быть учтено, что на момент планирования первого спринта должен быть спланирован весь список заданий на 2 месяца (product-бэклог ), чтобы не получилось так, что к моменту проведения мероприятия что-то не выполнено.

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

Scrum на простом языке

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

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

Основные принципы организации работы в Scrum командах

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

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

2. Требования разбиваем на небольшие, ориентированные на пользователей, функциональные части, которые максимально независимы друг от друга, в результате чего мы получим беклог продукта. Затем упорядочите элементы беклога по их важности и произведите относительную оценку объемов каждой истории. Выделите отдельного человека – владельца продукта, который будет отвечать за требования и их приоритеты, замыкая на себя всех заинтересованных лиц.
3. Всю работу ведем короткими от 1 до 4 недель фиксированными итерациями – спринтами, поставляя в конце каждого из них законченный функционал, который можно при необходимости вывести на рынок – инкремент продукта . Команда согласно своей скорости набирает задачи на неизменяемую по времени итерацию – спринт. Каждый день проводится скрам-митинг, на котором команда синхронизирует свою работу и обсуждает проблемы. В процессе работы члены команды берут в работу элементы беклога согласно приоритету.
   

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

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