Как закалялся scrum: происхождение и применение методологии
Scrum — это авторская гибкая методология разработки с нестандартным распределением ролей в команде и уникальной организацией итераций. Scrum, как и другие agile методы управления задачами и проектами, исповедует командный подход, короткие итерации и непрерывное улучшение в процессе работы. Эти принципы реализуются через набор особых ролей, правил, процессов и инструментов, благодаря которым команды производят продукты вдвое быстрее.
В скрам-командах ключевые позиции занимают
scrum-master и product owner,
итерация начинается планированием,
на котором члены команды «играют»
в покер планирования,
и завершается демо с ретроспективой.
Scrum методология создана американцами Джеффом Сазерлендом, исследователем и бизнес-консультантом, и Кеном Швабером, практикующим программистом, в 1993 году. В 1995 году авторы концепции официально представили ее подходы на научной конференции Ассоциации вычислительной техники в Остине, Техас.
SCRUM — метод управления проектами. Обучающий мультик для вас и ваших сотрудников!
Идея соавторов скрама не была новой: и концепцию, и даже название они переняли из работы японских исследователей в сфере управления Такеучи и Нонака «Разработка нового продукта. Новые правила игры», опубликованной в 1986 году. Уже тогда японские производители использовали подходы, которые легли в основу скрама. А название методологии заимствовано из словаря игроков в регби. Scrum, или схватка, — элемент игры, показывающий важность командной работы для победы на поле.
Применение скрама в IT и не только
Впервые scrum был применен в компаниях, которые производят программное обеспечение. Первый проект, который Дж.Сазерленд курировал еще до официальной презентации скрама, — создание ПО для сети банкоматов (1983 г.). Команды программистов в IT компаниях и подразделениях до сих пор остаются главными потребителями scrum. Однако автор методологии настаивает, что скрам применим для решения любых задач, и приводит примеры использования скрама в производстве, строительстве, образовании, политике и даже при решении бытовых задач вроде генеральной уборки или организации праздника.
И действительно, по данным отчета Scrum Alliance за 2016 г. 21% проектов, выполненных по скраму, не имели отношения к сфере IT. Посмотрите, какие подразделения успешно используют scrum:
Scrum VS Agile VS Waterfall
Скрам относится к группе гибких методологий, или agile методологий. Agile — это не отдельная методология, а целая философия разработки ПО, ее основные подходы зафиксированы в Manifesto for Agile Software Development в 2001 году. В манифесте перечислены основные принципы agile — значимость команды, акцент на продукт, а не на документацию, прозрачность процессов, постоянное совершенствование, быстрый результат.
Как внедрить AGILE-технологию в сфере услуг? // Скрам для бизнеса // 16+
Скрам — это один из фреймворков agile, формализованная методология работы над проектами. К аджайл методологиям, кроме скрама, относятся и другие современные подходы. Альтернативой scrum могут быть XP, Kanban, Lean, Crystal, Rapid application development, Scrumban и другие. То есть скрам — это agile, но agile — не только скрам.
Представьте, что agile — это христианство, а scrum — одно из его течений, например, протестантизм. И хотя христиане в целом и протестанты в частности исповедуют одни и те же принципы, протестанты имеют свои уникальные ритуалы для проявления веры.
Источник: worksection.com
Что такое SCRUM
Эта заметка об управлении проектами в разработке (и в других областях жизни). Она понадобится тем, кому придётся работать в ИТ-компаниях или кто сам будет управлять командами.
Скрам вкратце
- SCRUM — это способ управлять проектами. Не единственный и не универсальный, просто один из многих. Часто используется в разработке софта.
- В скраме работа нарезается на небольшие циклы — итерации.
- В результате итерации должен получаться стабильный работающий продукт, который стал лучше, чем раньше.
- В конце итерации происходит ретроспектива: люди обсуждают прошедшую работу и думают, как ее улучшить. Так заведено.
- В скраме много внимания уделяется организации труда — чтобы всем было удобно работать, конфликты разрешались заранее и т. д.
- Скрам полезен в ИТ и для пошаговой разработки продукта. Но это не волшебная таблетка.
Для этой статьи нам понадобится чебурек:
Наша задача — вместо обычного чебурека придумать уникальное фирменное блюдо, которое должно понравиться большинству клиентов. Назовём это блюдо суперчебуреком.
Если перевести эту метафору в разработку — у нас есть некая версия нашего приложения и нам нужно сделать более совершенную версию этого же приложения: доработать, добавить, улучшить, прокачать. Как это делать?
Для этой задачи нам не подходит канбан, поскольку мы пока не знаем, каким будет суперчебурек или наше новое приложение. Вместо этого мы можем воспользоваться методом скрама, который как раз и придуман для подобных случаев. Давайте разбираться, что такое скрам и как им пользоваться.
Что есть SCRUM
Скрам, он же SCRUM — это один из способов управления проектом. Помимо скрама проект можно делать в порядке постановки задач, в алфавитном порядке, по степени важности задач, в авральном режиме, хаотично; можно делать проект с восьми утра до пяти вечера или круглосуточно; можно делать проект, пока не сгоришь; можно — по графику «два через два».
Скрам — просто ещё один способ структурировать работу над проектом. Смысл скрама — разбить работу на несколько маленьких кусочков, делать их последовательно и после каждого кусочка получать понятное и видимое улучшение продукта.
Ещё в скрам входят всевозможные ритуалы, артефакты и заклинания, но это лишь подспорье для основной мысли: мы улучшаем проект маленькими рывками.
Теперь посмотрим на основные компоненты скрама.
Бэклог — «что будем делать»
Работа в скраме начинается с формирования бэклога — списка задач, необходимых для разработки продукта. Эти задачи называются пользовательскими историями, и у них две особенности: они должны расставляться по приоритету и находиться на скрам-доске — физическом или виртуальном пространстве с колонками «Что сделать», «В процессе» и «Готово».
Бэклог составляет product owner — человек, который выслушивает пожелания заказчика, передаёт их команде и отвечает за выпуск продукта. Он же занимается оргвопросами и следит за тем, чтобы между сторонами не возникало конфликтов. В метафоре чебурека можно представить, что есть бизнес-заказчик — директор ресторана. И есть оунер — шеф-повар. Директор знает, что ему нужен суперчебурек.
Шеф отвечает за то, чтобы этот суперчебурек случился.
Что за сценарий
Хорошая практика — хранить в бэклоге не отдельные кнопки, фишки и возможности продукта, а именно сценарии. Например, если это мобильное приложение, то «пользователь может поделиться фотографией с друзьями» или «пользователь может войти через соцсети».
Когда мы пилим продукт по сценариям, мы можем выпускать их отдельно: например, сделали «пользователь входит через соцсети» и выпустили.
Хуже — когда вместо сценария у нас отдельное свойство или кусочки продукта. Например, не «пользователь может войти через соцсети», а «поддержка плагина авторизации VK». Это как бы часть сценария, но не весь сценарий — нужно ещё доделывать интерфейс, ошибки, подсказки и другие вещи. Если мы мыслим не сценариями, а отдельными кусочками, то у нас продукт всегда «недоготовлен».
Но такое сценарное мышление возможно не во всех продуктах.
Для простоты можно думать о сценарии так: «Можно ли выпустить новую версию продукта для пользователей, если реализовать только этот конкретный набор задач?» Если можно — условно можно назвать это сценарием. Пример с чебуреком: мы можем выкатывать в меню сначала чебурек новой формы, потом чебурек с новым цветом, потом новый размер чебурека и т. д.
Итерации — «рывок» проекта
Когда бэклог сформирован, команда оценивает силы и определяет длительность одной итерации. Итерация — это один рабочий «рывок», обычно в ИТ он занимает 1—3 недели.
Команде нужно посчитать, сколько пользовательских историй войдёт в одну итерацию и какое количество итераций понадобится. Например, если у нас пять историй с недельной итерацией, то на проект уйдёт пять недель.
Итерации в скраме — это то же самое, что и спринты в программировании. Подробно об этом мы рассказывали в отдельной статье.
Перед каждой итерацией команда составляет план работы над выбранными пользовательскими историями. Дополнительно проводятся ежедневные встречи, на которых каждый участник отвечает на три вопроса: что он уже сделал, какие проблемы и чем будет заниматься дальше. На встречи не должно уходить более 15 минут, поэтому численность скрам-команд всегда ограничена 5—9 участниками.
Встречи ведёт скрам-мастер — опытный член команды. Он выступает как менеджер: делает так, чтобы команда могла выполнить поставленную задачу, координирует людей и создаёт условия труда. Сломался ноутбук — скрам-мастер организует ремонт и найдёт новый на замену. Проблемы с дедлайном — скрам-мастер закупит кофе и поставит раскладушку в офис.
Инкремент — результат «рывка»
После каждой итерации команда должна выдать инкремент — промежуточную версию продукта, которая выносится на обсуждение с заказчиком. На встрече каждый участник команды отчитывается о проделанной работе, отвечает на вопросы и предлагает идеи по улучшению. В результате заказчик может принять инкремент, отправить его на доработку или досрочно закрыть проект.
В идеальной ситуации инкремент должен быть стабильной и рабочей версией продукта. Недопустимо, чтобы из-за новых сценариев в продукте начали отваливаться старые возможности (как это часто бывает). Поэтому тестирование и отладка продукта тоже закладывается в итерацию. Лучше сделать меньше, но более стабильно, чем взять много сценариев и получить сырой глючный продукт.
Это всё, конечно, в идеале. В жизни бывает по-всякому.
Ретроспектива
После первой итерации появляется обратная связь от заказчика — проще говоря, «правочки». Для её обсуждения предусмотрено отдельное командное собрание — ретроспектива. Для многих разработчиков это самая ненавистная часть скрама, потому что здесь тебе будут что-то говорить про твою работу, не всегда приятное.
Ретроспектива состоит из четырёх частей и проходит по следующему плану:
- Команда обозначает все положительные моменты предыдущей итерации. Например, продукт выпущен вовремя. В статье это может казаться очевидным, но в жизни даже это само по себе может быть предметом для гордости.
- Обсуждаем проблемы. В нашем случае хотели предложить заказчику десять вариантов формы чебурека, а успели подготовить только три.
- Накидываем идеи по улучшению рабочего процесса. Например, не давать таких оптимистичных обещаний.
- В конце составляется план по внедрению принятых идей.
Можно сказать, что задача ретроспективы — понять, что пошло не так в рабочем процессе, и исправить это. Фокус не на том, что кто-то пропустил баг на тестировании или неправильно обозвал переменную, а именно на том, как ставятся задачи и планируются следующие итерации.
Во время ретроспективы команда не ищет виновных — по умолчанию считается, что каждый участник сделал всё возможное для получения лучшего результата. Если что-то не получилось, то причина в обстоятельствах. Их нужно менять.
Ретроспектива происходит после каждой итерации. При этом важно, чтобы во время каждой следующей ретроспективы учитывались результаты предыдущей — это поможет следить за тем, чтобы продуктивность повышалась не только на бумаге.
Диаграмма сгорания
Для отслеживания прогресса в скраме используется диаграмма сгорания — это график, на котором видно, как быстро мы должны были исполнять задачи и как быстро мы их исполняем на самом деле. Можно было рисовать как угодно, но в скраме — так.
Критерии готовности
Скрам пытается решить одну из самых горьких проблем разработки: «Заказчик хотел одно, мы это сделали, а оказалось, что он хотел другое». В этот момент у разработчиков, дизайнеров и всех остальных должны наворачиваться слёзы.
Скрам пытается решить эту проблему, прописывая критерии готовности задачи. Заказчик и скрам-мастер должны постараться чётко описать видение результата: на что он должен быть похож, как работать и т. д.
Но это всё в теории и в идеальном мире. В реальности заказчик всё равно скажет: «Да, я написал, но сейчас ситуация изменилась и нужно сделать по-другому».
Критика SCRUM
Скрам критикуют за излишнюю ритуальность: вместо того чтобы спокойно работать и делать задачки, люди сидят на встречах и занимаются ретроспективным анализом собственной деятельности.
Скрам критикуют за модность: все его пытаются внедрить, не везде уместно и не везде правильно. Результат легко представить.
Скрам критикуют за то, что получается, когда его внедряют неграмотные управленцы. Когда ритуалы замещают полезную работу, это действительно печально.
Но здесь надо понимать, что критика скрама — это в первую очередь критика плохой реализации скрама и людей, которые неуместно его используют. Донт блейм зе гейм, блейм зе плейа.
Что там с чебуреком?
В идеальном мире прошло пять недель, и наши бойцы сделали суперчебурек, который без вопросов был принят руководителем и скрам-мастером. Презентация чебурека разлетелась по всем СМИ, тысячи людей встали в очередь на предзаказ, а чебуречная вышла на IPO.
В реальности фаундер чебуречной купил иномарку, попал на ней в аварию, инвесторы отказались финансировать проект, команда забрала наработки и разбежались кто куда: кто-то в крупные компании, другие — в стартапы, третьи бросили эту айтишную жизнь и переехали в село.
Потому что жизнь сложнее, чем представления скрам-мастера о ней.
Что дальше
Скрам — это гибкая методика, принципы которой подходят под разные проекты, будь это ИТ-компания или чебуречная. В статье мы рассмотрели общие положения, и для погружения в тему рекомендуем следующие ресурсы:
- Scrum.org — это сообщество скрам-тренеров, которые делятся контентом и предлагают курсы по скрам-подготовке.
- Scrumalliance.org — ещё одно крупное сообщество с бесплатными материалами, курсами для сертифицированных специалистов и скрам-конференциями по всему миру.
Дополнительно посмотрите интервью Павла Свиридова, который руководит бэкенд-разработкой и обращается с коллегами как настоящий скрам-мастер.
Источник: thecode.media
Технология скрам в бизнесе
Инкремент – это потенциально высвобождаемый результат спринта, который соответствует цели спринта. Инкремент должен быть завершен, в соответствии с определением готовности, данным командой Scrum, полностью функционирующим и в пригодном для использования состоянии, независимо от того, решит ли владелец продукта фактически развернуть и использовать его.
Если бэклог продукта представляет список дел для проекта, инкремент – это список всех элементов, которые были отмечены как выполненные. Элементы в инкременте должны быть помечены как «выполненные» в соответствии с общим определением Scrum-команды того, что представляет собой законченный выпуск.
Другие артефакты
Следующие артефакты и методы могут быть использованы на усмотрение команды.
- Диаграмма сгорания задач – количество сделанной и оставшейся работы относительно времени на разработку проекта или спринта.
- Определение готовности – критерии, помогающие определить, достаточно ли четко заданы спецификации и входные данные для запуска рабочего элемента.
- Скорость команды ( Velocity ) – общие усилия команды для одного спринта, полученные путем оценки работы, выполненной в последнем спринте.
- Spike – ограниченный по времени период, используемый для исследования концепции или создания простого прототипа.
События Scrum
Scrum-фреймворк основан на спринтах. Спринт – это фиксированный период времени, в течение которого Scrum-команда пытается реализовать определенную функцию или набор работ. В рамках Scrum проходят четыре основных мероприятия, и все они организованы вокруг спринта.
Планирование спринта
Каждый спринт представляет собой ограниченное по времени событие: он длится только определенную продолжительность, а затем завершается. В начале каждого спринта Scrum-команда проводит мероприятие по планированию спринта.
При планировании спринта решаются три важных задачи:
- определить цель спринта;
- выбрать элементы работы по продукту, которые способствуют достижению цели;
- решить, как будет выполняться выбранная работа.
Ежедневный Scrum
Цель ежедневного Scrum – проверить прогресс в достижении цели спринта и при необходимости адаптировать бэклог, корректируя предстоящую запланированную работу.
Разработчики могут выбирать любую структуру и методы, которые они хотят, при условии, что они фокусируются на прогрессе в достижении цели спринта. Совещание намеренно делается коротким, поскольку участники встают и разговаривают, а не сидят за столом в конференц-зале.
Обзор спринта
Цель обзора спринта – оценить и обновить артефакты Scrum и совместно определить следующие шаги. Scrum-команда представляет результаты своей работы ключевым заинтересованным сторонам, и обсуждает прогресс в достижении цели продукта.
Ретроспектива спринта
Цель ретроспективы спринта – проанализировать работу Scrum-команды за прошлый спринт и выявить любые возможности для улучшения, которые могут привести к лучшим результатам в будущем.
Применение Scrum
Одним из основных недостатков управления проектами является неопределенность результатов, поэтому сложно заранее гарантировать успех проекта до его завершения. Scrum обеспечивает итеративность, скорость и достаточную адаптивность, чтобы как можно скорее получить результаты в проекте, чтобы уменьшить разрыв между началом и окончанием.
Материалы по теме
- ✔️ Ключевые различия между Agile, Scrum и Kanban
- Scrum мастер и Agile Scrum: 20 вопросов собеседования
- Применение принципов Agile на практике
Источник: proglib.io