Завершение описаний функциональности пользователей

Завершив планирование спринта, команда формирует список описаний функциональности пользователей, которые она обязуется реализовать в течение спринта.Эти описания функциональности разбиваются на задачи.В момент начала спринта каждый участник команды выбирает себе одну из задач.После завершения этой задачи участник команды обновляет ее состояние и выбирает следующую задачу.Таким образом команда обрабатывает все задачи, необходимые для реализации описаний функциональности пользователей из списка невыполненных работ спринта.Член группы может указать выполненные задачи при возврате кода.Дополнительные сведения см. в разделе Сопоставление рабочих элементов с наборами изменений.

Дополнительные сведения о назначении задач и обновлении их состояния см. в разделе Задача (гибкая разработка).

Методология Scrum в первую очередь основана на взаимодействии людей, а не на формальных процессах. Благодаря этому достигается ясное понимание всех зависимостей и обеспечивается обмен полученными знаниями и опытом и эффективное внедрение изменений планов.Команда должна ежедневно проводить короткое Scrum-собрание, на котором каждый участник команды сообщает о работе, выполненной за предыдущий день и запланированной на текущий день. Кроме того, он докладывает обо всех проблемах или препятствиях, которые могут отрицательно сказаться на ходе работы или требуют помощи со стороны других участников команды.Дополнительные сведения см. в разделе Ежедневное Scrum-собрание.

В своей книге "Extreme Programming Explained" Кент Бек (Kent Beck) рассказывает о том, почему гораздо эффективнее исправлять ошибки на ранних этапах работы.Учитывая этот факт, команда должна понимать приоритеты заказчика.Возможно, заказчик больше ценит качество продукта, чем поддержку большего количества функций.Владелец продукта обязан знать такого рода информацию, поскольку заказчики контролируют рабочий процесс команды.

Программное обеспечение, создаваемое командой Scrum, не должно содержать ошибок.Однако команды, скорее всего, будут находить ошибки в своих проектах.Обрабатывая ошибки, команда должна понимать, что быстрее и дешевле сразу исправлять найденные ошибки, чем откладывать их исправление на более поздние сроки.При обнаружении ошибок команде следует исправлять их немедленно.Если команда не может устранить ошибку в тот же день, когда она была найдена, участник команды должен создать рабочий элемент ошибки в Visual Studio ALM и исправить ее до окончания спринта.

Дополнительные сведения см. в разделе Ошибка (гибкая разработка).