Hardening Sprints: o que são eles? Você precisa deles?

Para quem está desenvolvendo um software usando o Scrum, XP ou outra abordagem de desenvolvimento incremental, a ideia de um “hardening sprint” ou uma “iteração do release” sempre surge. Mas as pessoas discordam sobre o que um “Hardening  sprint” deve incluir; sobre quando é você precisa fazer um, e se você deve fazê-lo afinal. Existe uma divisão considerável entre as pessoas que reconhecem que investir um pouco de tempo em Hardening é necessário para muitos ambientes e as pessoas que insistem em que atribuir um tempo nisso seja um sinal de que você está fazendo algumas coisas – ou tudo – erradas.

Hardening para garantir que ‘done’ significa ‘done’

Em um Hardening spring, a equipe tira o foco da entrega de novos recursos ou arquitetura e, em vez disso, gasta seu tempo na estabilização do sistema e fazendo com que ele esteja pronto para ser lançado.

Para algumas pessoas, Hardening sprints servem para concluir os testes e corrigir o trabalho que não poderia ser feito – ou não foi feito – antes. Isto pode incluir UAT ou outros testes de aceitação final, se for construído em um contrato ou modelo de governança.

Mike Cohn reconhece que as equipes podem precisar de um “release sprint” no final de cada ciclo de lançamento, porque a definição da equipe de “pronto” pode não ser suficiente – que um “produto potencialmente entregável” e um sistema que está realmente “entregável” ou pronto para produção não é a mesma coisa. Ele sugere que, depois de cada 3-5 iterações de recursos, a equipe pode querer programar um release sprint para fazer um trabalho como o do sistema manual caro e os testes de integração e comentários extras – o que for necessário para ter certeza de que o que eles acham que está feito, esteja realmente feito.

Anand Viswanath, em“The endofregression, stabilisation, hardeningor release sprints” (“O fim da regressão, estabilização, hardening ou release sprints”), descreve uma abordagem comum onde as equipes agendam um ou dois sprints de estabilização a cada 4-6 iterações para fazer testes de regressão e de sistema em um ambiente de preparo. Em seguida, corrige quaisquer erros que são encontrados. Como ele destaca, é difícil prever quantos testes podem ser necessários e quanto tempo demora para corrigir quaisquer problemas que sejam encontrados, então a ideia é fazer um time box neste trabalho e, em seguida, fazer uma triagem dos resultados.

Por acontecer de ser uma forma cara, arriscada e estressante de trabalhar, Vishwanath recomenda seguir o processo de entrega contínua para construir uma cadeia de testes automatizados até o momento de pré-lançamento, de forma a encontrar o máximo de problemas logo no início do processo. Esta ideia é boa, mas a maioria dos grandes projetos, especialmente os que começam a partir de uma base de código legacy, provavelmente ainda vai precisar de algum tipo de hardening ou fase de testes de integração em pontos regulares, independentemente de qual tipo de teste contínuo que está sendo fazendo.

Alguns testes, como os de interoperabilidade com outros sistemas e os operacionais não podem ser feitos de forma eficaz até mais tarde, quando houver um sistema de trabalho suficiente para fazer testes ponto a ponto. Alguns desses testes só podem ser feitos na realização (se você tiver um ambiente de teste), ou na produção. Para alguns sistemas, testes de carga e de estresse também precisam ser deixados para mais tarde, porque essas equipes não têm acesso a um sistema de teste grande o suficiente para executar cenários de carga elevada antes de chegar à produção.

Hardening é um sinal de que você não está fazendo as coisas direito?

Nem todo mundo pensa que agendar um hardeningsprint para testar e fazer a correção dos erros seja uma boa ideia:

“[um hardeningsprint] pode levar o crédito pelas coisas estúpidas inventadas que conduziram à ilusão institucionalizada e a ‘disfunção’ Agile”. Janelle Klein, Who Came up with the “Hardening Sprint”?

Para muitas pessoas, um hardening sprint ou lançamento de sprint é um processo que indica que algo não cheira bem: um sinal de que a equipe não está funcionando corretamente ou pensando claramente:

