A implementação de bases sólidas de qualidade apoiadas por uma abordagem iterativa é um tema central na comunidade.

No entanto, raramente é acompanhado de casos concretos.

Por isso resolvi partilhar uma história fortemente inspirada da minha experiência pessoal, com toda a humildade.

O objetivo é que as práticas exemplificadas sejam relevantes para si e retratadas no contexto, sem tentar dar uma imagem diluída da realidade.

Foi retido o contexto mais relevante, abreviado em alguns parágrafos dos anos de implementação. A temporalidade não é, portanto, representada por escolha.

Em nenhuma circunstância deseja transmitir uma mensagem de facilidade, neste contexto ou em qualquer outro lugar.

Este artigo cobre as próximas etapas de uma possível abordagem :

• A necessidade de uma organização de “bater na parede” para reagir
• Obter o sponsoring do Business e do IT num período de oportunidades 
• Usar uma crise para acelerar a mudança de hábitos
• Implementando uma abordagem iterativa com foco no cliente e no negócio
• Focar a organização numa perspectiva transversal da qualidade
• Integrar a testabilidade by design antes dos ciclos de desenvolvimento
• Dê espaço para experimentar enquanto supervisiona a experiência do cliente

Junte-se à Unidade QE para acessar conteúdo exclusivo e regular da comunidade.

La Redoute, uma empresa histórica

La Redoute é uma empresa no centro do panorama francês, com uma reputação de 99% na França e mais de 180 anos de existência.

Todos guardam a memória dos catálogos na mesa da sala de família, folheados inúmeras vezes e cheios de surpresas.

É essa longevidade que também lhe rendeu o legado de um sistema de informações histórico e complexo, mais comumente caracterizado de legacy. 

Embora a La Redoute tenha se recuperado hoje, uma transformação profunda em todos os níveis da empresa foi necessária.

Neste artigo, focaremos o nosso prismo no negócio, no SI e na qualidade do software.

O confronto com a fria realidade

Identificamos a necessidade de as organizações “baterem na parede” para reagir.

Para a La Redoute, penso que este período crucial ocorreu em 2014, com a sua saída do grupo PPR, agora Kering.

A empresa se viu sozinha diante de perdas operacionais significativas, em um contexto organizacional e competitivo complicado.

Apesar de um site de comércio eletrônico fornecer mais de 50% do faturamento, o mainframe e sua lentidão inerente ainda eram o coração do reator da empresa. 

A plataforma de e-commerce também é um factor limitador com releases trimestrais, seguidos por períodos complicados de estabilização. 

As equipas estão regularmente cansadas e geralmente têm dificuldade em fazer mudanças estruturais, grandes projetos sofrem atrasos consideráveis.

Olhando para trás, essa fase de confronto a realidade é um fator determinante na capacidade de uma organização em acelerar a sua mudança.

Infelizmente, podemos traçar um paralelo com um fumador que não para de fumar até que sobreviva a um ataque cardíaco.

Uma transformação acelerada e drástica como única opção

A transformação acelerada era a única possibilidade de sobreviver em um contexto cada vez mais competitivo e globalizado. 

Foi durante este período que a La Redoute deu início a uma profunda transformação, combinando uma reformulação do modelo de negócios e a aposta na digitalização. 

Racionalização e proteção são a palavra de ordem em um contexto de sobrevivência onde cortes severos estão ocorrendo em todos os níveis (por exemplo, redução de 3.000 para 1.500 postos de trabalho). 

O IT não é excluído, deve unificar 3 plataformas web para responder às necessidades de aceleração e de racionalização. 

Ao mesmo tempo, o back-office deve se afastar completamente do mainframe histórico para uma arquitetura distribuída de forma a fornecer mais velocidade e flexibilidade. 

É neste contexto de fortes constrangimentos que se criam oportunidades, nomeadamente de qualidade, vector de aceleração e de estabilização das entregas de software. 

Uma liderança de transformação, o sponsor de facto

A primeira etapa de fundações era mais do que necessária. 

O desenvolvimento por si só não podia resolver os problemas de entregas e de qualidade encontrados. 

Através de uma análise sistemática do contexto, particularmente do ponto de vista sistêmico e organizacional, a falta de qualidade é saliente. 

A convergência para a nova plataforma acabou sendo uma oportunidade para começar com melhores bases, com um forte patrocínio, tanto de negócios quanto de TI. 

Sendo forte a necessidade de transformação, as pessoas em liderança formal ou posições informais de influência estão impulsionando uma dinâmica.

Aqui encontramos o pré-requisito do sponsor para uma abordagem de qualidade, que muitas vezes não existe e acaba sendo fatal.

A transversalidade do negócio e do IT no contexto compartilhado tem sido facilitada pela história e pelo senso de urgência de transformação.

“Entregar menos, mas todos os dias”, uma mensagem forte e necessária

Uma visão de equipa é movida para ser capaz de entregar pequenas mudanças todos os dias, com confiança e estabilidade. 

Esta é uma mensagem forte em um contexto anterior, onde o número de assuntos enviados para uma entrega era o índice de desempenho seguido. 

Além disso, este princípio implica mudanças drásticas nos processos de desenvolvimento de software, em contato direto com os hábitos da organização.

Veja o exemplo do controle de versão e das branches, onde os desenvolvedores geralmente gostam de ter seu próprio branch “local”.

Pessoalmente, esta palavra “local” ativa um sinal de alerta interno.

Faz a ligação com o system-thinking e os perigos das otimizações locais.

