12. Qualidade de Software: um Compromisso de Toda a Empresa

Transcrição

1 12. Qualidade de Software: um Compromisso de Toda a Empresa Qualidade de software é um assunto que muito se discute e pouco se pratica. Temos a impressão, às vezes, de que o discurso da qualidade não passa disso mesmo: discurso. Desde o início dos tempos do desenvolvimento de software, temos problemas de qualidade que não só ainda não foram resolvidos como ainda parece que se agravam a cada nova geração tecnológica. Prazos estourados, baixa produtividade, custos altos e qualidade deficiente parecem ser um fantasma que novas tecnologias nunca são capazes de exorcizar. O que é qualidade de software? Para abordarmos o problema da qualidade, é necessário, evidentemente, que tenhamos claro em primeiro lugar o que entendemos por qualidade de software. Utilizando uma simplificação, poderíamos dizer que todos os problemas de qualidade de software caem em uma das duas categorias seguintes: falhas na qualidade de conformidade e falhas na qualidade de desempenho. Qualidade de conformidade diz respeito à aderência do produto à finalidade para a qual foi construído. No nosso caso, estamos falando de software que dá ao seu usuário a funcionalidade de que ele precisa. Como é amplamente sabido, esse tipo de qualidade é mosca branca na nossa área. Por sua vez, qualidade de desempenho refere-se à capacidade do produto em apresentar consistentemente a funcionalidade desejada. Em termos de software, isso quer dizer boa performance, ausência de bugs, tolerância a falhas de infra-estrutura (hardware), tolerância a erros do usuário, etc. Por que qualidade? Por que deveríamos nos preocupar com a qualidade de software? Existem algumas razões óbvias. Ninguém gosta de software com bugs. Bugs podem causar prejuízos que variam desde a mera necessidade de reiniciar o sistema operacional até à perda de satélites de milhões de dólares (como o Clementine, um satélite construído para designar alvos, no projeto Guerra nas Estrelas, o qual, quando recebeu um comando para mirar um ponto na superfície lunar, ativou os foguetes direcionais e ficou girando até acabar o combustível...). Bugs podem fazer um banco perder milhões e a confiança dos clientes ou parar por horas uma companhia telefônica, impedindo a realização de telefonemas interurbanos (como já ocorreu com a AT&T). Os problemas de qualidade tendem a aumentar com o uso maciço das tecnologias de processamento distribuído, onde é muito mais difícil prever o que pode dar errado... Mas não é só isso. Os esforços pela qualidade na indústria automobilística provaram há tempos que a qualidade não tem custo. Ao contrário do que muita gente pensa, os investimentos em qualidade pagam-se em pouco tempo. O aumento de qualidade sempre é acompanhado por aumento de produtividade e redução de custos na forma de menos retrabalho e menor índice de refugo. Isso sem falar na maior satisfação do cliente, que pode ser refletida muitas vezes em maior participação no mercado. Assim, o axioma que diz que investimentos em qualidade dão lucro é plenamente aceito pela indústria de manufatura. Infelizmente, não é fácil encontrar quem acredite nisso na área de software. No entanto, as empresas que entenderam não existirem razões para se acreditar que esse axioma não funciona com software, puderam experimentar os benefícios da aplicação das técnicas de qualidade presentes na engenharia de produção na engenharia de software (leia a entrevista com Watts Humphrey nesta edição). Em um artigo na edição de março, apresentei e discuti o modelo CMM de qualidade de software, desenvolvido pelo SEI (Software Engineering Institute). Comentei, naquela ocasião, que os esforços em melhoria da qualidade não podem ter seu foco no produto apenas (fazer software melhor), mas principalmente no processo (fazer melhor o software).

