Você está na página 1de 40

O Mítico

Homem-Mês

Carlos Filho Fabio Benigno Gabriel Gamaniel Jimmy Padilha Juliane Silva
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”.
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.
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;
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.
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!”
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
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.
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.
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.
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.
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.
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.
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.
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!!!


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.
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,...
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.
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.
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.
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?
O Mítico Homem-Mês Capítulo 11

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.
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.
O Mítico Homem-Mês Ferramentas Afiadas

• Bibliotecas de programas e registros: ideia de contro-


le, 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.


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.
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.
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.
O Mítico Homem-Mês Capítulo 15

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.


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.
O Mítico Homem-Mês Não Há Bala de Prata

• Características do problema
1. Complexidade: em software não há 2 partes iguais. Elemen-
tos diferentes adicionados relacionam-se de várias maneiras.

Complexidade

Enumerar Visão Efeitos Mudança


Comunicação
estados geral colaterais de pessoal

Excesso Não Falha na integri-


Falhas Atraso
de custos confiável dade conceitual
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
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.
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.
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).
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.
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.
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”.
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,...).
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.”


O Mítico Homem-Mês

Dúvidas???
...

Obrigado!