O que é Anti-Pattern?

Este texto é uma tradução da Wikipedia

Em Engenharia de Software, um anti-pattern é um pattern que pode ser utilizado, mas é ineficiente e contraprodutivo na prática.

O termo foi cunhado em 1995 por Andrew Koening, inspirado no livro Design Patterns da Gang of Four, que desenvolveu o conceito de design patterns na área de software.
O termo foi popularizado três anos depois pelo livro AntiPatterns, que estendeu o uso do termo além das fronteiras do design de software para a interação social geral. De acordo com os autores, devem haver pelo menos dois elementos-chaves presentes para distinguir formalmente um anti-pattern de um simples mau hábito, má prática, ou má idéia:

- Alguns patterns repetidos de ação, processo ou estrutura que inicialmente parecem ser benéficos, mas acabam produzindo mais conseqüências ruins que que resultados benéficos;
- Uma solução refatorada é claramente documentada, comprovada na prática e repetível.

Muitas idéias anti-patterns são mais que erros, retórica, problemas sem solução ou práticas ruins que devem ser evitadas. O uso informal do termo, às vezes denominado "armadilhas" (pitfalls) ou "patterns negros" (dark patterns), refere-se a soluções ruins para os problemas. Desta forma, muitos anti-patterns colocados sob debate não seriam formalmente considerados anti-patterns.

Através da descrição formal de erros repetidos, podem-se reconhecer as forças que levam a esta repetição e aprender refatorar este pattern.

Anti-patterns Organizacionais:
- Paralisia na análise: colocar um esforço desproporcional na fase de análise de um projeto.
- Vaca leiteira: Um produto legado rentável que muitas vezes leva à complacência sobre os novos produtos.
- Design por commitê: resultado de muitos contribuintes para o design, mas sem uma visão unificada.
- Escalação de compromisso: falha em revogar uma decisão quando a mesma se revela errada.
- Gestão por perkele (sem tradução): estilo autoritário de gerenciamento, sem tolerância à dissidência.
- Gestão matricial: estrutura organizacional sem foco, que resulta em subordinação dividida e falta de direção.
- Risco moral: isentar um tomador de decisão das conseqüências de sua decisão.
- Gestão Cogumelo: manter funcionários sem informação ou mal informados.
- Stovepipe ou Silos (sem tradução): uma estrutura que suporta principalmente o fluxo vertical (de cima para baixo) de informação, mas inibe a comunicação organizacional.
- Vendedor bloqueado: tornar um sistema excessivamente dependente de um componente externo.

Anti-patterns de Gerenciamento de Projetos:
- Marcha para a morte: todos sabem que o projeto caminha para um desastre, exceto o presidente da empresa. Porém, a verdade permanece ocultada e a sobrevida do projeto é mantida artificialmente até que o "Dia D" chega. Definição alternativa de marcha para a morte: funcionários sofrem pressões para trabalharem dias, noites e fins de semana em um projeto com prazo irracional.
- Groupthink (pensamento em grupo): durante o groupthink, membros do grupo evitam mencionar pontos de vista que estejam fora da zona de conforto do pensamento consensual.
- Fumaça e espelhos: demonstrar como funções não implementadas irão surgir.
Software bloat (inchaço do software): permitir versões sucessivas de um sistema a fim de demandar cada vez mais recursos.

Anti-patterns de análise:
- Apatia do espectador: quando um requisito ou uma decisão de design está incorreta, mas as pessoas que notaram o problema não fazem nada a respeito, porque isto afeta um número maior de pessoas.

Anti-patterns do design de Software:
- Inversão da Abstração: não expor a funcionalidade implementada requisitada pelos usuários, para que eles a re-implementem usando funções de mais alto nível.
- Ponto de vista ambíguo: apresentar um modelo (normalmente análise e design orientados a objeto) sem especificar seu ponto de vista.
- Grande bola de lama: um sistema sem nenhuma estrutura reconhecida.
- Database-as-IPC: usar um banco de dados como message queue para comunicação de interprocessamento de rotina onde um mecanismo muito mais simples seria apropriado.
- Chapeamento a ouro: continuar a trabalhar em uma tarefa ou projeto bem além do ponto em que o esforço extra agrega valor.
- Efeito na plataforma interna: um sistema é tão customizável que se torna uma réplica pobre da plataforma de desenvolvimento de software.
- Input kludge (sem tradução): falha em especificar e implementar o tratamento de uma entrada possivelmente inválida.
- Interface bloat (inchaço da interface): construir uma interface tão poderosa que se torna extremamente difícil de implementá-la.
- Magic pushbutton (botão mágico): codificar a lógica de implementação diretamente no código da interface, sem usar abstração.
- Race hazard (perigo de corrida): falha na verificação da conseqüência de diferentes ordens de eventos.
- Stovepipe system: componentes mal-relacionados e difíceis de manter.

Anti-patterns do design orientado a objeto:
- Anemic Domain Model: uso do modelo de domínio sem qualquer lógica de negócio. Os objetos do modelo de domínio não podem garantir sua correção, porque sua lógica de validação e mutação está armazenada externamente (muito provavelmente em múltiplos locais).
- BaseBean (sem tradução): herdar a funcionalidade de uma classe utilitária em vez de delegar a ela.
- Call super (sem tradução): requisitar às subclasses a chamarem um método overriden de uma superclasse.
- Problema círculo-elipse: subtipar tipos-variável com base dos subtipos de valor.
- Dependência circular: introduzir dependências mútuas diretas ou indiretas entre objetos ou módulos do software.
- Constant interface (sem tradução): usar interfaces para definir constantes.
- God object (Objeto Deus): concentrar muitas funções em uma única parte do design (classe).
- Object cesspool (fossa de objetos): reutilizar objetos cujo estado não está em conformidade com o contrato (possivelmente implícito) para reúso.
- Orgia de objetos: falha para encapsular propriamente os objetos, permitindo acesso irrestrito ao seu interior.
- Poltergeists: objetos cujo único propósito é passar informação para outro objeto.
- Acoplamento seqüencial: uma classe que exige que seus métodos sejam chamados em uma ordem particular.
- Problema Iô-Iô: uma estrutura (por exemplo, de herança) que é difícil de entender devido à sua fragmentação excessiva.

Anti-patterns de programação:
- Complexidade acidental: introduzir uma complexidade desnecessária a uma solução.
- Ação a distância: interação inesperada entre partes amplamente separadas de um sistema.
- Fé cega: falta de verificação da correção realizada em um bug, ou do resultado de uma subrotina.
- Âncora de barco: manter uma parte do sistema que não possui mais qualquer uso.
- Busy spin (sem tradução): consumir CPU enquanto aguarda algo ocorrer, normalmente pela verificação repetida em vez de mensagem.
- Caching failure (sem tradução): esquecer de resetar uma flag de erro quando o mesmo foi corrigido.
- Cargo cult programming (sem tradução): usar patterns e métodos sem entender por quê.
- Codificar por exceção: adicionar novo código para tratar cada caso especial reconhecido.
- Esconder o erro: fazer um catch da mensagem de erro antes que a mesma seja mostrada ao usuário e não mostrar nada ou uma mensagem sem significado algum.
- Hard code: incorporar pressupostos do ambiente de um sistema em sua implementação.
- Fluxo de lava: manter código indesejável (redundante ou de baixa qualidade) porque removê-lo é muito caro ou trará conseqüências imprevisíveis.
- Seqüência Loop-switch: codificar um conjunto de etapas seqüenciais usando switch dentro de um loop.
- Números mágicos: incluir números inexplicáveis em algorítmos.
- Strings mágicos: incluir strings literais no código, para comparações, como tipos de eventos etc.
- Soft code (código leve): não armazenar a lógica de negócio no código fonte, mas em arquivos de configuração.
- Código macarrônico: programas cuja estrutura é difícil de compreender, especialmente por causa da mistura de estruturas de código.

