Как оценить пользовательскую историю с помощью автоматизированной таблицы аффинности

Очки истории или дни, или оба?

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

Таблица аффинности для оценки истории

В Visual Paradigm, мы не рассматриваем оценку истории как процесс конфликта или переговоров, а как процесс построения команды, который делает взаимодействие по задачам и нагрузку понятными и прозрачными для всех членов команды. Инструмент пользовательской истории оснащает команду таблицей аффинности для автоматизации процесса оценки истории вместе с устранением спайков. Более того, визуальная таблица аффинности поддерживает одновременную оценку в реальном времени как по очкам истории, так и по часам. Когда вы перетаскиваете историю по таблице, одновременно отображаются и очки истории, и часы, пока история продолжает перемещаться. Просто опустите историю в ячейку, где ваша команда считает, что оценка подходит.

Как рассчитывает таблица аффинности?

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

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

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

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

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

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

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

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