Управление проектами: метод "Scrum". Scrum на простом языке

Scrum (skrʌm «схватка») - это методология управления проектами. Основной акцент использования данной методология делается на качественном контроле процесса разработки. Scrum является одной из наиболее популярных «методологий» разработки ПО. Кроме управления проектами по разработке ПО, Scrum может также использоваться и по сопровождению программ.

В статье «The New Product Development Game» (Гарвардский Деловой Обзор, январь-февраль 1986) Хиротака Такэути и Икудзиро Нонака отметили, что проекты, над которыми работают небольшие команды из специалистов, как правило, производят лучшие результаты. Они сослались на «подход регби» Scrum (толкотня, схватка вокруг мяча).

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

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

Процесс управления проектом Scrum

Терминология проекта Scrum

• Sprint - этап разработки;
• Sprint backlog - задачи по этапу разработки;
• Project backlog - cписок требований к функциональности.

Итерация Sprint

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

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

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

Список требований проекта Project backlog

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

В классическом Scrum подразумевается, что заказчик проекта может вносить любые изменения прямо по ходу проекта, но не в текущий Sprint . В большинстве случаев бюджет разработки ПО зафиксирован. А это значит, что и возможности Заказчика влиять на ход выполнения тоже ограничены. Тем не менее, при необходимости можно оформить «Дополнительное соглашение» к договору с учетом изменения финансовой составляющией проекта поскольку потребность добавлять или менять какие-либо функции проекта для Заказчика очень актуальна. Это способствует разработке нужного клиенту проекта, а не того, что формально представлено в ТЗ.

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

Список требований спринта Sprint backlog

Журнал пожеланий спринта Sprint backlog содержит функциональность проекта для определенного этапа Sprint"a.

Роли в управлении проектом Scrum

По методике Scrum в производственном процессе есть определённые роли, разбитые на 2 группы « свиней» и «кур». Эти названия были использованы вследствии следующей распространенной шутки:

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

Согласно Scrum «Свиньи» создают продукт, в то время как «куры» не настолько заинтересованы в готовом продукте. Им всё равно, будет ли проект удачным или нет, на них это мало отразится. Поэтому требования, пожелания и идеи «кур» принимаются во внимание, но им не разрешают непосредственно включаться в ход Scrum-проекта .

Классический Scrum использует 3 базовых роли («Свиньи» ) :

• Product owner (PO) - владелец продукта представляет интересы заказчика в проекте.
  PO является не членом команды разработчиков, а связующим звеном между командой разработчиков и заказчиком, т.е. это должен быть представитель заказчика. Поскольку роль накладывает высокие требования к опыту и компетенции индивида в сфере разработки и развития проекта, а также требует постоянного личного участия в проекте (что не всегда возможно для заказчика), то данную роль, как правило, выполняет менеджер проекта.
• Scrum master (SM) «служащий лидер» - член команды, следящий за соблюдением принципов Scrum .
  Роль SM не предполагает каких-то дополнительных полномочий по проекту. Задача SM - помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, оказание помощи PO.
• Development team (DT) - команда разработчиков.
  Команда разработчиков состоит из специалистов, выполняющих непосредственную работу над проектом. Согласно «The Scrum Guide» DT должна обладать следующими качествами:
  • должна быть самоорганизующейся. Никто (включая SM и PO ) не может указывать DT каким образом преобразовать Project backlog в работающий продукт;
  • должна быть многофункциональной и обладать всеми необходимыми навыками для создания работающего продукта;
  • должна отвечать за проект вся команда, а не отдельные её члены.
  Рекомендуемый размер команды DT , как правило составляет 6...8 человек. Согласно идеологам Scrum , команда большего размера требует слишком больших ресурсов на коммуникации, в то время как команда меньшего размера повышает риски (в виду возможного отсутствия требуемых навыков) и уменьшает размер работы, который можно выполнить за определенный отрезок времени.

Дополнительные роли (Ancillary roles ) в методологии Scrum («Куры» ) :

• клиенты Stakeholders - лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в Scrum только во время обзорного совещания по спринту Sprint Review ;
• управляющие персоналом Managers;
• эксперты-консультанты Consulting Experts.

