Casa > Programação > Não-ficção > Ciência da Computação > O Mês do Homem Mítico: Ensaios sobre Engenharia de Software Reveja

O Mês do Homem Mítico: Ensaios sobre Engenharia de Software

The Mythical Man-Month: Essays on Software Engineering
Por Frederick P. Brooks Jr.
Avaliações: 30 | Classificação geral: média
Excelente
11
Boa
4
Média
10
Mau
3
Horrível
2
Poucos livros sobre gerenciamento de projetos de software foram tão influentes e atemporais quanto The Mythical Man-Month. Com uma mistura de fatos de engenharia de software e opiniões instigantes, Fred Brooks oferece insights para quem gerencia projetos complexos. Esses ensaios foram extraídos de sua experiência como gerente de projetos da família de computadores IBM System / 360 e, em seguida, para o OS / 360, seu enorme

Avaliações

05/18/2020
Maren Lepke

Neste livro clássico sobre o processo de desenvolvimento de software, Fred Brooks destrói vários mitos persistentes. Eles nunca desaparecem: toda nova geração apenas precisa aprendê-las novamente.

O primeiro e mais perigoso desses mitos é a crença de que colocar mais pessoas em um projeto significa que ele será concluído mais rapidamente. Brooks inclui um dos gráficos mais brilhantes que eu já vi, plotando o número de mulheres contra o tempo necessário para produzir um bebê. Você acreditaria: o gráfico é plano em nove meses, independentemente de quantas mulheres são designadas para o projeto. Como ele ressalta, o desenvolvimento de software geralmente é notavelmente semelhante.

Se você é um jovem desenvolvedor de software e ficou surpreso com o exposto acima, deve adquirir uma cópia do Brooks sem demora. Algumas de suas observações agora podem ser um pouco datadas, mas a maioria ainda é bastante relevante.
05/18/2020
Mori Duhon

Até onde eu sei, os princípios básicos deste livro não estão mais em disputa. Não pretendo soar como o leitor rabugento mencionado no epílogo, reclamando que o livro oferecia "nada que eu não sabia já sabia" (por mais experiente que ele tenha sido, ainda duvido), mas seja do meu limitado experiência no setor em primeira mão ou em segunda mão através dos vários gerentes que tive ao longo dos anos, o princípio de que desenvolvedores e tempo não são recursos intercambiáveis ​​parecia familiar e auto-evidente. Então, em certo sentido, não sinto que tenha mais negócios criticando isso como um livro do que "Relatividade: a teoria especial e geral". Ainda assim, outra parte do meu cérebro está contente em separar uma crítica do livro como um livro de qualquer tipo de disputa com os argumentos reais e compartilhe alguns snipes mesquinhos que tornaram essa leitura menos agradável do que poderia ter sido:

1) Sua recusa obstinada em reconhecer a realidade das programadoras.

Essa tendência frustrante começa com o título (o que diabos é um mês "homem"? Seu projeto precisa de barbas para crescer ou código para ser escrito?) E apenas nunca. Vamos. Acima. Exceto por um "ela" gramaticalmente necessário ao mencionar Frances Spence (na página final!), Não tenho certeza de que os pronomes femininos apareçam uma vez neste livro inteiro. Certamente, "eles" não tinham a mesma legitimidade que um pronome singular neutro em relação ao gênero que o de hoje, mas essa coisa foi relançada em 1995, uma época em que "eles" poderiam estar na vanguarda, mas "ele ou ela "era prática comum mesmo na gramática da escola primária. Também não são apenas desenvolvedores - arquitetos de sistemas, gerentes, todos da "equipe cirúrgica"; diabos, mesmo os USUÁRIOS, pelo menos aqueles que têm alguma iniciativa em testar os limites do software, são todos masculinos por padrão.

Espere, lembrei-me - as mulheres aparecem. Parafraseando: "você não pode engravidar nove mulheres e esperar um bebê em um mês".

Ugh.

Tenho certeza de que esse não é um argumento novo a ser feito, e tenho certeza de que ele respondeu com graça e sinceridade sobre como o padrão de escrita que ele criou com pronomes masculinos usados ​​como uma conveniência para se referir a TODOS, e, claro, teve o prazer de trabalhar com muitas mulheres competentes e até visionárias ao longo dos anos, e tal e tal e tal. Se tornar o texto original um pouco mais inclusivo em termos de gênero foi uma supervisão inocente da parte de Brooks, seu editor da reedição recebe menos um passe livre. Código das mulheres. Como cortesia a eles, atualize sua gramática.

2) As implicações religiosas gratuitas

