Шкала Фибоначчи (гибкая) - Fibonacci scale (agile)

В Гибкая разработка программного обеспечения, то Шкала Фибоначчи состоит из последовательности чисел, используемых для оценки относительного размера пользовательские истории в баллах. Agile Scrum основан на идее итеративной работы в коротких спринтах, обычно продолжительностью две недели, когда требования и разработка постоянно улучшаются. В Последовательность Фибоначчи состоит из чисел, которые представляют собой сумму двух предыдущих чисел, начиная с [0, 1]. Agile использует последовательность Фибоначчи для достижения лучших результатов за счет уменьшения сложности, усилий и сомнений при определении времени разработки, необходимого для задачи, которое может варьироваться от нескольких минут до нескольких недель.[1]

Процедура

Легче определить относительную сложность задачи, чем вычислить, сколько времени она требует. Из-за этого при работе с Agile используется пересмотренная шкала Фибоначчи в пунктах для оценки работы, в отличие от традиционного измерения времени.[2]

В одном методе, который обычно используется для вычисления размера историй в баллах, такой процесс, как игра Планирование покера, используется следующий процесс:

  1. Владелец продукта садится с командой, чтобы оценить пользовательские истории.
  2. Каждый участник оценивает число по шкале Фибоначчи, которое, по его мнению, представляет размер задачи.
  3. Все участники раскрывают свое количество одновременно (чтобы на них не влияли оценки друг друга).
  4. Любые расхождения в числах будут сопровождаться обсуждением до достижения консенсуса.
  5. Каждая пользовательская история добавляется в корзину, которая представляет соответствующую точку на шкале Фибоначчи.
  6. Вышеупомянутые шаги повторяются для всех пользовательских историй.
  7. Ковши добавляются в отставание.

Предоставление каждому участнику возможности мыслить индивидуально снижает давление и может привести к более точному представлению размера объекта.

В другом широко используемом методе, таком как игра двухпроходного относительного определения размера,[3] также известный как метод Стива Бокмана[4] и командная оценка игры,[5] используется следующий процесс:

  1. Менеджер по продукту сидит с командой, чтобы оценить ценность проекта пользовательских историй, которые предоставляются команде в стопке карточек 3x5 или 4x6.
  2. Первый член команды читает первую карточку и кладет ее на стол, передавая оставшуюся стопку следующему члену команды.
  3. Второй член команды читает вторую карту, может заявить о своем убеждении, что история больше или меньше, чем карта, уже лежащая на столе, или может попросить команду помочь в определении этого и устанавливает, какое направление меньше или больше, помещая карту. слева или справа от первой карты; и передает оставшуюся стопку следующему члену команды.
  4. У третьего члена команды есть выбор: переместить позицию второй карты; или, чтобы прочитать третью карточку, заявить о своей уверенности в том, что рассказ больше первых двух, меньше первых двух; или принадлежит между первыми двумя; и передает оставшуюся стопку следующему члену команды.
  5. Когда все карты на столе - если менеджер по продукту действительно указал ценность проекта, то, вероятно, есть 60, 100 или 130 карт, и команде пришлось «подгонять» их, чтобы вместить их все, - тогда команда начинает с самый маленький рассказ и присваивает ему «1», продолжая присваивать «1» последующим рассказам, пока они не увидят очевидный переход к «2», а затем к «3», «5», «8», и так далее. В результате «змея» карт теперь пронумерована от самого маленького рассказа, «1», до самого большого эпоса, «100».

Этот метод имеет то преимущество, что числа не используются до второго прохода; что для первого рассказа не требуется угадывать, насколько велика цифра «5», «8» или «3»;[4] что истории действительно упорядочены и пронумерованы относительно друг друга; и когда не все могут оценить всю историю.[6]

Независимо от метода, когда команда проходит несколько спринтов и процесс оценки улучшается, менеджер по продукту сможет определить стабильный скорость. Скорость определяется путем подсчета количества набранных очков истории на каждой итерации.[1]

Значимость

Люди оценивают пользовательские истории с меньшими точками более точно, чем пользовательские истории, с которыми связаны более высокие затраты. По мере увеличения числа разница между двумя последующими числами увеличивается экспоненциально и приводит к менее точным оценкам.[7]

  • Использование рядов Фибоначчи полезно в этом сценарии, потому что более крупные пользовательские истории (то есть истории размером более 8), которые, как правило, приводят к несогласованным оценкам между каждым членом команды, могут быть сгруппированы до ближайшего оценочного числа Фибоначчи соответствующего сегмента в бэклоге.
  • В случае небольших пользовательских историй разница между сегментами невелика, и, следовательно, окончательная стоимость ресурсов и времени может быть определена более точно.

Один из хороших способов оценить стоимость - выразить ее в терминах, кратных стоимости других известных пользовательских историй. Таким образом, каждому члену команды будет легче оценить относительную стоимость. Процесс оценки сравнения истории с двумя ранее оцененными пользовательскими историями называется триангуляцией.[7]

Менеджер продукта может включить в шкалу значение «0», указывающее, что пользовательские истории требуют очень мало времени или ресурсов.[7] Однако пользовательская история, которой была присвоена стоимость 0, не может использоваться в качестве относительной шкалы для оценки стоимости других пользовательских историй (т.е. мы не можем сказать, что история в 10 раз сложнее, чем история размера 0).

Преимущество последовательности Фибоначчи состоит в том, что она позволяет разработчикам разделить пользовательскую историю из одной большой корзины на две предшествующие группы (поскольку корзина формируется путем добавления размера двух предыдущих сегментов).[7] Этот процесс помогает создавать оптимальные пользовательские истории.

Прочие оценочные шкалы

  • Линейная шкала - увеличение фиксированного значения
  • Размер футболки - (S
  • Играя в карты - В основном используется при планировании покера (A <2 <3…)
  • Экспоненциальный ряд - ({ап} для некоторых а и для всех целых п>0)

Смотрите также

Рекомендации

  1. ^ а б «Обзор размеров и оценок | Справка CA Agile Central». help.rallydev.com. Получено 2017-02-10.
  2. ^ «Гибкое управление проектами (доступна загрузка PDF-файла)». ResearchGate. Получено 2017-02-10.
  3. ^ Бокман, Стив (2015-01-25). Практическая оценка. Цифровые сервисы Amazon. КАК В  B00SS794IQ.
  4. ^ а б «Размер истории: лучшее начало, чем планирование покера». agilelearninglabs. Получено 2018-07-08.
  5. ^ «Как играть в командную оценочную игру». agilelearninglabs. Получено 2018-07-08.
  6. ^ «Оценка команды». нетобъективы. Получено 2018-07-09.
  7. ^ а б c d Кон, Майк (2005-11-01). Гибкая оценка и планирование. Pearson Education. ISBN  9780132703109.