Что такое доска задач спринта

---

Что такое доска задач спринта?

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

В начале спринта владелец продукта, заинтересованные стороны и команда разработки встречаются вместе, чтобы определить приоритеты и выбрать пользовательские истории, которые необходимо выполнить в рамках спринта. Поскольку разные стороны имеют разные предпочтения, соображения и опасения относительно проекта и графика проекта, цель встречи — предоставить участникам возможность выслушать и понять мнения других и прийти к согласию по набору пользовательских историй, который будет принят всеми сторонами.

Продолжительность спринта

Быстрая доставка качественной работы — одна из причин, по которой команды разработки программного обеспечения хотят внедрить гибкие методологии разработки. Поэтому, хотя нет универсального решения для продолжительности спринта, общепринято, что она должна быть как можно короче. Но насколько короткой она должна быть?

Хотя длинный спринт не является предпочтительным, чрезмерно короткая продолжительность спринта может снизить мотивацию команды разработки к выполнению значительной работы или даже привести к низкому качеству результатов.

Таким образом, выбор продолжительности спринта — результат обсуждения всей команды — владельца продукта, мастера Scrum и членов команды, таких как дизайнеры баз данных, программисты, дизайнеры пользовательского интерфейса, тестировщики, аналитики и т.д. Но в конечном итоге кто-то должен принять решение. В этот момент мастер Scrum, как правило, и даёт ответ.

Традиционно спринт длится от трёх недель до одного месяца, но сегодня всё больше команд добиваются успеха с двухнедельными спринтами. В конечном счёте, нет жёсткого правила выбора продолжительности спринта. Хороший мастер Scrum обладает навыками сотрудничества и посредничества при определении продолжительности спринта, чтобы обеспечить выполнение работ в соответствии с ожиданиями. Вот некоторые факторы, которые может учитывать мастер Scrum:

1. Согласованный график проекта
2. Доступность клиентов/заинтересованных сторон/владельца продукта (кто может разъяснить потенциальные сомнения)
3. Рабочая культура клиентов
4. Компетентность команды Scrum
5. Опыт работы в Scrum

Как только команда достигнет согласия, все последующие спринты будут иметь одинаковую продолжительность без частой смены спринт за спринтом. Однако хорошей практикой является постоянный анализ эффективности спринта и поиск оптимальной продолжительности, которая будет наилучшим образом соответствовать всем участникам.

Подтверждение работ (пользовательских историй) в спринте

Разработка начинается вокруг пользовательских историй после начала спринта, и с каждым шагом спринта реализуется всё больше пользовательских историй. Однако полная реализация пользовательской истории — это ещё не конец. Существует ещё один важный этап — подтверждение.

Подтверждение пользовательской истории означает проверку реализованной функции и определение, соответствует ли она ожиданиям. Оценка должна основываться исключительно на критериях, установленных при детализации пользовательских историй, записанных в виде пунктов подтверждения. В процессе подтверждения владельцу продукта предоставляется тестовая среда или устройство для проверки реализованной работы. Владелец продукта последовательно проверяет каждый пункт подтверждения, указанный в пользовательской истории. Если все пункты подтверждены как выполненные, пользовательская история считается подтверждённой. Если какой-либо пункт не выполнен или не работает, как ожидается, владелец продукта запросит у команды разработки исправление. Процесс исправления и подтверждения будет повторяться до тех пор, пока пользовательская история не будет полностью подтверждена.

Когда нужно подтверждать?

Спринт, а на самом деле и гибкая разработка — это непрерывный процесс доставки. Вместо подтверждения пользовательских историй в конце спринта, подтверждение следует проводить сразу после завершения любой пользовательской истории. Однако, если владелец продукта не может участвовать в непрерывном подтверждении, можно организовать еженедельные встречи продолжительностью от 1 до 2 часов. В ходе встречи владелец продукта будет работать с командой над подтверждением завершённых пользовательских историй. Встреча также включает сессию обсуждения, которая помогает разъяснить сомнения, возникшие при реализации других историй, входящих в спринт.

Подтверждение не эквивалентно тестированию

Как уже говорилось, цель подтверждения — убедиться, что пользовательская история реализована правильно. Оценка основывается исключительно на пунктах, установленных как пункты подтверждения при детализации пользовательской истории, ни больше, ни меньше. Масштаб проверки недостаточен для гарантии готовности функции к использованию в производстве. Так когда следует проводить «настоящее тестирование»?

Разные команды имеют разные подходы к тестированию программного обеспечения. Некоторые команды предпочитают тестирование в рамках спринта, включающее проведение тестов, таких как интеграционное тестирование и тестирование на регрессию, к концу спринта. Другие команды предпочитают организовать стабилизационный спринт, как следует из названия, для тестирования и устранения ошибок. В этом спринте не будет новых разработок.

Независимо от выбранного подхода, помните, что выбор — это не выбор одного человека, а выбор всех.

Visual Paradigm предоставляет все инструменты, которые вам нужны в гибкой разработке программного обеспечения, включая инструмент диаграмм вариантов использования UML, (агильный) пользовательская история, спринт, сценарий и провалы для проектирования пользовательского опыта, инструмент управления задачами, и т.д.