Работа по этапам

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

В начале каждого этапа команда набирает себе из списка Project backlog столько задач, сколько способна реально выполнить за этап Sprint"a . Разбивает на подзадачи и уточняет сроки.

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

В начале новой итерации Sprint"a необходимо выполнить соответствующее планирование. Для этого из Backlog"a проекта выбираются задачи, которые за Sprint команда DT должна выполнить. На основе выбранных задач создается Backlog Sprint"a .

Каждую задачу спринта необходимо оценить в идеальных человеко-часах. Решение задачи должно занимать от 8 до 16 часов, т.е. не более двух рабочих дней. При необходимости задачу можно разбить на подзадачи.

Во время планирования обсуждается и определяется порядок реализации всего объёма работ. Продолжительность совещания имеет строгие ограничения (не более одного рабочего дня) и зависит от продолжительности итерации и опыта команды.

Ежедневный контроль, Daily meetings

Daily meetings , иначе называемый Stand-up Meeting проводится каждый день. На протяжении всего Sprint"a команда регулярно собирается в одно и то же время. Каждый член команды DT должен ответить на три вопроса:

• Что было сделано вчера?
• Что будет сделано сегодня?
• Какие есть проблемы?

При проведении Daily-Meeting важно не опуститься до обсуждения технических деталей проекта, либо формального выяснения статуса проекта.

Остановка спринта, Abnormal Termination

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

После остановки спринта проводится совещание с командой DT , где обсуждаются причины остановки. После этого команда переходит к выполнению очередного Sprint"a .

Диаграмма сгорания задач Burndown chart

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

Существуют два вида диаграммы:

• диаграмма сгорания работ для спринта, представляющая объем выполненных и невыполненных задач в текущем спринте;
• диаграмма сгорания работ для проекта, представляющая объем выполненных и невыполненных задач готового программного продукта (обычно строится на основе нескольких спринтов).

Особенности Scrum-проекта

1. В Scrum-проекте изменения в требования можно вносить в любой момент.
Таким образом можно менять Product backlog по ходу выполнения. Это затрудняет использование принципов Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, поэтому нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. планированием только тех работ, которые должны быть выполнены в ближайших Sprint"ах.

2. В Scrum-проекте главным источником достоверной информации является эмпирический опыт участников.
В «The Scrum Guide» говорится о необходимости полного и точного выполнения положений Scrum в виду отсутствия формального лидера и руководителя.

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

Плюсы и минусы Scrum-проекта

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

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

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

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

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

Гибкие методологии

Начать стоит с самого происхождения Agile-методологий. Начало им положил «Манифест гибкой методологии разработки программного обеспечения» в 2001-м году. Agile - в переводе с английского «гибкий». Вот основные принципы Манифеста:

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

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

Различные гибкие методики существовали и до выпуска Манифеста. Как следует из его названия, применялись они в разработке ПО, и долгое время никто не пробовал использовать их в других сферах. Некоторые из гибких методологий, которые использовались до 2001-го года:

• DSDM с начала 90-х,
• FDD с 97-го,
• Kanban ещё с 60-х годов, однако эта методология использовала лишь часть приёмов от гибких методик.

Srum тоже был разработан во второй половине 80-х годов прошлого века.

История Scrum

Впервые слово «Скрам» не в контексте регби (там этот термин обозначает позицию игроков, борющихся за мяч в плотном скоплении), а в контексте разработки использовали Хиротака Такеучи и Нонака Икуджир в статье в 1986-м году. Там учёные описывали новый гибкий геймификационный подход к разработке коммерческого продукта, позволяющий выполнять работу в быстрые сроки. Команда разработчиков сравнивалась с командой в регби: действует во время «Скрама», как единый организм, для достижения общей цели.

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

В этом же году создаётся Scrum Alliance. Его миссия: направлять лидеров, компании и людей в целом на создание правильной организации рабочего процесса - «Transform the World of Work». Альянс существует и сегодня и занимается внедрением методологии Scrum.

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

