Como o ágil funciona ao substituir um sistema em funcionamento?

Em um mundo Agile ideal, você cria rapidamente um subconjunto pequeno, mas útil, do sistema final desejado e o entrega aos usuários. Eles estão animados, porque é útil, eles começam a usá-lo e dão feedback. Em seguida, você decide o que adicionar, constrói e repete até ficar sem tempo.

Recentemente, tive alguns projetos que envolveram a substituição de algum tipo de sistema de trabalho. O modelo acima simplesmente não funcionou: até você criar um sistema que incluísse praticamente toda a funcionalidade do sistema existente, os usuários não tinham interesse algum. Eles não usariam.

Como você aplica o Agile quando "o menor subconjunto útil" é "tudo isso"?

A solução ágil pode não ser substituir tudo de uma só vez, mas colocar a substituição gradualmente.

Introduzir o novo sistema gradualmente, pouco a pouco, mantendo partes do sistema antigo em execução. O sistema antigo não é desligado de uma só vez, apenas desaparece. As novas peças fornecem novas funcionalidades ou outros benefícios, para que os usuários tenham prazer em usá-las. Isso também é menos arriscado, pois você tem um sistema de trabalho 100% sempre.

• Leia mais de Martin Fowler .
• As estratégias do trabalho eficaz de Michael Feather com código legado podem ser úteis

Em vez de reescrever o sistema existente (que, como você mencionou, exigirá bastante esforço antes que o novo sistema corresponda à funcionalidade existente), considere a abordagem de estrangulamento do cipó . Basicamente, você implementa novas funcionalidades usando sua nova abordagem sobre o aplicativo existente. Eventualmente, à medida que você resolve as deficiências do sistema antigo para lidar com novas funcionalidades, o novo código substituirá completamente o antigo.

Isso requer mais precisão e esforço do que uma "reinicialização" do aplicativo antigo. Mas você obtém um tempo menor de retorno do investimento. Além disso, ao longo do processo, você pode colocar ganchos no lugar para permitir que o "novo" sistema seja mais facilmente estrangulado pelo próximo "novo" sistema.

A liberação de pequenos incrementos no mundo pode funcionar em projetos greenfield, mas mesmo assim o pequeno número de recursos pode não ser muito útil.

O Scrum defende que, após cada sprint, o produto seja "potencialmente descartável". Ele não precisa ser enviado, mas deve ter a qualidade de um produto expedível.

Se você deseja fornecer aos usuários uma versão incremental do aplicativo, é possível classificá-lo como Alpha e Beta e então liberar versões Candidate, enquanto o aplicativo de produção real ainda está sendo usado.

Você pode descobrir que novos recursos são adicionados e antigos são descartados se você estiver incorporando comentários dos usuários.

Trabalhei em uma linha enorme de substituição de aplicativos de negócios para uma importante rede nacional de TV a cabo. O desenvolvimento do novo sistema foi feito com o SCRUM, foi um projeto de desenvolvimento de 18 a 24 meses para reimplementar quase todos os principais subsistemas; com quase 10 anos de idade.

Houve uma fase de planejamento de seis meses antes do início do desenvolvimento, mas também foi abordado como SCRUM. É aqui que o proprietário do produto escreve lojas e épicos de alto nível após a análise do sistema existente e a entrevista com os clientes.

O sistema existente era extremamente estável quando entrou no modo de manutenção crítica; apenas mostrar problemas de rolha foram corrigidos, tudo registrado apenas para fins históricos e para garantir que os mesmos problemas não aparecessem no novo sistema.

O novo sistema evoluiu conforme descrito em um processo Agile, sendo extremamente suave na maior parte do tempo. Quando o sistema de substituição alcançou a parte do recurso, ele não entrou em produção, mas em testes de produção paralelos. Um subconjunto de trabalhadores não críticos começou a usar os dois sistemas para validar que o novo sistema se comportou como o antigo; com os bugs antigos corrigidos, é claro.

