Как смягчить последствия Мифического Месяца Человека?

Закон Брукса: добавление рабочей силы в поздний программный проект делает это позже.

В своей книге « Нет серебряной пули» - сущность и несчастные случаи разработки программного обеспечения Фредерик Брукс определяет концепцию « Мифического человека» :

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

С 1982 года мы, безусловно, продвинулись вперед и приобрели некоторый опыт в смягчении этой проблемы. Каковы некоторые из решений, которые вы успешно применили на своей работе, чтобы добавить ресурсы в проект, не создавая больше проблем.

Что такое МММ

Сначала я хочу объяснить контекст для закона Брука. Какое предположение заставило его создать его еще в 1975 году?

Человеко-месяц - это гипотетическая единица работы, представляющая работу, выполненную одним человеком за один месяц; Закон Брукса гласит, что невозможно измерить полезную работу в человеко-месяцах.

^{источник: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

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

Это очень верно в отношении высокосвязных программных монолитов. Независимо от того, сколько разделений сделано, большой монолит требует времени, необходимого новым программистам для изучения монолита. И увеличенные накладные расходы на связь, которые будут занимать все большее количество доступного времени.

Но так ли это должно быть на самом деле? Нужно ли нам писать монолиты и сохранять каналы связи n(n − 1) / 2там, где nчисло разработчиков?

Мы знаем, что есть компании, в которых тысячи разработчиков работают над большими проектами ... и это работает. Так что должно быть что-то, что изменилось с 1975 года.

Возможность смягчения МММ

В 2015 году PuppetLabs и IT Revolution опубликовали результаты отчета о состоянии DevOps за 2015 год . В этом отчете они сосредоточились на различии между высокопроизводительными организациями и неэффективными.

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

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

Это график из этого отчета -

В то время как малоэффективные организации согласуются с предположениями о Мифическом Месяце Человека. Высокопроизводительные организации могут масштабировать число развертываний / день / dev линейно с количеством разработчиков.

Об этой находке рассказывает отличная презентация Джина Кима на DevOpsDays London 2016 .

Как это сделать

Во-первых, как стать высокопроизводительной организацией? Об этом говорится в нескольких книгах, в этом ответе недостаточно места, поэтому я просто сделаю ссылку на них.

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

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

Например, Уорд Каннингем объясняет технический долг как все то, что нам разрешено оставить нефиксированным. Это принято руководством, потому что оно всегда обещает, что будет исправлено, когда будет время.

Времени всегда не хватает, а технический долг становится все хуже и хуже.

Что это за вещи, которые вызывают технический долг?

• устаревший код
• ручная настройка сред
• ручное тестирование
• ручное развертывание

Устаревший код Как определено в книге «Эффективная работа с унаследованным кодом » Майкла Фезерса, это любой код, который не имеет автоматического тестирования.

Любые ярлыки времени используются для запуска кода; операции обременены обслуживанием этого долга навсегда. Тогда процесс развертывания становится все длиннее и длиннее.

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

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

пример

• Джон Дженкинс на Velocity 2011 : Amazon проводит 15 тыс. Развертываний в день
• Кен Экснер на AWS Summit 2015 : Amazon проводит 136 тыс. Развертываний в день

Эти две презентации показывают все, что Amazon сделала для сокращения времени, необходимого для развертывания кода в рабочей среде.

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

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

То, что я сделал (и это только субъективно), выглядит следующим образом:

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

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

Сам код написания медленнее, но при тестировании меньше опечаток / ошибок и ошибок из-за неизбежного просмотра, сделанного во время записи. Я чувствую, что общее качество кода также немного лучше, но у меня нет метрик, подтверждающих это утверждение.

Говоря исключительно с точки зрения CI, увеличение числа разработчиков, работающих над проектом, обычно приводит к увеличению числа людей, работающих в одной отрасли.

Традиционные системы CI имеют проблему масштабируемости в этом отношении: вероятность поломок / регрессий / блокировок увеличивается, замедляя скорость интеграции и предлагая меньшим командам разрываться и переходить к дочерним ветвям (т.е. дальнейшие замедления). См. Как масштабировать непрерывную интеграцию для очень больших проектов / команд? , Это соответствует концепции Мифического Месяца Человека.

Решение, которое я предлагаю в своем ответе на этот вопрос, - хорошо масштабируемая система CI позволила бы перейти к истинной CI - интеграции на основе одной ветви / соединительной линии для целых больших групп (даже с огромными размерами).

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

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

Я считаю, что все это можно рассматривать как успокаивающие эффекты концепции «Мифического человека».