Não me interpretem mal - eu ainda me lembro vividamente do êxtase quase espiritual daquele primeiro dia em que realmente "recebi" recursão, e compreendo perfeitamente como alguém pode posicionar a beleza do design de software dentro de sua atual estrutura de espiritualidade, o cristianismo. Infelizmente, uma conseqüência da construção de toda a sua cosmologia em torno de um ser como o Deus monoteísta ocidental é que ele necessariamente consome tudo e qualquer outra coisa; torna-se quase impossível escrever sobre a beleza ou nobreza de alguma busca ou princípio, exceto na medida em que supostamente emana de a natureza dessa suposta entidade. Uma conexão entre o bom design de software e as idéias cristãs de santidade surgem repetidas vezes, e elas me irritam não apenas por parecerem um pouco santimoniais, mas porque, muitas vezes, as lentes cristãs distorcem o conteúdo.

Dois exemplos vêm à mente: o primeiro vem no capítulo "Aristocracia, Democracia e Design de Sistemas", que defende a integridade conceitual como a virtude suprema de um sistema de software. Concordo que o livro anteceda todos os avanços que tornaram possíveis sistemas de código aberto possíveis ou a conquista do GNU / Linux para provar que era um modelo viável, mas Brooks parece tão envolvido na analogia do software semelhante a Deus arquiteto que ele nunca considera justa o modelo pagão do "bazar" - a "catedral" é evidentemente superior a quem acredita sinceramente que o mundo inteiro representa um projeto unificado e intencional por uma única entidade.

O segundo está no capítulo "Por que a Torre de Babel falhou?", E minha objeção se resume a isso: a Torre de Babel não falhou porque os construtores "careciam de organização e comunicação". Falhou porque um onipotente foi intervindo para torná-lo impossível ter organização e comunicação; isso aconteceu, por sua vez, porque o Deus cristão (e especialmente o Deus do Antigo Testamento) é um ser irado, rancoroso e às vezes francamente mesquinho, e que o empreendimento humano organizado de construir essa torre representava um desafio à sua autoridade. A interpretação que Brooks optou por confundir causas próximas e finais, o que dificultou a compra de qualquer coisa que se seguisse, por mais legítimos que fossem os pontos.
05/18/2020
Prissy Monteforte

Como o que sei sobre programação provavelmente poderia estar escrito no verso de um cartão postal e não valeria a pena ler, não há nada que valha a pena dizer sobre o lado da engenharia de software desta coleção de ensaios sobre engenharia de software.

Além disso, Brooks estava escrevendo nos anos 60, em parte com base na experiência dos anos 50, o que suponho significa que estarei reivindicando uma maior aplicabilidade em relação ao gerenciamento de projetos e gerenciamento de pessoas e à compreensão da natureza das tarefas.

Eu li a edição do 20º aniversário, que eu me lembro como não sendo barata e para justificar o preço, é amplamente disposto com muitas fotos em preto e branco de animais pré-históricos capturados em um poço de alcatrão, a Torre de Babel, lobisomens e outras coisas que saltam como metáforas para explicar a experiência de certos projetos, não há um Zeppelin em chamas, mas talvez isso seja retificado em uma edição futura.

Vou prosseguir com breves resumos dos ensaios:
The Pit Pit ?
O Mês do Homem Mítico - se um projeto estiver atrasado, a adição de mão-de-obra adicional atrasará ainda mais, principalmente se a natureza do projeto exigir comunicação entre os membros da equipe.
A equipe cirúrgica uma equipe de projeto é melhor organizada com funções fixas e exclusivas, cada membro focado em uma tarefa - como uma equipe cirúrgica, essa abordagem é escalável se um projeto grande puder ser dividido em partes apropriadas
Aristocracia, democracia e design de sistemas Seja como os construtores da Catedral de Reims, aceite a criatividade de implementar a visão de outra pessoa para alcançar o maior de todos em harmonia
O segundo efeito do sistemaO projetista de seu primeiro sistema se sentirá à vontade, e tão cauteloso e enxuto, o segundo sistema tenderá a se encher de detalhes barrocos e idéias para animais de estimação.
passando a palavra Eu acho que era sobre a documentação do projeto
Por que a Torre de Babel caiuproblemas de comunicação também não importunam Deus desnecessariamente.
Chamando a foto ?
dez libras em um saco de cinco libras ?
A hipótese documental
planeja jogar um fora mais ou menos o que diz
ferramentas afiadas coisas do computador, essas coisas nunca vão pegar.
o todo e as partes como acima, e saia do meu gramado
eclodindo uma catástrofe "Como um projeto chega atrasado um ano? .. Um dia de cada vez"(P.246)
a outra cara ?
nenhuma bala de prata Boas notícias para os lobisomens, não há balas de prata.

Em seguida, os pontos principais são repetidos resumidamente nas páginas 230-250, evitando a necessidade do restante do livro.

Eu tinha ouvido algumas páginas no capítulo No Silver Bullet na primeira vez em que o li, mas foi outra pessoa que o leu, e eu não conseguia ver ou imaginar o que chamou sua atenção. Aparentemente estou morto para mim (ver spoiler)[o que provavelmente é o melhor, você sabe, esse crânio não é grande o suficiente para nós dois, e tudo isso (ocultar spoiler)]!

