что такое планирование спринтами

Scrum — реальный опыт работы по методологии

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

Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».

Какие роли есть в Scrum

С чего обычно начинается разработка программного обеспечения? С идеи: «Как было бы замечательно, если бы у меня было некое ПО, которое делало бы примерно вот это. Было бы просто супер!» Человека, который в команде будет представлять эту идею, называют Product Owner (PO) или Владелец продукта. Product Owner – это тот, кто видит цель продукта или кому кажется, что он видит цель продукта, но важно то, что он может ее сформулировать и начать процесс движения к ее достижению. Цель он формирует в виде списка своих пожеланий (хотелок). Этот список называется Product Backlog Items (PBI). Он постоянно модифицируется в зависимости ситуации на рынке или от разрастающегося аппетита Product Owner’a.

Команда. По Scrum считается, что наибольшая эффективность разработки достигается в том случае, если команда сама будет самостоятельно принимать решения в отношении того, как она будет двигаться к цели. Поэтому основное требование к команде – она должна быть самоорганизующейся и самоуправляемой. Обеспечьте одно это требование, и этого будет достаточно для успеха проекта. Так как требование серьезное, то в команду вводится роль ScrumMaster’a, который следит за тем, чтобы соблюдались правила Scrum.

Что такое спринт и зачем он нужен

ProductOwner сформулировал свою цель в виде некого пункта B, который нужно достичь, начав движение с пункта A. Но пункт B – это не точка, в которую можно попасть, просто нарисовав прямую линию между ней и пунктом А. На самом деле пункт B это окрестность точки, и радиус ее может варьироваться.

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

Как формируется список задач на спринт

В команде спринт длится 2 недели. За неделю ничего не успевается, за месяц все забывается. Поэтому 2 недели для нас самый оптимальный вариант. Первый день спринта уходит на планирование. На ранних этапах на планирование уходило даже 2 дня. Планирование – это процесс, при котором команда берет из списка требований наиболее приоритетные и разбивает на задачи, которые позволяют достичь результата. Каждая задача оценивается в часах. Желательно, чтобы задача не занимала времени больше, чем 4 часа. Если участник команды говорит, что сделает задачу за 5 дней, значит, он понятия не имеет, что нужно сделать.
Общее количество часов в спринте на каждого человека рассчитывается из того, что спринт длится 2 недели или 10 рабочих дней. Это 80 часов минус один день на планирование. Итого 72 часа. Но это идеальные часы. Это значит, что человек ни на что не отвлекается, не ест, не пьет, с места не встает, а только работает и не устает. Во время планирования задача оцениваются в идеальных часах. Но набирается для человека не 72 часа, а 72 часа, умноженные на некий коэффициент, который называется производительностью команды. Обычно это 0.5. Удивительно, но это какое-то магическое число, именно при нем весь спринт сдается успешно. Кто-то из великих сказал: «Возьмите время, которые назвал вам разработчик, умножьте его на два и еще немного прибавьте и получите срок, за который вам программист выдаст результат». И это действительно так.
В Scrum есть несколько рекомендаций в отношении того, как исполнителю оценивать время на задачу. Например, играть в покер. Но мы этим не грешим. Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт. И только он может оценить, сколько ему нужно времени на выполнение задачи. Единственные, кто ему может помешать завысить сроки, это его совесть (помните про самоорганизацию) и ScrumMaster.

Как проверить, что требование ProductOwner’а выполнено

Есть список требований. Но как проверить, достигнуто это требование в ходе разработки или нет? Для этого необходимо написать тесты, в которых будет детально описано то, что считать достижением требования. Просто говоря, в них описано то, на какую кнопку нажать, и что при этом получится. В команде тесты пишут аналитики. И тесты эти должны быть готовы к моменту запуска очередного спринта. У нас в команде аналитики и дизайнеры работают с опережением команды разработчиков на 1 спринт.

Главное требование – тесты должны быть очень подробными.

