Какая методология является самой близкой к Операционной бригаде в Мифическом Месяце Человека? [закрытый]

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

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

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

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

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

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

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

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

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

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

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

Agile Like:

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

Non Agile Like:

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

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

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