Методология SCRUM. Обзор и сравнительный анализ с другими методологиями разработки ПО

+

Оглавление

 

 

Определение

 

 

 

 

Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.

Обзор методологии SCRUM

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

SCRUM (по-русски читается СКРАМ) — методология управления процессом для гибкой разработки программного обеспечения. 
Для лучшего понимания методологии пройдем последовательно по этапам создания программного продукта согласно методологии SCRUM.

 

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

На встрече с клиентом определяется концепция и список требований к функциональности продукта. При этом все требования описаны на понятном для заказчика языке. На основании этого Product Owner — человек, который представляет интересы заказчика, составляет Product Backlog — список требований к функциональности, упорядоченный по степени важности так, чтобы в первую очередь были реализованы наиболее ценные для бизнеса заказчика возможности. Product Backlog должен быть ориентирован на бизнес, т.е. на то “что надо”, а не на то “как сделать”.

 Затем список  обсуждается с командой (Scrum Team) для оценки объема работ.

В результате у каждого элемента Backlog'а должны быть заполнены следующие поля:

• ID – уникальный идентификатор – порядковый номер.

• Название – краткое описание. Должно быть однозначным, чтобы разработчики и product owner могли примерно понять, о чем идет речь, и отличить один элемент Backlog'а от другого. Обычно от 2 до 10 слов.

• Важность (Importance) – степень важности, по мнению product owner'а., Например, 10. Или 150. Чем больше значение, тем выше важность.

• Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации элемента Backlog'а. Приблизительно соответствует числу “идеальных человеко-дней”.

• Как продемонстрировать (how to demo) – краткое пояснение того, как завершённый элемент Backlog'а будет продемонстрирована в конце спринта. По сути, это простой тестовый сценарий типа “Сделайте это, сделайте то – должно получиться то-то”.

• Примечания – любая другая информация: пояснения, ссылки на дополнительные источники информации, и т.д.

Официально документ принадлежит product owner’у, однако другим членам команды разрешается его редактировать. 
У каждого продукта должен быть только один product backlog и только один product owner. 
Все наиболее важные элементы Backlog'а должны быть классифицированы по уровню важности, а их числовые значения не должны совпадать. 
Product owner должен понимать каждый элемент Backlog'а. 
 
Примечание: Хотя заинтересованные лица могут добавлять требования в product backlog, они не имеют права присваивать им уровень важности. Это прерогатива product owner’а. Они также не могут добавлять оценки трудозатрат, поскольку это прерогатива команды.

Весь процесс разработки продукта в SCRUM разбит на итерации, называемые СПРИНТами. Продолжительность итерации 1 — 4 недели.

 
Перед каждой итерацией производится планирование спринта. 
Задачи планирования спринта – это определение цели спринта, выбор требований из Product Backlog'а для перемещения их в Sprint backlog, определение даты демонстрации (или длины спринта), определение команды, реализующей спринт. По окончании спринта на выходе должна быть работающая программа, которую владелец продукта может попробовать своими руками. 
Цель спринта должна отвечать на главный вопрос “Зачем команда работает над этим спринтом”? 
Sprint backlog – это список верхних элементов элементов из Product Backlog'а, которые команда обязалась выполнить в течение спринта. 
Дата демо — дата окончания спринта, дата демонстрации работающего функционала. 
Важно, чтобы и product owner, и команда совместными усилиями определили критерий готовности элемента Backlog'а. 
Каждый элемент Sprint backlog'а может быть разбит на задачи. Разница между “задачами” и “элементами Backlog'а” в том, что элементы Backlog'а это нечто, что можно продемонстрировать, что представляет ценность для product owner’а, а задачи либо нельзя продемонстрировать, либо они не представляют ценности для product owner’a. 
Также во время планирования спринта определяются время и место проведения ежедневных Scrum-митингов. 
Scrum-митинг — ежедневная короткая встреча команды, где каждый участник разработки отчитывается, что он сделал вчера, что должен сделать сегодня, какие проблемы у него возникли. В ходе общей встречи ищутся способы разрешения этих проблем. Задача Scrum Master’a (лидера команды) — состоит в том, чтобы предоставить команде все возможности для реализации выбранных задач, но не диктовать, что должен делать каждый участник разработки. 
Scrum Master контролирует продвижение работ. 
Эффективный инструмент для этого — доска задач. Доска задач состоит из трех колонок: “В планах”, “В процессе”, “Готово”. 
Для иллюстрации мы взяли картинки из книги Хенрика Книберга “SCRUM и XP: заметки с передовой”.

При старте спринта все задачи находятся в колонке “В планах”. После первого ежедневного Scrum'a доска задач может выглядеть примерно так:

Через пару дней доска задач может выглядеть примерно так:

Кроме доски задач Scrum Master создает burndown-диаграмму (ее видно на рисунках справа). 
Burndown-диаграмма создается следующим образом:

• по оси Y отмечается прогнозируемый объем работ в story-point'ах.

• по оси Х даты до дня демонстрации. Выходные дни при этом лучше пропустить.

После окончания каждого Scrum-митинга Scrum Master отмечает на burndown-диаграмме точку, в которой находится команда.

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

При обнаружении отклонений Scrum Master принимает меры. 
По завершению спринта проводится демонстрация продукта Product owner'у.

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

Сравнение методологий.

Scrum более директивный, чем Kanban

Можно сравнить инструменты по количеству предписываемых правил, которое в них содержится. Директивный означает "содержащий больше правил, которым надо следовать", a адаптивный – "содержащий меньше правил". При 100%-но директивном подходе вам не придется напрягать свой мозг, есть правила для всего. А при 100%-й адаптивности – "Делай что хочешь", тут не существует никаких правил и ограничений. Как видите, обе крайности выглядят весьма нелепо. Agile-методы иногда называют легковесными, в частности, потому что они менее директивны, чем традиционные методы. В самом деле, первый принцип Agile-Манифеста гласит "Люди и взаимодействие важнее процессов и инструментов". Scrum и Kanban являются высоко адаптивными, но, если их сравнить, то Scrum более директивен, нежели Kanban. Scrum предоставляет вам больше ограничений, и, таким образом, оставляет меньше вариантов для выбора. Например, Scrum предписывает использование фиксированных по времени итераций, Kanban – нет. Давайте сравним несколько инструментов процесса на шкале "предписание/адаптация":

RUP – очень даже директивный  метод, – насчитывает более 30 ролей, более 20 мероприятий и более 70 артефактов; просто куча всего для изучения. Вы конечно не должны использовать  все, предполагается выбор какого-то  подмножества для конкретного  проекта. К сожалению, на практике  это не просто. "Хм ... потребуются  ли нам результаты проверки  инфраструктуры? Потребуется ли  нам роль Менеджера по управлению  изменениями? Давайте просто оставим  на всякий случай." Это может  быть одной из причин, почему RUP-реализации  часто оказываются довольно тяжеловесными  по сравнению с Agile-методами, такими  как Scrum и XP. XP (eXtreme Programming) – намного  более директивен по сравнению  со Scrum-ом. Эта методология включает  в себя большую часть Scrum-а + кучу  весьма конкретных инженерных  практик, таких как TDD (разработка  через тестирование) и парное  программирование. Scrum менее директивный, чем XP, так как он не навязывает  использование никакой конкретной  инженерной практики. Scrum более директивный, чем Kanban, поскольку он предусматривает  такие вещи, как итерации и кросс-функциональные команды. Одно из основных различий между Scrum и RUP в том, что в RUP вы получаете сразу много всего, но надо избавиться от лишнего. А в Scrum – слишком мало, и надо добавить недостающее. Kanban оставляет почти все на ваше усмотрение. Единственные ограничения – визуализировать ваш ход работы и ограничить незавершенную работу (НЗР). Всего в нескольких сантиметрах от "Делайте что хочешь", но все равно на удивление мощно.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список использованной литературы:

1. Хенрик Книберг “SCRUM и XP: заметки с передовой”.
2. Майк Кон. Scrum: гибкая разработка ПО = Succeeding with Agile: Software Development Using Scrum. — М.: «Вильямс», 2011. — С. 576.
3. Jeff Sutherland. Scrum:The Art of Doing Twice the Work in Half the Time
4. A Practical Guide to Feature-Driven Development [Книга] / авт. Stephen Palmer John Felsing. A Practical Guide to Seven Agile Methodologies, Part 2 [В Интернете] / авт. Rod Coffin Derek Lane.
5. Advanced Topics in Agile Planning [В Интернете] / авт. Cohn Mike.
6. Экстремальное программирование: постановка процесса. С первых шагов и до победного конца *Книга+ / авт. Кент Ауэр Рой Миллер.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Вопросы к реферату:

1.Какова продолжительность  каждой итерации (СПРИНТа):

1. 3 месяца
2. День
3. 1-4 недели 
4. Год

2. Product Backlog это :

1. человек, который представляет интересы заказчика
2. методология управления процессом
3. список требований к функциональности
4. начальная оценка объема работ

 

3. Какое поле содержит каждый элемент Backlog'а:

1. Предварительная оценка (initial estimate)
2. Дата демо
3. Burndown 
4. Цель