Объясняем на пальцах. Как использовать любимую методику разработчиков Кремниевой Долины
Представьте: регби, идет схватка вокруг мяча, игроки толкают друг друга, пытаясь добыть трофей. Этот процесс можно назвать английским словом Scrum. Оно обозначает один из подходов к разработке продукта, по смыслу похожий на спортивную игру.
Основа Scrum — это небольшая команда (5-7 человек), которая участвует в «спринтерских забегах» продолжительностью 1-4 недели (эти забеги так и называются — Sprint). Результатом каждого Sptint должен стать минимально работающий продукт. Scrum ориентирован на клиента и приветствует возможность вносить изменения в процесс в любой момент. Чтобы разобраться поглубже, рекомендуем почитать 10 фактов о подходе.
Scrum — это набор правил
Часто спрашивают: « А Agile и Scrum это одно и то же?» Правильный ответ такой: Scrum реализует на практике ценности Agile. Можно сказать, что Agile — это как конституция с основополагающими ценностями и принципами государства, а Scrum — это набор довольно подробных законов, через которые реализуется все описанное в конституции. Как всякий закон, правила Scrum нарушать нельзя. Если не будет выполнен хотя бы один из пунктов правил Scrum, то гибкости не будет, и ценности Agile невозможно будет реализовать.
Scrum — это прокладывание пути, а не сам путь
Следуя принципам Scrum продукт создается поэтапно, от простого к сложному. В первую очередь за короткий фиксированный срок создается «скелет», решающий очень простые задачи, но уже отвечающий самым важным потребностям. Проанализировав то, что получилось, приступают к новому этапу Sprint. Эти шаги повторяются до тех пор, пока не станет ясно, что дальше улучшать продукт не стоит — либо получится слишком дорого, либо набор функций уже достаточен.
Соберите всех вместе
«К пуговицам претензии есть?» — говорил известный персонаж из сатирической миниатюры Райкина. Мы помним ответ: «К пуговицам претензий нет», но главному герою от этого не легче — костюм ужасен. Одна из главных причин, почему это происходит, — дробление ответственности между отделами и специалистами и со всех сторон звучит: «Я свою работу сделал, а что там дальше — не моя ответственность». Как на эти вызовы отвечает Scrum: нужно использовать командный подход, когда все нужные специалисты объединены в малую команду, и на всех — одна общая бизнес-задача. Получается: либо все молодцы, либо все «завалили». В таких условиях становится невыгодно концентрироваться только на своей зоне ответственности. При этом, чтобы добиться синергии команда должна быть постоянна по своему составу.
Каждой команде — штатный психолог
Если людей собрать вместе и поставить общую задачу, это не значит, что они сразу начнут эффективно работать сообща. Могут даже разбежаться или находиться в постоянном конфликте друг с другом. У Scrum свой подход к этой проблеме: Scrum-мастер, который помогает команде. Он должен обладать навыками разрешения конфликтов, эффективной организации встреч, представлять интересы команды во вне (перед другими отделами или начальством), но при этом он не управляет командой и не ставит перед ней задачи. Он как штатный психолог — чутко следит за атмосферой и в сложных ситуациях выступает посредником, организуя процесс таким образом, чтобы сложная ситуация была разрешена мирно и конструктивно. Идеально, когда один Scrum-мастер отвечает за одну команду, но в крупных организациях из-за больших масштабов зачастую выделенные Scrum-мастера «окучивают» несколько команд.
Сконцентрируйте знания о продукте и приоритетах в одном человеке
Бывает так, что у продукта несколько заказчиков и они напрямую общаются с производителем. Их запросы противоречат друг другу. Чтобы избежать этого, Scrum требует наличия специальной роли — Product Owner. Это представитель заказчика в команде, который лучше всех разбирается в будущем продукте, согласовывает интересы заказчиков и представляет их перед производителем. При этом у Product Owner есть право обоснованно говорить «нет» заказчикам: если, например, они просят «перламутровые пуговицы», а мы делаем костюм химической защиты для спасателей.
Прозрачность процесса
Scrum предлагает пользоваться «доской задач», которая доступна всем, и на ней каждый день актуализируется статус работ. Прозрачность, в свою очередь, — это инструмент контроля. Команда знает, что она на виду и прогресс ее работы виден всем и каждому. Это стимулирует ее поддерживать постоянный ритм, но избавляет от микроконтроля со стороны вышестоящих руководителей или заказчика. «Доска задач» представляет собой три колонки: To Do, In Progress, Done. В каждой из них располагаются карточки задач в соответствии с их текущим прогрессом.
Постоянное улучшение процесса и решение проблем
Уильям Деминг — основоположник системы «встроенного качества» утверждал, что 94% причин плохого качества продукта, задержек и простоев связаны с несовершенством рабочего процесса и только 6% имеют в своей основе человеческую природу (ошибки и плохая работа сотрудников). Scrum следует принципам Деминга и предусматривает специальный процесс «непрерывного улучшения» и сбора обратной связи от команды. В конце каждого спринта проходит специальная встреча, когда команда, представитель заказчика (Product Owner) и Scrum-мастер вспоминают, что происходило в течение Sprint, выявляют, что помогало достигать результата, а что мешало. По итогам создается план изменений, и команда берет на себя обязательство реализовать его за следующий Sprint.
Беклог вместо технического задания (ТЗ)
Обычно работа производителя начинается с подробного ТЗ заказчика, но оно зачастую оказывается бесполезным при первом же изменении внешних условий или потребностей заказчика. Scrum требует формировать конкретные задачи небольшого размера так, чтобы по итогам выполнения любой из них заказчик получал пользу, а клиент мог пользоваться результатом. Этот список задач называется беклог (backlog). «Владеет» им Product Owner как лицо наиболее сведущее и заинтересованное в развитии продукта. Основное назначение беклога — он должен представлять собой последовательность задач, выстроенных по приоритету.
Прямая коммуникация вместо бумаги и переписки
Живое общение позволяет передать гораздо больше информации в единицу времени, чем самое подробное письмо. За пять минут люди смогут договориться и однозначно понять друг друга гораздо в большем объеме, чем если это делать через письмо или документ. С другой стороны, когда производителя постоянно отвлекают вопросами, дело тоже будет двигаться очень медленно.
Поэтому в Scrum предусмотрен ряд обязательных встреч для личного общения:
- планирование работ в начале Sprint (2-3 часа),
- ежедневный стендап для синхронизации и вскрытия проблем (до 15 минут),
- демонстрация результатов в конце Sprint (1-2 часа),
- ретроспектива в конце этапа для анализа рабочего процесса и его улучшения (1-2 часа).
В среднем на эти мероприятия уходит около 8-10 часов чистого времени в ходе Sprint.
Оценивайте трудоемкость, а не время
Обычно работу оценивают по времени, которое она занимает. Хорошо, если у нас однотипные задачи, которые делает один специалист. Но если у нас командная работа, то вопрос «Сколько времени займет эта работа?» может вылиться в многочасовой жаркий спор. Scrum предлагает для простоты использовать систему размеров для одежды — Small (S), Medium(M), Large(L), Extended Large (XL), и присвоить задачам эти оценки относительно друг друга. Далее можно присвоить каждому из размеров какое-то цифровое обозначение, например S = 1, M=3, L=8, XL=13. Тогда можно просуммировать оценки и получить общую цифру трудоемкости, которую команда намерена взять в работу в текущем спринте. Эту сумму в Scrum называют «скорость команды». Отслеживая и анализируя эту цифру от спринта к спринту, можно увидеть, каков средний уровень «скорости команды».