Эта заметка об управлении проектами в разработке (и в других областях жизни). Она понадобится тем, кому придётся работать в ИТ-компаниях или кто сам будет управлять командами.
Скрам вкратце
- SCRUM — это способ управлять проектами. Не единственный и не универсальный, просто один из многих. Часто используется в разработке софта.
- В скраме работа нарезается на небольшие циклы — итерации.
- В результате итерации должен получаться стабильный работающий продукт, который стал лучше, чем раньше.
- В конце итерации происходит ретроспектива: люди обсуждают прошедшую работу и думают, как ее улучшить. Так заведено.
- В скраме много внимания уделяется организации труда — чтобы всем было удобно работать, конфликты разрешались заранее и т. д.
- Скрам полезен в ИТ и для пошаговой разработки продукта. Но это не волшебная таблетка.
Для этой статьи нам понадобится чебурек:
Наша задача — вместо обычного чебурека придумать уникальное фирменное блюдо, которое должно понравиться большинству клиентов. Назовём это блюдо суперчебуреком.
Если перевести эту метафору в разработку — у нас есть некая версия нашего приложения и нам нужно сделать более совершенную версию этого же приложения: доработать, добавить, улучшить, прокачать. Как это делать?
Для этой задачи нам не подходит канбан, поскольку мы пока не знаем, каким будет суперчебурек или наше новое приложение. Вместо этого мы можем воспользоваться методом скрама, который как раз и придуман для подобных случаев. Давайте разбираться, что такое скрам и как им пользоваться.
Что есть SCRUM
Скрам, он же SCRUM — это один из способов управления проектом. Помимо скрама проект можно делать в порядке постановки задач, в алфавитном порядке, по степени важности задач, в авральном режиме, хаотично; можно делать проект с восьми утра до пяти вечера или круглосуточно; можно делать проект, пока не сгоришь; можно — по графику «два через два».
Скрам — просто ещё один способ структурировать работу над проектом. Смысл скрама — разбить работу на несколько маленьких кусочков, делать их последовательно и после каждого кусочка получать понятное и видимое улучшение продукта.
Ещё в скрам входят всевозможные ритуалы, артефакты и заклинания, но это лишь подспорье для основной мысли: мы улучшаем проект маленькими рывками.
Теперь посмотрим на основные компоненты скрама.
Бэклог — «что будем делать»
Работа в скраме начинается с формирования бэклога — списка задач, необходимых для разработки продукта. Эти задачи называются пользовательскими историями, и у них две особенности: они должны расставляться по приоритету и находиться на скрам-доске — физическом или виртуальном пространстве с колонками «Что сделать», «В процессе» и «Готово».
Бэклог составляет product owner — человек, который выслушивает пожелания заказчика, передаёт их команде и отвечает за выпуск продукта. Он же занимается оргвопросами и следит за тем, чтобы между сторонами не возникало конфликтов. В метафоре чебурека можно представить, что есть бизнес-заказчик — директор ресторана. И есть оунер — шеф-повар. Директор знает, что ему нужен суперчебурек. Шеф отвечает за то, чтобы этот суперчебурек случился.
Что за сценарий
Хорошая практика — хранить в бэклоге не отдельные кнопки, фишки и возможности продукта, а именно сценарии. Например, если это мобильное приложение, то «пользователь может поделиться фотографией с друзьями» или «пользователь может войти через соцсети».
Когда мы пилим продукт по сценариям, мы можем выпускать их отдельно: например, сделали «пользователь входит через соцсети» и выпустили.
Хуже — когда вместо сценария у нас отдельное свойство или кусочки продукта. Например, не «пользователь может войти через соцсети», а «поддержка плагина авторизации VK». Это как бы часть сценария, но не весь сценарий — нужно ещё доделывать интерфейс, ошибки, подсказки и другие вещи. Если мы мыслим не сценариями, а отдельными кусочками, то у нас продукт всегда «недоготовлен».
Но такое сценарное мышление возможно не во всех продуктах.
Для простоты можно думать о сценарии так: «Можно ли выпустить новую версию продукта для пользователей, если реализовать только этот конкретный набор задач?» Если можно — условно можно назвать это сценарием. Пример с чебуреком: мы можем выкатывать в меню сначала чебурек новой формы, потом чебурек с новым цветом, потом новый размер чебурека и т. д.
Итерации — «рывок» проекта
Когда бэклог сформирован, команда оценивает силы и определяет длительность одной итерации. Итерация — это один рабочий «рывок», обычно в ИТ он занимает 1—3 недели.
Команде нужно посчитать, сколько пользовательских историй войдёт в одну итерацию и какое количество итераций понадобится. Например, если у нас пять историй с недельной итерацией, то на проект уйдёт пять недель.
👉 Итерации в скраме — это то же самое, что и спринты в программировании. Подробно об этом мы рассказывали в отдельной статье.
Перед каждой итерацией команда составляет план работы над выбранными пользовательскими историями. Дополнительно проводятся ежедневные встречи, на которых каждый участник отвечает на три вопроса: что он уже сделал, какие проблемы и чем будет заниматься дальше. На встречи не должно уходить более 15 минут, поэтому численность скрам-команд всегда ограничена 5—9 участниками.
Встречи ведёт скрам-мастер — опытный член команды. Он выступает как менеджер: делает так, чтобы команда могла выполнить поставленную задачу, координирует людей и создаёт условия труда. Сломался ноутбук — скрам-мастер организует ремонт и найдёт новый на замену. Проблемы с дедлайном — скрам-мастер закупит кофе и поставит раскладушку в офис.
Инкремент — результат «рывка»
После каждой итерации команда должна выдать инкремент — промежуточную версию продукта, которая выносится на обсуждение с заказчиком. На встрече каждый участник команды отчитывается о проделанной работе, отвечает на вопросы и предлагает идеи по улучшению. В результате заказчик может принять инкремент, отправить его на доработку или досрочно закрыть проект.
👉 В идеальной ситуации инкремент должен быть стабильной и рабочей версией продукта. Недопустимо, чтобы из-за новых сценариев в продукте начали отваливаться старые возможности (как это часто бывает). Поэтому тестирование и отладка продукта тоже закладывается в итерацию. Лучше сделать меньше, но более стабильно, чем взять много сценариев и получить сырой глючный продукт.
Это всё, конечно, в идеале. В жизни бывает по-всякому.
Ретроспектива
После первой итерации появляется обратная связь от заказчика — проще говоря, «правочки». Для её обсуждения предусмотрено отдельное командное собрание — ретроспектива. Для многих разработчиков это самая ненавистная часть скрама, потому что здесь тебе будут что-то говорить про твою работу, не всегда приятное.
Ретроспектива состоит из четырёх частей и проходит по следующему плану:
- Команда обозначает все положительные моменты предыдущей итерации. Например, продукт выпущен вовремя. В статье это может казаться очевидным, но в жизни даже это само по себе может быть предметом для гордости.
- Обсуждаем проблемы. В нашем случае хотели предложить заказчику десять вариантов формы чебурека, а успели подготовить только три.
- Накидываем идеи по улучшению рабочего процесса. Например, не давать таких оптимистичных обещаний.
- В конце составляется план по внедрению принятых идей.
Можно сказать, что задача ретроспективы — понять, что пошло не так в рабочем процессе, и исправить это. Фокус не на том, что кто-то пропустил баг на тестировании или неправильно обозвал переменную, а именно на том, как ставятся задачи и планируются следующие итерации.
Во время ретроспективы команда не ищет виновных — по умолчанию считается, что каждый участник сделал всё возможное для получения лучшего результата. Если что-то не получилось, то причина в обстоятельствах. Их нужно менять.
Ретроспектива происходит после каждой итерации. При этом важно, чтобы во время каждой следующей ретроспективы учитывались результаты предыдущей — это поможет следить за тем, чтобы продуктивность повышалась не только на бумаге.
Диаграмма сгорания
Для отслеживания прогресса в скраме используется диаграмма сгорания — это график, на котором видно, как быстро мы должны были исполнять задачи и как быстро мы их исполняем на самом деле. Можно было рисовать как угодно, но в скраме — так.
Критерии готовности
Скрам пытается решить одну из самых горьких проблем разработки: «Заказчик хотел одно, мы это сделали, а оказалось, что он хотел другое». В этот момент у разработчиков, дизайнеров и всех остальных должны наворачиваться слёзы.
Скрам пытается решить эту проблему, прописывая критерии готовности задачи. Заказчик и скрам-мастер должны постараться чётко описать видение результата: на что он должен быть похож, как работать и т. д.
Но это всё в теории и в идеальном мире. В реальности заказчик всё равно скажет: «Да, я написал, но сейчас ситуация изменилась и нужно сделать по-другому».
🔥 Критика SCRUM
Скрам критикуют за излишнюю ритуальность: вместо того чтобы спокойно работать и делать задачки, люди сидят на встречах и занимаются ретроспективным анализом собственной деятельности.
Скрам критикуют за модность: все его пытаются внедрить, не везде уместно и не везде правильно. Результат легко представить.
Скрам критикуют за то, что получается, когда его внедряют неграмотные управленцы. Когда ритуалы замещают полезную работу, это действительно печально.
Но здесь надо понимать, что критика скрама — это в первую очередь критика плохой реализации скрама и людей, которые неуместно его используют. Донт блейм зе гейм, блейм зе плейа.
Что там с чебуреком?
В идеальном мире прошло пять недель, и наши бойцы сделали суперчебурек, который без вопросов был принят руководителем и скрам-мастером. Презентация чебурека разлетелась по всем СМИ, тысячи людей встали в очередь на предзаказ, а чебуречная вышла на IPO.
В реальности фаундер чебуречной купил иномарку, попал на ней в аварию, инвесторы отказались финансировать проект, команда забрала наработки и разбежались кто куда: кто-то в крупные компании, другие — в стартапы, третьи бросили эту айтишную жизнь и переехали в село.
Потому что жизнь сложнее, чем представления скрам-мастера о ней.
Что дальше
Скрам — это гибкая методика, принципы которой подходят под разные проекты, будь это ИТ-компания или чебуречная. В статье мы рассмотрели общие положения, и для погружения в тему рекомендуем следующие ресурсы:
- Scrum.org — это сообщество скрам-тренеров, которые делятся контентом и предлагают курсы по скрам-подготовке.
- Scrumalliance.org — ещё одно крупное сообщество с бесплатными материалами, курсами для сертифицированных специалистов и скрам-конференциями по всему миру.
Дополнительно посмотрите интервью Павла Свиридова, который руководит бэкенд-разработкой и обращается с коллегами как настоящий скрам-мастер.