O que foi exposto acima parece bastante relutante, principalmente nos capítulos que pareciam insípidos demais para merecer algo mais que um ponto de interrogação. No entanto, achei este livro muito emocionante na primeira vez (e não apenas por causa da imagem da mega fauna pré-histórica capturada em um tarpit (ver spoiler)[embora a influência disso na minha compreensão imaginativa do trabalho do projeto não deva ser subestimada (ocultar spoiler)]) Para isso, existem duas razões. Primeiramente. como ele reconhece, é um livro sobre programação de software, e o tema são as pessoas que trabalham em equipes para fornecer um produto de serviço para os usuários finais, e ele estava familiarizado com o software, mas meu segundo motivo é que este é um livro de sabedoria e essa sabedoria é amplamente aplicável - qualquer organização que entrega um produto ou serviço aos usuários finais (que podem ou não ser as pessoas que pagam). Claramente, a desvantagem de um texto de sabedoria é que ele é apócrifo (ver spoiler)[isto é, anedótico e derivado (ocultar spoiler)] mas tenho idade e feio o suficiente para viver com isso, de fato, como na literatura da sabedoria, achei isso tão tranquilizador quanto instrutivo. Eu havia notado que adicionar pessoas ao projeto tardio não acelera a entrega do que a adição de mulheres extras para ajudar na gravidez, mas eu não ousaria admitir que isso é contrário à ortodoxia do "bom senso" ao meu redor. De fato, o trabalho adicional não só me causou trabalho extra, mas também me fez chorar em uma pequena sala de reuniões. Brooks cita com aprovação outros escritores (pp276-7) de que a natureza do trabalho não é tecnológica, mas sociológica; portanto, talvez, o apelo duradouro de trabalhar para si mesmo.

Além disso, seu ponto de vista sobre os usuários finais influenciou meu pensamento, ele diz que o ponto de programação não é criar um programa que possa fazer uma coisa ou outra, mas satisfazer o usuário (ver spoiler)[ou o comprador, não necessariamente a mesma pessoa (ocultar spoiler)] o que, para mim, foi uma mudança de paradigma, da prestação de um serviço técnico definível, à satisfação do cliente e, de fato, pode-se destacar que, particularmente se você pensar em serviços públicos, você tem várias partes esperando resultados diferentes de um serviço.

Portanto, possivelmente, não posso, com justiça, recomendar amplamente este livro, os frutos que colhi dele podem não agradar aos gostos dos outros; na verdade, você pode não encontrar nada de novo ou saboroso lá, principalmente se você é um antropólogo atencioso do local de trabalho.

No software, sua defesa da microficha três vezes nobre pode ser muito peculiar para o gosto contemporâneo, e geralmente para todos os leitores, todos os trabalhadores deste livro e todos os trabalhadores presumidos, unidos em todo o mundo, são homens, que para alguém que não estava trabalhando apenas nos anos 50, mas nos anos 70 e 80, me parece interessante.
05/18/2020
Lougheed Novitski

Exceto sexismo flagrante *, era um livro muito bom. É uma série de experiências que você obtém gradualmente quando trabalha na indústria de software. Está um pouco desatualizado, por exemplo, não temos mais manuais impressos e não precisamos lidar com os problemas de atualizá-los constantemente, mas muitas sabedorias deste livro ainda são valiosas.


* o livro inteiro nunca usa um pronome feminino. sempre. faz parecer que engenheiros, gerentes, líderes técnicos, clientes são sempre apenas homens. Além disso, há isso:
'Uma equipe de dois, com um líder , geralmente é o melhor uso das mentes. [Observe o plano de Deus para o casamento.] 'Você realmente teve que incluir suas opiniões patriarcais ultrapassadas e conservadoras em um livro de não ficção sobre ciência da computação?
05/18/2020
Vivianna Zegarra

Quero imprimir muitas cópias deste livro.
Quero imprimir várias cópias e enrolá-las.
Quero enrolá-los e levá-los para reuniões com meus clientes.
Eu quero levá-los para as reuniões e bater na cabeça deles repetidamente enquanto grita "mais ... que ... 30 ... anos ... e você ... ainda ... não ... não entende. .. qualquer coisa ... pare ... de me fazer ... escrever ... software ruim ...! "

Sério.
05/18/2020
Pressman Blasini

O Mítico Homem-Mês começos fortes - com uma sólida mistura de bom humor, ótimas histórias e analogias e metáforas ainda melhores. Mais interessante, as alegações de Frederick Brooks feitas há mais de 40 anos permanecem verdadeiras hoje. Mas, mesmo assim, o livro não envelheceu bem.

