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?
Não é o tipo de documentação volumosa que ameaça as florestas tropicais ou dá sono nos leitores. É a documentação que as pessoas (técnicas ou não) podem ler e seguir.
A equipe de engenharia escolheu uma ferramenta comercial para documentar seu trabalho colaborativo. Os engenheiros usaram o software para elaborar uma documentação mínima, porém eficaz, do que estavam concordando em criar em cada ciclo de trabalho. Registraram o que e como tinham criado e o que era necessário para que entrasse em funcionamento. Vimos o valor desta abordagem e a implementamos -- assim como a ferramenta – para o restante dos envolvidos no processo.
Inicialmente, sugerimos uma seqüência de tarefas para liberar o software que recebemos das equipes de engenharia, abrangendo o modo como recebemos a entrega por parte do sistema de gerenciamento de controle de origem, que nomes os pacotes teriam e como cada elemento (código executável, scripts de banco de dados etc.) funcionaria em quais plataformas. Depois fizemos um teste simulado utilizando código fictício para cada elemento. Testamos nossa seqüência documentando o que e como fizemos. Isso formou a base das instruções de instalação.
Em seguida, as pessoas que iriam implementar o release real fizeram outro teste simulado usando apenas a nossa documentação. Elas estenderam, corrigiram e aprimoraram nossas instruções. O processo se tornou mais abrangente e todos colaboraram com a documentação. O processo foi adotado de maneira mais ampla e com mais qualidade, já que todos ajudaram a defini-lo.
Revisamos o processo depois de cada liberação. Examinamos a documentação e identificamos mudanças feitas durante a liberação. A cada vez, verificamos como a documentação poderia ser aprimorada e incorporamos os aprimoramentos ao processo.
4. Estabelecer uma infra-estrutura de liberações no início.
A infra-estrutura de liberações é tudo aquilo que precisa existir para que o software seja implementado e as pessoas possam utilizá-lo. Seu compromisso com o cliente não é somente criar um software excelente, mas que ele esteja disponível para ser acessado e utilizado.
Para obter um bom processo de liberação, é crucial que você descubra o que precisa estar implantando para disponibilizar ao cliente antes da equipe de engenharia acabar de criar o software.
A infra-estrutura de liberações cobre hardware, storage, conexões de rede, banda larga, licenças de software, perfis dos usuários e permissões de acesso. Recursos humanos e habilidades também fazem parte da infra-estrutura de liberações. Se você precisa que um software especializado seja instalado e configurado, por exemplo, não é uma atitude inteligente excluir do seu plano de infra-estrutura a disponibilidade das habilidades envolvidas ou o custo de obtê-las.
Quando estiver em busca do hardware necessários ou das habilidades que faltam (por exemplo, para configurar redes seguras), é vital descobrir gargalos ocultos o mais cedo possível. Você precisa resolvê-los antes que eles atrasem a entrega do software.
Não é coisa simples. Nós nos esforçamos para implantar nossa infra-estrutura de liberações assim que iniciamos o projeto. Depois de seis semanas, ainda estávamos esperando memória e hard drives especiais para os servidores de teste!
5. Automatizar e padronizar o máximo possível.
A automação permite que você execute tarefas repetitivas sem comprometer recursos humanos valiosos. A padronização garante que inputs e outputs da automação sejam consistentes o tempo todo.
Antes do nosso envolvimento com o projeto, as equipes de engenharia produziam manualmente um pacote implementável. Não havia garantia de que um novo pacote seria igual ao anterior. Na realidade, nem havia garantia de que era o software que as equipes andavam desenvolvendo e se funcionaria! Muitas vezes, a equipe técnica levava dias para criar um pacote com os recursos que estavam sendo entregues em uma estrutura que pudesse ser implementada.
Formulamos imediatamente uma estrutura e critérios de aceitação para o pacote implementável que as equipes estavam nos entregando e as ajudamos a padronizar o empacotamento. Isso ativou a implementação de processos automatizados para criar o software nesta estrutura consistente para cada ponto da liberação.
De repente, o empacotamento do software para liberação deixou de ser um problema. Sua executabilidade estava garantida, já que tínhamos automatizado a verificação dos critérios de aceitação — por exemplo, testar o código antes da entrega e implementar o teste para assegurar que a implementação real poderia ser feita. Como resultado, conseguimos empacotar, versionar, testar e implementar código acabado com um único comando em pouquíssimo tempo.
Mas a automação não parou por aí. A cada ciclo de desenvolvimento, tínhamos que fazer ainda mais testes de regressão. Os testes de regressão existentes levavam três semanas para serem executados manualmente e, por isso, as liberações nunca eram bem testadas.
No nosso recém-criado ciclo de liberações, tínhamos que realizar testes de regressão, desempenho e integração em duas semanas para podermos colocar em produção. Podíamos superar a questão de ter diferentes tipos de teste utilizando ambientes separados para cada um. Mas como encaixar três meses de testes de regressão em um período de duas semanas?!
Iniciamos um exercício de priorização. O cliente identificou os testes de regressão mais prioritários, o mínimo que aceitaria como prova de que a antiga funcionalidade ainda executava. Depois partimos para automatizar este conjunto. Testes de aceitação subseqüentes também se tornaram automatizados, assegurando que poderíamos fazer testes de regressão em cada liberação em algumas horas em vez de dias.
6. Estabelecer expectativas positivas.
Se a liberação de software é importante para você, não faça segredo disso. Nossas equipes reforçaram o compromisso de liberar o software quando sabiam que era importante.
Endossamos esta importância ao estabelecer que o gerente de liberações designado presumiria que o software estaria pronto na data que as equipes concordaram que ele estaria pronto. Fizemos o gerente de programa (na realidade, nosso cliente) explicar para as equipes por que esta liberação era importante. (No fim das contas, o motivo era não perder muito dinheiro!)
Pedimos que o software fornecido pelas equipes de engenharia seguisse um padrão (versionado, testado, documentado e empacotado). Estabelecemos que solicitaríamos este empacotamento padrão para cada ciclo de liberação. Tivemos de explicar por que queríamos o software desta maneira (nosso processo automatizado se tornava mais fácil e consistente) e incorporamos o feedback da equipe ao processo.
Estabelecer expectativas positivas é uma ótima maneira de empoderar todos os envolvidos no processo. Não nos foi delegada nenhuma autoridade executiva e, portanto, não receávamos sansões ou demissões. Tínhamos o poder da expectativa positiva para fazer as pessoas aderirem e nos ajudarem a melhorar o processo de liberação. Elas tomaram decisões-chave (que nunca tinham se sentido capazes de tomar antes) porque "Mike e Tym precisam deste software na quinta-feira e nós dissemos que o entregaríamos”.
7. Investir em pessoas.
Não importa o quanto você gaste em hardware, software e processos imaginativos -- sem o comprometimento dos membros da equipe você não alcançará um sucesso sustentável na liberação do seu software.Talvez você nem mesmo tenha um software para liberar!
Provavelmente você pensou que falaríamos em arregimentar as pessoas certas e recompensá-las bem ou que discorreríamos sobre as ferramentas e qualificações necessárias para o trabalho. A verdade é que você sabe que precisa ter as pessoas certas nas equipes (a definição de "certas" varia de uma empresa para outra), você deve recompensá-las adequadamente pelo valor que agregam e, sim, você deve assegurar que elas tenham as ferramentas e qualificações necessárias.
Nossa pressuposição básica é de que as pessoas estão inerentemente interessadas em fazer um bom trabalho. Se você quiser que os membros das suas equipes se importem com seu produto e com a realização de um bom trabalho, antes você precisa demonstrar que se importa com o que é importante para elas. Desde o começo do projeto, criamos um ótimo relacionamento com todos os membros das equipes, baseado em compreensão e respeito mútuo. Demonstramos que éramos flexíveis em termos de desafios pessoais e fizemos o que estava ao nosso alcance para ajudar. Comprar almoço, pegar alguma coisa para beber, organizar treinamento, aconselhar, ouvir problemas, fazer o papel do advogado do diabo... fizemos o que era necessário para que cada indivíduo se sentisse valorizado e um elemento vital do processo.
No nosso primeiro contato com o projeto, detectamos um sentimento geral de apatia. Alguns funcionários fixos mais antigos estavam simplesmente à espera de um pacote de dispensa de pessoal; outros não eram chamados para nada porque nunca tinham feito nada certo. Nos dedicamos a criar um bom relacionamento e despertar um auto-julgamento positivo para que as pessoas voltassem a se importar em adicionar valor pessoal ao processo.
O gerenciamento de liberações é uma parte muito importante de qualquer projeto de software e, freqüentemente, não recebe a atenção que merece. Poderíamos compartilhar muitas outras dicas e observações excelentes sobre nossa experiência de fortalecer o processo de liberações desta empresa de telecomunicações de médio porte. Mas estas são as sete mais importantes para nós neste caso específico, embora suponhamos que sejam idéias muito boas para qualquer situação.
Um bom gerenciamento de liberações exige trabalho árduo, determinação e ótima comunicação. Mas o mais importante é a habilidade de revisar, aprender e adaptar melhorias.
Boa sorte!
Mike Sutton era um menino programador prodígio. Hoje, depois de 15 anos de atuação, deixou de ser tão menino mas é prodigioso em ajudar as equipes de programação a se tornarem fornecedoras de soluções vencedoras utilizando metodologias ágeis e abordagens pragmáticas como as descritas neste artigo. CEO da Wizewerx, é consultor de TI independente especializado em soluções de desenvolvimento Java high-end e coaching e mentoring para métodos ágeis e já trabalhou para empresas de primeira linha no Reino Unido e na Europa.
Tym Moore estava ocupado demais ajudando seus clientes e não conseguiu enviar a tempo sua biografia de autor.
copiado de
