O Mítico Homem-Mês -The Mythical Man-Month

O Mítico Homem-Mês
	Primeira edição
Autor	Frederick Brooks
Sujeito	Gerenciamento de projetos de software
Editor	Addison-Wesley
Data de publicação	1975
ISBN	0-201-00650-2 (ed. 1975), 0-201-83595-9 (ed. 1995)
OCLC	1201368
Decimal de Dewey	001.6 / 425
Classe LC	QA76.6 .B75
Seguido pela	" Sem bala de prata "

The Mythical Man-Month: Essays on Software Engineering é um livro sobre engenharia de software e gerenciamento de projetos de Fred Brooks publicado pela primeira vez em 1975, com edições subsequentes em 1982 e 1995. Seu tema central é que "adicionar mão de obra a um projeto de software atrasado o torna mais tarde." Essa ideia é conhecida como lei de Brooks e é apresentada junto com o efeito do segundo sistema e a defesa da prototipagem .

As observações de Brooks são baseadas em suas experiências na IBM enquanto gerenciava o desenvolvimento do OS / 360 . Ele havia acrescentado mais programadores a um projeto que estava atrasado, uma decisão que mais tarde concluiria que, contra-intuitivamente, atrasou o projeto ainda mais. Ele também cometeu o erro de afirmar que um projeto - envolvido na escrita de um compilador ALGOL - exigiria seis meses, independentemente do número de trabalhadores envolvidos (exigia mais tempo). A tendência dos gerentes de repetir tais erros no desenvolvimento de projetos levou Brooks a gracejar que seu livro se chama "A Bíblia da Engenharia de Software", porque "todo mundo cita, algumas pessoas leem e poucas pessoas seguem".

Edições

O trabalho foi publicado pela primeira vez em 1975 ( ISBN 0-201-00650-2 ), reimpresso com correções em 1982 e republicado em uma edição de aniversário com quatro capítulos extras em 1995 ( ISBN 0-201-83595-9 ), incluindo uma reimpressão do ensaio " No Silver Bullet " com comentários do autor.

Ideias apresentadas

O mítico homem-mês

Brooks discute várias causas de falhas de agendamento. O mais duradouro é sua discussão sobre a lei de Brooks : adicionar mão de obra a um projeto de software atrasado o torna mais tarde . Homem-mês é uma unidade de trabalho hipotética que representa o trabalho realizado por uma pessoa em um mês; A lei de Brooks diz que a possibilidade de medir o trabalho útil em homens-mês é um mito e, portanto, a peça central do livro.

Projetos de programação complexos não podem ser perfeitamente particionados em tarefas discretas que podem ser trabalhadas sem comunicação entre os trabalhadores e sem estabelecer um conjunto de inter-relações complexas entre as tarefas e os trabalhadores que as executam.

Portanto, atribuir mais programadores a um projeto atrasado o tornará ainda mais tarde. Isso ocorre porque o tempo necessário para que os novos programadores aprendam sobre o projeto e o aumento da sobrecarga de comunicação consumirão uma quantidade cada vez maior de tempo disponível no calendário. Quando n pessoas têm que se comunicar entre si, conforme n aumenta, sua produção diminui e quando se torna negativa, o projeto é atrasado ainda mais com cada pessoa adicionada.

Fórmula de intercomunicação de grupo: n ( n - 1) / 2
Exemplo: 50 desenvolvedores fornecem 50 · (50 - 1) / 2 = 1225 canais de comunicação.

Sem bala de prata

Brooks adicionou "No Silver Bullet - Essence and Accidents of Software Engineering" - e outras reflexões sobre isso, "'No Silver Bullet' Refired" - à edição de aniversário de The Mythical Man-Month .

Brooks insiste que não há uma bala de prata - "não há um desenvolvimento único, seja em tecnologia ou técnica de gerenciamento, que por si só promete uma melhoria de magnitude [dez vezes] em uma década em produtividade, confiabilidade e simplicidade. "

O argumento se baseia na distinção entre complexidade acidental e complexidade essencial, semelhante à forma como a lei de Amdahl se baseia na distinção entre "estritamente serial" e "paralelizável".

O efeito do segundo sistema

O efeito do segundo sistema propõe que, quando um arquiteto projeta um segundo sistema, é o sistema mais perigoso que eles projetarão, porque eles tenderão a incorporar todas as adições que originalmente não adicionaram ao primeiro sistema devido ao tempo inerente restrições. Portanto, ao embarcar em um segundo sistema, um engenheiro deve estar ciente de que eles são suscetíveis a engenharia excessiva.

A tendência para o número irredutível de erros

99 pequenos bugs no código.
99 bichinhos.
Pegue um, remende-o.
127 pequenos bugs no código ...

O autor observa que, em um sistema adequadamente complexo, há um certo número irredutível de erros. Qualquer tentativa de corrigir os erros observados tende a resultar na introdução de outros erros.

Acompanhamento de progresso

Brooks escreveu "Pergunta: Como um grande projeto de software chega um ano atrasado? Resposta: Um dia de cada vez!" Deslizes incrementais em muitas frentes eventualmente se acumulam para produzir um grande atraso geral. É necessária atenção contínua para cumprir pequenos marcos individuais em cada nível de gestão.

Integridade conceitual

