Методология, технология Scrum (метод управления проектами). Scrum на простом языке

Методология Scrum. Как управлять проектами? Reviewed by Владислав Челпаченко on Jul 27 Rating: 4.0

Добрый вечер, уважаемые коллеги!

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

Я предлагаю вам ознакомиться с методологией скрама, которая поможет вам добиться удивительных результатов! Читайте и применяйте!

Что такое Scrum?

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

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

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

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

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

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

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

1. Выберите визионера. Обычно это владелец самого продукта. Этот человек обладает видением того, что должно быть на выходе. Он понимает, как должно быть всё устроено, и является путеводной звездой для всего проекта.
2. Выберите скрам-мастера. Это человек, которые решает все мелкие и многочисленные задачи, устраивает короткие собрания и следит за выполнением самого подхода.
3. . Найдите тех, кто лучше всего вам подходит для работы над проектом. Scrum подразумевает малое количество участников от 3 до 12.
4. Создать бэклог. Это список всех требований к продукту по приоритетности. Составляется он с учётом все людей, принимающих участие в создание продукта.
5. Оцените список задач. Пусть команда определится, что ей необходимо и достаточно ли знаний, умений и информации для реализации каждой из задач. Также задайте сложность каждой задаче, можно сделать это с помощью чисел Фибоначчи: 1, 2, 3, 5, 8, 13, 21. При подведение итогов и сравнению с прошлым опытом необходимо сравнить количество баллов.
6. Запланируйте спринт. Это краткосрочный забег на 1 или 2 недели, который команда сама планирует. Берётся определённое количество заданий, с которыми по мнению команды она может справиться. Если уже пройдено несколько спринтов, то стоит учитывать количество прошлых баллов. Должна наблюдаться динамика.
7. Видимость процесса. Очень важно сохранять прозрачность процесса для скорейшего достижения результата. Для этого можно завести скрам-доску с колонками: «нужно сделать», «в процессе» и «сделано». Для этого подойдёт обычная доска в офисе или мобильное приложение Trello.
8. Ежедневные собрания. Это встреча Scrum-мастера и команды, которая длится не более 15 минут. На ней разбираются несколько основных вопросов: «что делал вчера для спринта», «что будешь делать сегодня для завершения спринта» и «какие препятствия встают перед командой». Это необходимо для быстрого устранения любых проблем скрам-мастером.
9. Обзор спринта. Это собрание, на котором команда предоставляет свои результаты - что она сделала окончательно по завершению спринта.
10. Собрание после завершения спринта. На этом обсуждении должны присутствовать все. Главный упор делается на улучшении процесса, а не на поиске виноватых и нерешаемых препятствий. Что можно улучшить? Что поможет ускорить процесс? Что можно внедрить? и так далее. Занесите результаты в бэклог.
11. Следующий спринт. Начинайте его немедленно с учётом прошлого опыта. Непрерывность, развитие и гибкость - важнейшие параметры скрама.

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

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

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

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, или знаком лишь частично (к примеру, работает в модифицированном Scrum).

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

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

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

Роли в Scrum

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

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

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

Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master - помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO

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

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

Процесс Scrum

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

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

Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum - определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint"а.

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

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

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

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

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

2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения .
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в 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. Существуют и иные ограничения.

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

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

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

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

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

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

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

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

Заранее благодарю за указанные ошибки и неточности!

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

В скрам-командах ключевые позиции занимают
scrum-master и product owner ,
итерация начинается планированием ,
на котором члены команды «играют»
в покер планирования,
и завершается демо с ретроспективой .

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

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

Применение скрама в IT и не только

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

И действительно, по данным Scrum Alliance за 2016 г. 21% проектов, выполненных по скраму, не имели отношения к сфере IT. Посмотрите, какие подразделения успешно используют scrum:

Scrum VS Agile VS Waterfall

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

