Глава 5. Планирование и коллективные обязательства в Scrum
Каждый разработчик должен чувствовать себя комфортно, отвечая за работу, под которой он подписался. А поскольку команда исповедует принцип «это наше общее дело», комфортно должен чувствовать себя каждый ее участник.
Майк Кон
Вы изучили механизмы Scrum и то, как использовать базовые шаблоны Scrum для совместной работы вашей команды. Но есть существенная разница между теорией Scrum и командной разработкой программного обеспечения в ходе реального проекта. Как вы настраиваете свою scrum-команду на то, чтобы добиться успеха? Как вы убеждаете ее членов стремиться к одинаковым целям? Иными словами, теперь, когда вы понимаете, что Scrum – это самоорганизация и коллективные обязательства, как вы управляете своей командой, чтобы обеспечить все это в реальной жизни?
В этой главе вы узнаете о практиках, которые используют многие scrum-команды для планирования своих спринтов. Вы увидите, как пользовательские истории помогут понять, что именно требуется пользователям от программы, и будете использовать очки историй и показатель скорости команды, чтобы определить объем работ, который команда способна сделать в каждом спринте. Кроме того, вы узнаете, как использовать два полезных инструмента визуализации – график сгорания и доску задач, чтобы все члены команды находились на одном и том же этапе.
Также вы поймете, почему этих практик и основной схемы scrum-проекта недостаточно, чтобы достичь «гиперпроизводительности» или «удивительных результатов». Мы вернемся к ценностям Scrum, и вы узнаете, как определить, соответствуют ли ваша команда и корпоративная культура этим ценностям. И что делать, если не соответствуют.
Рис. 5.1. Владельцам продукта часто чрезвычайно сложно угадывать мысли пользователей
Описание: команда, работающая над приложением для мобильного телефона в небольшой компании
Роджер – лидер команды, пытающийся применять Agile
Ави – владелец продукта
Эрик – scrum-мастер в другой команде