5.6.4. Выполнение спринта
В ходе спринта команда выполняет задачи, необходимые для реализации описаний функциональности пользователей из списка невыполненных работ спринта.До завершения каждого спринта команда может отслеживать ход его выполнения и проверять соответствие готового программного обеспечения условиям приемки заказчиков и критериям, установленным в команде.
Завершение описаний функциональности пользователей
Завершив планирование спринта, команда формирует список описаний функциональности пользователей, которые она обязуется реализовать в течение спринта.Эти описания функциональности разбиваются на задачи.В момент начала спринта каждый участник команды выбирает себе одну из задач.После завершения этой задачи участник команды обновляет ее состояние и выбирает следующую задачу.Таким образом команда обрабатывает все задачи, необходимые для реализации описаний функциональности пользователей из списка невыполненных работ спринта.Член группы может указать выполненные задачи при возврате кода.Дополнительные сведения см. в разделе Сопоставление рабочих элементов с наборами изменений.
Дополнительные сведения о назначении задач и обновлении их состояния см. в разделе Задача (гибкая разработка).
Методология Scrum в первую очередь основана на взаимодействии людей, а не на формальных процессах. Благодаря этому достигается ясное понимание всех зависимостей и обеспечивается обмен полученными знаниями и опытом и эффективное внедрение изменений планов.Команда должна ежедневно проводить короткое Scrum-собрание, на котором каждый участник команды сообщает о работе, выполненной за предыдущий день и запланированной на текущий день. Кроме того, он докладывает обо всех проблемах или препятствиях, которые могут отрицательно сказаться на ходе работы или требуют помощи со стороны других участников команды.Дополнительные сведения см. в разделе Ежедневное Scrum-собрание.
В своей книге "Extreme Programming Explained" Кент Бек (Kent Beck) рассказывает о том, почему гораздо эффективнее исправлять ошибки на ранних этапах работы.Учитывая этот факт, команда должна понимать приоритеты заказчика.Возможно, заказчик больше ценит качество продукта, чем поддержку большего количества функций.Владелец продукта обязан знать такого рода информацию, поскольку заказчики контролируют рабочий процесс команды.
Программное обеспечение, создаваемое командой Scrum, не должно содержать ошибок.Однако команды, скорее всего, будут находить ошибки в своих проектах.Обрабатывая ошибки, команда должна понимать, что быстрее и дешевле сразу исправлять найденные ошибки, чем откладывать их исправление на более поздние сроки.При обнаружении ошибок команде следует исправлять их немедленно.Если команда не может устранить ошибку в тот же день, когда она была найдена, участник команды должен создать рабочий элемент ошибки в Visual Studio ALM и исправить ее до окончания спринта.
Дополнительные сведения см. в разделе Ошибка (гибкая разработка).
Отслеживание хода выполнения спринта
Команда может отслеживать ход выполнения спринта для проверки того, что работа выполняется должным образом и соответствует условиям приемки.Для отслеживания хода выполнения работ в течение спринта команды чаще всего используют отчет "Выработка".Платформа MSF для гибкой разработки программного обеспечения версии 5.0 предоставляет набор отчетов, которые могут использоваться командами для отслеживания хода выполнения спринта.
Отчет "Выработка и темп работ" (гибкая разработка)
Отчет "Индикаторы качества построения"
Отчет "Ход выполнения плана тестирования"
Отчет "Ход выполнения описаний функциональности" (гибкая разработка)
Команды часто обнаруживают, что для выполнения задачи им требуется больше или меньше времени, чем они оценивали во время собрания по планированию выпуска.Этот тип отклонения является типичным.Можно записать эти сведения, указав фактическое время, затраченное командой на выполнение задачи.
В ходе выполнения спринта команда может обнаружить незапланированную работу, необходимую для реализации описания функциональности пользователя.В этом случае команда должна создать задачу, оценить ее и определить, может ли она выполнить эту задачу за время, оставшееся в спринте.Если задачу можно выполнить, команде следует продолжить спринт.Если завершить задачу в рамках спринта невозможно, необходимо обсудить дальнейшее продолжение работы с владельцем продукта.Владелец продукта и команда могут разрешить проблему, внеся следующие изменения.
Снижение условий приемки для пользовательского описания функциональности, что сделает данную задачу необязательной.
Удаление пользовательского описания функциональности из списка невыполненных работ спринта.
Отмена спринта.
Завершение спринта
По мере приближения завершения спринта необходимо убедиться в том, что все описания функциональности пользователей или требования полностью выполняются командой.Например, необходимо проверить, что приемочные тесты проходят успешно, и каждое описание функциональности пользователей отвечает установленным командой критериям.Дополнительные сведения о том, что понимается под полным выполнением, см. на следующей веб-странице: Mitch Lacey & Associates, Inc.
Отчет "Состояние ошибки"
Отчет "Тенденции ошибок"
В последний день спринта команда продемонстрирует реализованные описания функциональности пользователей владельцу продукта и, возможно, заказчикам.Владелец продукта и заказчики принимают решение о приемке по каждому описанию функциональности пользователя.Дополнительные сведения см. в разделе Краткое собрание по проверке результатов.
После проверки заказчиков команда проведет ретроспективное собрание.Дополнительные сведения см. в разделе Ретроспективное собрание.