Sete maneiras de melhorar o desenvolvimento de software

Para se concretizarem, os projetos de software exigem investimentos, apoio, cuidados, trabalho árduo e dedicação. Uma boa prática de gerenciamento de entrega garante que, depois de criado, o software possa ser implementado com êxito, atendendo às necessidades da área que o solicitou e, ainda, de outras unidades que queiram utilizá-lo no futuro.

Na lista de clientes que confirmam essa premissa está uma grande empresa britânica de telecomunicações. A companhia decidiu mudar de fornecedor na hora de realizar uma reengenharia dos sistemas para gestão da área de billing (bilhetagem) e da emissão de contas. A companhia tinha de implementar as mudanças em três meses ou poderia perder centenas de milhões de libras, inclusive com queda no valor das ações. Outra questão era que, na época, os processos para desenvolvimento de software eram ruins e o gerenciamento de entrega extremamente problemático.

A empresa de telecomunicações chamou uma empresa especializada para ajudá-la a entregar o software no prazo e recuperar um processo falho de gerenciamento das mudanças. Com isso, em três meses, fez os lançamentos pendentes e conseguiu realizar a reformulação de dois aplicativos. Mais importante, estabeleceu um processo de gerenciamento de entregas simples e direto para assegurar que futuras liberações aconteçam no devido tempo e com a qualidade exigida.

A seguir, segue um detalhamento de todo o processo, inclusive, com os erros cometidos.

1. Entender o estado atual do gerenciamento de entregas.
Você não pode começar a consertar alguma coisa sem entender o que ela é e qual o problema. O primeiro passo para aprimorar o sistema de gerenciamento das entregas do nosso cliente foi criar um panorama detalhado do processos antigos. Para começar, a empresa realizou várias sessões explanatórias com pessoas-chave envolvidas no processo de software.

Nas reuniões, o fornecedor descobriu que o ponto de partida era muito ruim: ainda havia software a espera de liberação, depois de dois meses em que ele estava pronto.
Os ambientes de teste eram limitados, sem gerenciamento e, portanto, desatualizados e impossíveis de usar. Pior ainda, melhorar novos ambientes e renovar os existentes era um processo relativamente lento.

Em média, um teste manual de software demorava três meses. E boa parte deles acabava sendo abandonado, o que reduzia a qualidade das soluções entregues.

De um modo geral, o engajamento da equipe de desenvolvimento era muito baixo. Como os profissionais nunca tinham sido ajudados a fornecer software de boa qualidade, regularmente, estavam desestimulados.

2. Estabelecer um ciclo regular de liberações.
Quando obtivemos um panorama geral do estado atual do processo, começamos a definir um ciclo regular de liberações.

Se a equipe de engenharia é o coração do projeto, o ciclo de liberações é seu batimento cardíaco. Para determinar a freqüência de liberações para produção, foi preciso descobrir de quanto teste não funcional precisaríamos e quanto tempo demoraria. Este projeto exigiu teste de regressão, desempenho e integração.
Estabelecer um ciclo de liberações é vital porque:

•         Cria uma oportunidade de discutir a fundo os testes não funcionais de que o software possa precisar.

•         Anuncia um cronograma de entrega das porções da funcionalidade que as partes interessadas poderão obter. Se elas souberem que haverá liberação de funcionalidade regularmente, podem continuar concordando em relação ao resultado final esperado.

•         Cria uma rotina que todas as equipes podem seguir (inclusive marketing e engenharia).

•         Dá aos clientes a confiança de que podem pedir algo e receber o que pediram.
O ciclo de liberações tem de ser o mais exato possível, não um número inatingível que você inventou durante o almoço. Antes de anunciá-lo, teste-o. Não há nada pior para um processo de liberações já falho do que mais datas ilusórias!

Sugerimos um ciclo semanal. Este plano, porém, mostrou-se inviável, já que o ambiente de banco de dados do cliente não podia ser renovado com suficiente rapidez. Então tentamos ciclos quinzenais. Não houve objeção imediata dos participantes, mas as duas primeiras tentativas fracassaram! Tornou-se viável depois que superamos alguns gargalos do ambiente e automatizamos alguns testes.

Por fim, estabelecemos um ciclo em que, a cada duas semanas, o código da equipe de engenharia, pronto para produção, era encaminhado para teste no sistema. Quinze dias depois, liberamos este código para produção.

Lembre-se: seu ciclo de liberações não diz respeito a quando seu cliente quer a liberação, mas quando você pode realizá-la com o nível desejado de qualidade. Nossos clientes apoiaram nosso ciclo de liberações porque nós os chamamos para ajudar a determiná-lo. A opinião dos clientes é apenas um dos fatores levados em conta para estabelecer a regularidade das liberações.

3. Adotar processos leves. Testá-los no início e revisá-los regularmente.
Se existe um princípio norteador da engenharia (ou reengenharia) de um processo, este princípio é desenvolver um pouco, analisar os resultados e fazer um pouco mais. Repita esta abordagem cíclica até alcançar os resultados desejados.

Processos leves são aqueles que não exigem aprovações longas e burocráticas ou reuniões intermináveis para obter consenso. Normalmente, demandam apenas o nível mínimo aceitável de inputs e outputs. O que lhes falta em volume e burocracia é compensado com resposta a mudanças e adoção popular!
Subjacente a esta abordagem há o problema espinhoso da documentação. Você precisa registrar o que fez e como fez. Do contrário, o que vai revisar e como vai melhorar?