Nos artigos anteriores eu escrevi sobre a origem e os valores do Agile Manifesto. Para concluir a tríade de conteúdos sobre o manifesto, neste artigo vou abordar os 12 princípios do Agile Manifesto. Então vamos a isso!
Mas afinal, o que são princípios?
“Princípios são um conjunto de normas ou padrões de conduta a serem seguidos por uma pessoa ou instituição.”
Fonte: Significados
Ao criar o Manifesto Ágil com os 4 valores, os signatários também criaram os 12 princípios que são a fundação em direcionar no como fazer e/ou como praticar o Manifesto no dia a dia.
Vamos então passar pelos 12 princípios com alguns comentários e observações:
1 - “A nossa maior prioridade é, desde as primeiras etapas do projecto, satisfazer o cliente através da entrega rápida e contínua de software com valor.”
Este princípio tem como objetivo evitar entrega de software depois de meses ou anos de desenvolvimento, e já em 2001 os signatários colocaram o foco no cliente nas entregas de valor.
Ou seja, desenvolve-se o tem maior ROI (Return on Investment) e coloca-se em produção para o cliente utilizar.
2 - “Aceitar alterações de requisitos, mesmo numa fase tardia do ciclo de desenvolvimento. Os processos ágeis potenciam a mudança em benefício da vantagem competitiva do cliente.”
Supostamente, não deveria ser um problema o utilizador partilhar um feedback de melhoria e mudanças na Sprint Review e/ou em outra etapa do desenvolvimento. Conforme comentei no artigo anterior, quando tiver alguma mudança de âmbito, é importante validar, ajustar o plano e entregar o que maior ROI para o negócio / cliente.
3 - “Fornecer frequentemente software funcional. Os períodos de entrega devem ser de poucas semanas a poucos meses, dando preferência a períodos mais curtos.”
Existem muitas frases que utilizamos no dia a dia que são o oposto deste princípio:
“Está pronto, mas falta testar”;
“Está pronto, mas tem dependências”;
“Está pronto mas falta virar para ambiente produtivo”;
“Está pronto, MAS….”;
Esse MAS complica pois se ele aparece em uma frase, se calhar podem existir melhorias no fluxo de trabalho para colocar em produção o mais breve possível. Sem MAS.
Por experiência própria nestes anos de trabalho com Agile em vários projetos e clientes posso garantir que o MAS tem ligação direta com a gestão do backlog, roadmap, dependências e definição de done.
4 - “O cliente e a equipa de desenvolvimento devem trabalhar juntos, diariamente, durante o decorrer do projecto.”
Como fazer para trabalhar com o cliente (utilizador) junto à equipa se grande parte das equipas nem sabem quem são os clientes? Pois…
“Fácil”, o Product Owner é o representante do cliente (ou stakeholders) no desenvolvimento e perante à equipa (Scrum Guide) mas isso não quer dizer que temos que manter o cliente à distância. Pelo contrário.
Seja através do PO ou de outra pessoa da equipa, temos que receber feedbacks dos clientes regularmente durante todo o processo de desenvolvimento para “garantir” que estamos à atender suas necessidades e caso não estejamos, que façamos a correção atempadamente.
5 - Desenvolver projectos com base em indivíduos motivados, dando-lhes o ambiente e o apoio de que necessitam, confiando que irão cumprir os objectivos.
“Quase 30% dos trabalhadores tenciona demitir-se em 2023 (Sapo.pt).” A cada dia torna-se mais importante saber liderar, acompanhar, gerenciar e manter motivadas as pessoas. Além disso, partilhar a estratégia da empresa, o propósito da equipa, como a equipa contribui para os resultados da empresa e também delegar / empoderá-los.
6- O método mais eficiente e eficaz de passar informação para e dentro de uma equipa de desenvolvimento é através de conversa pessoal e directa.
Não é à toa que um dos valores do manifesto é “indivíduos e interações mais do que processos e ferramentas”. Temos neste princípio uma questão “óbvia” que é de conversar “face a face” com mais regularidade do que ficarmos quase que a 100% a trocar mensagens assíncronas pelas ferramentas de comunicação.
Vale lembrar que mesmo ao conversar, eventualmente não percebemos bem as questões, imagina por textos e mensagens?
7 - A principal medida de progresso é a entrega de software funcional.
Se recordam do está pronto, MAS só falta testar do princípio 03? Então, ao conseguir colocar partes funcionais do produto em produção frequentemente (incrementos do produto), usaremos essas entregas como métrica de progresso do projeto. Entretanto também temos outras métricas que devemos e podemos usar:
Leadtime;
Cycle Time;
Throughput;
Capacidade;
Velocidade;
ROI;
Churn;
Ciclo de vida do utilizador;
Etc.
A ideia com este princípio, é usar informações reais de progresso do projeto como métrica e evitar de usar medidas mais “tradicionais” que tem vários pressupostos mas os itens não estão realmente em produção.
8 - Os processos ágeis promovem o desenvolvimento sustentável. Os promotores, a equipa e os utilizadores deverão ser capazes de manter, indefinidamente, um ritmo constante.
O princípio 8 tem ligação com o 5 pois a questão abordada é que a equipa como um todo consiga trabalhar de forma sustentável. Ou seja, buscar evitar pressões exageradas, cobranças, datas de entrega impossíveis, horas extraordinárias e a famosa “sala de guerra”.
O objetivo (independente de ser uma equipa ágil) é que as pessoas reconheçam suas responsabilidades, senso de dono, que façam o seu trabalho e que isso tudo aconteça num ambiente de trabalho saudável, que motive os profissionais.
9 - A atenção permanente à excelência técnica e um bom desenho da solução aumentam a agilidade.
Antes de qualquer coisa, vale lembrar que “ o bom é inimigo do ótimo”. Ou seja, temos que encontrar um meio termo entre ambos.
Já passamos da época do eXtreme Go Horse (XGH) e não faz sentido desenvolver software sem “best practices” e/ou não utilizar tecnologias mais modernas.
Seja em ágil ou em outro método, nós podemos abrir mão da qualidade nunca. Muito menos deixar de desenhar e evoluir a arquitetura e solução do projeto.
Uma boa arquitetura, solução e qualidade do código te ajudam a ser mais rápido, corrigir erros com menos esforço e te permite ser mais ágil nas mudanças de negócio.
10 - Simplicidade – a arte de maximizar a quantidade de trabalho que não é feito – é essencial.
Atenção Product Owners (e outros interessados): Trabalho bom é trabalho não feito. Temos que ser eficazes na gestão do backlog e do trabalho a ser feito e não feito.
É muito importante priorizar o backlog, mas é tão importante quanto despriorizar e descartar trabalho. Existem muitas técnicas para priorização de Backlog para ajudar com essa atividade. Portanto, desapegue e deite fora os itens sem medo!
11 - As melhores arquiteturas, requisitos e desenhos surgem de equipas auto-organizadas.
Este princípio entra em questões de empoderamento, delegação, confiança e humildade e vou dar exemplo sobre isso.
Eu já fui desenvolvedor e muitas vezes, eu e/ou outros colegas sabíamos mais sobre databases, best practices e outras cenas de desenvolvedor do que meu gerente.
Entretanto o gerente (por ser nosso chefe) é quem ditava as regras e formas de desenvolver os sistemas, que na maioria das vezes não eram as melhoras mas tínhamos que fazer pois ele era o chefe (manda quem pode, obedece quem tem juízo).
Nestes casos, falta humildade de algumas pessoas em reconhecer que existem pessoas que sabem mais do que elas e são pagas justamente para fazer o trabalho.
Atenção: Não tenho nada contra os gestores darem opinião sobre cenas, mas se a equipa como um todo tem ownership, responsabilidade e capacidade caberia a equipa em decidir qual arquitetura usar nos projetos.
12 - A equipa reflecte regularmente sobre o modo de se tornar mais eficaz, fazendo os ajustes e adaptações necessárias
Por último, mas não menos importante, o princípio 12 que faz uma ligação com o trabalho e aprendizagem empírica.
Ou seja, com frequência e regularmente a equipa deve parar, conversar, validar o que correu bem, o que correu mal, o que pode-se mudar, criar um plano de ação com os responsáveis e fazer as melhorias necessárias para o próximo ciclo de trabalho.
Quer perceber mais sobre o Manifesto, Scrum e outros temas?
Inscreva-se em nossa newsletter para receber nossos conteúdos e novidades.
Até breve.
Referências:
Autor: Ricardo Caldas
תגובות