?

Log in

No account? Create an account
 
 
29 Ноябрь 2007 @ 08:59
FogBugz и Evidence Based Scheduling  
На так давно Joel Spolsky написал статью, в которой описывается довольно интересный метод вычисления оценки времени завершения проекта, реализованный в FogBugz 6.

Суть метода в следующем:

  1. Перед началом работы программисты разбивают задачи на небольшие задачки, не больше 16 часов каждая.

  2. На задачи назначаются ответственные программисты.

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

  4. После завершения работы - смотрим сколько рабочего времени на самом деле заняла задача.

  5. Вычисляем для каждой задачи параметр velocity как "оценка / на самом деле". Joel пишет, что в большинстве случаев velocity (по сути, степень оптимизма разработчика) будет очень близкой для разных задач одного разработчика. Даже если разработчика отвлекает шеф разговорами о рыбалке, то беспокоиться по этому поводу не надо - в будущем он будет отвлекать точно так же и алгоритм все правильно посчитает.

  6. Берем оставшиеся задачи и делаем для них 100 прогонов следующего содержания:




  • смотрим, какой у данной задачи разработчик

  • выбираем его velocity случайным образом из тех, что уже были в его истории.

  • на основании оценки и выбранного velocity считаем сколько времени займет решение этой задачи



Если сделать это для каждой задачи и просуммировать - получим общее время выполнения всех задач в данном случае.Делаем 100 прогонов алгоритма - получаем 100 вариантов общего времени выполнения задач. После этого можно построить график типа: "с вероятностью 5% мы сделаем за 100 часов, с вероятностью 50% - за 120, с вероятностью 95% - за 150 часов". Чем ближе оценки для 5% и 95% - тем точнее прогноз.

Идея замечательная, сразу захотелось реализовать это в TrackStudio, но есть серьезные проблемы:

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

  • У нас код - общий, программисты заранее не знают какие из этих задач они будут делать через месяц. Т.е. у каждого программиста есть 1-2 текущие задачи, а кто будет делать оставшиеся (и сколько это времени у них займет - разница может быть на порядок легко) - не известно.

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



У нас в TrackStudio созданием задач (а значит и их оценкой) занимаюсь я сам, критерий - 2-3 часа на задачу. Конечно, бывают и большие задачи на десятки часов, но они потом компенсируются большим количеством мелких доделок по 15-20 минут. Я посчитал среднее время решения задачи в TrackStudio 3.0, 3.1 и 3.5:
TrackStudio 3.0 - 2.37 часа на задачу
TrackStudio 3.1 - 2.25 часа на задачу
TrackStudio 3.5 - 2.39 часа на задачу.

Как видно, оценка в 2.3 часа на задачу очень точна, разброс минимальный, при том что я просто поделил одно число на другое и вообще ничего больше не учитывал. Значит ли это, если я теперь умножу оставшиеся по следующей версии TrackStudio 50 задач на 2.3 часа, то получу очень точный прогноз в 115 часов ?

Очевидно, нет - проблема именно в количестве задач:

  • 50 задач - это то, что известно. Что там вылезет когда мы начнем это сами тестировать - не известно. Что найдут бета-тестеры и клиенты - тоже. Джоэль советует включать время на исправление багов в задачу, где была изначально реализована требуемая функциональность, но это все сильно усложняет и все равно не поможет - нам не нужно знать, что оценка такого-то работника 2 года назад была неверной, он с большой вероятностью с тех пор научился оценивать лучше или вообще уволился.

  • В своей статье Джоэль пишет, что периодические отвлекания на разговоры с шефом или помощь с настройкой софта другому разработчику - не проблема. Я тут полностью согласен, но это только если эта нагрузка более-менее постоянная. Если у компании начался бурный рост, и мы наняли 50 человек - на обучение сотрудников придется потратить куда больше времени, чем планировалось. Если мы запустили хорошую рекламу, и поток клиентов/вопросов увеличился в 10 раз - это чертовски сложно предсказать. Могут быть ошибки и в обратную сторону - (реальный пример) мы собирались делать хитрый импорт в TrackStudio, а потом нашли JitterBit и поняли, что будет достаточно просто вырезать лишнее.

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


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

