Como priorizar as tarefas de um projeto ágil

100 trilhões de dólares do Zimbábue
100 trilhões de dólares do Zimbábue

Trabalho e ensino outros a trabalharem com Scrum desde 2010. Independente das empresas adotarem ou não a metodologia ágil mais utilizada (e com mais cases de sucesso conhecidos) no mundo, sempre há o que aprender com seus métodos inusitados e com a cultura que permeia este mundo ágil em geral. Um dos pontos-chave em qualquer projeto, seja com Scrum ou não, é a priorização de tarefas, tema do post de hoje.

Alguns especialistas que conheço dizem que basta perguntar ao cliente o que ele quer e depois, o que ele quer primeiro.

Pergunte ao seu usuário e/ou cliente tudo o que ele quer no software e você terá uma pilha de documentos com vários centímetros de altura e dezenas (talvez centenas) de páginas. Depois pergunte à ele o que é mais importante e ele vai lhe responder que tudo é importante. Pergunte o que é mais urgente e ele vai te responder que tudo é urgente. Esqueça, isso não funciona. Pelo menos dessa forma tão direta não.

Como fazer então?

Cortando o escopo

Simplesmente nunca teremos tempo hábil (e nem faz sentido) desenvolver tudo o que o cliente acha que precisa no software. Principalmente na primeira versão (já ouviu falar em MVP?) e é o seu dever ensinar isso a ele.

Gerentes de projeto tem de lidar com escopo, custo e prazo nos projetos. Dificilmente conseguimos equilibrar essas três variáveis e, na minha opinião, escopo é a que faz mais sentido cortar. Não apenas porque manter um equilíbrio nessa balança de três pratos é quase utópico mas porque é o mais inteligente a se fazer, pensando no sucesso do projeto como um todo.

Jason Fried fala no seu livro Getting Real que é melhor fazer meio-software do que um software meia boca. E eu concordo com ele.

É no escopo onde temos sempre a maior quantidade de desperdício em um projeto. E desperdício aumenta os custos e estoura os prazos, simples assim. A Toyota passou a GM com seu método Lean focando em apenas uma coisa: reduzir o desperdício.

Mas como reduzir o desperdício de escopo?

Princípio de Pareto

Use o Princípio de Pareto ou a “regra do 80/20”, como muito bem apontada por Tim Ferriss em seu best-seller Trabalhe 4h por semana. Pareto determina uma relação de 80/20 ou simplesmente maioria/minoria que é aplicada há muitas coisas em nosso cotidiano. Por exemplo, 80% do uso de um software se dá em apenas 20% das funcionalidades.

Isso quer dizer que apenas 20% de tudo que for desenvolvido será utilizado realmente. O restante cairá no esquecimento.

Scrum enfatiza o foco na geração de valor para o cliente a cada entrega e a chave para geração de valor é reduzir o desperdício priorizando muito bem o que deve ser DONE em cada Sprint. Ok, dentro do Scrum isso é uma tarefa para o Product Owner, mas se você leu até aqui é porque de alguma forma está envolvido com as decisões de produto também, certo?

Atualmente trabalho em um banco e como todo banco, temos alguns processos e projetos inchados, burocráticos e cheios de desperdícios. Alguns são culpa do Banco Central, outros são culpa nossa mesmo.Algumas vezes parece que Agile e Lean jamais andarão de mãos dadas com a palavra banco, mas essa é a minha função lá e tem sido um trabalho bem interessante.

Cito o case do banco pois lá eu tenho cuidado da priorização de tarefas para os times de desenvolvimento, além das minhas atribuições normais como Scrum Master. Um app de cartão de crédito, por exemplo, é cheio de features, por mais que pareça algo simples como comprar-e-pagar. É troca de senha, de data de vencimento, aviso de viagem, solicitação de mais limite, ajuste do limite atual, etc. Se deixar a equipe de negócio se empolga e quer um Nubank pronto em duas sprints. Quem nunca passou por isso?

Minha estratégia neste projeto foi bem simples: priorização. Não vamos entregar um Nubank em duas sprints, mas consegui priorizar as features baseado no que agregaria mais valor ao cliente o mais rápido possível. Assim, em três sprints teremos um app de cartão funcional com os 20% de features que trazem 80% dos benefícios. E sim, nós vamos entregar, pois falta apenas uma das três sprints e já estamos com boa parte das funcionalidades essenciais prontas.

Conhecendo seu produto

Mas como saber o que é mais prioritário dentre centenas de features que aparecem no backlog todos os meses?

