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


164

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

Хирургическая бригада

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

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

Почему это?

  • Была ли «Хирургическая бригада» еще тогда необычной?
  • Или это было опробовано и провалилось?
    • Если так, как это потерпело неудачу?
    • Если нет, то почему мы не видим этот шаблон в современных программных проектах?

12
Я бы сказал, что это может дать только основанные на мнении ответы. Моё мнение о том, что ни один «программист» не хочет, чтобы его воспринимали как «поддерживающую» роль. Они хотят, чтобы их считали равными всем остальным в команде. Это может быть связано с тем, что большинство разработчиков программного обеспечения чрезвычайно молоды. В большинстве команд нет никого, кто мог бы претендовать на старшинство и считаться «хирургом» команды.
Euphoric

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

9
@Euphoric Не забывайте, что некоторые из менеджеров, которые обманывают себя, думают, что у них уже есть программист-супер-супер-гуру-звездный хирург, так зачем вообще нанимать всех этих поддерживающих крестьян? Я видел свою долю пользователей, которые не продемонстрировали понимание понимания разработки программного обеспечения и его присущих задач при «управлении» командами разработчиков программного обеспечения, или, к сожалению, за пределами их красочных таблиц Excel (обычно, хотя и не всегда, людей, близких к выходу на пенсию) ).
code_dredd

7
Это может иметь какое-то отношение к тому факту, что «хирургия» является одной из наиболее отсталых отраслей медицины - на самом деле, это хорошо известная шутка в Великобритании, что хирурги проводят 7 лет, изучая их, поэтому их можно назвать «врачом», а затем еще 7 лет, чтобы их снова можно было назвать «мистер» или «миссис»! Фактически реорганизация хирургии с целью повышения ее эффективности путем следования «наилучшей практике» других отраслей с гораздо более низким уровнем ошибок и т. Д. (В частности, гражданской авиации) является постоянной задачей медицинских работников. ...
Alephzero

6
@alephzero: Это пара забавных заявлений. Где именно вы практиковали хирургию? Здесь количество дерьма, которое вы называете «наилучшей практикой», занимает большую часть времени хирурга и приносит нулевую выгоду. Супер-умные люди [иронично] изо всех сил стараются улучшить то, чего не понимают, добавляя в него больше бюрократического дерьма почти каждую неделю. Причины упомянутой вами частоты отказов, тем не менее, не устранены. Почти все неудачи связаны с недосыпанием, недостаточным образованием и завышенной оценкой. Часто все трое вместе.
Дэймон,

Ответы:


103

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

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

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

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

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

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


20
Если у кого-нибудь, читающего это, есть издание книги, посвященное 20-й годовщине, то стоит прочитать новое предисловие и новую главу 19. Хотя даже изданию, посвященному 20-й годовщине, по состоянию на 2017 год уже исполнилось 20 лет, автор указывает на некоторые из утверждений в этот ответ, который часто упускают из виду в спешке, чтобы подвести итог всей книги как «добавление инженеров в уже запоздалый проект делает его еще более поздним».

1
Что в мире означает "UUGE"? Отличный ответ, кстати.
Уэйн Конрад

5
@WayneConrad народный для огромного .
zzzzBov

1
Будучи уже системным программистом IBM в этот период, было обычным делом иметь очень плотно определенные роли в команде, по специальности определенной части ОС. Ожидается, что человек в каждой из этих ролей будет знать или изучать все, что можно было знать об этом, и выступать в качестве вспомогательного персонала для любого из других экспертов. По сути, мы получили хирургическую бригаду на каждого сотрудника, каждый со своей специализацией.
Джо МакМахон

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

87

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

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

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

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

Точно так же роль системного администратора (не входящая в хирургическую группу Миллса, а часть типичной межфункциональной команды последних лет) устарела из-за таких концепций, как DevOps (поглощение роли Sysadmin в роли инженера-программиста) Платформа как услуга, Инфраструктура как услуга и Утилиты (превращение Sysadmin в «чужую проблему») или Инфраструктура как код (превращение системного администрирования в разработку программного обеспечения).

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

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

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


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

15
«Можете ли вы себе представить, что платите работнику, работающему полный рабочий день, чтобы распечатать исходный код, а затем вручную проиндексировать и сохранить его?» Нет, но я определенно могу себе представить оплату штатного сотрудника за управление системами контроля версий и непрерывной сборки, и фактически в любой компании среднего или крупного размера это норма. На самом деле, управление вики, системами управления документами и т. Д. - это совершенно отдельная, еще более важная роль, которую, как правило, уделяют все время техническим писателям, занятым полный рабочий день.
Майлз Рут

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

