Проект разбиваем на такски 2-4-8-12 часов

Не надо путать длительность и трудозатраты. Программисты могут сказать только трудозатраты, да и то идеальные.

А уже в длительности можно учесть, что норма выработки прогера реально 70-80%, что есть риски на некоторых тасках а для некоторых тасков надо ждать клиента и тп

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

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

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

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

А если бы программист полгода писал программу, потом бы 1 раз компилировал, запускал ее и смотрел – работает или нет ? Какие бы вывод он мог сделать после такого прогона ? Что в следующий раз нужно сделать в 3 раза больше проверок на нулевой указатель ?

Evidence-based scheduling отвечает на вопрос “когда разработчики закончат все внесенные в систему задачу?”, но не “когда мы сможем выпустить релиз?”.

Тут есть важный момент – разработчики же видят свои оценки и реальные результаты. Если у разработчика средняя задача занимает 2 часа, то за месяц у него будет ~80 задач. За год – почти 1000.

Если он по каждой будет видеть свою первоначальную оценку и сколько времени оно заняло в реальности – он через год прогнозы не хуже багтрекера сможет выдавать и корректировать свои “ощущения”. Если у менеджера 10 таких работников – менеджер научится еще раньше.

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

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

я прочитал заметку, хорошо написано. Мне кажется тут происходит некоторое смешение понятий.

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

Если в процессе увольняется или заболевает разработчик – это не новая задача, это форс-мажор (если он один на проекте).

Если клиент просит включить еще одну-две фичи в плановый релиз и вы соглашаетесь – это проблема руководства. Нужно либо клиенту отказать, либо решить его проблему другим способом.

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

Мы разбиваем проект на задачи даже по 2-3 часа, но на реальность сроков это не влияет никак.

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

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

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

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

Насколько понял, идея заключается в следующем:
Существует несколько буферов, играющих роль амортизаторов по времени.
Задачи на критическом пути календарного плана подкрепляются буффером по времени. Каждая ветка задач, которая “кормит” критический путь также имеет свой буффер. Кроме того, существуют несколько других буферов, которые “прикрывают” другие проблемы: недоступность ресурсов на момент старта выполнения задач и т.п.
Разработчики подхода верят в обратное относительно мнениям, представленным здесь в комментах: Специалист всегда накидывает больше времени на выполнение задачи, учитывая всевозможные риски и опыт прошлых неудач.
Поэтому …
1. Узнаем оценку специалиста.
2. Делим! ее на коефициент и заносим в план разработчику. Соответсвенно время на выполнение становится меньше, чем изначально оценили.
3. В “своем” плане к этой задаче добавляем буфер времени + другие буферы.
4. Контролируем задачи и процент использования резервных буферов.

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

Также, деление оценочного времени на опр. коефициент “давит” на исполнителей и мотивирует выполнить работу в максимально короткие сроки (не дает расслабляться).

Сам подход не использовал, но планирую поэксперементировать. Чувствую, что есть в этом что то здравое.

Кроме того, имею несколько вопросов:
1. Как продать такое клиенту?
2. Каким образом расчитывать счета на оплату услуг (например, на почасовую оплату труда разработчиков ПО в outsourcing проектах)? – Подозреваю, что фактическое время, затраченное на выполненных работ. Но нужно обдумать.
3. А стоит ли?

Р.

З.Ы. Читал, в основном, здесь: http://www.prochain.com/resource_center/articles/intro_to_critical_chain.asp