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

Автор работы: Пользователь скрыл имя, 19 Апреля 2013 в 09:30, реферат

Описание работы

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

Содержание работы

Введение……………………………………………………………………….3
Концепция Scrum .……………………………………………………….........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 файл

Зачетная работа.docx

— 436.69 Кб (Скачать файл)

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

 

  1. Практики

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

    1. Спринт

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

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

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

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

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

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

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

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

 

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

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

Рис 1.

 

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

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

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

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

 

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

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

 

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

 

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

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

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

 

  1. Выводы

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

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

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

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

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

 


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