удовлетворит основные потребности – правило Парето говорит, что чаще всего это возможно. Это – конструктивное обсуждение.
А вот переход в этом случае к различным способам давления чаще всего не имеет смысла. Потому что наиболее распространенный результат – команда соглашается, а потом просто не делает. И в результате вместо четкого представления о том, что какой-либо функционал не будет получен через две недели, стейкхолдеров обнаруживают это постфактум, две недели спустя, когда они рассчитывали его получить. Не обязательно тот, по поводу которого было давление – может оказаться, что его сделали, но не сделали что-то другое. А если не сделали именно его – то на него при этом уже затрачены определенные ресурсы, и далее надо доделывать или выбросить. Конечно, может оказаться, что сознательная команды сделает этот функционал за счет личного времени. Но, как показывает практика, на это может сработать один-два раза, а вот на регулярной основе это приводит к негативным последствиям: либо команда выгорает и производительность падает, а сотрудники уходят, либо команда начинает систематически завышать оценки, чтобы было, куда отступать при давлении. В любом случае, прозрачность процесса и сотрудничество в достижении цели – разрушается, что разрушает эффект использования Agile-подходов.
Планирование – контракт на спринт.
Вообще надо отметить, что планирование представляет собой заключение контракта на спринт между командой и стейкхолдерами, при этом интересы стейкхолдеров представляет Product Owner. Этот контракт может иметь разную жесткость. В свое время была популярной идея о том, что «настоящая команда» на планировании всегда дает обещание, commitment, которое потом выполняет почти любой ценой. Такой взгляд очень нравится стейкхолдерам и, на первый взгляд, отвечает их интересам. Однако, практика показывает, что это неверно. В долгую это ведет к выгоранию команды либо к сознательному завышению оценок, в котором еще и не сознаются, тратя выигранное время по своему усмотрению и превращая работу в agile- курорт. И этому есть системная причина – длинный хвост распределения в оценках IT-работы, о чем есть хороший доклад Андрея Бибичева «Пуассоново горение сроков».
Поэтому правильный подход – учитывать такую статистику на планировании и ранжировать задачи по желательности их исполнения. Для этого можно применять шкалу MoSCoW (Must – Should – Could – Would) или ее сокращенный вариант, и не ставить максимальное значение достаточному количеству задач. Кроме того, учитывая статистику, необходимо не заполнять весь бэклог крупными задачами, в нем должен быть достаточный буфер мелких задач. Конечно, планирование спринта обычно не является заключением какого-то принципиально нового контракта, речь обычно идет лишь о целях и объеме работ на спринт. Однако, в общем случае, стейкхолдерами проекта после любого спринта может быть принято решение о прекращении
