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

Поскольку этот сайт для программистов, для разминки я предложу программистскую задачку.

Предположим, что у вас есть две отдельных вычислительных задачи (A и B), которые нужно выполнить. Каждая задача требует для полного выполнения 10 секунд процессорного времени. В вашем распоряжении есть один процессор, и для упрощения будем считать, что других задач в очереди нет.

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

Какой вариант вы выберете? Первая реакция у большинства людей: многозадачность лучше. В обоих случаях для получения обоих ответов придётся ждать 20 секунд. Но давайте подумаем, сколько времени придётся ждать каждого ответа по отдельности.

В обоих случаях от момента начала вычислений до получения результата B пройдёт 20 секунд. Но посмотрите на задачу A. При использовании многозадачности с момента начала вычислений до получения её результата прошло 19 секунд... тогда как при последовательной обработке результат был готов через 10.

Иными словами, в этом удачно притянутом за уши примере среднее время меньше (15 секунд вместо 19.5) при последовательной обработке, чем при многозадачности. (Вообще-то этот пример не так уж сильно притянут -- он основан на реальной проблеме, которую Джареду пришлось решать на работе).

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

Последовательно = 15.25 секунд
Параллельно = 28.75 секунд

Теперь... ладно, не смейтесь, я знаю, что это глупость ... что если переключения занимают целую минуту?

Последовательно = 45 секунд
Параллельно = почти 19 минут!

Чем дольше переключение между задачами, тем больше потери времени от многозадачности.

Само по себе это не слишком революционная мысль, не правда ли? Скоро я стану получить злые письма от деятелей, обвиняющих меня в том, что я "против" многозадачности. Будут ехидно спрашивать "что, хочется обратно во времена DOS, чтобы обязательно выходить из WordPerfect, прежде чем запустить Lotus 1-2-3?"

Но я не про это. Я всего лишь хочу, чтобы вы согласились, что при данном примере:

а) последовательная обработка обеспечивает в среднем более быстрое получение результатов, и

б) чем дольше переключение между задачами, тем больше потери времени от многозадачности.

Хорошо, возвращаемся к более интересной теме управления людьми, а не процессорами. Особенность тут в том, что у программистов переключение между задачами происходит очень, очень, очень долго. Потому что это такое занятие, при котором приходится держать в голове много всякой всячины одновременно. Чем больше, тем быстрее движется работа. Программисту, работающему в полную силу, приходится удерживать в голове миллион разных вещей: названия переменных, структур данных, системных вызовов и вспомогательных функций, которые были ранее написаны и часто используются, даже название подкаталога, где живут исходники. Если послать этого программиста на три недели в отпуск на остров Крит, то он всё это забудет. Человеческий мозг, похоже, при первой возможности высвобождает оперативную память, сбрасывая её содержимое на ленту, откуда всё это потом очень долго доставать.

Насколько долго? Например, моя компания недавно на три недели бросила всё (а именно разработку программного продукта под кодовым названием CityDesk), чтобы выручить клиента, которому внезапно потребовалось наша помощь. Когда мы вернулись в контору, потребовалась почти неделя, чтобы набрать обычную скорость работы над CityDesk.

Вы лично никогда не замечали, что даешь человеку задание, и он его отлично выполняет, но даёшь два задания одновременно, и результат гораздо хуже? Он либо делает одну работу и забывает про другую, либо пытается делать обе, но настолько медленно, что улитки обгоняют. Это потому, что переключение между программистскими задачами происходит медленно. Если у меня на столе два проекта одновременно, то переключение отнимает часов шесть. При восьмичасовом рабочем дне остаётся два часа производительного времени. Негусто.

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

Джоэл Сполски, перевод Дмитрия Майорова. 12 февраля 2001

Оригинал: Human Task Switches Considered Harmful

... А Дейкстра прав!..

На счёт двух задачь и процессора немного не точно. Переключение процессов позволяет утилизировать простои процессора, т.к. редко какая задача требует 100% загрузки (более 90% десктопный процессор простаивает). Две интенсивные по вычислениям задачи распараллеливать на тредах глупо. Обычно решается пулом тредов, где количество тредов в пуле равно количеству ядер/процессоров в системе. В итоге получаем максимальную производительность на интенсивных, не зависимых друг от друга задачах.

На счёт менеджмента, да, заставлять программиста вести два проекта одновременно есть абсолютная глупость. Хотя если проекты просты и умещаются сразу в голове, то всё получиться, даже интересней 

где это ты такие простые проекты нашёл? лабораторки студентам, что ли?   
Полностью согласен с положением в статьи. Сам в ситуации, когда  начали проект на Delphi и надо было сделать корректировки к уже немного подзабытому проекту на PHP. Это такая пытка! Хорошо, хоть совсем недолго такое продолжалось...   

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

Или доверять своему team lead'у.

Попытался девелопить два проекта одновременно. В результате не хочется работать ни над одним.   

Согласен в приципе со статьей. Сам страдаю тем, что веду много проектов одновременно. Буду перестраиваться.

А мне кажется, что описанныя ситуация очень идеализированна. Согласен с Sardar'ом.
Всё очень сильно зависит от проектов.

В случае однотипных проектов (таких, например, как ведение нескольких кастомизаций), никакого вреда от работы на два-три фронта нет. А проектам польза.

smartov, ну так это не недостаток процесса работы с несколькими проектами, а неудачный configuration management данного проекта. У нас вот все лежит в одной системе (в данном случае - ClearCase), и структура кода организована таким образом, что при сборке билдов кастомизационные ветки накатываются поверх ядра. И никаких особенных проблем мы не испытываем. Изменения вносятся только один раз.

batigoal, я просто привёл пример того, что даже мелочь может привести к тому, что мы у себя между собой называем "multiple concurrent tasks", имея в виду именно сабж этой темы.
Даже мелочь к этому может привести, и это плохо. Наши американские манагеры никак до этого не допрут. И мне кажется им просто нравится прочесс "все в срачке" - когда все бегают как с загаженными штанами с криками "гипс снимают, клиент уезджает!"...
Так что паралельные таски это самый крайний случай и должны применяться как можно реже вообще в принципе в любом случае. Один человек не должен правой ногой красить забор а левой рукой готовить суп.

А как это удалось достичь?

Структура папок одинаковая, при сборке преимущество имеют файлы кастомизаций. Т.е. файлы core заменяются одноименными файлами кастомизации, если таковые существуют.

Перенос кастомизаций на следующую версию ядра производится при участии всех команд custom-проектов. Процедура мёржа, как правило, тривиальна.

Ой. У меня постоянно примерно 5-6 задач... И все срочные!   
Сейчас вот 3, но это временное явление   

Одной никогда не бывало, я это даже представить не могу...   

Всё это ерунда, что одна задача, что десять. Просто некоторые люди неспособны выполнить даже одну. Но кое в чём я согласен. Как говорил учитель, три дня без программирования и жизнь теряет смысл (молчаливая пустота).