?

Log in

No account? Create an account
 
 
13 Декабрь 2009 @ 14:14
Про планирование связанных задач и закон больших чисел - 2  
Шансы на то, что вышеупомянутая четверка уложится в 3000 дней - примерно 0.01%, т.е. 1 из 10 тысяч.
Шансы уложиться в 3005 дней - порядка 0.02%. Даже шансы уложиться в 3100 дней относительно невелики - порядка 37%.

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


Демо-программа:
http://www.trackstudio.com/cr/loadapp/Load.java

В result.txt показан результат тестового прогона, видна длина очереди незавершенных задач для каждого работника по дням.
http://www.trackstudio.com/cr/loadapp/result.txt

Например, строка
===
Day: 243 Analyst: 2758 Developer: 20 Tester: 16 Writer: 7
==
означает, что на 243 день аналитику осталось проанализировать 2758 задач, у разработчика висит 20 задач, у тестировщика - 16, а у техписателя - 7.

Что интересно:

1) Аналитик закончил работу на 2970 день и уложился в срок, в то время как техписатель сделал последнюю задачу только на 3121 день.

2) Задачи для работников, находящихся в конце списка, поступают волнами. Например, в районе 300-го дня у техписателя в очереди 15 задач, 523 день - 30 задач, 815 день - 33 задачи, ..., 2531 - 53 задачи. При этом между этими пиками есть длительные периоды времени, когда работы у техписателя нет вообще.
Поэтому запас производительности у работников в конце цепочки должна быть больше, чем у работающих в начале.
Чем цепочка связанных задач длиннее - тем сильнее проявляется этот эффект.

3) Предположим, программист у нас хороший, не лодырь - если в какой-то день у него кончаются задачи, а он может сделать больше, то он сам находит задачи и делает их по своему усмотрению. Но т.к. эти дополнительные функции тоже нужно протестировать и описать, то они создают дополнительную нагрузку на (уже перегруженных!) тестировщика и техписателя, поэтому шансы завершить реализацию исходных 3000 задач за 3100 дней падают с 37% до 22%. При этом время нахождения нужных задач в очереди на тестирование и документирование растет. Стремление загрузить всех людей на 100% и ненужная инициатива самих людей - зло.

4) Дробление задач увеличивает производительность работы команды. Например, разобьем тот же объем работ на 12000 задач (x4), соответственно максимальная производительность работника увеличится с 2 до 8 задач в день (средняя - с 1 до 4 задач в день). Шансы на завершение работы за 3100 дней в этом случае вырастают с 37 до 67%.
При этом дополнительные затраты времени аналитика или программиста на переключение между задачами не снижают производительность команды, т.к. они находятся в начале цепочки. "Оптимизация" загрузки людей в начале цепочки путем создания больших задач - зло.

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

 
 
 
Сергей Слесаревsergeyslesarev on Декабрь, 13, 2009 11:57 (UTC)
Зато шансы уложиться в 3300 дней должны быть очень велики - а это всего 10% от общего срока проекта. А погрешность при оценке производительности уж в любом случае больше 10% :)
Максим Крамаренкоmaximkr on Декабрь, 13, 2009 18:20 (UTC)
Тут интереснее не отклонение в процентах, а разброс результатов по сравнению с ожидаемым разбросом в случае независимых задач.

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