O que você pensava sobre desenvolvimento de software em 2012? O que eu pensava era algo assim… e um aviso sobre 2012. Era comum a galera ficar pensando sobre o que queremos e quando queremos, baseado em algumas tirinhas / memes que brincavam com situações do dia a dia.

Eu pensava algumas coisas assim, e sigo pensando na verdade:

• Devemos entregar software de forma contínua.
• Devemos trabalhar próximos de clientes, e buscar mais e mais comunicação para entender e perceber o que é valor para quem atendemos.
• Devemos melhorar continuamente, o processo de fazer software e as técnicas usadas para fazer software.
• Devemos buscar a arte de maximizar o trabalho que não é feito, por vezes entendendo o que é relevante. A simplicidade.

Em 2012 eu ouvi alguém criticando quem estava entregando software dentro da iteração de trabalho, ou em diversos momentos da iteração de trabalho, pois em algum livro estava dito que não poderia ser assim. Só deveria entregar depois? Ou dali algum tempo?

Você vai se julgar porque consegue entregar mais valor, e antes do final do seu ciclo de trabalho? Vai parar de fazer porque? Se está sendo bom para clientes e para a equipe?

Se a crítica vem por causa do método YZ usado pela sua equipe, é hora de parar de pensar no “by the book“, e começar a pensar em desenvolvimento de software e olhar que princípios sua equipe acredita e aplica no dia a dia.

Na minha visão? Scrum, eXtreme Programming, e nenhuma metodologia deveria estar preocupada em quantas vezes você entrega software em produção durante a semana. A pergunta tem que ir mais longe. Está gerando valor? Está acontecendo sem impacto negativo para quem faz uso?

Até podemos entrar em discussão sobre quando fazer entregas, mas o resumo deveria ser “sempre que possível“. E saber como operar neste processo sem afetar quem faz uso do seu produto. Ou seja, devemos saber evoluir e também retroceder versões da forma mais suave possível. É sempre um processo, e sempre vai existir espaço para evolução.

Aproveitando que falamos de Scrum, no Scrum Guide se ouvia falar em “potencialmente entregável” ainda na versão de 2017. Na versão de 2020, o jogo muda, onde se pede que as equipes estabeleçam objetivos para o produto e para sprints. E que a equipe busque atender os objetivos, que façam o que precisa para caminhar em direção aos objetivos.

No fim, não queremos potencialmente entregável. Queremos entregar. Queremos software em produção. Queremos gerar valor. E só saberemos se estamos gerando valor se entregarmos.

Certo? Tomara que sim, porque eu busco fazer software assim faz algum tempo. 😛

— Daniel Wildt

Você pode apoiar a minha jornada de conteúdo através do projeto A Filosofia da Tranquilidade! Venha conhecer mais a minha iniciativa!