Оценка пользовательской истории – таблица схожести

Как оценить пользовательские истории для разработки по Agile

Оценка пользовательской истории — непросто! Как мы можем получить наилучшую оценку размера истории? Некоторые говорят, что лучший размер следует оценивать в баллах истории, а другие предпочитают оценивать в часах или днях.

Оценка, безусловно, непроста, но есть несколько концепций, которые могут помочь нам в процессе оценки пользовательских историй:

  1. Оценивайте пользовательские истории относительно друг друга с двух сторон
    • Усилия по работе
    • Риск (например, сложность и неопределенность)
  2. Оценивайте пользовательские истории с использованием баллов истории
  3. Разместите те пользовательские истории в таблице схожести, в которых вы имеете большую уверенность в оценке по усилиям по работе и сложности (риску)
  4. Постепенно оценивайте другие менее знакомые пользовательские истории по усилиям по работе и сложности, сравнивая их с теми историями, которые уже были оценены в таблице схожести.

Схожесть пользовательских историй для оценки

Оценка пользовательской истории никогда не может быть на 100% точной, и на самом деле никакой метод не может достичь этого. Чтобы повысить точность оценки, мы начинаем с определения продолжительности спринта (например, две недели или 10 рабочих дней) и проводим оценку несколькихпользовательских историйс которыми мы чувствуем наибольшую уверенность при оценке (например, 5 дней, а уверенность — средняя). В этом случае вы поместите историю посередине по вертикали (уверенность илирискуровень) и по горизонтали (усилия по работеусилияравны 5 дням, или половине продолжительности спринта, которая составляет 10 дней). Затем вы можете использовать его в качестве опорной точки при оценке других пользовательских историй. Задайте себе вопрос: требует ли эта пользовательская история больше усилий, чем опорная, или меньше, и больше ли неопределенности, или меньше. По мере размещения дополнительных пользовательских историй на таблице схожести вы можете сравнивать несколько историй, чтобы определить, логична ли их оценка, и при необходимости корректировать их, чтобы сделать оценку справедливой. Процесс скорее похож на искусство, чем на инженерию. Проводите его и обсуждайте в командном совещании, а не в конфронтации. Точность обычно повышается по мере зрелости команды.

Estimate User Story with reference point

Как рассчитывается таблица схожести? (Посмотреть видео

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

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

How Affinity Table Calculate?

Обратите внимание: в первом примере выше

Балл истории = Усилия × Риск (например, 3 × 4 = 12)

Единица балла истории = Общее количество баллов / Продолжительность спринта (например, 100 / 20) = 0,2

Дни (часы) истории = Балл истории / Единица балла истории (например, 12 × 0,2) = 2,4

Устранение рисков с помощью проектного спайка

Согласно словарю Agile определение спайка:

«Задача, направленная на ответ на вопрос или сбор информации, а не на создание отгрузочногопродукта. Иногда создается пользовательская история, которую невозможно точно оценить, пока разработческая команда не выполнит реальную работу для решения технического вопроса или проблемы проектирования. Решением является создание «спайка», который представляет собой работу, цель которой — предоставить ответ или решение.»

При оценке пользовательской истории мы учитываем не только усилия по разработке, но и риски и неопределенности, связанные с ней. Часто спайк создается до официального начала спринта для управления работой, которая должна быть выполнена, чтобы другие пользовательские истории можно было оценить справедливо.

Скачать и попробовать сейчас!

Leave a Reply