O jeito mais óbvio é conhecendo o seu produto, o seu time e entendendo o seu mercado. Óbvio que isto não é algo simples de se alcançar e existem diversos outros fatores que impactam na priorização. Se você está lançando uma versão nova de um produto, olhar o que os usuários realmente usam na sua aplicação pode ajudar bastante a decidir o que deve entrar ou não em uma nova versão. Se está lançando um novo produto, tente entrevistar usuários de produtos concorrentes, vai lhe ajudar a entendê-los e fazer algo superior à concorrência.

Quais são as dores do seu usuário? Priorize o que “dói mais”. Se o que o usuário mais reclama é de não ter um bom limite de crédito nos cartões concorrentes, foque em fazer uma análise de crédito automatizada, eficiente e que forneça um crédito condizente com a realidade (e histórico) de cada cliente. Permitir que ele escolha a cor do seu cartão pode ficar pra depois.

O quê seu usuário mais utiliza no dia-a-dia? Entregue primeiro o que ele espera como “mínimo viável” em produtos do seu nicho. Se o usuário consulta o limite disponível no cartão todos os dias, mas apenas viaja para o exterior anualmente, o que você acha que deve ser feito primeiro: consulta de limite ou aviso de viagem? Se seu usuário troca de senha do cartão apenas uma vez por ano (no máximo), mas paga faturas todos os meses, qual funcionalidade deve ser o foco nas primeiras entregas?

Este tipo de raciocínio, sem muita técnica, ajuda bastante a priorizar o que é realmente importante e deve ser posto na frente em um projeto de software.

Buy a Feature Game
Buy a Feature Game

Buy a Feature Game

Obviamente existem diversas técnicas que podem ser utilizadas pra fugir do “achismo” e até mesmo lidar com conflitos de egos que muitas vezes irrompem em reuniões para priorização de backlog. Vou falar da minha favorita: a técnica Buy a Feature Game,  que é bem simples, lúdica e eficiente.

Primeiro, escreva as histórias ou features do seu projeto em cards e deixe-os todos espalhados em uma mesa. Não traga qualquer feature aqui, apenas aquelas que já estão no roadmap próximo e/ou são minimamente importantes ao projeto. Cada card postado na mesa deve ser lido, com a atenção de todos. O ideal é que cada card possua um “preço” também, que pode ser a estimativa de horas para desenvolvimento ou os story points, mas se não estiver tudo estimado, não invalida a dinâmica, apenas reduz um pouco a sua eficiência.

Para cada um dos envolvidos na priorização (de 4 a 7), geralmente stakeholders ou até mesmo usuários, entregue à eles um maço de notas falsas, tipo Banco Imobiliário. Se todas as tarefas estiverem estimadas e com “preço”, some os preços, divida o valor pelo número de participantes e distribua esta quantia em notas para cada participante (poucas notas grandes, muitas notas pequenas).

O dinheiro da dinâmica pode ser apenas post-its com os valores escritos ou dinheirinho de brinquedo, à venda em bazares. Apenas não permita a fabricação de dinheiro falso ao longo da dinâmica nem injeção ou lavagem de dinheiro aproveitado de outras dinâmicas. 🙂

Já se não estiver tudo estimado mas se você estiver trabalhando com story points ou horas e já souber quanto o seu time entrega por sprint, divida essa quantia entre os participantes em notas, seguindo aquela mesma lógica do Banco Imobiliário (poucas notas grandes, muitas notas pequenas). Você pode jogar o B-a-F Game uma vez para várias sprints, por exemplo, somando a capacidade das sprints na hora de distribuir as notas.

Se suas sprints são de 15 dias e você entrega 30 pontos em cada sprint, você pode priorizar uma vez a cada 30 dias, emitindo 60 pontos de notas para os participantes, por exemplo. Para que os valores não fiquem muito limitados, sugiro multiplicar story points por $10 ou até $100 mesmo, enquanto que horas geralmente não possuem esse problema.

Sem nenhuma regra, cada participante pode depositar o seu dinheiro sobre cada card, representando o seu interesse e/ou o quanto aquela feature vale a pena ser implementada. Aqui, cada um terá a sua própria percepção de prioridade, mas como o dinheiro é limitado, eles serão obrigados a trabalhar com esta limitação na hora de distribuir as notas.

Esta limitação de dinheiro ilustra bem as limitações reais de um projeto como a verba, as horas-homem, etc. Ajuda os stakeholders a “sofrerem” com as decisões difíceis que o gerenciamento de um projeto exige. Caso seus cards possuam outras limitações, como precedência, crie combos de produtos do tipo “para comprar esse, tem de comprar o outro primeiro”.