Основные принципы организации рабочего процесса в Scrum во многом являются эталоном и совпадают с другими Agile-методологиями.

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

Доска и Диаграмма сгорания задач

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

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

Другой, более простой инструмент: Desk. Диаграмма сгорания визуализирует эффективность команды, а Доска помогает работникам ориентироваться в текущих заданиях. Это таблица, состоящая из трёх или более столбцов: запланировано, выполняется, готово. В некоторых случаях добавляется столбец Stories, где могут отображаться истории пользователей - не только на текущий спринт, но и на следующие. По этим колонкам расклеиваются стикеры, на которых кратко изложена суть подзадачи: нарисовать эскиз, протестировать код, добавить кнопку на сайт. Стикеры постепенно переходят из «запланировано» в «выполняется», а из «выполняется» в «выполнено». Таким образом становится моментально ясно, что уже сделано, а что ещё в процессе, о каких делах сотрудники забывают.

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

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

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

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

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

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

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

Герман Греф активно вводит Scrum в IT-сфере «Сбербанка». Там методология используется для поддержки «Сбербанк Онлайн» с 2013-го года. По гибкой методике это же приложение и создавалось. Несколько команд занимаются разработкой других различных проектов, таких как «Советы».

Легко ли внедрять Scrum в большие компании? Гибкая методология требует полного изменения рабочего процесса, а далеко не все сотрудники будут к такому готовы. Как правило, легче всего вводить «Скрам» постепенно, набирая работников, которые заинтересованы в проекте, желают изменить привычный график. Точно не стоит сразу переводить на новый режим работы всю компанию целиком.

Мелкие компании, стратапы подходят для Scrum больше всего. Ведь чем «моложе» организация и чем меньше число сотрудников, тем легче ввести Agile-методологию и соблюдать её основные принципы.

Оценка Scrum

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

Преимущества

• Быстрое удовлетворение большинства требований заказчика или клиентов.
• Высокая конкурентоспособность продукта за счёт его постоянной оптимизации.
• Большая эффективность рабочей команды: каждый сотрудник постоянно занят своим делом, не тратит время на лишние разговоры, при этом постоянно взаимодействует с коллегами и через Product Owner с заказчиками.
• Готовый продукт производится в быстрые сроки.
• Экономия на менеджерах, так как команда управляется изнутри только Scrum-мастером, а извне лишь получает требования к продукту от заказчика.

Недостатки

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

Дэйв Томас, один из авторов Манифеста, считает, что Agile-методологии так и не получили воплощения. Вместо этого были придуманы наборы жёстких правил (как в Scrum), а слово «Agile» превратилось в бессмысленный маркетинговый термин.

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

Обучение Scrum

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

1. «Scrum. Революционный метод управления проектами» Джеффа Сазерленда.

Джеффа Сазерленда.

3. «Scrum и XP: заметки с передовой», Хенрик Книберг.

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

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

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

1. JIRA. Это приложение позволяет с удобством управлять проектами разной величины. Применяет шаблоны не только Scrum, но и Kanban. Доступно на мобильных устройствах, отправляет e-mail-уведомления и обладает ещё рядом полезных функций. Для Open Source проектов JIRA бесплатна.
2. Version One. Платформа для организации деятельности при различных Agile- и DevOps-методологиях. Визуализирует рабочие процессы, планирует спринты и релизы. Присутствуют Доска, Диаграмма сгорания и другие средства визуализации. Позволяет команде или командам коммуницировать между собой. Version One была первой программой, выпущенной для гибких методик, и до сих пор остаётся одной из лучших.
3. Taskify.us. Это интерактивный вариант Доски. Довольно простое приложение, которое, тем не менее, отлично выполняет свои функции.
4. Trello. Ещё одна интерактивная Доска, но с гораздо большими возможностями. Базовый вариант программы включает обычный Desk с карточками, в которых задача может быть очень подробно расписана. При потребности можно подключить дополнительные опции: календарь, голосование, «старение» карточек.
5. SprintGround. Таск-менеджер, оптимизированный под Agile-методики. Распределяет задачи, выводит информацию об эффективности команды на графиках, позволяет получать User stories.

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