Что происходит во время спринта

Начинается процесс исполнения спринта. Главная его цель – добиться, чтобы тесты, предъявляемые к требованиям, к концу спринта выполнялись.
Для сплоченного движения команды к цели Scrum предлагает делать ежедневные митинги. Митинг – это когда каждый, стоя у доски с маркером, вычеркивает то, что он сделал вчера и пишет то, что он собирается сделать сегодня.

Это очень мощная практика. Благодаря ей каждый знает, куда движется проект в целом. К тому же когда человек, рассказывает, что он будет делать сегодня, то он автоматически координирует свои действия с другими участниками. Другие участники могут тут же предложить лучшие решения задачи. А еще написанная на доске задача, а по сути — это обещание всем своим коллегам, очень хорошо мотивирует самого исполнителя. Единственное, ScrumMaster не должен забывать объявлять, что начался митинг.
Митинги проводить желательно стоя и длительностью не более 15 минут. Мы начинаем митинги в 9 утра.

Что происходит в конце спринта

Наступает долгожданный конец спринта, обычно это пятница в 16:00, и команда сдает спринт Product Owner’у и всем-всем, кто заинтересован в продукте. Каждый отчитывается по задачам, которые выполнял и рассказывает о том, каких успехов достиг, а также объясняет причины, по которым не удалось достичь цели. Главное правило — никогда не переносите срок сдачи спринта.
Иногда после сдачи спринта делается анализ того, почему что-то происходит или не происходит, и что нужно предпринять, чтобы исправить ситуацию.
А в понедельник все повторяется сначала.

Накопленный опыт

Мы для себя выработали несколько правил, несоблюдение которых приводило к провалу спринта:
• Спринт надо планировать детально, не жалея на это сил. Если что-то из требований непонятно, то надо прояснять требование. Если это не удается сделать, то не надо брать задачу в спринт, а требование отправлять на доработку.
• Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.
• Количество человек в команде не должно превышать 5-6 человек. Когда наша команда выросла до 16 человек, митинг начал затягиваться на 2 часа. Ввели фиксированное время выступления для каждого и стояли с секундомером. Но тогда человек не успевал донести свою мысль, и митинг превращался в формальность. Поэтому мы просто разделились. Сначала поделились на клиентщиков и ядерщиков, а потом начали делиться по задачам. Т.е. каждая команда делает свою фичу, и в этой подкоманде есть как клиентщики, так и ядерщики. Этот подход используется до сих пор, и для нас он наиболее эффективен.

Вывод

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

Кто мы?

Команда, в которой я работаю, называется «Юниклауд Лабс». Это дружный коллектив интересных людей, реально болеющих за свое дело.

Вариков Андрей VAndrey
Технический директор ООО «Юниклауд Лабс»

Источник

Планирование в Agile методологии

Раздел планирования описан на примере планирования спринта для итерационных моделей разработки.

Планирование Спринта

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

Планирование спринта ограничено по времени. Для спринта длительностью один месяц планирование не должно занимать более 8 часов. Если спринт короче, то и планирование проводится быстрее.

Скрам-мастер убеждается, что событие состоялось, а участники понимали его цель. Скрам-мастер обучает скрам-команду соблюдать временное ограничение.

По результатам планирования спринта скрам-команда решает:

Тема первая: что будет сделано?

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

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

Тема вторая: как будет выполнена работа?

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

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

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

Команда разработки самоорганизуется как во время спринта, так и во время его планирования при работе над бэклогом спринта.

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

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

Цель Спринта

Цель Спринта – это установленный для спринта ориентир, который достигается через выполнение части бэклога продукта. Цель спринта формируется во время его планирования и объясняет команде разработки, для чего создается инкремент.

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

Цель спринта – это ориентир для команды разработки. Чтобы его достичь, команда должна использовать технологии и реализовывать функциональность. Если объём работ становится отличным от ожиданий команды разработки, команда договаривается с владельцем продукта об объёме бэклога текущего спринта.