Anti-patterns metodológicos:
- Copiar e colar um programa: copiar e modificar um código existente em vez de criar soluções genéricas.
- Golden hammer (martelo de ouro): presumir que uma solução favorita é universalmente aplicável.
- Fator de improbalidade: presumir que seja improvável que um erro conhecido possa ocorrer.
- Otimização prematura: codificar pensando somente na eficiência, sacrificando o bom design, manutenibilidade e, muitas vezes, a própria eficiência.
- Programar por acidente: tentar chegar a uma solução através de modificações sucessivas no código para ver se funciona.
- Reinventar a roda: não adotar uma solução existente e adequada.
- Reiventar a roda quadrada: não adotar uma solução existente. Em vez disso, adotar uma solução customizada com um desempenho muito pior que a existente.
- Silver bullet (bala de prata): presumir que uma solução técnica favorita pode resolver um processo ou problema maior.
- Tester Driven Development (Desenvolvimento Orientado ao Testador): projetos de software onde novos requisitos são especificados em relatórios de erros.

Anti-patterns de gerenciamento de configuração:
- Dependency hell: problemas com as versões dos produtos exigidos.
- DLL hell: gerenciamento inadequado das dynamic-link libraries (DLLs).
- Conflito de extensão: problemas com diferentes extensões para as versões do pre-Mac OS da MC OS, na tentativa de corrigir as mesmas partes do sistema operacional.
- JAR hell: superutilização de múltiplos arquivos JAR, normalmente causando problemas de versionamento e localização, devido ao não entendimento do Java class loading model.

Tester Driven Development: Não Confundir com Test Driven Development

Este texto é uma tradução do Wikipedia

Tester driven development é um anti-pattern no desenvolvimento de software. Não pode ser confundido com Test Driven Development (TDD). Este anti-pattern diz respeito a qualquer projeto de desenvolvimento de software onde a fase de teste é tão longa que os requisitos podem mudar radicalmente durante o teste do software. Requisitos novos ou alterados acabam surgindo como relatórios de bugs. Um software de rastreamento de bugs normalmente não oferece suporte para lidar com requisitos. Como resultado, ninguém sabe de fato quais são os requisitos do sistema.

Projetos que são desenvolvidos utilizando este anti-pattern sempre sofrem grandes atrasos. Outro problema freqüente é a queda na qualidade do código.

As causas mais comuns para projetos que acabam sendo executados dessa maneira, são:

A fase de teste começa muito cedo;
Requisitos incompletos;
Testadores inexperientes;
Desenvolvedores inexperientes;
Má gerência de projetos.

As coisas pioram quando os testadores percebem que não sabem quais são os requisitos e, portanto, não sabem como testar uma mudança particular no código. Desta forma, o ônus recai sobre os desenvolvedores de alterações para escreverem seus próprios casos de teste.

Anemic Domain Model

Este post é uma tradução do Wikipedia.

O Anemic Domain Model é um termo usado para descrever o uso de um software domain model, onde a lógica de negócio é implementada fora dos objetos de domínio.

Resumo
Este pattern foi descrito primeiramente por Martin Fowler, que considera a prática um anti-pattern. Com este pattern, a lógica é tipicamente implementada em classes separadas que transformam o estado dos objetos de domínio. Fowler denomina estas classes externas como transaction scripts (scripts de transação). Este pattern é uma abordagem comum em Enterprise Java Applications, possivelmente encorajado por tecnologias como as versões iniciais do EJB Entity Beans, assim como aplicações .Net que seguem a arquitetura de aplicação de serviços em três camadas, onde tais objetos se enquadram na categoria de "Entidades de Negócios" (embora Entidades de Negócio possam conter comportamento).

Benefícios:
Separação clara entre lógica e dados (programação procedural).


Deficiências:
- Lógica não pode ser implementada de forma verdadeiramente orientada a objeto a não ser que wrappers sejam usados para esconder a estrutura anêmica de dados.
- Violação do encapsulamento e dos princípios de ocultação de informação.
- Necessita de uma camada de negócios separada para conter a lógica localizada em um modelo de domínio. Isto também significa que objetos do modelo de domínio não podem garantir sua correção, porque sua lógica de validação e mutação é colocada em algum local externo (muito provavelmente em múltiplos locais).
- Necessita de um acesso global aos internos das entidades de negócio compartilhadas, aumentando acoplamento e fragilidade.
- Facilita a duplicação de código entre scripts transacionais e casos de uso similares, além de reduzir o reúso de código.
- Necessita de uma camada de serviço quando for compartilhar a lógica de domínio entre diferentes consumidores de um modelo de objeto.
- Torna um modelo menos expressivo e mais difícil de entender.

God objects: em geral, uma má prática

Este post é composto de trechos extraídos da Wikipedia.

Em programação orientada a objeto, um God Object (Objeto Deus) é um objeto que sabe muito e faz muito. God Object é um exemplo de anti-pattern.

A idéia básica por trás da programação estruturada é que um problema grande seja quebrado em muitos problemas menores (estratégia dividir e conquistar) e soluções são criadas para cada um destes problemas. Assim que os problemas pequenos são resolvidos, o problema como um todo também será. Portanto, há somente um objeto de quem um objeto precisa saber tudo: ele mesmo. Além disso, há somente um objeto de quem um objeto deve resolver um conjunto de problemas: ele mesmo.

O código baseado em God Object não segue esta abordagem. Em vez disso, a maioria da funcionalidade global é codificada em um único objeto "sabe-tudo", que mantém a maioria das informações do programa inteiro e fornece a maioria dos métodos para manipular os dados. Devido ao fato que este objeto mantém muitos dados e requisita muitos métodos, seu papel no programa se torna como se fosse um "Deus". Em vez de objetos se comunicando diretamente, os outros objetos dentro do programa confiam a um God Object a maioria de suas informações e interações. Uma vez que o God Object é referenciado por muitos outros códigos, a manutenção se torna mais difícil do que em um design dividido de forma mais equilibrada.

God Object é um análogo orientado a objeto de não usar subrotinas em linguagens procedurais, ou em usar muitas variáveis globais para armazenar informação de estado.

Enquanto a criação de um God Object é normalmente considerada uma má prática de programação, esta técnica é ocasionalmente utilizada em certos ambientes de programação (como microcontrollers), onde há um ligeiro aumento de desempenho e a centralização do controle é mais importante que a manutenibilidade e o código elegante.

O que é Code Smell?

Este post é um conjunto de trechos extraídos da Wikipedia.

Em programação, code smell é qualquer sintoma no código fonte que indica um problema mais profundo.

O problema sugerido por um code smell sempre ser descoberto quando o código está sujeito a um pequeno ciclo de feedback, onde é refatorado em etapas pequenas e controladas, e o design resultante é examinado para verificar se há mais code smells que indiquem a necessidade de mais refatoração.

