Как мы адаптировали SCRUM: кейс автоматизации «Академии современного образования А+»

Страшный сон команды разработчиков — нырнуть в незнакомую предметную область, оценить полусырую идею и дать твёрдое обещание уложиться в фиксированный срок за фиксированные деньги. На самом деле дать точную оценку неточных требований нереально. Мы пошли другим путём и рассказываем, как адаптировали классический SCRUM под реальный проект: игра в покер в офисе, выброшенный функционал, «брутальный редактор» для завуча, огромные чертежи на стенах, живая лента вместо десятка мессенджеров, а ещё маркеры, стикеры и голосование точками.

Зачем SCRUM, когда требования неточны

Типичный путь в проектном менеджменте — составить как можно более детальное техническое задание до начала разработки, а затем реализовать весь функционал одним большим куском. Но такой «водопадный» подход несёт другие риски: заказчик видит первый результат только в конце проекта, и этот результат может оказаться очень далёким от реальных бизнес-целей и потребностей пользователей. Зачем так рисковать, если можно пойти совсем другим путём?

Когда при знакомстве с проектом есть понимание «мы знаем, что мы этого не знаем» и даже «мы не знаем, где границы того, чего мы не знаем», выручает SCRUM.

Специфика SCRUM может отпугнуть того, кто никогда не работал с этим фреймворком: на старте ещё неизвестна длина пути, который придётся пройти, чтобы получить рабочий проект, устраивающий на 100%. Заказчику сложно — он не может подготовить стратегический план развития проекта с достоверными датами релизов. Неизвестность пугает, особенно когда оплачивать этот путь нужно уже сейчас.

Но есть и плюсы: заказчик на старте не обязан детально и скрупулёзно описывать все функции и особенности огромной будущей системы. А ещё он может практически в любой момент изменить приоритеты и подстроиться под внешний конкурентный рынок.

SCRUM опирается на концепцию малых шагов: выпускать версии работающего программного обеспечения регулярно, как можно чаще и раньше. Каждая итерация — это микроэтап разработки, который немедленно проверяется практикой. Это значит, что уже после первой итерации заказчик получает вполне полезный, пусть и небольшой, но рабочий функционал, проверяет его в деле и сразу даёт обратную связь.

Важные ключевые решения — какую следующую ценность дать бизнесу — команда принимает перед каждой новой итерацией, постоянно. В результате система развивается критически-оптимальным путём до тех пор, пока не станет максимально соответствующей бизнесу. Заказчик здесь — часть команды: за успешность разработки отвечают и исполнитель, и заказчик. Они в одной команде, а не по разные стороны стола.

Проект: автоматизированная система для «Академии современного образования А+»

Мы хотим рассказать о нашем пути адаптации классического SCRUM-фреймворка в работе над автоматизированной системой управления для «Академии современного образования А+». Это современный образовательный центр в Киеве, в который входят школа, детский сад, центр раннего развития, музыкальная, танцевальная и спортивная школы, художественные студии и центр изучения иностранных языков.

Как заказчику и исполнителю начать работать по SCRUM

Чтобы работать в незнакомой парадигме, заказчику иногда приходится менять привычное мышление и оказаться в одном контексте с исполнителем. Поэтому перед разработкой системы для Академии мы организовали совместный тренинг с командой Scrum Ukraine. Его главные цели: познакомиться, вникнуть в терминологию, отработать все методики в игровой форме, смоделировать основные активности, понять, с чего начать, распределить роли и прописать обязанности.

За три дня совместного тренинга мы, используя так называемый helicopter view, сформировали будущую систему крупными мазками и зафиксировали это на временной прямой в виде Project RoadMap.

Helicopter view — a general description or opinion of a situation, rather than a detailed oneОпределение термина

Какие выводы мы сделали после этого этапа

• Совместный тренинг помогает изменить мышление заказчика и команды.
• Product RoadMap позволяет визуализировать высокоуровневый план разработки и приблизительно распланировать релизы. Важно понимать, что это «живая дорожная карта», которая будет меняться по мере открытия новых деталей разработки.
• Договорённость о глобальных правилах игры нужна «на берегу»: product owner после каждого спринта получает ценность — рабочую систему, которую следует сразу же использовать, а затем давать обратную связь.