Quando todos terminam sem dinheiro (deixe que discutam e troquem as notas de lugar até o final da dinâmica), basta somar quanto cada card recebeu e os que receberam mais dinheiro são os mais prioritários. Opcionalmente, se estiver trabalhando com as estimativas, uma feature só vira de fato prioridade se ela recebeu um valor mínimo equivalente ao valor necessário para sua compra.

Se uma feature exige 100h de desenvolvimento, ela não entrará na próxima sprint se não alcançar $100 de ‘doações’ dos stakeholders, por exemplo.

Permita uma pequena discussão sobre o resultado da distribuição de notas logo após exibir os cards que se mostraram mais prioritário (i.e. que receberam mais $). Isso tende a gerar algumas movimentações de capital, o que é perfeitamente normal, mas ao término da sessão, o que ficou definido é o que será utilizado como prioridade do backlog e orientará os times nas próximas semanas.

Obviamente que nenhum método é perfeito, mas assim como o Planning Poker, este método baseia sua eficácia no consenso entre os envolvidos no projeto e o conhecimento que cada um tem do produto e do mercado para priorizar de uma maneira caótica, mas organizada.

E aí, o que achou desta técnica? Conhece alguma outra? Compartilhe nos comentários!

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

Microservices e Agile: o futuro da programação?

Este artigo é uma reprodução do artigo homônimo publicado na edição impressa da revista iMasters do mês de agosto de 2017.

Revista iMasters
Revista iMasters

Nenhum destes termos é exatamente novo, mas por algum motivo, jamais estiveram tão na moda como atualmente. Mas o que teriam, a arquitetura microservices e os métodos ágeis de desenvolvimento de software em comum? Ou melhor: por que seriam eles o futuro da programação? Não tenho a pretensão de ser eu a dizer como as empresas de tecnologia deveriam trabalhar, mas vou tentar trazer uma luz para esse assunto e provocar uma reflexão (espero) na forma como você trabalha.

Os métodos ágeis existem desde a virada do século, mas, mais recentemente, nos últimos cinco anos, uma nova onda de “agilistas” passou a defender um modelo que seria uma evolução dos métodos ágeis originais. Essa evolução foi proposta pelo Spotify em um famoso vídeo onde é apresentado o modelo de “squads” (esquadrões) do Spotify, que, em teoria, não possui grandes diferenças em relação ao Scrum Team original mas que propõe um mindset focado em um único produto à cada um dos times/squads ao invés do foco tradicional em projetos.

O termo viralizou entre as startups e hoje empresas como Nubank, Umbler e Conta Azul, por exemplo, organizam-se em squads também. Organizar um squad ao redor de cada produto faz com que as pessoas “abracem” o mesmo como se fosse “seu” e que queiram o melhor para ele em termos de tecnologia, experiência, resultados, etc. Permite que os times tenham mais controle (e mais resultados) com seus OKRs, KPIs, etc. Como bem o Scrum prega, cada time decide como seu produto deve ser melhor desenvolvido com base na estratégia da empresa e isso inclui TODOS os aspectos técnicos, como linguagem utilizada, banco de dados, etc.

Tudo isso é muito lindo e é exatamente o que as empresas querem: esquadrões focados no produto que entreguem software rapidamente (já ouviu falar de CI?) com as melhores tecnologias para resolver cada problema. Mas sabemos que na prática não é tão simples assim, certo? Mas deveria, e já, já, eu explico o porquê.

Estamos há décadas desenvolvendo software em grandes e complexos blocos de software que a própria TI chama de monolíticos, em alusão às grandes pedras (monólitos). Não importa se você organiza sua aplicação em ‘x’ camadas. Se você não pode fazer o deploy de apenas uma delas sem precisar compilar o projeto inteiro, o seu software é monolítico. Se você não pode escrever uma de suas camadas em uma linguagem diferente das demais, também. E isso não é ruim, aprendemos a construir softwares assim desde a faculdade e construímos grandes softwares ao longo das décadas que a profissão de programador existe. É apenas uma característica, sem julgamentos.

No entanto, cada vez mais o mercado nos pede softwares maiores e mais complexos, e nossos monólitos ficam ainda maiores e mais complexos. Mas ao invés de ficarem igualmente resistentes como a analogia, estão mais para um castelo de cartas altíssimo, infelizmente. Isso porque as demandas atuais estão exigindo pluralidade de tecnologias. E as aplicações monolíticas não trabalham muito bem com pluralidade, não foram concebidas desta forma. Fato.

