Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
В конце спринта все, над чем работали для текущего спринта, демонстрируется команде, владельцу продукта и всем, кто приглашен для наблюдения. Этот ритуал называется демонстрацией спринта, и он дает всем инженерам возможность продемонстрировать истории, над которыми они работают, которые они считают завершенными. Демонстрация спринта — это возможность владельца продукта протестировать каждую историю, проверить, соответствует ли она критериям приемлемости, а затем принять или отклонить ее.
Цель демонстрации спринта состоит в том, чтобы получить четкое представление о том, сколько работы было выполнено во время спринта, и увидеть, каким будет текущее состояние продукта после интеграции работы, которая была проделана во время спринта. Основываясь на принятых историях, команда узнает больше о том, сколько баллов они могут достичь за один спринт, и это улучшает их способность оценивать истории и журналы спринтов в будущем.
Примечание: гости в Sprint Demos
Демонстрация спринта часто является популярным ритуалом для гостей, потому что у людей, не входящих в команду Scrum, есть возможность увидеть, над чем работала команда, и наблюдать за состоянием продукта на его следующей итерации, основываясь на последней произведенной работе. Но нельзя допускать, чтобы присутствие гостей мешало целям ритуала или изменяло время. Гости — наблюдатели, а не участники. Если от гостей не поступают отзывы, их следует попросить не комментировать продукт или процесс.
Time Box
Время, отведенное на планирование спринта, зависит от количества историй, выполненных во время спринта, и уровня сложности, связанной с критериями приемлемости. Большинство команд выделяют полдня на демонстрацию спринта, если они используют двухнедельный спринт. После того, как команда решила, сколько времени они хотят посвятить демонстрации, хозяин схватки должен нести ответственность за то, чтобы все, что должно произойти, вписывалось в этот временной интервал.
Примечание: совместное планирование демонстраций и ретроспектив
Часто команды планируют ретроспективу спринта (о которой мы вскоре расскажем) в тот же день, что и демонстрация. Преимущество планирования этих двух ритуалов в один и тот же день состоит в том, что перерыв в производительности, связанный с ритуалами, сводится к минимуму. Недостатком для команды является то, что в наши дни производят в основном скрам-артефакты, а не материальные разработки продукта. Этот компромисс нужно учитывать, и разные команды будут иметь разные предпочтения.
подготовка
Демонстрация спринта — это возможность для команды показать всю работу, которую они проделали, и продемонстрировать, что все истории, над которыми они работали, сделаны и готовы включить в продукт (при условии, что они этого не сделали). был уже). Демонстрация охватывает всю работу до начала спринта, в котором рассказывается о том, что команда сделала, независимо от того, была ли эта работа выпущена или нет. Каждый человек, который работал над любыми историями, готовыми к демонстрации, должен быть готов объяснить, что они сделали с этими историями.
Часто инженеры собираются вместе с владельцем продукта перед демонстрацией, чтобы убедиться, что все знают о том, что будет представлено. Это может быть полезным последним шагом перед демонстрацией, поскольку оно гарантирует, что представленные истории соответствуют всем критериям приемлемости. Это также напоминает инженерам о необходимости подготовиться к демонстрации неизданных историй.
Мастер Scrum должен встретиться со всеми инженерами, у которых есть законченные истории, чтобы убедиться, что эти истории подготовлены для демонстрации. Ответственность за проведение ритуала лежит на мастере схватки, и следит за тем, чтобы все, что нужно продемонстрировать, могло быть представлено в выделенное время. Повестка дня Scrum Master для ритуала должна включать список всех историй, которые будут продемонстрированы, а также людей, ответственных за каждую из историй.
Совет: пусть владелец продукта ведет демо
Хотя некоторые команды позволяют инженерам демонстрировать истории, хорошей практикой является участие владельца продукта, тестирующего продукт вживую. Инженер, который разрабатывал новую функцию, знает счастливый путь для кода, который всегда будет работать. Но владелец продукта будет искать крайние случаи и знает о критериях приемлемости, которые являются наиболее важными. Наличие инженера, создающего демо, и присутствия владельца продукта, вовлекает всех и гарантирует, что истории сделаны к удовлетворению владельца продукта.
Демонстрация истории
Процесс демонстрации каждой истории должен быть последовательным. Скраммастер должен просмотреть каждую историю в списке, и инженеры должны подготовить демо для команды. Многие команды предпочитают делать это с помощью проектора в конференц-зале, хотя это можно сделать, собрав вокруг большого монитора или даже с помощью удаленных служб конференц-связи, в зависимости от характера сюжета и предпочтений команды.
На этом этапе спринта описание истории будет знакомо большинству людей в комнате, но владелец продукта должен прочитать историю — а также любые основные критерии приемлемости — команде, пока идет демонстрация вверх. Таким образом, все будут знать, что искать, и будут знать о проблемах, которые могут возникнуть.
Как только история подготовлена и готова к демонстрации, основное внимание уделяется состоянию продукта. Каждая история должна быть полной частью функциональности, добавленной к продукту, и демонстрация должна показать эту часть функциональности в контексте с фактическим продуктом. Демо должно пройти через каждый из критериев приемлемости, доказывая, что они были выполнены.
Иногда во время демонстрации выясняется, что критерии приемлемости в том виде, в котором они были изначально написаны, были неадекватными и, возможно, не охватывали все случаи, в которых владелец продукта нуждался в решении. Если это произойдет, имейте в виду, что демонстрация, которая соответствует всем критериям приемлемости — как они были указаны в истории, которая была оценена при планировании спринта — должна считаться принятой и сделанной. Любые дальнейшие изменения, которые могут потребоваться, являются новыми историями. Владелец продукта в этой ситуации должен быть готов создать новые истории для будущего спринта, которые связаны с дополнительными критериями приемлемости, которые не были рассмотрены в оригинальной истории.
Предупреждение: не вдавайтесь в подробности о возникших проблемах
Хотя для инженеров, которые работали над историей, может быть заманчиво и полезно подробно рассказать о трудностях или новых уроках, полученных в результате разработки конкретной истории, демонстрация не является подходящим временем для этого. Если разговор переходит к этим темам, мастер схватки должен побудить людей записать эти моменты и обсудить их на ретроспективе. В противном случае демонстрация может превратиться в длительный диалог о деталях создания каждой истории, а не в демонстрацию продукта с новыми историями на месте.
Подсчет очков
В конце демонстрации будет принят ряд историй, а некоторые могут быть отклонены. Мастер схватки должен сложить количество баллов, набранных во время спринта, основываясь исключительно на оценочных баллах, присвоенных историям, которые были приняты как выполненные. Только истории, которые были приняты как выполненные и которым были назначены баллы при планировании спринта, должны быть включены в эту общую сумму. Общее количество очков, набранных в спринте, должно быть записано как скорость команды для этого спринта.
Некоторые истории могут быть отклонены или не готовы к демонстрации, несмотря на то, что они включены в список спринтов. Владелец продукта будет решать, будут ли не завершенные истории добавлены к следующему спринту или отложены в ожидании возможного будущего спринта. Мастер Скрама должен отслеживать все истории, как законченные, так и еще не завершенные, и обновлять их статус в любых инструментах отслеживания, которые может использовать команда.
Часто мастер Scrum генерирует набор отчетов, которые отправляются в конце демонстрации спринта, информируя заинтересованные стороны о состоянии продукта. Если команда решила провести демонстрацию спринта и ретроспективу спринта в один и тот же день, мастер схватки может захотеть составить расписание так, чтобы необходимые данные для этих отчетов могли быть собраны между двумя ритуалами, таким образом делая их доступными для ссылка.
Выпуская Истории
Выпуск — это процесс, который берет законченные функции и интегрирует их в работающий продукт, либо пользователи могут сразу получить к ним доступ, либо их можно оценить для включения в будущий выпуск. Процесс может контролироваться инженерами релизов или может быть интегрирован на уровне разработчика с набором отказоустойчивых сейфов и процедур отката.
У веб-и мобильных команд есть много вариантов, когда дело доходит до выпуска. Для некоторых команд раскрытие истории клиенту сразу после его завершения — иногда несколько раз в течение одного дня — имеет смысл. Для других процесс выпуска более сложен, и имеет больше смысла группировать истории из всего спринта или даже из нескольких спринтов и делать более крупные унифицированные выпуски.
Непрерывная интеграция — это подход, который поддерживает выпуск историй по мере их завершения, а не ожидание окончания спринта. Обычно это зависит от надежного набора тестов и отлаженного набора сценариев выпуска. Для команд, осуществляющих непрерывную интеграцию, выпуск историй в живой продукт уже будет сделан как часть завершения самих историй, и после демонстрации никаких дополнительных шагов не потребуется.
Примечание. Использование непрерывной интеграции
Когда команда решила сделать непрерывную интеграцию, важно, чтобы инженеры, работающие над историей, не отказывались от этой истории, пока она не была выпущена, и продемонстрировали, что не создают никаких проблем в живом продукте. Хотя это может привести к некоторому простою для инженеров, это время может иногда применяться к историям, связанным с поддержкой и улучшением базы кода.
Для команд, не занимающихся непрерывной интеграцией, будет еще одна задача, необходимая для выпуска всех историй из спринта в производство. Задачи, связанные с процессом выпуска, обычно считаются частью определения выполненного для истории, но в этом случае их может потребоваться выполнить после демонстрации.
Некоторые команды регулярно планируют релизы в начале каждого спринта. Другие выпускают чаще или могут выпускать только в определенное время года или по графику, чтобы согласовать с определенными событиями, связанными с потребностями более крупной организации или рынка. Выяснение того, как планировать и планировать выпуски, — это возможность для команды обдумать и повторить свой процесс, найти ритм, который лучше всего подходит для них и наилучшим образом соответствует целям владельца продукта.
Примечание: работа по графику выпуска
Независимо от фактического графика выпуска, для всех в команде важно понимать, что то, что будет выпущено, — это только то, что было завершено. Скрам не о том, чтобы торопиться закончить определенные истории, чтобы уложиться в заранее определенные сроки. Scrum — это работа в устойчивом темпе, изучение того, на что способна команда, и выпуск того, что было сделано, когда оно будет готово.
Команда должна противостоять любым усилиям по встраиванию новых историй в конкретный спринт для соблюдения графика выпуска. Если даты не могут быть скорректированы, владелец продукта должен быть готов к компромиссу, решая, какие функции следует исключить из запланированного выпуска, чтобы у команды было время для выполнения наиболее важных функций.