Agile para Product Managers
Todo Product Manager precisa entender como os processos de desenvolvimento funcionam, não por que eles precisam se envolver ativamente, mas por que eles são responsáveis pelo fluxo do O QUE será desenvolvido.
É muito difícil encontrar atualmente uma empresa de tecnologia que não use metodologias ágeis para desenvolver seus softwares. Em 90% das vezes, as empresas usam Scrum ou Kanban.
Algumas delas usam algo que chamamos de Scrumban. Outras não usam nada. Outras criaram ou adaptaram sua própria metodologia. Mas todas elas tentam se fundamentar nas mesmas premissas advindas das Metodologias Ágeis.
Metodologias Ágeis?
Primeiro, é importante que você entenda que o pensamento do que chamamos de Agilidade hoje, veio de princípios e padrões de boas práticas de desenvolvimento de software. É muito comum que ao pesquisar sobre Agilidade ou Movimento Ágil, você leia referências sobre o Manifesto Ágil. O Manifesto Ágil foi escrito por programadores mais do que reconhecidos no mercado. Todos eles impactaram de forma muito ampla o mercado de desenvolvimento de software em uma escala global, disseminando práticas, métodos e boas práticas técnicas de construção de software complexos. Você pode ver o nome de todos eles lá no site do Manifesto Ágil[1], mas segue a lista aqui:
- Kent Beck
- Mike Beedle
- Arie van Bennekum
- Alistair Cockburn
- Ward Cunningham
- Martin Fowler
- James Grenning
- Jim Highsmith
- Andrew Hunt
- Ron Jeffries
- Jon Kern
- Brian Marick
- Robert C. Martin
- Steve Mellor
- Ken Schwaber
- Jeff Sutherland
- Dave Thomas
Só para citar alguns: Martin Fowler fez o livro Refactoring, que aborda tudo sobre refactoring de código. Alistair Cockburn é autor da metodologia chamada Crystal Clear (que é uma das metodologias do Crystal, que é uma família de metodologias processuais para vários tamanhos de times). Sobre Jeff Sutherland você já deve ter ouvido falar, pois ele criou o Scrum junto com o Ken Schwaber (que na verdade, não foram eles que criaram do zero, já existia algo muito antes, mas eles adaptaram para desenvolvimento de software e nomearam com Scrum).
Todas essas 17 pessoas já estavam trabalhando com "agile" muito tempo antes de existir esse manifesto, pois todos eles, de alguma forma, entendiam que o ambiente de construção de software é complexo e por isso tentavam praticar processos para diminuir a complexidade do trabalho. O interessante é que práticas tinham muito em comum:
- Eram baseadas em ciclos curtos de desenvolvimento;
- Eram baseadas em ciclos de feedbacks recorrentes;
- Focadas em entregar pequenos pedaços de software funcionando;
- Focadas em uma estrutura e organização flexível à imprevistos e mudanças de prioridade;
O Robert Martin, percebeu meio que sem querer, que várias pessoas competentes estavam tendo ideias e criando metodologias que seguiam mais ou menos essas mesmas essências, e organizou uma reunião com o propósito de que essas pessoas conversassem e tentassem unificar suas ideias de boas práticas de organização de processos de construção de software em uma espécie de manifesto. O resto é história.
Procurando pela internet você vai encontrar uma série de vídeos[2] e artigos que descrevem como essa reunião lendária aconteceu. O meu predileto é um vídeo incrível que o maravilhoso Akita gravou[3], explicando seu próprio ponto de vista (que eu concordo mais do que 100%) sobre como o mercado deturpou o real sentido da Agilidade. As Transformações Digitais estão aí para provar a cegueira generalizada. O primeiro valor do manifesto é "Indivíduos e interações em vez de processos e ferramentas", e a primeira coisa que uma grande empresa faz nas transformações digitais é contratar uma consultoria ultracara para implementar Processos e Ferramentas. Não faz sentido.