SlideShare ist ein Scribd-Unternehmen logo
1 von 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?
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.
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 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.
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.
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.
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.
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
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!

Weitere ähnliche Inhalte

Was ist angesagt?

Criatividade e Inovaçao
Criatividade e InovaçaoCriatividade e Inovaçao
Criatividade e InovaçaoJairo Siqueira
 
Palestra sobre Ecossistemas de Inovação
Palestra sobre Ecossistemas de InovaçãoPalestra sobre Ecossistemas de Inovação
Palestra sobre Ecossistemas de InovaçãoElvis Fusco
 
Big Data, o que é isso?
Big Data, o que é isso?Big Data, o que é isso?
Big Data, o que é isso?Ambiente Livre
 
Aula03 - Termo de Abertura de Projeto
Aula03 - Termo de Abertura de ProjetoAula03 - Termo de Abertura de Projeto
Aula03 - Termo de Abertura de ProjetoDaniela Brauner
 
Exercicio de Planejamento Estrategico
Exercicio de Planejamento EstrategicoExercicio de Planejamento Estrategico
Exercicio de Planejamento EstrategicoPAULO RICARDO FLORES
 
Aula Lógica de Programação - cap1
Aula Lógica de Programação - cap1 Aula Lógica de Programação - cap1
Aula Lógica de Programação - cap1 Cloves da Rocha
 
MASP - Método de Análise e Solução de Problemas
MASP - Método de Análise e Solução de ProblemasMASP - Método de Análise e Solução de Problemas
MASP - Método de Análise e Solução de ProblemasMárcio Hosken
 
Criatividade e Inovação
Criatividade e InovaçãoCriatividade e Inovação
Criatividade e InovaçãoRenato Melo
 
Metodologia Lean Startup
Metodologia Lean StartupMetodologia Lean Startup
Metodologia Lean StartupFranciele Sena
 
Fase de Imersão com Design Thinking
Fase de Imersão com Design ThinkingFase de Imersão com Design Thinking
Fase de Imersão com Design ThinkingUFPA
 
Inovação Tecnológica
Inovação TecnológicaInovação Tecnológica
Inovação TecnológicaSandro Servino
 
Sistema Toyota de Produção - Produção Enxuta x Desenvolvimento Lean
Sistema Toyota de Produção - Produção Enxuta x Desenvolvimento LeanSistema Toyota de Produção - Produção Enxuta x Desenvolvimento Lean
Sistema Toyota de Produção - Produção Enxuta x Desenvolvimento LeanMayra de Souza
 
KPI Indicadores de Desempenho Financeiro
KPI Indicadores de Desempenho FinanceiroKPI Indicadores de Desempenho Financeiro
KPI Indicadores de Desempenho FinanceiroLuciano Morato
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - ResumoDaniel Brandão
 

Was ist angesagt? (20)

Criatividade e Inovaçao
Criatividade e InovaçaoCriatividade e Inovaçao
Criatividade e Inovaçao
 
Palestra sobre Ecossistemas de Inovação
Palestra sobre Ecossistemas de InovaçãoPalestra sobre Ecossistemas de Inovação
Palestra sobre Ecossistemas de Inovação
 
Big Data, o que é isso?
Big Data, o que é isso?Big Data, o que é isso?
Big Data, o que é isso?
 
Aula03 - Termo de Abertura de Projeto
Aula03 - Termo de Abertura de ProjetoAula03 - Termo de Abertura de Projeto
Aula03 - Termo de Abertura de Projeto
 
Pilares da Inovação
Pilares da InovaçãoPilares da Inovação
Pilares da Inovação
 
Exercicio de Planejamento Estrategico
Exercicio de Planejamento EstrategicoExercicio de Planejamento Estrategico
Exercicio de Planejamento Estrategico
 
Aula gestão da inovação
Aula gestão da inovaçãoAula gestão da inovação
Aula gestão da inovação
 
Engenharia de software - Prototipo
Engenharia de software - PrototipoEngenharia de software - Prototipo
Engenharia de software - Prototipo
 
