Основы методологии scrum реферат

Обновлено: 03.07.2024

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

Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно :)

Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии :)

Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)

Роли в Scrum

В классическом Scrum существует 3 базовых роли:
-Product owner
-Scrum master
-Команда разработки (Development team)

Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.

Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).

Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды

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

Процесс Scrum

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.

По окончанию Sprint'а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint'е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.

Схематическое изображение процесса приведено на следующем рисунке:

Важные, часто забываемые особенности

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

1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.

2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.

3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.

Достоинства и недостатки

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

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

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

Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.

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

Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:

Список использованных источников

[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

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

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

Файлы: 1 файл

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 Жизненный цикл спринта 6
3.1 Планирование итерации (iteration planning), планированиеспринта (sprint planning) 6
3.2 Фокус-фактор (focus factor) 6
3.3 План итерации (iteration plan), Баклог спринта (sprint backlog) 7
3.4 Доска задач (Task Board) 7
3.5 Стендап (Standup meeting), Скрам (Daily Scrum Meeting) 8
3.6 Диаграмма сгорания (burndown chart) 8
3.7 Демо (Demo), Ревью спринта (Sprint Review) 8
3.8 Ретроспектива (retrospective) 9
3.9 Критерииготовности (Definition of Done) 9
3.10 Долгосрочное планирование (long-term planning), Планирование релиза (release planning) 9

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 10

SCRUM — методология управления развитием информационных систем для гибкой разработки программного обеспечения. SCRUM чётко делает акцент на качественном контроле процесса разработки.

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

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

– команда;
– Scrum Master;
– Product Owner.

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

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

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

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

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

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

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

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

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

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

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

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

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

Концепция Scrum-методологии

В системе Agile Scrum-управление проектами состоит из трех основополагающих частей:
- Роли
- Практики
- Документы (артефакты)
Чтобы уяснить суть, лучше разобрать эти части отдельно.

Роли в Scrum

Всего в Скрам есть три роли:
- Владелец продукта (Product Owner)
- Скрам-мастер (Scrum Master)
- Команда разработчиков (Delivery Team)
О них тоже имеет смысл сказать в отдельности.

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

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

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

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

Краткий перечень обязанностей владельца продукта:
- Формирование видения продукта
- Управление ожиданиями заказчика (и других заинтересованных лиц)
- Координация и приоритизация бэклога (журнала) продукта (см. ниже)
- Предоставление команде понятных и тестируемых требований
- Взаимодействие с командой проекта и заказчиком
- Прием и оценка результата работы в конце каждой итерации
Скрам-мастер

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

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

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

Краткий перечень обязанностей скрам-мастера:
- Создание доверительной атмосферы
- Участие в общих встречах и обеспечение успешной коммуникации участников
- Устранение препятствий в работе
- Обозначение проблем и открытых вопросов
- Обеспечение соблюдения практик процесса
Команда разработчиков

Командой разработчиков называется группа из 5-9 инициативных и самостоятельных человек – членов команды. Ее первостепенная задача состоит в постановке реально достижимой, прогнозируемой, интересной и значимой цели для каждой итерации.

Следующая задача состоит в достижении поставленной цели в указанные сроки и в надлежащем качестве. Цель итерации можно считать достигнутой лишь тогда, когда реализованы все поставленные задачи, прописаны коды (если это IT-разработка), протестирован рабочий вариант продукта, установлены и устранены все дефекты.

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

Краткий перечень обязанностей команды разработчиков:
- Оценка элементов бэклога продукта (см. ниже)
- Разработка продукта и предоставление его заказчику
- Отслеживание своего прогресса (совместно со скрам-мастером)
- Предоставление результата владельцу продукта
Все вместе участники проекта проделывают не только основную работу, но и реализуют скрам-практики.

Практики в Scrum

Как и ролей, практик в Scrum-управлении проектами существует три:
- Ежедневные Скрам-встречи (Daily Scrum Meeting)
- Встречи по обзору спринта (Sprint Review Meeting)
- Аварийная остановка спринта (Sprint Abnormal Termination)
Все эти практики имеют самое прямое отношение к спринтам, поэтому сначала скажем несколько слов о том, что вообще такое спринт.

Спринт

Спринтом в Scrum-проекте называется одна итерация (фаза) проекта. В большинстве случаев спринт длится 30 дней. В результате каждого спринта команда должна получить рабочую версию продукта, которую уже можно демонстрировать заказчику.

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

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

Команда разработчиков определяет оценки требований, чтобы убедиться, что они точны в степени, необходимой для начала работы. Затем определяется объем работ, который может быть успешно выполнен за один спринт. При этом нужно исходить из численности команды, доступного времени и производительности. Очень важно, чтобы команда разработчиков внимательно изучала журнал продукта и выбирала требования, первые по приоритету.

Как только команда разработчиков объявляет о своей готовности к реализации выбранных требований, скрам-мастер планирует спринт. Затем команда делит выбранные требования на задачи, которые нужно реализовать для успешного окончания спринта. В идеале на этот этап (разделение на задачи) не должно уходить более 4 часов, а в итоге нужно получить перечень разбитых на задачи требований, т.е. журнал спринта. Все участники команды разработчиков в обязательном порядке должны взять на себя ответственность по достижению поставленной цели.

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

Ежедневные Скрам-встречи

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

Проводит ежедневные встречи скрам-мастер. Поочередно каждому участнику он задает вопросы:
- Что ты сделал вчера?
- Что ты сделаешь сегодня?
- С какими проблемами ты столкнулся?
- Обсудить детали дизайна бэкграунда
- Толя и Коля
- Сразу после обеда
Участвовать в ежедневных встречах может любое заинтересованное лицо, однако все решения принимаются только членами команды разработчиков. Причиной этому служат обязательства участников по достижению цели спринта. Если кто-то иной будет вносить свою лепту в принятие решений, тем самым он снимет ответственность с членов команды.

Встречи по обзору спринта

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

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

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

Во второй половине встречи скрам-мастер вместе с остальными участниками анализирует прошедший спринт. Команда разработчиков определяет эффективные и неэффективные методы совместной работы, проводит их анализ, делает выводы и принимает решения, которые улучшат дальнейшую работу.

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

Аварийная остановка спринта

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

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

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

Артефакты в Scrum

В любом Scrum-проекте есть три основных артефакта (документа):
- Журнал продукта (Product Backlog)
- Журнал спринта (Sprint Backlog)
- График спринта (Burndown Chart)
У каждого из артефактов есть свои особенности.

Журнал продукта

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

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

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

Журнал спринта

Журнал спринта отражает функциональность, которую выбрал владелец продукта из составленного ранее журнала продукта. Каждая из функций разбивается на задачи. Разбивка же делается так, чтобы на выполнение одной задачи не уходило более двух дней.

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

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

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

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

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

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

Выводы о Scrum

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

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

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

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

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

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

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

Scrum представляет собой гибкую методологию управления проектами. Придумали её ещё во второй половине восьмидесятых, но настоящую популярность Scrum обрела в конце двухтысячных. Чем гибкие методики отличаются от остальных, и работает ли это?

Гибкие методологии
- люди и взаимодействие важнее процессов и инструментов,
- работающий продукт важнее исчерпывающей документации,
- сотрудничество с заказчиком важнее согласования условий контракта,
- готовность к изменениям важнее следования первоначальному плану.
В основе таких методологий лежит итеративный подход: когда разработка ведётся циклами (итерациями). После каждого цикла определяются планы по изменению продукта на следующий.

Различные гибкие методики существовали и до выпуска Манифеста. Как следует из его названия, применялись они в разработке ПО, и долгое время никто не пробовал использовать их в других сферах. Некоторые из гибких методологий, которые использовались до 2001-го года:
- DSDM с начала 90-х,
- FDD с 97-го,
- Kanban ещё с 60-х годов, однако эта методология использовала лишь часть приёмов от гибких методик.
Srum тоже был разработан во второй половине 80-х годов прошлого века.

История Scrum

Статью заметил Джефф Сазерленд, бывший военный лётчик США, занимающийся поиском новых подходов к разработке ПО. В это же время Кен Швабер, тоже разработчик, также искал новые подходы для оптимизации своей деятельности. В 1995-м году Сазерленд и Швабер объединяются и создают документ, отражающий основы методологии Scrum. В 2001-м они участвуют в создании Манифеста Agile.

На чём базируется Scrum

Основные принципы организации рабочего процесса в Scrum во многом являются эталоном и совпадают с другими Agile-методологиями.
- Работа над проектом состоит из спринтов (итераций), длина которых две–четыре недели. В течение спринта необходимо выполнить заданный заранее объём работ. Обычно это либо новая функциональность продукта, либо готовый продукт в целом, который в ходе следующих спринтов улучшается. Нельзя менять задачи в ходе спринта, спринт можно остановить только в исключительных ситуациях.
- Численность команды: четыре–десять человек. Такое ограничение обеспечивает максимальную производительность и сводит к минимуму отвлечения от работы и разговоры. Команда должна содержать всех необходимых для создания продукта специалистов.
- Задачи спринта излагаются в Product Backlog. Product Backlog составляется из пожеланий пользователей (user stories) — то, что заказчик или потребитель желает видеть в проекте.
- Каждый спринт начинается с планирования — на нём обсуждается, какие задачи нужно будет выполнить, завершается ретроспективой — оценка эффективности команды. Каждый день проходят 15-минутные собрания — члены команды, обязательно стоя, обсуждают: что удалось сделать вчера, что нужно сделать сегодня и что может этому препятствовать.
- Отсутствие многозадачности. Единовременно команда работает только над одной задачей.
- Помимо команды разработчиков обязательно присутствуют ещё две роли. Scrum-мастер, который следит за соблюдением принципов Scrum и убирает препятствия для эффективной работы, и Product Owner. Он взаимодействует с заказчиком и передаёт его требования команде.
Доска и Диаграмма сгорания задач

Отдельно стоит поговорить о методах визуализации работы, используемых в Scrum и некоторых других Agile-методиках. Две главных из них: Burndown Chart и Desk.

Burndown Chart — Диаграмма сгорания задач. Такая диаграмма отображает процесс работы над проектом. По ней легко отследить, насколько команда приблизилась к выполнению задачи. По горизонтали откладывается время: остаток дней до конца стрима. По вертикали — количество подзадач, человеко-часов или Story Points — единиц измерения работы. График Диаграммы сгорания стремится вниз, от первого дня к последнему, от максимального количества подзадач/человеко-часов к их отсутствию. Отдельным цветом изображается идеальный график — прямая: когда за каждый день выполняется одинаковый объём работы, что в итоге приводит к равномерной нагрузке и выполнению цели в срок. Плохим результатом на Диаграмме сгорания будет не только возвышение реального графика над идеальным. Если команда выполнила весь объём работ на несколько дней раньше, значит неправильно был определён размер итерации либо поставлена слишком маленькая или простая задача.

Два этих способа визуализации обязательны в Scrum. Burndown chart и Desk — статистика и мотивация для команды. Однако применять такие инструменты можно и без перехода к гибким методикам: они отлично покажут эффективность любого рабочего коллектива.

Ещё один популярный инструмент: метрика Velocity. На диаграмме за несколько спринтов сравниваются столбцы запланированных подзадач/Story points за стрим со столбцами выполненных. На основе этого определяется эффективность. Метод весьма спорный, так как слишком обобщает результаты, но может использоваться дополнительно.

Где применяется Scrum

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

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

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

Scrum и крупные компании

Оценка Scrum

Scrum существует уже достаточно долго и за это время приобрела много сторонников и немало противников.

Преимущества
- Быстрое удовлетворение большинства требований заказчика или клиентов.
- Высокая конкурентоспособность продукта за счёт его постоянной оптимизации.
- Большая эффективность рабочей команды: каждый сотрудник постоянно занят своим делом, не тратит время на лишние разговоры, при этом постоянно взаимодействует с коллегами и через Product Owner с заказчиками.
- Готовый продукт производится в быстрые сроки.
- Экономия на менеджерах, так как команда управляется изнутри только Scrum-мастером, а извне лишь получает требования к продукту от заказчика.
Недостатки
- Не все проекты можно выполнять по такой методологии. Для госзаказов, к примеру, Scrum многие специалисты считают неприменимой.
- Отсутствие фиксированных бюджета и срока (имеется ввиду не спринт, а в целом время, нужное для получения готового продукта) на выполнение также осложняет заключение юридических договоров.
- Немотивированная или низкоквалифицированная команда не сможет работать эффективно. А далеко не все сотрудники отличаются самоорганизованностью. Это же может повысить затраты на подбор и отбор кадров.
- С некомпетентностью можно столкнуться и при подборе специалистов на роль Scrum-мастера. Сейчас очень много людей, имеющих на руках сертификат о том, что они прошли обучение. При этом далеко не всегда эти люди действительно являются профессионалами и могут организовывать деятельность команды.
Обучение Scrum

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

Эта книга также написана Джеффом Сазерлендом совместно с Кеном Швабером — другим создателем Scrum. В книге описывается процесс быстрой разработки программного обеспечения на основе методики, а дополнение Scrum Guide описывает все роли, артефакты, процессы.

Автор делает выводы из использования методологий на практике. Поможет быстро войти в тему.

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

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

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

Читайте также: