Sprint planning meeting что это
Sprint Planning Meeting
Одно из самых важных мероприятий в методологии Scrum – это, конечно же, Sprint Planning Meeting. В нём принимают участие владелец продукта, Scrum Master и вся команда разработки. Иногда происходит и участие внешних заинтересованных сторон, однако это бывает редко.
Во время Sprint Planning Meeting Product Owner описывает наиболее приоритетные задачи команды. Команда в это время задаёт достаточное количество вопросов, чтобы более точно оценить и распределить задачи, которые будут решаться во время Sprint.
Владелец продукта не должен описывать каждый элемент Product Backlog. Для Product Owner хорошим ориентиром будет приход на Sprint Planning Meeting и разговор о задачах, которые в сумме будут распределены на два спринта. Если, скажем, команда будет брать 5 задач на текущий Sprint, то разговор будет о топ-10 задачах из всего Backlog.
Цель спринта – это сформулированные одно или два предложения, которые описывают то, что команда планирует достичь во время Sprint. Sprint Goal описывается командой и владельцем продукта (совместно).
Длительность Sprint Planning Meeting
Гибкость методологии Scrum проявлена везде, в том числе и в длительности Sprint Planning Meeting, которая зависит от длительности будущего спринта. Формула тут следующая: 1 неделя Sprint = 2 часа Sprint Planning Meeting. То есть при спринте длительностью в 2 недели Sprint Planning Meeting должен быть равен 4 часам.
Формат проведения встречи
Встреча условно делится на две части.
В первой части Product Owner проводит обзор элементов из Product Backlog, которые необходимо представить и обсудить на данной встрече. Владелец продукта описывает то, что он хочет видеть. Именно тут задаются вопросы и обсуждаются задачи в, можно сказать, хаотичном порядке, так как после обсуждения одной задачи на ум может прийти ещё какой-то уточняющий вопрос. По сути, целью таких уточнений является прояснение любой двусмысленности.
В конце первой части формируется та самая Цель спринта / Sprint Goal.
Во второй части команда уже формирует Sprint Backlog, задачи которого оцениваются в часах. На данном этапе вмешательство Product Owner недопустимо. На самом деле владелец продукта должен находиться в зоне досягаемости и команда может его привлечь, но он не должен находиться в комнате, где идёт обсуждение. Иногда, правда, бывают случаи, когда он присутствует, но тогда Scrum Master должен взять на себя ответственность за создание спокойной атмосферы для работы команды. Product Owner не всегда может понимать какие-то глубокие процессы и во время обсуждения, когда команда решает сделать так или по-другому, владелец продукта может посеять панику.
Пример
В качестве примера покажем, как всегда, задачи создания интернет-магазина.
Необходимо: реализовать основные функциональные возможности корзины покупок, включая добавление, удаление и изменение.
Разработка процесса контроля: оплатить заказ, забрать груз, заказать подарочную упаковку и т.д. Вообще цель спринта служит некоторой точкой отсчёта для «внешних участников». Практически в любом проекте присутствуют заинтересованные лица, желающие знать, как работает команда, но которым нет необходимости (да и не разрешено) лезть в глубину работы команды и оценивать каждую задачу и тот или иной шаг, совершаемый Scrum Team. Sprint Goal здесь как нельзя лучше подходит в качестве такого «мерила». Всё ведь очень просто: достигнута цель или нет, а не какие элементы были сделаны или не сделаны.
Вторым артефактом является бэклог спринта, который уже является рабочим списком для реализации в спринте.
Важно то, что команда должна всё же решить, сколько работы она сможет выполнить. Недопустима постановка задач таким образом: работы на 4 спринта, так что в первый спринт команда должна выполнить 25% от всех задач.
Product Owner
Sprint
Основной процесс в методологии Scrum вокруг которого всё крутится. Правильно выстраенная итерация приведет всю разработку к успеху.
Product Backlog
Список задач из которого формируется впоследствие Sprint Backlog принимаемый на Sprint Planning Meeting. За составление Product Backlog ответственнен Product Owner.
Scrum Team
Совокупное объединение Scrum Master, Product Owner и Development Team действует как единый организм. Естественным образом данный организм живет по своим особым законам.
Scrum-митинги
Хорошо, когда первые шаги на пути к Agile уже сделаны и каскадная модель остаётся немного позади. На первых порах большинство команд просто используют доску и, возможно, небольшое планирование спринтов. Такой подход действительно рекомендуем для большинства команд. Иногда команда развивается быстро, иногда застревает на одном месте и на некоторое время остаётся в подвешенном состоянии, некий «недоскрам» получается. В обоих случаях вопросы митингов остаются, чаще всего, на потом. Люди стараются решать и обсуждать всё по старинке, показывая продукт, как им кажется, удобно и правильно. Некоторые даже и не знают, какие митинги существуют, и для чего вообще в них ввели те или иные правила.
Прежде чем приступить к рассмотрению Scrum-митингов, хотелось бы напомнить самому себе, что Agile он и есть Agile, так что абсолютно все митинги могут иметь уникальный окрас, зависящий от команды и условий. Более того, как оттенок хамелеона может меняться под воздействием внешних факторов, так и сам стиль проведения митинга может варьироваться время от времени.
Scrum – живой организм с высоким уровнем отклика (странно звучит, согласитесь). Дело всё в том, что сухо внедрить скрам нельзя, он очень гибок, и часто бывают ситуации, когда он вынуждает команду поступать так, как ей, может быть, и не хочется. Договариваясь со Scrum, скажем, по срокам работ, так или иначе вам нужно будет пойти на компромиссы.
Sprint Planning Meeting
Если мы решаем, что наш спринт будет длиться 2 недели, то значит первый митинг, называемый Sprint Planning Meeting, будет продолжаться 4 часа (по 2 часа на неделю работы). Легко себе представить, что при спринте сроком в месяц длительность первого митинга будет 8 часов. Это, конечно, не означает, что команда должна сесть на 8 часов и не выходить из комнаты, пока они не пройдут и команда не придет к единогласию.
Копное право основывалось на правиле единогласия — прихода к единому мнению всех собравшихся сходатаев.
Копное право, Wikipedia.org
Данную встречу можно и даже нужно разделить на несколько блоков. Такой подход более рационален, ведь, скажем, после первых 2-х часов обсуждения могут всплыть новые проблемы, которые нужно хорошенько обдумать, а затем опять обсудить. Как видно, даже митинг планирования можно разделить на итерации.
В Sprint Planning Meeting участвуют:
Основная цель: определить цель спринта, сформировать Sprint Backlog.
Подробнее о Sprint Planning Meeting.
Daily Scrum Meeting / Ежедневный скрам
На самом деле очень важная встреча, которую почему-то многие пропускают. В ходе неё выявляются в основном проблемы, которые начинают мешать рабочему процессу (ключевое слово тут «начинают»). Если рабочий процесс уже пошёл не по плану, то исправить ситуацию будет гораздо сложнее, так как изначально момент был упущен. Ежедневный скрам и нужен для того, чтобы Scrum Master мог увидеть проблему на самой ранней стадии и оперативно решить её. Вторым важным моментом данной встречи является некая синхронизация команды. Каждый член команды отвечает на вопросы:
Основные ошибки заключаются в том, что каждый начинает подробно рассказывать, что он сделал. Цель тут просто об этом объявить – сухо, кратко, без детализации, а также озвучить, куда двигаешься дальше (что будешь делать сегодня). Также следует понимать, что каждый член команды не отчитывается тем самым, скажем, перед Scrum Master или Product Owner (они вообще могут не участвовать в ежедневном митинге, но, однако, присутствие Scrum-мастера очень рекомендовано).
В нашей системе Scrum Time данный функционал реализован с помощью специального инструмента.
Sprint Review Meeting
Спринт-ревью! До этого момента всё, что делала команда, не имеет смысла. Именно на данной демонстрации становится ясно, что команда сделала так, а что – не так, и, возможно, видение заказчика / команды / потенциальных покупателей и т.д. поменяется. Быть может, они посмотрят на всё и скажут: «Всё сделано классно, так, как мы хотели, но сейчас нам стало понятно, что часть идей нужно переосмыслить». Изменения могут быть как глубокими, так и нет. Sprint Review Meeting – очень важная встреча, и мы сами используем её как основную движущую силу, как вектор развития. К нам поступает большое количество заявок на реализацию той или иной возможности, которая может быть достаточно специфична. На каждом спринт-ревью мы рассматриваем все новые заявки и жалобы, а затем формируем из них спринт-бэклог на следующий спринт. Со стороны пользователей, конечно, постоянно идёт обзор нашего продукта, но формирование задач мы делаем на Sprint Review Meeting.
Длительность ревью – 2 часа на двухнедельный недельный спринт.
Подробнее про Sprint Review Meeting
Sprint Retrospective Meeting / Ретроспектива в Scrum
Ретроспектива в Scrum – это единственное место, где Scrum Master может побить палкой. Естественно, не только побить, но и угостить мороженным, да и не только Scrum Master, а вся команда друг друга. Ретроспектива является тем местом, где команда останавливается и делает выдох, оглядывается на проделанный путь, смотрит на свои успехи и неудачи. На основе всего этого делаются правильные выводы.
Здесь главное – не стесняться обсуждать проблемы, так как каждая мелочь, решённая сейчас, в общей степени обязательно повлияет на Velocity.
Выводы записываются и необходимые коррективы вносятся к следующему спринту.
Длительность: 1 час 30 минут на двухнедельный недельный спринт.
Подробнее про ретроспективу.
Гибкая методология разработки “Scrum”
Я продолжаю работу над диссертацией по проектному менеджменту. Сегодня мы кратко рассмотрим Scrum, рассмотрим типичные ошибки, приводящие к проблемам. Данный пост не претендует на полноту, он является обзорным и адресуется тем, кто еще не знаком со Scrum, или знаком лишь частично (к примеру, работает в модифицированном Scrum).
В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].
Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно 🙂
Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂
Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)
В классическом Scrum существует 3 базовых роли:
—Product owner
—Scrum master
—Команда разработки (Development team)
Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.
Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).
Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO
Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды
Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]
Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.
Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.
Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.
По окончанию Sprint’а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint’е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.
Схематическое изображение процесса приведено на следующем рисунке: 
Важные, часто забываемые особенности
Часто можно услышать, что Scrum не работает, или работает хуже, чем ожидалось. Необходимо заметить, что чаще всего так происходит по одной из следующих причин:
1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.
2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.
3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.
Достоинства и недостатки
Scrum обладает достаточно привлекательными достоинствами. Scrum ориентирован на клиента, адаптивен. Scrum дает клиенту возможность делать изменения в требованиях в любой момент времени (но не гарантирует того, что эти изменения будут выполнены). Возможность изменения требований привлекательна для многих заказчиков ПО.
Scrum достаточно прост в изучении, позволяет экономить время, за счет исключения не критичных активностей. Scrum позволяет получить потенциально рабочий продукт в конце каждого Sprint’а.
Scrum делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. Это особенно привлекательно для малых компаний и стартапов, так как избавляет от необходимости от найма или обучения специализированного персонала руководителей.
Конечно, у Scrum есть и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей клиентоориентированности в принципе, т. к. клиенту не важны внутренние правила команды разработки, особено если они ограничивают клиента. К примеру, в случае необходимости, по решению клиента Sprint backlog может быть изменен, не смотря на явное противоречие с правилами Scrum.
Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.
Другой слабой особенностью Scrum является упор на самоорганизующуюся, многофункциональную команду. При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:
Список использованных источников
[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)
Заранее благодарю за указанные ошибки и неточности!
Планирование Спринта (Sprint Planning)
Это встреча, инициирующая Спринт и планирующая работу на этот Спринт. Является одним из 5 Мероприятий Скрама. В Планировании Спринта принимает участие вся Скрам-команда, а для консультаций могут приглашаться и другие люди.
Руководство по Scrum 2020 следующим образом описывает 3 темы и содержание Планирования Спринта.
Тема 1: Почему этот Спринт ценен?
Владелец продукта предлагает, как можно повысить ценность и практичность продукта в текущем Спринте. Затем вся Скрам-команда совместно определяет Цель Спринта, которая объясняет, почему результат Спринта будет ценен для заинтересованных лиц.
Тема 2: Что конкретно может быть сделано в этом Спринте?
Разработчики обсуждают с владельцем продукта, какие элементы Бэклога Продукта выбрать для включения в текущий Спринт. Скрам-команда может попутно уточнять эти элементы, чтобы достичь уверенности в том, что все понимают их одинаково и на уровне, достаточном для оценки этих элементов.
Оценка и основанный на ней выбор элементов, которые получится завершить за Спринт, может оказаться трудной задачей. Однако, чем больше Разработчики знают о своей прошлой Производительности, своих возможностях на следующий Спринт и своих Критериях готовности, тем более уверенно они могут прогнозировать работу, которую выполнят в ходе Спринта.
Тема 3: Как будет выполняться выбранная работа?
Для каждого выбранного элемента Бэклога Продукта, разработчики планируют работу, необходимую для создания Инкремента, соответствующего Критериям готовности. Это часто делается путем декомпозиции элементов Бэклога Спринта на более мелкие задачи продолжительностью не более одного дня. То, как это делается, остается на усмотрение разработчиков. Никто не указывает им, как превращать элементы Бэклога Продукта в Инкремент.
Цель Спринта, выбранные элементы Бэклога Продукта, а также план их реализации вместе называются Бэклогом Спринта.
Для Спринта длиной в месяц Планирование Спринта длится не более 8 часов. Для более коротких Спринтов на планирование обычно выделяется меньше времени.
Чтобы встреча была максимально короткой и все же достигла всех трех своих целей, есть следующие практические рекомендации:
Одно из 5 Мероприятий Скрама. Эта встреча длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. В нем принимают участие все разработчики. На нем озвучивается информация для оценки прогресса и отмечаются препятствия. В результате разработчики могут прийти к необходимости перепланирования работы внутри Спринта.
Одно из 5 Мероприятий Скрама. Проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Скрам-команда, при необходимости, сделала адаптацию Бэклога Продукта. Для Спринта длиной в месяц Обзор Спринта длится не более 4 часов.
Одно из 5 Мероприятий Скрама. Ретроспектива Спринта дает Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием Спринта. Для Спринта длиной в месяц эта встреча ограничивается 3 часами.
Одно из 5 Мероприятий Скрама, которое является контейнером для других мероприятий. Спринты — это короткие регулярные циклы длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Все остальные Мероприятия Скрама проводятся в рамках Спринта. Следующий Спринт начинается сразу же по окончании предыдущего.
Активность, которая проводится Владельцем Продукта при участии всех членов команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).
Уточнение бэклога обычно занимает не более 10% времени Скрам-команды в Спринте.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Как мы делали SCRUM
Страшный сон команды разработчиков — это когда до начала разработки надо «нырнуть» в неизвестную предметную область и «проэстимейтить» 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: Бизнес-анализ и адаптация методологии
Разработку любого проекта мы начинаем с бизнес-анализа: необходимо понять специфику. В любой компании всегда много процессов, и наша задача в исследовании — выяснить, как участники системы взаимодействуют между собой, прежде чем строить систему.
После раунда проблемных интервью и обработки полученной информации мы получили описание предметной области в виде примеров использования.
Хотя SCRUM не требует наличия спецификации на разработку, то, что у нас было готово описание предметной области, оказалось большим плюсом. Этот документ лег в основу product backlog — базы для старта SCRUM. Product backlog — список требований, историй, функционалов, которые упорядочены по степени важности. С такого списка все начинается. При этом все требования описаны на понятном для заказчика языке. Элементы этого списка — user story, «пользовательские истории».
User story — это описание простейших пользовательских сценариев использования системы, суть которых можно сформулировать так: «кто, что, для чего делает, каковы особенности и ограничения».
Наш product backlog из 203 истории, для удобства сгруппированных по сегментам
Пример user story
Какие мы сделали выводы после этого этапа
Шаг №2: Планирование спринта. Как мы адаптировали Sprint planning
Нашей первой ценностью для бизнеса стал электронный журнал. Для большинства опытных разработчиков это покажется утопией: перед нами чистый лист, еще нет ни одного справочника, пользовательского интерфейса, системы авторизации, ни одной бизнес-сущности, а мы обязуемся предоставить одну из сложнейших функций системы.
Как это было. Для нас обязательно было получить 2 вещи: сформулированную цель спринта и утвержденный sprint backlog.
Наш product owner всегда начинал планирование спринта с описания того, что в первую очередь нужно сделать, — наиболее значимых историй. После этого команда производила оценку трудозатрат для всех user story, начиная с самой важной. В процессе у команды возникало много вопросов по поводу того, как это должно функционировать.
Sprint planning — это очень важная SCRUM-активность. Все осознают ответственность за правильную оценку, потому что:
Пример sprint backlog
Электронный журнал после первого спринта
Упрощения и допущения для первого спринта. В системе — 2 пользователя: преподаватель и родитель; один класс — 5«А»; настоящий состав класса, внесенный вручную напрямую через SQL запросы; настоящее расписание для 5«А», сформированное также напрямую через запись в таблицы.
User story #1: преподаватель заходит в систему и проставляет оценки по любому предмету из расписания класса за день. Система с одной простой, но уже работающей функцией. Уже на sprint demo преподаватель сказал, чем пользоваться удобно, а чем — нет, чтобы в следующих спринтах команда могла запланировать корректировки и дать обновленный инструмент.
Какую реальную ценность дает: оцифрованная успеваемость реального класса, актуальные оценки, перспектива для автоматической подготовки месячной, семестровой, квартальной отчетности.
User story #2: еженедельный отчет родителям об успеваемости на почту.
Какую ценность добавляет: информирование родителей о текущей успеваемости; комментарии преподавателя к домашнему заданию; минимальную, но реальную аналитику.
После нескольких спринтов я решил, что функционала для работы преподавателей с электронным журналом хватает. Поэтому мы поставили разработку этого инструмента на паузу и сместили фокус на конструктор расписания. Это нормально для SCRUM. К электронному журналу фокус разработки я вернул через десяток спринтов, и мы, частично выбросив упрощенный функционал, довели электронный журнал до состояния, необходимого для анализа годовой успеваемости. Этот функционал на тот момент был нам нужнее. Мы получили достаточную ценность и переключили активную разработку на более приоритетные части системы.
Для справки: чтобы зафиксировать окончательную (идеальную) версию, нам приходилось возвращаться к электронному журналу в течение нескольких спринтов.
Так выглядел журнал после первого спринта, но с ним уже можно было работать
Эта версия электронного журнала была получена после 12 спринта и ее можно было показывать родителям
Еще яркий пример итеративного SCRUM-подхода — конструктор расписания
Первый конструктор расписания заказчик получил через 2 месяца после старта проекта. Это был «брутальный редактор» для очень продвинутого пользователя. Но он позволил нам ввести расписание для всех пятых классов и протестировать систему на настоящем живом расписании.
На его доработку до «визуального редактора» ушло три спринта. Фокус разработки несколько раз переключался, но к началу учебного года заказчик получил полнофункциональный конструктор расписания, с помощью которого всего за час ввел расписание с первых (А, Б, В, Г) по восьмые классы.
Проследим маршрут «брутальный редактор для настоящего админа» — «визуальный редактор» — «конструктор расписания»
А как делали расписание до этого?
Расписание составляли на склеенных листах ватмана А1 вручную: рисовали, выделяли цветными маркерами, склеивали. На это у завуча уходили недели и месяцы
Самая первая версия редактора: «Брутальный редактор для админа» — который составил расписание на 2018 год
Вторая, улучшенная версия, с помощью которой было составлено расписание 2018/2019
Конструктор расписания — окончательная версия
Какие мы сделали выводы после этого этапа
Как сделать, чтобы команда оценивала 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. Так сразу мы обнаружили невыявленные требования, которые заметил более осторожный разработчик. Плюс вскрылись глобальные задачи, связанные с персонализацией. Это прекрасный пример того, как команда может предвосхитить трудности.
Какие выводы мы сделали по методике оценки
Шаг №3: Спринт запущен. Как мы адаптировали sprint execution и ежедневный SCRUM
Ежедневный SCRUM-meeting, или stand-up, да и весь SCRUM — это история про эффективные коммуникации, которые помогают экономить время и усилия команды. Это не просто «встречи» и «разговоры». Они не отнимают время, которое можно было бы потратить на работу, а помогают оптимизировать усилия. Один из принципов SCRUM так и звучит: «Люди и взаимодействие важнее процессов и инструментов».
Каждый участник команды коротко сообщает, согласно специально разработанному checklist, что сделал, с какими проблемами столкнулся, что будет делать дальше. Человек не остается один на один с проблемой, ему быстро помогают ее решить наиболее эффективным способом. Так, инженер не тратит время на безуспешные попытки, после которых, возможно, придется переделывать с нуля, тем самым экономит ресурсы всей команды.
Кроссфункциональность: команда готова выполнять любые задачи по запуску продукта
При формировании команды мы подбирали Т-специалистов, которые разбираются во многих областях и как минимум в одной является экспертом. Благодаря такой универсальности все инженеры знают систему достаточно хорошо.
Опыт каждого ценен для поиска самого эффективного решения.
В команде у одного человека может не оказаться нужного для конкретной задачи опыта, но с большой вероятностью он будет у его коллег. То же самое со стороны заказчика: один человек может не знать каких-то деталей, а их знает другой человек.
Чтобы моя команда стала еще более самоорганизованной, я оформляла каждый спринт по четко заданному шаблону: номер, цель спринта, sprint backlog с оценкой для каждой истории, состав команды, сроки, время ежедневных собраний, организационные события. Все это так разложено по полочкам для того, чтобы, двигаясь планомерно, шаг за шагом, к концу спринта гарантированно подготовить законченную ценность для заказчика. Чтобы он был удовлетворен и немедленно начал использовать в бизнесе.
Майя Сокольская, Scrum Master
Какие выводы мы считаем важными для этапа sprint running
Шаг №4: Как мы проводили демонстрацию результатов. Наша адаптация sprint demo
Разработчики по очереди демонстрируют новый функционал вживую на реальных данных. Фокус — на том, ЧТО мы сделали, а не на том, КАК мы это делали. Вообще мы постоянно стремимся, чтобы наше демо было бизнес-ориентированным, без упоминаний про технические детали.
Как узнать, что решение подходит заказчику
Здесь опять на передний план выходит цель спринта. На наших демо часто присутствовали специально приглашенные учителя и завучи, которые не были на планировании. Они знали о продукте лишь в общих чертах. Мы всегда приветствовали, чтобы после каждой продемонстрированной истории заказчики сами попробовали что-то сделать в системе. Тогда конечный пользователь проверяет каждый пункт критерия приемки. Он говорит, что устраивает, а что нет, какие аспекты можно улучшить. И так — по каждой user story, которая была запланирована на этот спринт.
Какие выводы мы сделали по методике проведения демонстрации результатов
Шаг №5: Как мы адаптировали и проводили retrospective
Для нас ретроспектива — это важное мероприятие сразу же после sprint demo. Ретроспективы полезны, особенно когда что-то идет не так. Без ретроспектив может оказаться, что команда наступает на одни и те же грабли снова и снова.
Как застраховаться от повторения ошибок
Самые частые грабли — это когда реальная производительность команды сильно отличается от прогнозируемой. Реальная производительность рассчитывается на основании начальной оценки каждой истории. И когда в середине спринта мы понимаем, что история, оцененная в 5 story points, делается столько же, сколько обычно занимает задача на 13story points и далека от завершения, а если это еще и блокирующая история, — другие не могут быть начаты из-за неготовности проблемной. Когда цели спринта под угрозой — ретроспектива неизбежна.
Наши ретроспективы имеют абсолютно четкую структуру и цели: команда собирается вместе. Scrum Master зачитывает sprint backlog, просит высказаться каждого члена команды и оценить с его точки зрения итоги спринта. Каждый член команды высказывает свое мнение, что удалось сделать хорошо, что пошло не так и — главное — почему. Что продолжать делать, а от чего отказаться. При этом его никто не перебивает. Свои выводы, записанные на стикере, он помещает в одну из колонок:
Пример наших улучшений по результатам одной из ретроспектив
«После того как команда закончит мозговой штурм по поводу всех проблемных стикеров, я провожу «точечное голосование»: каждый член команды имеет три голоса (тремя точками маркера на стикерах). Он может отдать все свои голоса сразу одной проблеме, а может распределить иначе. Основываясь на этом командном голосовании, мы выбираем 2-3 улучшения, на которых фокусируемся в следующем спринте. А в начале следующей ретроспективы проверим, что у нас вышло. Так сказать „проверка домашки“ :)»
Одна неделя работы может сэкономить один час планирования
12% — много, но это того стоит, так как в классическом «водопаде» цена использования методологии — это отдельная роль проджект-менеджера. В среднем по нашему сегменту рынка на менеджмент затрачивается около 15% от стоимости разработки.
Какие выводы мы сделали по методике проведения ретроспектив
Шаг №6: Как мы адаптировали product backlog refinement, или Grooming
Многие коллеги, знакомые со спецификой IT, засомневаются: как во время планирования спринта команде может быть все настолько ясно, что она готова давать оценку всем user story.
Да, действительно, без подготовки такой слаженности не выйдет. Для того чтобы это так работало, существует специальная SCRUM-активность: product backlog refinement. Для ее проведения необходимо попросить product owner дать горизонт планирования: очертить, какие истории могут быть кандидатами на ближайший спринт. Если среди них окажутся истории, требующие углубленного изучения или специальных компетенций, которых нет у команды, назначается собрание — grooming/pre-planning.
Результаты grooming
Наш product owner был очень компетентным, поэтому мы всегда имели достаточный горизонт видения, как система будет развиваться, и регулярно проводили refinement. Ведь прозрачность — это один из основополагающих принципов SCRUM.
Так выглядит план проведения grooming
Какие выводы мы сделали по методике проведения refinement
Фэйлы
Да, мы откровенно в восторге от разработки по методологии SCRUM, но это не означает, что все проходило гладко. Вот три момента, где мы бы подстелили соломки, если знали заранее, что пойдет так.
Работа по привычным схемам
На одной из ретроспектив мы детально проанализировали причину аномального отклонения «реальной производительности» команды во всех историях с участием дизайнеров. Реальная производительность обычно рассчитывается по формуле: прогнозируемая производительность /фактическая производительность.
Мы обнаружили, что они по привычке организовались в знакомый им последовательный waterfall.
Как результат: задачи выполнялись последовательно, разработчики тратили время на последовательное включение на разных этапах с задержками, вызванными необходимостью доводить до конца уже начатые задачи.
Вывод: Пожалуй, самая болезненная для нас история, которая принесла больше всего вреда и выявлена была не сразу. Нужно регулярно проверять, все ли участники команды переключились на работу по новым стандартам.
Лишняя работа над ненужным функционалом
На втором спринте product owner поддался мнению одного из завучей, который считал что «журнал куратора» — крайне важный функционал. Мы взяли эту историю в спринт, потратили на нее усилия.
Почему ошибка: этот инструмент можно было тестировать только на поздних этапах, так как ему требовались накопленные данные, которых на тот момент не было.
Как результат: его не проверяли, не использовали, не развивали. Нужные функции были решены иначе и совсем не так, как думал тот завуч, совсем через другие инструменты. Вывод: берите в работу только то, чем сразу же начнут пользоваться.
Равнение на продвинутых пользователей
На одном из этапов мы взяли в работу историю с «редактором замен», в разработке которой участвовал учитель — очень опытный пользователь компьютеров. В итоге мы получили прекрасный инструмент, но его не могли использовать обычные учителя школы, которые не были такими продвинутыми.
Вывод: подтверждать историю на regular customers.
Общие выводы
Про гибкость: SCRUM позволяет быть эффективной командой
Результаты каждого спринта зависят от вводных задач, эффективности, скоординированности, ответственности команды и качественной обратной связи.
Вводные данные дает product owner. Он же отвечает за контекст, в котором будет использоваться функционал, качество формулировки требований, обеспечивает достаточную глубину детализации.
SCRUM требует от команды завершения вполне осязаемого отрезка работы, что позволяет получить ценность, то есть инструмент, который можно предоставить пользователю в конце каждой итерации. Это помогает видеть решение в работе и на начальных этапах понимать, что нужно изменить, чтобы продвинуться дальше.
Про максимально эффективное использование ресурсов
SCRUM — форма организации работы, выгодная заказчику и исполнителю. Чем?
Работа итерациями позволяет уже на ранних стадиях понимать, что идет не так, а значит — вовремя вносить коррективы. Подготовка к каждому спринту и специфика его организации помогают всякий раз делать только то, что нужно заказчику, и не уходить в сторону. И это дает колоссальную ЭФФЕКТИВНОСТЬ затраченных ресурсов, времени и усилий.
Заказчик уже на начальных этапах получает работающий участок системы: после первых спринтов берет сделанный функционал в работу и тестирует его в деле.
SCRUM — когда обе стороны застрахованы от рисков
Посмотрите как разделяется ответственность между заказчиком и исполнителем
Исчезает баррикада, по разные стороны которой в классическом проджект-менеджменте находятся исполнитель и заказчик. В принципе исчезают позиции заказчик и исполнитель, остается команда. И нет условий для возможной конфронтации.
Заказчик платит только в том случае, если все цели спринта были достигнуты. Если не разработан инструмент, который заказчик может обкатать на практике уже завтра, спринт не засчитывается.
Заказчик платит фиксированную сумму за каждый спринт, и делает свой бизнес еще на один шаг эффективнее
Исполнитель заинтересован в том, чтобы в ходе каждого спринта подготовить новый инструмент, новую ценность для заказчика, потому что это даст новый виток обратной связи и информации/опыта. Которые можно использовать для дальнейшего развития продукта.
Каждый спринт повышает уровень компетентности исполнителя, ускоряет его в реализации проекта.
Итого, всего за 7 месяцев мы сделали работающую и полностью устраивающую заказчика систему, проверенную им на практике и отражающую все пожелания, а не выдали систему, теоретически спроектированную по ТЗ, которую еще несколько месяцев нужно будет докручивать, так как практика неизбежно внесет свои коррективы.
Глобально этот кейс — про правильно подобранную методику ведения проекта в условиях большой степени неопределенности и ограниченным временем до запуска.
С таким требовательным заказчиком, с высокими стандартами качества, нам было временами очень сложною, но вместе с тем очень интересно. Те challenges которые мы преодолели, допущенные, однако вовремя осознанные и исправленные ошибки, сделанные выводы, навсегда изменили культуру в нашей команде
Наверное уже давно всем интересно узнать о самом продукте, который получился.
Заказчик получил прекрасный продукт: набор инструментов для современной школы, способный быстро трансформировать ее в школу будущего