2 O SEI apresentou, em um estudo recente, alguns números impressionantes relativos a melhorias de desempenho em empresas que investiram em qualidade seguindo os passos do CMM. O aumento médio de produtividade foi em média 35% por ano, enquanto o número de bugs encontrados em software após a entrega foi reduzido em 39% ao ano, chegando em algumas empresas a 95%! A relação custo/benefício, comparando os investimentos em qualidade com o retorno financeiro em termos de redução de custos via aumento de produtividade e redução de retrabalho e manutenção, ficou em média em 5 para 1, chegando a 9 para 1 em alguns casos isto é, para cada dólar investido em qualidade, essas empresas economizaram 5 dólares em média. Qualquer pessoa que conheça o Retorno Sobre o Investimento (ROI, em inglês) típico no mercado poderá confirmar que um ROI de 5:1 não se encontra todo dia... Custa caro investir em qualidade? Por que, então, existe tão pouco investimento em qualidade nas organizações típicas de desenvolvimento de software? Existe aí um problema cultural de grandes dimensões e difícil de superar. Infelizmente, a cultura atual de desenvolvimento de software baseia-se em crenças absurdas que se espalham por todos os níveis da organização. Nos níveis mais altos, isto é, na administração de informática, acredita-se que os investimentos típicos em qualidade de software (uso de processos padronizados de gerência de projetos, uso de metodologias de desenvolvimento, treinamento contínuo dos desenvolvedores, uso de métricas, estabelecimento de procedimentos eficazes de controle de qualidade de software, etc.) são caros demais, são mera burocracia e, principalmente, causam o alongamento dos prazos de desenvolvimento. Essa crença errônea é agravada pela limitada cultura de informática dos usuários e clientes, que tendem a pressionar por prazos completamente fora da realidade. Não passa pela cabeça de um alto executivo da GM ou da Volkswagen exigir de seus engenheiros a construção de uma nova fábrica de caminhões em três meses. Em nossa área, porém, é mais ou menos a isso que estamos submetidos dia após dia. No dizer de DeMarco e Lister (Peopleware, 1987), regularmente pondo o processo de desenvolvimento sob extrema pressão de tempo e depois aceitando produtos de baixa qualidade, a comunidade dos usuários de software mostrou seu verdadeiro padrão de qualidade. O desenvolvedor, por outro lado, além de acreditar nessas mesmas coisas, não aceita que ninguém lhe diga como deve fazer seu trabalho, afirmando que padronização de procedimentos e uso de best practices seriam uma violência à sua criatividade. Se levarmos em conta que a maioria dos desenvolvedores não foi formada em engenharia de software e aprendeu tudo o que sabe na marra, fica difícil acreditar nessa afirmação. Afinal, quem de nós confiaria sua saúde a um médico que aprendeu sozinho a profissão (fora da faculdade) e que tem solene desprezo pelos manuais de medicina? O caso é que a maioria de nós, desenvolvedores, não sabe desenvolver software, e deveríamos ter a humildade de aprender com quem já aprendeu. Existem erros graves de percepção subjacentes a essas crenças. O primeiro deles é em relação aos prazos. O executivo de informática costuma falhar em perceber que o tal aumento nos prazos é geralmente relativo aos prazos prometidos, e não aos efetivamente cumpridos. Como raramente são registrados os prazos reais, ao final dos projetos, o que fica no inconsciente do gerente como regra de referência são os prazos que ele costuma prometer, não os que ele cumpre! E não é preciso ter décadas de experiência na área para se saber que o cumprimento de cronogramas é a exceção, e não a regra. Minimizando a curva de aprendizado É claro que a introdução de procedimentos visando ao aumento da qualidade pode causar, num primeiro momento, uma pequena redução de produtividade, devido à curva de aprendizado. Isso acontece com a introdução de qualquer nova tecnologia em um ambiente de produção. De forma geral, a introdução de novas tecnologias segue o gráfico da figura da página seguinte. O grande problema é que esses projetos acabam sendo abandonados no ponto mínimo da curva, fazendo