2
В то время как компьютеры были дорогими в 1975 году, нажатия клавиш были довольно дешевыми. Когда я сначала программировал мэйнфреймы (не в 75, а в 77), мы записывали код на бумаге, перфорировали его на карточки, доставляли его в калитку, а затем периодически проверяли, была ли распечатка доставлена ​​обратно. (Время поворота может составить 2 часа для нас, а на некоторых сайтах - больше дня.) Клерк был бы очень полезен для всех, кроме первой из этих задач. Я не видел терминалы до 1979 года или около того.
Теодор Норвелл

1
Re: Smalltalk - не только каждый разработчик и каждый пользователь должен иметь свой собственный компьютер, эти компьютеры также должны были быть мощными компьютерами с большим объемом памяти и графическим интерфейсом . Подумайте «рабочая станция», а не «ПК». У оригинальных компьютеров IBM не было мощности для запуска Smalltalk. На мой взгляд, позор ...
Боб Джарвис,

20

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

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

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

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


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

2
@RibaldEddie относительно чего? Если вы сравните труд с ценой жизни, она снижается; час работы может дать вам больше еды / жилья, чем в 1969 году
k_g

3
@k_g хорошо, это зависит от местоположения. С точки зрения инфляции, в большинстве мест в США вы можете нанять разработчика за меньшие деньги с поправкой на инфляцию сегодня, чем в 1969 году. Для справки, в книге Брукс предлагает 20 тыс. За то, что сегодня мы считаем старшим разработчиком архитектуры и 10 Кб для прогона программиста мельницы, который выполняет основную часть работы. В сегодняшних долларах эти 10 тысяч - это около 65 тысяч. Сегодня иметь в своей команде большинство разработчиков, заработавших 65 тысяч, - очень хорошая цена.
Рибальд Эдди

3
Это, по сути, зарплаты программного обеспечения не изменились с 1969 года. Учитывая общую инфляцию и более высокую стоимость жизни, разработчики сегодня значительно дешевле.
Рибальд Эдди

11
Действительно, все преимущества современной экономической среды с точки зрения производительности и более дешевой рабочей силы достались классу руководителей и акционеров в бизнесе. Как я уже сказал, даже с учетом инфляции зарплаты разработчиков программного обеспечения остались прежними, в то время как вознаграждение руководителям увеличилось во много сотен раз выше, чем инфляция. Кроме того, во многих местах, особенно вдоль западного побережья Северной Америки, стоимость жизни росла значительно быстрее, чем инфляция (см. Недвижимость), и все же зарплаты профессиональных застройщиков едва успевали за инфляцией.
Рибальд Эдди

13

Этот паттерн звучит очень похоже на программирование мобов:

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

С http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

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

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


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

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

Пришел сюда, чтобы сказать это; или различные формы самоорганизации команды.
Марчин

2
@BobJarvis Я не согласен. Я имел большой успех, работая в командах интровертов (и я думаю, что некоторые из них включали и экстравертов). Ключевым моментом является создание пространства, в котором люди чувствуют себя в безопасности и могут внести свой вклад и готовы на некоторое время расширить свои естественные наклонности на благо группы. Тихая Сьюзен Кейн очень помогла понять, как хорошо работать с разными темпераментами: ted.com/talks/susan_cain_the_power_of_introverts
Дэвид Карбони,

12

Эта модель команды снова упоминается в статье «Быстрое развитие - укрощение диких программ» Стива Макконнелла на странице 305. Там она называется командой шеф-программистов.

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

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

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

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


9

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

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

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


1
так что в принципе ничего не случилось с этим. +
Горди

1
@gordy да и нет. Вы заметите, что в примере с Brook, по всей вероятности, именно от менеджеров зависит, кто был в каждой роли в команде, но в современной гибкой концепции команда самоорганизуется. Таким образом, роли хирурга или второго пилота естественно выпадают из того, как работает команда. Я думаю, что это ключевое различие: самоорганизация против компании.
Рибальд Эдди

Я бы изменил «большинство» на «некоторые». Это действительно зависит от динамики команды. И это определенно должно расти органически, если хирург продиктован сверху, результат будет неоптимальным, так что +1 для самоорганизации.
Питер

