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.