Третий пункт обязателен, без него ничего не заработает. Ведь надежды на запуск после абстрактной полной готовности в финале приводят к разочарованиям, причём с обеих сторон:

• Со стороны заказчика: «Это то, что мы просили, но это не то, что нам нужно».
• Со стороны исполнителя: «Мы чётко делали то, что вы просили. А теперь ваши требования звучат для нас совсем иначе. Мы согласны всё переделать, но за ваш счёт. И вообще изменений так много, что доработка займёт ещё полгода».

Шаг 1. Бизнес-анализ, product backlog и user story

Разработку любого проекта мы начинаем с бизнес-анализа: необходимо понять специфику. В любой компании всегда много процессов, и наша задача в исследовании — выяснить, как участники системы взаимодействуют между собой, прежде чем строить систему. После раунда проблемных интервью и обработки полученной информации мы получили описание предметной области в виде примеров использования.

Хотя SCRUM не требует наличия спецификации на разработку, то, что у нас было готовое описание предметной области, оказалось большим плюсом. Этот документ лёг в основу product backlog — базы для старта SCRUM.

Product backlog — список требований, историй, функционалов, упорядоченных по степени важности. С такого списка всё начинается. При этом все требования описаны понятным для заказчика языком. Элементы этого списка — user story, «пользовательские истории». Наш product backlog насчитывал 203 истории, сгруппированные по сегментам для удобства.

Какие выводы мы сделали после этого этапа

• Длительность наших спринтов составит две недели. Почему? Короткие спринты удобны: они позволяют команде быть максимально гибкой — готовой часто корректировать планы. Короткий спринт означает короткий цикл обратной связи, а значит, частые релизы. Частые релизы = быстрые отзывы от клиентов = меньше времени на работу в неправильном направлении = быстрое обучение и совершенствование.
• У длинных спринтов свои плюсы — меньше накладных расходов вроде планирования спринта, демо и прочего. Но мы выбрали короткие, чтобы быть гибкими и меньше рисковать.

Шаг 2. Планирование спринта и первые ценности для бизнеса

Нашей первой ценностью для бизнеса стал электронный журнал. Для большинства опытных разработчиков это покажется утопией: перед нами чистый лист, ещё нет ни одного справочника, пользовательского интерфейса, системы авторизации, ни одной бизнес-сущности — а мы обязуемся предоставить одну из самых сложных функций системы.

Для нас обязательно было получить две вещи: сформулированную цель спринта и утверждённый sprint backlog. Наш product owner всегда начинал планирование спринта с описания того, что нужно сделать в первую очередь, — самых значимых историй. После этого команда оценивала трудозатраты для всех user story, начиная с самой важной. В процессе у команды возникало много вопросов о том, как это должно функционировать.

Sprint planning — это очень важная SCRUM-активность. Все осознают ответственность за правильную оценку, потому что:

• это позволяет бизнесу понять, какого функционала он может ожидать в конце спринта, а команде — быть предсказуемой и находиться «on the same page» с заказчиком;
• ценность наполовину реализованной истории нулевая, поэтому все запланированные в рамках одного спринта истории нужно довести до конца;
• любые изменения оценки в течение спринта игнорируются.

Электронный журнал после первого спринта

Упрощения и допущения для первого спринта. В системе — два пользователя: преподаватель и родители; один класс — 5«А»; настоящий состав класса, внесённый вручную напрямую через SQL-запросы; настоящее расписание для 5«А», сформированное так же напрямую записью в таблицы.

User story № 1: преподаватель заходит в систему и выставляет оценки по любому предмету из расписания класса за день. Система с одной простой, но уже рабочей функцией. Уже на sprint demo преподаватель сказал, чем пользоваться удобно, а чем — нет, чтобы в следующих спринтах команда могла запланировать корректировки и дать обновлённый инструмент.

Какую реальную ценность даёт: оцифрованная успеваемость реального класса, актуальные оценки, перспектива автоматической подготовки месячной, семестровой, квартальной отчётности.