Aula Lógica de Programação - cap1
Aula Lógica de Programação - cap1 Aula Lógica de Programação - cap1
Aula Lógica de Programação - cap1
 
MASP - Método de Análise e Solução de Problemas
MASP - Método de Análise e Solução de ProblemasMASP - Método de Análise e Solução de Problemas
MASP - Método de Análise e Solução de Problemas
 
Criatividade e Inovação
Criatividade e InovaçãoCriatividade e Inovação
Criatividade e Inovação
 
Metodologia Lean Startup
Metodologia Lean StartupMetodologia Lean Startup
Metodologia Lean Startup
 
Fase de Imersão com Design Thinking
Fase de Imersão com Design ThinkingFase de Imersão com Design Thinking
Fase de Imersão com Design Thinking
 
Inovação Tecnológica
Inovação TecnológicaInovação Tecnológica
Inovação Tecnológica
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Sistema Toyota de Produção - Produção Enxuta x Desenvolvimento Lean
Sistema Toyota de Produção - Produção Enxuta x Desenvolvimento LeanSistema Toyota de Produção - Produção Enxuta x Desenvolvimento Lean
Sistema Toyota de Produção - Produção Enxuta x Desenvolvimento Lean
 
O que é Brainstorming?
O que é Brainstorming?O que é Brainstorming?
O que é Brainstorming?
 
KPI Indicadores de Desempenho Financeiro
KPI Indicadores de Desempenho FinanceiroKPI Indicadores de Desempenho Financeiro
KPI Indicadores de Desempenho Financeiro
 
Mudança organizacional
Mudança organizacionalMudança organizacional
Mudança organizacional
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 

Ähnlich wie O Mítico Homem-Mês e a Gestão de Projetos de Software

The Mythical Man-Month
The Mythical Man-MonthThe Mythical Man-Month
The Mythical Man-Monthpizzol
 
The Mythical Man-Month
The Mythical Man-MonthThe Mythical Man-Month
The Mythical Man-Monthpizzol
 
O ciclo da vida
O ciclo da vidaO ciclo da vida
O ciclo da vidaLuiz Borba
 
Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Leandro Silva
 
Implementing lean software development
Implementing lean software developmentImplementing lean software development
Implementing lean software developmentLuiz Faias Junior
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoAchiles Camilo
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosWilliam Lima
 
Projetos Estruturados de Redes - Parte 1
Projetos Estruturados de Redes - Parte 1Projetos Estruturados de Redes - Parte 1
Projetos Estruturados de Redes - Parte 1José Wagner Bungart
 
Aula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisAula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisDaniela Brauner
 
Como automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOpsComo automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOpsRafael Salerno de Oliveira
 
Projeto de sistemas com UML - Parte 1
Projeto de sistemas com UML - Parte 1Projeto de sistemas com UML - Parte 1
Projeto de sistemas com UML - Parte 1Natanael Simões
 
Equipes de sucesso final
Equipes de sucesso finalEquipes de sucesso final
Equipes de sucesso finalPaulo Mattos
 
Aula 1 introducao
Aula 1   introducaoAula 1   introducao
Aula 1 introducaolicardino
 
Escalando infra em ops em um ambiente de hiper crescimento
Escalando infra em ops em um ambiente de hiper crescimentoEscalando infra em ops em um ambiente de hiper crescimento
Escalando infra em ops em um ambiente de hiper crescimentoRenan Capaverde
 

Ähnlich wie O Mítico Homem-Mês e a Gestão de Projetos de Software (20)

The Mythical Man-Month
The Mythical Man-MonthThe Mythical Man-Month
The Mythical Man-Month
 
The Mythical Man-Month
The Mythical Man-MonthThe Mythical Man-Month
The Mythical Man-Month
 
O ciclo da vida
O ciclo da vidaO ciclo da vida
O ciclo da vida
 
Scrum
ScrumScrum
Scrum
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
 