Вывод: проблема не в оценке тех задач, о которых мы знаем, проблема в задачах о которых мы не знаем. Для точной оценки нам нужны не методы предсказания оптимизма разработчиков по уже известным задачам, а методы предсказания количества неизвестных задач. К сожалению, оценить это на основе исторической/хронологической информации нельзя, т.к. весь опыт разработчиков уже учтен в созданных задачах.
 
 
 
Макс Васенковwinzard on Ноябрь, 29, 2007 08:16 (UTC)
Макс, а какова цель, в чем смысл этих оценок? Определить, когда будет выпущена версия или сколько денег понадобится для ее выпуска?

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

По поводу разбиения на этапы - можно сделать Workflow UDF типа Float и заполнять туда оценку и часы.
Максим Крамаренкоmaximkr on Ноябрь, 29, 2007 08:23 (UTC)
Смысл - определить release date, который можно сказать клиентам. Суть поста в том, что на основе оценки истории можно определить время выполнения уже известных задач, но это мало чего говорит о release date.

Макс Васенковwinzard on Ноябрь, 29, 2007 10:15 (UTC)
Хм... Это напоминает мне мою попытку посчитать приблизительное время, которое мне потребуется для того, чтобы на велосипеде объехать вокруг Смоленска.
В принципе, я могу ехать со скоростью 30 км/ч. Мне неоднократно удавалась проехать 10 км менее, чем за 25 минут, а 20 км менее чем за 1 час. Протяженность планируемого пути - 110 км. Как бы Джоель эту задачу решил?

Хинт: я 73 километра однажды ехал часов 8, а окружную так и не проехал, потому что там автомагистраль, по которой движение велосипедистов запрещено.
(Удалённый комментарий)
Максим Крамаренкоmaximkr on Ноябрь, 29, 2007 10:35 (UTC)
С другой стороны - вот есть задачка, написать очередную версию TrackStudio, решалась уже раз 10 :-) На этот раз (4.0) нужно переделать интерфейс, тоже его уже раза 3 переписывали. Исходник - известен, сами писали. Почти ничего нового из технологий мы тут не используем.

Но бета ожидалась в августе, а нет ее до сих пор. Причины - в июле дали удачную рекламу, и по октябрь включительно интенсивно общались с новыми клиентами, до 4.0 руки вообще не доходили. Предсказать это было невозможно - мы рекламировались на тех же площадках уже лет 5 и ничего подобного не было. Потом Atlassian свою JRA-1330 закрыла с won't fix, это особенно заинтересовало иностранных клиентов. Эта бага 4.5 года висела, кто же знал что они ее этой осенью решат закрыть. Скоро русскую документацию (точнее, большой кусок от нее) выложим - никто не знает как это повлияет на продажи в России, у нас никогда полноценной русской документации не было...

Мне кажется, что оценка времени релиза - это оценка вероятности именно таких факторов, а не анализ истории прогнозов.
Max Maximus on Март, 4, 2014 02:31 (UTC)
есть нюанс. связан именно со спецификой вашей работы. Если человек"-всё-в-одном", то тогда он, как девелопер, тратит время на общение с клиентами, он же пишет документацию и так далее. Тут статья дяди не сработает.

НО...стоит только каждому делать свою работу, и тогда статья становится применимой. "Я так думаю" (с).
Маркетолог занимается рекламной компанией и планированием ресурсов (он ведь предполагает отдачу от неё), менеджер общается с клиентами, кодеры - кодят код).

