English Version

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


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

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

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

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

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

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

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

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

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

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

*      *      *

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

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

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

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