Scrum em 1h.
Scrum em 1h.Scrum em 1h.
Scrum em 1h.
 
Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012
 
Implementing lean software development
Implementing lean software developmentImplementing lean software development
Implementing lean software development
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
SCRUM.pptx
SCRUM.pptxSCRUM.pptx
SCRUM.pptx
 
Projetos Estruturados de Redes - Parte 1
Projetos Estruturados de Redes - Parte 1Projetos Estruturados de Redes - Parte 1
Projetos Estruturados de Redes - Parte 1
 
Aula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisAula05 - Metodologias Ágeis
Aula05 - Metodologias Ágeis
 
Como automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOpsComo automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOps
 
Enter SCRUM
Enter SCRUMEnter SCRUM
Enter SCRUM
 
Projeto de sistemas com UML - Parte 1
Projeto de sistemas com UML - Parte 1Projeto de sistemas com UML - Parte 1
Projeto de sistemas com UML - Parte 1
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Equipes de sucesso final
Equipes de sucesso finalEquipes de sucesso final
Equipes de sucesso final
 
Aula 1 introducao
Aula 1   introducaoAula 1   introducao
Aula 1 introducao
 
Escalando infra em ops em um ambiente de hiper crescimento
Escalando infra em ops em um ambiente de hiper crescimentoEscalando infra em ops em um ambiente de hiper crescimento
Escalando infra em ops em um ambiente de hiper crescimento
 

Mehr von Juliane Silva

Arquitetura ARM - Raspberry Pi
Arquitetura ARM - Raspberry PiArquitetura ARM - Raspberry Pi
Arquitetura ARM - Raspberry PiJuliane Silva
 
Processamento de Documento Multimídia
Processamento de Documento MultimídiaProcessamento de Documento Multimídia
Processamento de Documento MultimídiaJuliane Silva
 
Análise dos Modelos SCAP, Vetorial e Okapi BM25 para Atribuição de Autoria de...
Análise dos Modelos SCAP, Vetorial e Okapi BM25 para Atribuição de Autoria de...Análise dos Modelos SCAP, Vetorial e Okapi BM25 para Atribuição de Autoria de...
Análise dos Modelos SCAP, Vetorial e Okapi BM25 para Atribuição de Autoria de...Juliane Silva
 
Padrão de Projeto - Decorator
Padrão de Projeto - DecoratorPadrão de Projeto - Decorator
Padrão de Projeto - DecoratorJuliane Silva
 

Mehr von Juliane Silva (8)

Arquitetura ARM - Raspberry Pi
Arquitetura ARM - Raspberry PiArquitetura ARM - Raspberry Pi
Arquitetura ARM - Raspberry Pi
 
Conversores D/A
Conversores D/AConversores D/A
Conversores D/A
 
Processamento de Documento Multimídia
Processamento de Documento MultimídiaProcessamento de Documento Multimídia
Processamento de Documento Multimídia
 
Análise dos Modelos SCAP, Vetorial e Okapi BM25 para Atribuição de Autoria de...
Análise dos Modelos SCAP, Vetorial e Okapi BM25 para Atribuição de Autoria de...Análise dos Modelos SCAP, Vetorial e Okapi BM25 para Atribuição de Autoria de...
Análise dos Modelos SCAP, Vetorial e Okapi BM25 para Atribuição de Autoria de...
 
Globus Toolkit
Globus ToolkitGlobus Toolkit
Globus Toolkit
 
Simple Factory
Simple FactorySimple Factory
Simple Factory
 
Padrão de Projeto - Decorator
Padrão de Projeto - DecoratorPadrão de Projeto - Decorator
Padrão de Projeto - Decorator
 
Framework Yii
Framework YiiFramework Yii
Framework Yii
 

O Mítico Homem-Mês e a Gestão de Projetos de Software

  • 1. O Mítico Homem-Mês Carlos Filho Fabio Benigno Gabriel Gamaniel Jimmy Padilha Juliane Silva
  • 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.”