2
Слова Дао Программного Обеспечения: #IV - Дао Командной работы: Хорошее программное обеспечение написано небольшими командами, работающими быстро. Плохое программное обеспечение написано большими командами, работающими медленно. Следствия: - оптимальный размер команды 1; - максимальное практическое значение для размера команды - 3; - Для команд размером> 3 (неправильное) общение становится серьезной проблемой; - Для размера команды> 6, завершение проекта становится серьезно скомпрометировано. Завершение проекта в срок, скорее всего, за окном. В таких случаях умные разработчики будут использовать дверь ... Так написано ... ( BWOOoooonnnggggg !!! )
Боб Джарвис

6

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

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

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

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


9
Часть, которая заставляет меня улыбаться (?), Это вещь "... несколько менеджеров ...". Одного менеджера более чем достаточно для снижения производительности. Несколько менеджеров могут подтолкнуть разработчиков к мысли о самоубийстве (интроверты) или убийстве (экстраверты).
Боб Джарвис

4
@BobJarvis - у меня было, в зависимости от проекта, до пяти «менеджеров» одновременно с разными названиями. Эффект в значительной степени, как вы могли себе представить.
Роб Кроуфорд

1
Очевидно, вы экстраверт. Итак ... защита безумия? Мексика? Или ... справедливое убийство ..? :-)
Боб Джарвис

Вот почему у меня было пять начальников в одной компании. В то время как я был там, любая проблема, была ли она моей или чьей-либо другой, я услышал бы это с 5 различных точек зрения. Я обычно анализировал это к моменту, когда появился номер 2, и было просто неприятно слышать об этом там больше раз.
Роберт Барон

Первоначальная идея заключалась не в том, чтобы «иметь пять разных менеджеров, пытающихся вмешаться», а в том, чтобы обеспечить, например, «сотрудника отдела кадров» и «сотрудника отдела кадровой карьеры» и т. Д. Я думаю, что несколько менеджеров будут работать, если вы будете выставлять счета каждому отделу менеджера на основе как часто они связывались с инженером. Сделал бы забавную видеоигру!
Чарльз Мерриам

2

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

  • Хирург: программист
  • Второй пилот: пара программистов , коллег, интернет-сообщества, такие как StackExchange или IRC
  • Администратор: роль, обычно занятая менеджером программных проектов
  • Редактор: интегрированные среды разработки, интегрирующие генераторы документации, такие как Javadoc или Doxygen; документация из комплектов разработки программного обеспечения
  • Секретарь: клиент электронной почты, инструменты управления проектами, такие как средства отслеживания ошибок и запросы, чаты компании и списки рассылки.
  • Программный клерк: IDE хранит информацию о дизайне проекта с добавленной возможностью рефакторинга кода; документация и примеры из комплектов разработки программного обеспечения
  • Toolsmith: все сообщество с открытым исходным кодом
  • Тестер: немедленное тестирование и тестирование библиотек. Но, конечно, для производственного кода необходим отдельный процесс обеспечения качества.
  • Язык юриста: онлайн-документация, StackExchange

1

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

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

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


0

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

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


2
Это определенно не модель DevOps.
Рибальд Эдди

5
На самом деле DevOps больше похож на модель хирургической команды, потому что Developer Operations подразумевает, что операции существуют для обслуживания разработки. DevOps - это две основные концепции: операции должны рассматриваться как практика разработки и, следовательно, инструменты и методы, используемые в разработке, такие как контроль исходного кода и гибкие методы управления, должны использоваться операциями, а операции используются для поддержки разработки.
Рибальд Эдди

1
@RibaldEddie Интересно. Мой опыт работы с группой DevOps в моей компании заключается в том, что они нанимают разработчиков и несут ответственность за все, от разработки продукта, тестирования, документации, развертывания и т. Д. На ум приходит слово «кросс-функциональный». Ну да ладно, с 2 голосами против и голосами за удаление в течение 15 минут, я думаю, я буду держаться подальше от этого сайта.
Майк Оунсворт,

1
Ах, тогда у нас есть другое определение «кросс-функционал». Я использую это для обозначения того, что каждый член команды способен выполнять любую задачу - Джираса обычно разбрасывают между людьми, потому что они покончили со специализацией. Кто-то, кто разрабатывает эту функцию, протестирует или задокументирует следующую функцию. Это «DevOps», которые я испытал.
Майк Оунсворт,

1
@MikeOunsworth: это команда кросс-функционалов :-D
Jörg W Mittag

0

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.