User story № 2: еженедельный отчёт родителям об успеваемости на почту.

Какую ценность добавляет: информирование родителей о текущей успеваемости; комментарии преподавателя к домашнему заданию; минимальную, но реальную аналитику.

После нескольких спринтов я решил, что функционала для работы преподавателей с электронным журналом достаточно. Поэтому мы поставили разработку этого инструмента на паузу и сместили фокус на конструктор расписания. Это нормально для SCRUM. К электронному журналу фокус разработки я вернул через десяток спринтов, и мы, частично выбросив упрощённый функционал, довели электронный журнал до состояния, необходимого для анализа годовой успеваемости. Этот функционал на тот момент был нам нужнее. Мы получили достаточную ценность и переключили активную разработку на более приоритетные части системы.Святослав, Product owner

Для справки: чтобы зафиксировать окончательную, идеальную версию, нам приходилось возвращаться к электронному журналу в течение нескольких спринтов. Версию журнала, которую уже можно было показывать родителям, мы получили после 12-го спринта.

Ещё один яркий пример итеративного подхода — конструктор расписания

До этого расписание в Академии составляли на склеенных листах ватмана А1 вручную: рисовали, выделяли цветными маркерами, склеивали. У завуча на это уходили недели и месяцы.

Первый конструктор расписания заказчик получил через два месяца после старта проекта. Это был «брутальный редактор» для очень продвинутого пользователя. Но он позволил нам ввести расписание для всех пятых классов и протестировать систему на настоящем живом расписании. На доработку до «визуального редактора» ушло три спринта. Фокус разработки несколько раз переключался, но к началу учебного года заказчик получил полнофункциональный конструктор расписания.

Какие выводы мы сделали после этого этапа

• Каждый спринт должен иметь чётко сформулированную цель.
• Упрощать функционал, а потом его развивать — это нормально. Именно этим и хорош SCRUM: нет единственно правильного пути в разработке продукта. Это не учебник с задачами и правильными ответами в конце. Всегда можно рассматривать множество альтернативных вариантов и выполнять их в разной последовательности. Если в конце спринта клиент получает законченную ценность, с которой может работать, тестировать, вводить новые данные, и это продвигает вперёд к глобальной финальной задаче, — это правильный путь.
• Основная философия SCRUM: не гнаться за красивым кодом на старте, а сконцентрироваться на том, чтобы дать заказчику рабочий инструмент. Поэтому можно мириться с ошибками во время работы, но нужно понимать: лучшее средство выявить эти ошибки — перестать думать об идеальном коде на уровне архитектуры и дизайна, а сначала дать бизнесу рабочий прототип.
• Важно во время обсуждения вносить изменения в user story, а все артефакты сохранять и прикреплять к карточкам.

Оценка в story points: SCRUM-покер

Команда всегда адекватно оценит user story, если выполнены условия: детально описано поведение реального пользователя, обозначены границы использования и допущения, перечислены критерии приёмки. То есть команда понимает, «что» нужно сделать, и приблизительно предполагает «как». Формулировать критерии приёмки и границы использования важно потому, что это даёт одинаковое понимание объёма работ по историям как со стороны product owner, так и со стороны команды.

В SCRUM оценка историй проходит не в часах или днях, а в story points. Это микс сложности, рисков и усилий, которые команда должна потратить, чтобы выполнить историю. Для каждой команды 1 story point — величина индивидуальная, эмпирическая, но каждый член команды её чувствует.

Обратите внимание: последовательность значений на карточках нелинейна. Например, между 13 и 21 нет ничего. Почему так?

1. Чтобы не появлялось ложное ощущение точности. Если история оценивается примерно в 17 story points, нет смысла обсуждать, должна она быть 15, или 18, или 21. Всё, что нам нужно знать, — историю сложно оценить. Поэтому мы назначаем ей ориентировочную оценку 21.
2. Чтобы не переоценить собственные возможности. Людям свойственно преувеличивать свои силы, а шкала не даёт сильно ошибиться с оценкой времени и ресурсов. Скажем, команда сошлась во мнении, что на одну из задач достаточно 6 story points. Но если нет уверенности, что хватит и 5, лучше выбрать 8. Это позволяет устанавливать реальные сроки, в которые команда точно уложится.
3. Чтобы начался диалог. Шкала помогает участникам поделиться своим видением реализации истории, озвучить риски и прийти к консенсусу.