Para tornar um sistema amigável, o sistema deve ter integridade conceitual, o que só pode ser alcançado separando a arquitetura da implementação. Um único arquiteto-chefe (ou um pequeno número de arquitetos), agindo em nome do usuário, decide o que entra no sistema e o que fica de fora. O arquiteto ou equipe de arquitetos deve desenvolver uma ideia do que o sistema deve fazer e certificar-se de que essa visão seja compreendida pelo restante da equipe. Uma ideia nova de alguém pode não ser incluída se não se ajustar perfeitamente ao design geral do sistema. Na verdade, para garantir um sistema amigável, um sistema pode deliberadamente fornecer menos recursos do que é capaz. A questão é que, se um sistema for muito complicado de usar, muitos recursos não serão usados porque ninguém terá tempo para aprendê-los.

O manual

O arquiteto-chefe produz um manual de especificações do sistema. Deve descrever detalhadamente as especificações externas do sistema, ou seja , tudo o que o usuário vê. O manual deve ser alterado conforme o feedback chega das equipes de implementação e dos usuários.

O sistema piloto

Ao projetar um novo tipo de sistema, uma equipe irá projetar um sistema descartável (quer pretenda ou não). Este sistema atua como um “plano piloto” que revela técnicas que irão subsequentemente causar um redesenho completo do sistema. Este segundo sistema , mais inteligente , deveria ser entregue ao cliente, uma vez que a entrega do sistema piloto não causaria nada além de agonia para o cliente e possivelmente arruinaria a reputação do sistema e talvez até mesmo a empresa.

Documentos formais

Cada gerente de projeto deve criar um pequeno conjunto básico de documentos formais definindo os objetivos do projeto, como eles devem ser alcançados, quem irá alcançá-los, quando eles serão alcançados e quanto eles custarão. Esses documentos também podem revelar inconsistências que, de outra forma, seriam difíceis de ver.

Estimativa de projeto

Ao estimar os tempos do projeto, deve-se lembrar que os produtos de programação (que podem ser vendidos para clientes pagantes) e os sistemas de programação são três vezes mais difíceis de escrever do que programas internos independentes simples. Deve-se ter em mente quanto da semana de trabalho será realmente gasto em questões técnicas, em oposição a tarefas administrativas ou outras tarefas não técnicas, como reuniões e, especialmente, reuniões "stand-up" ou "all-hands".

Comunicação

Para evitar desastres, todas as equipes que trabalham em um projeto devem permanecer em contato umas com as outras de tantas maneiras quanto possível - e-mail, telefone, reuniões, memorandos, etc. Em vez de presumir algo, os implementadores devem pedir aos arquitetos para esclareça sua intenção em um recurso que estão implementando, antes de prosseguir com uma suposição que pode muito bem estar completamente incorreta. O (s) arquiteto (s) são responsáveis por formular uma imagem de grupo do projeto e comunicá-la a outras pessoas.

A equipe cirúrgica

Assim como uma equipe cirúrgica durante a cirurgia é liderada por um cirurgião que realiza o trabalho mais crítico, enquanto dirige a equipe para auxiliar nas peças menos críticas, parece razoável ter um "bom" programador para desenvolver componentes críticos do sistema enquanto o resto da equipe fornece o que é necessário no momento certo. Além disso, Brooks pondera que "bons" programadores são geralmente cinco a dez vezes mais produtivos que os medíocres.

Congelamento de código e controle de versão do sistema

O software é invisível. Portanto, muitas coisas só se tornam aparentes quando uma certa quantidade de trabalho é realizada em um novo sistema, permitindo que o usuário experimente. Essa experiência trará insights, que mudarão as necessidades do usuário ou a percepção das necessidades do usuário. O sistema deve, portanto, ser alterado para atender aos requisitos alterados do usuário. Isso só pode ocorrer até certo ponto, caso contrário, o sistema pode nunca ser concluído. Em uma determinada data, não devem ser permitidas mais alterações no sistema e o código deve ser congelado. Todas as solicitações de mudanças devem ser adiadas até a próxima versão do sistema.

Ferramentas especializadas

Em vez de cada programador ter seu próprio conjunto especial de ferramentas, cada equipe deve ter um fabricante de ferramentas designado que pode criar ferramentas altamente personalizadas para o trabalho que a equipe está fazendo, por exemplo , uma ferramenta geradora de código que cria código com base em uma especificação . Além disso, as ferramentas de todo o sistema devem ser construídas por uma equipe de ferramentas comuns, supervisionada pelo gerente de projeto.

Reduzindo os custos de desenvolvimento de software

Existem duas técnicas para reduzir os custos de desenvolvimento de software sobre as quais Brooks escreve:

Os implementadores podem ser contratados apenas após a conclusão da arquitetura do sistema (uma etapa que pode levar vários meses, durante os quais os implementadores contratados prematuramente podem não ter nada para fazer).
Outra técnica mencionada por Brooks é não desenvolver software, mas simplesmente comprá-lo " na prateleira " quando possível.

Veja também

Bibliografia

- (1975). O Mítico Homem-Mês . Addison-Wesley. ISBN 0-201-00650-2.
Brooks, Frederick P. Jr. (setembro de 1983). “O Mítico Homem-Mês” . Revista PC . 2 (4): 210–240.
- (1995). "Cap. 17".'Sem bala de prata' refeito . The Mythical Man Month (edição de aniversário com quatro novos capítulos ed.). Addison-Wesley. ISBN 0-201-83595-9.

Languages

In other projects