Agile

20 mai, 2019

Os 12 princípios do Manifesto Ágil e dinâmicas

Publicidade

Agilidade, no contexto de desenvolvimento de software, é algo difícil de definir e de mensurar.

No entanto, é unânime que sua formalização e, provavelmente suas principais características, estão documentadas no Manifesto Ágil, documento criado e assinado em 2001 por 17 das maiores autoridades em desenvolvimento de software mundial da época.

Embora existam correntes modernas tentando redefinir o que é agilidade ou até desacreditá-la enquanto ideal a ser buscado, ainda acredito humildemente que há muita sabedoria envolvida e que ainda é um caminho muito válido a ser perseguido por times de desenvolvimento.

No artigo de hoje, gostaria de apresentar uma breve visão sobre cada um dos 12 princípios do software ágil, parte fundamental do Manifesto, e dar algumas ideias de dinâmicas envolvendo os mesmos, para ajudar a educar e melhorar times em torno do mesmo.

No final do artigo você pode baixar um baralho com os mesmos, para ajudar nas dinâmicas.

Princípios Ágeis

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

Gerar valor para o cliente é o primeiro princípio, e não é à toa. Substitua a palavra software pelo produto do seu trabalho (independente do setor) e você tem o clássico posicionamento de “cliente no centro da empresa”.

Todo time deveria focar em entregar valor continuamente (e não apenas uma vez no final do projeto) e de maneira adiantada (o que gera mais valor primeiro).

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

Se tem uma expressão que pode ser usada como sinônimo para agilidade é “reagir a mudanças”. O calcanhar de Aquiles do waterfall sempre foi justamente sua inflexibilidade: uma vez fechado escopo, prazo e custo (os três pilares clássicos da gestão de projeto), é só ladeira abaixo.

Times ágeis tentam manter um lead time baixo e ciclos curtos de entregas (sprints, por exemplo), justamente para poder aceitar mudanças de requisitos de maneira mais fácil, com menos atrito.

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

Em uma era de DevOps e Entrega Contínua (CD), esse princípio pode soar ultrapassado se levado ao pé da letra. No entanto, mude o trecho “software funcionando” por “valor ao cliente” e novamente nota-se que não “chegamos lá”.

Apesar da engenharia de software moderna lhe permitir entregar software todos os dias e até várias vezes no mesmo dia, entregar valor para o cliente em ciclos curtos não é assim tão simples e é algo que os times devem estar sempre atentos.

4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto

Esse princípio, originou-se uma série de papéis novos em times ágeis como o Product Owner no Scrum, o Service Request Manager no Kanban e o Cliente no Extreme Programming.

Desde muito tempo notou-se que uma das maiores gaps na entrega dos projetos era o popular “telefone sem fio” e que uma maneira de atacar este problema diretamente era alocando um profissional de negócio dentro do time ágil para trabalhar requisitos e dúvidas diariamente com os desenvolvedores.

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

Esse é um dos mantras do Management 3.0, popular framework de gestão ágil. O criador do método alega que não se deve fazer gestão de pessoas, mas gestão do entorno destas pessoas, garantindo um bom ambiente, suporte e motivação, para que as pessoas consigam se auto-organizar e realizar o trabalho necessário.

Um apelo contra o microgerenciamento, uma prática que sempre destruiu mais valor do que gerou.

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

Tido como um princípio polêmico em uma era de home office, times distribuídos e trabalho remoto, parece insanidade forçar todo mundo a conversar cara a cara, certo? Errado – pelo menos no meu entendimento.

Lembra do primeiro valor do Manifesto? Indivíduos e interações entre eles mais que processos e ferramentas!

Incentivar e perseguir conversas diretas e o mais próximas possível de “conversa cara a cara” sempre será algo eficiente e sadio. E sim, você pode usar Skype pra isso se a outra pessoa está há quilômetros de distância.

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

Novamente, troque “software funcional” por “entrega de valor” e você tem um princípio à prova de métricas de vaidade. A principal métrica de sucesso de qualquer time deve ser o quanto de valor ele entrega para a empresa.

Afinal, de nada adianta um lead time baixo se o time entrega rapidamente software inútil para o cliente, não é mesmo?

Um mau condutor em um carro veloz ainda será um mau condutor. Seja criativo, existem muitas maneiras de mensurar valor.

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

Esse princípio vem lá do pensamento Lean, onde é chamado de Muri (sobrecarga). Para garantir a entrega contínua de valor, o time deve ser capaz de trabalhar constantemente em um ritmo saudável.

Eventuais picos de trabalho acontecem nas melhores empresas, mas salas de guerra todos os dias são uma exclusividade das piores.

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

Esse princípio é contra-intuitivo para alguns gerentes, mas é uma máxima do desenvolvimento de software e até mesmo do pensamento Lean: faça uma coisa bem feita na primeira vez, e não será necessário trabalhar de novo nesse mesmo item tão cedo.

Débito técnico, ferramental ruim, ausência de pipeline automatizado e os famigerados bugs acabam com a capacidade, velocidade e moral de times técnicos. Não deixe isso acontecer.

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

Você já ouviu falar no Princípio de Pareto? O famoso 80/20 é aplicado a muitas coisas, e em software não poderia ser diferente. 20% das features de um software geram 80% do seu valor para o usuário e/ou são usados em 80% das vezes.

Então porque perder tempo fazendo 100% do software? Ou melhor, porque você primeiro não faz os 20% que importam?

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

