Os 12 princípios ágeis

O que fazer para garantir que eles estão sendo seguidos

Para contribuir com a trilha de metodologias ágil do grupo Mulheres de Produto, me voluntariei para escrever sobre os 12 princípios nos quais as valores do Manifesto Ágil foram baseados.

Se você é uma pessoa nova no assunto, recomendo ler o post da Priscila que conta um pouco da história de como e porquê este Manifesto foi criado.

Decidi listar os princípios e também alguns exemplos do que eu acredito que podemos fazer para garantir que o desenvolvimento do nosso produto seja realmente ágil.

Principios ágeis e alguns exemplos

1 Nossa maior prioridade é satisfazer o cliente através da entrega adiantada e contínua de software de valor.

• Possuir infraestrutura, ferramentas e práticas que possibilitem a integração e a entrega contínua de software (CI-Continuos Integration/CD-Continuos Delivery).
• Realizar pesquisas antes de escrever código para a identificação do real valor que deve ser entregue e irá satisfazer o usuário. Assim como a entrega contínua de código, as pesquisas também devem ser contínuas e trazerem informações para cada novo ciclo de desenvolvimento. Aqui vocês encontram vários tipos de pesquisas que podem ser feitas.

2Aceitar mudanças de requisitos mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças para que o cliente possa tirar vantagens competitivas.

• Ser flexível e transparente. Com as pesquisas e feedbacks recorrentes é possível (e provável) descobrirmos que algo que estava mapeado para ser feito não terá o valor que se esperava e/ou uma nova funcionalidade pode entregar maior valor para o produto e/ou uma funcionalidade que foi desenvolvida não entregou o valor esperado e precisa ser adaptada ou removida. No desenvolvimento de um produto, a entrega de valor para o usuário, no momento “certo”, é o que garante uma vantagem competitiva no mercado. Por isto, seja flexível para mudar sempre que necessário e transparente para comunicar o esforço técnico e assim ter as informações necessárias para uma repriorização.

3Entregar software funcionando com frequência, na escala de semanas até meses, dando sempre preferência à períodos mais curtos.

• Para garantir que o código entregue esteja funcionando precisamos testar. Existem vários tipos de testes e para cada produto, existem tipos e quantidades diferente de cada um destes testes que devem ser aplicados.
• Para entregar software com frequência, vale o exemplo citado no primeiro princípio sobre CI/CD que já possibilita entrega de código funcionando em dias ou horas.

4Pessoas de negócio e desenvolvedoras devem trabalhar em conjunto e diariamente durante todo o curso do projeto.

• Para times que trabalham de forma presencial a sugestão é de que todas as pessoas estejam na mesma mesa ou pelo menos em mesas uma do lado da outra.
• Para times que trabalham de forma remota ou distribuída é fundamental que todos estejam em um chat único onde a comunicação deve ser constante.
• Ter participação ativa de todas as pessoas (ou pelo menos uma pessoa de cada par) na reunião diária. Desta forma, pessoas que possuem papéis diferentes conseguem aprender e entender melhor sobre os outros papéis.
• Parear com pessoas de outros papéis. A escrita de tarefas ou estórias podem ser feitas em pares ou mesmo em trio como na técnica dos 3 amigos. Para a ideação das telas do produto o pareamento entre designers e pessoas desenvolvedoras traz um ótimo ganho e antecipa possíveis dificuldades técnicas.

5Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário e confiar que farão seu trabalho.

• Os times mais motivados em qual trabalhei foram aqueles que tinham objetivos claros e se sentiam em um ambiente seguro. Uma boa prática é definir o objetivo do produto, da entrega atual e da semana e depois colar na parede do escritório ou fixar no topo do chat do time. Para ter um ambiente seguro, todos devem conhecer e respeitar a diretiva primária das retrospectivas.

6O Método mais eficiente e eficaz de transmitir informações para, e dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

• Em uma conversa cara a cara a comunicação é mais rica de detalhes pois é possível também interpretar as expressões faciais e corporais das pessoas. Atualmente, existem inúmeras ferramentas de videoconferência e planos de internet cada vez mais rápidos que possibilitam estas conversas acontecerem até mesmo com pessoas do time que não estejam no mesmo local.
• Este princípio em nenhum momento diz que não precisamos documentar as decisões tomadas. As conversas cara a cara ajudam a diminuir a burocracia do modelo tradicional para se tomar uma decisão, mas é preciso documentar as decisões. Esta documentação garante que todos tenham visibilidade do que foi decidido e ajuda a montar um histórico do projeto para futuros pessoas que chegarem.

7 Software funcional é a medida primária de progresso.

• O planejamento de cada estória deve garantir a entrega de uma nova funcionalidade para o produto. Se você construir todo o front-end do produto primeiro, depois o backend e então testar, o produto só terá progresso para o usuário depois de tudo pronto. Uma boa prática é criar estórias com a técnica da fatia de bolo onde garantimos entregas menores possibilitando feedback mais rápidos.

8Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

• Todas as pessoas relacionadas a construção do produto devem ser envolvidas deste o início e devem interagir e acompanhar a evolução do produto. Os projetos pelo quais passei onde áreas como atendimento, comercial, jurídico, marketing e riscos estavam juntas deste o início, foram os projetos onde alcançamos melhores resultados dos produtos.
• Para que os usuários sejam incluídos no processo vale lembrar a importância das pesquisas contínuas comentadas no primeiro princípio.

9Contínua atenção à excelência técnica e bom design aumenta a agilidade.

• Reservar um tempo em cada ciclo de desenvolvimento para refatorar o código e o design garante que não será necessário um ciclo somente para estas alterações e sem entrega de software funcional, o que romperia com o terceiro princípio.

10Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

• Menos é mais e tempo é dinheiro! Pensar em cada nova funcionalidade como um novo MVP (Minimum Viable Product/Produto Minímo Viável) ajuda a lembrar que não devemos colocar esforço para construir a funcionalidade (que o time acredita ser) perfeita. Quem vai descobrir e nos dizer qual o melhor uso da funcionalidade é a usuária depois de utilizá-la.

11As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

• As pessoas são seres muito mais complexos do que um rótulo da sua função no time. É importante que cada uma tenha claro qual a expectativa da sua atuação no time. Porém, mais importante ainda é identificar quais são as habilidades que cada uma possui e como elas podem ser aplicadas no dia a dia do projeto. Por exemplo, se pessoas que estão no papel de designer ou de líder técnica gostam de discutir sobre negócios, elas podem e devem parear com a analista de negócios ou com a gerente de produto nestas conversas e também realizar as tarefas dos seus papéis. Aproveite ao máximo as habilidades únicas que seu time possui em conjunto!

12Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo

• Independente do framework de trabalho utilizado, é importante para o time ter momentos frequentes de retrospectiva, onde se descobre o que está dando certo, o que não está funcionando e o que é necessário fazer para ter um time ainda melhor. E não se esqueçam que este também é o momento de celebrar as conquistas do time! Neste link existem várias técnicas para diversificar a forma de fazer uma retrospectiva.

Aproveitem os comentários para também trazer exemplos de atividades que seus times estão fazendo para garantir que os princípios estão acontecendo na prática!