Заложники Длинных Очередей


Автор: Александр Якима.

Что общего между очередями и умными людьми (и не только), ставшими заложниками неэффективного процесса? Очень много общего!

Начнем с самих очередей и их поведения. Без излишних математических выкладок понятно, что длинная очередь (чего-либо) - это в большинстве случаев большая неопределенность. Если я нахожусь в короткой очереди, например, третий по счету на регистрацию пассажиров авиарейса и если в среднем регистрация одного пассажира занимает 3 минуты, то с довольно хорошей точностью можно сказать, что минут через 10 и меня обслужат.

Если я последний в очереди, состоящей из 100 человек - ситуация иная. Сказать с надежностью, что это будет 300 минут нельзя, вариация может быть огромна, процесс может легко отнять в два раза больше времени. Кто-то релоцируется и у него 5 чемоданов и он не знал, что за перевес придется доплатить и кроме полезного времени еще минимум 5 минут повозмущается по поводу обираловки. Кто-то летит далеко с многими пересадками и оператору придется позвонить в центральный офис, чтобы узнать, нужна ли гражданину, скажем, Индии транзитная виза в Британию, если он летит через Хитроу. Кто-то не знал, что даже грудному ребенку нужно покупать билет и т.д. Задержка по времени может легко составить час а то и больше...

Где в разработке ПО появляются очереди? Повсюду. Если рассматривать работу над проектом как процесс продвижения требований от некого определенного состояния до полной имплементации, то легко заметить, что между различными этапами возникает целый ряд очередей. Так, в классическом пофазовом процессе большая очередь только что определенных требований (например, в виде SRS - Software Requirements Specification) направляется к следующему шагу - разработке архитектуры. Затем, когда будет определена архитектура (опять же, для всего продукта целиком в случае такого процесса), эта очередь вся целиком движется дальше - к этапу разработки. Потом точно так же - на тестирование.

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

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

Наверняка читатель уже суть проблемы прочувствовал и задается совершенно естественным вопросом, как бороться с длинными очередями. Некоторые точно уже догадались - бороться нужно самым банальным способом: ограничивать длину очереди! Это выглядит довольно просто и на это зиждется целый ряд методологий, берущих свое историческое или логическое начало в Lean: взять только сравнительно малую часть требований и "провести" их сквозь весь процесс, начиная от более детальной проработки самих требований и заканчивая тестированием. Потом взять следующую небольшую часть и так далее, пока не исчерпается все множество. После первого же подобного "цикла" можно достаточно уверенно (самое главное, уже базируясь на опыте) делать предположения об остальных подобного размера "пакетах".

Не бывает так, чтобы в Lean-проектах были одни умники, а в традиционных проектных моделях были бы профессионалы чем-то хуже. Просто, к огромному сожалению, даже отличные специалисты могут здорово пострадать (и страдают) от беспощадной "мести" длинных очередей.

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

*      *      *

Добавлено 01-05-2012.

Важно действительно понимать "масштаб бедствия". На диаграмме можно увидеть "скорость", с которой наростает разброс времени обслуживания очереди с ростом ее длины. Диаграмма показывает функции распределения плотности вероятности для очередей с длинами от 5 до 100 элементов. Для простоты сравнения все они "отцентрированы".

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

Для интересующегося математическим обоснованием читателя заметим, что вышеизложенное следует из Центральной Предельной Теоремы, которая также указывает, что "разброс" (среднеквадратическое отклонение) растет пропорционально корню квадратному из n, т. е. длины очереди. Также, вероятность того, что время примет среднее ожидаемое значение, быстро убывает с ростом n (обратно пропорционально корню из n). Вряд ли наш великий соотечественник, Александр Михайлович Ляпунов, подозревал, что так "отожжет" в IT.   