ЧТО ТАКОЕ ПЛАНИРОВАНИЕ СПРИНТА?

Планирование спринта — это ограниченная по времени встреча в начале спринта, на которой команда и владелец продукта (ВП) обсуждают и принимают решение о том, какая работа будет завершена в спринте.

Как правило, встреча делится на две части: «Что?» и «Как?».

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

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

КАК ЭТО ВЫГЛЯДИТ?

ЧАСТЫЕ ПРОБЛЕМЫ

ПЕРЕД ПЛАНИРОВАНИЕМ СПРИНТА

Чек-лист для подготовки к успешному планированию:

ДЛИТЕЛЬНОСТЬ

Длительность встречи зависит от длины спринта, чем дольше спринт, тем больше времени нужно для его планирования. Для ориентира:

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

Задача встречи — сформулировать цель спринта. Ее можно представить в форме беклога спринта. Беклог спринта — список приоритезированных задач, которые команда берется завершить до конца спринта. Здесь важно помнить о командных критериях готовности (Definition of Done).

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

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

СТРУКТУРА ВСТРЕЧИ

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

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

РАЗБИВКА ЗАДАЧ

РАБОЧАЯ СРЕДА

Команде важно чувствовать себя в безопасности, понимать, что нормально не знать всего прямо сейчас. Agile весь состоит из адаптации, подстройки и обучения. Должно быть ощущение сотрудничества, поддержки, любопытства и драйва. Команда не должна бояться задавать вопросы, высказываться. Команде важно чувствовать уверенность в том, что они действительно могут поставить и какие взять на себя обязательства; и если у них есть какие-то сомнения или возникают риски, отнеситесь к ним всерьез. Очень важно, что последнее слово о поставке остается за командой, а не владельцем продукта.

Автономия команды

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

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

Активное слушание

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

Взаимное уважение

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

ВП отвечает за «почему» и команда должна позволить ему сосредоточиться на этом. ВП отвечает за управление заинтересованными сторонами и представляет голос бизнеса.
Команда ответственна за «как», ВП слушает и, возможно, делится мнением, но никоим образом не диктует команде, как выполнять задачи, это их работа и они в этом профи. С обеих сторон нужно взаимное уважение и четкое определение ролей для каждого.

Вопросы

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

Процесс

ЗАВЕРШЕНИЕ ВСТРЕЧИ

Планирование спринта ограничено во времени, заканчивайте его вовремя. Даже если фактически планирование еще не закончено, важно начать работу, продолжение встречи не поможет завершить пользовательские истории. Совершенно нормально не знать всех деталей, это развивает гибкость!

Иногда команде необходима смелость сказать «Ок, этого достаточно, мы не знаем всех деталей, но будем изучать оставшиеся и приспосабливаться по пути». Быть гибким — значит экспериментировать, изобретать, и старт работы дает команде шанс сделать это!

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

Capacity

Velocity Scrum

Если представить себе движение автомобиля, то скорость в нем оценивается по спидометру и тогда всё предельно ясно. Однако, в жизни в целом и в каком-то конкретном деле нет спидометра и как оценить скорость объективно — вопрос. Если представить, что на автомобиле сломался спидометр, то скорость может быть оценена постфактум, то есть, когда человек будет ехать 60 минут и проедет, например, 100 км, затем опять пройдет 60 минут, но проедет 120 км, он будет видеть с какой скоростью он двигался – около 110 км/ч. При этом, если во время следующих 60 минут он остановится и потратит на заправку 12 минут, на обед 15 минут и проедет 55 км, то средняя скоростьза весь путь составит – 98 км/ч.

Как и в движении на автомобиле, скорость можно измерять и в Scrum, и называется это Velocity (скорость). Расчет Scrum Velocity очень простой и также состоит из поставленных отметок, как через каждые 60 минут было какое-то количество километров.