Mas então, como  podemos alinhar diferentes tecnologias, diferentes produtos, mantendo uma alta velocidade de integração, qualidade e atendendo às expectativas, internas e externas, em relação aos projetos em que trabalhamos?

Com uma outra tendência que voltou muito forte após décadas: microservices.

Microservices não é algo exatamente novo, embora tenha-se voltado a falar dessa arquitetura há poucos anos. A ideia central é que você quebre sua aplicação em serviços bem pequenos, semelhante ao que SOA e CORBA propõem, mas sem as complicações que as grandes corporações criaram no em torno destas duas excelentes ideias (ESB?). Cada um desses microservices é auto suficiente na sua responsabilidade, é independente de linguagem, de persistência e comunica-se com os demais serviços através de protocolos comuns, como HTTP.

Não é à toa que tecnologias como Node.js, Elixir, Scala e Go (sem citar as funcionais em geral) estejam tão em alta ao mesmo tempo em que só se fala de arquitetura microservices e squads (não esqueçamos a persistência poliglota!). Ao que tudo indica, essa combinação de tecnologias leves e focadas em paralelismo, em micro serviços, mantidos por squads, para compor grandes soluções; são a “bola da vez” e podem ser a “salvação” para conseguirmos construir (e manter) os sistemas do futuro. Grandes empresas como Amazon, ThoughtWorks, Uber e Netflix acreditam nisso.

Por que eu não acreditaria? 🙂

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

Dicas para um Sprint Planning de sucesso

A Sprint Planning ou Reunião de Planejamento de Sprint é uma cerimônia simples dentro do processo ágil Scrum. Se você investir algum tempo prévio refinando o Product Backlog (tarefa principal do Product Owner) você conseguirá fazer uma Planning produtiva sem sombra de dúvida. Ajuda também evitar algumas más práticas que vou citar no artigo de hoje, que tem como objetivo enriquecer as informações sobre Sprint Planning existentes no Scrum Guide.

O propósito da Sprint Planning

Antes de começar a dizer o que fazer e o que não fazer quando o assunto é Sprint Planning, vale a pena relembrarmos qual o real propósito dela: alinhar o time de desenvolvimento e o Product Owner. Ambos precisam concordar no que será entregue como incremento de produto na próxima sprint e o time deve apresentar um plano de como irá trabalhar para que este incremento seja possível.

Se o Time Scrum possui um Product Backlog refinado e priorizado, o Time de Desenvolvimento será capaz de, juntos, ajustar o escopo da sprint à sua capacidade de produzir código, incluindo nessa previsão as ausências e impedimentos já previstos como férias de colegas, idas ao médico, etc. Geralmente essa conversa inicial para mensurar um escopo exequível e demais assuntos preparatórios dura entre cinco a dez minutos da etapa inicial da Planning, deixando todos alinhados e preparados para quebrar as tarefas macro em sub-tarefas que fiquem mais fáceis de mensurar na etapa seguinte (geralmente usando User Stories).

O Time de Desenvolvimento na Planning

Em primeiro lugar, é imprescindível que todo o time de desenvolvedores esteja disponível para participar da Sprint Planning. Ausências não eximem os ausentes da responsabilidade do que for acordado nesta reunião.

Além disso, é importante que todos os desenvolvedores sejam capazes de dizer o quão disponíveis estarão para a próxima sprint. Jamais considere que 100% dos membros do time estarão disponíveis 100% do tempo e não esqueça de novos membros que possam estar entrando no time e que demoram a se adaptar. Em geral, assumir uma capacidade de produção de 80% do total de horas trabalhadas é uma prática aceitável para cobrir possíveis ausências não previstas (doença, atrasos diversos, detalhes não previstos, bugs urgentes, etc).

Alguns times assumem uma postura confiante de que são 100% produtivos o tempo todo e isso leva-os a uma armadilha do ego que diminui a qualidade do trabalho, de vida e das relações entre os membros do time, que ficam cada vez mais reféns de metas impossíveis e inalcançáveis.

Em segundo lugar, para que a sprint seja minimamente bem sucedida, os desenvolvedores jamais devem superestimar sua capacidade de produzir. Para cada tarefa a ser estimada (seja com Planning Poker ou qualquer outra técnica), cada detalhe que possa afetar a capacidade do time de entregar aquela tarefa deve ser analisado. Ter uma Definição de Pronto bem definida aqui ajuda bastante, pois dá uma noção mais clara de todas etapas que cada tarefa deverá percorrer para ser entregue de fato.