Os capítulos 5-8 e 9-15 parecem desatualizados. Apresento alguns raciocínios abaixo, mas a essência é que o meio é basicamente ignorável. Pior é que as conotações religiosas ficam um pouco fora de controle nesta seção. E para tornar ainda mais óbvio o quão desatualizado, o sexismo é galopante - onde Brooks intencionalmente usa "ele" para cada pronome. É verdade que quase todos os programadores eram do sexo masculino na época, então não é como se o uso dele fosse enganador. Mas, lendo-o nesta época, parece que o livro pretende ser sexista.

Além do uso questionável do pronome, os quatro primeiros capítulos, o capítulo 7 e os capítulos finais ainda são realmente perspicazes. Eles detalham principalmente como e por que o desenvolvimento de software custa tanto (ainda hoje) e por que é improvável que a adição de mais engenheiros a um projeto acelere a produtividade linearmente.

O ponto principal é que os maiores problemas no desenvolvimento de software decorrem de 1) comunicação e organização e 2) gerenciamento de complexidade adicional. De certa forma, acho que sempre soube disso. Mas os capítulos o articularam de maneira muito clara e convincente.

Isso me faz pensar por que as entrevistas de engenharia selecionam tanto para a solução de problemas e dificilmente para as habilidades de comunicação e organização, ou a capacidade de gerenciar a crescente complexidade.


Eu recomendo os capítulos 1-4, 7 e 16+. Aqui está um resumo de por que eu pularia o resto:

O capítulo 5 pode ser resumido com a famosa citação de Ernest Hemingway: "O primeiro rascunho de tudo é uma merda". Brooks fornece explicações detalhadas sobre por que o primeiro rascunho de cada programa é uma merda e como se preparar para isso e projetá-lo. O capítulo 11 reitera isso principalmente.

O capítulo 6 descreve o quão complicado o manual do OS / 360 se tornou. Embora perspicazes - por causa de quão ridiculamente desatualizada é - os manuais foram substituídos principalmente por sites gerados automaticamente. Mas na época do OS / 360, quando os engenheiros chegaram ao trabalho, uma pilha de páginas aguardava em sua mesa. Essas páginas representavam as alterações feitas no sistema no dia anterior, e o engenheiro deveria encontrar as páginas no manual CINCO-FOOT-TALL e substituí-las por essas novas páginas. Brooks registra os problemas de manutenção de um manual assim e como a mudança para um manual de microfichas ajudou em alguns aspectos, mas prejudicou em outros.

O capítulo 10 fala sobre documentos importantes para uma organização de software. Embora possam ter relevância em uma grande configuração corporativa, eles pareciam bastante deslocados em um ambiente de inicialização.

O capítulo 13 explica as propriedades de uma boa estrutura de teste, basicamente pregando a importância dos testes de unidade e de integração. Isso é um dado adquirido no ambiente de trabalho moderno, pois toda empresa pelo menos sabe da importância.

O Capítulo 14 explica da mesma forma a importância de marcos ou objetivos principais com pontos de extremidade claramente discerníveis e verificáveis. Novamente, isso é um dado adquirido no local de trabalho moderno. O Kanban, o Agile e todos os outros Ciclos de Vida de Desenvolvimento de Software giram em torno disso.

O capítulo 15 explica a importância da documentação. Mas, olhando para o futuro, Brooks vê isso se tornando obsoleto, admitindo que linguagens mais recentes da época, como Ada, permitiam que o código fosse quase legível por humanos. Atualmente, o código é legível por humanos o suficiente para que a maioria dos programadores prefira que o código seja "auto-documentado". Está sempre em debate se o código escrito é de fato auto-documentado. Mas a importância da documentação diminui constantemente à medida que as linguagens se tornam cada vez mais declarativas, e os sistemas são cada vez melhores.
05/18/2020
Lubbock Kineard

Li este livro originalmente na faculdade e depois o reli depois de alguns anos de codificação profissional. Embora existam certamente algumas seções datadas, como a ideia de codificar o análogo de uma equipe cirúrgica, muitas das sugestões se mantiveram contra o teste do tempo.

Os dois mais populares são "sem balas de prata" e "adicionar desenvolvedores a um projeto atrasado o torna mais tarde". O primeiro é que nenhuma nova tecnologia / técnica fará uma diferença de ordem de magnitude na produtividade há mais de 10 anos. Isso é especialmente importante quando se lida com fornecedores ou com o mais recente proselitista de uma ideologia de linguagem ou processo. Acho que esse é um bom complemento à opinião de Robert Glass de que a maior diferença nas equipes produtivas é a qualidade dos desenvolvedores. O segundo é mais auto-explicativo. O aumento do custo da adição de novos desenvolvedores excede o valor que eles oferecerão dentro de um período de tempo razoável.

Também há lições menos referenciadas a serem colhidas no livro. Por exemplo, muito antes do Agile, este livro evitou o desenvolvimento em cascata em favor de uma abordagem iterativa. Minha lição favorita no livro é a da integridade conceitual. Em essência, é assim que Brooks se refere à idéia de que um software deve fazer uma coisa bem e, se tentar se encaixar em muitas funções, será um ajuste inadequado para todos eles, em vez de um ajuste adequado para um. Como exemplo, ele cita várias catedrais que levaram séculos para serem concluídas. As catedrais vítimas de arquitetos egoístas nos estágios intermediários ou posteriores da construção são menos esteticamente consistentes e, portanto, atraentes do que aquelas em que o estilo original foi respeitado.

