Скрам (от англ. Scrum, «схватка») — это методология совместной командной работы над проектом (в основном это разработка ПО), которая отличается гибкостью, разбивкой главной задачи на несколько кратких этапов, нестандартным распределением ролей в команде. Простыми словами, Scrum — современная и гибкая модель работы над проектом.
Как работает Scrum: основы и устройство
До появления методологии Scrum работа над проектами велась в основном по каскадной модели, или модели «водопад». Например, классическая разработка состоит из четырех этапов:
- Планирование.
- Разработка.
- Тестирование.
- Продакшн.
Так вот, по каскадной модели ни один этап не мог быть начат, пока не будет закончен предыдущий. Все идет строго по плану, и только так: невозможно представить, что на этапе тестирования придется опять вернуться к разработке, а потом еще и план немного поменять.
Но ведь в реальной жизни часто так и бывает! Разработка — процесс динамичный, этапы могут перетекать друг в друга, меняться. Для этого и был придуман Скрам, где работа над этапами происходит параллельно.
Скрам-команда создает продукт по частям. Абсолютно любой этап можно довести до релиза, даже если предшествующие ему еще не закончены. Участники команды работают на разных стадиях проекта и одновременно друг с другом.
Еще одно отличие — работа по Scrum поделена на короткие циклы, или спринты. В течение одного спринта команда должна работать над достижением конкретной цели.
Например, разработка сайта делится на несколько спринтов. Результатом первого спринта будет создание прототипов. Результатом второго — верстка, третьего — интеграция с нужными системами и сервисами и так далее. Длится типичный спринт не больше двух недель.
Состав команды Scrum
Этот подход предусматривает особые взаимоотношения в команде: здесь есть собственные ролевые системы. Интересно, что помимо разработчиков, над проектом активно работает и сам заказчик, или владелец продукта. Еще более интересно, что нет ярко выраженной иерархии: все члены команды равноправны и работают на один результат. Соответственно, за результат в целом отвечает вся команда, а каждый ее член — за свой участок работы.
Элемент самоуправления делает команды максимально самостоятельными в своих решениях. Команда сама решает,какую задачу она будет выполнять, в каком порядке, какими методами и когда устанавливать дедлайн (последнее часто, но не всегда).
Рассмотрим основные роли в команде.
Скрам-мастер. Часто это не сотрудник компании, его привлекают со стороны. Мастер не управляет разработчиками напрямую — лишь мягко задает направление и решает управленческие задачи:
- Отвечает за эффективность процессов — оптимизирует их, убирает факторы, которые затормаживают процесс разработки.
- Планирует и проводит групповые встречи с командой.
- Решает возникающие проблемы.
- Проводит коучинг членов команды.
Владелец продукта. В его обязанности входит:
- Коммуникации с клиентами, спонсорами, иными лицами, которые связаны с продуктом.
- Общение с командами, например, донесение требований заказчика к продукту, если эти требования меняются в процессе работы.
- Составление бэклога (упорядоченного по важности списка задач или конкретных работ).
Разработчики. Это специалисты (как правило, их несколько в одной команде), которые создают исправно работающий продукт по завершению каждого спринта. Помимо этого в их обязанности входят следующие задачи:
- Прокачивание профессиональных навыков.
- Генерация бэклога для каждого спринта.
- Соблюдение целей и критериев рабочих процессов, включая спринты.
Стоит отметить, что типичная команда Скрам, как правило, не превышает 10-12 человек. Существуют даже специальные исследования, которые говорят о том, что небольшие команды эффективнее крупных. Если команда больше 12 человек, то согласно методологии ее нужно разбить на мелкие единицы — с учетом, что команда справится с объемом поставленных задач.
Процесс работы в Scrum
Каждый спринт делится на несколько этапов: от бэклога продукта до конечного результата (инкремента).
- Бэклог продукта. Это список всех задач, который необходимо сделать в проекте. Владелец продукта собирает все данные о нем, сортирует их по важности, затем составляет ТЗ согласно требованиям заказчика.
- Бэклог спринта. Это часть бэклога продукта — список задач для конкретного спринта и определение его цели. Для каждого спринта планируется предварительный объем работ и методы, которыми будет выполняться спринт. Отвечает за этап планирования спринтов скрам-мастер.
- Собственно спринт, который включает в себя работу над проектом в рамках поставленных задач. Ежедневно проводятся короткие планерки, так называемые стендапы или митинги, где члены команды получают задачи, отчитываются о сделанном, обсуждают возможные проблемы и думают, как их решить. Каждый член команды отвечает на несколько вопросов. Чаще всего их три: «Что вы делали вчера?», «Что будете делать сегодня?», «Что помешало выполнить цель ранее?».
- Получение результата, или инкремента. По завершении каждого спринта подводятся их предварительные итоги. На этом этапе команда решает, удалось ли достичь цели, насколько работоспособен полученный результат, можно ли демонстрировать его заказчику или надо доработать.
- Демонстрация достигнутых задач и результатов. На финальном этапе происходит показ выполненных задач. При этом принимается решение: отправлять продукт в продакшн или допиливать его далее.
- Ретроспектива. Члены команды оглядываются назад, на все законченные к этому моменту спринты, обсуждают выполненные задачи, думают, какие моменты можно улучшить и каким образом.
Случается и такое, что итоговый результат спринта нерелевантен тому, что был заявлен в начале. В таком случае происходит коррекция рабочих процессов, а в некоторых случаях изменяется видение задач, изложенных в бэклоге.
В отличие от других систем разработки, в Скрам даже на промежуточных этапах инкремент должен оставаться работоспособным. Вот почему в каждой итерации предусматривается тщательная тестировка. Scrum-тестирование — это тип тестирования, которое выполняется для проверки выполнения сложных задач и процессов определенной программой.
В качестве альтернативы традиционным этапам владельцы продукта могут использовать классическую дорожную карту — для согласования релизов по календарю, если организация использует годовые, полугодовые, квартальные или ежемесячные релизы.
Обязательно различайте бэклог релиза (см. иллюстрацию выше) и бэклог самого спринта. Бэклог релиза — это функции, которые необходимо реализовать для конкретного релиза. Бэклог спринта — изначальная цель проведения спринта.
Как внедрить Scrum в компанию: советы бизнесу
- Соберите сильную команду. О разных ролях мы уже немного сказали в разделе «Состав команды». Напомним, это разработчики, владелец и Скрам-мастер. Особое внимание уделите поиску мастера: это должен быть человек, знающий все тонкости методологии, этакий мастер Йода, который научит всем премудростям и будет координировать работу членов команды.
- Визуализируйте работу. Скрам хорош тем, что все члены команды имеют подробное визуальное представление обо всех рабочих процессах. Как правило, разделяется три вида задач: в работе, в процессе и завершенные. При этом для непосредственной визуализации данных применяются как электронные, так и офисные доски.
Нельзя не сказать о нехватке квалифицированных специалистов, которая и сдерживает повсеместное распространение гибких моделей управления. По-настоящему крутых мастеров очень мало, а спрос растет изо дня в день: даже такие гиганты отрасли как Dell, IBM, HP постоянно ищут сильных Scrum-мастеров. Согласно payscale.com, средняя зарплата профессионалов в Agile и Scrum находится в диапазоне от 107 000 до 126 000 долларов.
Чтобы вести работу в досках онлайн, сделайте следующее:
- Выберите менеджер проектов для командной работы. Это инструмент, который позволяет работать нескольким членам одной команды вместе онлайн (прямо в браузере или в отдельно устанавливаемой программе). Наиболее подходящие сервисы для командного управления проектами — Flowlu, Worksection, Wrike, YouGile. Если боитесь блокировок, то воспользуйтесь их российскими аналогами: «Мегаплан», «Штаб», «Планфикс», «Битрикс24». Хорошо раскрученные Jira и Trello подходят для гибкой управления проектами чуть меньше.
- Создайте несколько колонок, например: «Идеи», «В плане», «В работе», «Завершено», и карточки конкретных задач. Прикрепите участников команды, ответственных за конкретные задачи, к карточке, или попросите прикрепиться самостоятельно. Теперь они могут оставлять свои комментарии и идеи по предстоящей работе.
- Начинайте накидывать идеи. Для предварительного набрасывания идей можно отвести определенный дедлайн — например, 3 дня. Затем возьмите самые лучшие мысли из колонки «Идеи» и перемещайте их в колонку «В плане». Устанавливайте дедлайн, например, 2 недели.
- Впишите конкретные задачи в планирование на основе отобранных идей, при необходимости назначьте на них конкретных членов команды. Можно маркировать задачи исходя из срочности выполнения, сложности исполнения, требуемых навыков.
- Обязательно собирайте обратную связь у команды после окончания каждого спринта. В первую очередь спрашивайте сотрудников о времязатратах на решение конкретных задач. Такой фидбэк поможет в дальнейшем грамотно распределять время сотрудников, ведь от времени часто зависит и оплата проекта.
Обратите внимание: в соответствии с методологией Скрам на задачу не обязательно назначается конкретный участник команды. Ее берет тот, кто в состоянии справиться с ней наилучшим образом исходя из собственного опыта и навыков.
Преимущества и недостатки Scrum
У методологии есть немало плюсов. Вот наиболее важные:
- Работа выполняется командой разработчиков одновременно. Программисты пишут код «на лету» и не ждут руководителя или заказчика, которые дадут ответы на все вопросы. Разработчики могут приступить к написанию кода максимально быстро. В линейных моделях такая скорость программирования невозможна. Кроме того, благодаря сугубо собственным методам (например, парному кодингу) скорость и уровень знаний участников команды увеличиваются как минимум вдвое.
- Все рабочие процессы максимально гибкие, изменяемые в течение всего срока разработки проекта и даже после него. Изменения могут быть поддержаны и интегрированы в текущий проект, даже если среда постоянно меняется. Объем проекта, который должен быть выполнен, в Scrum является переменным, но при этом его время и стоимость — постоянны. Это существенное отличие от традиционного подхода, при котором область применения постоянна (изменения не допускаются, а если и допускаются, то крайне неохотно), но время и затраты — изменчивы. Вот такая инверсия рабочих процессов.
- Задачи расставляются по приоритетам и в порядке важности. Задачи, которые должны быть выполнены в первую очередь, вероятно, больше всего повлияют на возврат инвестиций. Определенные части продукта попадают на рынок быстрее, чем в традиционных проектах, где завершенная работа выпускается в продакшн в основном только в конце проекта.
- Команда разработчиков максимально сближается: они тесно взаимодействуют и придерживаются благородного девиза «все за одного и один за всех». Нет босса, который бы указывал — что, как, где, каким образом делать. Да, есть ScrumMaster, но это не босс, а защитник — он лишь наставляет и направляет членов команды. По всем этим причинам моральный дух и удовлетворенность работой в Скрам гораздо выше, чем в линейных / каскадных моделях управления проектами.
- Повышается удовлетворенность клиентов и пользователей продукта. Главная цель членов команды в спринте — как можно скорее завершить полезные сегменты приоритетной работы, которые будут иметь ценность для бизнеса. Да и пользователи быстрее получают пригодные для использования части готового продукта. Затем они могут протестировать их, дать фидбек. Это очень важно и часто недооценивается для успеха всего продукта. Пользователь обнаружил, что для выполнения работы необходимы изменения в его первоначальном запросе? Отлично! Проблем возникнуть не должно, ведь Scrum уже изначально рассчитан на адаптивность и быстрое внедрение изменений
Теперь о недостатках Скрам:
- Можно использовать не в каждой сфере. Скрам подходит не только для разработки — эту методологию используют и в бизнесе, и в маркетинге. Нельзя рекомендовать ее при работе с госзаказами, так как к ним всегда предъявляются ограничения по сроку готовности продукта).
- И не при любом бюджете. Модель нельзя рекомендовать, если речь идет о сверхограниченном бюджете. Поскольку отсутствуют точные показатели цены работ и есть риск выйти за рамки установленной стоимости.
- Сложность при юридическом оформлении документов. Так как ТЗ может сильно изменяться в процессе работы (как и сама среда разработки), прописать все этапы работ в договоре будет крайне затруднительно.
Бонус: что почитать, чтобы разобраться в Скрам
Напоследок предлагаем 8 книг, которые обязательно нужно прочитать, если вы хотите сделать Скрам своим инструментом. Собрали англоязычные и переведенные на русский язык книги:
- The Scrum Guide. Превосходный 16-страничный документ от создателей методологии, который можно скачать бесплатно.
- Scrum. Революционный метод управления проектами. Джефф Сазерленд составил великолепный сборник теории и практики. Несмотря на большое количество технической информации, книга легкая в плане восприятия и стиля.
- Путь скрам-мастера. Практичное, конкретное иллюстрированное и конкретное руководство от Зузаны Шоховой.
- Управление продуктом в Scrum. Роман Пихлер расскажет о тонкостях работы владельца продукта.
- Agile estimating and planning. Не столько о самой методологии, сколько о сложностях в традиционной разработке ПО.
- Scrum: потрясающе краткая инструкция и введение в Agile. Крис Симс рассказывает об опыте Scrum в реальном мире. Помогает с хронологией событий и приоритетами, которые недостаточно освещаются в других книгах.
- Scrum: The Art of Doing Twice the Work in Half the Time. Scrum Narrative and PSM Exam Guide — by mohammed. Дополнение к Scrum Guide, но более увлекательное по манере изложения. Наверное, одна из лучших книг по базовому Scrum со строгим соответствием канону методологии.
Комментарии