суббота, 20 декабря 2008 г.

Story Points vs Ideal Hours

Для многих возникает неоднозначность и недопонимание, зачему вводить такую характеристику, как Story Point. А так же в продолжение предыдущего поста.
Объяснения очень просты. В Agile используется и то и другое. Но для разных уровней декомпозиции требований и реализации.

Я выделяю следующую пирамиду требований к разрабатываему продукту. От верхнеуровневой бизнес идеи до задач для разработчиков. В этой пирамиде требования к продукту (1-3) постепенно разбиваются до требований разработчика к коду (4-5) :)

1. Метафора продукта
2. Фичи продукта
3. User Story
4. Task
5. Task List

Каждый нижний пункт является декомпозицией верхнего. Мерить п.1 и п.2 очень сложно. Так как это очень высоко и тяжело оценить хоть как-то. п.5 (декомозиция задачи на мелкие шаги; Test List - шаги по задаче) слишком мелкий для оценки и нецелесообразен для оценок.

Рассмотрим п.3 и п.4
3. User Story оцениваем в Story Points с использование Planning Poker.
4. Tasks оцениваем в Ideal Days/Hours используя одну из схем: индивидуально (старый подход) или коллективно (новый с 2004 года).

В переводе на русский
3. Функциональные требования оцениваются в единицах трудоёмкости
4. Задачи оценивают в идеальных часах задачи (до 2 дней)

Продолжительность Ideal Hour адаптивно выбирается. В классике отталкиваются от 6 часов. Остальное адаптируется по ситуации.
Во время планирования на выходе мы получаем
1. Плановую суммарную Story Points
2. Плановое суммарное Ideal Days/Hours

Управление скоростью разработки легче вести с более высокоуровнего пункта. А так как у нас оценке подлежит только п.3 и п.4 - выбор очевиден. К тому же Story Points непосредственно связаны с функциональными требованиями и бизнес ориентированы. В тоже время под Ideal Hours может подпасть много не входящее в User Story, и носят инженерный оттенок реализации. Далее вводится фокус-фактор, но об этом смотрите в предыдущем посте.

Это классическая схема работы. Опыт показывает, что изобретать альтернативы не имеет смысла. Но это не должно останавливать.

Дополнительные ссылки:
1. Об agile по-русски: User Stories
2. Planning Poker

2 комментария:

  1. Зачем оценивать задачи, если уже дана оценка User Story? Ещё и в других единицах?

    ОтветитьУдалить
  2. А, ок - в следующей статье написано значит =)

    ОтветитьУдалить