Brooks também recomenda manter duas carreiras independentes para desenvolvedores. Em muitas organizações, os desenvolvedores são forçados a gerenciar após um certo nível. Brooks argumenta que isso é um erro e que, em muitos casos, é melhor deixar alguns desenvolvedores permanecerem como desenvolvedores. Isso requer paridade de título e remuneração com a faixa de gerenciamento.

Embora muitos dos exemplos específicos de tecnologia estejam datados, o Mythical Man Month é uma leitura recomendada para todos os desenvolvedores.
05/18/2020
Jourdain Citarelli

Fiquei desapontado com o quanto esse texto envelheceu. As referências, que faziam sentido há 15 anos, não retêm mais a água, e o projeto mais referenciado certamente não é mais o modo como escrevemos software atualmente. Embora a idéia permaneça válida, acho que as pessoas que escrevem sobre este texto são mais relevantes que o próprio texto, mantendo apenas valor histórico, no máximo.
05/18/2020
Howe Sempek

Estou realmente surpreso que as pessoas ainda recomendem este livro. Ele se preocupa principalmente com projetos de software de grande escala (ou seja, um sistema operacional), muitos dos "dados" são anedóticos e muitas das suposições estão simplesmente desatualizadas. Por exemplo, Brooks escreve sobre (1) criar manuais em papel com documentação sobre o sistema que é atualizado diariamente para os engenheiros, (2) estratégias para alocação de tempo em computadores centralizados e (3) sobre como otimizar o tamanho do código compilado. Esses simplesmente não são mais problemas fora dos aplicativos de nicho.

Além disso, a principal tese de Brooks sobre homens-mês é frequentemente citada e mal interpretada. Ele escreve que pessoas e meses não são intercambiáveis ​​e que adicionar pessoas a tarde os projetos só os farão depois - porque as pessoas inicialmente têm uma contribuição negativa. Os detalhes desse aforismo são incrivelmente importantes, mas sempre esquecidos.

Seria bom ver um livro novo e atualizado sobre esse tópico, que inclui dados reais e mede conceitos deste século. Mas achei a articulação de Brooks de alguns outros conceitos útil. Entre eles:

Simplicity and straightforwardness proceed from conceptual integrity.

By documenting a design, the designer exposes himself to the criticisms of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible.

All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress.
05/18/2020
Kimura Gornall

en bilinen kısmı unutmuşum :) “O parto de uma criança dura nove meses, não importa quantas mulheres sejam designadas. Muitas tarefas de software têm essa característica devido à natureza seqüencial da depuração. ”
05/18/2020
Archambault Yoshioka

Reli isso recentemente, depois de recomendá-lo a um colega, principalmente por nostalgia e planejando ler alguns dos ensaios mais populares, como "The Tar Pit". Em vez disso, li o livro inteiro novamente e ainda o achei fresco e perspicaz, mais de 40 anos desde a publicação. A prosa consegue ser densa de idéias, mas brilhantemente clara e muitas vezes espirituosa. Agora, ao ler textos contemporâneos (blogs, mas até livros), lamento profundamente essa arte perdida.

Além de suas declarações ousadas, mais famosas da Lei de Brooks, que foram citadas ao ponto do clichê, o que mais me impressionou desta vez é o quanto seu entusiasmo em construir sistemas e liderar equipes se manifesta. Você esperaria que um veterano grisalho de projetos maciços da IBM estivesse um pouco cansado, mas pessoalmente achei suas descrições do que os construtores adoram sobre a construção serem bastante bonitas. Se eu estiver meio apaixonado por meu ofício na idade dele, terei sorte.

IMHO isso classifica-se ao lado Peopleware e Psicologia da Programação de Computadores as leitura absolutamente essencial para líderes técnicos. As referências específicas, mesmo da seção de 2º aniversário, são datadas (fãs do MS Works por aí?), Mas 80% dos pontos apresentados não envelhecem por dia. De qualquer forma, as seções obsoletas serão um lembrete preocupante de que o seu Macbook é basicamente um supercomputador que você pode levar no trem para seu uso exclusivo. Estou tão agradecido que não preciso mais me preocupar com o tamanho das minhas funções na memória e posso usar linguagens bonitas e interpretadas como Ruby em escala da web, por exemplo, para executar este site ;-)

Alguns revisores observaram a linguagem excludente de apenas pronomes masculinos. Na verdade, havia muito mais mulheres programadoras em 1975 (antes da era do PC), então eu devo assumir que essa é uma convenção de estilo complexo (e não foi usada nos capítulos complementares de 1995). E sim, existem alguns tons religiosos espalhados por toda parte, mas eles não atrapalharam as idéias para mim.

