Что случилось с рисунком «Хирургическая команда» от «Мифического человека-месяца»?

Несколько лет назад, когда я читал «Мифический человек-месяц», я нашел много вещей, которые я уже знал из других источников. Однако там были и новые вещи, несмотря на то, что книга была с 1975 года. Один из них был:

Хирургическая команда

  

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

Это очень интересный образец для организации команды разработчиков программного обеспечения, но я никогда не обнаружил, что это описано в любой другой книге Software Engineering, даже не упомянутой нигде.

Почему это?

  • Была ли тогда «хирургическая команда» необычной?
  • Или он был опробован и не прошел?
    • Если да, то как это случилось?
    • Если нет, почему бы нам не увидеть, что эта модель реализована в современных проектах программного обеспечения?
159 голосов | спросил vog 6 PM00000070000003631 2017, 19:36:36

11 ответов


97

«Мифический человек-месяц» вышел в тот год, когда я начал колледж, и был, чтобы использовать нынешний народный, UUUGE! :-) Что вам нужно понять, так это различие в том, как разрабатывалось ПО THEN vs. NOW. Back In The Day (tm) в значительной степени все кодирование было сделано на бумаге сначала, затем было нажато на клавиатуру (вы догадались), перфокартные карты, затем были прочитаны, скомпилированы, связаны, выполнены, получены результаты, и процесс повторяется. Время CPU было дорогим и ограниченным ресурсом, и вы не хотели его тратить. То же самое, что и дисковое пространство, время на магнитной ленте и т. Д., Бла. Отбросить отличное время процессора на компиляции, которая привела к ошибкам (шок и ужас!), Было ... ну, отходы совершенно хорошего времени процессора. И это было в 1975 году. В то время, когда Фред Брукс разрабатывал свои идеи, то есть процессорное время середины-конца 1960-х годов было даже больше дорого, память /диск /все еще было БОЛЬШЕ ограничено, и т. д. Идея Хирургической команды заключалась в том, чтобы гарантировать, что One Super Great Rockstar Developer не нужно было тратить свое время на мирские задачи, такие как проверка кода, наложение ключей, отправка заданий, ожидание (иногда в течение нескольких часов) результатов , Разработчиком Rockstar Dude был должен быть ПИСЬМЕННЫЙ КОД. Его легион групп /клерков /младших разработчиков должен был выполнять мирские вещи.

