Несколько лет назад, когда я читал «Мифический человеко-месяц», я обнаружил много вещей, которые я уже знал из других источников. Однако там были и новые вещи, несмотря на то, что книга 1975 года. Одним из них было:
Миллс предлагает, чтобы каждый сегмент большой работы решался командой, но чтобы команда была организована как хирургическая команда, а не как команда по разделке свиней. То есть вместо того, чтобы каждый участник решал проблему, один занимается сокращением, а другие оказывают ему всяческую поддержку, которая повышает его эффективность и продуктивность.
Это очень интересный шаблон для организации команды разработчиков программного обеспечения, но я никогда не встречал его в какой-либо другой книге по разработке программного обеспечения, даже нигде не упомянутой.
Почему это?
- Была ли «Хирургическая бригада» еще тогда необычной?
- Или это было опробовано и провалилось?
- Если так, как это потерпело неудачу?
- Если нет, то почему мы не видим этот шаблон в современных программных проектах?
Ответы:
«Мифический человеко-месяц» вышел в тот год, когда я начал учиться в колледже, и, говоря современным языком, UUUGE! :-) То, что вам нужно понять, это разница в том, как программное обеспечение разрабатывалось тогда и сейчас. Назад в день (tm) в значительной степени все кодирование было сначала сделано на бумаге, затем было перфорировано на перфокарты (как вы уже догадались), затем было прочитано, скомпилировано, связано, выполнено, результаты были получены, и процесс повторился. Процессорное время было дорогими ограниченный ресурс, и вы не хотели тратить его впустую. То же самое и на диске, время на магнитной ленте и т. Д., Бла. Потеря совершенно хорошего процессорного времени на компиляции, которая приводила к (шокирующим и ужасным) ошибкам, была ... ну, трата совершенно хорошего процессорного времени. И это было в 1975 году. В то время, когда Фред Брукс разрабатывал свои идеи, в середине 1960-х годов процессорное время было еще больше.дорого, память / диск / что бы то ни было еще БОЛЬШЕ ограничено и т. д., и т. д. Идея The Surgical Team состояла в том, чтобы обеспечить, чтобы One Super Great Rockstar Developer не пришлось тратить ЕГО время на рутинные задачи, такие как проверка кода, нажатие клавиш, отправка работы, ожидание результатов (иногда часами). Человек-разработчик Rockstar Dude должен был быть ПИСЬМЕННЫМ КОДОМ. Его легион поклонников / клерков / младших разработчиков должен был заниматься мирскими делами.
Проблема заключалась в том, что в течение 2 лет после публикации книги Брукса основные идеи, стоящие за хирургической командой, были разрушены:
ЭЛТ-терминалы и дисковые файлы стали заменять наборы клавиш и карточные колоды. Компьютерное время стало дешевле, стало доступно несколько компьютеров, а время выполнения работы резко сократилось. Когда я поступил в колледж (Университет Майами, Оксфорд, Огайо, класс 79, спасибо за вопрос) хорошоОборот работы был около часа. Во время финальной недели - четыре часа, может быть, иногда шесть. (Мы конкурировали за процессорное время с кучей коммерческих компаний и университетов - и коммерческие пользователи получили первый приоритет). В течение моего старшего года, когда Майами отказались от своего «общего компьютера», установили в кампусе свой собственный IBM 370/145, и у меня был прекрасный HP mini, над которым я работал, который действовал как станция RJE, которую мы могли превратить в мэйнфрейм работы около пяти минут или меньше. Теперь стоило добавить свой код на HP, отправить его с HP на мэйнфрейм, перевернуть пальцы / выкурить сигарету и получить свои данные задолго до того, как вы сможете закончить настольную проверку кода.
В основе хирургической команды лежит идея о том, что вы (или «руководство», да поможет нам всем Бог) можете определить Чувак-разработчик Rockstar Surgical Developer. На самом деле, я сомневаюсь, что это возможно. Там являются Rockstar разработчиков, каждый знает , что это - исследования показали различия в производительности между лучшими и худшими разработчиками целых 2000% - но , определив , что человек без них писать код в течение длительного периода временискорее всего невозможно. Единственный способ узнать, является ли кто-то разработчиком Rockstar, - это заставить его на самом деле разрабатывать код, но если они НЕ Чувак, разработчик Rockstar Surgical Developer, они будут делать захватывающие вещи, такие как настольная проверка его кода, вставка его на карты и откладывать коробки перфокарт в отдел ввода вакансий, а затем бездельничать в ожидании результатов, чтобы они могли отнести их обратно к мистеру Rockstar Surgical Developer Dude вместо того, чтобы учиться кодировать единственный способ, который действительно работает - путем написания кода, отладки кода, и т. д. Назад В тот день (tm) не было соревнований по программированию, не было переполнения стека, у вас не было ПК, на котором вы могли бы писать код, когда захотите, не было книг «Алгоритмы для идиотов» - единственный способ научиться программированию - это пойти в школу и заняться чем-то, где нужно немного программировать. Но программированиеper se не воспринимали всерьез, и предполагалось, что это то, чего люди не хотят делать . На моем первом курсе в колледже (SAN151 - Введение в системный анализ, доктор Том Шабер - спасибо, Том :-), инструктор сказал нам: «... нам просто пришлось столкнуться с фактом, что нам придется потратить пару лет как программисты, прежде чем мы могли стать системными аналитиками ". «Два года?» - подумал я. «Я ТОЛЬКО ДОЛЖЕН ДЕЛАТЬ ЭТО В ТЕЧЕНИЕ ДВА ГОДА?!?». Я был серьезно расстроен. К счастью, он ошибался, и с тех пор я довольно много кодирую. :-)
Хирургическая бригада предполагает, что программисты являются относительно редким ресурсом. На самом деле это заняло еще несколько лет, но с появлением ПК в начале 80-х программирование стало чем-то, в чем мог принять участие любой гик. Цена на компьютеры начала падать, цена на инструменты разработки начала падать, и это все Приветствую Turbo Pascal - по сегодняшним меркам это было немного, но в то время это была полная IDE для Pascal за 40 баксов, что было абсолютно чокнутым! Теперь любой может заняться программированием - если вы можете позволить себе компьютер, и когда IBM решила выпустить PCjr (да, мой первый компьютер был одной из самых больших ошибок IBM :-) в продаже примерно за 500 долларов, чтобы избавиться от этих индюков, наличными привязанные повсюду гайки везде пропускали свои арендные платежи в течение месяца («Да, я знаю, но я ... сломала свой язычок и должна была сделать операцию и ..» да, на следующей неделе, нет проблем, спасибо, мужик ...) и поглотил их по ценам распродажи. Затем потратили больше, чем мы заплатили за компьютер на надстройки, чтобы сделать его пригодным для использования. («Да, чувак, на следующей неделе, наверняка, наверное ...» :-).
Что меня действительно огорчает, так это то, что даже сегодня, если вы спросите людей, читали ли они когда-нибудь «Мифический человеко-месяц» или поняли его основной урок («Добавление ресурсов в поздний проект делает его позже»), они дают вам пустое место. посмотрите - и затем продолжайте делать те же самые ошибки, которые были сделаны все те годы назад во время разработки OS / 360. Все старое снова новое ...: -}
источник
Есть некоторые аспекты этой концепции, которые иногда реализуются сегодня, есть и другие аспекты, которых следует избегать .
Сохранение команд небольшим - одна из основных особенностей Agile Methods, но также практикуется и за пределами Agile.
Кросс-функциональные команды также являются основой Agile, но распространены и за пределами Agile.
Роль Программного клерка в значительной степени определяется компьютеризированными системами, такими как системы контроля версий, системы управления конфигурацией программного обеспечения, системы управления изменениями, системы управления документами, вики, системы непрерывного построения с репозиториями артефактов и так далее. Я имею в виду, можете ли вы себе представить, что платите работнику, работающему полный рабочий день, чтобы распечатать исходный код, вручную проиндексировать и подать его?
Точно так же роль системного администратора (не входящая в хирургическую группу Миллса, а часть типичной межфункциональной команды последних лет) устарела из-за таких концепций, как DevOps (поглощение роли Sysadmin в роли инженера-программиста) Платформа как услуга, Инфраструктура как услуга и Утилиты (превращение Sysadmin в «чужую проблему») или Инфраструктура как код (превращение системного администрирования в разработку программного обеспечения).
Один из аспектов, который мы стараемся избегать сегодня, заключается в том, что не более двух человек понимают систему. Только хирург гарантированно понимает систему полностью, второй пилот может или не может. Это дает коэффициент шины от 1 до 2. Если хирург заболел, проект мертв. Период. Agile ответом на это является коллективное владение кодом, которое является полной противоположностью этой модели: никто не несет особой ответственности за какую-либо часть системы. Вместо этого каждый несет ответственность за все как группа .
Наконец, в эту концепцию заложены некоторые предположения, которые устарели. Например, даже если это не указано явно, команда настроена таким образом, что только один человек в команде (хирург) фактически имеет компьютер. Это, конечно, потому что на момент написания статьи даже идея, что у всей команды будет один компьютер для себя, не говоря уже об одном человеке в команде, была натянутой. (Даже в 1980 году, когда был выпущен Smalltalk, одной из причин его провала был тот факт, что система была настроена так, что у каждого разработчика и каждого пользователя был свой компьютер - в то время он был совершенно немыслим.)
Так, в общем , я не думаю , что концепция была реализована именно так , как описано выше, но некоторые его аспекты , безусловно , будут реализованы, некоторые аспекты рассматриваются как нежелательные и активно избегать, некоторые из них устарели, а некоторые из них , вероятно , хорошо Идеи ™, но никто этого не делает.
источник
Раньше, образование в колледже было чем-то уникальным, и инженеры были среди немногих избранных. Компьютеры были дорогими, и команды работали над проектами с определенным бизнес-RoI. Они были не очень распространены.
То, что произошло, - это микрокомпьютеры, повсеместное высшее образование и компьютерные системы, которые даже не нуждаются в университетских степенях для достижения прогресса. Кроме того, произошло изменение экономической ситуации и рост стоимости рабочей силы.
Экономия соотношения поддержка: инженер 8: 2 больше не имеет смысла. Инженеры должны быть их собственной поддержкой. Современный человек с достаточным образованием и навыками для эффективной работы в команде разработчиков слишком дорог, чтобы не заниматься каким-либо собственным развитием.
(Связанный экономический термин "болезнь стоимости сектора услуг.")
источник
Этот паттерн звучит очень похоже на программирование мобов:
Вся группа (QA, разработчики и даже Владелец продукта при необходимости) одновременно работает над одной и той же проблемой. Не вставай, высокая связь, прямо развернутый в прямом эфире.
С http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/
Смотрите его в действии здесь: https://www.youtube.com/watch?v=dVqUcNKVbYg
источник
Эта модель команды снова упоминается в статье «Быстрое развитие - укрощение диких программ» Стива Макконнелла на странице 305. Там она называется командой шеф-программистов.
Эта модель возникла потому, что в команде был гений и вычислительные ресурсы были ограничены. Он не пользуется популярностью, потому что гениальность редка, а благодаря вездесущим компьютерам и распределенному контролю версий у нас есть место для многих рук за операционным столом.
Другие ссылки:
Бейкер Ф. Терри. «Главный программист отдела управления производственным программированием», IBM Systems Journal, вып. 11, нет. 1, 1972, с. 56-73.
Бейкер Ф. Терри и Харлан Д. Миллс. «Главный программист команды». Datamation, том 19, номер 12 (декабрь 1973 года), с. 58-61.
источник
Я предполагаю, что большинство небольших самоорганизующихся команд будут склонны в любом случае склоняться к фактической модели хирургической команды.
Последние две команды, в которых я принимал участие, обычно состояли из трех или четырех человек, обычно одного старшего (хирург), среднего (второй пилот) и пары юниоров / специалистов. Некоторые роли в хирургической команде, упомянутые Бруксом в настоящее время, выполняются мастерами Scrum и системными администраторами или облачными провайдерами. Помните, что контроль над источниками в то время почти не существовал, не говоря уже о чем-то столь мощном, как git.
Подумайте о правиле Безоса с двумя пиццами. Это ваша самоорганизующаяся хирургическая бригада прямо здесь.
источник
Была бумага из HP, в которой предлагалось нечто подобное:
Газета была в до-сетевые дни и время от времени поднималась как забавная. Каждый год, когда его поднимали, комментарии все больше переходили от «настолько смешного, его смешного» к «возможно, нам следует это делать».
Известно, что реальные тесты сложно спроектировать, поэтому, вероятно, они остаются мнением. Могут существовать некоторые обзоры проектов и степени их завершенности.
источник
Интересно , сколько из необходимости хирургической команды стало излишним из-за роста Интернета, интегрированные среды разработки и средств разработки программного обеспечения , которые могут взять на себя много функциональности Фред Брукс приписываемой хирургической бригады, в том числе:
источник
Я думаю, вам нужно взглянуть на предпосылку Мистического Месяца Человека. Наем большего количества программистов только ухудшает проблемный / просроченный программный проект. Проблема заключается в общении и получении новых программистов для ускорения проекта (отнимает время от существующей разработки), технологии и иногда самого домена.
Один хорошо поддерживаемый программист избавляет от многих затрат времени и координации. Допустим, вы нанимаете консультанта для Technology X. Вместо того, чтобы довести этого консультанта до уровня скорости, достаточного для того, чтобы этот человек мог выполнять все кодирование в этой области, он просто тренирует существующего разработчика до такой степени, что он может что-то построить с некоторым надзором.
Одна из причин, по которой вы этого не видите, заключается в том, что большинство программ в любом случае пишутся одним человеком. Команды делят работу, и все идут и делают свое дело. Парное программирование, обзоры и все, что пахнет микроуправлением, не одобряется. Многие не считают программирование командным видом спорта. Один человек решает данную проблему с некоторым учетом общих ограничений.
источник
Я бы сказал, что чем больше мы разделяем проект, реализацию, тестирование, документацию, сборку, развертывание, операции и т. Д. На уникальные роли, выполняемые специалистами, тем больше мы следуем философии «хирургической команды» (хотя, возможно, не совсем так, как описано ).
По моему опыту, философия devOps о том, что каждый человек должен быть способен на любую задачу, - это возвращение к модели разделки свиней (не говоря о том, что это плохо, просто разные).
источник
Как программист, который часто исполнял роли DevOps и Build Master, я чувствовал, что часто оказывался на этой должности хирургической команды ... э-э ... парня в команде. Как мастер сборки у меня был обзор всего кода, и он был первой строкой, когда он потерпел неудачу. Часто я просто исправлял это сам.
Я был часто тем, кто писал эти системы метрик и измерял горячие точки в коде, части, которые чаще всего выходили из строя, привлекали большинство отчетов об ошибках и т. Д. Я не просто опубликовал результаты для команды, но и проанализировал их, нашел излом, который вызвал проблему и предложенные решения и архитектурные изменения, чтобы решить эту проблему.
Как DevOps я бы автоматизировал огромное количество процессов и накладных расходов. Я бы исследовал технологии и инструменты, которые облегчили бы жизнь всей команде, всей команде, от разработчиков, QA-тестировщиков до ИТ-менеджеров. Моя роль состояла в том, чтобы понять процесс, да; но, не сводя глаз с команды (реальных людей), использующих (страдающих) этот процесс, я смог довести его до такой степени, чтобы сделать его полностью прозрачным, в то же время получая массу полезных данных, чтобы получить объективное представление об этом неуловимая "большая картина".
Это неблагодарное положение и, вероятно, почему его так избегают. Я знаю, что делал свою работу хорошо, когда никто не заметил этот процесс, когда никто не задумывался о конвейере сборки. Так что да, хорошо смазанная машина быстро воспринимается как должное. Но я знал, на самом деле я измерял мультипликативное влияние, которое эта работа может оказать на производительность команды, и оно того стоит.
Так что да, я думаю, что эта роль все еще очень жива сегодня, хотя по общему признанию она действительно развивалась из того, что было тогда.
источник