Do ponto de vista de um programador encarregado de realizar a refatoração, code smells são heurísticas que indicam quando refatorar, e quais técnicas específicas de refatoração devem ser usadas.

Determinar o que é ou não um code smell é sempre um julgamento subjetivo, e sempre irá variar de acordo com a linguagem de programação, o desenvolvedor e a metodologia de desenvolvimento.

Existem ferramentas que detectam certos tipos de code smells, como:
Java: Checkstyle, PMD e FindBugs.
Dot Net: ReSharper.

Code smells comuns:

Código duplicado: código idêntico ou muito similar existe em mais de um local.
Método longo: um método, função ou procedure muito extenso.
Classe extensa: uma classe que acabou ficando muito extensa (God Object).
Feature envy (sem tradução): uma classe que utiliza em excesso métodos de outra classe.
Intimidade inapropriada: uma classe que possui dependência de detalhes de implementação de outra classe.
Legado recusado: uma classe que sobrepõe (override) o método da classe genérica de forma que o contrato da classe genérica não é cumprido pela classe derivada.
Classe preguiçosa: classe que faz muito pouco.
Complexidade artificial: uso forçado de design patterns extremamente complicados, onde um design simples seria suficiente.
Identificadores excessivamente longos: em particular, o uso de convenções de nomes para evitar ambigüidades, o que deveria estar implicito na arquitetura do software.

Princípios SOLID: O que são?

SOLID são cinco princípios básicos de programação e design orientados a objeto, introduzidos por Robert C. Martin no início dos anos 2000:

SRP: Single Responsibility Principle (Princípio da Responsabilidade Única). Noção de que um objeto deve possuir uma única responsabilidade.

OCP: Open/Closed Principle (Princípio Aberto / Fechado). Noção de que o software deve ser aberto para extensão, mas fechado para modificação.

LSP: Liskov Substitution Principle (Princípio da Substituição de Liskov). Noção de que objetos devem ser substituídos por instâncias de seus subtipos, sem afetar a correção do programa.

ISP: Interface Segregation Principle (Princípio de Segregação da Interface). Muitas interfaces específicas são melhores do que uma interface de uso geral.

DIP: Dependency Inversion Principle (Princípio de Inversão da Dependência). Noção de que se deve depender de interfaces abstratas e não de classes concretas, uma vez que implementações concretas são mais propensas a mudanças.

Princípios SOLID podem ser aplicados no desenvolvimento de software:

- A fim de remover Code Smells. Desta forma, o desenvolvedor refatora o código fonte do software até que esteja legível e extensível.
- Em conjunto com TDD (Test-Driven Development: desenvolvimento orientado a testes).
- É parte de uma estratégia global de programação ágil e adaptativa.
- Quando os princípios são aplicados em conjunto, aumentam bastante as chances de que o sistema criado seja simples de manter e estender.

Esta foi uma introdução a SOLID. Nos próximos posts farei uma explicação simples de cada um dos princípios aqui mencionados.

Scrum com Team Foundation Server 2010

Uma dica para os amantes do Scrum e do Dot Net é ler o slide abaixo, publicado por Aaron Bjork:

Scrum With Team Foundation Server 2010

View more presentations from Aaron Bjork.

As 10 melhores práticas para se construir software.

Estas são As 10 melhores práticas para se construir software, post escrito por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet:

1 - Desenvolva uma visão do produto.
2 - Trabalhe de modo iterativo e evolutivo.
3 - Envolva o cliente no processo.
4 - Gerencie requisitos.
5 - Acolha mudanças.
6 - Construa o design e a arquitetura incrementalmente.
7 - Diminua o tempo de feedback.
8 - Gerencie riscos.
9 - Aplique técnicas de engenharia.
10 - Confie na equipe.

Clique aqui e leia este e outros posts na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Como trabalham os desenvolvedores profissionais?

O post Como trabalham os desenvolvedores profissionais?, publicado por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet, lista as características inerentes aos bons desenvolvedores da seguinte forma:

Estudam muito, sempre;
Gostam de compartilhar conhecimento;
Escrevem seus próprios testes;
Escrevem código para pessoas e não para máquinas;
Refatoram de forma disciplinada e habitualmente;
Evoluem com o design tendo o business em mente.

Clique aqui e leia este post na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Verdades e Mitos sobre a Programação Orientada a Objetos

O post Verdades e Mitos sobre a Programação Orientada a Objetos, publicado por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet, divide idéias sobre a programação orientada a objetos em:

Verdades:
O Desenvolvimento OO é mais lento;
Programadores mais antigos têm dificuldades com OO;
A programação OO favorece a reutilização.

Mitos:
Objetos são "abstrações" do mundo real;
Programar em Java ou C# gera automaticamente software OO;
Para aprender OO é preciso antes aprender UML;

Para saber o porquê destas verdades e mitos, clique aqui e leia o post na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Scrum e as práticas de engenharia de software

O Scrum é uma metodologia adaptativa e voltada à gestão. Deixa lacunas em termos de riscos e engenharia. Por isso, o Scrum, de acordo com o contexto de cada projeto, deve ser combinado com outras práticas como, por exemplo, a gerência de riscos do PMI e práticas de engenharia de software. Neste post cito 2 práticas de engenharia do XP (Extreme Programming):

- Refactoring (refatoração): muito importante para que o código tenha um design cada vez mais limpo, elegante e flexível. Como o Scrum é um processo ágil, ocorrem vezes em que, devido ao prazo de entrega do release ao final do Sprint, um determinado código é entregue sem estar de acordo com o ideal. Isto gera um débito técnico (tech debt). Ou seja, quem entregou o código mentaliza que assim que houver a possibilidade, este código será melhorado, se tornará mais semântico, que aquele dado método que está muito grande será quebrado em métodos menores etc. E implementa estas melhorias! Para o usuário do software, o refactoring não muda nada, já que as mesmas funcionalidades serão mantidas. Porém, para o Time que desenvolveu o software, é um grande ganho de qualidade e, também, de tempo quando for necessário atender a requisitos de evolução relativos à manutenção, adaptação ou adição de novas funcionalidades.

- Pair Programming (programação em pares): visa a propriedade coletiva do código. Tem como meta a melhoria contínua do código e a idéia de que, em casos onde haja alguma dificuldade de imaginar a implementação de alguma estória, 2 cabeças pensem melhor que uma. Devido à questão da propriedade coletiva do código, a sugestão é que não se utilizem sempre os mesmos pares. O piloto deve trocar com o co-piloto e, também, as pessoas devem formar pares diferentes. Ao mesmo tempo, ninguém é obrigado a trabalhar em par o dia inteiro. Pode, por exemplo, trabalhar em par na parte da manhã e individualmente na parte da tarde. Ou vice versa! Pode trabalhar individualmente e, quando sentir a necessidade, devido a algum bloqueio de inspiração, programar em par. A programação em pares não deve ser imposta, mas uma atitude de convencimento através da conversa e da pontuação de seus benefícios.

Muitas empresas ainda não entendem a utilidade da programação em pares, com a mentalidade “pago o salário individualmente, não em par”. E muitos desenvolvedores dizem que é uma prática “furada”, sem nunca tê-la experimentado. Não se pode dizer que algo é ruim sem antes experimentar.

