В проекте Scrum следует ли тестировать и проводить рецензирование в каждом спринте как отдельные задачи?

Ответ 1

В проекте Scrum все, что нужно сделать, должно быть введено как задача.

Одним из ключевых моментов Scrum является возможность точно предсказать, что команда может сделать в спринте. Чтобы сделать это, вы должны учитывать все, что будет потреблять время разработчика.

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

Изменить: Основываясь на записи Mendelt, я немного проясню ситуацию.

От Wikipedia:

Задержка продукта. Заготовка продукта - это документ высокого уровня для всего проекта. Он содержит подробные описания всех необходимых функций, элементов списка пожеланий и т.д. Это будет "Что", которое будет создано. Он открыт и редактируется кем угодно. Он содержит приблизительные оценки, обычно в днях. Эта оценка помогает Владельцу продукта оценить временную шкалу и в ограниченной степени приоритет (например, если функция "добавить проверку орфографии" оценивается в 3 дня по 3 месяца, что может повлиять на желание владельца продукта).

Sprint Backlog: Задержка спринта - это очень подробный документ, содержащий информацию о том, как команда собирается выполнить требования к предстоящему спринту. Задачи разбиваются на часы без задания более 16 часов. Если задача больше 16 часов, ее следует разбить дальше. Задачи в отстающем отставании никогда не назначаются, скорее задачи регистрируются членами команды по своему усмотрению.

Элементы в Backlog продукта не будут показывать такие вещи, как документация или тестирование, но задачи в Sprint Backlog, безусловно, должны быть.

Я приведу пример. Скажем, есть функция "А" в продукте, а его расчетное время составляет 1 неделю. В Sprint Backlog, который может быть разбит на следующие задачи:

Initial design document:              4 hours  
Development of subset 1 of Feature A: 8 hours  
Peer review of subset 1 of Feature A: 2 hours  
Testing of subset 1 of Feature A:     6 hours  
Development of subset 2 of Feature A: 8 hours  
Peer review of subset 2 of Feature A: 2 hours  
Testing of subset 2 of Feature A:     6 hours  
User Documentation for Feature A:     4 hours
---------------------------------------------
Total time                           40 hours

Редактировать # 2: Идея, лежащая в основе Sprint Backlog, заключается в том, чтобы точно указать, где именно вы должны тратить свое время. Вот почему задачи не могут быть более 16 часов, и именно так вы достигаете точки, в которой вы можете быть очень надежным в своих прогнозах расписания.

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

Ответ 2

Подумайте о вертикалях, а не о горизонтальных слоях.

Если вы рассматриваете дизайн, программирование и модульное тестирование, тестирование и т.д. как слои в разработке торта, я думаю, вы могли бы увидеть функции (рассказы), которые вы передаете как фрагменты торта, каждый из которых состоит из небольшого фрагмента дизайна, кода, тестирования, производительности и т.д. Это как-то вроде Pragmatic Programmer "отслеживание пуль".

Ответ 3

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

Общим инструментом для команд Scrum является определение приемочных тестов для элементов отставания продукта (часто эти элементы отставания поступают в форме пользовательских историй).

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

Эти методы могут быть такими, как модульное тестирование, парное программирование, экспертная оценка и т.д. Часто это становится частью определения команды того, что это значит для чего-то. Если команда борется с оценками или делает это, то может быть полезно назвать их задачами в отставании от спринта. Моя рекомендация состоит в том, чтобы облегчить процесс - вам не нужно вызывать каждую мелочь (но вам нужно учитывать время, которое потребуется, чтобы делать обычные предметы в оценках).

Ответ 4

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

Ответ 5

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