Altamente, altamente recomendado. Um ótimo livro para ler com sua equipe e compartilhar histórias de guerra.
05/18/2020
Niel Fiorelli

Isso é mais de importância histórica do que um livro usado hoje em dia. Ainda assim, estou feliz por ter lido.

Eu concordo com os pontos feitos nestes dois rever, especialmente aqueles sobre o programador padrão do sexo masculino e o ponto de vista cristão estendido demais, o que realmente faz Brooks distorcer um de seus exemplos.

Ainda assim, adorei a mensagem positiva e realista de "Não há estrada real, mas há uma estrada". Eu posso ficar atrás de ambas as partes deste.
05/18/2020
Magel Schoenherr

Livro interessante, com um foco bastante restrito, uma coleção de ensaios sobre o gerenciamento e o planejamento de uma boa engenharia de software. O autor incutiu os erros e sucessos de seu trabalho no sistema operacional IBM 360 nos anos 70, e a maior parte do que encontrou ainda se aplica hoje. Por exemplo, sabedoria como: mais programadores atrasam um projeto e, se você adicionar programadores a um projeto já atrasado, os resultados chegarão ainda mais tarde. Tenha um arquiteto e um gerente, espero que em duas pessoas diferentes. Tenha controle de versão (já que o livro é antigo, é mais um repositório central de livros impressos (!!) que detalham todas as alterações, o esboço, o design etc.). Não existe uma bala de prata - o software é inerentemente complexo e nunca haverá uma única tecnologia que a torne rápida / fácil / barata / livre de erros.

Uma grande parte do conhecimento contido é de grandes empresas ou projetos grandes, mais úteis, onde você tem de 100 a 1000 programadores trabalhando ao mesmo tempo; portanto, para mim, como um bioinformático solitário, trabalhando em meu próprio código, nem tudo é aplicável. Mas, se eu olhar para os projetos fracassados, por exemplo, no Kickstarter, percebo que eles frequentemente repetem os erros que as pessoas já solucionaram nos anos 70.

Esta revisão tem um bom resumo dos pontos principais.

Estou dando 4 estrelas, já que alguns exemplos, discussões e problemas estão claramente desatualizados.
05/18/2020
Tompkins Solmonson

Muitas vezes, quando leio um livro datado, suas pérolas de sabedoria ainda estão lá em vista clara para serem colhidas e utilizadas. Não posso dizer a mesma coisa sobre o Mês do Homem Mítico. Vou admitir que a Lei de Brook ainda é válida, e os gerentes ainda hoje tropeçam nessa. No entanto, muitos de seus conselhos falharam diante do movimento de desenvolvimento ágil mais recente e do movimento devops ainda mais recente. No final, ele ainda estava pregando uma espécie de abordagem do tipo cascata para o desenvolvimento, que se repetia repetidamente. Além disso, sua prosa cheirava a alguém que estava todo apaixonado por seus próprios pensamentos. O Mês do Homem Mítico acabou caindo na minha opinião, embora eu possa entender por que, a certa altura, era um livro altamente elogiado. Seria melhor eu pensar que se alguém tirasse os verdadeiros pedaços de sabedoria do Mythical Man Month e escrevesse um novo livro que levasse em conta o estado da arte e tivesse um tom menos auto-elogioso.
05/18/2020
Head Lark

04/23/11

Dr. Brooks é o fundador do nosso departamento, razão mais do que suficiente para ler seu livro.

A recente extensão de nosso prédio de departamentos foi nomeado após o Dr. Brooks. Aparentemente, o dinheiro para o edifício veio como uma doação anônima de um ex-aluno, com a condição de receber o nome do Dr. Brooks. Esse é o tipo de respeito que ele conquistou de várias pessoas.
05/18/2020
Goldstein Porrazzo

Este livro teve algumas idéias interessantes sobre as práticas de engenharia de software, mas grande parte do livro não é mais relevante.

O autor mergulhou em alguns detalhes específicos sobre situações que ele havia encontrado, por exemplo, práticas envolvendo desenvolvedores planejando como eles dividiriam os computadores de depuração entre si.

Máquinas modernas podem lidar com muito mais do que computadores nos anos 70, e este livro precisa de uma atualização para refletir isso.

As principais conclusões que recebi deste livro são que as práticas de engenharia de software precisam ser flexíveis para atender às demandas inconstantes / desconhecidas do software, acrescentar mais engenheiros a um projeto atrasado é uma má ideia e a documentação é difícil de manter; uma boa idéia é colocar parágrafos da documentação no próprio código (para impedir que o código fique fora de sincronia com a documentação).
05/18/2020
Cicely Robar


* Estimar o tempo de conclusão do projeto de software é realmente difícil. (Os requisitos mudam, o software é intangível e precisa se encaixar nas idiossincrasias dos sistemas humanos)

