Aplicando a metodologia Ágil em Provas de Conceito para tecnologias emergentes

Há uma abundância de tecnologias novas e empolgantes capazes de fazer desenvolvedores, engenheiros e cientistas de dados a arregaçar as mangas e aprender como aplicar e avaliar possíveis aplicações de negócios. Para aprender sobre isso, as equipes de tecnologia e dados geralmente realizam POCs (provas de conceito) para validar aspectos como casos de uso, desempenho, recursos de integração e outros requisitos.  

As equipes de TI e dados conduzem POCs em plataformas como novas bibliotecas JavaScript, ferramentas de devops, recursos de nuvem pública, plataformas de low-code, tecnologias de banco de dados, modelos de machine learning e integrações de dados. 

Aplicar metodologias agiles, como scrum, para executar uma prova de conceito tem muitos benefícios. A equipe define seus objetivos no início da sprint e depois usa o que aprendeu para priorizar novos experimentos e validações nos próximos sprints. 

Usar POCs para conduzir revisões rápidas de novas tecnologias é relativamente simples quando a equipe ou parceiros são os especialistas no assunto e podem determinar os critérios de sucesso. As equipes ágeis podem definir Spikes, um item especial na lista de backlogs (ou pendências, no português) que indica o trabalho orientado à pesquisa, como o momento para agendar o trabalho relacionado à POC no sprint.  

Os critérios de aceitação do Spike ajudam a definir o sucesso, e a equipe pode decidir quando a tecnologia está pronta para passar pelas aprovações de mudança. Mesmo depois de aprovadas, essas equipes podem usar feature flags (também conhecida como feature toggles) para introduzir a nova tecnologia em produção de forma gradual. 

Aplicação de metodologias ágeis em POCs complexos 

O planejamento e a execução de POCs de escopo mais amplo apresentam desafios adicionais, especialmente ao validar tecnologias emergentes como machine learning, inteligência artificial, Internet das coisas ou blockchain.  

Essas POCs são experimentos nos recursos subjacentes, plataformas selecionadas, aplicativos da tecnologia e requisitos de negócios aplicados. As equipes devem iterar por meio de um processo de descoberta ao longo de todas essas dimensões e suas dependências para validar o valor do negócio, a solução correta e a abordagem tecnológica. 

Ao comparar uma POC ágil em tecnologias emergentes com outras iniciativas ágeis, existem várias diferenças gritantes:

• A maioria das iniciativas ágeis é liderada por um product owner que trabalha com clientes e stakeholders na visão, prioridades e requisitos. Mas em uma POC de tecnologia emergente, esse profissional deve atrair os interessados em potencial para um processo de descoberta sem prometer excessivamente os resultados.  
• O processo Ágil deve ajudar a determinar se a aplicação da tecnologia ao problema resulta em uma solução viável que cria valor comercial suficiente. Ao mesmo tempo, as partes interessadas devem concordar em participar da jornada do experimento por meio do sucesso, reduções de velocidade e falhas. 
• Ao trabalhar com uma tecnologia emergente, as partes interessadas não podem fornecer facilmente requisitos ou critérios de aceitação, e as equipes ágeis não podem estimar o trabalho com precisão. Lidar com uma tecnologia emergente é um processo de descoberta.  
• As equipes ágeis validam os recursos da tecnologia e demonstram os resultados nas revisões de sprint para informar as partes interessadas. Então, os envolvidos podem avaliar se e como proceder e determinar quais experimentos priorizar. 
• As equipes de tecnologia e dados geralmente conduzem POCs em uma ou mais tecnologias comparáveis para validá-las em relação a um conjunto de critérios de sucesso. Isso é mais difícil de orquestrar em POCs de tecnologia emergentes porque as equipes estão iterando nos critérios de sucesso, requisitos e recursos técnicos simultaneamente. Além disso, as tecnologias e arquiteturas emergentes podem gerar soluções que são difíceis de validar em relação aos requisitos de suporte e às necessidades de negócios futuras. 

Capacite equipes de auto-organização em POCs de tecnologia emergentes 

As POCs têm seus desafios, mas as equipes ágeis de sucesso sabem como usar princípios de auto-organização, ajustar suas ferramentas de gerenciamento ágil e criar uma cultura que estimula a inovação experimental. 

Primeiro, revise os ciclos de sprint e release para POCs de longa duração que requerem equipes dedicadas. Muitas equipes ágeis que trabalham no desenvolvimento de aplicativos, DevOps ou ciência de dados são formadas ao redor de sprints de duas semanas. É tempo suficiente para fazer as histórias do usuário, participar de cerimônias ágeis e planejar os próximos sprints. 

Nas POCs de longa duração, as equipes ágeis podem querer planejar uma cadência mais agressiva de sprints semanais ou até mais curtos. Sprints mais curtos funcionam bem quando as equipes se comprometem com experimentos rápidos e as partes interessadas revisam e fornecem feedback frequente.

Essas POCs geralmente têm menos complexidades de execução e os loops de feedback rápido permitem correções de curso e tomadas de decisão mais rápidas. 

Quando se trata de experimentos, as equipes podem se beneficiar definindo os requisitos de maneira diferente do formato e dos critérios de sucesso aplicados em histórias de usuário típicas.

Na escrita Ágil de histórias do usuário, os critérios de aceitação de uma história limitam as soluções às restrições funcionais e os critérios não funcionais ajudam a equipe a validar suas implementações. 

Escrever histórias de usuário curtas, mas detalhadas, com critérios de aceitação, ajuda a criar um entendimento compartilhado entre o proprietário do produto e a equipe ágil sobre o usuário, declaração do problema e soluções aceitáveis. 

Definir critérios de aceitação de aprovação/reprovação em POCs complexas pode ser difícil. Nesses experimentos, uma alternativa é definir critérios de falha que ajudam a indicar quando o experimento errado foi selecionado ou quando os resultados de um experimento estão fora dos resultados desejados.

Quando um experimento é considerado malsucedido, as equipes podem tomar melhores decisões sobre quando encerrá-lo e priorizar diferentes abordagens. 

Para POCs altamente estratégicas, as organizações técnicas e de dados podem optar por ter várias equipes competindo em seleções e implementações de tecnologia.

Uma opção é definir hackathons curtos onde várias equipes aplicam diferentes tecnologias, abordagens e soluções. Esses eventos devem incluir os desenvolvedores, engenheiros e cientistas de dados mais jovens; é uma excelente oportunidade para eles aprenderem novas tecnologias e colaborações ágeis. 

Transição de POC para protótipo e MVP 

Um benefício de aproveitar o ágil na POC é que ele permite uma transição suave para novas fases, como o desenvolvimento de protótipos e MVPs (produtos mínimos viáveis, em português).

Durante a POC, equipes ágeis colaboram e ganham experiência na aplicação da nova tecnologia; as partes interessadas aumentam sua compreensão das capacidades da tecnologia.  

Mais importante, os stakeholders testemunham a velocidade da equipe ágil e ganham uma expectativa realista do que a equipe pode concluir durante um sprint.

A colaboração e empatia desenvolvidas durante a POC podem produzir resultados promissores durante as fases subsequentes, incluindo o desenvolvimento de protótipos e MVPs. 

É importante lembrar que a inovação não termina com POCs de sucesso. Elas são apenas um passo na jornada. Em última análise, um recurso para organizações que desejam trazer inovações tecnológicas emergentes para a produção e perceber os impactos nos negócios.  

Iniciar POCs usando metodologias ágeis estabelece uma colaboração entre negócios, tecnologia, dados e outras funções que devem evoluir suas estratégias, prioridades, declarações de problemas e soluções durante o processo.