Очень важно: оценку должен дать каждый участник команды. Почему?

• Для аргументированной оценки каждый участник должен прекрасно понимать, в чём суть этой истории. Получая оценку от каждого члена команды, мы убеждаемся, что все в курсе, о чём идёт речь. Это увеличивает вероятность взаимопомощи во время спринта. И главное — самые важные вопросы по этой истории всплывут как можно раньше.
• Разностороннее видение проблемы приводит к сильному разбросу оценок. Такие расхождения лучше выявлять и обсуждать как можно раньше. После обсуждения — повторная оценка, голосование. Обычно пары циклов оценивания хватает, чтобы прояснить основные моменты и создать общее понимание.

Яркий кейс: «Живая лента»

В системе управления школой возникает много событий разной степени значимости. Например, ученик получил оценку; произошла замена, и вместо математики будет биология с другим учителем; с учеником произошёл досадный инцидент, и родителей нужно немедленно проинформировать; преподаватель написал важный комментарий к домашнему заданию.

Отправлять эти данные стандартными методами в мессенджеры или на почту неудобно для пользователей, да и вообще — это вчерашний день. К тому же сообщения могут касаться нескольких человек сразу: преподавателю нужно сообщить родителям, что ученик вышел с территории школы во время урока. В исходном документе эти правила собраны на десяти страницах.

Когда мы обсуждали среди разработчиков, во сколько оцениваем объём работ по истории «Живая лента», каждый высказался, сколько story points понадобится. Выяснилось, что у нас большие расхождения во взглядах, и мы обратили внимание на крайние мнения: почему кто-то оценил в 50, а его коллега уверен в 5 story points. Так сразу мы обнаружили невыявленные требования, которые заметил более осторожный разработчик. Плюс раскрылись глобальные задачи, связанные с персонализацией. Это прекрасный пример того, как команда может предвидеть трудности.

Какие выводы мы сделали о методике оценки

• Да, это нормально, чтобы оценку технической истории дали также QA и UX-дизайнер.
• На первых спринтах команда сопротивляется эмпирическим story points, потому что привычнее и «проще» оценивать трудозатраты в часах и днях. Пока мы обкатывали эту систему оценки, иногда сильно ошибались, но потом очень точно определяли объём задач в story points.
• К 2–3-му спринту команда чётко понимает, сколько это — 1 story point.

Шаг 3. Ежедневный SCRUM и кросс-функциональная команда

Ежедневный SCRUM-meeting, или stand-up, да и весь SCRUM — это история об эффективных коммуникациях, которые помогают экономить время и усилия команды. Это не просто «встречи» и «разговоры». Они не отнимают время, которое можно было бы потратить на работу, а помогают оптимизировать усилия. Один из принципов SCRUM так и звучит: «Люди и взаимодействие важнее процессов и инструментов».

Каждый участник команды кратко сообщает, согласно специально разработанному checklist, что сделал, с какими проблемами столкнулся, что будет делать дальше. Человек не остаётся один на один с проблемой, ему быстро помогают решить её самым эффективным способом. Так инженер не тратит время на безуспешные попытки, после которых, возможно, придётся переделывать с нуля, и тем самым экономит ресурсы всей команды.

Кросс-функциональность: команда готова выполнять любые задачи по запуску продукта

Формируя команду, мы подбирали T-специалистов, которые разбираются во многих областях и как минимум в одной являются экспертами. Благодаря такой универсальности все инженеры знают систему достаточно хорошо. Опыт каждого ценен для поиска самого эффективного решения: у одного человека может не оказаться нужного для конкретной задачи опыта, но с большой вероятностью он будет у его коллег. То же самое со стороны заказчика — один человек может не знать каких-то деталей, а их знает другой.

