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)

‘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.

Cascata (Waterfall) x Ágil

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.

Princípios Agile

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.

Quem compõe uma equipe ágil?

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.

Entendendo seus usuários

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:

• Entrevistar usuários atuais sobre como o produto funciona em suas vidas.
• Permitir que os usuários testem seus novos recursos após um sprint e forneçam feedback.
• Perguntar aos usuários em potencial sobre sua experiência com produtos concorrentes.

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.

Definindo a estratégia do produto

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.