Для примера, предоставим график Velocity, отображающий по горизонтальной оси количество Sprints, а по вертикальной — Story Points.

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

Если быть кратким в сравнении с движением по дороги, то список ассоциаций, влияющих на скорость, может быть такой:

Хочется, однако, отметить, что по поводу метрики Velocity в Scrum ходят споры, и кто-то считает данные графики не очень полезными и сложными в определении возможных проблем, да и самого разгона. В целом, все сходятся во мнении, что Velocity должен использоваться специалистом, как дополнительное наглядное отображение эффективности, которое как калька накладывается на другие данные, помогая скорректировать аналитическую работу Scrum Master.

Трудозатраты — количество рабочего времени, необходимого для выполнения работы (выражается в человеко-часах).

Перед выполнением каждого задания, возникают следующие вопросы:

Оценка трудозатрат

Алгоритм обучения формированию оценки:

Полезные идеи по формированию оценки трудозатрат:

Оценка с использованием структурной декомпозиции

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

В процессе выполнения структурной декомпозиции большие задачи делятся на всё более и более мелкие подзадачи, что позволяет:

Если абстрагироваться от научного подхода и формул, то суть такой оценки сводится к следующим шагам:

Оценка трудозатрат (помимо получения данных непосредственно о необходимом количестве персонала для тестирования) также позволяет определить:

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

Метод «пальцем в небо»

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

Экспертная оценка

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

Специальный метод

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

Структура декомпозиции работ

Расчет количества заданий, выполнение которых ожидается от команды на этапе тестирования, осуществляется на декомпозиции проекта на определённые логические более мелкие части (например: модули –-> подмодули —> функциональности). И уже после проведения декомпозиции оценивается объем работ каждой небольшой части проекта.

Например, протестировать авторизацию. Буква «о» не проходит – можно сходу сказать 5 мин для себя. Это минимальная единица. Такое может определить даже человек, который работает всего пару месяцев. Плюс в таком методе – Вам сложнее что-то забыть.

Метод Дельфи

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

Данный метод характеризуется значительной точностью.

Метод определения трудозатрат в процентном отношении к разработке

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

Метод процентного распределения

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

При осуществлении оценки трудозатрат принимаются во внимание также следующие факторы:

Обратите внимание на диаграмму: здесь приведена статистика для сайтов от полугода – года. Программирование занимает от 20% до 40% разработки, это не тоже самое, что 20-40% от проекта, а это, в среднем, 15% от проекта. Тестирование никогда не занимает 15% от продукта. Если у вас не закладывают столько время для тестирования, то закладывайте хоть сколько-нибудь. Желательно, выясните статистически, какой процент от проекта занимает тестирование и это применимо, если у Вас стабильные версии релизов, постоянный объем продуктов один и тот же.

Planning Poker (Scrum Poker)

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

Что собой представляют карты для Planning Poker / Scrum Poker

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

Есть несколько вариантов карт, которые пользуются большой популярностью.

1 вид популярной колоды для Planning Poker:

Карточки представляют собой последовательность чисел Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.

2 вид популярной колоды для Planning Poker:

Как проходит Scrum Poker / Planning Poker

Один человек является ведущим и он не участвует в «игре». На обсуждение выносятся поочередно пункты, которые необходимо оценить. Каждый пункт позволено обсудить и провести обзор без оценочных данных. После этого каждый член команды выбирает карточку и кладет её рубашкой вверх. После того, как все положили карты – они вскрываются. Идеальным состоянием считается, если разброса в значениях практически нет. Как можно догадаться, такое бывает не всегда. Так или иначе в выброшенных картах будут наименьшие и наибольшие значения. Людям, выбросившим такие карточки, дают слово и они высказывают свое мнение, почему оценка была именно такой. Это позволяет получить больше информации всей остальной команде и задуматься, услышав доводы, либо объяснить выбросившим высокие или низкие позиции свою точку зрения.

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

Основные проблемы в использовании Planning Poker

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