Scrum: por que fazer reuniões diárias?

O objetivo das reuniões diárias é que não somente o Scrum Master, mas todos os membros do Time, tenham um acompanhamento e feedback diário do Sprint. Nesta reunião, cada membro da equipe deve responder a 3 simples perguntas:

- O que fiz ontem?
- O que farei hoje?
- Houve algum impedimento?

É uma reunião rápida, realizada em pé e com um timebox de no máximo 15 minutos. Caso o(s) membro(s) reporte(m) impedimentos, o Scrum Master é responsável por, somente após a reunião, tratá-los e removê-los. Exemplos de impedimentos: solicitações referentes a outras atividades que não digam respeito ao projeto, problemas no servidor de teste, dificuldades com a tecnologia, entre outras.

O melhor horário para realizar esta reunião é na parte da manhã, quando todos os integrantes do Time tiverem chegado. Caso não seja possível, pode-se realizá-la em outro horário na parte da manhã ou da tarde. Mas é importante que sempre seja realizada em um horário fixo.

Esta reunião não é para expor um membro da equipe caso esteja com alguma dificuldade. É exatamente para que haja um feedback precoce e quaisquer dificuldades sejam sanadas. Assim, o Time se manterá sempre produtivo. Por outro lado, esta reunião também faz com que o Scrum Master detecte facilmente o “morcegão”, aquele integrante que "não quer nada com nada". Este tipo de profissional detesta Scrum.

Um bom teste para verificar se os membros do Time entenderam o significado da Daily Scrum é o Scrum Master deixar de aparecer na reunião um dado dia. Se o Time se reunir e realizar a reunião, isto significa que entendeu o seu significado.

Assim como todas as práticas sugeridas pelo Scrum, a reunião diária não deve ser imposta no estilo: “vocês vão fazer esta reunião diária porque eu sou o chefe e quero assim”. Deve-se, através da comunicação e negociação contínua, fazer com que as pessoas entendam o seu significado, passem a aderir e, conseqüentemente, apoiar sua utilidade e reconhecer seu grande valor no processo.

Scrum (Parte 4): Reuniões

Scrum – Reuniões (Cerimônias):

Sprint Planning (Planejamento do Sprint): o que vamos construir no Sprint e como iremos construir. O Product Owner (PO) explica o escopo (o que é mais importante para a dada iteração). Ele escreve as tarefas de cada história em alto nível (funcionalidades a serem construídas). Depois, o time estima a complexidade. O time escolhe o sprint backlog e escreve as tarefas para cada estória. O Time Boxed máximo para esta reunião é de 4 horas.

Daily Scrum (Reunião Diária): reunião diária para levantar como está ocorrendo o sprint. A sugestão é fazer a reunião todo dia pela manhã, se possível no começo do dia, se todos chegam no mesmo horário. O que fiz desde a última reunião? O que farei até a próxima reunião? Algum impedimento? Esta reunião é feita em pé para que seja rápida. O Scrum Master anota os impedimentos, se houverem, para depois da reunião tratá-los. Não é uma reunião de discussão. A reunião não é para o chefe, mas para o time. Um bom teste para o chefe é faltar uma vez ou outra para verificar se a equipe faz a reunião. Se não fizer, então a equipe não entendeu o propósito das reuniões diárias. Nesta reunião ninguém pode ficar exposto por não estar conseguindo realizar certas tarefas. A função do Scrum Master neste caso é escutar, depois "chamar para um café", detectar as dificuldades e pensar numa solução para esta pessoa (ex.: treinamento, ou colocar algum profissional mais experiente para auxiliá-lo). Esta reunião dá visibilidade a um processo que é empírico por natureza. As reuniões diárias visam também uma melhora constante da comunicação entre as pessoas e isso faz com que muito do que teria que ter sido escrito possa ser resolvido na base da conversa. E se uma pessoa sai da empresa, em uma equipe de 5? As outras 4 pessoas conhecem muito bem o projeto e dividirão as estórias que a pessoa que saiu deixar. Nada substitui uma boa conversa. A reunião diária leva ao feedback constante do projeto. É ESSENCIAL que pelo menos o Scrum Master e o time inteiro estejam presentes. Já o Product Owner deve estar disponível para ser consultado pelo Time diversas vezes ao longo do dia, para o caso de dúvidas em relação aos requisitos ilustrados nas estórias. Time boxed máximo: 15 minutos.

Sprint Review (Revisão do Sprint): onde o Tiime mostra o resultado do sprint (Team demo). É informal, sem slides. Todos podem participar, mas somente 'pigs' (Time, Product Owner e Scrum Master) podem falar. O Product Owner dará a nota para o Sprint, podendo aceitá-lo ou rejeitá-lo. O time boxed máximo é 2 horas.

Sprint Retrospective: lições (o que foi bom? O que precisa melhorar? O que o time pode resolver? O que a empresa precisa resolver?). Participam Product Owner, Scrum Master e Time). O time boxed máximo é de entre 2 horas.

Scrum (Parte 3): Papéis

Scrum – Papéis:

O Scrum possui os seguintes papéis:

1) Comprometidos:

- Product Owner (Dono do Produto): interage com os stakeholders (participantes do projeto) constantemente para alinhar a visão, ou seja, garantir que o seu entendimento, do Time e do Scrum Master está de acordo com as expectativas com o cliente. A palavra final do produto é do Product Owner, mas ele deve ser colaborativo com a equipe e não deve agir como um gerente de projetos centralizador. Ele depende do time e o time depende dele. No Scrum o foco é a equipe! Faz a interface Time e Scrum Master x Cliente. Atende aos requisitos do cliente e, por isso, se comporta como o próprio cliente do projeto. Desta forma, deve estar disponível ao Time para elucidação de dúvidas referentes aos requisitos contidos nas estórias. Tem responsabilidade sobre a elicitação dos requisitos e, conseqüentemente, o controle do Product Backlog. Sabe, define e redefine o nível de importância das estórias. Por exemplo, em caso de cronograma apertado, pode retirar uma estória do Sprint e deixá-la para o próximo. Monitora o projeto contra os objetivos de ROI e visão, prioriza e refina o Product Backlog medindo seu sucesso. Decide datas para apresentação dos releases. E, também, aceita ou rejeita o resultado do trabalho realizado pelo Time no final do Sprint. O perfil do Product Owner é muito mais voltado às questões do negócio do que às questões técnicas do projeto.

- Scrum Master (Mestre Scrum): guardião do processo, monitorando-o para garantir o sucesso da equipe. Remove obstáculos (por exemplo, problemas no servidor de teste). Blinda o time contra perturbações externas (por exemplo, outras pessoas fora da equipe que ficam pedindo favores e atrasando o Sprint). Promove rápidas reuniões diárias a fim de monitorar o andamento do processo. Organiza as reuniões de planejamento, retrospectiva e revisão de cada Sprint. Protege valores e princípios (não pode ser um profissional genérico, tem que entender de software e como é o dia-a-dia do desenvolvedor). Mantém a equipe mais funcional e produtiva (dentro do budget, busca ferramentas de apoio, trabalha motivação, consegue cursos para a equipe etc). Apóia e incentiva a colaboração no time; Facilita integração. O Scrum Master pode até ajudar a equipe de desenvolvimento (por exemplo, dar um upgrade no Hybernate) para acelerar o processo, mas não é parte do Time. Ele não aloca tarefa, ou seja, não diz "você vai implementar esta estória". O time gerencia e auto-organiza o próprio trabalho. Mas ele pode sugerir: por exemplo, ele percebe que um membro do time escolheu uma estória para a qual ainda não tenha habilidade suficiente para implementar. Ele vai conversar e negociar sobre o fato, para que o membro do Time escolha uma estória mais condizente com a sua habilidade. É responsável por manter o equilíbrio.