Не забываем добавлять "+/-" какой- то % на форс-мажор и прочие (из опыта). Как-то так я мислю
mindflyer on Ноябрь, 29, 2007 12:54 (UTC)
А если подойти к количеству неизвестных задач так же, как к оценке трудоёмкости? Т.е. вот у вас уже было 3 версии, можно посмотреть, сколько задач было запланировано изначально и сколько появилось новых. Или ещё более общо - сколько времени планировалось на всю версию и сколько заняло реально. С точки зрения мат.статистики 3 события, конечно, мало. Но можно ведь просто глянуть даже на весь период разработки TrackStudio.
Интересно, какое время окончания разработки получилось бы для 4-ой версии.
Если для программиста получается стабильный коэффициент, то и для команды (если она не меняется) по идее должно быть аналогично.
PS: ты на каких-нить программерских форумах это дело обсуждаешь? Я иногда заглядываю на http://forum.vingrad.ru/forum/forum-273.html - там есть толковые люди.
Максим Крамаренкоmaximkr on Ноябрь, 29, 2007 14:16 (UTC)
Хм,а мы не планируем количество задач :-) Т.е. кажется что нужно что-то сделать - создаем задачу. Клиент что-то просит - создаем задачу. Т.е. скорее количество задач зависит и от процесса разработки, и от активности клиентов (которую предсказать сложно), и от внешних факторов.

Если среднее количество часов на задачу у нас получилось тут почти одинаковым во всех случаях, то количество задач в этих версиях отличалось (максимум от минимума) в 3 раза.

Конкретно FogBugz - не обсуждал, а так вообще да, пишу иногда :-)
mindflyer on Ноябрь, 29, 2007 15:02 (UTC)
> Но бета ожидалась в августе, а нет ее до сих пор.
...
> Хм,а мы не планируем количество задач :-) Т.е. кажется что нужно что-то сделать - создаем задачу. Клиент что-то просит - создаем задачу. Т.е. скорее количество задач зависит и от процесса разработки, и от активности клиентов (которую предсказать сложно), и от внешних факторов.

Но ведь оценку про август делали на основе каких-то критериев?

> Конкретно FogBugz - не обсуждал, а так вообще да, пишу иногда :-)

Где? Просто интересно, какие есть толковые форумы. Русские или английские.
Максим Крамаренкоmaximkr on Ноябрь, 30, 2007 06:23 (UTC)
Оценка про август получилась как из-за того, что нужно было до выпуска беты доделать 2 небольшие новые функции + исправить самые серьезные баги. Сейчас состояние примерно аналогичное, до реализации этих новых функций руки просто не дошли еще.

По поводу форумов - не, постоянно ничего не читаю.
Larionov "MOU" Andrewmou_ngaged on Ноябрь, 29, 2007 13:34 (UTC)
Лично для меня Джоэль не яляется авторитетом. Поэтому данное решение я бы изначально поставил под вопрос, поскольку оно не содержит скольнибудь объективной статистичекой модели. А для вынесения долгосрочных прогнозов использование методов перехода от частного к общему, не может дать нормальной оценки. То есть в любом случае полученный результат будет ни чем не лучше, чем аналитическое решение эксперта (а в большинстве случаев даже намного хуже). Однако если планировать недельные циклы, то погрешность может не так сильно повлиять на сроки.
Максим Крамаренкоmaximkr on Ноябрь, 29, 2007 19:55 (UTC)
А вот хорошая статья о том, почему с помощью ms project нельзя получить достоверную оценку времени выполнения работы, даже если оценки трудоемкости конкретных подзадач очень точные:
http://fed-nik.livejournal.com/104550.html
coderoidcoderoid on Декабрь, 16, 2007 09:25 (UTC)
Как-то трудно согласиться с вашими выводами.

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

На сколько я понимаю, для EBS предлагается считать, что зависимости сами должны учитываться разработчиками при планировании. Плюс, тулза, кажется, разрешает ставить даты начала выполнения задачи. То есть, по идее, техписатель должен будет оценить приблизительно когда он сможет приступить к своей части, плюс оценить возможные задерки со стороны программиста. Программист сделает то же самое со своей стороны (ну и EBS расширит его оценку соответственно).

>> У нас код - общий, программисты заранее не знают какие из этих задач они будут делать через месяц. Т.е. у каждого программиста есть 1-2 текущие задачи, а кто будет делать оставшиеся (и сколько это времени у них займет - разница может быть на порядок легко) - не известно.