Эффект привязки в Scrum Poker

Главной проблемой всегда был эффект привязки, который может проявлять себя по-разному. Главной ошибкой, вызывающей этот эффект, является открытое обсуждение оценок. Если тот, кто начинает обсуждение, говорит примерно следующее: «Я считаю, что данное задание займет 18 часов разработки», то, так или иначе, все будут акцентированы на сроке в 18 часов, и тот, кто считал, что задача будет решена за 2 дня, может подумать, что на самом деле и 18 часов будет достаточно, а тот, кто думал про 5 часов, может подумать, что недооценил. С одной стороны, консенсус достигается быстрее, но с другой стороны, он не будет эффективным, а эффективность – это то, для чего мы всё это делаем. В такой ситуации больше в результат войдет мнение одного человека, а не команды.

Не выделяться из толпы

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

Story Points

Одна из самых важных сторон методологии Scrum – так называемые Story Points. Эта сторона очень плотно интегрирована в Scrum совместно с технологией Planning Poker.

Самая частая проблема в работе Scrum Team – это неумение правильно оценивать сложность работы и временные затраты на её выполнение.

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

Рано или поздно использование такого подхода сделает из Вас классную и прогрессирующую команду, что и есть единственно верное направление. Постоянно модернизирующаяся команда, всегда будет разгонять свой Velocity и радовать своих заказчиков успехами.

Что же происходит на самом деле при Story Points?

Когда Scrum Team способна оценивать свою работу, ведет график Velocity, следит за Диаграммой сгорания задач, рано или поздно (или с самого начала работы) абсолютно все оценки будут вестись в Story Points.

Например, по графику Velocity можно увидеть, что динамика команды по среднему разгону за каждый Sprint идет вверх и среднее значения за последние две итерации составили 23-30 Story Points (зависит от выбранной системы оценок). Глядя на эти показатели Product Owner может видеть, на какие задачи потратить доступные очки, чтобы заполнить Backlog.

Ретроспектива спринта

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

Ретроспектива спринта проводится после обзора спринта и перед планированием следующего спринта. Максимальная продолжительность ретроспективы – 3 часа (для спринта длительностью один месяц). Для более коротких спринтов, как правило, отводится меньше времени.

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

Цели проведения ретроспективы спринта:

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

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

Sprint Review Meeting

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

Не стоит относится к Sprint Review Meeting как к формальной четко поставленной встрече с развернутыми докладами. Sprint Review Meeting это всё же просто логическое завершение Sprint. На подготовку к этой встрече не позволительно готовиться более 2 часов и запрещено использование слайдов типа PowerPoint.

В ходе Sprint Review Meeting проект оценивается в отношении цели спринта, которая была определена во время планирования. В идеале, команда выполнила все задачи из Product Backlog, помещенные в Sprint, но это не самое важное, а важно то, что была достигнута цель спринта.

Более подробно, на что смотрит заказчик на Sprint Review Meeting:

Время Sprint Review Meeting

Время данного обзора строится по следующей формуле: за каждую неделю Sprint набегает 1 час обзора. То есть, если Sprint был четырехнедельным, то Sprint Review Meeting будет длится 4 часа. Проводится эта встреча в последний день спринта.

Пример Sprint Review Meeting

Один созданный пример на всю базу знаний можно и упомянуть здесь. Разработка интернет магазина, описываемая в разных статьях нашей Info Base, само собой разумеется, имеет спринты, а спринты имеют Sprint Review Meeting.

Sprint Review Meeting при разработке интернет магазина

Имея данный Product Backlog, в Sprint были добавлены задачи из первого релиза. А точнее, мы имеем задачи:

На Sprint Review Meeting, соответственно, будут продемонстрированы возможности по добавлению продуктов в базу интернет магазина и возможность их удалять. Также продемонстрирована работа корзины с возможностью оплаты заказа по карте или выбором наложенного платежа.

Источник