Que metodologia está mais próximo da equipe cirúrgica em The Mythical Man-Month? [fechadas]

Question

O Mítico Homem-Mês agora é clássico, mas a metodologia "Equipa Médica" ainda é interessante. Qual a metodologia mais se assemelha ou tem a mesma essência?

Para resumir a analogia da equipe cirúrgica: Um cirurgião entende o domínio do problema / negócios e é o especialista. Eles são a autoridade quando há dúvidas ou conflito com na equipe. Os cirurgiões trabalham entre si quando há problemas, digamos, com design, funcionando como uma equipe apertado menor de especialistas. Então, em essência eles têm o conhecimento do domínio, sejam atribuídas a eles acham que é certo, e fazer o real codificação? O resto da equipe se concentra em suporte, testes, documentação e planos do projeto são delegadas tarefas. Consequentemente, o cirurgião é também o recurso mais qualificado / treinado.

A resposta poderia ser projeto, programação, metodologias de projeto, uma vez que parece ter implicações em vários domínios principal metodologia. Agile, MDA, Extreme, em terceirização de desenvolvimento? Esta questão também fazer mais sentido para software que é grande em um domínio de negócios complexo, acho que o controle de tráfego aéreo, não um desenvolvedor COTS ou utilidade comum.

Answer 1

Um dos padrões mencionado na padrões organizacionais de Desenvolvimento Ágil de Software é intitulado "três a sete ajudantes per Papel"; ela difere da equipe cirúrgica em que presta atenção a cada papel, por exemplo, não é apenas que o cirurgião 'papel' que tem ajudantes ou relacionamentos: todas papéis têm algum número de relações

Outro padrão a partir da mesma fonte no chamado "Architect também implementa", que pode ser análogo ao "da Equipa cirúrgica" em que o arquitecto, em particular, é (presumivelmente) altamente qualificados.

Answer 2

No caso de um cirurgião, o ator chave é tanto o especialista de domínio e o implementador.

i., Ele é tanto o gerente do programa de software (arquiteto) e o desenvolvedor.

Este tipo de metodologia pode caber certo curto queimar situações:., Por exemplo, uma operação complexa como uma atualização de migração de servidor ou software ao vivo

Para o desenvolvimento geral, no entanto, existem alguns problemas com essas metodologias "herói":

• Poucos principais desenvolvedores entender o domínio do problema a um grau suficiente, e deve contar com especialistas de domínio. Isto é simplesmente uma função da especialização -. É difícil encontrar programadores pontapé-extremidade que também são advogados, médicos, contadores, ou de outra forma são especialistas no domínio do software é a modelagem

• A escalabilidade é limitada pelo número de "cirurgiões" que você tem disponível.

• Há um monte de tempo para baixo para o outro pessoal, enquanto se espera por instruções, desde o altamente focada "doer" também está a gerir a equipa. Isso é ok no OR, desde que você está lidando com um mandato "-bug zero" e "software ao vivo." Mas nesta economia, uma carga de trabalho mais distribuída é mais eficiente, mesmo que resulta no problema sincronização ocasionais entre os membros da equipe.

Answer 3

Eu não tenho certeza qualquer metodologia realmente endereços que, como é realmente uma questão de priorizar os desenvolvedores e dobra tudo para as suas necessidades, em vez que estar nada sobre como os desenvolvedores realmente desenvolver o seu software.

Se você estava procurando por algum methodolgy que impements isso, eu suponho que isso pode ser uma má notícia. Eu prefiro considerá-lo boa notícia , na medida em que significa que você pode usar essa abordagem com praticamente qualquer metodologia de desenvolvimento de software.

Eu trabalhei em exatamente um projeto que foi executado dessa forma. Ele foi tão agradável, eu quase me sinto mal chamando-o de "trabalho". Quatro de nós desenvolvedores (com apoio extra personell, incluindo o macaco código júnior ocasional extra) tem uma quantidade realmente prodigous de código escrito e funcionando corretamente em apenas 9 meses. Outros lugares que já estive não poderia ter feito tanto com uma equipe de 20.

Answer 4

A partir do texto eu ver o seguinte:

Agile como:

• equipes pequenas focado em resolver problemas específicos
• A colaboração entre o surgeions

Não Agile como:

• Os cirurgiões são a autoridade, dirigindo o plano, determinar o design, distribuir as tarefas de apoio (viewng-los como subservent de codificação) e fazer a codificação. Todos esses são muito comando e controle na abordagem e ao contrário do equipes auto dirigir (vs a equipe dirigida)
• Não parece haver nenhuma colaboração com o parceiro de negócios (vamos colaboração frequente a sós com o parceiro busines)
• Não parece haver nenhuma product backlog priorizado, portanto, as picaretas cirurgião que é importante não é o parceiro de negócios
• Não parece haver nenhuma entrega incrmental (apertado ciclo de feedback)

Para um projeto em cascata, ele está sugerindo usar uma equipe de especialistas (cirurgiões) para fazer o planejamento, projeto, codificação, etc e distribuir as tarefas para a equipe de "apoio". Em um time ágil, o teste não é tratado como apoio, mas parte integrante de entrega.

Não se pode dizer com certeza a metodologia a ser defendida. No entanto, ele parece usar a linguagem (planos de projetos, tarefas) e assumir que a abordagem em cascata está sendo seguidas (fases como o projeto, codificação, testes conduzidos por um plano). Seja qual for a metodologia está sendo usado, aquele para o qual poucos determinar o trabalho para muitos.