Собрание по планированию спринта
Ваша команда создает список невыполненных работ по спринту на планировочном собрании в первый день спринта. На этом собрании владелец продукта работает совместно с вашей командой, чтобы определить, какие описания функциональности пользователей будут выполнены в спринте. Планировочное собрание состоит из двух частей продолжительностью ровно половина собрания каждая. В первой части собрания команда владелец продукта составляют пользовательские описания функциональности, которые, по мнению команды, могут быть реализованы в течение данного спринта (на основе опыта предыдущих спринтов). После определения описаний функциональности пользователей для их назначения спринту можно использовать книгу "Планирование продукта". Дополнительные сведения см. в разделе Книга "Планирование продукта".
Во второй части собрания команда решает, как будет вестись разработка и тестирование пользовательских описаний функциональности. После этого команда разбивает пользовательские описания функциональности на задачи и оценивает объем работ для реализации каждого из них. Наконец, ваша команда подтверждает реализацию некоторых или всех описаний функциональности пользователей (user stories) на основе этих оценок.
В первой части собрания владелец продукта встречается с вашей командой для обсуждения описаний функциональности, которые могут быть включены в спринт. Владелец продукта поделится информацией и ответит на вопросы, которые ваша команда задаст об этих описаниях функциональности. В этой беседе можно обсудить источники данных, макет интерфейса пользователя, ожидаемое время ответа, а также вопросы безопасности и удобства использования. Ваша команда должна добавить эти сведения к описаниям функциональности пользователей (user stories). Во время этой части собрания ваша команда знакомится с тем, что она должна создать.
После того как ваша команда полностью обсудила все необходимые описания функциональности пользователей (user stories), координатор начинает вторую часть планировочного собрания. На этой части собрания должен присутствовать владелец продукта, чтобы помочь прояснить требования и помочь понять альтернативы и выбрать оптимальную. Координатор ведет обсуждение по мере того, как ваша команда определяет, каким образом будут реализованы описания функциональности пользователей (user stories) и возможна ли реализация всех описаний, которые требуются владельцу продукта. Чтобы лучше понимать, что используется при выполнении каждого описания функциональности, ваша команда разбивает каждое описание на задачи, которые необходимо выполнить для реализации этого описания и проверки его завершения. Можно найти следующие примеры задач в списке невыполненной работы по спринту: "Обновление хранимой процедуры для использования нового канала данных" и "Создание класса для веб-службы сборщика".
Ваша команда может использовать книгу "Невыполненная работа по итерации", чтобы разбить описания функциональности на задачи. Дополнительные сведения см. в разделе Книга "Отставание итераций".
Затем команда оценивает количество рабочих часов, необходимых для каждой задачи. Поскольку задачи назначаются после их оценки, команда работает вместе над созданием этих оценок. (Зачастую команды не могут определить и оценить всю работу, которую предстоит выполнить, во время планировочного собрания спринта. Около 40 % работы, выполняемой командой в течение спринта, не учитывается и не оговаривается на планировочном собрании).
Хорошим инструментом для оценки часов по задаче является метод покера (покер-планирование). При использовании покер-планирования каждый участник команды может участвовать в процессе оценки, а не зависеть от оценки задач экспертами в соответствующей области. При использовании этого метода или другого необходимо задействовать всю команду, чтобы определить количество часов, требуемых для каждой задачи. Дополнительные сведения см. на следующем веб-ресурсе: Planning Poker.
Выполнение задачи не должно занимать больше одного дня. Если задача слишком большая, необходимо разбить ее на части. В некоторых случаях не удается точно оценить одни задачи до тех пор, пока не завершено выполнение других. Поэтому необходимо создать задачу сейчас, но оценивать объем работ по ее решению, когда появится достаточно информации. Оценки по отдельным задачам суммируются для определения количества часов, которые потребуются для выполнения каждого описания функциональности пользователей (user story).
Ваша команда продолжает анализ каждого описания функциональности пользователей (user stories) и оценку его задач, пока команда не определит, что для спринта имеется необходимое количество описаний функциональности. Ваша команда осуществляет это определение, сравнивая количество оцененных часов с количеством предполагаемых часов, за которые команда выполнит спринт.
Можно использовать лист производительности команды в книге "Невыполненная работа по итерации" для определения производительности команды по спринту. Необходимо внести сведения о спринте в листе настроек. Для учета отпусков, праздников и других перерывов необходимо заполнить лист перерывов. Дополнительные сведения см. в разделе Книга "Отставание итераций".
Необходимо предупредить владельца продукта, если ваша команда определяет, что она не может выполнить одно или несколько описаний функциональности, которые требуются владельцу продукта, поскольку его оценка задачи превышает количество допустимых часов. Владелец продукта может изменить описание функциональности пользователей (user story) для уменьшения объема работ или внести ее в список невыполненной работы по продукту для следующего спринта. По завершении обеих частей планировочного собрания команда должна получить следующие результаты.
созданный список невыполненной работы с задачами и часами для каждого описания функциональности пользователей (user story);
подтвержденные описания функциональности пользователей, которые команда реализует и поставит в спринте;
понимание того, как самостоятельная команда будет работать сообща над выполнением взятых на себя обязательств.
См. также
Основные понятия
Планирование и отслеживание проектов
Другие ресурсы
MSF для гибкой разработки программного обеспечения версии 5.0