Por exemplo, foi necessário mudar para um trunk-based development para suportar um ciclo de entrega diário com pequenas mudanças sincronizadas.

Daí a necessidade de ter sponsors para ter sucesso nessas transformações, a mudança de hábito organizacional sendo um verdadeiro desafio. 

É implementada uma bateria de teste mínima, estável, rápida e orientada para o cliente

Os ciclos de entrega podem ser mais rápidos e controlados, falta garantir a sua qualidade.

É aqui que uma campanha de teste mínima é configurada.

As funções mínimas são definidas para garantir essa abordagem: gerente de projeto multifuncional, gerente de qualidade, DevOps, colocando os Product Owner, os desenvolvedores e o controle de qualidade no centro do processo. 

É definida uma bateria de testes inicial, com o objetivo de validar o número mínimo de funcionalidades chaves do ponto de vista do cliente.

No contexto da empresa, muitas vezes nos referimos às customer journeys em conexão com personas de forma a alinhar os testes realizados.

As primeiras campanhas são difíceis, os testes têm dificuldade em ficar estáveis ​​devido a problemas de dados que devem ser resolvidos. 

O business começa a ficar impaciente, temos de defender a abordagem que existe para não ceder aos velhos hábitos. 

Depois de algumas semanas, um ritmo de entrega começa a se estabelecer, mesmo que poucas mudanças sejam integradas. 

Integrar a testabilidade “por design” antes dos ciclos de desenvolvimento

O sucesso nos primeiros ciclos é uma primeira etapa, mas como manter o ritmo?

Por experiência própria, o controle do run é um pré-requisito para uma organização que deseja ser mais ágil e acelerar.

O uso de LEAN, problem solving e automação são frequentemente combinados para alcançar resultados estruturais.

Uma vez sob controle, resta a chegar a um equilíbrio entre as evoluções e a manutenção do perímetro existente.

É neste momento que os requisitos precisam de ser traduzidos em testes em paralelo dos desenvolvimentos.

Sem falar em BDD ou TDD, a abordagem ficou pragmática, alinhando os casos de uso com os testes funcionais.

O trabalho das equipas de QA durante o sprint é de preparar os testes automáticos, enquanto validam os casos de uso manualmente, conforme e quando as entregas diárias são feitas.

É um exercício complicado, cheio de restrições, que exige uma verdadeira priorização, partilha entre as equipas e modularidade dos testes.

Este assunto nunca acaba, o foco deve ser em aprimorar o amadurecimento das equipas na sua implantação e garantir a estabilidade e manutenção.

O negócio precisa de liberdade de experimentação

Para experimentar mais fortemente as ideias no mundo das interações digitais, as equipas precisam de mais liberdade de ação. 

Os feature-flags são estudados.

Eles representam verdadeiros desafios de engenharia para serem usados ​​corretamente, desde a criação, a manutenção e até sua eliminação.

Costumam ser úteis para as equipas de TI para gerir entregas e ativações progressivas, mas são dificilmente acessíveis para os negócios.

É aqui que a complementaridade por meio de mecanismos de A/B Testing entra em ação para agregar um valor transversal à organização. 

Eles permitem entregar funcionalidades parciais, podendo ao mesmo tempo ativá-los ou até desativá-los gradualmente. 

Esse grau de liberdade na plataforma levanta a questão da estabilidade da experiência do cliente.

Como garantir que não seja afetada por todas essas experimentações contínuas? 

O início da Observabilidade

Testes funcionais focados nas jornadas do cliente são uma parte essencial.

Supervisão técnica falando de processador, memória e latência de rede é cansativa e longe da experiência do cliente.

Um foco na customer journey é necessário.

A execução regular de testes funcionais em produção fornece uma primeira garantia de estabilidade.

Diretamente integradas à supervisão, as equipas de business e de IT podem ter uma visão abrangente da experiência em diferentes dispositivos, países e ambientes.

Com o tempo, também percebemos que os dados usados ​​apenas na supervisão também podem ser úteis na geração de relatórios.

A implementação de dashboards possibilita, por exemplo, monitorar a estabilidade da página de entrada, acesso a conta do cliente, adicionar ao carrinho, etc.

Sem aperceber-se, a equipa também segue KPIs comuns entre business e IT, facilitando a colaboração estendida e acelerada. 

As guerras do excel e da justificações de perdas estão quase esquecidas.

O estabelecimento de fundações, uma abordagem transversal, iterativa e incremental

Julgo que essas três palavras resumem o estabelecimento de uma base para uma abordagem de qualidade.

Sem transversalidade, o patrocínio parece difícil e as otimizações locais apenas alternam resoluções temporárias e o surgimento de novos problemas.

Práticas transversais são também encontradas, que variam de negócios, controle de qualidade, TI, desenvolvimento e operações.

Você tem que saber como compor e se adaptar, como em um conjunto de jazz, ao contexto e às questões do momento, daí o valor de um processo iterativo.

As iterações trazem a capacidade de limitar a complexidade inicial e adaptar processos eficientes ou restrições ineficientes com muito mais rapidez.

É por isso que uma abordagem incremental em um ecossistema complexo e incerto com forte mudança humana é mais do que relevante.

Por fim, não esqueçamos que um processo iterativo não significa necessariamente que não tenha um objetivo, uma visão ou um destino em mente.

A visão é a diferença fundamental para uma equipa que chega ao porto de destino, sem acabar por voltar ao porto de partida.