Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
Ритуал, который отмечает начало каждого спринта, называется спринтерским планированием. Планирование спринта ведется мастером Scrum, но ответственным за большую часть контента, который входит в планирование спринта, является владелец продукта.
Задача
Целью планирования спринта является определение повестки дня предстоящего спринта. Команда собирается вместе с владельцем продукта и мастером схватки, чтобы получить представление об историях, которые должны быть завершены во время следующего спринта.
Владелец продукта показывает, как истории вписываются в видение продукта, и команда оценивает истории, которые владелец продукта представил, и берет на себя обязательство завершить столько, сколько они считают способным, учитывая их историческую скорость — что определяется количество очков, которые они смогли набрать в среднем спринте. В конце планирования спринта должна быть приверженность определенному набору историй, с которыми каждый может согласиться. Все истории должны быть ясными, и объем работы, которую они представляют, должен быть в пределах способности команды завершить во время следующего спринта.
Time Box
В зависимости от количества недель, которые команда посвятила каждому спринту, планирование спринта может занять несколько часов или весь день. Для двухнедельного спринта команда может обнаружить, что выделение трех или четырех часов — это хорошая инвестиция для планирования спринта. Может показаться, что прошло много времени, но правильное планирование спринта очень детально и четко о том, что нужно команде. Ключевой ценностью схватки является общение, которое она облегчает. Планирование Спринта иллюстрирует это.
Большинство команд обнаружат, что они могут более эффективно выполнять задачи этих ритуалов, поскольку они лучше знакомятся с процессом. Наличие сильного мастера схватки, который поддерживает четкие временные рамки вокруг различных аспектов ритуала, может помочь сделать процесс как можно более плавным.
Но во время планирования спринта многое еще предстоит сделать, и этим ритуалам должно быть предоставлено достаточно места для решения всех проблем, которые возникнут на поверхности. Начало с четкими временными ограничениями вселяет уверенность в том, что у вас есть цель и конечная точка, а также помогает людям сосредоточиться.
подготовка
В рамках подготовки к этому ритуалу владелец продукта будет работать с дизайнерами, клиентами, различными членами команды и мастером схваток, чтобы создать список ясных и конкретных историй, которые имеют наивысший приоритет для продукта.
Владелец продукта должен убедиться, что каждая из этих историй готова к работе и сформулирована таким образом, что любой член команды может прочитать и понять описание и критерии принятия каждой истории.
Представляем новые истории
Спринт-планирование дает возможность команде Scrum получить представление об историях, над которыми владелец продукта хочет, чтобы они работали для следующей итерации продукта. Во время этой части ритуала владелец продукта просматривает подготовленные истории и представляет их команде для оценки.
Для каждого члена команды важно активно участвовать во время этой презентации, потому что это их возможность подвергнуть сомнению и оспорить полноту и уместность каждой истории. Хороший владелец продукта будет обсуждать истории с экспертами в команде перед этим ритуалом, чтобы убедиться, что предсказуемые возражения были учтены.
Планирование спринта поощряет активное обсуждение каждой истории. Процесс открывает диалог, позволяющий владельцу продукта и команде детально рассмотреть последствия и выполнимость каждой истории. Несмотря на то, что владелец продукта уполномочен устанавливать приоритет журналов в списке заданий спринта, команда имеет право отклонять статьи, которые она считает невозможными, неадекватно определенными или технически неприемлемыми, до их добавления в список заданий спринта.
Эта часть ритуала планирования спринта также связана с тем, что команда несет ответственность за представление историй, связанных с самим кодом. Если владелец продукта отвечает за видение продукта, команда разработчиков отвечает за качество и удобство сопровождения кода. Ориентация на продукт в Scrum не является оправданием для игнорирования технического долга.
Часто команда рассказывает истории о рефакторинге кода, обновлении кода в соответствии с новыми стандартами или внесении важных обновлений в инфраструктуру. Для команды важно сделать веские аргументы, потому что владелец продукта имеет максимальную власть. Различные команды решают этот баланс сил по-разному, и каждая команда должна выяснить, как наилучшим образом справиться с техническим долгом, при этом отвечая ожиданиям разработки продукта.
Оценка истории
Следующим этапом планирования спринта является оценка истории . В ходе этого процесса команда оценит относительный уровень усилий, необходимых для выполнения каждой истории, основываясь на опыте команды с аналогичными историями в прошлом и их согласованном определении выполненного.
Есть много способов, которыми команды оценивают истории. При оценке важно помнить, что значения, присвоенные различным историям, являются произвольными и относительными и не имеют никакого сходства с фактическим временем. Смысл оцениваемого упражнения заключается в том, чтобы улучшить способность команды взглянуть на новую историю и выяснить, сколько усилий ей потребуется по сравнению с другими историями, над которыми они уже работали.
Большинство команд используют систему баллов для оценки историй. Маленькая, легкая история может быть оценена в один балл, а большой или сложной истории может быть назначено 20 баллов. Многие команды используют модифицированную шкалу Фибоначчи, где цифры 0, 1, 2, 3, 5, 8, 13 и 20 представляют увеличивающиеся уровни усилий. С течением времени цель состоит в том, чтобы команда получила представление о том, сколько очков они могут набрать в одном спринте, чтобы они могли более эффективно оценивать форвард.
Каждая команда придумывает свое собственное понимание того, что означает каждое значение для себя. Не может быть логического сравнения между баллами, набранными одной командой во время спринта, и баллами, набранными другой командой за тот же спринт. Значение баллов субъективно и актуально только для участников конкретной команды.
Другие системы для определения размеров историй включают в себя определение размеров футболок, таких как маленький, средний, большой, очень большой. Это полностью зависит от команды, какую систему они выбирают. После того, как команда выбрала систему, она должна попытаться придерживаться ее в течение нескольких спринтов, чтобы они могли со временем почувствовать, какова их скорость в метрике, которую они выбрали.
Примечание: каждый должен согласиться
Для всех в команде важно согласиться с точной оценкой для истории, независимо от того, будет ли каждый член команды работать над этой конкретной историей. Это часть прозрачности схватки. Каждый в команде должен быть в состоянии понять каждую историю достаточно хорошо, чтобы оценить ее относительный уровень усилий, и когда один участник команды работает над историей, у каждого должно быть по крайней мере представление о том, что это за история.
ошибки
Другие истории, которым обычно не присваиваются баллы, являются ошибками. У ошибки есть определенное определение в scrum, и оно не имеет ничего общего с неожиданным или нежелательным поведением в существующем продукте. Ошибки в схватке — это пропущенные требования для историй, которые еще находятся в процессе разработки или уже были приняты как выполненные в предыдущем спринте.
Если команда завершила историю, и она была принята, и очки были включены в общую сумму за спринт, но позже выясняется, что история не была завершена правильно, очки не назначаются для исправления ошибок, чтобы донести историю до готовое состояние.
Работа с ошибками отнимает у команды скорость, потому что она касается точек, которые были неправильно учтены в расчете скорости. Это должно быть правдой независимо от того, исправлена ли ошибка в том же спринте или в последующем спринте. До тех пор, пока команда получала очки за историю, которая не соответствовала критериям приемлемости, работа по приведению ее в правильное состояние не должна учитываться при подсчете очков в любом спринте.
Примечание: вам не нужно выделять емкость для ошибок
Нет необходимости выделять процент от способности команды справляться с ошибками. Объем работы, который команда может предсказуемо выполнить в типичном спринте, включает в себя усилия, приложенные для исправления ошибок, когда истории были приняты как выполненные, но на самом деле не отвечали всем критериям приемлемости.
Задания
Есть старая шутка о том, что схватка — это система, позволяющая улучшить способность команды отрабатывать технические долги. Конечно, разработка веб-приложения или мобильного приложения — это нечто большее, чем просто использование набора функций в постоянно растущей и все более сложной кодовой базе. В конце концов, этот код должен быть пересмотрен, придется работать над изменениями инфраструктуры, и команда не сможет эффективно работать над новыми функциями, пока эти проблемы не будут решены. Эти необходимые улучшения могут не иметь особой ценности для клиента, но они необходимы для того, чтобы код не становился устаревшим или сложным в обслуживании.
Задачи, связанные с обслуживанием кода, должны быть включены в работу, проделанную командой, и иметь приоритет в зачете спринта, но не должны оцениваться с баллами. Точки в схватке измеряют способность команды обеспечивать ценность для клиента и связаны с разработкой функций. Они не являются показателем общего объема работы, которую выполняет команда.
Задача обычно не доставляет ощутимой пользовательской ценности. Но задачи должны быть выполнены, и необходимо провести переговоры между командой и владельцем продукта во время планирования спринта, если команда признает, что необходимая работа по поддержанию работоспособности систем и избежанию технического долга откладывается в пользу новых функций.
Шипы
Большинство историй, связанных с планированием спринта, должны быть в пределах технических возможностей команды, но иногда будут истории, которые требуют более глубокого исследования. Такие истории вызывают новые задачи, называемые шипами . Шипам обычно не присваиваются баллы. Тем не менее, правильный всплеск имеет критерии приемлемости. Должен быть четкий и согласованный результат для любого всплеска.
Шипы отнимают у команды ресурсы, в то время как частные лица идут и исследуют технические решения, которые могут выходить за рамки текущих возможностей команды. В результате, чем больше всплесков требуется для достижения целей владельца продукта, тем меньше очков набирает команда в спринте.
Из-за неизвестной природы шипов, они могут съесть много ресурсов команды, если они не ограничены. Обычно, соглашаясь включить шип в спринт, команда принимает решение о максимальном количестве времени и усилий, которые могут быть предприняты до того, как шип должен быть завершен или отменен.
Принятие обязательств в спринте
После того, как все истории, представленные владельцем продукта, были оценены, все участники ритуала работают вместе, чтобы подготовить резерв, который имеет смысл для предстоящего спринта. Это отставание будет измеряться на основе исторического количества баллов, которые команда смогла достичь в прошлом, с учетом балльных оценок для новых историй.
В то время как владелец продукта имеет окончательные полномочия над содержимым журнала невыполненных работ спринта, а также над порядком журнала заданий спринта, у команды есть возможность отстаивать определенные изменения во время подготовки журнала незавершенного производства.
Например, хотя каждая история должна стоять отдельно, команде может иметь смысл работать над конкретными историями в определенном порядке. Команда может также пожелать завершить истории, которые были начаты, но не закончены в предыдущем спринте. Завершение истории, которая находится в процессе, полезно для команды разработчиков, потому что это помогает им поддерживать преемственность. Несмотря на то, что за потерю преемственности приходится платить, ответственность за нее несет владелец продукта, и владелец продукта имеет право принимать эти решения ради продукта.
После создания окончательного журнала невыполненных работ спринту все в команде должны зафиксировать это отставание. Это последняя возможность для команды возразить или поднять проблемы, которые, по их мнению, могут повлиять на их способность выполнять требуемую работу. Если все еще есть разногласие, хозяин схватки должен вмешаться и облегчить разговор, чтобы соглашение могло быть достигнуто.
Конечным продуктом планирования спринта является отставание спринта, с которым могут согласиться все члены команды. Скрам-мастер должен провести опрос в комнате, чтобы убедиться, что все согласны с тем, что обязательство является реалистичным, и что они готовы принять его для предстоящего спринта. Затем новые истории следует вводить в порядке приоритета в инструменты отслеживания, которые команда согласилась использовать для отставания в спринте.
Планирование спринта напоминает всем, где именно они находятся в процессе формирования видения продукта владельцем продукта, и каковы цели будущего роста. В конце планирования спринта все в команде должны иметь четкое представление о том, что им нужно делать дальше, и твердо предаться набору приоритетных историй, которые необходимо выполнить в течение всего предстоящего спринта.