Про Agile я уже рассказывал, пора рассказать про SCRUM. На самом деле это не аббревиатура, а название одного из элементов игры в регби, когда обе команды сбиваются в могучую кучку, чтобы поделить мяч и перезапустить игру. Столь забавное название получила практика разработки, представленная в 1995 году, более двадцати лет назад.
Scrum родился в недрах корпорации Easel, которая несколькими годами ранее безуспешно создавала среду разработки Smalltalk. По задумке авторов, продукт должен был превращать красивые блок-схемы в код, а код — обратно в красивые блок-схемы. Уже тогда проблемы сложности и нулевой цены копирования довлели над разработчиками, приводя к срыву сроков и очень огорчая руководство. Им было с чего огорчаться: каждый месяц задержки запланированной версии приводил к потерям миллионов долларов.
Автор Scrum, Джеф Сазерленд, во время встречи с CEO Easel на пальцах объяснил, что многолетнее планирование классического waterfall просто не может работать в условиях неопределенности, новых задач и меняющихся требований. В числе его аргументов было то, что при классической модели разработки у CEO не было возможности понять, что что-то идет не так в середине работы. Проблемы всплывали в самом конце, когда уже не было возможности что-то поменять. И компания теряла деньги.
Джеф предложил разделить разработку на «спринты» длиной в месяц. В рамках каждого спринта команде ставилась достижимая цель, в течение месяца никто не мешал им работать, а в конце месяца готовый продукт был готов к отправке пользователям. Такая модель разработки устраняла главный страх CEO: срыв сроков. В конце каждого месяца CEO получал улучшенную версию готового продукта, который он мог отправить в релиз или же запустить следующий спринт для доработки и добавления новых функций.
Выслушав эту идею, CEO принял решение в течение 60 секунд. Через два года, в рамках конференции «OOPSLA’95» Джеф Сазерленд и Ке Швабер представили миру методологию, которую назвал Scrum. Название было заимствовано из работы «The New New Product Development Game» (нет, не опечатка, действительно два new подряд), опубликованной в 1986 году японскими учеными, в которой были описаны приемы создания самодостаточной, эффективной команды.
Анатомия Scrum
Как работает Scrum? В начале проекта команда составляет список высокоуровневых задач: product backlog. Это «видение» продукта на начальном этапе, примерный список того, что мы хотим получить в конце. Далее из этого списка выбираются несколько задач на первый спринт, устоявшаяся длительность которого сейчас составляет от 1 до 2 недель. Эти несколько задач делятся на маленькие задачи, выполнение каждой из которых не должно занять больше дня: sprint backlog. В течение спринта участники команды берут по одной задаче из sprint backlog и выполняют их, всячески помогая друг другу. Близкая цель, «общий» пул небольших задач и утренние stand up совещания психологически сплачивают коллектив, делая совместную работу крайне эффективной. Задача команды не просто реализовать взятые фичи, но сделать готовую версию продукта, которую можно отдавать пользователям. В конце спринта эта версия показывается заказчику, он вносит коррективы в product backlog и запускает следующий спринт — до тех пор, пока он не примет решение релизить текущую версию. Или не кончится бюджет.
Выбор задач на текущий спринт нетривиален. Если взять слишком много задач, то команда не сможет выполнить их в срок. Это крайне негативно скажется на боевом духе коллектива и деградирует процесс до непредсказуемых сроков, от которых он как раз призван защищать. Если взять слишком мало задач, то скорость разработки будет крайне низка и боевой дух команды будет опять подорван отсутствием работы в оставшееся до конца спринта время. Чтобы брать нужное количество задач, в Scrum предусмотрено два действия: planning poker и ретроспектива. В начале каждого спринта команда оценивает и дробит задачи на основании условных единиц сложности, так называемых «story points». А в конце спринта анализирует скорость своей работы, возникшие проблемы и принимает решение сколько «story points» брать на следующий спринт. Во время самого спринта используется специальная доска с тикетами и график выполнения задач, «burndown chart». Все красиво и со вкусом.
При чем тут микроскоп и гвозди?
Как вы видите, Scrum построен на идее «итераций» из гибких методологий. Которая, как я уже писал в предыдущих колонках, очень хороша. Но в чем отличие Scrum от простого «ставим промежуточную цель, выделяем к ней мешок задач и выполняем их пока цель не достигнута»? Можно выделить следующие свойственные Scrum’у механики:
- фиксированная длина спринта;
- оценка сложности задач;
- анализ «скорости» работы команды и корректирование оценок;
- сопротивление к новым задачам во время спринта.
Зачем это все было сделано? Вспомним как появился Scrum, какая основная проблема стояла перед компанией Easel. Срыв сроков. Все эти механики служат одной цели — максимизировать шансы на получение ожидаемого результата в конце спринта.
Хорошо это или плохо? Для Easel двадцать лет назад — безусловно хорошо. В те времена выпуск новых версий программ для крупных компаний было целой большой историей. Реклама в профильных журналах, пресс-конференции, выпуск коробок, печать обучающих материалов, подготовка очных курсов… Все это занимало много времени и требовало синхронизации за много месяцев до выпуска готового продукта. Сейчас все не так. Интернет стал основным каналом распространения для большинства программ, глобализация на порядок сократила цену многих процессов, общение с клиентами и быстрая реакция на изменения рынка стали намного важнее, чем выпуск продукта к фиксированной дате.
Цена вопроса
Разработка программ — это большая область. Разница между созданием компьютерной игры и драйвера для встраиваемого устройства колоссальна. Мне трудно оценить, в каких областях сейчас главным критерием является соблюдение сроков. На мой взгляд, таких областей довольно мало. Scrum, тем не менее, применяется во множестве компаний почти для всех типов задач, начиная от разработки сайтов и заканчивая системной интеграцией.
Это приводит к очень интересным последствиям. Scrum решает вопрос со сроками совсем не бесплатно. И в жертву приносится не только время работы, которое тратится на planning poker и ретроспективы. В конце концов, это занимает не так много времени. А утренние stand up совещания полезны сами по себе — в одной из следующих колонок я обязательно расскажу почему.
Самая большая цена, которую платит команда за Scrum — это требование универсальности специалистов. Чтобы работала оценка в story point’ах, считалась velocity и сгорал burndown chart, каждый боец команды должен уметь оценить и выполнить любую из задач по проекту. Двадцать лет назад это был само собой разумеющимся фактом — большинство разработчиков знали один язык программирования и один стек технологий, в команду нанимали «20 C++ программистов под unix», которые имели похожий набор навыков. Сейчас все совсем не так. Развитие технологий породило узкую специализацию: Android разработчик не сможет оценить сложность разработки под iOS, и оба они никак не помогут frontend или backend разработчикам с их задачами. Причем «никак» от слова «вообще никак» — у них не только разные языки программирования, но и разные toolchain. Без нескольких дней чтения документации они даже собрать проекты друг друга не смогут без посторонней помощи. В большинстве «внедрений» Scrum, которые я видел, planning poker превращается в профанацию — каждую задачу может оценить один, максимум два-три специалиста, остальные кидают на стол карты «а фиг его знает сколько это займет времени». Sprint backlog перестает быть общим — большинство задач также могут выполнять строго определенные люди, что порождает постоянный дисбаланс и попытки «докрутить» методологию под объективную реальность.
Понимание этой цены позволяет опытным тим лидам не внедрять «Scrum по книжке», а адаптировать процессы под конкретные задачи и команды. Используются лучшие практики: итерации, backlog, утренний standup и демонстрация в конце спринта, ретроспектива для анализа «что можно было сделать лучше». А неработающие практики, такие как planning poker или рассчет velocity, выкидываются или модифицируются. Понимание почему в методологиях разработки сделаны те или иные штуки — ключ к победе над сложностью и неизвестностью. Старайтесь почаще задаваться вопросом «почему это сделано именно так» — в ответе на него кроется возможность стать лучшим разработчиком и создавать потрясающие программы.