11 comments:

  1. "Без излишних математических выкладок понятно, что длинная очередь (чего-либо) - это в большинстве случаев большая неопределенность."

    В случае с регистрацией как раз всё наоборот. Чем длиннее очередь на регистрацию, тем больше определённость. Регистрация пассажиров (в отличие от разработки ПО) - стабильный повторяющийся процесс, подчиняющийся какому-то распределению вероятности с вполне вычисляемыми статистически параметрами. Чем длиннее очередь, тем больше нивелируются все отклонения.

    ReplyDelete
  2. А вот теперь и прибегнем к математике. Дисперсия суммы независимых случайных величин (чистое время обслуживания каждого пассажира, без времени в очереди) равна сумме дисперсий. Это означает, что "разброс" суммарного распределения по времени тем больше, чем длиннее очередь. Greesha, ваша предпосылка о "повторяемости" процесса верна, но о времени обслуживания всей очереди - нет.

    ReplyDelete
  3. Отличная метафора! На мой взгляд, её основная прелесть в том, что в большинстве случаев мы не знаем никого из образовавшейся очереди. Каждый стоящий в ней пассажир — потенциальная угроза для спрогнозированного срока, как, собственно и каждая проектная фаза при разработке нового продукта. С другой стороны, если Вы, скажем, детский футбольный тренер и в который раз «загружаете» свою команду на рейс, все возможные проблемы вам отлично известны и сроки прогнозируемы довольно точно. Здесь вполне сойдёт и каскадная модель — можно грузить всех скопом.

    ReplyDelete
  4. И всё же.. Я поддержу Гришу.
    На основании большого количества данных (сотни тысяч и даже, быть может, миллионов пассажиров, прошедших через кассы) можно сказать, что средняя продолжительность "обработки" одного пассажира - Х минут. И, соответственно, чем больше количество пассажиров в очереди, тем больше вероятность, что x (средняя продолжительность "обработки" одного пассажира именно в вашей очереди) будет похоже на X, и тем более похожим на правду становится выражение - x*N.
    Ведь именно так получилось, что стала "известна" средняя скорость движения пешехода, велосипедиста и машины в городе. И именно эти данные помогают gps-навигаторам и гугл-картам определять, через сколько вы будете в заданной точке. И чем больше расстояние, тем обычно (проверено на собственном опыте) точнее расчитывается время прибытия.

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

    ReplyDelete
  5. Коллеги, Вы путаете среднее время обработки пассажира без ожидания (!) с величиной совершенно иной природы - временем ожидания последнего пассажира.

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

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

    ReplyDelete
  6. Но, опять же, крайне благодарен за комментарии.

    Любую идею, порождающую вопросы, нужно разложить по полочкам. Чувствую, что это следует сделать в отдельном посте, вопрос важный...

    ReplyDelete
  7. "В среднем регистрация одного пассажира занимает 3 минуты" - где здесь сказано "без ожидания"? :)

    "Вариация" не накапливается. Если матожидание времени обслуживания 3 минуты, то в нём уже учтены все отклонения как в отрицательную (пять чемоданов), так и в положительную сторону (семья из трёх человек обслуживается быстрее, чем три отдельных человека). Тогда чем длиннее очередь, тем точнее можно предсказать общее время стояния в очереди.

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

    ReplyDelete
  8. ""Вариация" не накапливается" - это откуда вообще?

    ReplyDelete
  9. 2 Greesha.

    Если после этого комментария все еще будет непонятно - это уже не ко мне, сорри...

    Задаем простейшее распределение вероятности для обработки одного пассажира (который ничего не ждет): он будет обработан за 3 минуты с вероятностью 50%, за 2 минуты с вероятностью 25% и за 4 минуты с вероятностью 25% (выбрано всего три значения для простоты выкладок). Представим, что у нас очередь из двух (независимых друг от друга) пассажиров. Итак, вопрос, как оказывается, не для простаков: какова вероятность того, что очередь из двух человек займет 6 минут (среднее значение)?

    Очень легко увидеть, что вероятность равна всего 37,5% (= 0,5*0,5 + 0,25*0,25 + 0,25*0,25). То есть, вероятность отклонения от среднего уже становится 62,5%. До этого она была 50%.

    ReplyDelete
  10. Я понял, в чём разногласие. Ты (можно на ты?) под надёжной своевременной поставкой, видимо, понимаешь подход "точно вовремя", а я, как представитель "традиционных моделей" понимаю подход "не позже".

    Пример с распределением хорош. Поскольку распределение у нас дискретное, то для очереди из двух человек возможны следующие значения общего времени обслуживания: 4, 5, 6, 7, 8 минут. Соответствующие вероятности равны: 0.0625, 0.25, 0.375, 0.25, 0.625

    Да, вероятность попасть _ровно_ в 6 минут равна 0.375, но вероятность _уложиться_ в эти 6 минут равна уже 0.6875.

    ReplyDelete
  11. Да, конечно, можно "на ты".

    Greesha, так вот ты как раз всегда один шаг опускаешь в самом конце. Ничего же не изменится. В случае с очередью из двух элементов, как ты сам правильно указал, вероятность "успеть не позже дэдлайна" 68,75%. Но в случае одноэлементной очереди та же величина (т.е., вероятность успеть не позже дэдлайна) будет 75%.

    :)

    ReplyDelete

 
Powered by Blogger