- Team (Time): Desenvolve as estórias do Sprint Backlog. Expande as estórias em tarefas mais detalhadas. Completa 100% de cada tarefa escolhida. Diariamente inspeciona o projeto para atingir os objetivos do Sprint. Normalmente é pequeno (5 a 9 pessoas). O Product Owner e o Scrum Master são outros papéis, não fazem parte do Time. Ou seja, a equipe pode ter 9 integrantes do Time mais o Product Owner mais o Scrum Master. É importante que o time tenha múltiplas habilidades distribuídas (ex.: profissional com habilidades SQL, outro de orientação a objeto, outro de teste, outro de webdesign, outro de redes etc). O time do projeto deve estar full time allocated, sem impedimentos ou interferências externas. Se não puder, definir quais e quantas pessoas "bombeiras" (ex.: 2) deverão dar suporte a outro(s) projeto(s). O Time é auto-organizado e responsável pela qualidade e em estimar complexidade das tarefas. Os bombeiros sentem a vantagem de não serem obrigadas a estarem 100% comprometidas com o projeto, mas sentem a desvantagem de não conseguir focar no projeto como gostariam.

2) Envolvidos: Clientes e usuários finais.

Scrum (Parte 2): Preceitos

Scrum – Preceitos

- Indivíduos e interações são mais importantes que processos e ferramentas.

- Software funcionando é mais importante do que documentação pesada.

- A colaboração com o cliente deve sobressair em relação à negociação do contrato. Isto é uma via de mão dupla, mas se o cliente percebe o nosso interesse no projeto, a parceria tende a ocorrer naturalmente.

- Responder a uma mudança é muito mais importante que seguir o plano. O Scrum, por ser adaptativo, acolhe mudanças. A equipe trabalha para produzir aquilo que traz valor ao negócio. Se uma regra do negócio mudar, o Scrum acolhe as mudanças e as implementam. O Scrum não tem dó nem piedade de jogar um projeto fora se o barco estiver rumando em um sentido oposto. Mas isso se aplica melhor a um ambiente organizacional interno. Em empresas que prestam serviços para outras empresas, a negociação terá de ser feita de forma mais abrangente, pois envolve contrato e custo.

- É colaborativo na sua essência e ideal para projetos de desenvolvimento de software em um cenário onde os requisitos mudam constantemente.

- Não fala sobre muitas disciplinas que o RUP e o XP implementam, mas não impede e estimula que adaptemos estas disciplinas. É mais focado na gestão do processo, enquanto o RUP e o XP são mais focados nas questões de engenharia.

- Cada composição de processos de engenharia deve ocorrer de acordo com cada contexto organizacional. Não se podem engessar as questões de engenharia de software. Por exemplo, escolher Scrum como processo e não atentar às lacunas que ele deixa.

- O Scrum aceita mudanças e não condena erros. Erros de cronograma, por exemplo: ao invés de apresentar o incremento com 10 estórias estimadas implementadas, apresenta o produto com 6 estórias implementadas. As outras 4, joga para o próximo sprint. Assim, a velociadade da equipe vai sendo ajustada de sprint em sprint até chegar a uma estimativa próxima do ideal.

- Comunicação melhorada, comprometimento, verdade e transparência.

- Times auto-organizados: o time é auto-organizado dentro dos limites delegados pelo Scrum Master, que é o guardião do processo. Quanto mais tempo um time está junto, mais conhecimento um do outro há e, portanto, melhor será a produtividade e a qualidade do projeto.

- Produto progride em sprints de 15 dias cada.

- Rever os problemas e levantar as lições aprendidas para melhoria constante do processo.

- Software funcionando, sempre como entrega. Ao final de cada sprint, o time deve apresentar um release, que deve ser um potencial entregável. Isto faz com que o cliente já tenha os subsistemas do software em produção e trazendo ROI (retorno ao investimento) a cada sprint de 3 semanas, o que é muito mais produtivo e lucrativo do que esperar meses ou anos para o projeto como um todo ser concluído.

Scrum (Parte 1): Introdução

Scrum - Introdução

Segundo o dicionário, Scrum significa “uma parte de um jogo de Rugby”. Em um jogo de Rugby os jogadores movem-se rápido para tentar apanhar a bola.

No mundo dos negócios, Scrum é um método ágil, iterativo e incremental para o Gerenciamento de Projetos, baseado nos princípios da comunicação, colaboração, simplicidade, negociação, alinhamento do negócio e resposta rápida ao mercado e à mudança constante dos requisitos.

Este método moderno compartilha os poderes, não possui aquela figura do gerente de projeto centralizador que o PMBOK defende.

Com Scrum o foco é na Equipe!

É compatível com CMMI 3 e ISO9001. Porém, somente a utilização do Scrum não basta (não é a bala de prata), uma vez que é uma metodologia voltada para a gestão de projetos, deixando lacunas em relação a questões de engenharia de software e riscos.

Deve-se analisar o que pode ser mesclado com Scrum, de acordo com o contexto de cada projeto, como por exemplo:
- Práticas como gerência de riscos do PMI;
- Disciplinas de engenharia do XP: trabalhar orientado a testes (TDD: Test Driven Development), refactoring, programação em pares e integração contínua.
- Disciplinas de engenharia do RUP: gerenciamento de configuração e mudanças.

Em empresas que utilizam processos tradicionais, ou nenhum processo consagrado, não necessariamente deve-se quebrar todos os paradigmas e sair adotando Scrum. Mas pode-se ir adotando práticas aos poucos para melhorar o trabalho, a organização e a produtividade.

No Silver Bullet (Sem Bala de Prata): Essência e Acidentes da Engenharia de Software

O artigo "No Silver Bullet" ("Sem Bala de Prata" ou "Não há Bala de Prata"), escrito por Frederick P. Brooks, Jr, em 1986, discute sob diversos pontos de vista os problemas e dificuldades encontradas nos processos de engenharia de software. É incrível como, apesar de ter sido escrito na década de 1980, este texto ainda seja tão atual!

O autor começa seu texto comparando o software ao lobisomem, dizendo que, de todos os monstros que preenchem os pesadelos de nosso folclore, nenhum nos aterroriza mais que lobisomens, porque eles inesperadamente se transformam do familiar ao horrível. Assim, procuram-se balas de prata que possam magicamente fazê-los descansar. O projeto de software familiar, pelo menos do ponto de vista do gerente não técnico, tem algo desta personagem; ele é normalmente inocente e honesto, mas capaz de se tornar um monstro de prazos deficientes, orçamentos estourados e produtos falhos. Surgem então súplicas desesperadas por uma bala de prata – algo que faça os custos de software cair tão rapidamente quanto os custos de hardware de computador.


Isto Precisa Ser Ouvido?—Dificuldades Essenciais

