8 июня 2017   •   Ольга Гранько   •   23 min read

Scrum или не-Scrum - какой
подход выбрать?

Как закалялся scrum: происхождение и применение методологии

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

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

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

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

Scrum - схватка в регби

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

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

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

Scrum статистика

Scrum VS Agile VS Waterfall

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

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

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

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

Scrum

Agile

Философия

-

+

Методология

+

-

Ритуалы

+

-

Роли

+

-

Артефакты* / Создаваемые объекты

+

-

Прозрачность

+

+

Короткие итерации

+

+

Частые релизы

+

+

Учет изменений

+

+

Постоянное улучшение

+

+

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

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

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

Waterfall

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

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

Роли в скраме

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

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

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

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

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

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

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

Заказчик

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


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

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

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

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

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

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

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

  1. что я делал вчера, чтобы команда добилась цели?
  2. что я буду делать сегодня, чтобы команда добилась цели?
  3. что мешало мне выполнять работу?

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Покер планирования в scrum

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

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

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

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

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

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

Что почитать, чтобы лучше разобраться в скраме

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

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

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

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

Скрам Джефф Сазерленд Роман Пихлер

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

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

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

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

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

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

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

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

  1. Прозрачность. В команде открытый обмен информацией, знаниями, проблемами, каждый чувствует себя причастным к общей цели. Заказчик всегда в курсе хода работ, вносит правки в процессе, получает достоверную информацию о сроках сдачи.
  2. Автономность команд. Члены команды сами решают, как работать над проектом, свобода действий и ответственность мотивируют. Заказчик передает требования команде напрямую, без испорченного телефона.
  3. Мотивация результатом. Концепция скрама позволяет каждому члену группы видеть свои и общие достижения ежедневно. Заказчик получает прирост функциональности с каждой итерацией.
  4. Минимизация рыночных рисков. Команда оперативно реагирует на изменение требований к проекту и не делает лишнюю работу. Заказчик получает то, что хочет, и что востребовано на рынке.
  5. Минимизация финансовых рисков. На устранение багов и добавление функционала тратится мало времени и средств, все вкладываются в бюджет.

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

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

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

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

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

Scrum-компании

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

Salesforce.com

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

Amazon

Amazon

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

Spotify

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

Microsoft

Microsoft

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

Интересные Scrum-проекты

eduScrum

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

eduScrum

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

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

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

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

Приложения

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

Worksection

Worksection

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

Worksection сейчас дорабатывает и тестирует перед внедрением (на октябрь 2017) фишки для scrum: диаграммы сгорания задач и бэклог — чисто скрамовские инструменты. Возможно будет и покер планирования. Наш консультант в этом деле, Виталий Цимбалюк, предпочитает свою колоду для скрам-покера — с Бэтменом.

Уже сейчас в Worksection можно:

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

Scrumdo

Scrumdo

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

Вердикт

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

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

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

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

Книги для статьи предоставлены kniga.biz.ua

ответить
Дмитрий 23 сентября 2017
≻Worksection пока что не настроен точно на работу по scrum [...] Бэклог продукта и бэклоги спринтов создаются как отдельные проекты

Пожалуйста, реализуйте Kanban и Scrum доски для проектов!
ответить
Валерий 7 октября 2018
Канбан доски реализовали
ответить
Владимир 11 мая 2018
Я пользовался ворксекшн как заказчик - не удобно, реально есть только переписка с исполнителем. Или команда не сумела настроить все фичи...
ответить
Программист 8 января 2019
Скрам хорош для создания продукта, но не поддержки, я видел проекты посе скрама, все состоит из говно кода , потому что "А надо все успеть быстро, задача стоит, надо закрыть а то я плохой спецаилист и подставлю команду"
ответить
Виталий 15 января 2019
Говорить можно очень много. Видел образцовые проекты, в которых и в помине не было никакого скрама. Видел ужасные скрам-проекты. Динамика развития IT (повсеместное снижение качества продуктов, проблемы с адекватной документацией, выгорание сорудников и т.д. и т.п.) говорит о том, что "что-то не так в датском королевстве" (С). Не хочу начинать холивар на эту тему - просто не вижу смысла...
Вот это реально посмешило: "Мотивация уже заложена внутрь скрама, а при поддержке руководства скрам команды увеличивают производительность в несколько раз". Не о деливери-менеджерах случайно речь идет (очень модная фишка в последнее время; впрочем, абсолютно предсказуемая)? Которые приходят за пару дней до демо и говорят что-то типа: "А мне пофиг, что у вас скрам. Чтобы к понедельнику было это и это. Можете работать в выходные и по ночам!" (Ну просто классика скарма :))

Опубликовать

Бизнес-кейсы
Каждый руководитель должен контролировать работу команды, знать, что и когда происходит, кто и чем занимается, понимать, сколько на это требуется времени.
9 января 2019   •   5 min read
Бизнес-кейсы
Цель аккаунтинга — счастье клиента. Есть побочные плюшки, типа важной информации для специалистов или погашенной дебиторки, но это мелочи. Если клиент доволен — все будет хорошо, верно же?
13 июля 2018   •   6 min read
Бизнес-кейсы
Основатель агентства эффективного интернет-маркетинга Roman.ua Роман Рыбальченко о том, как удобно и эффективно выстраивать работу с клиентами и внутреннюю активность.
22 мая 2018   •   4 min read
Мы в соц-сетях
esc
Поделиться в
esc
Лучшая система управления проектами
Worksection
Попробовать бесплатно
уже есть аккаунт
Войти
Новинки Кейси PM Книги
Найти
Видео Диаграмма Ганта Отчёт План Интеграции Уведомления Еще 47...
Видео Диаграмма Ганта Отчёт План Интеграции Уведомления Бизнес процесс Проектный менеджмент Roman.ua Теория Рецензия Шесть Сигм Бережливое производство App Android IOS Задачи Календарь Связи Подзадачи UI Статусы Метки Отчёты Затраты Учёт времени Учёт финансов Горящие задачи Экспорт Фильтр Комментарии Сhecklist Таймер Документы Топ 10 Файлы Ответственный Поиск Безопасность Интервью Развитие команды Развитие лидера Саморазвитие Креативные команды Маркетинг команды IT команды Сервисные компании TOP 10 Рецензии Бизнес-процесс Акции Советы Партнерство Канбан
Лучшая система управления проектами
Worksection
Попробовать бесплатно
уже есть аккаунт
Войти