?

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. Разбиение на аналитика, программиста, тестировщика и техписателя условно, это может быть и просто команда программистов, которые выполняют реализацию системы как набора связанных между собой модулей.

 
 
 
Тимур Василенкоtimur0 on Декабрь, 13, 2009 12:00 (UTC)
такая числовая иллюстрация к "теории ограничений" Голдратта получилась :-)

Пункт 4 можно попробовать оценить по порядку величины. Соображения следующие: предположим в цепочке всего двое, так что величина запаздывания будет определяться длиной самой большой серии неудач первого из них (тогда второй вынужденно простаивает). Если мне не изменяет память, в цепочке из N испытаний длина серии пропорциональна sqrt(N). Так что разбивая каждую задачу на 4 мы в среднем вдвое сокращаем время запаздывания.

По пункту 2. Если производительности работников в цепочке различаются достаточно сильно, то не столь важно, в начале или в конце цепочки находится узкое место - производительность системы будет определяться производительностью этого узкого места. Т.е. правильнее выстраивать систему так, чтобы такое узкое место было в ней одно - в предложенном примере как раз все четверо и являются узкими местами, т.е. их равная производительность и является минимальной.
Кстати, из самой архитектуры системы с одним узким местом следует, что большинство будет работать не в полную силу - их резерв производительности будет использоваться только чтобы компенсировать отставание узкого места. Т.е. если узкое место аналитики, то любое их задание вся оставшаяся цепочка выполняет влет и не добавляет своих задержек; то же относится и к писателям - предыдущая цепочка завалила их работой с запасом и теперь все зависит от писателей, которые уж точно не простаивают.
Anatoly Levenchukailev on Декабрь, 13, 2009 17:15 (UTC)
Правильно, это голдратовщина. А то тут ниже в комментах мой материал на совершенно другую тему сюда привязывают (в помянутой серии лекций я весьма еще далеко от изложения теории ограничений, хотя уже ввел "потоковую" действительность проектного менеджмента как одну из важных групп описаний).

Тут еще важно роли не путать и самих людей, а также не переоценивать жесткость процесса: http://blog.tastycupcakes.com/2009/11/project-pinwheel/
Максим Крамаренкоmaximkr on Декабрь, 13, 2009 17:48 (UTC)
Да, оно, осмысливаю книжку.

Вроде умом понимаю, но интуитивно кажется невероятным, что цепочка всего из 4-х исполнителей, простые связи, а мы получаем очереди на 50 задач и такие отклонения в сроках.