Переназначить историю пользователя во время спринта? - PullRequest
5 голосов
/ 20 апреля 2020

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

Ответы [ 4 ]

1 голос
/ 29 апреля 2020

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

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

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

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

1 голос
/ 20 апреля 2020

Scrum не имеет ничего сказать о том, как выполняется работа, и как управляется доска. Тем не менее, многие команды смотрят на "1003" подходы "тянуть", чтобы ответить на этот вопрос. В этом случае работа никогда не назначается и не дается, она только востребована / взята на работу. Поэтому рецензент переводит работу в «Обзор кода», когда он начинает работу. Точно так же тестер, когда они начнут, переводит работу в QA. «Готовые» столбцы немного неправильны, поскольку они не являются состояниями. Скорее, они являются статусами предыдущего состояния. Если ваш заказ - Code Review - QA Ready - QA, то фактически QA ready - это возможное обозначение работы в Code Review. Это может показаться незначительным, но очень важно предотвратить скопления в вашем процессе, когда работа останавливается без владельцев.

0 голосов
/ 06 мая 2020

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

0 голосов
/ 22 апреля 2020

Мы используем немного другой подход. Как у нас есть следующие столбцы на Jira Board.

  1. To-do
  2. In_progress
  3. Готов для обзора
  4. Готов для QA
  5. In-Testing
  6. Переработано / Отклонено
  7. Выполнено

Разработчик выбирает задачу из списка дел, назначает ее себе и сохраняет в прогресс. Когда он закончил, он переместил его в Ready for Review и оставил его без назначения. Кто-то выберет это, назначит это себе и рассмотрит это. После рассмотрения этот человек переместит дело в готовое для обеспечения качества, не назначая его никому. Тот, кто свободен или готов работать над делом, назначит это дело себе, а когда он начнет работать над делом, он перейдет к тестированию. В результате тестирования дело может go в переработке / отклонении или в Готово. Если он переместился в Rework / Rejected, он назначит его первоначальному человеку, который изначально работал над ним. И этот человек, когда переделает его, снова переместит дело в процесс.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...