Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
grischenko-proj-management / books / KanbanAndScrum-Russian.pdf
Скачиваний:
50
Добавлен:
03.03.2016
Размер:
3.62 Mб
Скачать

27

Как оценивать?

Это вечная тема для обсуждения, и здесь, конечно, нет однозначного ответа:

Оценивайте регулярно

Оценивайте, когда это необходимо

Используйте идеальные дни / story points

Точных оценок все равно не бывает, так что используйте относительные оценки (например, размеры футболок – S, M, L)

Избегайте оценок, или оценивайте только тогда, когда стоимость задержки оправдывает это

Под влиянием Scrum-а (все-таки именно с него начинали) мы решили начать со story point-ов. Но на практике команды относились к story point-ам, как к человеко-часам (что было для них более естественно). Сначала мы оценивали все истории. Со временем, менеджеры поняли, что если количество одновременных проектов в работе невысокое, то мы не заставляем заказчиков ждать выполнения их запросов. Кроме того, стало ясно, что в случае резкого изменения ситуации всегда можно сместить приоритеты и решить новую проблему.

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

Когда-то один менеджер под давлением пообещал сдать проект "к концу этой недели". Так как на проекте применяли Kanban-доску, было легко оценить прогресс (количество завершенных историй) и понять, что только около 25%, скорее всего, будет выполнено после первой недели. Следовательно, понадобились бы три дополнительные недели. Столкнувшись с этим фактом, менеджер изменил приоритет проекта, остановил параллельные работы, и сделал возможной сдачу проекта в срок. Всегда сверяйтесь с доской

Что означает оцениваемый объем? Время выполнения с учетом задержек или время работы?

Наши story points отражали время работы, т.е. сколько часов непрерывной работы мы ожидали потратить на эту историю; это не общее время выполнения с учетом задержек (не календарное время и не количество часов ожидания). Измеряя каждую неделю количество story point-ов завершенных задач (производительность), мы смогли просчитать время выполнения с учетом задержек.

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

Соседние файлы в папке books