как пользователи будут их достигать, работая используя разработанный софт, должна быть достаточна. Однако, что делать, если проблема в вашем проекте существует? Правильный способ решения этих проблем – придумать альтернативные механизмы получения релевантной обратной связи и встроить в процесс именно их, чтобы обеспечить выполнение основной функции демо. Например, в цикл выполнения задачи может быть включено не только тестирование, но выкатка на боевые сервера и A/B тестирование на пользователях. Или установка его на тестовые сервера заказчика с приближенными к боевым данными, и проведение обучения и демонстрации конечным пользователям. Таким образом, есть различные варианты. Но на практике вместо разработки механизмов часто просто назначают формального ответственного «ты будешь смотреть и оценишь результат». И в результате команда идет по неверному пути, а выясняется это только на внедрении функционала. Я слышал истории, когда эти проблемы возникали даже когда таким ответственным стейкхолдером был руководитель проекта от заказчика: он был на демо, был очень доволен, команда была вдохновленной. А потом оказалось, что он не слишком давно работает у заказчика, и его представления о процессе были основаны на опыте работы в другом месте. Поэтому, когда функционал принесли конечным пользователям, то выяснили его слабую пригодность для реального процесса. Заметим, что техническая выкатка изменений на боевые сервера не спасает, так как пользователи, не зная о новых функциях им просто не пользуются. А вот изменение работы пользователей в любом случае надо отдельно организовывать.
Отмечу, что примерно те же проблемы возникают и при применении Scrum для не IT-проектов: новые продукты или новые материалы недостаточно просто сделать и предъявить, могут быть необходимы испытания, тестирование на пользователях или у заказчиков. Типичный пример – маркетинг, конечным результатом маркетинговой компании тут являются привлеченные пользователи или покупатели, а вовсе не публикация рекламы, и именно по ним можно определить ценность.
Что делать с долгой обратной связью?
Как было отмечено выше, в ряде случаев получение релевантной обратной связи подразумевает долгий по времени процесс. И далеко не всегда это может решено внутри спринта по объективным причинам. Если такие задачи встречаются изредка, то можно получение обратной связи выделять в отдельный поток, при этом может быть допустим перенос их в следующий спринт. Если же такие задачи составляют большинство, то надо придумывать другие механизмы.
Один из них – splitting sprint, при котором команда живет в двух спринтах, сдвинутых относительно друг друга, например, на неделю, в первом происходит разработка и тестирование вплоть до выкатке на боевые сервера, которое носит предсказуемый характер, а во втором —тестирование на реальных пользователях и экспресс-доработки по его результатам. Планирование учитывает оба