Оценки сложности по шкале Фибоначчи — это способ измерить относительную трудоемкость или сложность задач в agile-разработке, используя числа из последовательности Фибоначчи. Вместо того чтобы пытаться посчитать, сколько часов или дней уйдет на выполнение задач, команды проставляют для них оценку, основываясь на предполагаемой сложности в сравнении с другими задачами. 

Если команда оценивает задачу на 5, это означает, что она примерно вдвое сложнее задачи с оценкой 3 и наполовину проще, чем задача с оценкой 8. 

Зачем использовать последовательность Фибоначчи для оценки по методике agile?

Шкала Фибоначчи хорошо подходит для оценки по методике agile, так как естественным образом отражает то, как растет неопределенность по мере усложнения задач. Разрыв между числами в последовательности постоянно увеличивается: разница между 1 и 2 небольшая, а вот скачок с 13 до 21 уже существенный. 

Это математическое свойство отражает реальную сложность проекта. Небольшие задачи относительно предсказуемы, а большие связаны с большей неопределенностью. Именно это делает разницу между оценками сложности эпиков 13 и 21 гораздо более существенной. 

Методика оценки по шкале Фибоначчи естественным образом помогает командам дробить слишком большие задачи на более мелкие.

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

Такой продуманный подход позволяет принимать эффективные решения по планированию спринтов и устанавливать более предсказуемые сроки выполнения проектов, на которые могут рассчитывать заинтересованные стороны.

Эффективное обсуждение в команде при планировании спринта

Когда участники команды по-разному оценивают сложность выполнения тех или иных задач, это побуждает к продуктивному обсуждению объема работ, сложности и подхода к реализации. В такой дискуссии можно определить предположения, выявить потенциальные препятствия и убедиться, что команда понимает, что будет входить в работу.

В результате в команде улучшится взаимодействие и взаимопонимание, а это сведет к минимуму непредсказуемость в процессе разработки.

Ускоренная оценка без споров по мелочам

Расстояние между числами Фибоначчи не дают команде погрязнуть в обсуждении мелких расхождений, не влияющих на планирование. Вместо того, чтобы спорить, тянет ли задача на 6 или 7 баллов, приходится выбирать между 5 и 8, что вынуждает смотреть на вещи шире. 

Благодаря этому команды быстрее договариваются на собраниях по планированию и могут посвящать больше времени реальной разработке.

Вот как эффективно использовать оценки сложности по шкале Фибоначчи в команде.

1. Выберите истории, которые станут эталонной основой для оценки сложности

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

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

2. Разбейте крупные пользовательские истории на управляемые задачи

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

Если история кажется слишком большой для точной оценки, разбейте ее на более мелкие и комфортные части. Как правило, в процессе вы обнаружите скрытые сложности и зависимости, которые не были видны в исходной истории.

Декомпозиция пользовательских историй также помогает управлять бэклогом и дает больше гибкости при планировании спринта. 

3. Убедитесь, что у каждой пользовательской истории есть конкретные цели и критерии успеха

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

Нечетко прописанные истории, например «улучшить производительность системы», невозможно оценить точно. Почему? В этом случае объем работ ничем не ограничен, а значит, его будет сложно реализовать.

Лучше ставить конкретные задачи, например: «сократить время загрузки страницы каталога продуктов до 2 секунд». Четко сформулированные истории также способствуют повышению гибкости рабочих процессов и сохранению высокого темпа работы на протяжении всего спринта. 

4. Проведите покер планирования для совместной оценки задач

Покер планирования — это эффективный метод оценки сложности. Во время таких сессий участники команды независимо друг от друга присваивают каждой истории баллы по шкале Фибоначчи, а затем одновременно раскрывают свои оценки, чтобы избежать предвзятости.

Одновременное раскрытие оценок позволяет не влиять на мнение друг друга. Можно использовать как физические карточки для покера планирования, так и цифровые инструменты для удаленных команд. 

Цель состоит в том, чтобы обеспечить активное участие каждого. 

5. Проведите обсуждение с участниками и придите к единой оценке

Покер планирования может стать особенно интересным, когда мнения людей расходятся. Если один человек ставит 3 балла, а другой — 8 баллов, это обычно означает, что они по-разному воспринимают работу. 

Если оценки сильно отличаются, попросите участников с самыми высокими и низкими оценками объяснить свою логику. Высокая оценка часто объясняется тем, что человек заметил скрытую сложность, которую остальные упустили. 

А участник, поставивший низкую оценку, может знать способ упростить выполнение задачи. 

Продолжайте обсуждение и повторное голосование, пока команда не придет к разумному консенсусу.

6. Отслеживайте скорость и корректируйте оценки с течением времени

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

Отслеживайте как скорость отдельных спринтов, так и скользящее среднее, чтобы учитывать естественные колебания. Используйте данные о скорости для обоснования оценок в будущем. 

Если ваша команда систематически недооценивает определенные виды задач, учитывайте это в своих оценках. Такой процесс непрерывного улучшения помогает со временем повысить точность оценок.

Самая распространенная проблема при оценке сложности по шкале Фибоначчи — несогласованность: разные аналитики могут оценивать похожие задачи разным количеством баллов. Эту проблему можно решить путем регулярных собраний команды с целью проверки выполненной работы и обсуждения точности изначальных оценок. 

Еще одна проблема — стремление напрямую перевести оценки сложности в оценки времени. Не стоит этого делать. Лучше сосредоточьтесь на тенденциях скорости и обязательствах по спринтам.

Альтернативы последовательности Фибоначчи для оценки сложности

Оценки сложности по шкале Фибоначчи подходят для многих команд, однако это не единственный способ оценки для методики Agile. Вот самые популярные альтернативы и их сравнение.

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

• Размер футболок (XS, S, M, L, XL). Этот способ более интуитивен, так как размеры одежды понятны каждому. Это отличный вариант для первоначальных приблизительных оценок, но он не дает возможности математически измерять и отслеживать скорость с течением времени.

• Степени 2 (1, 2, 4, 8 и т. д.). Этот способ создает такие же разрывы, как и в последовательности Фибоначчи, но он проще в расчетах. Принцип удвоения легко запомнить, но для многих команд он кажется более искусственным, чем Фибоначчи.

• Модифицированный ряд Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100). В этой версии для простоты большие числа округляются. При этом сохраняются все преимущества оценки по шкале Фибоначчи, но оценки получаются точнее и удобнее.

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

В Jira есть отличная встроенная поддержка оценки сложности по шкале Фибоначчи, что позволяет легко реализовать этот подход без дополнительных инструментов и сложной настройки. Платформа включает в себя функции для применения покера планирования (в рамках agile-подхода), отслеживания скорости и планирования спринтов, и эти функции отлично работают в совокупности с оценкой сложности.

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

Готовы повысить точность оценок своей команды? Начните использовать оценку сложности по шкале Фибоначчи в Jira уже сегодня, и вы увидите, как продуманная совместная оценка может способствовать эффективности управления проектами в рамках agile-подхода.

Получить Jira бесплатно