заниматься тестированием, если тестировщики вдруг не успевают. Особую остроту это приобретает, если используются WIP- лимиты. Могут быть и другие правила.
Срочные задачи
Как правило, sprint backlog фиксируется при планировании. Однако, в конкретных командах может быть необходимо уметь включать в спринт дополнительные задачи, например, если команда не только создает новый функционал, но и устраняет ошибки в старом, или обрабатывает какие-то срочные обращения клиентов или поручения руководства. Если срочные задачи появляются регулярно, то на такие задачи обычно выделяется резерв мощности команды при планировании спринта. Сгорание этого резерва можно отдельно рисовать на Burndown Chart снизу-вверх. Управления срочными задачами также желательно вести через доску, а не прямыми поручениями. Задача может быть просто повешена на доску, если ее содержание ясно. Если требуются дополнительные пояснения, то хорошая практика – подождать до очередного Daily Scrum для информации всей команде.
Если задача имеет большой объем, то с Product Owner обсуждают не только ее содержание, но и изъятие соответствующего объема запланированных задач из числа тех, которые еще не начали выполнение. При этом важно, чтобы эти изменения не нарушили достижения целей спринта. Если изменения столь велики, что цель спринта не достигается, то имеет смысл текущий спринт прервать, и начать новый спринт, восстановив осмысленность движения.
Нет прерываниям!
Начатое выполнение задачи не прерывается. Предполагается, что они достаточно малы, чтобы любые срочные задачи могли подождать, пока кто-нибудь завершит свою и увидит на доске новую. Понятно, что это – идеальная картина. Реально коммуникации не запрещены, в каких-либо срочных случаях сотрудника можно и нужно отвлечь, в том числе если при выполнении очередного этапа обнаружились проблемы в ранее сделанном – тот, кто делал может быть призван на помощь. Однако, запрету отвлекать есть важная причина, характерная для любых задач умственного труда: их выполнение требует погружения и сосредоточения, и нарушение этого представляет собой существенные накладные расходы. По опыту, задача на 2—3 часа требует около получаса погружения, поэтому если исполнителя пару раз отвлекли, то время выполнения возросло в полтора раза. Эти цифры – из моего опыта, но я слышал аналогичные цифры в разных докладах на конференциях, а быстрый поиск выдал, например, эту статью, в которой приведена близкая цифра со ссылкой на исследования.
Если члены команды видят реальные потери производительности из-за частых отвлечений, это следует обсудить на ретроспективе и договориться о правилах работы. Отметим, кстати, этот прием: если кто-то увидел проблему, он начинает немедленно возмущаться и пытаться решить, а фиксирует возникшее напряжение. А потом высказывает его на соответствующей встрече, в данном случае это ретроспектива, а в случае острой проблемы –