A agilidade, ou a capacidade de responder às mudanças em seu mercado, costuma ser considerada um dos preditores mais significativos do sucesso de uma empresa. Na verdade, os projetos ágeis desfrutam de uma chance 60% maior de sucesso em comparação aos projetos mais tradicionais do tipo “cascata”..
Mas o que é Ágil? O conceito de uma abordagem Agile é algo que é muito discutido. Mas pode haver muita confusão sobre o que isso realmente implica. Tem algo a ver com paredes cheias de post-its coloridos? É um software sofisticado de gerenciamento de projetos? Ou algo que você só aprende com consultores especializados?
Nesta publicação, abordaremos os principais e mais importantes conceitos e processos do desenvolvimento de produtos Agile e como você pode aplicá-los à sua própria organização.
Primeiro, antes de olharmos para Agile, vamos dar uma olhada em cascata:
‘Cascata" (Waterfall) é o nome do estilo mais tradicional de desenvolvimento de produtos, tanto para software quanto para produtos físicos.
Segue um processo linear. Para começar, normalmente há um longo processo de planejamento (Planning), onde absolutamente tudo para todo o projeto é planejado. Esta fase de planejamento pode levar vários meses.
Após a conclusão do planejamento, o projeto passará para a próxima etapa, 'Design', onde todo o design do produto é finalizado. O projeto continua passando pelas etapas, sempre completando a última etapa completamente antes de passar para a próxima.
Finalmente, o produto acabado completo é lançado no mercado, meses, senão anos, após o estágio inicial de planejamento. Como resultado, o produto errado pode ser lançado no mercado. O que originalmente poderia ter sido um produto bem planejado com um ótimo ajuste ao mercado, agora pode estar desatualizado quando for lançado. A tecnologia pode ter mudado ou a demanda do mercado pode ter mudado.
Então, olhamos para a Cascata (Waterfall), mas o que isso tem a ver com o Agile?
Bem, com o Agile, dividimos o processo em Cascata em partes menores.
Primeiro, fazemos apenas o planejamento necessário para começar. Em vez de planejar o produto inteiro, planejaremos apenas um componente muito pequeno dele, talvez apenas um ou dois recursos.
Em seguida, pretendemos construir e projetar apenas o suficiente para podermos enviar esse pequeno conjunto de recursos - também conhecido como 'versão incremental'.
No Agile, todo esse processo, desde o planejamento até a liberação incremental, geralmente leva cerca de 2 semanas e é frequentemente chamado de 'sprint'.
Depois de fazer um lançamento, começamos o ciclo novamente. A cada vez, estamos planejando apenas o suficiente para criar a próxima versão incremental de software funcional.
Ao enviar pequenos lançamentos regulares, o processo do produto é flexível. À medida que enviamos pequenos conjuntos de recursos ou versões incrementais, podemos começar a testar rapidamente e coletar feedback do usuário sobre cada recurso enviado. Esse teste contínuo significa que podemos responder rapidamente a requisitos novos e em constante mudança. Como resultado, podemos ajustar continuamente o roteiro de curto prazo para atender às necessidades do cliente, o que significa que temos muito mais chances de entregar um produto final que nossos usuários adoram.
O desenvolvimento ágil de produtos é baseado nos 12 princípios ágeis. No entanto, a fim de manter este artigo amigável para iniciantes, vamos nos concentrar apenas em 4 princípios-chave abaixo que acho útil ter em mente se você for novo no Agile.
1-Refletir e ajustar: Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, então sintoniza e ajusta seu comportamento de acordo.
2-Satisfazer o cliente: Nossa maior prioridade é satisfazer o cliente por meio da entrega antecipada e contínua de software valioso.
3-Entregue com frequência: Entregue o software funcionando com frequência, de algumas semanas a alguns meses, com preferência pela escala de tempo mais curta.
4-Equipes auto-organizadas: As melhores arquiteturas, requisitos e designs surgem de equipes auto-organizadas.
Como você pode ver pelos princípios, Agile não é uma lista de processos a serem seguidos ao criar um produto, mas sim um conjunto de valores e crenças orientadoras que podem ser usados para ajudar a tomar decisões ao desenvolver produtos.
Se você está aprendendo sobre o 'mundo ágil', há uma boa chance de também ter ouvido outros termos, como 'Scrum' e 'Kanban'. Scrum e Kanban são metodologias ágeis populares. Eles são estruturas de desenvolvimento de produtos projetadas para ajudar as equipes a alcançar os princípios ágeis.
No entanto, embora essas metodologias possam ajudar uma equipe a ser ágil, elas não são necessariamente ágeis em si mesmas. Seguir essas metodologias só resulta em uma prática ágil se ajudar a equipe a alcançar os princípios ágeis. Você não precisa necessariamente seguir uma metodologia ou processos estritamente se achar que não está ajudando sua equipe a alcançar os princípios ágeis. A equipe está refletindo e se ajustando? Você está entregando recursos com frequência? Alcançar os princípios ágeis é o que determina se uma equipe é realmente ágil.
Talvez você esteja seguindo o Scrum, que sugere ter uma reunião diária para se conectar com sua equipe. Mas depois de segui-lo por algum tempo, simplesmente não está funcionando. Você descobre que sua equipe é mais produtiva e satisfeita tendo reuniões sentadas em torno de uma mesa. Tudo bem também! Você pode fazer essa mudança. Parte do Agile está respondendo à mudança, revisando seus processos e adaptando, e isso também pode significar adaptar como você estrutura o desenvolvimento de seu produto.
Por fim, você deve usar o que achar que ajuda sua equipe a tomar melhores decisões ágeis. Não existe um método ou sistema verdadeiro que seja a única maneira de ser Ágil.
Para equipes novas no Agile, pode ser mais fácil seguir uma metodologia estabelecida para começar com alguma estrutura em vigor, então, quando sua equipe se sentir confortável, você pode tentar mudar a fórmula.
Uma equipe ágil é composta por:
Equipe de desenvolvimento
Essa equipe geralmente inclui habilidades como design, desenvolvimento, teste e entrega. Os membros da equipe geralmente desempenham várias funções, alguns dias eles podem estar testando e outros dias desenvolvendo.
Product owner (Proprietário do produto)
Um Product owner (proprietário do produto) é responsável por maximizar o valor do produto criado pela equipe de desenvolvimento. Essa função interna reúne requisitos técnicos, prepara o backlog do produto e detalha as histórias do usuário.
Partes interessadas / acionistas (Stakeholders)
As partes interessadas podem ser qualquer pessoa afetada pelo desenvolvimento de um projeto de software. Isso inclui uma ampla categoria de pessoas, como usuários finais, executivos e TI.
Antes de prosseguirmos, vamos examinar a comunicação com os usuários e entender suas necessidades.
No início do desenvolvimento de um produto, e de forma consistente durante todo o processo, você deve se comunicar e testar com os usuários. Geralmente, esse é um trabalho principalmente para o profissional de UX da equipe, se você tiver um, mas realmente todos os membros da equipe devem ser incentivados a conversar regularmente com usuários reais.
A comunicação com o usuário pode ser feita de várias maneiras:
O objetivo da comunicação com o usuário é identificar as necessidades do usuário. Um exemplo de necessidade do usuário pode ser “comparar convenientemente as tarifas de telefonia móvel”. As necessidades do usuário sempre devem ser baseadas em conversas reais com as pessoas, não nas necessidades que a equipe acha que o usuário deseja.
No início de um novo projeto de desenvolvimento de produto Agile, você precisa definir a estratégia do produto. Isso resume a necessidade de negócios que seu projeto está abordando. Em termos mais simples: qual é o objetivo final deste projeto Agile e como você o alcançará?
Os proprietários do produto são responsáveis por criar uma estratégia de produto em colaboração com suas partes interessadas para garantir a adesão e o alinhamento. It is optional, but recommended to include key members of the development team too.
Definir uma estratégia clara é crucial em um ambiente Ágil. Às vezes, as equipes de desenvolvimento podem se sentir presas aos detalhes de um projeto e perder de vista o objetivo geral por trás de todo o seu trabalho. A estratégia do produto é uma meta de alto nível à qual a equipe pode se referir para ter certeza de que está vendo o quadro geral.
Para se preparar para uma reunião de estratégia de produto, você já deve ter trabalhado de perto com os usuários para entender seus pontos problemáticos, pesquisado o mercado e estar ciente de seus objetivos comerciais gerais. Existem muitos modelos e ferramentas de tela que você pode usar para ajudá-lo a criar sua estratégia de produto. Um que eu acho muito amigável para iniciantes é o método de Elevator Pitch.
Depois que a estratégia é decidida, o proprietário do produto com as partes interessadas realizará uma reunião para começar a planejar o roteiro do produto.
O roteiro do produto é uma visão de alto nível dos requisitos, prioridades e um cronograma flexível de como tudo será concluído.
Jeff Gothelf, autor de Lean UX, explica bem o dilema do roteiro ágil,
“Um dos maiores desafios na gestão de produtos é planejar o trabalho de forma linear e visual... O desenvolvimento de produtos digitais não é linear. É iterativo. Construímos algumas coisas. Nós os entregamos. Vemos como eles afetam o comportamento do cliente. Nós os iteramos e entregamos novamente.”
Os projetos ágeis são flexíveis por natureza, portanto, planejar o roteiro para os próximos dois anos pode ser um desafio e deve ser abordado de maneira diferente do planejamento normal do roteiro.
Assim como ao definir sua estratégia de produto, você deve primeiro conversar com os usuários e identificar suas necessidades antes da reunião do roteiro. As necessidades do usuário são o combustível para o planejamento!
1. Comece a pensar em temas:
Você deve ter descoberto alguns problemas ou áreas de melhoria ao conversar com os usuários e, com eles e suas necessidades de negócios em mente, você pode começar a criar seus temas.
Temas são itens do seu roteiro. Eles devem falar em resultados, não em características. Os resultados são mudanças específicas mensuráveis na vida de sua organização ou de seus usuários que você deseja alcançar com seu produto. Os recursos são apenas as maneiras pelas quais alcançamos esse resultado.
Por exemplo, um resultado que podemos querer alcançar é ‘Menos visitantes do site abandonam o carrinho de compras’. E um recurso que poderíamos criar para nos ajudar a alcançar isso poderia oferecer automaticamente códigos promocionais quando algo é adicionado a um carrinho de compras.
No entanto, no nível do roteiro, não queremos listar nossas ideias de recursos, elas virão mais tarde. Ao usar temas baseados em resultados, mantemos nosso roteiro em alto nível, o que significa que podemos ser flexíveis e alternar recursos dentro e fora do tema sem afetar significativamente o roteiro.
2. Medir o sucesso do produto:
Como diz o ditado: “Você não pode melhorar o que não mede”.
Para cada tema, você deve decidir em equipe qual métrica ou KPI usará para medir o sucesso. Isso nos ajudará a avaliar a qualidade de um produto e acompanhar o desempenho da equipe.
Métricas comuns de sucesso de produtos são medidas pela forma como os usuários interagem com produtos e serviços, como envolvimento do cliente, taxas de conversão e rotatividade de clientes. No entanto, tome cuidado. Você não quer medir uma faceta em detrimento de outras informações. E você não quer medir muitas coisas e dispersar o foco de sua equipe.
3. Crie épicos:
Dentro de cada tema, o roteiro incluirá um ou mais épicos (corpos de trabalho para servir ao tema). Cada épico consistirá nos recursos e histórias relevantes necessários para completá-lo.
Muitas vezes há discussões nos círculos ágeis sobre a diferença entre épicos e temas. Um tema é tipicamente um agrupamento de épicos semelhantes. Mas seja qual for a sua definição, é importante manter os temas em alto nível.
4. Priorize:
Depois de identificar vários temas que sua equipe considera importantes, você precisa priorizá-los. Afinal, você tem recursos limitados e não pode resolver tudo de uma vez. Assim, considerando seus KPIs, estratégia de produto e recursos disponíveis, você pode começar a classificar seus temas.
5. Iterar:
Assim como os produtos produzidos pelas equipes Agile, os roteiros Agile são iterativos. Os processos ágeis de planejamento e roteiro são atividades contínuas que devem ser ajustadas regularmente para acomodar mudanças.
Por exemplo, oportunidades inesperadas no mercado podem aparecer no horizonte que sua empresa seria tola em deixar passar. Para que as empresas sobrevivam em um mercado volátil, não apenas os roteiros podem mudar, mas também devem mudar.
O roteiro do produto não é apenas para as partes interessadas do negócio, mas também para toda a sua equipe de produto. O roteiro dá à sua equipe uma visão geral do seu produto e como o trabalho que eles estão fazendo hoje se encaixa nesse quadro. Como resultado, eles podem tomar decisões mais bem informadas em seu trabalho.
Também serve como uma boa maneira de manter os executivos e as partes interessadas na mesma página e focados no quadro geral. É esse uso do roteiro do produto para comunicar melhor sua estratégia de longo prazo para sua equipe e partes interessadas que destaca um dos benefícios mais úteis de um roteiro de produto, uma ferramenta de comunicação. E para planos táticos mais detalhados? Em seguida, usamos o backlog do produto.
Um bom roadmap de produto Agile fornece contexto para o backlog do produto. É aqui que começamos a entrar em detalhes.
É a única fonte autorizada para as coisas em que uma equipe trabalha. Um backlog de produto é uma lista de novos recursos, alterações em recursos existentes, correções de bugs, alterações de infraestrutura ou outras atividades que uma equipe pode entregar para alcançar um resultado específico. Você pode pensar em uma lista de pendências como uma lista de "coisas a fazer" para a equipe de desenvolvimento.
À medida que solicitações, comentários de usuários e novas ideias chegam, você acaba tendo uma tonelada de recursos e projetos em potencial para assumir. Eles ficam no backlog do produto até que você esteja pronto para adicioná-los a um sprint.
Nada é feito que não esteja no backlog do produto, mas, inversamente, a presença de um item no backlog do produto não garante que ele será entregue. Os itens do backlog são simplesmente opções que a equipe tem para entregar um resultado específico, em vez de um compromisso
Seu backlog é flexível. O gerente de lista de pendências, geralmente o proprietário do produto, deve ser capaz de adicionar ou remover rapidamente itens de sua lista de pendências. Seu backlog deve estar constantemente se adaptando à forma como você acha que sua equipe pode alcançar melhor o resultado desejado.
Os itens do backlog do produto assumem uma variedade de formatos, sendo as histórias do usuário as mais comuns.
User stories são histórias simples que descrevem algo que daria valor ao usuário. Eles nos ajudam a organizar nosso trabalho em pedaços pequenos. Um formato comum usado para é o formato ‘Quem, o quê + por quê’ abaixo:
Como <papel>
Eu quero <objetivo>
Para que <benefício>
Por exemplo, "Como trabalhador autônomo, quero controlar com facilidade e sem estresse as finanças relacionadas ao trabalho, para que eu possa ter certeza de que paguei meus impostos corretamente"
As user stories podem nos ajudar a seguir um dos princípios fundamentais do Agile: “nossa maior prioridade é satisfazer o cliente por meio da entrega antecipada e contínua de recursos de software valiosos”
No final de nosso sprint de 2 semanas, pretendemos entregar nosso lançamento incremental de recursos de software valiosos. Para completar user stories e entregar software valioso, nos concentramos apenas em construir o que é necessário para entregar o valor.
Por exemplo, em cascata, podemos querer construir todo o banco de dados para todo o produto antes de passar para outras partes da estrutura. No Agile, construiremos apenas o suficiente do banco de dados para entregar o recurso.
Pode parecer pouco intuitivo no início, e você pode ter que voltar e refazer as coisas que fez no passado, à medida que as futuras user stories se tornarem mais claras. Mas é importante lembrar que a metodologia Agile é uma forma mais eficiente de construir produtos. Em vez de esperar anos para lançar um projeto, em semanas você pode enviar recursos funcionais que agregam valor ao usuário e ao negócio. A partir dos recursos que você envia, você pode obter feedback para futuras iterações e se adaptar rapidamente às mudanças do mercado.
Depois que o backlog do produto coletar user stories suficientes para começar a entregar algo, você estará pronto para a reunião de planejamento do sprint.
Um sprint normalmente dura 2 semanas e é repetido várias vezes. Em cada sprint, você está apenas planejando e construindo o suficiente para lançar a próxima versão incremental. O ciclo de sprint é repetido até que o produto esteja completo.
Antes de um novo sprint, sua equipe terá uma reunião de planejamento do sprint para criar o backlog do sprint. Embora você não queira gastar muito tempo nesse estágio, pode levar de 2 a 4 horas.
O backlog do sprint é como um subconjunto do backlog do produto. A equipe discute quais histórias do backlog do produto eles querem trazer para o próximo sprint.
O planejamento do Sprint no Agile é feito pela equipe do produto, mas deve incluir informações e orientações do proprietário do produto. No entanto, cabe à equipe decidir o que deve (e pode) ser feito em um sprint.
Durante o planejamento do sprint, você naturalmente descobrirá que algumas das user stories no backlog são de menor prioridade para o usuário. Ao decidir em quais user stories trabalhar neste sprint, idealmente queremos criar user stories de alta prioridade primeiro.
Mas quantos devemos puxar em um sprint? Temos um tempo fixo e, obviamente, não podemos construir e liberar todos eles.
Um método popular para priorizar as user stories no planejamento do sprint é usar pontos de user story. É aqui que a equipe discute os votos das histórias para alocar stories com pontos, para estimar quanto esforço uma história exigirá. Dessa forma, você pode ter uma ideia de quais são as histórias maiores e quais são as vitórias fáceis. Em seguida, a equipe decide quais stories podem ser concluídas dentro do prazo do sprint.
À medida que seu projeto continua, uma velocidade prevista ficará clara - aproximadamente a quantidade de pontos que sua equipe pode lidar em um sprint sem sobrecarregar ou perder qualidade. Isso ajuda no planejamento futuro.
A estimativa é difícil e, com uma nova equipe, pode ser difícil prever o esforço estimado; portanto, não se preocupe se você perceber, após alguns sprints, que precisa recalibrar suas estimativas. Como sempre com Agile, reflexão e adaptação são fundamentais.
Na reunião de planejamento do sprint, você também deve revisar sua definição de “pronto”: é assim que seu software ficará no final do sprint. É importante que as pessoas que fazem o trabalho (os desenvolvedores) e as que o inspecionam (o proprietário do produto e outras partes interessadas) estejam todas na mesma página aqui.
As reuniões diárias são comumente conhecidas como 'standups' na metodologia scrum. Projetos ágeis se movem rapidamente. Portanto, é necessário que você tenha momentos regulares para fazer o check-in e garantir que não haja obstáculos no caminho.
Uma reunião diária de 10 a 15 minutos é uma oportunidade para sua equipe se reunir para discutir três coisas:
Embora isso possa parecer um aborrecimento para alguns de sua equipe, essas reuniões são essenciais para a comunicação que impulsiona o gerenciamento de projetos Agile. Agile depende de reagir rapidamente aos problemas e expressá-los em um espaço público é uma maneira poderosa de promover a colaboração entre equipes.
Ao final de cada sprint, a equipe terá entregue um software funcional. Este é um grande marco para comemorar! Após o sprint, realizamos uma reunião de revisão do sprint onde revisamos o que foi feito e compartilhamos com as pessoas de nossa equipe e com as principais partes interessadas. Pense nisso como o Agile show-and-tell.
O objetivo desta reunião é provar que os objetivos do sprint foram (ou não) alcançados. Verifique seu plano inicial e certifique-se de que todos os requisitos foram atendidos de acordo com sua definição de pronto. Você pode começar a identificar alterações ou bugs que podem ser adicionados ao backlog do produto e priorizados para o próximo sprint, se desejado.
Se algo deu errado, pergunte por quê? Como você pode ajustar o próximo sprint para que sua equipe atinja suas metas? Agile tem tudo a ver com aprendizado e iterações contínuos, e isso significa em seus processos e também em seu produto.
Agora, é hora de enxaguar e repetir! Hora de iniciar o próximo ciclo de sprint com uma reunião de planejamento de sprint.
