Какая методология ближе всего к хирургической бригаде в «Мифическом человеко-месяце»?[закрыто]

Question

Мифический человеко-месяц теперь стал классикой, но методология «Хирургической бригады» по-прежнему интересна.Какая методология наиболее схожа с ней или имеет ту же суть?

Подводя итог аналогии с хирургической бригадой:Хирург понимает проблему/область бизнеса и является экспертом.Они являются авторитетом, когда в команде возникают вопросы или конфликты.Когда возникают проблемы, например, с дизайном, хирурги работают между собой, действуя как небольшая сплоченная группа экспертов.То есть, по сути, они обладают знаниями в предметной области, им поручено делать то, что они считают правильным, и заниматься фактическим кодированием?Остальная часть команды сосредоточена на поддержке, тестировании, документации, а планы проектов являются делегированными задачами.Следовательно, хирург также является наиболее квалифицированным/подготовленным специалистом.

Ответом могут быть методологии проектов, программирования и проектирования, поскольку это, по-видимому, имеет последствия для основных областей методологии.Agile, MDA, Extreme, в разработке источников?Этот вопрос также имеет больше смысла для программного обеспечения, которое является крупным в сложной бизнес-области, например, для управления воздушным движением, а не для разработчика COTS или обычной утилиты.

Answer 1

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

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

Answer 2

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

То есть он одновременно и менеджер программы (архитектор), и разработчик.

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

Однако для общего развития есть несколько проблем с такими «героическими» методологиями:

• Лишь немногие ключевые разработчики в достаточной степени понимают предметную область, и им приходится полагаться на экспертов в предметной области.Это просто функция специализации — трудно найти отличных программистов, которые одновременно являются юристами, врачами, бухгалтерами или другими экспертами в области, которую моделирует программное обеспечение.

• Масштабируемость ограничена количеством имеющихся у вас «хирургов».

• Остальным сотрудникам приходится много времени простоять, пока они ждут инструкций, поскольку целеустремленный «исполнитель» также управляет командой.Это нормально в OR, так как вы имеете дело с мандатом с «нулевым кусочком» и «живым программным обеспечением». Но в этой экономике более распределенная рабочая нагрузка является более эффективной, даже если это приводит к случайной проблеме синхронизации между членами команды.

Answer 3

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

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

я работал именно над один проект, который был запущен таким образом.Это было так приятно, что мне почти неловко называть это «работой».Четверо из нас, разработчиков (с дополнительным персоналом поддержки, включая случайных младших кодировщиков) всего за 9 месяцев написали и правильно запустили поистине колоссальный объем кода.В других местах, где я был, я не смог бы сделать столько же с командой из 20 человек.

Answer 4

Из текста я вижу следующее:

Гибкий лайк:

• Небольшие команды, сосредоточенные на решении конкретных задач
• Сотрудничество хирургов

Негибкие типа:

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

Для проекта водопада предлагается использовать команду экспертов (хирургов) для планирования, проектирования, кодирования и т. д.и распределение задач «вспомогательному» персоналу.В agile-команде тестирование рассматривается не как поддержка, а как неотъемлемая часть поставки.

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