Проблема заключалась в том, что в течение 2 лет после публикации книги Брукса основные идеи Хирургической команды ломались:

  1. Клеммы CRT и файлы дисков начали заменять пусковые устройства и карточные колоды. Компьютерное время стало менее дорогостоящим, появилось множество компьютеров, и время обработки работы резко сократилось. Когда я учился в колледже (Майами-Университет, Оксфорд, штат Огайо, класс «79 », спасибо за то, что просил) good работа оборачивалась около часа. Во время финальной недели - четыре часа, может быть, иногда шесть. (Мы соревновались за процессорное время с кучей коммерческих компаний и университетов - и коммерческие пользователи получили первый приоритет). В течение моего старшего года, когда Майами вышла из своего соглашения с «общим компьютером», у них был установлен собственный IBM 370/145 на территории кампуса, и у меня был хороший HP mini, над которым я работал, и это работало как станция RJE, мы могли бы превратить мейнфрейм рабочих мест примерно через пять минут или меньше. Теперь стоило взломать ваш код на HP, отправить его с HP на мэйнфрейм, обмануть большие пальцы /выкурить сигарету и получить выход обратно задолго до того, как вы сможете закончить проверку своего кода.

  2. Хирургическая команда имеет в качестве своей основной предпосылки мысль о том, что вы (или «руководство», бог, помогаете всем нам) могут идентифицировать Хиппинг-конструктора Rockstar Surgical. На самом деле, я сомневаюсь, что это возможно. Там есть разработчики rockstar, все это знают - исследования показали различия в производительности между лучшими и худшими разработчиками в 2000 раз, но идентифицировали этого человека , не имея при этом кода на длительный срок период времени , скорее всего, невозможно. Единственный способ узнать, является ли кто-то разработчиком рок-звезды, - это заставить их на самом деле разработать код, но если они НЕ являются разработчиком Rockstar Surgical Developer Dude, они будут заниматься такими захватывающими вещами, как проверка его кода, наложение ключей на карты и скрепляющие коробки с перфокартами вниз до отделения Job Entry, а затем стоящие рядом, ожидая результатов, чтобы они могли отследить их до г-на Rockstar Surgical Developer Dude вместо того, чтобы учиться кодировать единственный способ, который действительно работает - путем написания кода, отладки кода, и т. д. Back In The Day (tm) не было соревнований по программированию, не было переполнения стека, у вас не было компьютера, на котором вы могли бы писать код, когда бы вы этого ни захотели, не было книг «Алгоритмы для идиотов» - единственный способ научиться программированию - это пойти в школу и стать чем-то значительным, когда вам нужно немного программировать. Но программирование per se не воспринималось всерьез, а предполагалось, что люди не хотели делать . В моем первом курсе колледжа (SAN151 - «Введение в системный анализ», д-р Том Шабер, спасибо, Том :-), нам сказал инструктор, что «... нам просто пришлось столкнуться с фактом, что нам придется потратить пару лет, как программисты, прежде чем мы смогли стать системными аналитиками ». «Два года?», Подумал я. «Я ТОЛЬКО ПОЛУЧИТ ЭТО НА ДВА ГОДА?!?». Я был серьезно баммедом. К счастью, он был неправ, и с тех пор я очень много кодирую. : -)

  3. Хирургическая команда предполагает, что программисты являются относительно редким ресурсом. На самом деле это заняло еще несколько лет, но с появлением ПК в начале 80-х годов программирование стало чем-то, к чему мог прибегнуть любой выродка. Цена компьютеров начала падать, цены на инструменты разработки начали падать, и все это приветствую Turbo Pascal - по сегодняшним меркам это было не так много, но в то время это была полная Pascal IDE около 40 баксов, что было абсолютно безумным! Теперь ANYBODY может войти в программирование - если бы вы могли позволить себе компьютер, и когда IBM решила поставить PCjr (да, мой первый компьютер был одним изКрупнейшие ошибки IBM :-) в продаже около 500 долларов, чтобы избавиться от этих индюков, повсюду безнаказанные гики повсюду пропускали свои арендные платежи в течение месяца («Да, я знаю, но я ... хм ... сломал мой uuvula и должен был пройти операцию и ... э-э ... да, на следующей неделе, никаких проблем, спасибо, человек ...) и высасывал их по ценам продажи огня. Затем потратил больше, чем мы заплатили за компьютер, («Да, мужик, на следующей неделе, наверняка, наверное ...»: -).

Мне очень грустно, что даже сегодня, если вы спрашиваете людей, читали ли они «Мифический человек-месяц» или понимали его главный урок («Добавление ресурсов к позднему проекту делает это позже»), они дают вы пустым взглядом - и затем приступайте к тем же ошибкам, которые были сделаны All These Years Ago во время разработки OS /360. Все старое новое снова ...: -}

ответил Bob Jarvis 7 AM00000060000003931 2017, 06:36:39
87

Есть некоторые аспекты этой концепции, которые иногда реализуются , существуют другие аспекты, которые избегаются .

Сохранение небольших команд является одной из основных особенностей Agile-методов, но также практикуется вне Agile.

Кросс-функциональные команды также являются основным продуктом Agile, но также и вне Agile.

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

