Как мы делали SCRUM25.03.2019 22:49

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

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

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

Зачем SCRUM

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

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

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

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

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

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

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

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

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

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

Достоинство 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 — владелец продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки. Еединственный человек, который отвечает за развитие продукта

Все наши договоренности в виде короткого списка

Шаг №1: Бизнес-анализ и адаптация методологии

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

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

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

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

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

Пример user story

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

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

Спринт — временной отрезок в течение которого создается «Готовый», то есть пригодный к использованию и выпуску продукт

Шаг №2: Планирование спринта. Как мы адаптировали Sprint planning

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

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

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

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

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

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

Пример sprint backlog

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

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

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

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

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

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

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

Святослав, Product owner

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

Так выглядел журнал после первого спринта, но с ним уже можно было работать

Эта версия электронного журнала была получена после 12 спринта и ее можно было показывать родителям

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

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

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

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

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

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

Самая первая версия редактора: «Брутальный редактор для админа» — который составил расписание на 2018 год

Вторая, улучшенная версия, с помощью которой было составлено расписание 2018/2019

Конструктор расписания — окончательная версия

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

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

Как сделать, чтобы команда оценивала user story реалистично

Команда всегда адекватно оценит 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 — величина индивидуальная, эмпирическая, но каждый член команды чувствует ее.

Шаг №3: Спринт запущен. Как мы адаптировали sprint execution и ежедневный SCRUM

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

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

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

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

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

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

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

Майя Сокольская, Scrum Master

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

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

Как проводить ежедневный SCRUM meeting

Шаг №4: Как мы проводили демонстрацию результатов. Наша адаптация sprint demo

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

Как узнать, что решение подходит заказчику

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

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

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

Цель каждого Спринта — продемонстрировать готовую к использованию функциональность продукта

Шаг №5: Как мы адаптировали и проводили retrospective

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

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

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

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

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

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

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

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

Павел Камышов, Agile Coach

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

Одна неделя работы может сэкономить один час планирования

Павел Камышов, Agile Coach of Scrum Ukraine

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

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

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

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

Шаг №6: Как мы адаптировали product backlog refinement, или Grooming

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

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

Результаты grooming

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

Так выглядит план проведения grooming

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

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

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

Фэйлы

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

Работа по привычным схемам

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

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

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

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

Лишняя работа над ненужным функционалом

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

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

© Habrahabr.ru