Não há balas de prata em vista, e a própria natureza do software torna improvável de que haverá alguma. Ou seja, nenhuma invenção irá fazer pela produtividade, confiança e simplicidade do software o que eletrônicos, transistores e integração em alta escala fizeram pelo hardware de computador.

Primeiro, deve-se observar que a anomalia não é que o progresso do software seja tão lento, mas que o progresso do hardware de computador seja tão rápido. Em nenhuma outra tecnologia alguém pode escolher ganhos tanto em melhoria de desempenho quanto em custos reduzidos.

Segundo, para ver qual taxa de progresso se pode esperar na tecnologia de software, devemos examinar as dificuldades daquela tecnologia. Seguindo Aristóteles, o autor as divide em:

 Essência: as dificuldades inerentes na natureza do software.
 Acidentes: dificuldades que afetam a produção do software, mas não são inerentes à sua natureza.

A essência de uma entidade do software é a construção de conceitos engrenados: conjuntos de dados, relacionamentos entre itens de dados, algoritmos e chamadas de funções. Esta essência é tão abstrata que uma construção conceitual é a mesma sob muitas representações diferentes. Portanto, é altamente precisa e rica em detalhes. O autor acredita que a parte mais difícil na construção do software seja a especificação, o projeto e o teste desta construção conceitual, e não o trabalho de representá-lo e testar a fidelidade da representação.

A construção de um software será sempre difícil. Não há nenhuma bala de prata inerente. Seguem as propriedades inerentes desta essência irredutível dos sistemas de software modernos:

Complexidade: as entidades do software talvez sejam mais complexas para seu tamanho que qualquer outra construção humana porque duas partes não são similares (pelo menos acima do nível de especificação). Se elas forem similares, criamos as duas partes em uma sub-rotina – aberta ou fechada. Neste aspecto, sistemas de software diferem profundamente de computadores, prédios ou automóveis, onde elementos repetidos abundam.

O escalonamento de uma entidade de software não é meramente a repetição dos mesmos elementos em tamanhos maiores, mas necessariamente um aumento no número de elementos diferentes. Na maioria dos casos, os elementos interagem entre si de forma não linear, e a complexidade do todo cresce muito mais que linearmente.

A complexidade do software é uma propriedade essencial, não acidental. Por isso, descrições de uma entidade de software que abstraem sua complexidade sempre abstraem sua essência.

Muitos dos problemas clássicos no desenvolvimento de produtos de software derivam desta complexidade essencial e seu aumento não linear de tamanho. Da complexidade surge dificuldade de comunicação entre os membros da equipe, o que leva a falhas no produto, custos exacerbados e atrasos nos prazos estabelecidos. Da complexidade surge dificuldade de enumerar, muito menos entender todos os estados do programa e a origem da deficiência. Da complexidade da função vem dificuldade de chamar a função, o que torna os programas difíceis de usar. Da complexidade de estrutura surge dificuldade de estender os programas com novas funções sem criar efeitos colaterais. Da complexidade de estrutura surgem estados invisíveis que constituem furos de segurança.

Não somente problemas técnicos, mas também de gerência surgem da complexidade. Isto dificulta a visão global, além de impedir a integridade conceitual. Torna difícil encontrar e controlar todos os pontos deficientes. Cria uma carga tremenda de aprendizagem e entendimento, o que torna a rotatividade de pessoal um desastre.

Conformidade: Einstein argumentava que deve haver explicações simplificadas da natureza, porque Deus não é excêntrico ou arbitrário. Porém, nenhuma fé conforta o engenheiro de software. Grande parte da complexidade que ele tem que dominar é de caráter arbitrário, forçada sem uma razão exata por muitas instituições humanas e sistemas para os quais suas interfaces devem se adaptar. Diferem de interface para interface e de tempo para tempo, não devido à necessidade, mas somente porque foram projetados por diferentes pessoas, em vez de Deus. Em muitos casos, o software deve se adaptar porque é novo e entrou em cena recentemente. Em outros, porque é percebido como o mais adaptável. Mas, em todos os casos, grande parte da complexidade surge da conformidade com outras interfaces; esta complexidade não pode ser simplificada por qualquer re-projeto isolado do software.

Mutabilidade: a entidade do software está constantemente sujeita às pressões por mudanças.
O software, dentro de um sistema, pode ser modificado mais facilmente – é puramente objeto intelectual, infinitamente maleável. Todo software de sucesso sofre mudança. Como o produto de software é feito para ser útil, as pessoas o testam em seu limite ou além do domínio original. As pressões por função estendida vêm principalmente dos usuários que apreciam a função básica e inventam novos usos para a mesma.

Um software de sucesso sobrevive além da vida normal do veículo de máquina para o qual é primeiramente escrito. Novos computadores, discos, displays, impressoras surgem e o software deve ser adaptável a estes dispositivos.

Em suma, o produto de software é incorporado a uma matriz cultural de aplicações, usuários, leis e veículos de máquina, que estão em constante mudança e suas mudanças, inexoravelmente, forçam mudanças no produto de software.

Invisibilidade: o autor defende que o software é invisível e invisualizável. Abstrações geométricas são ferramentas poderosas, mas a realidade do software não está incorporada inerentemente ao espaço. Por isso, não possui uma representação geométrica como, por exemplo, uma região possui mapas. Assim que tentamos diagramar a estrutura do software, descobrimos que ela não possui um, mas muitos gráficos superpostos. Os diversos gráficos podem representar o relacionamento entre fluxo de controle, fluxo de dados, camadas de dependência, seqüência de tempo e name-space.

Estes gráficos normalmente não são planos, nem hierárquicos. De fato, uma das formas de estabelecer um controle conceitual sobre tal estrutura é forçar o corte de vínculo até que um ou mais gráficos se tornem hierárquicos.

Apesar do progresso em restringir e simplificar as estruturas do software, elas permanecem inerentemente invisualizáveis e, por isso, não permitem à mente usar algumas de suas ferramentas mais poderosas. Esta carência não somente impede o processo de projeto dentro de uma mente, mas também dificulta bastante a comunicação entre mentes.


Progressos do Passado Resolveram Dificuldades Acidentais

O autor defende que, ao examinarmos as três etapas no desenvolvimento da tecnologia de software que foram mais produtivas no passado, descobrimos que cada uma atacou uma dificuldade diferente na construção do software, mas que aquelas dificuldades foram acidentais, não essenciais.

Linguagens de alto nível: a linha mais poderosa para a produtividade, confiança, simplicidade e inteligibilidade do software foi o uso das linguagens de alto nível na programação. A linguagem de alto nível livra um programa de muitas das suas complexidades acidentais. Seu maior benefício é fornecer todas as construções que o programador imagina no programa abstrato. E o desenvolvimento da linguagem se aproxima cada vez mais da sofisticação dos usuários.

Divisão do tempo (time-sharing): a divisão do tempo trouxe melhorias principalmente na produtividade dos programadores e na qualidade de seu produto, mas não tanto quanto as trazidas pelas linguagens de alto nível. A divisão de tempo preserva o imediatismo e, por isso, permite manter uma visão geral da complexidade.

Ambientes de programação unificada: Unix e Interlisp, os primeiros ambientes de programação integrada que chegaram a um uso abrangente, melhoraram a produtividade pois atacaram as dificuldades acidentais que resultam do uso de programas individuais em conjunto, através do fornecimento de bibliotecas integradas, formatos de arquivo unificados, filtros, entre outros. Como resultado, estruturas conceituais que, em princípio, poderiam chamar, alimentar e usar uma outra, podem fazê-lo facilmente na prática.