Чтобы моя команда стала ещё более самоорганизованной, я оформляла каждый спринт по чётко заданному шаблону: номер, цель спринта, sprint backlog с оценкой для каждой истории, состав команды, сроки, время ежедневных собраний, организационные события. Всё это так разложено по полочкам для того, чтобы, двигаясь планомерно, шаг за шагом, к концу спринта гарантированно подготовить законченную ценность для заказчика. Чтобы он был доволен и немедленно начал использовать её в бизнесе.Майя Сокольская, Scrum Master

Какие выводы мы считаем важными для этапа sprint running

• Команда станет самоорганизованной, автономной, самомотивированной и сверхпродуктивной, если в течение спринта никто не будет вмешиваться в её работу.
• Нужно сместить акценты и понимать, что ежедневный SCRUM необходим для коммуникации, а не для администрирования.
• Каждый следующий спринт должен учитывать опыт предыдущих.

Шаги 4 и 5. Демо результатов и ретроспектива

Как мы проводили демонстрацию результатов

Разработчики по очереди демонстрируют новый функционал вживую на реальных данных. Фокус — на том, что мы сделали, а не на том, как мы это делали. В целом мы постоянно стремимся, чтобы наше демо было бизнес-ориентированным, без упоминаний технических деталей.

Здесь снова на передний план выходит цель спринта. На наших демо часто присутствовали специально приглашённые учителя и завучи, которых не было на планировании. Они знали о продукте лишь в общих чертах. Мы всегда приветствовали, чтобы после каждой продемонстрированной истории заказчики сами попробовали что-то сделать в системе. Тогда конечный пользователь проверяет каждый пункт критерия приёмки. Он говорит, что устраивает, а что нет, какие аспекты можно улучшить. И так — по каждой user story, которая была запланирована на этот спринт.

Какие выводы мы сделали о методике демонстрации результатов

• Обязательный состав для демо: product owner, scrum master, представители заказчика, конечные пользователи, которые будут работать с инструментом, и команда.
• Перед каждой демонстрацией нужно зачитывать соответствующую пользовательскую историю, чтобы ввести всех в контекст.
• Полезно проводить демонстрацию на продуктовой системе с реальными данными и реальными пользователями, которые уже работают в системе. Такой подход возможен, когда система находится в стадии альфа-тестирования.
• Важно не тратить много времени на подготовку демо: мы никогда не создавали эффектную презентацию, а концентрировались только на демонстрации реально работающего кода и получении обратной связи.
• Не нужно показывать кучу исправлений мелких багов и элементарных фич. Можно упомянуть о них, но демонстрировать не стоит, потому что это отнимает много времени и снижает внимание к более важным историям.

Как мы адаптировали и проводили retrospective

Для нас ретроспектива — это важное мероприятие сразу же после sprint demo. Ретроспективы полезны, особенно когда что-то идёт не так. Без них может оказаться, что команда наступает на одни и те же грабли снова и снова.

Самые частые грабли — это когда реальная производительность команды сильно отличается от прогнозируемой. Реальная производительность рассчитывается на основании первоначальной оценки каждой истории. И когда в середине спринта мы понимаем, что история, оценённая в 5 story points, делается столько же, сколько обычно занимает задача на 13 story points, и далека от завершения, а если это ещё и блокирующая история — другие не могут быть начаты из-за неготовности проблемной. Когда цели спринта под угрозой, ретроспектива неизбежна.

Наши ретроспективы имеют абсолютно чёткую структуру и цели. Команда собирается вместе, Scrum Master зачитывает sprint backlog, просит высказаться каждого члена команды и оценить с его точки зрения итоги спринта. Каждый говорит, что удалось сделать хорошо, что пошло не так и — главное — почему. Что продолжать делать, а от чего отказаться. При этом его никто не перебивает. Свои выводы, записанные на стикере, он размещает в одной из колонок:

• хорошо;
• могло быть и лучше;
• надо фиксить.

