?

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)
Тут интереснее не отклонение в процентах, а разброс результатов по сравнению с ожидаемым разбросом в случае независимых задач.

А если задач будет меньше, ошибки в оценках времени отдельных будут больше, да еще точное количество задач заранее не известно, то предсказать время завершения проекта будет гораздо труднее.
Тимур Василенко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 задач и такие отклонения в сроках.
Serguey Zefirovthesz on Декабрь, 13, 2009 12:32 (UTC)
А этот результат, прошу прощения, не связан ли с проблемами генератора случайных чисел?
Максим Крамаренкоmaximkr on Декабрь, 13, 2009 18:21 (UTC)
А как эту версию можно подтвердить или опровергнуть ?
Serguey Zefirovthesz on Декабрь, 13, 2009 19:16 (UTC)
Почему у последующих этапов накапливается работа?

Это меня смущает больше всего.
Максим Крамаренко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
Nick Knutovknutov on Декабрь, 13, 2009 15:40 (UTC)
Очень интересно. А как считались все эти проценты?
Максим Крамаренкоmaximkr on Декабрь, 13, 2009 17:50 (UTC)
Методом Монте-Карло :-) Т.е. прогонял соот. программу 10 тысяч раз и смотрел сколько раз они уложатся в требуемые сроки.

Nick Knutovknutov on Декабрь, 13, 2009 18:10 (UTC)
Почитал гугл, вспомнил тервер за третий курс.

А не планируется ли написание маленькой програмки, который бы можно было задавать все эти цифры типа количество тасков, среднего времени на таск и цепочку людей и чтобы она красиво считала вероятности? :)
Максим Крамаренкоmaximkr on Декабрь, 13, 2009 18:16 (UTC)
Что-то такое я и сделал, правда исправление параметров - через изменение исходника и перекомпиляцию.
fukanchikfukanchik on Декабрь, 13, 2009 16:38 (UTC)
Это после просмотра лекции Левенчука?

И я не уверен что Ваш подход реалистичен. Т.е. мне кажется что математически там не всё гладко, но точно ничего сказать не могу - не хватает опыта работы с тервером.

Ага! Мне не нравится что там вся выполненная работа передаётся только в конце дня скопом. Т.е. если программист сделал 2 задачи - то тестировщик их получит только завтра и сразу обе. Вот в строительных примерах Левенчука это видимо не так... но не уверен.

>>Дробление задач увеличивает производительность работы команды. Например, разобьем тот же объем работ на 12000 задач (x4), соответственно максимальная производительность работника увеличится с 2 до 8 задач в день (средняя - с 1 до 4 задач в день).

В выводе работы программы есть куча моментов когда например сегодня девелопер выполняет 0 задач а тестировщик простаивает сегодня и завтра. очевидно что при увеличении величины performance вероятность выполнить 0 задач в какой-то день будет падать. т.е если сейчас там 1/3 то при 8 будет 1/8 т.е. вероятность недополучения работы тестировщиком снизится. с одной стороны интуитивно это понятно - если мы дробим работу, то вероятность выполнить её за один день возрастает. С другой стороны меня смущает что это выглядит как если бы мы считали интеграл суммами с данной дискретизацией, то получили бы величину Х, а если увеличим дискретизацию вдвое, получим 2*X, и т.д....
Anatoly Levenchukailev on Декабрь, 13, 2009 17:17 (UTC)
Это не после просмотра той лекции. Лекция была с материалом, который позволяет восстановить позицию, из которой такого сорта тексты пишутся -- проектное управление, логистика. А тут уже описывается, какие проблемы возникают при работе в этой потоковой действительности. Я это планирую рассказывать, но существенно позднее.
Максим Крамаренкоmaximkr on Декабрь, 13, 2009 17:54 (UTC)
Нет, как раз в данном примере работа передается не в конце дня, с сразу. Т.е. если аналитик сегодня сделал 1 задачу, то ее может сегодня же написать разработчик, ее можем сегодня же протестировать и документировать.

Строчки в выводе программы - это результаты на конец дня.
AHTOHvorobiev on Декабрь, 13, 2009 19:29 (UTC)
Вообще говоря картинка еще хуже.
С запозданием прочитал пост, сравнил с опытом участия в больших проектах. Предлагаемая модель разработки чрезвычайно оптимистична. В ней предполагается, тестировщик делает задачу и все. В реальной же жизни происходит следующее: в некотором проценте задач находятся ошибки и задачи должны быть переделаны.

Для примера рассмотрим ситуацию, когда аналитик и разработчик работают с эффективностью 0,9. Т.е. делают ошибки в 10% функционала. Тогда 10% задач после цикла тестирования будут возвращаться на предыдущие этапы, причем повторное исправление может тоже содержать ошибки. Получим бесконечную геометрическую прогрессию со знаменателем 0,1 в итоге имеем ее сумму 3000/(1-0,1)~3334 т.е. будет 334 ошибки проектирования с которыми должен заново разобраться аналитик.

После этого еще раз построим прогрессию для программиста получим 3705 задач, что даст нам 23% увеличение проекта за счет ошибок. Так что сроки еще отодвинуться. И это при относительно хорошем качестве кода.

Если же качество работы снизить до 0,7, то на тестировщика свалится более чем в два раза больше задач чем было функций в изначальном проекте. Даже если он будет делать всегда 2 задачи в день, то не справится. Кстати, если предположить что тестировщик и техписатель тоже работают со своими коэффициентами надежности, то можно попробовать подсчитать сколько на выходе будет ошибок.
(Анонимно) on Декабрь, 28, 2009 12:33 (UTC)
Re: Вообще говоря картинка еще хуже.
Про заказчика забыли.
AHTOHvorobiev on Декабрь, 28, 2009 13:14 (UTC)
Re: Вообще говоря картинка еще хуже.
Роль изменчивости требований заказчика здесь играет качество работы аналитика.