O Poder da Iteração

Depois de um pouco mais de um ano com o meu cliente que trabalha com gerenciamento de risco, rastreamento de frotas por GPS, estou aos poucos conseguindo demonstrar o poder do desenvolvimento iterativo. Neste sistema estamos, gradualmente, aumentando o nosso amadurecimento nos processos ágeis. Sim, não adianta apenas uma pessoa ser experiente em determinado assunto. O que importa é o time. O todo não é a soma das partes, mas a soma da interação entre elas.

No início deste relacionamento, nosso cliente insistia que o importante era ter todo o sistema funcionando, que não adiantava ter partes desenvolvidas e homologadas antes de ter toda a aplicação funcionando.

Este sistema é um stand-alone em Java que recupera mensagens codificadas de satelites e os transforma em dados consumíveis pelos clientes da gerenciadora de risco. Por definição, poderiamos classificar esse tipo de sistema como ETL. O destino sempre é a base de dados da gerenciadora de risco e a origem pode ser o próprio rastreador GPS ou uma central. Desta mensagem, recuperamos informações do como latitude, longitude, altitude, data e hora da mensagem, estado das portas de entrada e portas de saida, etc. Além da leitura, a gerenciadora de riscos também deve ser capaz de enviar comandos para o aparelho para bloquear, desbloquear, desativar panico, solicitar posição, etc.

Além de ser um terreno extremamente fértil para a prática do TDD, nós podemos perceber um grande potencial iterativo.

Pelo que pude observar dos locais adeptos ao BDUF todos os problemas estão relacionados a um ciclo de aprendizado muito longo. Neste tipo de cenário, a maioria do aprendizado, quando você aprende, é praticamente jogada no lixo. O motivo é simples. O aprendizado é para o contexto do projeto em andamento. Nos sistemas complexos, projetos diferentes se comportam de forma diferente, isto é, os problemas são diferentes. Terá pouca eficiencia transportar o aprendizado de um projeto para outro.

Desenvolvimento ágil não é sobre TDD, BDD, pareamento, integração contínua, XPTO Master, etc. Desenvolvimento ágil é aprender rápido. É sobre aprendizado. Trabalhamos em ciclos curtos para aprender mais sobre o processo e sobre domínio. O cliente não sabe o que quer, uma frase clássica entre os times de desenvolvimento. Sim. Ele não sabe e não tem que saber. A idéia toma uma forma diferente quando passada para o computador. Então vamos aprendendo e ajustando com ciclos curtos. Feedbacks constantes.

Cada domínio é único. Cada contexto é único, inclusive dentro da empresa e até no mesmo time. A imprevisibilidade e a variabilidade vão estar presentes. Sempre. O escopo aberto - possibilitado pelas iterações e transparencia - não exigindo um contrato assinado com sangue, permite que os requisitos evoluam de acordo com as necessidades, colocando na prática o valor ágil que, na minha visão, lida muito bem com a complexidade: Responding to change over following a plan.

Quando todos estão comprometidos com este mindset, cabe aos artistas -  desenvolvedores, testers, operação, etc - transformar uma idéia em arte funcional. Para tornar essa transformação mais eficiente, entram as práticas visando os princípios e valores: TDD, BDD, Integração Contínua, com testes e código bem escritos. Em equipes maduras, com um bom script de rollback, também é possível o deploy contínuo.

Iterações atômicas (fluxo contínuo) ou timeboxed favorecem o aprendizado rápido e a adaptação gradual do sistema (principalmente com eliminação de desperdícios) visando lidar de forma mais eficiente com a complexidade.

Lembrando que de alicerce, sempre, para qualquer assunto relacionado aos princípios do Lean e/ou aos valores e princípios ágeis, é o respeito às pessoas. Respeito dentro do time, cliente, gerencia, diretoria. Estes dois últimos precisam servir o operacional e o cliente. Daí vem o conceito de liderança servidora. Quem gera valor diretamente para o cliente é o operacional. O resto, pode parecer duro, é custo administrativo. Alguns necessários, outros nem tanto. Este mindset é essencial para a coisa toda dar certo.

Vivemos em vários tipos de sistemas complexos, socialmente e profissionalmente. Quebrar o sistema em partes menores (silos) não vai resolver, pois o todo não é a soma das partes, mas das interações entre as partes. Então, podemos manter unidades funcionais e independentes (times), passar pelo processo várias vezes, aprendendo (iterações), responder às mudanças (escopo aberto) e respeitar as pessoas.