Esperanças para a Prata

O autor chama o leitor para refletir sobre os desenvolvimentos técnicos que são avançados como potenciais balas de prata. Quais problemas eles visam – problemas de essência, ou as dificuldades acidentais permanentes? Eles oferecem avanços revolucionários, ou incrementais?

Programação orientada a objeto: o autor mantém mais esperança em programação orientada a objeto do que em qualquer outra novidade técnica atual. Mesmo assim, defende que tais avanços não fazem mais do que remover todas as dificuldades acidentais de expressão do projeto. A complexidade do projeto por si só é essencial e estes ataques não trazem nenhuma mudança na mesma.
Inteligência artificial: muitas pessoas esperam avanços na inteligência artificial para prover o progresso revolucionário que proporcionará ganhos na ordem de magnitude em produtividade e qualidade de software. Mas o autor não. Para verificar o porquê, ele dissecar o que se entende por “Inteligência Artificial”.

D.L. Parnas esclareceu o caos terminológico: [4]

“Duas definições diferentes de IA estão em uso comum atualmente. IA-1: o uso de computadores para resolver problemas que anteriormente puderam ser resolvidos somente pela aplicação da inteligência humana. IA-2: o uso de um conjunto específico de técnicas de programação conhecidas como heurística ou programação baseada em regras. Nesta abordagem, experts humanos são estudados para determinar o que a heurística ou regras eles utilizam para resolver problemas... O programa é projetado para resolver um problema da forma que os humanos o resolveriam.”

“A primeira definição possui um significado deslizante... Algo pode se encaixar na definição da IA-1 atualmente, mas uma vez que vemos como o programa trabalha e entende o problema, não pensaremos mais nele como IA... Infelizmente não posso identificar um corpo de tecnologia que seja único para este campo... A maioria do trabalho é específica do problema e é necessária alguma abstração ou criatividade para verificar como transferi-la.”

O autor concorda com esta crítica. Por exemplo, as técnicas usadas para reconhecimento de fala parecem ter pouco em comum com aquelas usadas para reconhecimento de imagem e ambas são diferentes daquelas usadas em sistemas experts. O difícil na construção do software é decidir o que alguém quer dizer, não dizendo. Nenhuma facilidade de expressão pode trazer mais que ganhos marginais.

Sistemas expert: de acordo com o autor, a parte mais avançada da arte da inteligência artificial, e a mais aplicada, é a tecnologia para construir sistemas expert. Um sistema expert é um programa que contém uma máquina de inferência generalizada e uma base de regra, tem dados de entrada e suposições, explora as inferências deriváveis da base de regra, fornece conclusões e avisos, além de oferecer explicações sobre os resultados re-traçando o raciocínio para o usuário.

O poder destes sistemas vem das bases de conhecimento cada vez mais ricas, que refletem o mundo real com mais precisão. O autor crê que o avanço mais importante oferecido pela tecnologia seja a separação entre a complexidade da aplicação e o programa. Esta tecnologia pode ser aplicada à engenharia de software de diversas formas, como: sugestões sobre diferentes regras, avisos sobre estratégias de teste, alertar sobre as freqüências de tipos de bug e oferecer dicas de otimização.

A maior contribuição dos sistemas experts será colocar a serviço do programador inexperiente a experiência e a sabedoria acumulada dos melhores programadores. E esta contribuição não é pequena. A lacuna entre a melhor prática de engenharia de software e a prática média é muito grande – talvez maior que em qualquer outra disciplina de engenharia. Uma ferramenta que dissemine boas práticas é importante.

Programação “Automática”: o autor cita Parnas: “Em suma, a programação automática tem sempre sido mais um eufemismo para a programação com uma linguagem de alto nível do que os recursos atualmente disponíveis ao programador.” E conclui que é difícil ver como esta técnica generaliza para o mundo mais extenso do sistema de software ordinário, onde casos com propriedades nítidas são exceções. E também é difícil imaginar como este progresso na generalização pode ocorrer.

Programação gráfica: o autor diz que, às vezes, o teórico justifica a abordagem por considerar fluxogramas o meio de projeto de programa ideal por fornecerem facilidades poderosas para construí-lo. Mas defende que nada convincente ainda surgiu destes esforços e crê que não surgirá, pois vê o fluxograma como uma abstração muito pobre da estrutura do software e as telas da época eram muito pequenas, em pixels, para mostrar tanto o escopo quanto a resolução de qualquer diagrama de software detalhado. E conclui que, mais fundamentalmente, é muito difícil visualizar o software.

Verificação do programa: o autor não acredita em grandes mágicas em produtividade com este recurso. A verificação do programa é um conceito poderoso, mas não promete poupar tanto trabalho. Embora verificação possa reduzir a carga de teste de programa, não pode eliminá-la. Indo além, mesmo uma verificação perfeita do programa pode somente confirmar que o programa atende às suas especificações. A parte mais difícil da tarefa de software é chegar a uma especificação completa e muito da essência de um programa é, na verdade, debugar a especificação.

Ambientes e ferramentas: o autor diz que editores inteligentes específicos de linguagem são desenvolvimentos ainda não utilizados amplamente na prática, mas prometem principalmente resolver problemas de sintaxe e erros simples de semântica. Talvez o maior ganho dos ambientes de programação ainda seja o uso de sistemas de banco de dados integrados para acompanhamento dos inúmeros detalhes que devem ser recuperados apropriadamente pelo programador individual e mantidos atualizados para um grupo de colaboradores em um sistema único. O autor conclui que este trabalho é válido e trará frutos em produtividade e confiança. Mas, pela sua própria natureza, o retorno deve ser marginal.

Estações de Trabalho: o autor diz que as estações de trabalho cada vez mais poderosas são bem vindas, mas não podemos esperar progressos mágicos a partir delas.


Ataques Promissores na Essência Conceitual

De acordo com o autor, embora nenhum progresso tecnológico prometa trazer resultados mágicos com os quais somos tão familiares na área de hardware, há a abundância de bons trabalhos e a promessa de um progresso, se não espetacular, estável. Todos os ataques tecnológicos sobre os acidentes do processo de software são fundamentalmente limitados pela equação de produtividade:

tempo_de_tarefa = ∑ (freqüência) x (tempo)

Se os componentes conceituais da tarefa agora estão tomando a maioria do tempo, nenhuma atividade sobre os componentes da tarefa que são meramente a expressão dos conceitos pode trazer altos ganhos de produtividade. Por isso o autor defende que devemos considerar aqueles ataques que indicam a essência do problema de software, a formulação destas estruturas conceituais complexas. Felizmente, alguns desses ataques são muito promissores.

Comprar versus construir: a solução mais radical possível para a construção do software é não construí-lo completamente.

Todos os dias isto se torna mais fácil, já que cada vez mais vendedores oferecem mais e melhores produtos de software para uma variedade vertiginosa de aplicações. Enquanto os engenheiros de software têm trabalhado na metodologia de produção, a revolução do computador pessoal criou não um, mas muitos mercados de massa para o software. Fontes mais especializadas oferecem produtos de muito poderosos, e ferramentas de software e ambientes podem ser comprados de prateleira.

