Методология гибкой разработки SCRUM

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

Цель лекции:

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жизненный цикл проекта ПО

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

Рис. 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. Клиентские сервисы TFS

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

Рис. 16.3. Рабочий процесс элемента невыполненной работы

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

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

Рис. 16.4. Связь между рабочими элементами

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

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

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

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

Краткие итоги

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

Набор для практики

Вопросы

1. Поясните основные положения методологии Scrum.
2. Какие артефакты характерны для методологии Scrum.
3. Какие рабочие элементы определены в шаблоне MicrosoftVisualStudioScrum 2.2.
4. Поясните назначение Элементов задела работы продукта.
5. Что представляет собой спринт в методологии Scrum.
6. Какие роли определены в организации команды в методологии Scrum.
7. Кто отвечает за качественный выпуск программного продукта в методологии Scrum.
8. Поясните содержание жизненного цикл проекта ПО в методологии Scrum.
9. Поясните содержание рабочего процесса элемента невыполненной работы.
10. Поясните возможные связи между рабочими элементами.

Упражнения

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