Scrum (Скрам) — это не аббревиатура, этот термин взят из регби, который обозначает схватку вокруг мяча.

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

Основные термины, которые используются в методологии:

Владелец продукта (Product owner) — человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как это продукт должен выглядеть/работать. Этот человек не работает в команде, он работает на стороне заказчика/клиента (это может быть как другая компания, так и другой отдел), но этот человек работает с командой. И это тот человек, который расставляет приоритеты для задач.

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

Scrum-команда — это команда, которая принимает все принципы Scrum и готова с ними работать.

Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность определяется командой один раз).

Бэклог (backlog) — это список всех работ. Можно сказать, что это ежедневник общего пользования 🙂

Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог.

Product-бэклог — это полный список всех работ, при реализации которых мы получим конечный продукт.

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

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

Попробую объяснить все это на примере работы PR-агентства, как бы это могло выглядеть, если бы они работали по Scrum.

Компания клиент «Икс» хочет провести через 2 месяца масштабное мероприятие для своих партнеров и журналистов. Услуги по организации такого мероприятия компания «Икс» заказала у агентства «Зет». Компанию «Икс» представляет PR-менеджер, который отвечает за организацию мероприятия со стороны клиента. В терминологии Scrum — этот человек называется Владелец продукта . Со стороны агентства за организацию мероприятия отвечает account-менеджер (Scrum-мастер ), в подчинении которого находится команда (Scrum-команда ). На совместном совещании (планировании спринта ) компания и агентство решают, что они будут отчитываться-планировать каждые 2 недели (длина спринта ). На первые 2 недели они запланировали список задач (спринт-бэклог ), однако команда оценила, что не все из этого списка они успеют выполнить. Тогда PR-менеджер (он же Владелец продукта ), говорит какие из этого списка задач более приоритетные на ближайшие 2 недели, после чего команда берется за выполнение заданий. Единственное что здесь должно быть учтено, что на момент планирования первого спринта должен быть спланирован весь список заданий на 2 месяца (product-бэклог ), чтобы не получилось так, что к моменту проведения мероприятия что-то не выполнено.

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

Scrum на простом языке

Если раньше офисы модно было обустраивать «по фэн-шую», то теперь - исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?

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

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке . Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

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

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

(Управляющий партнер ScrumTrek Алексей Пименов в на Rusbase)

Слово экспертам

Владимир Овелян

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

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

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

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

Виталий Сотников

Илья Шихалеев

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

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

Евгений Россинский

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

Недавно мы в MakeRight.ru с удовольствием прочитали книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда. О чем она? В двух словах - о том, как организовать слаженную командную работу.
Начав внедрять элементы скрама на практике, мы пришли к выводу, что идеи книги действительно работают.

Революционный ли это метод, как указано в названии? Не знаем. Но, возможно, те, кто не читал книгу и не знаком с методикой, почерпнут для себя ряд полезных идей из нашего саммари (краткого изложения). Итак…

Что такое Scrum. Суть методики

«Порвите свои визитки. Избавьтесь от званий и титулов, от руководителей и иерархических структур. Дайте людям свободу делать то, что они считают правильным, и возможность нести за это ответственность. Результаты вас поразят ».

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

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

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

1. Для начала необходимо выбрать «Владельца продукта» - человека, обладающего видением того, что вы собираетесь создать или достигнуть.
2. Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
3. Нужно выбрать «Скрам-мастера» - того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
4. Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
5. Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
6. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт - определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель - постоянно превосходить свои собственные результаты - «наращивать динамику производительности».
7. Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки «Бэклог» в колонку «в работе», а затем в «сделано».
8. Ежедневно проводится скрам-собрание. По выражению Джеффа Сазерленда «это пульс всего процесса Scrum». Суть его проста - ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
9. По завершении спринта команда делает его обзор - проводит встречу, на которой участники рассказывают, что сделано за спринт.
10. После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.

Недостатки традиционного подхода к управлению проектами

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

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

Изображение с сайта www.quickiwiki.com