“O problema com o “hardening sprints é que você está mentindo. Você faz acreditar que todo o esforço feito nos sprints iniciais te deixa mais próximo do ‘done’. Mas é uma mentira – você não está perto de estar pronto para Production até começar sua fase de testes. Você escreveu um monte de código que não testou adequadamente. Você não sabe o quão bom ele é, não sabe a quantidade de trabalho que deixou de fazer e não sabe quanto tempo vai demorar, até que você esteja mergulhado na sua fase de teste. “Richard Kasperowski, Hardening sprints? Sorry, you are not Agile“

Ron Jeffries diz que um hardening sprint para teste e correção é claramente anti-padrão. Concordo: se você precisa de um hardening sprint separado para corrigir erros, então você está fazendo algo errado. Mas isso não significa que você não vai precisar de mais tempo para consertar as coisas antes do sistema entrar no ar – ter consciência de que está errado não faz os erros desaparecerem. Você ainda precisa resolvê-los. Existe um risco de que a sua definição de “done” pode ficar aquém do que é realmente necessário para o cliente, por isso você deve planejar para um ou mais hardening sprints antes do lançamento, verificar duas vezes e estabilizar as coisas, só para garantir.

Nestes casos, a necessidade de hardening sprints é um sinal de imaturidade de uma equipe (de um artigo de Paul Beavers):

1. Uma equipe iniciante de Agile vai preferir programar seis iterações hardening após um plano de desenvolvimento de doze iterações.
2. Conforme o tempo passa, a equipe vai amadurecer um pouco e você vai ver que a equipe Agile experiente vai diminuir o número de iterações hardening necessárias no final, só porque ela entende que precisa “corrigir” os erros mais críticos à medida que avança e que QA entende que precisa testar mais cedo e melhor no ciclo de lançamento.
3. Mais adiante a equipe vai notar que ao adicionar uma iteração hardening no meio do ciclo de desenvolvimento (e expulsar até os menores erros de prioridade logo no início do processo), manter a cadência mais tarde será bem mais fácil.
4. A etapa final de maturidade está presente quando a equipe passa a entender que “Hardening não é necessário mais”, porque tornaram a correção de bugs parte de suas rotinas diárias.

Hardening  é o que você precisa fazer para tornar o sistema pronto para Prdoduction

Outra maneira de olhar para hardening é que é quando você para de pensar sobre os recursos e concentra todo o seu tempo nas etapas detalhadas de implantação, instalação e configuração do sistema e tem certeza que tudo está funcionando de ponta-a-ponta. Em um hardening sprint, os clientes mais importantes são as operações e o suporte – as pessoas que vão ter certeza de que o sistema está funcionando, em vez dos usuários finais.

Para algumas equipes, esse tipo de Hardening  pode vir como uma surpresa feia e dispendiosa, depois que entender que o que eles precisam fazer é ter um protótipo funcional e torná-lo pronto para o mundo real:

“Todas essas coisas que foram ignoradas na primeira fase – o tratamento de erros, monitoramento, administração – precisam ser colocadas no produto” Catherine Powell, The HardeningMyth

Mas um hardening sprint pode também ser quando você toma cuidado com o que as operações chamam de operações de hardening: revisão e preparação do ambiente de produção e garantir o tempo de execução, restringindo o acesso aos dados de produção, verificando as configurações de sistema e aplicação, certificando-se de que a auditoria esteja habilitada adequadamente, a fiação, o sistema em que as operações de monitoramento e a coleta de métricas, verificando as dependências do sistema, como versões de plataforma de software e níveis de patch (e garantindo de que todos os sistemas sejam consistentes), completando revisões finais de segurança e outra revisão e portas de lançamento e garantindo que as pessoas que instalam e executam o software tenham as instruções corretas. É assim, também, quando você precisa preparar seu plano de rollback ou plano de recuperação se algo de ruim acontece com o lançamento, e testar o seu rollback e as etapas de recuperação. Percorra e relate o processo de liberação e as listas de verificação, e se certifique de que todos estejam preparados para a implantação de patches rapidamente após que o lançamento.

Hardening é algo que você tem que fazer

Algumas pessoas vêem uma necessidade óbvia para hardening sprints. Por exemplo, Dean Leffingwell inclui hardening sprints em seu “quadro Scaled Agile Framework“, porque não é um trabalho que só pode realmente ser feito em uma fase final do hardening:

• Exploratório final e testes de campo;
• Validação da Checklist contra a libertação, QA padrões de governança;
• Libere signoffs se você precisar deles;
• Documentação Ops;
• Pacote de implantação;
• Comunique o lançamento para todos (difícil de fazer em grandes empresas);
• Rastreabilidade de Etc para ter uma alta garantia e conformidade regulamentar.

Leffingwell deixa claro que hardening não deve incluir a integração do sistema, correção de bugs de alta prioridade, automatização do test scripts, documentação do usuário, os testes de regressão e a limpeza de código. Existe outro trabalho que deve ser feito antes, mas no primeiro ano ou mais, isso provavelmente terá que ser feito em uma fase tardia do hardening:

• Componente transversal de integração, integração terceirizada;
• Testes integrados em nível de sistema;
• Finalização do doc do usuário;
• Localização.

Dan Rawsthorne explica que as equipes precisam de pelo menos um lançamento de sprint no começo para se preparar para o lançamento da produção, porque até que tenha feito isso, você realmente não sabe o que você precisa fazer. Lançamento de sprints incluem tarefas como:

• Testes exploratórios para confirmar que as características fundamentais estejam funcionando adequadamente;
• Os testes de estresse de carga/ ensaio/ teste de desempenho – teste que é dispendioso de configurar e fazer;
• Testes de interoperabilidade com outros sistemas de produção;
• Corrigir qualquer coisa que saia deste teste;
• Reveja e termine toda a documentação;
• Suporte para treino, vendas e clientes sobre os novos recursos;
• Ajude com comunicados de imprensa e outros materiais de marketing.

O gerente de projeto de software de Bridge para Agility antecipa que as equipes vão precisar de pelo menos uma pequena iteração hardening antes do sistema estar pronto para o lançamento, mesmo que antecipem ao máximo o teste. A iteração de lançamento não é uma fase de teste de correção – é quando você se prepara para o lançamento: a captura de screenshots para materiais de marketing, os testes finais, pequenos ajustes, o término da documentação para quem precisa e o treinamento. Os autores sugerem, porém, que, se alguns desenvolvedores têm tempo sobrando na iteração de lançamento, eles podem fazer uma refatoração e outra limpeza – o que eu acho que é um mau conselho, dado que neste momento você não quer a novas variáveis ou riscos.

A entrega de Agile disciplinado, um método que foi desenvolvido por Scott Ambler, na IBM, para escalonar práticas Agile para grandes organizações e projetos de grande porte, inclui uma fase de transição, antes de cada lançamento para cuidar de:

• Planejamento e coordenação de transição;
• Fim de ciclo de vida de testes e correções;
• Teste e rehearsing de implantação;
• Dados de configuração e migração;
• Pilotos e testes beta (UAT curto, se necessário);
• Revisão e finalização de documentação;
• Operações de preparação e de apoio;
• Treinamento dos interessados;

Este tipo de transição pode levar pouco tempo, ou pode levar várias semanas, dependendo da situação.

O Hardening, apesar de levar algum tempo para se certificar de que o sistema está realmente pronto para ser lançado, não pode ser evitado. Quanto mais longo forem os seus ciclos de liberação, quanto mais longe os desenvolvimento estará da produção do dia-a-dia, mais hardening você precisa. Mesmo que você esteja fazendo testes disciplinados e comentários em fluxo, você vai encontrar alguns problemas no final. Mesmo se você planejou com antecedência para a transição, você vai entrar em detalhes operacionais que não conhece ou não entende.

Quando nós lançamos a nossa plataforma de de inicialização, tivemos que fazer o trabalho de hardening e de estabilização antes de obter o sistema pronto, e depois um pouco mais de trabalho para lidar com questões operacionais e exigências para quais não festávamos preparados. Foram incluídos o tempo no final de lançamentos subsequentes para testes extra, implantação e planejamento rollback e coordenação de lançamento.

Mas como encurtamoso nosso ciclo de lançamento (lançando menos, mas com mais frequência) e com a construção de mais fail-safes para o sistema e como nós aprendemos mais sobre o que precisava fazer ops, e investimos mais na simplificação e automatização de implantação e tudo o mais que pudemos, achamos que não precisamos de tempo fora de nossas interações regulares para o hardening. Nós ainda estamos fazendo hardening – mas agora isso faz parte do trabalho do dia-a-dia de construção e de lançamento de software.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em: http://swreflections.blogspot.com.br/2013/01/hardening-sprints-what-are-they-do-you.html