Métodos Post-SCRUM

Faz alguns anos que a “Agilidade” começou a se espalhar pelo Brasil trazendo novos métodos pouco ortodoxos de desenvolvimento de software que diferem do tradicional “Waterfall” ou cascata como nós conhecemos. E não é que o cascata seja ruim, simplesmente a tecnologia tem dado passos tão gigantes e absurdamente velozes, que um ritmo de entregas à longo prazo não é mais uma opção, só se você quiser mesmo perder o “Time to Market” de seus produtos e/ou serviços.

Num mundo onde o usuário começou a fazer parte essencial do desenvolvimento de software tornando-se mais exigente a cada dia, era necessário implementar outros modelos mais dinâmicos que permitissem abraçar os avanços tecnológicos com um tempo de resposta adequado e aqui entra o famoso movimento ágil, sendo um dos principais frameworks o afamado “SCRUM”.

Trabalhei por vários anos ensinando, treinando, implementando e executando este framework em várias empresas e que sem dúvida nenhuma se mostrou muito mais eficiente que o tradicional cascata; e muitos me perguntam o porquê? O que faz este método de trabalho ser mais ágil? Para mim é bem simples, a “EXPOSIÇÃO”, e esta meus prezados leitores é a minha humilde opinião.

Não foi fornecido texto alternativo para esta imagem

A exposição se gera a través do evento mais significante deste modelo, a “Daily SCRUM”. Esse evento ou cerimonia, como também é chamado, é tão poderoso que deixa todos os integrantes de um time “expostos” em quanto a suas atribuições e tarefas. Imagine chegar a uma “Daily SCRUM” e falar que você não está trabalhando em NADA. Imediatamente o olhar crítico e desafiador do time para com você deixa uma sensação de desapontamento, de deslealdade que ninguém mesmo teria como suportar.

Essa sensação faz com que todo mundo faça o mínimo esperado, ou seja, seu trabalho. Por esse fato, muitos dizem, e sei que você também já diz, que o melhor do “SCRUM” é a disciplina que gera nos times. Mas é obvio, agora todo mundo sabe o que você faz e não faz a cada dia.

Não foi fornecido texto alternativo para esta imagem

Porém, o “SCRUM” assim como o “Cascata” tem algo em comum, são limitados a timebox, não dá espaço para mudanças ágeis e necessárias a qualquer momento, além disso, não nos oferece dados exatos e precisos do andamento do projeto, nem previsibilidade de entrega e bem menos nos mostra que tão eficientes estamos sendo em função de nossas entregas. Um modelo que utiliza o “ACHISMO” como recurso de medição (estimativa em “Story Points”) só fara de você alguém com capacidade de ação reativa e não proativa. À final, os “Story Points” não irão dizer para você quando irá entregar, só dirá a complexidade da estória. Será preciso acompanhar por um mínimo de 3 meses a “Velocity” e “Capacity” do time para começar a dar estimativas mais assertivas, mas sempre fundamentadas no “achismo” como toda estimativa.

Quer um exemplo simples? Imagine que você estima toda uma funcionalidade, previamente quebrada em estórias, fazendo uso dos Story Points e conforme a experiência de seu time fundamentada no “achismo”, estima-se que entregara a sua funcionalidade em 45 dias. Agora bem, você começara acompanhar, com o seu “Burndown Chart”, o status da sua entrega e chegando perto dos 30 dias você se depara com a famosa “boca do jacaré” abrindo a cada dia consideravelmente. Aqui você começa a buscar alternativas para evitar o inevitável atraso da sua entrega.

Mas o que é esse “achismo” que você fala? Simples, é uma estimativa baseada na experiência de quem irá desenvolver com um acréscimo de 20-30% de gordura para se garantir.

Agora, imagine que você consegue ter através de dados estatísticos, baseados em seu histórico de entregas, uma previsibilidade de entrega em 45 dias com 85% de confiabilidade. Sabendo disto, desde o primeiro dia você passa a ser proativo buscando alternativas para conseguir atingir o resultado esperado da sua entrega o que causa com certeza um ganho enorme de tempo e esforço. Terá uma diminuição do “Cycle Time” de no mínimo 10%, simplesmente porque não estará dando a chance de o “achismo” surgir.

Se ainda pensa que o “SCRUM” seria a melhor abordagem, o convido a conhecer o “Método Kanban”, um sistema de fluxo contínuo que tem se mostrado entre 10% e 30% mais eficiente e eficaz, e que irei falar no meu próximo artigo. E que fique claro, não estou dizendo que o “SCRUM” seja ruim assim como o próprio “Cascata” também não é, só estou dizendo que temos que continuamente evoluir em nossos conhecimentos e práticas se queremos entregar resultados mais satisfatórios para os nossos clientes.

“Quem se limita não muda, quem não muda não se transforma e quem não se transforma não evolui” Erasto Meneses

Um grande abraço e até uma próxima oportunidade 😊

Popular Posts

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *