Процесс Scrum: от элементов бэклога продукта к готовому приращению продукта

Целью повседневной работы спринта является создание готового к поставке инкремента продукта в форме, которая может быть доставлена ​​клиенту или пользователю.

В контексте одного спринта приращение продукта или отправляемое приращение означает, что рабочий продукт был разработан, интегрирован, протестирован и задокументирован в соответствии с определением готовности проекта и считается готовым к выпуску.

Команда разработчиков может или не может выпустить этот продукт в конце спринта — время выпуска зависит от плана выпуска. Проекту может потребоваться несколько спринтов, прежде чем продукт будет содержать набор минимального рыночного продукта (MMP), необходимого для обоснования выпуска на рынок.

Чтобы создать поставляемую функциональность, команда разработчиков и владелец продукта участвуют в трех основных действиях:

разработка

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

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

Разработка

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

• Объединяйте членов команды разработчиков для выполнения задач. Это повышает качество работы и способствует обмену опытом.
• Следуйте согласованным стандартам дизайна команды разработчиков. Если вы не можете следовать им по какой-либо причине, пересмотрите эти стандарты и улучшите их.
• Начните разработку с настройки автоматических тестов. Вы можете узнать больше об автоматизированном тестировании в следующем разделе и в главе 15. Если во время разработки появятся новые, полезные функции, добавьте их в бэклог продукта. Избегайте кодирования новых функций, которые не входят в цель спринта.
• Интегрируйте изменения, которые были закодированы в течение дня, по одному набору за раз. Тест на 100-процентную правильность. Интегрируйте изменения не реже одного раза в день; некоторые команды объединяются много раз в день. Проведите проверку кода, чтобы убедиться, что код соответствует стандартам разработки. Определите области, которые нуждаются в пересмотре. Добавьте ревизии как задачи в журнал спринта.
• Создавайте техническую документацию во время работы. Не ждите окончания спринта или, что еще хуже, окончания спринта перед релизом.

Проверка

Проверка работы, выполненной в спринте, состоит из трех частей: автоматизированное тестирование, экспертная оценка и проверка владельца продукта. Команда может проводить:

Автоматизированное тестирование

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

• Автоматизированное тестирование может включать следующее: Модульное тестирование: тестирование исходного кода в его мельчайших частях — на уровне компонентов.
• Системное тестирование: тестирование кода с остальной частью системы.
• Статическое тестирование: проверка соответствия кода продукта стандартам на основе правил и лучших практик, согласованных командой разработчиков.

Экспертная оценка

Экспертная проверка просто означает, что члены команды разработчиков проверяют код друг друга.

Отзыв владельца продукта

Когда пользовательская история разработана и протестирована, команда разработчиков перемещает ее в столбец «Принять» на доске задач. Затем владелец продукта просматривает функциональность и проверяет, соответствует ли она целям пользовательской истории в соответствии с критериями приемлемости пользовательской истории. Владелец продукта ежедневно проверяет пользовательские истории.

Резюме

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

Другие статьи о Scrum

• Что такое шаблон Роль-Функция-Причина?
• Инкремент спринта против потенциально готового к поставке продукта против MVP против MMP
• Напишите SMART цели и ИНВЕСТИРУЙТЕ для пользовательских историй
• Agile-манифест и двенадцать принципов
• 10 наиболее часто упоминаемых основных правил Scrum
• Что такое Скрам-события?
• Что такое Скрам-церемонии?
• Что такое уход за бэклогом продукта?
• Что такое спринт в Scrum?
• Сердце Scrum — The Daily Standup