Uma falha comum na definição do escopo e comprometimento com tarefas é ignorar o débito técnico. O time de desenvolvimento tem de estar ciente de que em torno de 25% do seu tempo estará fazendo correções, ajustes e refatorando código existente. Se o time ignorar o débito técnico, seja não deixando esta margem ou qualquer outra, mais cedo ou mais tarde terá problemas técnicos severos e sua produção cairá em sprints futuras.

Outra falha comum é na definição de tarefas. Quer você use User Stories ou não, jamais detalhe com uma granularidade muito fina o que terá de ser feito. Como a responsabilidade dos detalhes de implementação cabe aos desenvolvedores, não há porque discutir e especificar isso abertamente dentro da Sprint Planning. Nada impede, no entanto, que os desenvolvedores se reúnam após a Planning para uma reunião técnica de detalhamento. Planejar demais com antecedência gera desperdício.

E por fim, uma armadilha recorrente é subestimar a importância desse planejamento colaborativo e democrático. Alguns times nomeiam um líder para tomar as decisões por todos, desconsiderando a importância de suas opiniões individuais no processo de planejamento. Isso leva a uma série de problemas, desde estimativas não condizentes com a realidade até problemas de comprometimento de quem se sentir lesado posteriormente com as decisões tomadas nesta ocasião.

O Product Owner na Planning

O papel do Product Owner dentro da Sprint Planning é trazer um Product Backlog refinado, priorizado e um objetivo muito claro. Assim como para manter um exército motivado para uma batalha, todos precisam saber pelo quê estão “lutando”. Esse objetivo cabe ao Product Owner definir e ele deve ser alcançável e mensurável. O P.O. deve ser “firme” na sua decisão de objetivo e ser capaz de responder as dúvidas de negócio relacionados ao incremento combinado.

Com isso em mente, entende-se que o Product Owner deve fazer o “dever de casa” antes de começar a Sprint Planning, para poder definir o objetivo da sprint, a prioridade das tarefas e se cercar do conhecimento necessário sobre o produto a ser desenvolvido do ponto de vista do business. E dentro desse dever de casa, uma falha comum que P.O.s cometem é o de assumir que todo o trabalho não entregue da sprint passada caberá nesse sprint além das novas tarefas que ele priorizou.

Não é porque algumas tarefas haviam sido aceitas na sprint anterior que você pode considerá-las como automaticamente aceitas nesta sprint. Além disso, elas consomem tempo e por não terem sido entregues na última sprint devem ser alvo de uma investigação para entender os motivos do ocorrido.

Outro ponto de atenção são as famosas “mudanças de última hora”. O P.O. jamais deve tentar empurrar tarefas que apareceram de última hora na Sprint Planning e menos ainda após ela. Cabe ao Scrum Master não permitir esse comportamento que pode arruinar a sprint. Se isso acontece com frequência, é sinal de que o Product Owner não está fazendo o seu trabalho direito.

Lembre-se: o foco do P.O. não é delegar as tarefas ao time, mas priorizá-las de modo a garantir o ROI e a entrega de valor ao cliente. Focar em quantidade nunca é a melhor solução.

Anti-padrões

O anti-padrão mais comum em Times Scrum são as sprints irregulares e elas já nascem assim em Sprint Plannings mal conduzidas. Um dos motivos disso acontecer são tarefas mal dimensionadas que não cabem dentro da Sprint e acabam arrastando seu término. Nenhuma tarefa deve entrar na sprint com duração maior do que alguns dias, pior ainda quando insistem em colocar tarefas com o mesmo tamanho da sprint. É problema na certa! Sempre quebre tarefas grandes em pequenas tarefas.

Outro anti-padrão comum de acontecer em Sprint Plannings mal sucedidos é o “over-commitment” ou excesso de comprometimento. Seja porque o time acaba pegando tarefas demais para si, seja por que ele sempre coloca todo o trabalho não finalizado da sprint anterior na sprint atual. Se sobraram tarefas da sprint anterior, é porque as tarefas foram mal estimadas em relação à capacidade do time. Isso deve ser discutido na Retrospectiva e não ser algo recorrente.

Ignorar a Definição de Pronto nas estimativas também é um erro recorrente nos times. Conforme o time vai amadurecendo, é comum que a Definição de Pronto vá ficando mais complexa e que tome mais tempo para que cada tarefa satisfaça-a. Tempo este que não pode ser ignorado sob hipótese alguma.

Concluindo, a Sprint Planning é uma cerimônia simples, mas requer algum investimento de tempo prévio por parte do Product Owner e uma condução assertiva por parte do Scrum Master para que o time inteiro não caia em alguma das armadilhas supracitadas.

Conhece alguma outra dica para a sprint planning ou armadilha que deva ser evitada? Coloque nos comentários!

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.