* A aristocracia no gerenciamento de projetos é melhor. Deve haver um tomador de decisão final. A metáfora é uma equipe cirúrgica.

* O custo de coordenação e comunicação dentro de grandes equipes geralmente é ignorado. Isso causa uma estimativa ruim.

* Se um projeto estiver atrasado - é recomendável reagendar ou reduzir o escopo. Adicionar mão de obra resultará em mais atrasos.

* Evite carregar recursos no segundo sistema (lembrou-me o Vista)

* A especificação escrita é muito importante. Ele deve descrever tudo o que o usuário pode ver sobre o produto.

* Algoritmo pode ser previsto a partir das tabelas de dados.

* Um pequeno número de documentos se torna o pivô do gerenciamento de produtos (objetivos, especificações, cronograma, orçamento)

* Quantifique as alterações usando números de versão

* Mais bugs são encontrados à medida que o número de usuários aumenta

* As coisas sempre são as melhores no começo

* Reparos (software) aumentam a entropia

* "Concentração sustentada reduz o tempo de pensamento"

* O marco deve ser concreto, eventos mensuráveis ​​específicos. Preste muita atenção, mesmo com os menores atrasos, pois os projetos atrasam um dia de cada vez.

* A parte mais difícil do software de construção é: especificação, projeto e teste

* A atividade criativa tem três etapas:
1. Formulação do construto conceitual
2. Implementação em mídia real
3. Interatividade com usuários em usos reais

* "A integridade conceitual do prodcut conforme percebida pelo usuário é o fator mais importante na facilidade de uso"

* Use atalhos de teclado para projetar para usuários avançados e iniciantes

* "Pessoas com mais tempo levam mais tempo"

* Livros recomendados: Peoplware: equipes de projetos de produtos e Small is Beautiful
05/18/2020
Zarger Vecchione

Série fascinante de ensaios sobre a criação de software e o gerenciamento de equipes. Alguns bits realmente ressoaram, especialmente sobre o ofício da engenharia de software. Brooks disse que a parte mais difícil de aprender a programar é se adaptar à necessidade de perfeição, que eu acho que ainda é verdade hoje. Ele também tinha a descrição mais adequada de como é realmente escrever código, e as diferenças entre o trabalho essencial de criação de software e o trabalho "acidental" imposto por ferramentas, processos e peculiaridades ruins de computadores.

Infelizmente, Mythical Man-Month tem um problema de gênero. Todo pronome era "ele", exceto as referências ocasionais a secretárias e enfermeiras, que obviamente são mulheres. Além disso, o livro faz referências oblíquas (algumas) ao lugar das mulheres na casa. É nojento, desnecessário e incrivelmente frustrante. Hora de uma edição de 2016.
05/18/2020
Moonier Haerter

Esta é uma obra-prima da engenharia de software. Muitas pessoas leram este porque este é um relato extremamente acessível. Quando li este livro em 2007, senti o quanto de valor esse livro trouxe, que foi escrito há mais de 20 anos atrás. Desde então, ouvi muitas pessoas falarem e jurarem por este livro. Eu tenho uma queixa contra os leitores e as pessoas que falam sobre isso. Eles usam este livro para apoiar suas posições e, na maioria das vezes, essas pessoas não possuem o tipo de conhecimento e experiência que Fred Brooks possuía. Espero que todos lemos isso como uma conta divertida e tentemos obter algumas idéias no processo de desenvolvimento de software.
05/18/2020
Jehovah Huck

Eu o li como parte do meu doutorado, uma vez que faz parte dos livros clássicos de engenharia de software. No entanto, o livro aborda questões muito importantes, não apenas sobre gerenciamento, mas como as pessoas interagem durante o desenvolvimento de software. Eu me reconheci em muitas situações descritas pelo autor (mesmo que eu não faça parte de uma equipe de desenvolvimento de software).
Pode-se perguntar, como eu, quantos dos conceitos explicados pelo autor se aplicam à tecnologia atual do século XXI, mas o autor aborda isso nos últimos capítulos. No entanto, quase tudo se aplica, porque o foco do livro são as lições gerais que nunca ficam desatualizadas.
05/18/2020
Hanway Bonavita

Todos devem ler este livro, não apenas programadores ou gerentes de projeto. É fácil e divertido. Existem 9 capítulos, mas você só precisa ler 3 deles. Você saberá quais. Quando ele começar a atirar equações, pule essas partes. Ele usa metáforas de cozinha, onde a maioria dos livros de software usa metáforas de construção civil. O preconceito inconsciente de gênero, típico da época, é quase engraçado. Ele continua dizendo quantos "homens" são necessários para fazer um projeto.

Muitas vezes fico surpreso com quantos profissionais de software nunca leram este livro, nunca ouviram falar da Lei de Brook ou da Síndrome do Segundo Sistema (e sofrem por isso).
05/18/2020
Gizela Bobrosky

