Приветствую!
Знаете, какой вопрос от заказчика проекта можно назвать одним из самых трудных для команды разработчиков? Думаю, из названия статьи понятно, что это вопрос о том, сколько времени займёт разработка проекта со всеми вытекающими.
И одна из основных проблем этого вопроса заключается в том, что разработчики не любят составлять какие-либо графики и планировать своё время. Почему же? Скорее всего потому что крайне редко бывают ситуации, когда проект разрабатывается, следуя графикам, и завершается точно в срок. Так зачем заниматься планированием, рассчитывать будущее время, тратя при этом текущее впустую?
В далёком 2007 году, такой небезызвестный человек в мире программирования, как Joel Spolsky, написал статью под названием «Evidence Based Scheduling», в которой изложил свой взгляд на решение проблемы расчёта времени на проекте.
Здесь я хочу представить свой вольный перевод данной статьи с опущением информации, не относящийся к теме.
Суть планирования на основе фактов заключается в том, что во время своей работы вы собираете эти самые факты о времени своей работы над той или иной задачей, потом на основе этих данных строите графики разработки своего проекта. Но звучит это куда проще чем есть на самом деле, ведь в итоге вы получаете целую кривую с вероятностями завершить проект в тот или иной срок.
Попробуем разобраться в методе поподробнее…
1. Разбивайте свои задачи
При виде графика, время работы над задачами которого измеряется днями или даже неделями, вы можете быть уверены в том, что все эти расчёты времени не будут совпадать с действительностью. Вы должны делить свою работу на небольшие по времени задачи, которые можно измерять часами, не более 16 часов на задачу.
Это поможет вам лучше понимать то, чем предстоит заниматься. Написать функцию перебора массива, создать диалоговое окно, прочитать файл. Такие небольшие задачи вы, скорее всего, уже выполняли, а значит можете здраво оценить время, которое потратите на их выполнение в очередной раз.
Напротив, если вы будете строить график, не разбивая задачи на более мелкие, вам будет достаточно трудно осмыслить все детали каждой задачи и точно оценить время их выполнения. Всё просто.
2. Измеряйте время
Так как же всё-таки вы можете точно сказать, сколько времени потребуется для реализации данной функциональности? Вы не поверите, но метод точнее, чем просто измерить время выполнения той или иной задачи у вас едва ли получится найти. Но даже в этом случае, точного времени вы всё равно не добьётесь ввиду разных отвлекающих факторов.
Так что начинайте вести журнал учёта рабочего времени, следите за тем, как долго вы работаете над каждой задачей. Затем вы можете сравнить результат, который получили во время измерения с тем временем, которое, как вы оценили, должно было уйти на выполнение этой задачи.
Для каждого разработчика должны получатся свои данные:
Каждая точка на диаграмме - это одна выполненная задача с предсказанным и фактическим временем выполнения этой задачи. Когда вы делите свою оценку на фактическую, вы получаете коэффициент. Со временем каждый разработчик в команде должен собрать историю коэффициентов.
История коэффициентов мифического идеального оценщика времени будет выглядеть примерно вот так: {1, 1, 1, 1, 1, …}. А вот типичный «плохой» оценщик будет иметь историю: {0,1, 0,5, 1,7, 0,2, 1,2, 0,9, 13,0}. Все люди ошибаются, но, как правило, у среднего разработчика коэффициенты будут достаточно близки между собой и меньше единицы. Потому что все задачи обычно занимают больше времени ввиду отвлекающих факторов. Так, средний разработчик может иметь подобные коэффициенты {0,6, 0,5, 0,6, 0,6, 0,5, 0,6, 0,7, 0,6}. Причём по мере накопления опыта, навыки оценки времени улучшаются, так что вы можете выкинуть оценки, скажем, старше 6 месяцев.
Если в команде есть новый разработчик, у которого нет подобной истории коэффициентов, вы можете сделать ему заведомо плохую историю с широким диапазоном коэффициентов, пока он не выполнит нужное количество задач.
3. Моделируйте будущее
Вместо того, чтобы просто сложить оценки времени для получения одной даты завершения проекта, что звучит логично, однако даёт совершенно неверный результат, вы можете использовать метод Монте-Карло для моделирования многих возможных вариантов будущего. В этом методе вы можете получить 100 возможных вариантов будущего. Каждый из этих вариантов имеет вероятность сбыться 1%, поэтому вы можете составить диаграмму вероятности того, что вы завершите проект к какой-либо дате.
Для вычисления возможного времени завершения каждого разработчика, вы делите его оценку времени выполнения каждой задачи, на случайный коэффициент взятый из его истории на предыдущем шаге.
Пример вычислений:
Проведите измерения 100 раз. Каждое измерение будет иметь вероятность сбыться 1%. Таким образом мы можем получить вероятности сдачи проекта в какую-либо дату.
И что же получается?
- В случае мифического идеального оценщика все коэффициенты равны 1. Деление на 1, не имеет никакого эффекта. Таким образом, все результаты моделирования дают одну и ту же дату завершения, и эта дата имеет 100% вероятность. Прямо как в сказках!
- Плохая оценка времени будет давать совершенно разные результаты, потому что, когда вы делите на случайные коэффициенты, вы каждый раз получаете разные числа. Кривая распределения вероятностей, которую вы получите, будет показывать равные шансы на отправку завтра или в далеком будущем.
- Средний оценщик имеет множество коэффициентов, которые довольно близки друг к другу, например, {0,6, 0,5, 0,6, 0,6, 0,5, 0,6, 0,7, 0,6}. Когда вы делите на эти коэффициенты, вы увеличиваете количество времени, которое было изначально спрогнозировано, так что 8-часовая задача может превратиться в13 часов, а на другой итерации в 15 часов. А поскольку все исторические коэффициенты довольно близки и колеблются около 0,6, то после запуска каждой итерации моделирования, вы будете получать очень похожие числа - узкий диапазон возможных дат завершения проекта.
На каждой итерации моделирования Монте-Карло, конечно, вы должны преобразовывать почасовые данные в календарные, что означает, что вы должны учитывать график работы каждого разработчика, отпуска, праздники и т. д. Также каждую итерацию вы должны следить и брать именно значение того разработчика, который завершит свои задачи последним, ведь именно в этот момент проект будет окончательно готов.
Все эти расчеты довольно кропотливы, но, к счастью, мы являемся счастливыми обладателями различных вычислительных устройств.
Как быть с отвлекающими факторами?
Как насчёт того, чтобы потратить пол дня помогая новичку настроить среду для разработки или сходить на перерыв? Всё это отвлекающие факторы. Иногда на них уходит больше времени, чем на написание кода. Следует ли учитывать эти факторы при отслеживании рабочего времени? Да следует, и более того планирование на основе фактов в данном случае показывает даже лучшие результаты.
Давайте разберём простой пример:
Пусть у нас есть сотрудник Джон, вся задача которого сводится к написанию get и set функций для полей класса. Каждый геттер или сеттер занимает у него 2 часа. Итак, оценки его задач выглядят следующим образом: {2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, …}.
У этого бедного парня есть начальник, который иногда прерывает его двухчасовым разговором о ловле рыбы. Теперь, конечно, Джон мог бы иметь в своем расписании задачу под названием «Болезненные разговоры о рыбе» и записать ее в свое расписание, но это было бы неразумно с политической точки зрения. Вместо этого Джон просто держит часы. Его настоящее время выглядит так: {2, 2, 2, 2, 4, 2, 2, 2, 2, 4, 2, …}.
А вот его коэффициенты: {1, 1, 1, 1, 0,5, 1, 1, 1, 1, 0,5, 1, …}.
А теперь подумайте, что происходит. В моделировании Монте-Карло вероятность того, что каждая оценка будет разделена на 0,5, точно такая же, как вероятность того, что начальник Джона прервет его во время выполнения любой из задач. Итак, планирование на основе фактов составляет правильный график!
4. Управляйте своими проектами
После планирования на основе фактов вы можете активно управлять своими проектами. Например, расставив задачи по разным приоритетам, вы можете удалять некоторые задачи с низким приоритетом для того, чтобы успеть вовремя.
Так же вы можете перемещать задачи между разработчиками для достижения наилучшего результата по времени.
А как насчёт непредвиденных задач?
Если у вас было все продумано до мельчайших деталей, когда вы начали работу, планирование на основе фактов отлично работает. Однако, всегда могут появится задачи, которые не планировали. У вас появляются новые идеи, ваши заказчики хотят функции, которых у вас нет. Все это приводит к задержкам, которые нельзя было предсказать, когда вы планировали изначальный график.
В идеале, для таких вещей нужно выделять специальный буфер, вот список целей, под которые стоит выделить дополнительное время:
- Идеи о нового функционале
- Реакция на конкурентов
- Интеграция
- Время отладки
- Тестирование
Итак, теперь, когда появляются новые задачи, вы можете взять время из соответствующего буфера и использовать его.
Что произойдет, если вы все еще добавляете функции, а у вас закончился буфер? Что ж, теперь даты завершения проекта начинают сдвигаться. На этом моменте следует начать внимательно следить за временем, иначе есть риск того, что проект в принципе не завершится.
Несколько полезных фактов напоследок
1) Корректно рассчитать время может только разработчик, выполняющий работу. Любая система, в которой руководство составляет расписание и передает его разработчикам, обречена на провал. Только разработчик, который собирается реализовать функцию, знает, какие шаги ему необходимо предпринять для реализации этой функции.
2) Возвращайтесь и добавляйте время к задаче, при обнаружении ошибки в её реализации. Вы не можете спрогнозировать появление ошибок заранее, но для большей достоверности планирования на основе фактов, это время нужно учитывать.
3) Представляйте график, как коробку с деревянными блоками. Если у вас есть куча деревянных блоков, и вы не можете поместить их в коробку, у вас есть два варианта: взять коробку побольше или удалить несколько блоков. Если вы хотите завершить проект через 6 месяцев, но по прогнозам проект занимает все 12, вам придется либо отложить завершение, либо найти некоторые функции, которые можно удалить. Вы не можете сжимать блоки, и если вы думаете, что можете, то просто обманываете сами себя.
Заключение
На мой взгляд, метод планирования на основе фактов является самым конкретным из всего, что мне удавалось найти по этой теме, ведь обычно, говоря о расчёте часов, люди приводят какие-то абстрактные измерения, которые свойственны только им и, скорее всего, не подойдут вашему проекту.
Метод же планирования на основе фактов учитывает способности каждого разработчика в команде, отсюда можно говорить о его точности и применимости почти на каждом проекте. Его выгода огромна: реалистичные графики, которые заставляют вас принимать правильные решения во время реализации проекта.
Спасибо за просмотр!
Если вам понравилась статья - можете оценить её, а также задать свой вопрос в комментариях, я на них отвечаю.
