Часы на руках, часы на экране смартфона, часы на рабочем мониторе... Все время мы считаем время. В уме складываем часы и минуты. Умеем отнимать и прибавлять.

С большими отрезками времени сложнее:

• В одном месяце 30 дней... Или 31 или 29, или 28. А сколько из них рабочих дней? А в праздники? А с учетом отпусков?

• В одной неделе 7 дней... Или 5 рабочих. Или праздники, отпуска...

• В одном дне 24 часа... Или 8 рабочих. А перед «дедлайном» могут быть и все 24 рабочих часа

По крайне мере, мы уверены, что в одном часе 60 минут. Это железно. Но сколько из них рабочих? Когда не отвлекают и не мешают...

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

2 + 2 ≠ 4

Альтернативой использования часов в планировании задач стали «сторипойнты» (Story Points) - некая абстрактная величина размера задачи. Которая включает в себя сразу всё. И длительность задачи и ее сложность и неуверенность в точности оценки и риски (?).

Простая задача? 1 сторипойнт (SP)! Посложнее? 2SP или даже 4SP! Шкала сторипойнтов может идти по ряду чисел Фибоначчи или по степени двойки. Поэтому, если задача «больше», чем на 4SP, то это будет уже, к примеру, сразу 8SP.

А чего 4, а чего сразу 8? В чем измеряются сторипойнты? Ну... В сторипойнтах, в SP. В штуках. 4SP - это вовсе не обязательно 4 часа. Даже совершенно точно - не 4 часа. Это некое качественное описание сложности задачи. Сторипойнты можно сравнивать (8SP определенно больше 4SP), но складывать их уже не так просто.

Предположим, что 2 SP - это небольшая задача, обычно за день вы успеваете решить парочку таких. Тогда сколько будет 2SP+2SP? Наивно предполагать, что ответ «4SP». Потому что шкала не «гладкая» и задача на 4SP это уже может быть посложнее, что две простых.

А еще учтем, что разные люди по-разному понимают, что такое «простая задача». У разных сотрудников разный опыт, разные способности и наклонности.

Но польза от такого абстрактного понятия как SP, определенно, есть. Разработчик не привязан к календарю при планировании задачи. 2SP - это 2SP и в мае и в январе и перед дедлайном. И со временем, как показывает практика, люди начинают достаточно уверено (но не факт, что точно!) планировать свое время, пользуясь исключительно сторипойнтами.

Помогает в этом и статистика выполнения задач (вероятностный метод учета velocity). Если работник/команда за прошлый спринт, к примеру, успевала выполнить 20SP, то и в следующий тоже будет примерно 20SP. Ну, а если нет - то нет. Это же вероятность трудозатрат.

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

И опять все посматривают на циферблат на наручных часах, на календарь в углу монитора...

Сторипойнты - это хорошо, но вы скажите когда всё будет сделано! Нужна точная дата!

Вниз по кроличьей норе

Перед тем как предложить альтернативу часам и SP зафиксируем все хорошее, что, по нашему мнению, есть в сторипойнтах:

• Сторипойнты определяют, прежде всего, сложность задачи, а не точное время трудозатрат

• Сторипойнты позволяют закладывать в SP диапазон времени. 2SP это не точно «2 часа». А и 2 и 4 и может быть даже 10. Как договоритесь

• Сторипойнты позволяют уверенно сказать «8SP!» И не ошибиться, не опоздать

SP не привязаны к часам. Но, если от разработчика все-таки требуют точно сказать, когда будет сделана задача - к среде или к пятнице, то правильным ответом всегда будет «пятница» (ну или «среда», но уже следующей недели).

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

И это, на самом деле, главный бич классического планирования в часах. Спланируешь на малое количество часов - есть риск не успеть. Спланируешь подольше - мало сделаешь

Недостатков у сторипойнтов тоже немало:

• SP не персонифицирован - у каждого работника может быть свое понимание, какая задача «простая», какая «средняя», а какая «сложная»

• Вероятностный учет числа SP на требует накопления статистики. И имеет склонность предсказывать проблемы вчерашнего дня, а не текущие

• Нет четкой и понятной методики как суммировать SP. А если они выражаются в не числами (к примеру, методом «размеров» XS, S, M, L, XL), то проблем еще больше.

• Для преодоления всех описанных выше проблем в команду обычно требуется специальный человек для работы с SP и отчетами по ним

Безумное чаепитие

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

