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-мастер пересчитывает объем оставшейся работы и отмечает это на графике спринта. Только в том случае, если объем работ по окончании итерации закончился (в журнале спринта не осталось незавершенных задач), итерация считается успешной. График спринта используется как вспомогательный инструмент, позволяющий корректировать работу для завершения итерации вовремя, с работающим кодом и требуемым качеством

Пример графика спринта:

 

5. Практики

В Scrum итерация называется спринт. Ее длительность составляет от 1 до 4 недель[3]. В течение одной итерации проектная команда общается с заказчиками, анализирует, пробует, разрабатывает и тестирует код. В конце каждой итерации демонстрируется полностью доделанная за итерацию функциональность. Заказчики смотрят на результаты работы. Все предложения по улучшению планируются на последующие итерации. Внутри итерации заказчики стараются воздерживаться от изменения требований.

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

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

В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта.

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

 

1. Планирование спринта

Перед каждым спринтом проводится планирование. В планировании спринта участвуют заказчики, пользователи, менеджер, владелец продукта, Scrum-master и команда.

Планирование спринта  состоит из двух последовательных совещаний[5]:

1. Первое совещание

Участники: команда, Product Owner, Scrum Master, пользователи, менеджемент

Цель: Определить цель спринта (Sprint Goal) и журнал спринта т.е. функциональность, которая будет разработана в течение следующего спринта для достижения цели.

2. Второй совещание

Участники: Скрам Мастер, команда

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

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

 

2. Спринт

После окончания планирования начинается итерация. Каждый день Scrum-мастер проводит «скрам» (Daily Scrum Meeting)[4] — пятнадцатиминутное совещание, цель которого — достичь понимания того, что произошло со времени предыдущего совещания, скорректировать рабочий план к реалиям сегодняшнего дня и обозначить пути решения существующих проблем.

 Srum-совещание проводит Srum-Мастер. Он по кругу задает вопросы каждому члену команды:

1. Что сделано вчера?
2. Что будет сделано сегодня?
3. С какими проблемами столкнулся?

Srum-Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда, например[3]:

• Обсудить проблему с отрисовкой элемента управления
• Джон и Стив
• Сразу после Srum-совещания

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

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

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

 

3. Демонстрационное заседание

В конце каждого спринта проводится демонстрационное заседание (Sprint Review Meeting)[2] продолжительностью не более четырех часов. Сначала Scrum-команда демонстрирует владельцу продукта сделанную в течение спринта работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных заказчиков. Владелец продукта определяет, какие требования из журнала спринта были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в журнале продукта для следующей итерации. Во второй части митинга производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда ищет использованные в последнем спринте положительные и отрицательные способы совместной работы, анализирует их, делает выводы и принимает важные для дальнейшей работы решения. Scrum-команда также определяет программы, которые могут работать лучше, и ищет пути для увеличения эффективности дальнейшей работы. Затем цикл замыкается, и начинается планирование следующего спринта (Рис. 1).

Рис 1.

 

Scrum-Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить расписание и распланировать, кто и в какой последовательности что представляет[2].

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

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

Спринты выполняются до тех  пор пока заказчик не получит готовый  продукт.

 

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

Доска задач[5] – физическая доска, висящая в комнате, где находится команда.   Пространство доски поделено на полосы.

 

Рис. 2. Доска задач

 

         На доске  полоса (To Do) предназначена для задач, за которые еще никто не брался. Карточки прикрепляются на эту полосу так, чтобы карточки с задачами находились рядом с соответствующими карточками функциональность ПО. Следующая полоса (In Progress) предназначена для задач, которые находятся в работе. Каждый разработчик перевешивает и подписывает свою задачу.

 Как только задача  сделана, разработчик перемещает  карточку дальше, в третью полосу (Done). Теперь он может взяться за следующую задачу. Он берет карточку из первой полосы, подписывается и перемещает на вторую.

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

 

7. Выводы

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

8. Список использованной литературы
1. Михаил Борисов. Scrum: гибкое управление разработкой - URL:

http://www.osp.ru/os/2007/04/4220063/

2. Ikujiro Nonaka, Hirotaka Takeuchi. The New New Product Development Game. Harvard Business Review, Jan-Feb 1986.
3. Ken Schwaber, J. Sutherland, Scrum Development Process, in OOPSLA Business Object Design and Implementation Workshop. Springer, London, 1997.
4. Ken Schwaber, Agile Project Management with Scrum. Microsoft Press, 2004.
5. Асхат Уразбаев. Обзор методологии SCRUM – URL: http://citforum.urc.ac.ru/SE/project/scrum/

Симферополь, 2012