Ну вот и зря. Это означает что никакого долгосрочного планирования вы не делаете. EBS, я так понимаю, предназначена помогать отвечать на вопрос "так когда мы ориентировочно можем закончить?". Известно, что производительность отдельных программистов может отличаться в разы, так же как и погрешность их собственных оценок. Поэтому, если вы не разбираете задачи заранее, логично что ответа на вопрос "так когда?" для ваших проектов получить не будет возможно. Либо оставшиеся задачи оценит менеджер (специалист по оценке), а EBS попробует учесть его возможную ошибку... Но не уверен, что так получится.

>> Самая главная проблема: провалы сроков происходит не из-за того, что неправильно оценили задачи, а потому, что часть задач в список вообще не попала.

А про это Джоель пишет как о Scope Creep. И предлагает добавлять буферное время "на непредвиденное" (кроме того, нужно выделить и на то, что можно предвидеть, типа проблем с настройкой среды для интеграционного тестирования и т.п.).

Общая известная проблема оценок программистов -- они всегда очень оптимистичны. То есть, та цифра, которую мы выдаём -- это зачастую "дата, до которой я точно никак не успею сделать", т.е. с "точка 0% вероятностью". Джоэль для этого и предлагает EBS -- пусть программист оценивает, как всегда, а мы потом учтём смещение его оценки.

PS: От себя могу порекомендовать интересную книжку (сам сейчас читаю) "Software Estimation: Demystifying the Black Art" Стива МакКоннелла, на русском она выходила под совсем другим названием -- "Сколько стоит программный проект".
Максим Крамаренкоmaximkr on Декабрь, 16, 2007 10:31 (UTC)
У нас затраты времени на каждую конкретную задачу я/программисты могут оценить довольно точно, ведь если мы планируем работы по 2-3 часа, то за год таких работ набирается несколько тысяч. Уверен, что при наличии 3000 записей вида: "что нужно сделать - кто делал - сколько времени заняло" у любого менеджера не будет проблем с оценкой, при этом знать оценку программиста и степень его оптимизма совершенно не обязательно.

А вот оценка времени на Scope Creep - это и есть самое интересное, "пролет" по срокам именно тут и происходит: If you see ship date getting later and later (rising curves), you’re in trouble. If it’s getting later by more than one day per day, you’re adding work faster than you’re completing work, and you’ll never be done.

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

Скажем, делает Microsoft Windows Vista. В теории, они могли бы еще первую бету объявить релизом и это бы нормально прошло. А могли устроить бета-тестирование на год и объявить грядущий SP1 всего лишь Release Candidate. Релиз - это просто наш сигнал клиентам что эту версию они могут использовать в production и мы готовы ее поддерживать и оперативно фиксить глюки.

Помните старую историю с Intel и ошибкой при выполнении операций с плавающей точкой ? Intel занала про эту ошибку, но у типичного пользователя работающего с excel шансы поймать ее были минимальные, поэтому они зарелизили процессор и дальше спокойно с этим разбирались ("исправим в следующей версии"). А пользователи посчитали ошибку критической и устроили скандал.

Или вот недавняя новость про AMD:
http://www.ixbt.com/news/all/index.shtml?09/78/16
там обнаружили проблемы в новых 4-х ядерных процессорах и решили на всякий случай отложить массовое производство, хотя руководству проблема кажется незначительной. Интересно, что после того, как стало известно о задержке процессорами AMD, Intel тоже сообщила о проблемах в своих процессорах и решила отложить их выпуск:
http://www.ixbt.com/news/all/index.shtml?09/76/38
Т.е. если бы AMD "забила" на ошибку - Intel с большой вероятностью сделала бы то же самое, а раз выпуск процессоров AMD задерживается - они могут позволить потратить себе больше времени на "доведение до ума".

Очевидно, что никакими EBS учесть это нельзя и влияют подобные факторы на сроки релиза очень значительно.
Максим Крамаренкоmaximkr on Декабрь, 19, 2007 17:06 (UTC)
А вот и подтверждение догадки, что перенос выпуска новых процессоров Intel связан с проблемами AMD:
http://www.ixbt.com/news/hard/index.shtml?09/81/74