• Указывать примерное время (диапазон), требуемое для выполнения задачи

• Учитывать разнородность трудозатрат для разного типа задач

• Учитывать разнородность трудозатрат для разных разработчиков

• Автоматическая привязка такой оценки к реальным календарным часам

• Математическая обоснованная методика суммирования трудозатрат

• Простое и прозрачное использование как разработчиком, так и менеджером

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

Возьмем, к примеру, такое понятие как «простая задача». Отмерим диапазон от 2 до 4 часов. Это время, которое разработчик оценивает как наиболее точное на выполнение одной небольшой задачи. Но значит ли это, что задача точно не может быть выполнена за 1 час или за 5 часов? Нет. Но уверенность в этом у разработчика уже значительно меньше.

Укажем тогда на рисунке 1 по вертикальной оси степень точности (уверенности) оценки трудозатрат для понятия «простая задача» для, к примеру, обычного разработчика. Для 2, 3, 4 часов, к примеру, поставим 100% - т.е. если задача будет выполнена в итоге за 2, 3 или 4 часа, то разработчик совершенно точно попадает со своей оценкой. Для 1 часа и 5 часов поставим уверенность в 50%, т.е. тоже попадает в оценку, но уже с меньшей уверенностью. Выставим степень уверенности и остальных часов на графике.

Мы получили график функции принадлежности понятию «простая задача». По этому графику можно оценить, насколько точно соответствует то или иное время трудозатрат понятию «простая задача». Кроме того, можно найти «центр масс» или наиболее точное количество часов, которое соответствует такому понятию. К примеру, по формуле взвешенной суммы:

,(1)

Для такого определения понятия «простая задача» получается:

• пессимистичное значение трудозатрат - 5 часов (соответствует уверенности 50%)

• оптимистичное значение трудозатрат - 1 час (также соответствует уверенности 50%)

• реалистичное - 3.5 часа (в соответствии с формулой №1)

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

Алиса в стране Заде

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

Можно ввести такие графики для понятия «простая задача» у Алисы и Боба. К примеру, такие

Как же складывать такие функции принадлежности?

Дело в том, что все наши графики были отражением понятий нечеткой логики. Нечеткая логика - раздел математики, разработанный в 1965 году американским ученым Лотфи Заде. В соответствии с нечеткой логикой сложение двух нечетких понятий будет происходить по следующей простой формуле: суммарное значение берется как сумма, а уверенность берется как минимальная из двух (принцип расширения Заде).

Таким образом нечеткое понятие «простая задача Алисы» + «простая задача Боба» будет соответствовать функции принадлежности на рисунке 3.

По такому суммарному графику можно сделать выводы:

• пессимистичное значение суммарных трудозатрат - 10 часов (соответствует уверенности 50%)

• оптимистичное значение суммарных трудозатрат - 4 часа (соответствует уверенности 50%)

• реалистичное - 7 часов (в соответствии с формулой 1)

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

На самом деле, это не так. Разработчик оценивает привычным для себя способом, измеряя задачи либо в виде степеней двойки (1, 2, 4, 8 и т.д.), либо модифицированных Фибоначчи, либо в виде обычных часов (как при классическом подходе оценки времени часами и минутами). Менеджер же автоматически может получить отчет суммарных трудозатрат, выраженный в часах.

Нечеткие оценки в действии!

Установим в Trello специальный плагин (Power-Up) под названием «FuzzyLand» (на данный момент плагин не выложен в публичный доступ). Добавим в проект две новые фичи. Создадим задачи под каждой фичей. Укажем число FP (нечетких часов из шкалы степени двойки) для каждой задачи

Откроем настройки плагина (настройки доступны только пользователям с администраторскими правами в проекте) и выставим настроение: «оптимистичное» и опыт разработчика «Senior» (рисунок 5).

Эти настройки влияют на вид функции принадлежности при построении отчета. Оптимистичный сценарий «сдвигает» функцию влево, пессимистичный - вправо.

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

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

В будущих версиях плагина предполагается добавить учет исторических данных FP-оценок и ручное редактирование графиков функций принадлежности.

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

Итоги

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

Разработчики продолжают указывать привычные им SP или обычные человеко/часы. Вся «магия» нечеткой оценки происходит в момент построения суммарного отчета. Отчет при этом учитывает и опыт каждого сотрудника и общее настроение команды разработки. Переводя указанные числа в нечеткие часы, а затем суммируя их по правилам нечеткой логики.

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