Resenha do livro nova

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.