freeCodeCamp/guide/russian/agile/planning-poker/index.md

39 lines
4.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

---
title: Planning Poker
localeTitle: Планирование покера
---
## Планирование покера
### Введение
Планирование покера - это метод оценки и планирования в модели разработки Agile. Он используется для оценки усилий разработчиков, необходимых для [истории пользователя](../user-stories/index.md) или функции.
### Обработать
Планирование покера выполняется для одной истории пользователя за раз.
Каждая оценка имеет идентичный набор карт покера, состоящий из карточек с различными значениями. Значения карты обычно представляют собой последовательность Фибоначчи. Единицей, используемой для значений, может быть количество дней, сюжетных точек или любая другая единица оценки, согласованная командой.
Владелец продукта (ПО) или заинтересованная сторона объясняет историю, которая должна быть оценена.
Команда обсуждает эту историю, задавая любые уточняющие вопросы, которые они могут иметь. Это помогает команде лучше понять, _что_ хочет ПО.
В конце обсуждения каждый человек сначала выбирает карту (представляющую их оценку для истории), не показывая ее другим. Затем они открывают свои карты одновременно.
Если все карты имеют одинаковое значение, значение становится оценкой для истории. Если есть различия, команда обсуждает причины выбранных ими значений. Очень важно, чтобы члены команды, которые дали самые низкие и самые высокие оценки, обосновывали свои оценки.
После этого обсуждения повторяется процесс выбора карточки в приватном режиме, а затем ее одновременное отображение. Это делается до тех пор, пока не будет достигнут консенсус в отношении оценки.
Поскольку планирование покера - это инструмент для оценки _совместной_ экспертной оценки, это приводит к лучшему общему пониманию и, возможно, даже к уточнению запроса функции. Он имеет большую ценность, даже если команда работает в режиме без оценок.
Модератор должен попытаться избежать предвзятости подтверждения.
Стоит упомянуть:
* Оценки не сопоставимы между командами, так как каждая команда имеет свою собственную scala.
* Оценки должны включать все, что необходимо сделать, чтобы выполнить часть работы: проектирование, кодирование, тестирование, обмен информацией, обзоры кода (+ все возможные риски)
* Ценность использования планового покера заключается в итоговых дискуссиях, поскольку они показывают разные взгляды на возможную реализацию
### Дополнительная информация:
* Планирование видео в покере: [YouTube](https://www.youtube.com/watch?v=MrIZMuvjTws)