спринт. Если же такие задачи составляют большинство, то надо придумывать другие механизмы.
Один из них – splitting sprint, при котором команда живет в двух спринтах, сдвинутых относительно друг друга, например, на неделю, в первом происходит разработка и тестирование вплоть до выкатке на боевые сервера, которое носит предсказуемый характер, а во втором —тестирование на реальных пользователях и экспресс-доработки по его результатам. Планирование учитывает оба процесса и связано с первым циклом спринтов, а демо может проходить дважды или быть связано со вторым циклом. Отметим, что команда при этом остается общей, и хотя разработку и тестирование на пользователях часто делают разные специалисты, экспресс-доработки и решение проблем требуют участия всей команды. Другой вариант – вынести получение обратной связи от пользователей за пределы Scrum в отдельный Kanban-процесс. Он целесообразен в том случае, если с ним связаны длительные временные лаги, не укладывающиеся в короткий Scrum-цикл.
Отметим, что оба этих механизма могут применяться так же для предварительной подготовке бэклога к разработке.
Отметим, что независимо от выбранного способа, должны быть сделаны механизмы, реализующий еще одну функцию демо: обратная связь по ценности результата должна быть не только получена, но и донесена до всей команды. И не только отрицательная, но и положительная. Об этом часто забывают, успех очередной фичи маркетинг празднует у себя, а на команду транслирует только проблемы. Важно, чтобы команда тоже ощущала успех. То же касается и механизмов, описанных ранее, например, когда выделенные сотрудники из команды обучают новому функционалу пользователей заказчика – обратную связь надо донести до команды. В том числе положительную эмоциональную обратную связь, чтобы люди ощутили ценность сделанного, а не просто приняли это к сведению. Бывают очень тяжелые ситуации, когда реальная обратная связь может запаздывать на месяц-другой из-за реально длительного процесса, включающего, например, производство конечного продукта на основе того проекта, который разрабатывает Scrum-команда. В этом случае все равно надо заботиться о механизмах обратной связи, хотя готовых рецептов у меня тут нет…
Другие задачи демо.
Помимо описанной выше задачи получения обратной связи от стейкхолдеров о ценности созданного продукта, Демо решает еще пару вопросов.
Во-первых, на демо идет оценка достижения целей спринта со стороны стейкхолдеров. И связанное с этим позиционирование достигнутого результата как часть более крупных циклов планирования или целеполагания: вклад спринта в разработку релиза, в продвижение к квартальным или годовым целям. Подробнее о цикле релизного планирования я буду говорить в следующей статье, рассказывая полную схему Scrum. А вот работа с квартальными и годовыми целями находится за пределами обеспечиваемого