Скрам — это один из фреймворков agile , формализованная методология работы над проектами. К аджайл методологиям, кроме скрама, относятся и другие современные подходы. Альтернативой scrum могут быть , Scrumban и другие. То есть скрам — это agile, но agile — не только скрам.

Представьте, что agile — это христианство, а scrum — одно из его течений, например, протестантизм. И хотя христиане в целом и протестанты в частности исповедуют одни и те же принципы, протестанты имеют свои уникальные ритуалы для проявления веры.

Соответственно, визуально различия и сходства между Scrum и Agile можно представить так:

* Артефакты в скраме — это объекты, которые создаются командой во время работы над проектом. К ним относятся бэклог продукта, бэклог спринта и инкремент продукта, то есть работающий кусок функционала, который команда демонстрирует в конце спринта.

Гибкие методики разработки противостоят каскадной модели (каскад, водопад, waterfall) , которой в 90-е годы пользовались практически все команды разработчиков.

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

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

Как работать по скраму

Роли в скраме

Скрам-команда

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

Для скрама нужна небольшая команда: 7±2 человек. При большем количестве людей участники команды тратят слишком много ресурсов на коммуникации. В середине 90-х годов Лоуренс Путнэм проанализировал 491 команду разработчиков: все они создавали новый продукт и были разных размеров. Исследование показало, что большим командам (9-20 человек) нужно в 4 раза больше времени и усилий, чтобы решить задачу, чем малочисленным группам (3-7 человек).

Скрам-мастер

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

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

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

Заказчик

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

Регулярные скрам-собрания и Worksection

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

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

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

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

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

Для этого они отвечают на три вопроса:

Собрания длятся не дольше 15 минут и проводятся стоя.

Для этой встречи каждый может посмотреть свой Отчет за выбранный день.

Демонстрация или обзор спринта

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

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

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

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

Используются Отчеты за соответствующий промежуток времени по Людям, Отделам, Счета и Детальный.

Алгоритм. Что за чем делать?

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

2. Сформируйте скрам-команду.

3. Назначьте скрам-мастера.

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

Бэклог — это полный список работ, которые нужно выполнить.
Пользовательские истории, User stories — это требования к функциональности продукта, озвученные от имени конечного потребителя. Например, я, как покупатель интернет-магазина, хочу искать нужный товар на сайте (оплачивать покупки картой, сохранять товары в корзину и т.д.).

5. Оцените задачи из бэклога , используя относительные величины, например, размеры футболок или числа из последовательности Фибоначчи: 0, 1, 1, 2, 3, 5, 8, 13 и т.д. Оценивайте задачи всей командой с помощью покера планирования (planning poker): используйте колоду карт или приложение на смартфон.

Покер планирования — специальная колода карт с числами Фибоначчи. Каждый член команды получает свой комплект. Когда скрам-мастер озвучивает задачу, члены команды одновременно кладут на стол карты с числами, которые, по их мнению, соответствуют сложности задачи. Если карты участников расходятся на одну-две единицы, например, 3 и 8, то задаче присваивается сложность, равная среднему арифметическому этих чисел. Если расхождение больше, то участники, которые выкинули самую маленькую и самую большую карты, объясняют свои решения. После этого все члены команды выкладывают карты заново. И так, пока все не придут к соглашению.

6. Проведите планирование спринта : выберите задачи и распределите их между исполнителями.

7. Заведите скрам-доску , поделите ее на три части: нужно сделать, в работе, сделано. Перемещайте стикеры с задачами, чтобы видеть динамику работы. Используйте реальную или виртуальную доску.

8. Не забывайте о ежедневных собраниях.

9. В конце спринта проведите демонстрацию.

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

11. Начинайте следующий спринт с планирования (пункт 6).

Скрам Гайд. Исчерпывающее руководство по Скраму: Правила Игры / Кен Швабер, Джефф Сазерленд

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

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

Управление продуктом в Scrum. Agile-методы для вашего бизнеса / Роман Пихлер

