Scrum-технология разработки программного обеспечения

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

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 24.12.2014
Размер файла 79,3 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Реферат

Scrumехнология разработки программного обеспечения

Введение

Свинья идёт по дороге. Курица смотрит на неё и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать «Яичница с беконом «?». «Так не пойдёт, - отвечает свинья, - ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично».

Глядя на эту шутку можно сказать, что по методике Scrum в производственном процессе есть определённые роли, разбитые на 2 группы «свиней» и «кур».

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

1. Scrum

Рис. 1 - Основа Scrum

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

scrum программный управление

2. Историческая справка

Подход впервые описали Хиротака Такэути и Икудзиро Нонака в статье The New Product Development Game (Гарвардский Деловой Обзорянварь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби». В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения» ссылались на этот подход, как на Scrum (толкотня; схватка вокруг мяча (в регби)), спортивный термин, приведённый в статье Такэути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привел Scrum в его компанию. Впервые метод Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Швабером и Джефом Сазерлендом на OOPSLA'96 (англ.) в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь их опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как Scrum. Швабер объединил усилия с Майком Бидлом в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM».

3. Роли

В методологии Scrum всего три роли.

· Scrum Master

· Product Owner

· Team

Скрам Мастер (Scrum Master)

Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой.

Основные обязанности Скрам Мастера таковы:

· Создает атмосферу доверия,

· Участвует в митингах в качестве фасилитатора

· Устраняет препятствия

· Делает проблемы и открытые вопросы видимыми

· Отвечает за соблюдение практик и процесса в команде

Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте.

ScrumMaster может также помогать Product Owner создавать Backlog для команды

Product Owner

Product Owner - это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner - это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет.

Обязанности Product Owner таковы:

· Отвечает за формирование product vision

· Управляет ROI

· Управляет ожиданиями заказчиков и всех заинтересованных лиц

· Координирует и приоритизирует Product backlog

· Предоставляет понятные и тестируемые требования команде

· Взаимодействует с командой и заказчиком

· Отвечает за приемку кода в конце каждой итерации

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

Команда (Team)

В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды.

Обязанности команды таковы:

· Отвечает за оценку элементов баклога

· Принимает решение по дизайну и имплементации

· Разрабатывает софт и предоставляет его заказчику

· Отслеживает собственный прогресс (вместе со Скрам Мастером).

· Отвечает за результат перед Product Owner

Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды - 7 плюс минус 2.

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

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

4. Артефакты

Product Backlog

Product Backlog - это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.

Product Backlog включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д. Product backlog также включает задачи, важные для команды, например «провести тренинг», «добить всем памяти»

Product Backlog постоянно пересматривается и дополняется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.

Sprint Backlog

Sprint Backlog содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач. Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.

Спринт (Sprint)

В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней).

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

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

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

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

Жизненный цикл спринта

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

В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда.

Планирование спринта состоит из двух последовательных митингов.

Планирование спринта, митинг первый

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

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

Артефакт: Sprint Backlog

Планирование спринта, митинг второй

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

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

Артефакт: в Sprint Backlog появляются задачи

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

Остановка спринта (Sprint Abnormal Termination)

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

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

Daily Scrum Meeting

Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга - поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга.

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

· Что сделано вчера?

· Что будет сделано сегодня?

· С какими проблемами столкнулся?

Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда, например

· Обсудить проблему с отрисовкой контрола

· Петя и Вася

· Сразу после скрама

5. Демо и ревью спринта

Рекомендованная длительность: 4 часа

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

Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и распланировать кто и в какой последовательности что представляет.

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

Заключение

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

Размещено на Allbest.ru

...

Подобные документы

  • MySQL как одна из самых распространенных на современном этапе систем управления базами данных, оценка ее преимуществ и недостатков. Порядок разработки интернет-магазина, составление и листинг программы, анализ ее функциональности и возможности, значение.

    курсовая работа [223,3 K], добавлен 13.03.2015

  • Data Mining как процесс поддержки принятия решений, основанный на поиске в данных скрытых закономерностей (шаблонов информации). Его закономерности и этапы реализации, история разработки данной технологии, оценка преимуществ и недостатков, возможности.

    эссе [36,8 K], добавлен 17.12.2014

  • История языков разметки, их типы: текстовые и графические. Этапы развития браузеров, оценка их недостатков. Языки программирования, предполагаемые для разработки браузера, используемые методы и приемы. Пример написания программы на языке SmallBasic.

    курсовая работа [2,0 M], добавлен 11.07.2014

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

    лекция [108,2 K], добавлен 27.01.2012

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

    реферат [585,1 K], добавлен 10.09.2010

  • Несоответствие процессов разработки программного обеспечения международным стандартам. Фазы, развитие вычислительной инфраструктуры. История развития компьютерных систем. Этапы разработки программ и их тестирование. Ошибки в программном обеспечении.

    реферат [176,2 K], добавлен 27.08.2009

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

    курсовая работа [1,6 M], добавлен 04.12.2009

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

    презентация [6,1 K], добавлен 23.10.2013

  • Проблема конфиденциальности информации и принципы ее реализации, используемые методы. Общая характеристикам и сравнение шифров DES и ГОСТ, оценка их главных преимуществ и недостатков применения, удобства использования, возможности и функциональность.

    курсовая работа [525,8 K], добавлен 22.06.2015

  • Оценка финансовой, стратегической ценности и уровня рисков проекта. Классификация проектов: "свой" заказчик, продукт под заказ, тиражируемый продукт, аутсорсинг. Организация процесса разработки программного обеспечения, методологии его проектирования.

    презентация [82,8 K], добавлен 07.12.2013

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

    реферат [2,2 M], добавлен 25.12.2017

  • Браузер как программа, представляющая в удобном для восприятия виде информацию, получаемую из Интернета, история ее развития и этапы эволюции, современные тенденции. Обзор самых популярных браузеров, оценка их сильных и слабых сторон, перспективы.

    презентация [863,6 K], добавлен 01.05.2013

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

    курсовая работа [301,9 K], добавлен 29.10.2017

  • Базовые основы разработки программного обеспечения: его классический жизненный цикл, макетирование, стратегии конструирования, модели качества процессов разработки. Применение параллельных алгоритмов и CASE-системы, критерии оценки их эффективности.

    курсовая работа [179,5 K], добавлен 07.04.2015

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

    презентация [793,8 K], добавлен 15.11.2010

  • Сенсорный экран как устройство ввода-вывода информации, представляющее собой прибор, реагирующий на прикосновения к нему; история его разработок, оценка основных преимуществ и недостатков. Принципы работы и типы сенсорных экранов, сферы их применения.

    презентация [3,1 M], добавлен 14.05.2011

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

    презентация [2,0 M], добавлен 17.11.2015

  • Понятие и ключевое отличие распределенной разработки программного обеспечения, его достоинства и недостатки. Концептуальное решение и выбор типа разработки. Особенности программного обеспечения с открытым исходным кодом. Идея и развитие Open Source.

    курсовая работа [97,7 K], добавлен 14.12.2012

  • Модель этапа пост-архитектуры. Предварительная оценка программного проекта на основе LOC-метрик. Расчет затрат на разработку ПО. Стоимость, длительность разработки проекта на основе модели этапа пост-архитектуры конструктивной модели стоимости СОСОМО II.

    курсовая работа [89,9 K], добавлен 29.09.2009

  • Технологический процесс в организации и его компоненты. Организационная структура и роли в технологических процессах. Пятиуровневая модель зрелости технологического процесса разработки программного обеспечения. Внутренняя структура уровней зрелости.

    курсовая работа [184,1 K], добавлен 29.06.2010

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.