Qualquer um destes produtos é mais barato que construir um novo. Mesmo a um custo de cem mil dólares, o preço de compra do software é equivalente ao salário anual de somente um programador. A entrega é imediata e tais produtos tendem a ser muito melhor documentados e mantidos que o software feito em casa.

O autor defende que o desenvolvimento do mercado de massa seja a tendência na engenharia de software. O custo do software tem sempre sido de desenvolvimento, não de replicação. Dividir este custo mesmo entre alguns usuários corta radicalmente o custo por usuário. Outra forma de olhar para isto é que o uso de n cópias de um sistema de software multiplica efetivamente a produtividade de seus desenvolvedores por n.

Muitos usuários agora operam seus próprios computadores diariamente, utilizando diversas aplicações sem nunca ter escrito um programa. De fato, muitos desses usuários não podem escrever novos programas para as suas máquinas, mas são adeptos da solução de novos problemas com os mesmos.

O autor ainda defende que a estratégia de produtividade de software mais poderosa para muitas organizações seja equipar os trabalhadores intelectuais sem conhecimentos de computador com computadores pessoais e programas de escrita, desenho, arquivo e planilha. A mesma estratégia, executada com pacotes matemáticos e estatísticos e alguns recursos simples de programação, funcionará para centenas de cientistas de laboratório.

Refinamento de requisitos e prototipagem rápida: a parte mais difícil na construção de um sistema de software é decidir precisamente o que construir. Nenhuma outra parte do trabalho conceitual é tão difícil quanto estabelecer requisitos técnicos detalhados, incluindo todas as interfaces para pessoas, máquinas e outros sistemas de software. Nenhuma outra parte do trabalho prejudica o sistema resultante caso seja feita incorretamente. Nenhuma outra parte é tão difícil de corrigir mais tarde.

Portanto, as funções mais importantes que o construtor de software desenvolve para o cliente são a extração e o refinamento iterativos dos requisitos do produto. A verdade é que o cliente não sabe o que quer. O cliente normalmente não sabe quais questões precisam ser respondidas, e ele nunca pensou no problema com o detalhamento necessário para a especificação. Nem mesmo a simples resposta “Faça o novo sistema de software funcionar como o nosso velho sistema de processamento de informação manual” é na verdade tão simples. Ele nunca quer exatamente aquilo. Além disso, sistemas de software complexos são coisas que agem, movem e trabalham. É difícil de imaginar a dinâmica esta ação. Desta forma, no planejamento de qualquer atividade de projeto de software, é necessário permitir uma iteração extensiva entre o cliente e o projetista como parte da definição do sistema.

O autor ainda afirma que é realmente impossível para um cliente, mesmo trabalhando com um engenheiro de software, especificar completa, precisa e corretamente os requisitos exatos de um produto de software moderno antes de testar algumas versões do produto.

Portanto, um dos esforços tecnológicos atuais mais promissores e que ataca a essência do problema de software, e não os acidentes, é o desenvolvimento de abordagens e ferramentas para prototipagem rápida de sistemas, uma vez que a prototipagem é parte da especificação iterativa de requisitos. Um sistema de protótipo de software simula as interfaces importantes e desempenha as principais funções do sistema pretendido. Os protótipos normalmente desempenham as principais tarefas da aplicação, mas não tentam tratar as tarefas excepcionais, responder corretamente a entradas inválidas ou abortar de forma limpa. O propósito do protótipo é tornar real a estrutura conceitual especificada, para que o cliente possa testá-la em termos de consistência e usabilidade.

O autor diz que muito do procedimento atual de aquisição de software repousa sobre a suposição de que se pode especificar um sistema satisfatório antecipadamente, receber propostas para sua construção, construí-lo e instalá-lo. E defende que esta suposição é essencialmente incorreta, e que muitos problemas na aquisição de software surgem desta ilusão. Por isso, não podem ser corrigidos sem uma revisão fundamental – que prevê o desenvolvimento iterativo e a especificação de protótipos e produtos.

O desenvolvimento incremental evolui o software, não constrói. E o autor nos convida a transformar a natureza e a complexidade do estudo em matérias vivas, em vez de trabalhos mortos do homem. E diz que o cérebro sozinho é intrincado além de mapeamento, poderoso além da imitação, rico em diversidade, auto-protetor e auto-renovador. O segredo é que o cérebro é evoluído, não construído, e da mesma forma deve ocorrer com sistemas de software.

O autor ainda descreve a experiência de desenvolvimento incremental obtida no Software Engineering Laboratory, onde ministrava aulas, e defende que os mesmos benefícios obtidos em seus pequenos projetos podem ser obtidos em grandes projetos.

Grandes projetistas: o autor defende que a questão central de como melhorar os centros de software está nas pessoas. Podemos ter bons projetos seguindo boas práticas, que podem ser pensadas. Ressalta que os programadores fazem parte da camada mais inteligente da população, desta forma podem aprender boas práticas. Por isso, o grande impulso é propagar boas práticas modernas. Novos currículos, nova literatura, novas organizações a fim de elevar o nível de nossa prática de ruim para bom. Excelentes projetos vêm de excelentes projetistas. A construção do software é um processo criativo. Uma metodologia sólida pode capacitar e libertar a mente criativa. Muitos estudos mostram que projetistas muito melhores produzem estruturas que são mais velozes, menores, simples, limpas e com menos esforço.

Segundo o autor, um pequeno retrospecto mostra que, embora muitos sistemas de software bons e úteis tenham sido projetados por comitês, e construídos como parte de projetos multi-partes, os sistemas de software que realmente empolgaram e incitaram fãs apaixonados são produtos de uma ou poucas grandes mentes projetistas. Por isso, embora apóie fortemente os esforços de transferência de tecnologia e desenvolvimento dos programas de estudos em andamento, o autor pensa que o esforço mais importante a se realizar seja desenvolvermos maneiras de formar grandes projetistas.

Nenhuma organização de software pode ignorar este desafio, Bons gerentes, ainda que sejam escassos, não são tão escassos como bons projetistas. Grandes projetistas e grandes gerentes também são muito raros. A maioria das organizações faz esforços consideráveis para encontrar e cultivar grandes gerentes, mas o autor não conhece, ao menos na época, nenhuma que faça um esforço igual para encontrar e desenvolver grandes projetistas, de quem a excelência técnica dos produtos irá ultimamente depender.

A proposta do autor é que cada organização de software deve determinar e proclamar que grandes projetistas são tão importantes para o seu sucesso quanto grandes gerentes e, similarmente, nutri-los e recompensá-los. Não somente salário, mas gratificações de reconhecimento – tamanho do escritório, mobiliários, equipamento técnico pessoal, fundos para viagens e pessoal de apoio. E sugere alguns passos para que as organizações desenvolvam grandes projetistas:

 Identificar os melhores projetistas o mais cedo possível. Os melhores nem sempre são os mais experientes.
 Atribuir um mentor de carreira para ser responsável pelo desenvolvimento de cada profissional identificado e montar cuidadosamente um plano de carreira.
 Criar e manter um plano de desenvolvimento de carreira para o profissional, incluindo cuidadosamente aprendizagens selecionadas com os melhores projetistas do mercado, educação formal avançada e pequenos cursos, todos intercalados com projetos individuais e exercícios de liderança técnica.
 Dar oportunidades para os projetistas em crescimento interagirem e criarem estímulos.