После того как команда закончит мозговой штурм по всем проблемным стикерам, я провожу «точечное голосование»: у каждого члена команды есть три голоса — три точки маркером на стикерах. Он может отдать все свои голоса сразу одной проблеме, а может распределить иначе. На основании этого командного голосования мы выбираем 2–3 улучшения, на которых фокусируемся в следующем спринте. А в начале следующей ретроспективы проверим, что у нас получилось. Такая себе «проверка домашки».Павел Камышов, Agile Coach

Пример наших улучшений по результатам одной из ретроспектив

• Когда разработчик делает front-end и мы начинаем его внедрять, необходимо, чтобы дизайнеры были доступны на 100%.
• Обсудить с product owner включение методологических часов.
• По эргономике важно получать максимальную документацию.
• Не стоит накапливать технический долг. Согласовать с product owner выделение 10% на технические истории.
• Должен быть специалист, который будет решать технические вопросы по мере их возникновения.
• Перед каждым sprint planning обязательно проводить sprint grooming.

Да, SCRUM требует активной, вовлечённой работы всех участников команды. На активности — grooming, planning, ежедневный SCRUM — у нас уходило около 12% оплачиваемого времени. Это своеобразная цена за прозрачность, предсказуемость и снижение рисков.

Одна неделя работы может сэкономить один час планирования.Павел Камышов, Agile Coach of Scrum Ukraine

12% — много, но оно того стоит: в классическом «водопаде» цена использования методологии — это отдельная роль проектного менеджера. В среднем в нашем сегменте рынка на менеджмент тратится около 15% от стоимости разработки.

Какие выводы мы сделали о методике проведения ретроспектив

• Для нас ретроспектива является вторым по значимости мероприятием в SCRUM после планирования спринта.
• Высказывается каждый член команды, чтобы все находились в одном информационном поле.
• Каждое изменение имеет свою цену. Необходимо договариваться с product owner о включении в sprint backlog технических историй и методологических часов.
• Методологические часы оплачивает заказчик.

Шаг 6. Product backlog refinement, или grooming

Многие коллеги, знакомые со спецификой IT, засомневаются: как во время планирования спринта команде может быть всё настолько ясно, что она готова давать оценку всем user story? Да, действительно, без подготовки такой слаженности не получится.

Для того чтобы это работало, существует специальная SCRUM-активность: product backlog refinement. Для её проведения необходимо попросить product owner дать горизонт планирования — очертить, какие истории могут быть кандидатами на ближайший спринт. Если среди них окажутся истории, требующие углублённого изучения или специальных компетенций, которых нет у команды, назначается собрание — grooming, или pre-planning.

Наш product owner был очень компетентным, поэтому у нас всегда был достаточный горизонт видения, как система будет развиваться, и мы регулярно проводили refinement. Ведь прозрачность — один из основополагающих принципов SCRUM.

Какие выводы мы сделали о методике проведения refinement

• Это важное мероприятие, которое позволяет прояснить, чего мы не знаем и каких компетенций нам не хватает. Так, однажды было решено привлечь стороннего разработчика-консультанта в специфических вопросах, опыта решения которых у нас на тот момент ещё не было.
• Эти обсуждения проходили у нас очень эффективно: мы рассматривали множество альтернатив и вариантов, что позволяло держать проблему в голове, и к sprint planning самая сложная история уже была «разложена по полочкам».
• Сложные, казалось бы, нерешаемые проблемы находят понятные решения. Иногда достаточно просто купить библиотеку, чем вести разработку сложного участка самостоятельно.

Experience shows that 10% is a sensible average of the overall time incurred on a Sprint to spend on Product Backlog refinement.Verheyen, Gunther. Scrum — A Pocket Guide

Фейлы: три момента, где мы бы подстелили соломки

Да, мы откровенно в восторге от разработки по методологии SCRUM, но это не значит, что всё проходило гладко. Вот три момента, где мы подстелили бы соломки, если бы знали заранее, что пойдёт именно так.