Quando o novo sistema alcançou quase 100% de novos recursos completos, ele foi implementado para execuções gerais de produção paralela, que duraram alguns meses.

Depois que o cliente considerou que atendia às suas necessidades, o sistema antigo era copiado, desligado e em funcionamento. Suponho que eles propuseram novamente o hardware antigo do sistema porque nunca precisaram voltar ao sistema antigo após o corte.

Ainda acho que o ágil agrega muito valor nesse cenário.

Só que você tem um objetivo final muito definido de 'substituir o sistema atual'.

Técnicas e processos ágeis ainda podem levá-lo até lá com mais eficiência.

Por exemplo:

Você ainda pode executar o sistema de forma iterativa e em pequenos sprints.

Você ainda pode usar técnicas ágeis para priorizar o trabalho após se comunicar com as principais pessoas.

Você ainda pode usar o Agile para planejar com base na velocidade observada.

Você ainda pode usar técnicas e filosofias ágeis, como disseminar conhecimento, TDD, codificação limpa para aprimorar a qualidade e o design interno do projeto.

Se você tem pessoas que realmente não estão interessadas no projeto e não se envolvem com o projeto até que tenham um substituto perfeito, você tem um problema maior, independentemente de estar usando cascata, agilidade ou qualquer outro processo.

Funciona da mesma maneira, mas essa abordagem será mais difícil de vender para os usuários existentes. Eles podem não querer o novo sistema e não querem ser interrompidos por testes periódicos. Eles querem esperar o máximo possível e depois testá-lo no final. A maioria dos usuários se sente assim até um certo ponto, mas cabe aos responsáveis ​​educá-los. Na mente deles, você está trabalhando com um aplicativo existente; portanto, você deve saber o que ele deve fazer, por que incomodá-lo?

Faça com que eles entendam que você não quer fazer dessa maneira, porque você acha que será divertido e fica sozinho usando um processo em cascata. Ele criará um aplicativo melhor a longo prazo.

Um ponto importante de venda pode ser implementar essa alteração durante a criação do novo aplicativo que eles sempre desejaram, mas nunca conseguiram entrar no sistema antigo.

Se eu tenho um carro velho e enferrujado, preciso ir para o trabalho e vou à concessionária comprar um carro novo. O modelo que eu quero está esgotado, então eles precisam solicitá-lo na fábrica e levará um tempo antes de ele entrar.

O revendedor, então, de boa-fé, decide dar-lhe o bloco do motor do carro até que o carro que você pediu tenha entrado. Claro que posso conectar alguns componentes para testá-lo e fazê-lo funcionar, mas isso realmente não me ajuda a trabalhar amanhã, onde o velho carro enferrujado funciona.

É verdade que existe uma grande diferença entre a construção de um carro e a criação de software personalizado, mas vamos ignorar isso por uma questão de argumento. O ponto principal da história é não ficar perplexo com o fato de o cliente não encontrar utilidade para alterações incrementais quando ele já possui um software bom o suficiente para concluir o trabalho agora. Já preenche a necessidade deles por enquanto.

Isso não quer dizer que o Agile não seja uma parte importante do processo aqui, pois permite um feedback contínuo ao cliente sobre o status do projeto. Eles podem garantir que o progresso esteja sendo feito antes dos principais marcos e resultados. Eles podem identificar problemas e problemas em potencial antes que se torne um erro muito caro para corrigir.

Talvez como cliente do carro, você só queira olhar e avaliar o motor para garantir que realmente conseguirá o que esperava. Opa, eu realmente queria um motor de 6 cilindros em vez do motor de 4 cilindros! Eu não te disse isso antes? Não tem problema, vamos fazer uma alteração no pedido de fábrica.

Venda a ideia aos clientes de que é do seu interesse usar as novas versões de software ainda não como substituto, mas para avaliá-las e garantir que elas estejam felizes com cada etapa do processo.