Точно так же роль системного администратора (не являющегося частью хирургической команды Миллса, но частью типичной кросс-функциональной команды последних лет) устаревает такими понятиями, как DevOps (поглощение роли Sysadmin в роли Software-as-a-Service, Infrastructure-as-a-Service и Utility Computing (что делает роль Sysadmin «чужой проблемой») или Infrastructure-as-Code (превращение системного администрирования в Software Engineering) .

Один из аспектов, который мы пытаемся избежать сегодня, заключается в том, что не более двух человек понимают систему. Гарантируется, что только хирург полностью поймет систему, второй пилот может или не может. Это дает коэффициент для шины между 1 и 2. Если хирург заболеет, проект мертв. Период. Гибкий ответ на это - это способность коллективного кода, которая представляет собой точную противоположность этой модели: nobody несет исключительную ответственность за любую часть системы , Вместо этого все отвечает за все как группу .

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

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

ответил Jörg W Mittag 6 PM00000080000005931 2017, 20:56:59
19

Раньше университетское образование было чем-то уникальным, и инженеры были среди избранных. Компьютеры были дорогими, а команды работали над проектами с определенным бизнесом RoI. Они были не очень распространены.

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

Экономия соотношения поддержки: 8: 2 больше не имеет смысла. Инженеры должны быть их собственной поддержкой. Современный человек с достаточным образованием и навыками, чтобы быть эффективными в команде разработчиков, слишком дорог, чтобы не делать своего собственного развития.

(Связанный с экономической терминологией термин «болезнь затрат сектора услуг».)

ответил Jon Watte 6 PM00000080000004631 2017, 20:27:46
13

Эти шаблоны звучат для меня как программирование Mob:

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

Из http://codebetter.com/marcushammarberg/2013/08/06 /моб-программирование /

  

Основная концепция программирования толпы проста: вся команда работает   как команда вместе по одной задаче в то время. То есть: одна команда - одна   (активная) клавиатура - один экран (проектор, конечно). Это очень похоже на   делая программирование пары в полной команде.

Смотрите здесь: https://www.youtube.com/watch?v= dVqUcNKVbYg

ответил Chococroc 6 PM000000110000003031 2017, 23:19:30
12

Эта командная модель снова упоминается в Rapid Development - Taming Wild Software Schedules от Steve McConnell на стр. 305. Там ее называют командой главного программиста.

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

Другие ссылки:

Бейкер, Ф. Терри. «Главный программист команды управления производственным программированием», IBM Systems Journal, vol. 11, вып. 1, 1972, pp. 56-73.

Бейкер, Ф. Терри и Харлан Д. Миллс. «Главные команды программистов». Datamation, Volume 19, Number 12 (December 1973), pp. 58-61.

ответил Matt Everson 6 PM000000110000000431 2017, 23:24:04
8

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

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

Подумайте о правилах двух пиццы Безоса. Это ваша самоорганизующаяся хирургическая команда прямо там.

ответил RibaldEddie 6 PM00000090000004231 2017, 21:36:42
6

Из HP была опубликована статья, которая предложила нечто подобное:

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

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

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

ответил Charles Merriam 6 PM00000080000001631 2017, 20:36:16
2

Интересно, сколько из необходимости хирургической команды стало излишним из-за роста Интернета, интегрированные среды разработки и комплекты для разработки программного обеспечения , которые могут функциональность Фред Брукс, приписываемая хирургической команде, в том числе:

  • Хирург: программист
  • Со-пилот: пары программистов , сотрудники, сетевые сообщества, такие как StackExchange или IRC
  • Администратор: роль, которую обычно выполняет программное обеспечение менеджер проекта
  • Редактор: IDE интегрируют генераторы документации, такие как Javadoc или Doxygen; документация из комплектов разработки программного обеспечения
  • Секретарь: клиент электронной почты, инструменты управления проектами, такие как трекеры и запросы на запросы, чаты компаний и списки рассылки.
  • Программный клерк: IDE хранит информацию о проекте, с добавленной способностью к рефакторингу; документация и примеры из комплектов разработки программного обеспечения
  • Инструменты: все сообщество с открытым исходным кодом
  • Тестер: на начальном этапе, тестовые комплекты и библиотеки тестирования. Но, конечно, для производственного кода необходим отдельный процесс контроля качества.
  • Адвокат языка: онлайн-документация, StackExchange
ответил Gaurav 9 AM00000090000001131 2017, 09:53:11
1

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

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

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

ответил JeffO 8 PM00000040000002531 2017, 16:47:25
0

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

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

ответил Mike Ounsworth 6 PM00000090000005231 2017, 21:15:52
0

Как программист, который часто заполнял роли DevOps и Build Master, я чувствовал, что часто оказываюсь в том, что я являюсь хирургической командой .. err ... парень в команде. В качестве мастера сборки я просмотрел весь код и был первой строкой, когда она не удалась. Зачастую я бы сам это исправил. Я часто пишу эти системы показателей и измеряю горячие точки в коде, части, которые чаще всего терпят неудачу, которые привлекали самые сообщения об ошибках и т. Д. Я не только опубликовал результаты в команде, я бы тоже их анализировал, изгиб, вызвавший проблемы и предлагаемые решения и архитектурные изменения для решения этой проблемы.

Как DevOps, я бы автоматизировал огромные области процесса и накладных расходов. Я бы исследовал технологии и инструменты, которые облегчили бы жизнь команде, всей команде, разработчикам, тестировщикам QA, IT-операциям, вплоть до руководства. Моя роль заключалась в том, чтобы понять процесс, да; но, не сводя глаз с команды (реальных людей), используя (переживая) этот процесс, я смог отделить его до точки, чтобы сделать его полностью прозрачным, все еще получая полезную информацию, чтобы получить объективное представление об этом когда-либо неуловимой «большой картины».

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

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

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132