Resenha do livro O Mitico Homem - Mês

Prévia do material em texto

Resenha do livro “O Mítico Homem-Mês” 
Aluno: Fabrício de Oliveira da Silva Engenharia Civil 
 
O Mítico Homem-Mês foi a primeira obra literária de grande impacto que 
expôs claramente as peculiaridades da indústria de software. Por isso, se 
tornou um clássico e leitura indispensável à formação de todos os profissionais 
que estão envolvidos diariamente com projetos de desenvolvimento de 
software e seu gerenciamento. O autor traz uma obra com os pensamentos 
mais atuais sobre o tema e uma retrospectiva sobre as principais mudanças 
ocorridas desde o lançamento da primeira edição do livro, em 1975. 
O capítulo que dá nome ao livro fala sobre como a produtividade de uma 
equipe não é linear em relação a quantidade de pessoas que ela possui. Se um 
projeto precisa de seis meses para ser implementado por um desenvolvedor, 
ele não pode ser feito em um mês por seis desenvolvedores. 
“Homens e meses são intercambiáveis apenas quando uma tarefa pode 
ser dividida entre muitos trabalhadores que não se comuniquem entre si. (…) 
não é sequer aproximadamente real quando se trata de programação de 
sistemas.” 
Mas mais importante que desmistificar a relação entre desenvolvedores 
e meses de trabalho, é entender que quanto maior uma empresa, melhor ela 
tem que se comunicar para ganhar velocidade. 
Boa comunicação nesse caso não se trata apenas de reuniões. Você 
pode se comunicar bem escrevendo código compreensível; mantendo cards 
atualizados e bem descritos no board; fazendo commits e pull requests claros; 
e em geral, garantindo que as pessoas têm acesso às informações que 
precisam para desempenhar seu trabalho com autonomia. 
Muitas das ferramentas e práticas ágeis que se popularizaram nas 
últimas décadas tem a finalidade de lidar com questões como essa. Jira, Trello, 
Github, Slack, Hangouts, Scrum, Kanban, e etc, estão fundamentalmente 
melhorando a comunicação, e não devemos usa-las apenas como mais uma 
forma de gerar interrupção e ansiedade. 
Além de desenvolver software preparado para mudança (com código 
limpo, alta coesão, baixo acoplamento, testes automatizados, e etc), Brooks 
fala que é importante planejar a organização como um todo para mudanças. 
“Cada indivíduo deve ser designado para um trabalho que amplie seus 
horizontes, de maneira que toda a força de trabalho seja tecnicamente flexível.” 
Ele está falando especificamente sobre grandes times técnicos, com 
centenas de desenvolvedores implementando desde compiladores até 
interfaces visuais. Imagine ajustar o leme de um navio desse tamanho, com 
essa complexidade. 
Entretanto, essa forma de pensar para mim faz sentido inclusive para 
startups com times enxutos que precisam fazer progresso em meio a incerteza. 
Se a empresa está acelerando em uma direção e descobre que está indo para 
o caminho errado, o que se espera de uma startup é que ela seja capaz de 
ajustar a direção rapidamente. É fundamental que os times tenham capacidade 
de se adaptar e de perceber as mudanças necessárias. 
No capítulo que se chama “Aristocracia, Democracia e Projeto de 
Sistemas”, Brooks dá ênfase à importância de um software ter “integridade 
conceitual”. O produto deve fazer sentido para o usuário. 
Ele argumenta que a forma mais simples de alcançar isso seria 
separando as responsabilidades de “arquitetura” e “implementação”, sendo o 
arquiteto responsável por dizer o que fazer (ou seja, definir especificações 
externas do sistema) e o implementador em dizer como fazer. Além disso, ele 
propõe que, assim como a arquitetura de um edifício é idealizada por uma ou 
poucas mentes, devemos limitar essas decisões a poucas pessoas e isso 
levaria a escolhas melhores e mais rápidas no projeto. 
Isso não significa que o trabalho criativo ficaria sob responsabilidade de 
poucas pessoas porque ambas as funções demandam criatividade. Hoje em 
dia vemos essas responsabilidades serem divididas em papéis como product 
owners, designers e desenvolvedores — todos com trabalhos que exigem 
inovação. 
Trazendo esse assunto a um contexto mais atual, podemos olhar para o 
que acontece com os sistemas operacionais iOS e Android. Para a Apple, é 
muito mais fácil obter integridade conceitual por um motivo muito simples: 
existem poucos aparelhos que rodam o sistema, e a própria empresa os 
produz. Especialmente no início da popularização dos smartphones isso foi um 
valor percebido pelos usuários, porque eles simplesmente achavam o iPhone 
melhor e mais fácil de usar, e é um legado relevante até hoje. Por outro lado, o 
Android tem uma vida muito mais dura nesse quesito porque existem milhares 
de celulares com especificações muito diferentes (de hardware e software) 
rodando o sistema. 
Por fim, o livro termina com dois capítulos adicionados nas edições de 
10 e 20 anos, que são os meus favoritos. Brooks argumenta que os ganhos de 
produtividade que ele observava na época tratavam de melhorias em tarefas 
que ele chama de “acidentais”, como por exemplo “limites severos de 
hardware” e “linguagens de programação deselegantes”. A ideia principal 
trazida nesses capítulos é a de que não existe uma bala de prata para os 
problemas essenciais do desenvolvimento de software. 
“Acredito que a parte mais difícil na construção de software é a 
especificação, o projeto e o teste do seu construto conceitual, não o trabalho de 
representá-lo e testar a fidelidade da representação.” 
Apesar de parecerem capítulos desanimadores, essa não é essa a 
intenção do autor. As melhorias em problemas acidentais têm sido 
importantíssimas. Como exemplo, a adoção e amadurecimento da prática de 
implementar testes melhorou muito a experiência de escrever código — é um 
investimento que aumenta a qualidade do produto, e reduz o estresse dos 
programadores ao liberar versões. Muda completamente a prática de 
desenvolver software em equipe. 
Mesmo assim, Brooks sugere alternativas para tentar atacar os 
problemas essenciais: com “prototipagem rápida” e “desenvolvimento 
incremental”. Veja só, antes de “A Startup Enxuta” (e de diversos livros 
publicados na última década que propõe a construção de empresas por ciclos 
curtos de aprendizagem), Brooks já falava sobre isso em seu paper de 1986. 
 É curioso ver como o autor teve visões acertadas sobre diversos 
problemas na engenharia de software. No capítulo O Todo e as Partes, apesar 
dele estar descrevendo questões técnicas datadas, no fundo ele está 
apresentando princípios atuais de integração contínua, testes e versionamento, 
tudo isso vinte a trinta anos antes da popularização do XP. 
Na minha opinião a leitura é cansativa em alguns pontos, mas 
recomendo a todos que desenvolvem software hoje em dia.