Scrum — методология управления разработкой программного обеспечения

Министерство образования  и науки, молодежи и спорта Украины 
Таврический Национальный Университет имени В. И. Вернадского

Кафедра компьютерной инженерии  и моделирования

 

 

 

 

Зачетная контрольная  работа

по учебной  дисциплине

«Основы менеджмента»

 на тему:

«Scrum — методология управления разработкой программного обеспечения»

 

 

 

 

 

 

 

 

Выполнил:

студент 3-го курса

физического факультета

группы КСС- 312

Дергачев Александр

Проверил: Шостка В. И.

СОДЕРЖАНИЕ

1. Введение……………………………………………………………………….3
2. Концепция Scrum .……………………………………………………….........3
3. Роли…………………………………………………………………………….5

3.1. Scrum-команда ……………………………………………………………....5

3.2. Scrum- мастер …………………………………………………………..…....5

3.3. Владелец продукта …………………………………………………………..6

4. Документы……………………………………………………………………...7

4.1.  Журнал продукта…………………….……………………………………...7

4.2.  Журнал спринта ..…………………………………………………………...8

4.3.  График спринта……………………………………………………………...9

5. Практики……………………………………………………………………….10

5.1. Планирование спринта.……………………………….…………………….11

5.2. Спринт.……………………………….………………………….…………..12

5.3. Демонстрационное заседание.…….……….………………….…………...13

6. Вспомогательные средства. Доска задач……………………………………15

7. Вывод…………………………………………………………………………..16

8. Список использованной литературы………………………………………...17

 

 

 

 

 

 

 

 

 

 

 

1. Введение

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

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

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

 Scrum - одна из самых популярных методологий гибкой разработки. Одна из причин ее популярности - простота. Цель работы – раскрыть суть Scrum и показать ее простоту.

Концепция Scrum

Scrum[1] — простой каркас, который можно использовать для организации команды и достижения результата более продуктивно и с более высоким качеством за счет анализа сделанной работы и корректировки направления развития между итерациями. Методология позволяет команде выбрать задачи, которые должны быть выполнены, учитывая бизнес-приоритеты и технические возможности, а также решить, как их эффективно реализовать. Это позволяет создать условия, при которых команда работает с удовольствием и максимально продуктивно. К примеру, возможность самостоятельного выбора объема и пути решения задач без внешнего давления позволяет всем участникам команды почувствовать себя активными игроками, вовлеченными в процесс, а не простыми исполнителями, от которых требуется лишь четкая реализация поручений.

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

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

Девиз Scrum[4] — «анализируй и адаптируй»: анализируй то, что получил, адаптируй то, что есть, к реальной ситуации, а потом анализируй снова. Чем меньше формализма, тем более гибко и эффективно можно работать, — это основной принцип данной методологии. Но это не означает, что формальных процессов не должно быть совсем, их должно быть достаточно для организации эффективного взаимодействия и управления проектом. Формальная часть Scrum состоит из трех ролей, трех практик и трех основных документов.

 

2.  Роли

В методологии Scrum всего три роли[1]:

 – Scrum-команда (Scrum Team);

– Scrum-мастера (Scrum Master);

 – Владелец продукта (Product Owner)

 

3.1. Scrum-команда

Scrum-команда (Scrum Team)[1] — группа, состоящая из пяти –девяти самостоятельных, инициативных программистов. Первая задача этой команды — поставить реально достижимую, прогнозируемую, интересную и значимую цель для итерации. Вторая задача — сделать все для того, чтобы эта цель была достигнута в отведенные сроки и с заявленным качеством. Цель итерации считается достигнутой только в том случае, если все поставленные задачи реализованы, весь код написан по определенным проектом «стандартам кодирования» (coding guidelines), программа протестирована полностью, а все найденные дефекты устранены. Программисты этой команды должны уметь оценивать и планировать свою работу, работать в команде, постоянно анализировать и улучшать качество взаимодействия и работы. В обязанности всех членов Scrum-команды входит участие в выборе цели итерации и определение результата работы. Они должны делать все возможное и невозможное для достижения цели итерации в рамках, определенных проектом, эффективно взаимодействовать со всеми участниками команды, самостоятельно организовывать свою работу, предоставлять владельцу рабочий продукт в конце каждого цикла.

 

3.2. Scrum-мастер

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

Основные обязанности, Scrum-Мастера таковы[1]:

• Создает атмосферу доверия,
• Участвует в митингах в качестве фасилитатора (человек, обеспечивающий успешную групповую коммуникацию)
• Устраняет препятствия
• Делает проблемы и открытые вопросы видимыми
• Отвечает за соблюдение практик и процесса в команде

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

Scrum-мастер не раздает задачи членам команды. Scrum-мастер - один из членов команды. Он может быть разработчиком, тестировщиком, аналитиком и т.д.

Scrum-мастер проводит командные совещания (планирование, демонстрацию и ретроспективу).

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

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

По мере того, как команда  становится самоорганизующейся, роль Scrum-мастер уменьшается.

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

Владелец продукта (Product Owner)[5] – это человек, отвечающий за разработку продукта. Как правило, это менеджер продукта для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Владелец продукта – это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет. Это позволяет избежать проблемы множественности заказчиков.

Обязанности владелец продукта таковы[5]:

• Отвечает за формирование версии продукта (product vision)
• Управляет ROI (коэффициент, иллюстрирующий уровень доходности или убыточности бизнеса)
• Управляет ожиданиями заказчиков и всех заинтересованных лиц
• Координирует и приоритизирует журнал спринта(Product backlog)
• Предоставляет понятные и тестируемые требования команде
• Взаимодействует с командой и заказчиком
• Отвечает за приемку кода в конце каждой итерации

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

Владелец продукта ставит задачи команде, но он не вправе ставить  задачи конкретному члену проектной  команды.

 

3. Документы
1. Журнал продукта (Product Backlog)

Журнал продукта[2] – это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.

Журнал продукта включает в себя: дефекты, проблемы, улучшения, технологии и т.д. Он также включает задачи, важные для команды, например «провести тренинг».

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

Пример журнала продукта:

 

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

 

4.2. Журнал спринта (Sprint Backlog)

Журнал спринта содержит функциональность, выбранную владельцем продукта (Product Owner) из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

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

Пример журнала спринта:

Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется графиком спринта (Sprint Burndown chart)[3]. Он демонстрирует прогресс команды по ходу спринта.

4.3. График спринта

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