Страшный сон команды разработчиков — это когда до начала разработки надо «нырнуть» в неизвестную предметную область и «проэстимейтить» half-baked idea. При этом нужно буквально «подписаться кровью» за результат в назначенный срок за фиксированные деньги.

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

Зачем так рисковать, если можно пойти совершенно другим путем?

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

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

Заказчику трудно — он НЕ может подготовить стратегический план развития проекта с достоверными датами релизов. Неизвестность пугает, особенно когда нужно оплачивать этот путь уже сейчас.

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

Кстати, так было и в этом кейсе, но скоро вы увидите, как мы вырулили из сложной ситуации, когда мы вместе с заказчиком разбирались что и как реализовывать уже по ходу дела.

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

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

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

Именно так было и у нас, давайте посмотрим?

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

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

Достоинство 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

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

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

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

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

Product owner — владелец продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки. Еединственный человек, который отвечает за развитие продукта

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

После раунда проблемных интервью и обработки полученной информации мы получили описание предметной области в виде примеров использования.

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

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

Наш product backlog из 203 истории, для удобства сгруппированных по сегментам

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

Как это было. Для нас обязательно было получить 2 вещи: сформулированную цель спринта и утвержденный sprint backlog.

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

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

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

Цель спринта — то, ради чего спринт нужен. Самое главное, чтобы цель была обозначена в терминах бизнеса, а не технических. То есть языком, понятным даже людям вне команды, а Sprint backlog — это выборка историй из product backlog. Он представляет собой список историй, которые команда определила как наиболее важные на данном этапе и обязалась выполнить в течение спринта.

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

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

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

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

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

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

На его доработку до «визуального редактора» ушло три спринта. Фокус разработки несколько раз переключался, но к началу учебного года заказчик получил полнофункциональный конструктор расписания, с помощью которого всего за час ввел расписание с первых (А, Б, В, Г) по восьмые классы.

Проследим маршрут «брутальный редактор для настоящего админа» — «визуальный редактор» — «конструктор расписания»

А как делали расписание до этого?

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

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

Почему важно формулировать «критерии приемки» и «границы использования» — это дает одинаковое понимание объема работ для историй как со стороны product owner, так и со стороны команды.

Шкала оценки, или SCRUM-poker

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

Заметьте, последовательность значений на карточках — нелинейная. Вот, например, между 13 и 21 ничего нет. Почему так?

Во-первых, это нужно, чтобы избежать появления ложного чувства точности для больших оценок. Если история оценивается примерно в 17 story points, то нет смысла обсуждать, должна ли она быть 15, или 18, или 21. Все, что нам нужно знать, — историю сложно оценить. Поэтому мы назначаем ей оценку в 21. Ориентировочно.

Во-вторых, людям свойственно преувеличивать свои возможности, а шкала не позволяет сильно ошибаться с оценкой времени и ресурсов. Например, команда сошлась на мнении, что на одну из задач достаточно 6 story points. Но если нет уверенности, что хватит и 5, то лучше выбрать 8. Это позволяет устанавливать реальные сроки, в которые команда точно уложится. Плюс это помогает начать диалог между участниками, поделиться своим видением реализации story, озвучить риски и прийти к консенсусу.

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

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

Покажем это на примере широкой вариации оценки для одной из историй. История называлась «Живая лента».

Важно: Во время планирования мы обычно не знаем, кто будет выполнять ту или иную часть. Реализация user story требует участия специалистов для разных типов работ: архитектура, front-end, back-end, тестирование, подготовка реальных данных. Отдельно стоит такая группа работ, как проектирование и дизайн пользовательского интерфейса.

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

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

Живая лента в финальной реализации

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

Обсуждаем среди разработчиков, во сколько мы оцениваем объем работ по истории «Живая лента».

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

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

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

Для каждой команды story point — величина индивидуальная, эмпирическая, но каждый член команды чувствует ее.

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

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

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

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

Опыт каждого ценен для поиска самого эффективного решения.

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

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

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

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

Как застраховаться от повторения ошибок

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

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

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

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

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

Результаты grooming

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

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

На одной из ретроспектив мы детально проанализировали причину аномального отклонения «реальной производительности» команды во всех историях с участием дизайнеров. Реальная производительность обычно рассчитывается по формуле: прогнозируемая производительность /фактическая производительность.

Мы обнаружили, что они по привычке организовались в знакомый им последовательный waterfall.

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

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

На втором спринте product owner поддался мнению одного из завучей, который считал что «журнал куратора» — крайне важный функционал. Мы взяли эту историю в спринт, потратили на нее усилия.

Почему ошибка: этот инструмент можно было тестировать только на поздних этапах, так как ему требовались накопленные данные, которых на тот момент не было.

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

На одном из этапов мы взяли в работу историю с «редактором замен», в разработке которой участвовал учитель — очень опытный пользователь компьютеров. В итоге мы получили прекрасный инструмент, но его не могли использовать обычные учителя школы, которые не были такими продвинутыми.

Вывод: подтверждать историю на regular customers.

Вывод №1

Про гибкость: SCRUM позволяет быть эффективной командой

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

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

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

Вывод №2

Про максимально эффективное использование ресурсов

SCRUM — форма организации работы, выгодная заказчику и исполнителю. Чем?
Работа итерациями позволяет уже на ранних стадиях понимать, что идет не так, а значит — вовремя вносить коррективы. Подготовка к каждому спринту и специфика его организации помогают всякий раз делать только то, что нужно заказчику, и не уходить в сторону. И это дает колоссальную ЭФФЕКТИВНОСТЬ затраченных ресурсов, времени и усилий.
Заказчик уже на начальных этапах получает работающий участок системы: после первых спринтов берет сделанный функционал в работу и тестирует его в деле.

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

ЗАКАЗЧИК

Заказчик платит только в том случае, если все цели спринта были достигнуты. Если не разработан инструмент, который заказчик может обкатать на практике уже завтра, спринт не засчитывается.

Заказчик платит фиксированную сумму за каждый спринт, и делает свой бизнес еще на один шаг эффективнее

Исполнитель

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

Каждый спринт повышает уровень компетентности исполнителя, ускоряет его в реализации проекта.

Итого, всего за 7 месяцев мы сделали работающую и полностью устраивающую заказчика систему, проверенную им на практике и отражающую все пожелания, а не выдали систему, теоретически спроектированную по ТЗ, которую еще несколько месяцев нужно будет докручивать, так как практика неизбежно внесет свои коррективы.

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

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

Наверное уже давно всем интересно узнать о самом продукте, который получился.

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

Теги:

• SCRUM
• AGILE
• project management
• agility

Хабы:

• Управление проектами
• Agile