Когда спринт стартует, элементы его бэклога могут восприниматься командой как обязательства, потому что они обсуждались в ходе планирования спринта и представлены на доске задач. Но это не обязательства, а варианты. Вы знаете это, так как владелец продукта может удалить их из спринта. И если команда узнает ближе к концу спринта, что они не будут выполнены в срок, то она вытолкнет их в следующий спринт. В этом одна из причин хорошей работы Scrum: мы отделяем истинное обязательство (поставку ценного работающего программного обеспечения в конце спринта) от опциональных вариантов (предоставления конкретного функционала к определенной дате).

Заставить людей думать о вариантах вместо обязательств сложно, потому что не всегда легко понять, что означает обязательство. Никто не любит неожиданно брать на себя обязательства. Большинство из нас бывали на таких собраниях, где руководитель требует от члена команды назвать дату и тот нервно ерзает в кресле и пытается уйти от ответа. Так бывает, когда руководство считает, что проект «погорел» по вине команды, не выполнившей взятое на себя обязательство. Нервная реакция заставляет его заняться микроменеджментом, требуя от всех членов команды по отдельности принятия обязательств в отношении множества краткосрочных задач. В такой обстановке разработчики не спешат брать на себя ответственность.

Как проекты доходят до точки, в которой боссы и менеджеры проекта теряют доверие к команде, неоднократно проваливавшей свои обязательства? Это происходит потому, что, хотя отдельные люди и могут уклоняться от ответственности (особенно под прессингом руководства), команды имеют склонность к ее чрезмерной фиксации. Иногда это связано с желанием погеройствовать – программист обещает больше, чем может сделать. А порой потому, что ответственность вознаграждается: это характерно для тех, кто привык обещать, а потом как ни в чем не бывало извиняться за непредвиденные обстоятельства, помешавшие проекту. («Мы никак не могли это предугадать!») В компаниях, где привыкли обвинять и спасать свою шкуру (CYA), подход «пообещать и извиниться», конечно, не обеспечивает эффективные поставки программного обеспечения, но зато дает возможность получать высокую зарплату и сохранять свою должность.

Повторим основную мысль: руководители склонны требовать принятия обязательств, а команды часто их завышают.

Инкрементальная архитектура, разработка на основе установок и другие способы дать команде возможность выбрать из нескольких вариантов