«С распространением в 1980-е годы персональных компьютеров стало проще создавать разные затейливые диаграммы - и делать их по-настоящему комплексными - они превращались в подлинные художественные произведения. Весь ход проекта детально размечен. Каждый отдельный шаг. Любая стадия. Всякая дата поставки. Действительно, диаграммы Ганта производят глубокое впечатление. Существует лишь единственная проблема: они всегда неправильны - без исключения ».

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

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

Планы рассыпаются в прах. Альтернатива - это Scrum

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

Слово scrum («схватка») автор позаимствовал из игры в регби. Оно «обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели. „Схватка“ представляет собой идеальную модель полного взаимодействия игроков ». И это именно то, что требуется для успешной командной работы.

Изображение с сайта brendanmarsh.com

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

«Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы, предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт.
На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, чего удалось достичь за время совместной работы. Они смотрят, сколько единиц работы, занесенных на стикеры, действительно доведены до конца. Не все удается выполнить? Значит, для этого спринта было отобрано слишком много задач. Бывает наоборот - недостаточное количество задач. В данном случае важно другое: у группы развивается чувство собственной скорости ».

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

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

Философия scrum

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

Суть командной работы в Scrum

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

Какого размера должна быть команда? Джефф Сазерленд рекомендует малочисленные группы - около семи человек. Он приводит данные, что если группа состоит из более чем девяти человек, то скорость ее работы падает.

Кроме того автор напоминает о «законе Брукса»:

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

Нет мультизадачности

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

Никаких переработок

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

«Методология Scrum подразумевает, что те, кто применяет ее, перестают измерять свою работу только часами. Часы отражают лишь затраты. Измеряйте лучше результат. Кого волнует, сколько кто-то потратил времени на то, чтобы что-то сделать? Единственное, что имеет значение, - как быстро и качественно это было сделано ».

Суть работы - поток

Как его достичь? За состоянием потока стоит внутренняя дисциплина.

«Не должно быть ни одного движения впустую ».

Скрам и счастье

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

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

Элементы скрам

Спринты

Изображение с сайта nyaski.ru

Однако есть важное замечание - «ничто не переносится в колонку „Сделано“ до тех пор, пока эта часть проекта не будет опробована клиентом».

«Еще один важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка „блокируются“. Никто не имеет права их менять или вносить добавления ».

Ежедневные собрания

Делайте до конца

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

Планирование в Scrum

Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи «в собаках». Эта проблема - такса или ретривер? А может быть, дог?

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

Автор также предлагает использовать интересную методику покер планирования. Ее суть - каждому участнику процесса планирования дается колода карт с числами Фибоначчи - 1, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол. «Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования. В противном случае они лишь усреднят оценки, что сделает результаты слишком приблизительными».

Требования - это истории

«Представьте, что вы составляете „пожелание пользователя Amazon.com“. Пробный вариант выглядит так: „Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время“.

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

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

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

Как планировать спринт

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

Но что такое работа? Рутина, обязаловка? С точки зрения скрам, работа - это история. Что это значит? Это означает, что вам следует представить человека, которому нужно то, что вы делаете; потом то, что это такое, и, наконец, зачем людям это нужно.

Командам нужно хорошо узнать свою динамику - сколько работы она может выполнить за один спринт. Это поможет ей работать разумнее и устранять все помехи на своем пути.

«Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише ».

Открытость во всем

Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.

«Секретность - яд. Ничто не может держаться в тайне. Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственной выгоды ».

Расстановка приоритетов

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

• Вы выдвигаете на первый план то, что вы можете предложить. Тогда возникает риск сделать никому ненужный продукт;
• Вы ориентируетесь на рынок. Тогда вас могут опередить или уничтожить конкуренты;
• Ваше главное стремление - большие продажи. Тогда вы рискуете выпустить на рынок посредственный продукт.

Бэклог

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

«Для этого нужно выяснить, какие пункты списка:

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

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

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

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

Минимизация рисков в скраме

«Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное? »

Как внедрить Scrum прямо сейчас

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

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

О нас

Мы рассказываем о ключевых идеях из лучших книг жанра нон-фикшн. В нашей