3 com que os recursos investidos se percam e baixando o moral dos envolvidos. Mesmo assim, na prática, tenho observado (e conversado com colegas também) que, em ambientes de desenvolvimento caóticos (a grande maioria), qualquer esforço de melhoria, por simples que seja, causa rapidamente melhorias de produtividade. A barriga da curva é mínima ou mesmo inexistente. O simples esforço por melhorar a documentação do projeto e as verificações de qualidade desde o início reduzem significativamente o tempo gasto em testes e retrabalho, fazendo com freqüência com que mesmo o primeiro projeto em que se aplicam essas técnicas acabe sendo completado antes daquele que teria terminado sem essas mesmas técnicas, além de manter alto o moral dos envolvidos. A médio prazo, então, não há o que se discutir. Software com mais qualidade sofre menos manutenção, e as manutenções necessárias são feitas muito mais rapidamente. Isso libera recursos para o desenvolvimento de software novo, reduzindo o backlog e acelerando o desenvolvimento; mais software pode ser reutilizado; e o processo de desenvolvimento pode ser continuamente melhorado para aumentar sua eficiência (leia-se prazos menores). Para um esforço de melhoria de qualidade de software em uma organização funcionar, toda a organização deve estar comprometida. Especificamente, são fundamentais o compromisso da alta administração (de informática e usuária) e dos desenvolvedores, incluindo aí seus gerentes imediatos. Compromisso da alta administração não é apenas uma expressão bonita. Esse compromisso tem de se materializar em ações concretas. São necessários recursos para processos de melhoria (dinheiro e pessoas). É necessário bancar o esforço quando surgem crises. É necessário colocar em prática processos que garantam que pressões irrealistas dos usuários não esfumacem a iniciativa. É necessário treinamento e ampla comunicação. Enfim, são necessárias ações que somente executivos em nível de diretoria ou acima podem realizar. Em um esforço de melhoria da qualidade, o primeiro ponto é colocar em ordem o processo de planejamento e estimativas realistas de prazos. Assim, se o gerente de equipe não souber ou não quiser fazer esse planejamento, nada vai acontecer. Para garantir uma negociação realista com os usuários, a alta administração tem de garantir que os prazos estimados pelo gerente sejam aceitos pelos usuários. Os desenvolvedores, por sua vez, têm de comprometer-se a cumprir esses prazos, para que aumente a credibilidade das estimativas junto aos usuários. Dado que a alta administração garante prazos realistas e dá condições para que os desenvolvedores melhorem suas práticas, é responsabilidade destes últimos aplicar no seu trabalho diário os conhecimentos adquiridos em treinamentos. Também precisam comprometer-se em buscar continuamente mais conhecimentos, através de leitura de revistas técnicas, livros, pesquisa na Internet, etc. Afinal de contas, trata-se de melhorar o processo de engenharia e, se os próprios engenheiros não melhorarem suas práticas de trabalho, nada acontecerá. Em suma, os desenvolvedores devem melhorar seu trabalho, e a administração deve dar as condições para que isso aconteça. O comprometimento gerencial Para ilustrar o que entendo por comprometimento gerencial, apresento um caso real em que esses conceitos foram aplicados. Em uma empresa em que trabalhei, do setor financeiro, a questão de qualidade era crítica. Existia uma carga noturna de processamento batch em mainframe que era volumosa e sensível a problemas. Um programa que parasse, durante a noite, no caminho crítico da produção, levava a atrasos enormes no final do processamento batch, que durava o dia inteiro e não permitia a entrada dos sistemas on-line, impedindo ou dificultando muito a operação normal e o atendimento

4 aos clientes. A maioria dos abends durante a noite era causada por falhas de planejamento, testes malfeitos ou falta de coordenação entre a equipe de desenvolvimento/manutenção e algumas outras áreas-chave, como a produção ou a administração de bancos de dados. Para resolver o problema, foi instituído um processo de controle de manutenções, que exigia da equipe um planejamento detalhado, teste e coordenação com as áreas envolvidas. Nenhum programa poderia entrar em produção sem que todos os passos estabelecidos fossem cumpridos. Havia uma área especialmente encarregada de verificar o cumprimento do planejamento, cujo gerente respondia diretamente para o diretor de informática, evitando que pressões do gerente de desenvolvimento pudessem fazer com que se passasse por cima do processo estabelecido. Os desenvolvedores foram treinados no processo e foram-lhes mostrados os benefícios esperados. A solicitação de manutenção de prioridade normal tinha de ser apresentada com quase duas semanas de antecedência à entrada em produção dos programas alterados. Existia igualmente a possibilidade de implantações de maior prioridade acontecerem em um período inferior a essas duas semanas. Apesar de todas essas providências, esse processo não funcionou num primeiro momento. Os usuários continuaram pressionando os analistas por prazo e estes também não tinham o hábito de planejar as manutenções. Quando o usuário pedia algo, a equipe simplesmente sentava e fazia. As exceções eram a regra, e o processo praticamente não era cumprido. Solicitações de manutenção para o mesmo dia ou o dia seguinte eram aceitas sem maiores problemas e, freqüentemente, programas eram alterados no ambiente de produção sem mesmo passarem pela formalidade do processo. Não será surpresa para o leitor saber que os problemas de abends em produção continuaram ocorrendo com a mesma freqüência. Enfrentando o problema Percebendo esse problema, o diretor de informática, com suporte explícito do vice-presidente administrativo e tácito do presidente da empresa, estabeleceu que absolutamente todas as manutenções deveriam passar pelo processo. Além disso, os desenvolvedores e seus gerentes imediatos foram informados de que teriam de explicar muito bem cada abend em produção. Por outro lado, também foram encorajados a resistir às pressões dos usuários. Estes últimos foram instruídos a respeito do novo processo, e se deixou claro que eles, usuários, teriam de explicar muito bem por que suas solicitações exigiam os prazos curtos pedidos. A área de administração de mudanças recebeu poder para barrar qualquer solicitação de manutenção que entendesse estar fora dos padrões de qualidade, adiando as implantações em uma semana. Qualquer confronto de prazo entre essa gerência e a de desenvolvimento/manutenção seria levado para a decisão do próprio diretor de informática, que ouviria as razões do usuário. Todo abend em produção passaria a ser documentado por escrito, e a equipe de desenvolvimento teria de explicar suas causas e o que seria feito para evitar a recorrência. Estatísticas começaram a ser coletadas provando uma correlação positiva entre abends e manutenções urgentes, isto é, ficou comprovado que a maioria dos problemas em produção eram causados por programas alterados em manutenções de um dia para o outro. Níveis de erros em produção e de manutenções de prioridade urgente versus prioridade normal (duas semanas) eram coletados e divulgados, separados por equipe. Gerentes de equipes com altas taxas de erros e manutenções urgentes tinham de explicar as razões. Usuários de nível médio (um gerente na área de contabilidade, por exemplo) tinha de explicar ao seu diretor por que a sua manutenção era urgente, para que este pudesse por sua vez explicar ao diretor de informática, que liberaria a manutenção se esta fosse realmente necessária. É claro que, no início, houve uma celeuma geral. Ouviam-se gritos de terrorismo e burocracia por todos os corredores. Usuários queixavam-se da urgência de suas manutenções (na maioria não tão urgentes assim ou tornadas urgentes por não se ter feito planejamento no momento certo, com a devida antecedência). Desenvolvedores e seus gerentes imediatos não gostaram de ter a qualidade de seu trabalho medida e divulgada publicamente; a alta administração, porém, não se deixou intimidar pela gritaria.

