o mítico homem-mês

O Mítico

Homem-Mês

Carlos Filho Fabio Benigno Gabriel Gamaniel Jimmy Padilha Juliane Silva

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 Introdução

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 Capítulo 1

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;


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 Poço de Alcatrão


• 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!”



• 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



• 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.


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.


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

Aristocracia, Democracia e Projeto de Sistemas

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.


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.



• 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.



• 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!!!


Por Que a Torre de Babel Falhou?

Se eles tinham...• Uma missão clara;

• Recursos humanos;

• Materiais;

• Tempo suficiente;

• Tecnologia adequada.


Comunicação e organização.

O que faltou a eles?


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



• 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.


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.


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.


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?


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.


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.



• 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.

Ferramentas Afiadas

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.



• 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 Todo e suas Partes

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.


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.


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.



• Características do problema1. Complexidade: em software não há 2 partes iguais. Elemen-

tos diferentes adicionados relacionam-se de várias maneiras.


Complexidade

Comunicação

Falhas Excesso de custos Atraso

Enumerar estados

Não confiável

Visão geral

Falha na integri-dade conceitual

Efeitos colaterais

Mudança de pessoal


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



• 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.


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.


“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).


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

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”.

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

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.”

20 Anos Depois


Obrigado!

. . .Dúvidas???

o mítico homem-mês

Technology