Mesmo para um estudante inexperiente como eu, este livro causou uma impressão duradoura e me deixou pensando nas várias dinâmicas humanas envolvidas na engenharia de software. Definitivamente uma leitura obrigatória.

Aviso: às vezes fica um pouco seco, e a maioria dos exemplos está muito desatualizada, mas os princípios explicados são atemporais.
05/18/2020
Justus Goon

Originalmente escrito em 1975, antes da explosão do PC em meados da década de 1980, o livro Brooks ainda é relevante hoje. As mesmas "regras práticas" de gerenciamento de sistemas e possíveis armadilhas ainda existem em grande parte da mesma forma. Muitas de suas maiores lições se expandem além do desenvolvimento de software e se aplicam ao gerenciamento de programas como um todo. Uma leitura obrigatória para quem desenvolve sistemas complexos.
05/18/2020
Linis Ranjel

Datada, inacessível e, de certa forma, misógina (sistêmica, mas não intencional, tenho certeza). Eu realmente entendo por que esse ainda é o livro de programação # 2 mais popular no Safari Books Online (logo após o Clean Code).

Provavelmente, mais da metade das lições e sugestões não fazem sentido no mundo moderno de linguagens de alto nível, desenvolvimento ágil de software e desenvolvimento / release contínuos.

Outras lições ainda são amplamente aplicáveis ​​... tão amplamente aplicáveis ​​que já são conhecimento quase universal. Coisas como código de auto-documentação é o ideal, adicionar força pessoal no último minuto não economiza, uma especificação bem definida reduz bugs, etc.

Vou repetir o que alguns outros disseram que achei os últimos 1/4 do livro (capítulo 16+) os mais valiosos e ainda há algum valor aqui. Eu sempre pensei em construir um programa de computador, não em um, por exemplo. Ou aquela única linha sobre os comentários que precisam dizer * por que * você fez alguma coisa, não como fez.

Também existem momentos realmente estranhos e estridentes. O desenvolvimento do sistema é aparentemente igual à Santíssima Trindade. Realmente? Realmente?? De que maneira o desenvolvimento de sistemas como O Pai, Filho e Espírito Santo?
05/18/2020
Nesto Ernest

Ler este livro foi uma viagem no tempo para mim. É um livro bastante desatualizado da perspectiva atual. Foi incrível ler sobre problemas cotidianos totalmente diferentes, como técnicas e estratégias de atualização da documentação em papel.

No entanto, engenheiros de software, arquitetos, gerentes de projetos de TI, apesar das técnicas ágeis e da experiência das gerações anteriores, ainda enfrentam alguns problemas, como estimativas corretas de tempo e custo do projeto. Muitas regras ainda são válidas, como a Lei de Brook afirma que a inclusão de pessoas em projetos atrasados ​​só será possível posteriormente.

Este livro mostra que cada geração de profissionais de TI tem seus próprios desafios para lidar e parafrasear Heráclito; a mudança é a única constante no desenvolvimento de software.
05/18/2020
Charlton Vitelli

No contexto desta história das práticas recomendadas de engenharia e gerenciamento de software, para a criação eficaz de sistemas de software e o gerenciamento de todos os tamanhos de projetos e equipes, este livro é inestimável. Eu recomendo todo engenheiro de software que esteja interessado em construir sistemas de software em um nível meta (sistemas técnicos / sociais que o ajudam a construir sistemas de software) ou que queira obter uma visão desses processos. Notavelmente, apenas os métodos e ferramentas específicos mencionados foram alterados desde que este livro foi escrito; A maioria das discussões de nível superior sobre a arquitetura de software e os processos de gerenciamento parece ser atemporal!
05/18/2020
Erl Pluma

Muito deste livro é singular. As descrições da documentação que precisa ser impressa para ser compartilhada, sistemas de computador que mal conseguem executar os programas que estão sendo criados ... com todos os avanços técnicos, você acha que estaríamos mais avançados em nosso entendimento de como construir essas coisas. Pelo contrário, as equipes ainda estão sujeitas aos mesmos problemas descritos e os conselhos dados são aplicáveis.
05/18/2020
Fawcette Monreal

A primeira parte do livro é o original de 1975. A maioria das idéias gerais listadas pelo autor é interessante, mas ele está se concentrando em equipes muito grandes (desenvolvendo sistemas operacionais, compiladores etc.) trabalhando com tecnologia agora muito desatualizada, resolvendo conjuntos muito diferentes de problemas Felizmente, foi bastante curto. 2/5.

A segunda parte do livro é um resumo do livro original e reflexões do autor após 20 anos. Isso foi muito mais fácil de ler, pois os pensamentos de 1995 são mais relacionáveis. Depois de receber 20 anos de feedback, Brooks também mudou algumas de suas opiniões sobre os assuntos descritos no livro original, o que foi agradável de ler de uma perspectiva histórica. 4/5.

Deixe um comentário para O Mês do Homem Mítico: Ensaios sobre Engenharia de Software