1. Работа по привычным схемам. На одной из ретроспектив мы детально проанализировали причину аномального отклонения «реальной производительности» команды во всех историях с участием дизайнеров. Реальная производительность обычно рассчитывается по формуле: прогнозируемая производительность / фактическая производительность. Мы обнаружили, что дизайнеры по привычке организовались в знакомый им последовательный waterfall. Как результат: задачи выполнялись последовательно, разработчики тратили время на поочерёдное включение на разных этапах с задержками, вызванными необходимостью доводить до конца уже начатые задачи. Вывод: пожалуй, самая болезненная для нас история, которая принесла больше всего вреда и была выявлена не сразу. Нужно регулярно проверять, все ли участники команды переключились на работу по новым стандартам.
2. Лишняя работа над ненужным функционалом. На втором спринте product owner поддался мнению одного из завучей, который считал, что «журнал куратора» — крайне важный функционал. Мы взяли эту историю в спринт и потратили на неё усилия. Почему это ошибка: этот инструмент можно было тестировать только на поздних этапах, потому что ему нужны были накопленные данные, которых на тот момент не было. Как результат: его не проверяли, не использовали, не развивали. Нужные функции были решены иначе и совсем не так, как думал тот завуч, — совсем через другие инструменты. Вывод: берите в работу только то, чем сразу же начнут пользоваться.
3. Ориентация на продвинутых пользователей. На одном из этапов мы взяли в работу историю с «редактором замен», в разработке которой участвовал учитель — очень опытный пользователь компьютеров. В итоге мы получили отличный инструмент, но его не могли использовать обычные учителя школы, которые не были настолько продвинутыми. Вывод: подтверждать историю на regular customers.

Общие выводы и результат

Вывод № 1. О гибкости: SCRUM позволяет быть эффективной командой

Результаты каждого спринта зависят от входных задач, эффективности, скоординированности, ответственности команды и качественной обратной связи. Входные данные даёт product owner. Он же отвечает за контекст, в котором будет использоваться функционал, за качество формулировки требований, обеспечивает достаточную глубину детализации.

SCRUM требует от команды завершения вполне ощутимого отрезка работы, что позволяет получить ценность — инструмент, который можно предоставить пользователю в конце каждой итерации. Это помогает видеть решение в работе и на начальных этапах понимать, что нужно изменить, чтобы продвинуться дальше.

Вывод № 2. О максимально эффективном использовании ресурсов

SCRUM — форма организации работы, выгодная и заказчику, и исполнителю. Работа итерациями позволяет уже на ранних стадиях понимать, что идёт не так, а значит — вовремя вносить коррективы. Подготовка к каждому спринту и специфика его организации помогают каждый раз делать только то, что нужно заказчику, и не уходить в сторону. И это даёт колоссальную эффективность потраченных ресурсов, времени и усилий. Заказчик уже на начальных этапах получает работающий участок системы: после первых спринтов берёт сделанный функционал в работу и тестирует его в деле.

SCRUM — когда обе стороны застрахованы от рисков

Исчезает барьер, по разные стороны которого в классическом проектном менеджменте находятся исполнитель и заказчик. В принципе исчезают позиции «заказчик» и «исполнитель», остаётся команда. И нет условий для возможной конфронтации.

Всего за семь месяцев мы сделали работающую и полностью устраивающую заказчика систему — проверенную им на практике и отражающую все пожелания. А не выдали систему, теоретически спроектированную по техническому заданию, которую ещё несколько месяцев нужно было бы докручивать, потому что практика неизбежно внесёт свои коррективы.

Глобально этот кейс — о правильно подобранной методике ведения проекта в условиях большой степени неопределённости и ограниченного времени до запуска. С таким требовательным заказчиком, с высокими стандартами качества, нам было порой очень сложно, но одновременно очень интересно. Те challenges, которые мы преодолели, допущенные, однако вовремя осознанные и исправленные ошибки, сделанные выводы навсегда изменили культуру в нашей команде.

А заказчик получил отличный продукт: набор инструментов для современной школы, способный быстро трансформировать её в школу будущего.

Материалы и литература, которые нам помогли

• Software Estimation: Demystifying the Black Art (Developer Best Practices)
• Manifesto for Agile Software Development
• Principles behind the Agile Manifesto
• Agile Retrospectives: Making Good Teams Great
• Verheyen, Gunther. Scrum — A Pocket Guide