Olá Habitantes! Poucos livros sobre gerenciamento de projetos são tão significativos quanto The Mythical Man-Month. Uma mistura de exemplos reais de desenvolvimento de software, opiniões e pensamentos cria uma imagem vívida do gerenciamento de projetos complexos. Esses ensaios baseiam-se nos cinquenta anos de experiência de Brooks como gerente de projetos no IBM System / 360 e depois no OS / 360. A primeira edição do livro foi publicada há 45 anos, a segunda há 25 anos. Novas metodologias estão surgindo, novas linguagens de programação estão surgindo, o número de processadores está crescendo, mas este livro continua a ser relevante. Por quê? Meio século depois, continuamos a repetir os erros descritos por Brooks. Alguns dos tópicos discutidos no livro parecem desatualizados, mas isso é apenas uma aparência. Os problemas fundamentais por trás deles ainda são relevantes hoje. É importante conhecer seu passado para entenderonde a indústria de desenvolvimento de software está se desenvolvendo. Portanto, 45 anos depois, lemos Brooks. Muita coisa mudou no mundo, mas nove mulheres ainda não conseguem ter um bebê em um mês.
. ,
. , , , …
, , , , .
, ', , , . .
A maioria das catedrais europeias foi construída gradualmente, e as partes construídas por construtores de diferentes gerações diferem em termos de estilo arquitetônico. Os construtores subsequentes foram tentados a “refinar” os projetos dos anteriores, guiados por mudanças na “moda” arquitetônica e no gosto pessoal. Portanto, o pacífico transepto normando * confina e contradiz a alta nave gótica, e o resultado é tanto para louvar a glória de Deus quanto para o orgulho dos construtores.
Contra seu pano de fundo, a unidade arquitetônica de Reims está em grande contraste. O prazer que entusiasma o espectador vem tanto da integridade do design quanto de quaisquer méritos individuais. Conforme declarado no guia, essa integridade foi alcançada pela abnegação de oito gerações de construtores, cada um dos quais sacrificou algumas de suas ideias em prol da pureza do projeto geral. O resultado proclama não apenas a glória do Senhor, mas também Seu poder para salvar pessoas pecadoras de seu orgulho.
Embora a maioria dos sistemas de programação não tenha levado séculos para ser construída, eles exibem uma desunião conceitual muito pior do que catedrais. Isso geralmente acontece não por causa de uma mudança de designers, mas por causa da divisão do projeto em inúmeras tarefas realizadas por muitas pessoas.
Insisto que a integridade conceitual é a consideração mais importante em um projeto de sistemas. É melhor ter um sistema que carece de alguns recursos e melhorias, mas reflete um conjunto de idéias de design, do que ter um sistema que contém muitas idéias boas, mas independentes e inconsistentes. Neste capítulo e nos próximos dois, examinaremos as implicações deste tópico para o projeto de sistemas de programação:
- Como alcançar integridade conceitual?
Não é este argumento uma desculpa para o elitismo ou aristocracia dos arquitetos diante de uma horda de implementadores plebeus, cujos talentos criativos e ideias são suprimidos?
- Como evitar que os arquitetos caiam no azul com especificações não implementadas ou caras?
- Como garantir que cada pequeno detalhe da especificação arquitetônica seja levado ao conhecimento do implementador, entendido corretamente e com precisão embutido no produto?
Alcançando integridade conceitual
O objetivo do sistema de programação é tornar o computador fácil de usar. Para fazer isso, ele fornece idiomas e várias ferramentas de suporte, que na verdade são programas chamados e acionados por recursos de linguagem. Mas essas ferramentas têm um preço: a descrição externa do sistema de programação é de 10 a 20 vezes maior do que a descrição externa do próprio sistema de computador. É muito mais fácil para o usuário definir uma única função, mas a escolha é vasta e há muito mais opções e formatos a serem considerados.
O uso só é simplificado se o tempo ganho na especificação funcional for maior do que o tempo perdido na assimilação, memorização e pesquisa do manual de referência. Em sistemas de programação modernos, esse ganho excede o custo, mas nos últimos anos, a relação ganho-custo parece ter caído à medida que mais e mais recursos complexos são adicionados. Estou assombrado pela memória da facilidade de uso do IBM 650, mesmo sem a linguagem assembly ou qualquer outro software.
Visto que a facilidade de uso é o objetivo, essa relação entre funcionalidade e integridade conceitual é o teste final do projeto do sistema. Funcionalidade e simplicidade por si só não definem um bom design.
Esta tese é amplamente mal compreendida. O sistema operacional OS / 360 é saudado por seus criadores como o melhor já projetado, pois é inegavelmente o mais funcional. É a funcionalidade, não a simplicidade, que sempre foi a medida de excelência para os seus designers. Por outro lado, o sistema de compartilhamento de tempo do PDP-10 é saudado por seus criadores como o melhor devido à simplicidade e contenção de conceitos. No entanto, em qualquer medida, sua funcionalidade nem mesmo pertence à mesma classe que a do OS / 360. Uma vez que a facilidade de uso é tomada como critério, cada uma dessas abordagens se torna desequilibrada, apenas a meio caminho do objetivo.
No entanto, para um determinado nível de funcionalidade, o melhor sistema é aquele em que as coisas podem ser especificadas com a maior simplicidade e objetividade. A simplicidade por si só não é suficiente. As linguagens TRAC Mooers e Algol 68 alcançam simplicidade, medida pelo número de conceitos elementares distintos. A imediação, no entanto, não é característica deles. Expressar suas intenções geralmente requer a combinação de ferramentas básicas de maneiras complexas e inesperadas. Não basta estudar os elementos e as regras de sua combinação; também é necessário estudar o uso idiomático, para assimilar todo um corpo de conhecimento sobre como os elementos se combinam na realidade. Simplicidade e franqueza vêm da integridade conceitual. Cada peça deve refletir a mesma filosofia e o mesmo ato de equilíbrio.Cada parte deve usar até mesmo a mesma técnica de sintaxe e conceitos semelhantes em semântica. Assim, a facilidade de uso dita unidade de design, integridade conceitual.
Aristocracia e Democracia
A integridade conceitual, por sua vez, requer que o projeto venha de um desenvolvedor ou de um pequeno número deles, agindo em conjunto e em uníssono.
A pressão da agenda, por sua vez, exige o envolvimento de mais trabalhadores. Existem dois métodos para resolver este problema. O primeiro é a divisão cuidadosa de trabalho entre arquitetura e implementação. A segunda é uma nova maneira de estruturar instruções de implementação de programação, discutida no capítulo anterior.
Separar o esforço arquitetônico da implementação é uma maneira poderosa de alcançar integridade conceitual em grandes projetos. Eu mesmo já vi isso ser usado com grande sucesso na linha de produtos de computadores IBM Stretch and System / 360. E testemunhei como não funcionou no desenvolvimento do Operating System / 360 porque não foi usado o suficiente.
Por arquitetura de sistema, quero dizer uma especificação completa e detalhada da interface do usuário. Para um computador, ele está incorporado no manual de referência de programação. Para o compilador - no manual de referência da linguagem. Para um programa de controle, o manual de referência para o idioma ou idiomas usados para chamar suas funções. Para todo o sistema, é uma coleção de guias de referência para ajudar o usuário a atingir seu objetivo.
O arquiteto do sistema, como o arquiteto do edifício, é o agente do usuário. Suas responsabilidades incluem o uso de conhecimento profissional e técnico no interesse do consumidor, e não no interesse do vendedor, fabricante, etc. A
arquitetura deve ser claramente diferenciada da implementação. Como Blaauw observou, "Onde a arquitetura fala sobre o que acontece, a implementação fala sobre como é feita para que isso aconteça". Como exemplo simples, ele cita um relógio cuja arquitetura consiste em um mostrador, ponteiros e coroa. Quando uma criança aprende esta arquitetura, ela será capaz de dizer as horas com a mesma facilidade tanto pelo relógio de pulso quanto pelo relógio da torre da igreja. A implementação e sua implementação descrevem o que acontece internamente: a transferência de esforço e o controle de precisão por cada um dos muitos mecanismos.
Por exemplo, no System / 360, uma arquitetura de computador separada é implementada de forma muito diferente em cada um dos nove modelos. Por sua vez, a implementação separada, fluxo de dados, memória e microcódigo do sistema Modelo 30 em momentos diferentes atendem a quatro arquiteturas diferentes: o computador System / 360, o canal multiplexado com 224 subcanais logicamente independentes, o canal seletor e o computador 1401.
A mesma distinção se aplica igualmente aos sistemas de programação. Os EUA adotaram o padrão Fortran IV. É a arquitetura de muitos compiladores. Dentro desta arquitetura, diferentes implementações são possíveis: texto na memória ou compilador, rápido ou otimizador, sintático ou ad hoc. Da mesma forma, qualquer assembly ou linguagem de controle de trabalho permite muitas implementações de assembly ou planejador. Agora podemos enfrentar a questão profundamente emocional da aristocracia e da democracia. Os arquitetos da nova aristocracia, a elite intelectual, não são criados para dizer aos implementadores pobres e sem cérebro o que fazer? Essa elite não assumiu todas as atividades criativas, tornando os performers apenas engrenagens do mecanismo? Você não pode conseguir um produto melhorimplementar boas ideias de toda a equipe, seguindo uma filosofia democrática, em vez de limitar o desenvolvimento de especificações a um grupo seleto?
Quanto à última pergunta, é a mais simples. Não estou sugerindo que apenas os arquitetos tenham boas idéias arquitetônicas. Freqüentemente, um novo conceito vem do implementador ou do usuário. No entanto, toda a minha experiência me convence, e tentei mostrar isso, que a integridade conceitual de um sistema determina sua facilidade de uso. É melhor deixar de lado bons recursos e ideias que não se integram com os conceitos básicos do sistema. Se muitas dessas ideias importantes, mas incompatíveis, aparecerem, todo o sistema será descartado como um todo e o trabalho começará novamente em um sistema integrado com outros conceitos básicos.
Quanto à acusação de aristocracia, a resposta deve ser “sim” e “não”. Sim, no sentido de que deve haver poucos arquitetos, seu produto deve durar mais do que o produto do implementador, e o arquiteto está no centro das forças que ele deve, em última instância, direcionar no interesse do usuário. Para que o sistema tenha integridade conceitual, uma pessoa deve assumir a liderança. Esta é a aristocracia que não precisa de desculpas.
Desenvolver especificações externas é um trabalho tão criativo quanto projetar implementações. É criatividade, apenas um tipo diferente. O design de implementação ciente da arquitetura requer e permite tanta criatividade de design, tantas novas idéias e tanto brilho técnico quanto design para especificações externas. De fato, a relação custo-desempenho de um produto dependerá mais do implementador, assim como a facilidade de uso dependerá mais do arquiteto.
Existem muitos exemplos de artes e ofícios que levam à crença de que a disciplina melhora o artesanato. De fato, o aforismo do artista afirma: "a forma liberta". As piores estruturas são aquelas cujo orçamento era muito grande para o serviço ser servido. A atividade criativa de Bach dificilmente foi suprimida pela necessidade de publicar uma cantata semanal limitada em forma. Tenho certeza de que o computador Stretch teria uma arquitetura melhor se fosse mais restritivo; as restrições de orçamento do System / 360 Model 30 foram, em minha opinião, benéficas para a arquitetura do Model 75 em todos os aspectos.
Da mesma forma, acho que a terceirização da arquitetura aprimora, em vez de negar, o estilo criativo da equipe de implementação. Eles imediatamente focam na parte da tarefa que ninguém resolveu, e as invenções começam a fluir como um rio. Em um grupo de implementação irrestrita, a maior parte do pensamento e da discussão vai para soluções arquitetônicas, com prazos de implementação curtos.
Esse efeito, que já vi muitas vezes, é confirmado por RW Conway, cujo grupo em Cornell construiu um compilador PL / C para PL / 1. Ele observa o seguinte: “No final, decidimos implementar a linguagem sem mudanças e melhorias, já que a discussão da linguagem consumiria todas as nossas energias”.
O que o implementador deve fazer enquanto espera?
É humilhante cometer um erro de um milhão de dólares, mas é tão memorável. Lembro-me nitidamente da noite em que decidimos como organizar a redação real das especificações externas para OS / 360. O gerente de arquitetura e o gerente do programa de controle e eu elaboramos o plano, cronograma e atribuição de responsabilidades.
O gerente de arquitetura tinha 10 pessoas talentosas. Ele argumentou que eles podem escrever especificações e fazer isso direito. Levará 10 meses, três a mais do que o cronograma permite.
O gestor de implantação do programa de controle contava com 150 pessoas. Ele argumentou que eles poderiam preparar especificações em coordenação com a equipe de arquitetura; seria bem feito e prático, e se encaixaria no cronograma. Além disso, se a equipe de arquitetura fizesse isso, seus 150 funcionários ficariam sentados de braços cruzados por 10 meses.
A isso o gerente de arquitetura respondeu que se eu transferir a responsabilidade para a equipe do programa de controle, na verdade o resultado será recebido 3 meses depois e de qualidade muito inferior. Passei a responsabilidade para a equipe de implementação do programa de controle e saiu como ele disse. Ele estava certo em ambos os casos. Além disso, a falta de integridade conceitual tornou o sistema muito mais caro para construir e mudar, e estimo que atrasou a depuração em um ano.
É claro que muitos fatores influenciaram essa decisão errônea; mas os opressores eram as limitações de tempo da programação e o apelo para trazer todos esses 150 implementadores para o trabalho. É esse canto de sereias, repleto de perigos mortais, que agora tornarei visível.
Para a proposta de que uma pequena equipe de arquitetura irá realmente escrever todas as especificações externas para um computador ou sistema de programação, os implementadores levantam três objeções:
- As especificações serão muito ricas em recursos e não refletirão o custo prático.
- Os arquitetos terão todo o prazer criativo e abrirão mão da engenhosidade dos implementadores.
- Numerosos performers terão que ficar parados enquanto as especificações passam pelo gargalo da equipe de arquitetura.
O primeiro é um perigo real e vamos examiná-lo no próximo capítulo. Os outros dois são ilusões, pura e simples. Como vimos acima, a implementação também é uma atividade criativa de primeira ordem. A capacidade de ser criativo e inventivo no design é marginalmente limitada pela necessidade de trabalhar dentro de determinadas especificações externas, e essa disciplina pode até aumentar o grau de criatividade. Isso sem dúvida é verdade para o projeto como um todo.
A última objeção diz respeito ao tempo e às fases. A resposta rápida é não contratar implementadores até que as especificações estejam completas. Na construção, eles operam com o mesmo princípio.
No negócio de sistemas de computador, entretanto, o ritmo é mais rápido e todos querem apertar a programação o máximo possível. Até que ponto a especificação e o desenvolvimento podem se sobrepor?
Como Blaau aponta, o esforço criativo geral inclui três fases distintas: arquitetura, implementação e implementação. Acontece que eles podem realmente começar em paralelo e continuar ao mesmo tempo.
Por exemplo, no projeto de computador, o implementador pode começar assim que tiver suposições relativamente vagas sobre o manual de referência, idéias mais ou menos claras sobre a tecnologia e metas bem definidas de custo e desempenho. Ele pode projetar fluxos de dados, sequências de controle, conceitos de embalagem bruta, etc. Ele desenvolve ou adapta as ferramentas de que precisa, especialmente um sistema de contabilidade, incluindo um sistema de automação de projeto.
Ao mesmo tempo, no nível de implementação, os projetos de circuitos, placas, cabos, estruturas, fontes de alimentação e memória devem ser elaborados, aprimorados e documentados. Este trabalho segue em paralelo com a arquitetura e implementação.
O mesmo é verdade para o projeto de sistemas de programação. Muito antes de as especificações externas serem finalizadas, o implementador tem muito a fazer. Com algumas simplificações grosseiras da funcionalidade do sistema, que eventualmente serão incorporadas em especificações externas, ele pode continuar a trabalhar. Deve ter critérios de direcionamento espacial e temporal claramente definidos. Ele deve saber a configuração do sistema no qual seu produto será executado. Em seguida, ele pode começar a projetar limites de módulo, estruturas de tabela, quebras de passagem e fase, algoritmos e todos os tipos de ferramentas. Algum tempo também deve ser gasto na comunicação com o arquiteto.
Ainda há muito trabalho a ser feito no nível de implementação. A programação também possui tecnologia. Se a máquina for nova, há muito a ser feito sobre convenções de chamada de subrotinas, tecnologia de supervisor, algoritmos de busca e classificação.
A integridade conceitual requer que o sistema reflita uma única filosofia e que uma especificação visível ao usuário seja escrita por várias pessoas. No entanto, devido à divisão real do trabalho em arquitetura, implementação e implementação, não se segue, de forma alguma, que a montagem de um sistema planejado dessa forma demore mais. A experiência mostra o oposto: que todo o sistema converge cada vez mais rápido e leva menos tempo para testar. Na verdade, a ampla divisão horizontal do trabalho foi drasticamente reduzida pela divisão vertical do trabalho, e o resultado foi uma simplificação radical da comunicação e melhor integridade conceitual.
»Mais detalhes sobre o livro podem ser encontrados no site da Editora
» Índice
» Trecho
Para Habitantes desconto de 25% no cupom - Brooks
Após o pagamento da versão em papel do livro, é enviado um e-book por e-mail.