5 Qual foi o resultado? Com o tempo, usuários e desenvolvedores aprenderam a separar o urgente do urgente. Tanto os usuários quanto os desenvolvedores aprenderam a planejar melhor as manutenções. Prazos realistas passaram a ser estabelecidos. Alterações em programas passaram a ser testadas melhor. Todas as áreas técnicas e funcionais passaram a ser sistematicamente envolvidas em cada manutenção, evitando problemas de coordenação. Em pouco tempo, as manutenções planejadas passaram a apresentar taxas baixíssimas de erros em produção. Os atrasos de processamento, que aconteciam em mais da metade dos dias do mês, passaram a ocorrer apenas em dois ou três dias por mês. A médio prazo, a relação entre manutenções urgentes e planejadas foi ficando cada vez menor. Afinal, diante das evidências, todo o mundo teve de concordar que a coisa tinha melhorado muito. A empresa como um todo beneficiou-se com a maior disponibilidade dos sistemas e melhor serviço ao cliente. A cultura nascente de planejamento levou ao aumento de produtividade e a um gerenciamento de prioridades muito mais eficaz. Os usuários descobriram que o day after de cada manutenção não precisava ser a roleta-russa a que estavam acostumados. E os desenvolvedores aprenderam que trabalhar de forma planejada lhes rendia mais noites de sono não interrompido (havia programadores que eram acordados à noite três vezes por semana, na maioria das vezes exigindo sua presença imediata para consertar programas abendados ) e a possibilidade de ir para casa no final do expediente, em vez de às 11 horas da noite, como era a regra. Observe-se que a empresa em questão é uma multinacional da área financeira, isto é, está imersa em um ambiente onde as mudanças acontecem muito depressa e a toda hora. Mudanças de mercado, mudanças de legislação, mudanças em diretrizes da matriz surgem o tempo todo. Mesmo assim, o processo descrito foi um sucesso total, e chegou-se a um nível de serviço invejável, sendo que se verificou que apenas algo em torno de 10% das manutenções realmente necessitavam ser implementadas com urgência (prazo inferior a duas semanas). Assim, se um processo como este pôde funcionar em uma organização com essas características, pode funcionar em qualquer ambiente empresarial. Esse exemplo deveria fazer com que gerentes de informática e usuários percebessem que o aumento da qualidade do software depende muito menos do uso de novas tecnologias do que do uso de práticas gerenciais adequadas. Treinar desenvolvedores e dar-lhes tempo para absorver o que aprenderam é fundamental. Impedir os usuários de colocar prazos absurdos para seus pedidos é fundamental. Alocar recursos (tempo, dinheiro e pessoas em dedicação integral) para trabalhar na melhoria dos processos de software é fundamental. É obvio que os desenvolvedores que estão construindo software não terão tempo para definir processos, metodologias, medir qualidade, definir, coletar e analisar métricas, etc. Atribuir essa responsabilidade a quem está desenvolvendo software é a melhor garantia de que nada vai acontecer. Se queremos qualidade, temos de investir nela. Mas tendo a certeza de que esse é um investimento que se paga muitas vezes e em pouco tempo. Autor: Átila Belloquim Biografia: Átila Belloquim é especialista em processo de desenvolvimento de software, doutorando em Administração de Empresas pela USP e conferencista em eventos de informática. Atualmente, é diretor de gestão do conhecimento da Choose Technologies e membro da coordenação do SPIN Brasil (grupo de usuários SEI/CMM) e do Conselho Editorial de DevMag.