Система точек Фибоначчи

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

  • 1 - Небольшие однострочные исправления, изменения копирования или доработки дизайна.
  • 2 - Небольшие изменения логики с потенциальными регрессами.
  • 3 - Стандартная функция, которая часто требует отслеживания и тестирования AB.
  • 5 - Более крупные функции, чем 3, которые обычно включают создание новых экранов и компонентов.
  • 8 - Очень большая функция, которая часто требует значительного рефакторинга или разработки новой архитектуры.
  • 13 - Эпосы. Проекты, которые слишком велики для реализации. Сложные многоспринтовые задачи, требующие тщательного планирования и тестирования.

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

Разработчики часто шутят, что

«Ой, просто возьмите любую работу, которую вам нужно сделать, и умножьте ее на 3.»

Мы отшучиваемся, но в этом есть доля правды.

Почему это плохо для оценки спринта

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

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

  • У человека А есть ПЯТЬ билетов по 2 очка. Всего баллов: 10
  • У человека Б ДВА билета по 5 баллов. Всего баллов: 10

На бумаге и с точки зрения руководства, оба сотрудника А и Б имеют одинаковый объем работы, по 10 баллов каждому. Однако на самом деле у человека А относительно легкий спринт с работой, которая требует минимального планирования и минимального времени проверки кода около 5 минут на заявку.

Между тем, у человека Б невозможный спринт, который сильно недооценивается из-за количества неизвестных переменных, которые обычно возникают при 5-балльной истории и выше. Не говоря уже о том, что требуется ЧАСЫ, если не ДНИ, чтобы получить более крупные запросы на включение, которые будут рассмотрены, обновлены, проверены снова и повторены, пока они не будут одобрены. Написание модульных тестов и обеспечение качества более крупных функций также линейно масштабируются в зависимости от сложности функции. Таким образом, в целом по 5-балльной характеристике Человек Б на самом деле выполняет значительно больше работы, чтобы все было сделано «правильно». В противном случае они используют «ярлыки», создавая хакерский код, обходя проверку кода или пропуская модульное тестирование. Либо это, либо они работают сверхурочно, что ПРИВЕДЕТ к выгоранию разработчиков.

Тогда возникает проблема: как передать это другим?

Решение

Более точная оценка будет заключаться в том, что человек B имеет 30 баллов фактической работы по сравнению с лицом A, у которого 10 баллов. Это рассчитывается с использованием приведенной ниже таблицы, где фактический объем работы является результатом умножения сложности Фибоначчи истории на линейно увеличивающийся коэффициент масштабирования.

Платформа: просто оцените сложность функции, затем умножьте ее на коэффициент масштабирования и используйте результат для расчета фактического объема работы, необходимой для завершения функции без использования ярлыков . Если объем работы не может уместиться в рамках одного спринта, разбейте заявку до тех пор, пока он не уместится. Если можно воспользоваться более быстрыми путями и погасить их позже, сделайте это, но сделайте платежный талон, чтобы погасить его. Обязательно сообщите об этом долговом тикете руководству, чтобы оно понимало, насколько обходными путями обходятся обходные пути.

Но… количество баллов варьируется от человека к человеку

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

Ретроспективный взгляд в прошлое

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

Как правило, я заметил, что эти проблемы начинают возникать с 3-балльными характеристиками и часто возникают с 5- и 8-балльными историями. Объем работы, необходимой для выполнения этих более крупных функций, часто требует множества скрытых задач, таких как рефакторинг кода, обработка крайних случаев, обнаружение и устранение состояний гонки, а также проблемы отладки, обнаруженные при проверке кода и контроле качества. Не только это, но и решение этих проблем часто вовлекает других людей, которые уже заняты сами и, таким образом, вызывают простои из-за блокировщиков. Это время простоя очень мешает течению; умственно утомляет переключение контекста; и требует времени ожидания ответов и импровизированных встреч для принятия решения. Эти скрытые затраты будут учтены во время оценки фреймворком и будут намного лучше для психологического определения масштабируемости архитектуры и того, насколько хорошо работает команда.

Парное программирование

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

Заключение

Мой совет любому читателю - попробовать. Если люди хороши в одном, так это в том, что мы все умеем недооценивать. Эта структура учитывает это - она ​​точно оценивает, насколько сложна новая функция и сколько работы потребуется для ее создания, одновременно передавая скрытые затраты на создание более крупных функций руководству. Попробуйте и дайте мне знать, что вы думаете.