Существенная часть посвящена владельцу продукта: его функциям, качествам, ошибкам. Автор подробно рассматривает процесс создания продукта по скрам методологии, начиная продумыванием концепции будущего продукта и заканчивая созданием отчетов.

Scrum и XP: заметки с передовой / Хенрик Книберг

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

Agile-манифест разработки программного обеспечения

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

Преимущества и недостатки Scrum в ІТ

Скрам — отличная методология: высокоэффективная, прозрачная, мотивирующая. Это win-win подход, от которого выигрывает и команда, и заказчик.

Но скрам — формализованная методология, и для некоторых проектов применять ее не так просто.

Вот явные недостатки скрама:

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

В нашем проекте сразу пытались практиковать двухуровневый скрам: глобальный и на уровне подразделений (sales, маркетинг, финансы и т.д.). Сначала руководители отделов определяли задачи на глобальном планировании, потом они спускались на уровень отдела. У нас получалось плохо — конечный результат был слишком размыт.

• высокоэффективные команды расслабляются и перестают совершенствоваться. Индикатор наличия проблемы — снижение динамики производительности спринтов. Скрам-мастер должен донести серьезность проблемы до команды. Если команда не выходит из тупика самостоятельно, вмешивается руководство: нанимаются новые сотрудники, проводится ротация кадров.

Scrum-компании

По данным отчета Scrumalliance 70% IT компаний используют скрам. Среди них такие гиганты как Google, Amazon, Salesforce.com, Microsoft, Adobe.

Salesforce.com

Американская , ведущий разработчик CRM систем для бизнеса. Ее продуктами пользуется 150 тыс. компаний. Много лет использует гибкие методологические подходы во главе со скрамом, создав на его основе уникальный гибрид из нескольких фреймворков agile.

Применяет гибкие методики с 1999 года, и к 2004 году несколько команд разработчиков уже использовали скрам. К 2009 большая часть разработчиков была целенаправленно переведена на скрам.

Spotify

Цифровой музыкальный сервис, который успешно конкурирует с гигантами Google, Apple и Amazon. Своим конкурентным преимуществом Spotify считает максимальное использование возможностей скрам. Руководство компании нанимает лучших скрам-коучей на роль скрам-мастеров. Работа ведется маленькими автономными командами, к которым относятся как к стартапам.

Применяет скрам с 2008 г., 4 тыс. разработчиков в сотнях команд по 10-12 человек трудятся по методологии скрам, выпуская новый продукт каждые три недели. Корпорации удалось успешно масштабировать скрам под свои размеры.

То, что скрам используется не только в IT сфере, демонстрирует проект — инициатива учителя химии в школе нидерландского городка Алфен-ан-ден-Рейн. При поддержке делового сообщества в Голландии был создан фонд eduScrum, который обучает учителей использовать скрам на уроках. Школьники, работающие в скрам-командах, учатся лучше и с большим удовольствием, чем сверстники.

Проект «Страж» для ФБР

Внедрение скрам методологии спасло от краха многомиллионный проект американского правительства — единую базу данных «Страж» для ФБР. «Страж» был второй попыткой разработать единую информационную систему для ФБР. Первая провалилась, не проработав и дня.

«Страж» начал создаваться в 2005 г. по каскадной модели. На проект было выделено 4 года и 450 млн дол. В начале пятого года компания-подрядчик выполнила половину работ и израсходовала 95% бюджета. По оценкам экспертов ей бы потребовалось еще 350 млн. и 6-8 лет для завершения проекта.

Когда в начале 2010 г. каскадную модель сменила работа в скрам-командах, производительность разработчиков увеличилась втрое и 2 июля 2012 года «Стражем» пользовались сотрудники ФБР во всех штатах.

Приложения

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

Простой интуитивно понятный для работы над проектами и решения различных задач бизнеса.

Worksection сейчас дорабатывает и тестирует перед внедрением (на октябрь 2017) фишки для 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 прямо сейчас

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

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

О нас

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