Рабочие элементы Sprint - Agile Scrum

Ответ 1

Какие задачи могут быть включены и отслеживаться в качестве рабочих элементов в журнале Sprint Backlog?

В соответствии с руководством Scrum Guide → В части 2 встречи планирования команда определяет задачи. Эти задачи - это подробные части работы, необходимые для преобразования Backlog продукта в рабочее программное обеспечение. Задачи должны быть разложены, чтобы их можно было выполнить менее чем за один день. Этот список задач называется Sprint Backlog. Так что любая задача, которая соответствует вышеуказанному руководству, должна быть включена.

Можно ли включить анализ, проверку и модульное тестирование (истории пользователей) или включить или отключить только основные задачи кодирования в резервном хранилище Sprint?

Да, они могут и должны быть включены, если их выполнение приводит к преобразованию Backlog в рабочее программное обеспечение. Scrum NEVER предлагает включить только задачи кодирования в Sprint Backlog. На самом деле Scrum просит команду быть перекрестной функциональной.

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

Это звучит подозрительно для меня. Это просто "ты", который ломает задачи? Во второй части совещания по планированию должна быть разбита задача всей команды. Опять же задачи не кодирования могут быть включены в Sprint. Чтобы дать вам реалистичный пример: в моей команде веб-разработки типичный Backlog выполнял следующие задачи. 1. Определить и открыть 2. Разработка и создание тестовой матрицы 3. Записывать тесты устройств в тестовую матрицу 3. Код для прохождения теста 4. Тест 5. Регрессионный тест 6. Отладка 7. Перейдите "Рабочее программное обеспечение с ПО (если требуется, чтобы убедиться, что это то, что хочет ПО)

ИЗМЕНИТЬ

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

Надеюсь, это поможет!

Ответ 2

У вас есть эти задачи, которые вы хотите отслеживать как рабочие элементы. Будьте осторожны с этим.

Почему? Вы начинаете конкретизировать процесс. Здесь есть скользкий склон. Как только вы начинаете конкретизировать этот процесс, вы перестаете быть фактически Agile и начинаете создавать негибкий водопад обязательных последовательных шагов.

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

Вы относитесь к ним как к ненадежным.

• Анализ истории пользователей. Они все равно это сделают. Зачем это записывать? Они забудут? Точка понимания. Не документация. Не время управления.

• Обзор кода. Вы хотите, чтобы они это сделали. Вы должны создать культуру, где это сделано, и результаты награждение.

  Если результаты проверки кода "ваш код сосет, сделайте это снова", то никто не участвует, и это не делается, кроме как fiat.

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

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

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

Зачем вам это записывать? Что они не делают?

Здесь важная часть.

Почему они не делают это в первую очередь?

Разве они не анализируют? Почему нет? Вам трудно анализировать? Являются ли пользователи недоступными?

Разве они не делают проверки кода? Почему нет? Какой дорожный блок проверяет код? Недостаточно времени? Недостаточно сотрудничества? Недостаточно вознаграждения? Что их останавливает?

Разве они не выполняют модульные тесты? Почему нет? Какой дорожный блок для тестирования? Недостаточно времени? Недостаточно гибкости? Недостаточно положительной обратной связи для проведения тестов?

Почему вы чувствуете необходимость "контролировать" и "принуждать" своих разработчиков? Почему они не делают это самостоятельно?

Ответ 3

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

Например, если мы работаем над рефакторингом части кода как части пользовательской истории, мы можем разбить отдельную задачу, чтобы сначала обработать ее. Но если это новый разработчик, мы делаем вывод, что он будет тестироваться (и обычно делается с TDD) как часть нашего процесса.

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

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

Ответ 4

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

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

Изменить: Я использовал разделение задач на действия один раз. Мы не проводили TDD, но тесты были написаны после завершения задачи. Поэтому каждая задача разработки была сопряжена с тестовой задачей, чтобы показать, что это может быть сделано другим разработчиком, а иногда параллельно с разработкой. Но ответственность за тестирование другого разработчика была решением команды и для сложных задач, которые они действительно делали.

Ответ 5

Если вы сосредоточите все усилия, прилагаемые к отслеживанию задач, чтобы разделить ваши истории на меньшие (1-3 балла), вы будете работать над тем, чтобы стать более гибкими. Малые истории почти не нуждаются в оценках уровня или отслеживании уровня. Ваше ПО получает выгоду от того, чтобы иметь возможность приоритизировать более мелкие наборы функций, и вы можете сосредоточиться на доставке ценности, а не на повторном документировании очевидных шагов. Разумеется, отслеживание команды, согласованной с обычными практиками, в час за историю не совсем полезно.