Dê uma missão clara e com propósito a um time de especialistas e deixe-os trabalhar. Bons times técnicos buscam a excelência por natureza e você não precisa dizê-los como fazer o seu trabalho.

Obviamente, quanto mais distante de um time maduro você tiver, mais próximo você vai ter de gerenciá-los, e isso vale pra tudo, não apenas arquitetura, requisito e design.

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

Melhoria contínua é um processo, um método e se você quer ter resultados reais, precisa se dedicar a ela. Como dito no Toyota Kata, todo processo tende a se tornar ineficiente com o passar do tempo e temos de buscar a melhoria contínua se quisermos nos manter competitivos no mercado.

Dinâmicas com os princípios ágeis

Existem vários dinâmicas possíveis de serem realizadas usando estes princípios, seja no formato de baralho que estou disponibilizando logo abaixo, ou apenas escrito em post its mesmo.

Em momentos como retrospectivas, treinamentos e team buildings, você pode trazer esse assunto à tona para estimular a autocrítica, a reflexão e o amadurecimento enquanto time ágil.

Abaixo, três dinâmicas envolvendo o baralho com os 12 princípios.

Agile Clock

Cole os 12 princípios na parede, formando um relógio do princípio 01 ao 12.

Se for apenas um time que estiver participando da dinâmica, divida-o em duplas, ou se for muito pequeno, deixe os indivíduos separados. Se for mais de um time, forme times menores, mesclando os indivíduos.

Para cada princípio, o facilitador lê em voz alta e instiga as pessoas (em time, ou individualmente, dependendo da configuração) a tentarem resumir o princípio a uma palavra, no máximo duas.

Para que consigam chegar nessa síntese, o time terá um tempo para discutir o princípio e definir sua palavra.

Faz-se isso para cada princípio. Ao término, o próximo passo é, dentre as palavras dos diferentes times para o mesmo princípio, deve ser escolhida apenas uma para ser colocada no relógio, em cima ou ao lado do respectivo princípio.

Para se chegar na palavra final de cada princípio, os times terão de debater com uma timebox fixa, controlada pelo facilitador.

Agile Clock

Note que não existe uma resposta certa, pois o entendimento dos princípios pode variar conforme o contexto dos times.

No entanto, cabe ao facilitador presente instigar e provocar, sem nunca expor suas opiniões de maneira afirmativa, mas sempre interrogativa, para não se sobressair aos demais.

Dinâmica vista durante o PACC do Andy Barbosa.

Prós e contras

Esta é uma outra dinâmica bem interessante, por ser contra intuitiva e ter uma utilidade interessante, especialmente com gestores.

Divida o grupo da dinâmica em dois (grupo PRÓ e grupo CONTRA), ou faça divisões por princípios, dependendo do volume de pessoas.

Crie um painel em duas linhas e 12 colunas (ou o contrário), colocando nas linhas a legenda PRÓS e CONTRAS e nas colunas pode colar cada carta dos princípios (baralho para download abaixo).

O grupo PRÓ deve elaborar em post its bons motivos para seguirmos os princípios ágeis. Coisas boas que eles trazem, o lado positivo das coisas.

O grupo CONTRA deve elaborar em post its razões para não seguirmos os princípios ágeis. Coisas que eles podem atrapalhar, riscos que eles podem trazer, o lado negativo das coisas.

Durante as apresentações, intercale um princípio de cada vez, pedindo que as pessoas apresentem os prós e contras e discutam brevemente sobre cada um para espalhar as percepções. Não é um trabalho de convencimento, mas de compreensão e empatia.

Os objetivos dessa dinâmica são dois: primeiro, entender que, sim, existem riscos e que os princípios não são bala de prata e, segundo, que para cada item identificado pelo grupo CONTRAS, podemos definir ações para mitigá-los.

Um terceiro e oculto objetivo é o agilista identificar o mindset das pessoas do grupo (em especial os gestores) para identificar principalmente os seus medos e temores quanto ao ágil em seus times.

O resultado do grupo CONTRAS é muito mais importante neste caso, e é ali que você vai ter insumos de como vender e aplicar o ágil corretamente nessa empresa.

Dinâmica vista durante o PACC do Andy Barbosa.

Quadrante mágico

Essa dinâmica eu aprendi no site do mestre Jorge Audy. Ele teve a ideia de usar o conceito de quadrante mágico do Gartner para refletir com o time sobre sua adoção e entendimento dos princípios ágeis.

Divida um painel em quatro quadrantes, traçando uma cruz no centro dele. Da esquerda para direita, de cima para baixo, nomeie cada quadrante com: Não acredito, mas Faço; Acredito e Faço; Não Acredito e Não Faço; Acredito e Não Faço.

Peça que um membro do grupo pegue uma carta de princípio aleatória e leia em voz alta, dando o seu entendimento sobre o princípio.

Na sequência, incite uma discussão para decidir se esse princípio é acreditado pelo grupo e se o grupo o faz na prática, para posicionar a carta nos quadrantes.

Obviamente, o quadrante mágico é o topo direito (Acredito e Faço), mas não deixe nada ser colocado lá se não for consenso de que aquele princípio de fato é acreditado e aplicado.

Dinâmica dos Quadrantes

No final, o time pode definir ações para alguns itens que não ficaram no quadrante mágico (Acredito e Faço), sendo a escolha baseada nas prioridades que o agilista tem para o time (por exemplo, vamos nos focar em fazê-los acreditar antes de fazer? Ou fazer para depois acreditar?).