O documento resume o livro "O Mítico Homem-Mês" de Frederick P. Brooks Jr., que discute os desafios de gerenciar projetos de software complexos. O livro descreve como adicionar desenvolvedores a um projeto atrasado tende a atrasá-lo ainda mais, e que estimativas de tempo de projeto geralmente são otimistas demais. Ele também discute a importância da comunicação entre equipes, documentação, planejamento incremental e manter a integridade conceitual do projeto.
2. O Mítico Homem-Mês
Introdução
O Mítico Homem-Mês
• Autor: Frederick P. Brooks Jr.
• Experiência: Gerente de projeto no System e OS/360 da IBM.
• Anos: 1975, 1986, 1995
• Quantidade de capítulos: 19
• Ele é uma mistura de fatos sobre Engenharia de SW e opiniões
com a visão do autor para a gestão de projetos complexos.
• “Leitura obrigatória para todos os gerentes de projeto de SW”.
3. O Mítico Homem-Mês
Capítulo 1
O Poço de Alcatrão
• O trabalho de grandes sistemas assemelha-se à luta num
poço de alcatrão onde muitas bestas caíram.
• Elas não conseguem sair de lá por fatores acumulados.
• Porém, tem como sair! Cada pata tem que ser entendida e
solucionada por vez.
4. O Mítico Homem-Mês
O Poço de Alcatrão
Por que programar é bom?
“Gratifica anseios criativos construídos dentro de nós e deleita
sensibilidades que temos em comum com todos os homens”.
• Satisfação de construir algo útil para os outros;
• Fascínio da montagem de objetos complexos;
• Alegria da aprendizagem constante.
• Alegria de trabalhar em meio maleável;
5. O Mítico Homem-Mês
O Poço de Alcatrão
Por que programar pode não ser tão bom assim?
• O ajuste aos requisitos de perfeição é a parte mais difícil;
• Há a dependência de coisas (especialmente programas);
• Horas de trabalho monótonas e cansativas;
• A depuração de problemas pode ser linear e/ou quadrática;
• Um produto está sempre em risco de se tornar obsoleto.
6. O Mítico Homem-Mês
Capítulo 2
O Mítico Homem-Mês
• Cozinhar uma boa refeição leva tempo.
• Algumas tarefas não podem ser apressadas sem
comprometer o resultado.
• A maioria dos programadores são otimistas.
• “Tá tudo bem...”
• “Será mesmo? Muahaha!”
7. O Mítico Homem-Mês
O Mítico Homem-Mês
• Lei de Brooks: a adição de recurso humanos a um
projeto de software atrasado irá atrasá-lo ainda mais,
pois resulta em esforços adicionais de comunicação.
• “O homem-mês é um mito perigoso e enganoso, já que
implica que homens e meses sejam intercambiáveis”.
• Esforço ≠ Progresso
8. O Mítico Homem-Mês
O Mítico Homem-Mês
• Muitos projetos de softwares não dão certos por ter o
cronograma desacreditado.
• As tarefas são estimadas em chutes.
• Falta coragem para defender essas estimativas ante a pressão.
• A regra geral é que:
• 1/3 do cronograma vai para o projeto;
• 1/6 para a codificação;
• 1/4 para o teste de componentes;
• 1/4 para testes do sistema.
9. O Mítico Homem-Mês
Capítulo 3
A Equipe Cirúrgica
• Uma equipe pequena e afiada é melhor. Entretanto, ela
pode demorar anos para entregar um grande projeto.
• Max. de pessoas por equipe: 10, sendo ela formada por:
• 1 programador-chefe (cirurgião);
• Outros membros da equipe, cada com suas funções.
10. O Mítico Homem-Mês
Capítulo 4
Aristocracia, Democracia e Projeto de Sistemas
O que é integridade conceitual?
• A forma de manter a integridade do projeto definida desde a
elaboração do projeto.
• Quando separá-lo em as atividades para n pessoas, as mesmas
seguiriam a linha de pensamento do projeto inicial.
Adicionar ideias e funcionalidades no decorrer projeto?
• Faz com o sistema tenha certas funcionalidades anômalas.
11. O Mítico Homem-Mês
Aristocracia, Democracia e Projeto de Sistemas
• O arquiteto de um sistema é o agente do usuário.
• Traz conhecimento profissional e técnico.
• Satisfaz o interesse do usuário, não o do vendedor ou de outros.
12. O Mítico Homem-Mês
Capítulo 5
O Efeito do Segundo Sistema
• No 1º projeto, detalhes e requintes vão surgindo na
mente. E sendo guardados prum melhor momento.
• Cabe ao construtor retrucar, apresentando sugestões.
• O 2º é o mais perigoso sistema já projetado por alguém.
• A tendência geral é superprojetá-lo, usando as ideias de lado.
• Algumas funcionalidades podem atingir custos inesperados.
13. O Mítico Homem-Mês
Capítulo 6
Transmitindo a Mensagem
• Como garantir que as decisões dos arquitetos sejam
ouvidas, entendidas e implementadas?
• O manual é o principal produto para que isso ocorra.
• Feito por 1 ou 2 pessoas, abrangendo o que é e não é prescrito.
• Tem a precisão como elemento superior à vivacidade.
• Sem ditar como a implementação deve ser feita.
14. O Mítico Homem-Mês
Transmitindo a Mensagem
• Uma alternativa para atingir a precisão é usar...
• Notação formal: precisa, mas não totalmente compreensível.
• Notação em prosa: descritiva e explicativa, mas extensa.
• Sendo que 1 delas deve ser a definição padrão e, a outra,
a derivativa.
• Além disso, reuniões são necessárias!
• E é importante o contato telefônico
com o arquiteto responsável.
15. O Mítico Homem-Mês
Transmitindo a Mensagem
• E, nesse meio tempo, para realizar a auditoria do
projeto, existe o operante grupo de teste, que encontra
consequências da falha ou da falta de comunicação.
• É imperativo registrar e publicar os registros!!!
16. O Mítico Homem-Mês
Capítulo 7
Por Que a Torre de Babel Falhou?
Se eles tinham...
• Uma missão clara;
• Recursos humanos;
• Materiais;
• Tempo suficiente;
• Tecnologia adequada.
O que faltou a eles?
Comunicação e organização.
17. O Mítico Homem-Mês
Por Que a Torre de Babel Falhou?
Como as equipes devem se comunicar?
• De todas as formas possíveis: informalmente, em reuniões regula-
res e por meio de um diário de bordo, principalmente.
Com diário de bordo do projeto?
• Todos os documentos fazem parte de sua estrutura.
• Garante que a informação chegue a quem precisa dela.
• Precisa ser sempre atualizado: barras de mudanças, LIFO,...
18. O Mítico Homem-Mês
Por Que a Torre de Babel Falhou?
• A organização, por sua vez, deve de reduzir a comunicação, com a divisão e a especialização do trabalho.
• Cada subprojeto tem 2 papéis de liderança a serem
preenchidos, o do produtor e o do diretor técnico.
• O produtor e o diretor podem ser 1 só: equipes pequenas;
• O produtor pode ser chefe; o diretor, seu braço direito: grandes;
• O diretor pode ser chefe; o produtor, seu braço direito: respeito.
19. O Mítico Homem-Mês
Capítulo 8
Prevendo o Lançamento
Quanto tempo e esforço levará um trabalho de programação?
• Vai além da estimativa de tempo de codificação e da + de programas;
• Devem ser adicionados o tempo da documentação e outros.
• A programação aumenta exponencialmente de acordo com as
dimensões do programa, mesmo que não haja comunicação.
• A produtividade aumenta dependendo das ferramentas utilizadas.
20. O Mítico Homem-Mês
Capítulo 9
10Kg em um Saco de 5
• O espaço em memória ocupado por um programa
é um custo principal.
• Metas para controlar e reduzir o tamanho.
• Treinamento nas técnicas de programação para isso.
21. O Mítico Homem-Mês
Capítulo 10
A Hipótese dos Documentos
Quais os documentos necessários?
• “Um pequeno número de documentos torna-se o
eixo central ao redor do qual gira a gestão do
projeto”.
• O quê, quando, quanto, onde e quem?
22. Capítulo 11
O Mítico Homem-Mês
Inclua em seus Planos Descartar
• Plantas piloto e escalabilidade:
•
O único fator constante é a própria mudança;
•
Mudança: sistema e organização.
•
2 passos a diante e 1 passo atrás.
•
1 passo a diante a 1 passo atrás.
23. O Mítico Homem-Mês
Capítulo 12
Ferramentas Afiadas
• Máquinas-alvo: onde o software deve rodar e ser testado.
• Agendamento: “rodízio” para a utilização da máquina-alvo, de
modo que, dividido em blocos, cada equipe tenha um intervalo de
tempo para usá-la.
• Máquinas-veículo e serviço de dados: a procura de bugs.
• Veículos para a compilação e montagem: depuração por meio
da compilação e do teste de código.
24. O Mítico Homem-Mês
Ferramentas Afiadas
• Bibliotecas de programas e registros: ideia de controle, separação formal e progressão do playground.
• Sistema de documentação: é melhor o excesso do que a falta.
• Simulador de desempenho: parâmetro no desenvolvimento.
• Linguagem de alto nível: contribui para a produtividade e a
velocidade de depuração, porém tem objeções quanto a lerdeza e
o tamanho.
• Programação interativa: dobra a produtividade na programação.
25. O Mítico Homem-Mês
Capítulo 13
O Todo e suas Partes
• À prova de bugs: A tarefa crucial é ter um produto definido. Muitas
falhas referem-se a aspectos que nunca foram especificados”.
• Testando a especificação: o teste define se está clara.
• Projeto de cima para baixo:
• Evita bugs de várias maneiras: particionamento e independência
dos módulos, supressão de detalhes, outros.
• Facilita a precisa declaração de requisitos e funções de módulos.
26. O Mítico Homem-Mês
O Todo e suas Partes
• Depuração do sistema:
• Componentes depurados: inicia depois que todas as “peças”
pareçam funcionar.
• Degraus: programas/dados construídos a efeito de depuração.
• Controle de mudanças: alguém pode autorizar a modificação
de um componente ou a substituição de uma versão para outra.
• 1 componente por vez: para eliminar os bugs novos e antigos.
• Quantifique as atualizações: elas devem ser bastante grande e
amplamente espaçadas, ou muito pequenas e frequentes.
27. O Mítico Homem-Mês
Capítulo 14
Incubando uma Catástrofe
• A outra parte está atrasada também.
•
•
•
Qual a prioridade, PERT? Jogue pra debaixo do tapete!
Reduzindo o conflito de papéis: reuniões de revisões,
conferência de status, solução de problemas.
Levantando o tapete: revisão e relatórios requerem a
atenção de um grupo.
28. Capítulo 15
O Mítico Homem-Mês
A Outra Face
• Para usar um programa: propósito, ambiente, domínio e
variação, funções realizadas e outros.
• Para acreditar em um programa: cada cópia do programa deve
incluir casos de teste para saber se o programa está funcionando.
• Para modificar um programa: deve se deixar comentado.
• Programas autodocumentados: incorporados ao código fonte.
29. O Mítico Homem-Mês
Capítulo 16
Não Há Bala de Prata
• “Não há em desenvolvimento nenhuma tecnologia/técnica de
gerenciamento de projetos que por si só possibilitará desenvol-
ver sistemas 10x + rápido em um futuro de até 10 anos.” (Dito em 1986)
• A parte difícil de construir um SW é especificar, projetar e testar.
• E não, representar a estrutura conceitual ou testar a fidelidade da
representação.
30. Não Há Bala de Prata
O Mítico Homem-Mês
• Características do problema
1. Complexidade: em software não há 2 partes iguais. Elementos diferentes adicionados relacionam-se de várias maneiras.
Complexidade
Enumerar
estados
Comunicação
Falhas
Excesso
de custos
Atraso
Visão
geral
Não
confiável
Falha na integridade conceitual
Efeitos
colaterais
Mudança
de pessoal
31. O Mítico Homem-Mês
Não Há Bala de Prata
2. Conformidade: problemas ou complexidades em um software
podem ter raízes em entidades externas.
3. Mutabilidade: o software incorpora a função das coisas, e é na
função que existem pressões por mudanças. Considerando que
é mais fácil alterar um software do que um prédio, um carro,...
4. Invisibilidade: o mais perto de ver que se pode chegar é
produzir vários diagramas
32. O Mítico Homem-Mês
Não Há Bala de Prata
• Avanços passados que solucionaram problemas acidentais:
linguagens de alto nível, tempo compartilhado, IDE’s.
• Esperanças: linguagens de alto-nível, OO, IA, outros.
Qual a limitação deles?
• Só facilitam a parte braçal.
• Não habilitam a entender o que tem
que ser feito, nem a pensar de maneira
criativa as estruturas conceituais e
como elas se ligam.
33. O Mítico Homem-Mês
Não Há Bala de Prata
Ataques promissores na essência conceitual
• A maneira mais fácil de programar é não programando. Pegar pronto!
• Refinamento dos requisitos e prototipagem: mostrar ao cliente o
sistema em funcionamento mesmo que ele não trate as exceções, ou
atenda certos requisitos.
• Desenvolvimento incremental (de cima pra baixo): o sistema inteiro
deve estar sempre pronto para rodar, mesmo que algumas funções
estejam vazias.
• Grandes arquitetos: quem é mais criativo faz melhor.
• Software não é exato, cada um faz de uma forma diferente.
34. O Mítico Homem-Mês
Capítulo 17
“Não Há Bala de Prata” Refinado
O que aconteceu com a produtividade?
• Difícil de medir, mas há relatos de melhoras de 500% devido à
melhores estações de trabalho.
OO, uma bala de latão? Porque está sendo tão devagar?
• Muitos pensam em OO como linguagem.
• Estão em fase de adaptação, mas com futuro promissor
E quanto à reutilização?
• Grandes vocabulários (implementação de lista pronta, parâmetros).
35. O Mítico Homem-Mês
Capítulo 19
20 Anos Depois...
Integridade Conceitual
• Um produto de programação deve apresentar para cada um de seus
usuários um modelo mental claro e coerente da aplicação.
• “O resultado deve ser conceitualmente coerente para a mente de um
único usuário”.
• A gestão de grandes projetos de programação é qualitativamente
diferente de pequenos projetos, a coerência deve sempre ser atingida.
36. O Mítico Homem-Mês
20 Anos Depois
O Arquiteto
• Responsável pela integridade conceitual de todo o produto.
• Deve conhecer todas as funções e meios para chamá-las e controlá-las.
• Deve ter os conhecimentos de causa: funcionalidade, desempenho,
tamanho, custo e cronograma.
• Trabalho de tempo integral.
• No caso de produtos muito grandes, é necessário que o arquiteto geral
do sistema divida-o em subsistemas. Dessa forma cada subsistema terá
o seu próprio gerente.
37. O Mítico Homem-Mês
20 Anos Depois
Arquitetura x Implementação
• Separar a arquitetura (como o usuário percebe o programa) de sua
implementação.
• Definir um claro limite entre as partes, há muito trabalho de cada lado.
Ferramentas
• Ferramentas adicionais pode facilitar o uso de um aplicativo, mas
contudo pode prejudicar a performance do sistema.
• Uma análise recente do Word 6.0 diz “o Word 6.0 está carregada de
funcionalidades, sua atualização é lenta em função desta bagagem”.
38. O Mítico Homem-Mês
20 Anos Depois
Definindo o conjunto usuário
• Quanto maior o conjunto de usuário, maior é a necessidade pela
integridade conceitual.
• Cada membro da equipe terá uma imagem mental implícita da
necessidade do usuário, e a imagem de cada um será diferente.
• A imagem que o arquiteto tem do usuário é fundamental para uma
equipe chegar a uma imagem única, e isso requer a escrita de todos os
atributos do conjunto usuário (quem são, do que precisam,...).
39. O Mítico Homem-Mês
20 Anos Depois
Frequência
• Os atributos do conjunto usuário são uma distribuição com muitos
valores possíveis. Como o arquiteto deve determina tais valores?
• Pesquisar esse valores mal definidos é uma proposta cara e duvidosa.
• A melhor forma é fazer com que o arquiteto postule ou melhor adivinhe
esse conjunto de atributos, de forma cautelosa e com debates entre a
equipe o que esclarecerá as ideias de todos.
“É muito melhor ser explicito e estar errado do que ser vago.”