В компьютерных системах переключение контекста происходит, когда операционная система сохраняет состояние потока приложения перед остановкой этого потока и восстанавливает это состояние в другом (ранее остановленном) потоке, чтобы выполнение приложения могло продолжиться. Нагрузки, вызванные управлением процессом сохранения и восстановления состояния при переключении контекста, негативно влияют на производительность приложения и операционной системы. Данная заметка описывает, как DevOps сглаживает негативное влияние «переключения контекста» между проектами на производительность команды разработки ПО.

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

Переключение контекста чаще всего случается, когда члены команды приписаны к нескольким проектам разом. Смысл данной практики заключается в том, что логистически проще назначить людей на пересекающиеся проекты, чем пытаться выделить отдельные ресурсы на каждый проект. Кажется вполне разумным предположение, что человек, назначенный на два разных проекта, будет тратить по 50% усилий на каждый из них. Более того, если член команды занят всего на одном проекте, он будет простаивать в моменты, когда проект ожидает какого-то события: оформления бумаг, ревью и т.д.

Используя нашу компьютерную метафору, это переключение между задачами подобно концепции многопотоковости, где если по какой-то причине один из потоков блокирует процесс, остальные могут продолжать другую работу и не ждать, пока тот первый разблокируется. Если вся работа назначена первому потоку, прогресс будет гораздо медленнее. Однако если в компьютерной системе концепция многопотоковости вполне резонна, то с людьми есть проблема - далеко не всегда они распределяют усилия 50/50. Само переключение контекста тоже требует усилия, и если сотрудник тратит силы на несколько проектов сразу, продуктивность может резко упасть.

На графике, представленном выше и основанном на данных из книги «Управление качеством ПО: системное мышление», член команды с одним проектом может посвятить 100% своего времени этому проекту. Член команды с двумя проектами не достигает идеального деления 50/50. Фактически он отдает каждому из них лишь по 40%, потому что оставшееся время (грубо оценивая, 20%) он отдает переключению между контекстами. Иными словами, переключение между проектами требует дополнительной нагрузки на члена команды, ведь ему надо выяснить, на чем он остановился, что нужно сделать, как эта работа соответствует проекту, и т.д. Если член команды приписан к пяти проектам, его способность вносить вклад в каждый из них падает ниже 10%, а 80% усилий теряются на переключении между контекстами.

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

Фокус в том, что когда вы управляете программистами, переключение между задачами выполняется очень, очень, очень долго. Все дело в том, что программирование - такая деятельность, где нужно держать в голове много всего разом. Чем больше всего вы помните одновременно, тем вы продуктивнее как программист. Кодер держит в голове тысячу вещей разом: имена переменных, структуры данных, важные API, имена написанных им вспомогательных функций и даже имена папок, где лежит исходный код. Направьте программиста в отпуск на Крит на три недели - и он это все позабудет. Человеческий мозг, по-видимому, выкидывает это все из оперативной памяти и помещает на бэкапную ленту, распаковать с которой обратно занимает целую вечность.

Чем может помочь DevOps

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

Регулярная коммуникация между членами команды критична, особенно при балансировании между проектами. Без четких, структурированных каналов коммуникации проблемы, связанные с переключением контекста, рискуют превратиться в пропасть. Ежедневные летучки и использование корпоративных средств коммуникации позволяет членам команды быстро обнаружить, что переключение контекста существенным образом влияет на их способность создавать ценность для бизнеса. Трекеры дефектов помогут определить конкретных лиц, которые могли неосознанно взять слишком много работы на разных проектах.

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

Автор: Тедд Уэйтс, руководитель проекта

Оригинал: https://blog.sei.cmu.edu/post.cfm/addres[...]tal-effects-context-switching-devops-064

Перевод: Александра Родсет

Еще интересные статьи на эту тему:

• Оценка стоимости проекта на основе требований
• Гибкость и обязательства
• Варианты оценки производительности команды
• Бережливое производство программного обеспечения
• Анализ загрузки ресурсов