?

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

 
 
 
Максим Крамаренкоmaximkr on Декабрь, 14, 2009 12:51 (UTC)
Дело в том, что техписатель может обеспечить среднюю производительность только если у него всегда есть работа (т.е. предыдущие участники были достаточно производительны). А если у него работы нет, то не важно что ему по ГСЧ выпало - все равно 0 за этот день будет, а значит средняя производительность будет меньше 1 задачи/в день.

Но аналитику никто работать не мешает, у него производительность = 1 задачи/день. Т.е. задачи поступают в систему быстрее, чем покидают ее, а значит должны где-то внутри системы накапливаться.


Serguey Zefirovthesz on Декабрь, 14, 2009 21:34 (UTC)
Это не отвечает на вопрос, почему у последующих этапов накапливается работа.

У разработчика аж больше ста заданий висит.
Максим Крамаренкоmaximkr on Декабрь, 15, 2009 07:34 (UTC)
100 задач у разработчика - это случайная флуктуация в этом прогоне, в какой-то момент аналитик работал хорошо (у него работы кончились раньше срока), а разработчик тормозил.

Вот результат еще одного прогона
http://www.trackstudio.com/cr/loadapp/result.txt

Картина совершенно другая (аналитик теперь сам отстает на 60 дней, главные горы задач скапливаются у тестировщика, у техписателя горы задач только в начале), а результат - тот же, уложились в 3126 дней.
Максим Крамаренкоmaximkr on Декабрь, 15, 2009 07:35 (UTC)
Неправильная ссылка, вот правильная
http://www.trackstudio.com/cr/loadapp/result2.txt