Desenvolvimento ágil é u
m dos grandes temas nos últimos anos, e atualmente, na Engenharia de Software.
Hoje, quando focamos em desenvolvimento ágil, falamos de MVP (Produto Mínimo Viável), Scrum, Lean e outras siglas mais.
Porém, é necessário cuidado para não misturar as coisas, gerando mais problema que solução.
Vejamos a seguir 7 dicas simples e pragmáticas sobre desenvolvimento ágil. 🙂
Reflexão 1 – Ágil e Prioridade
“Agilidade não é fazer software correndo, é fazer com eficiência e eficácia aquilo que é prioritário.”
Para alinharmos, dois conceitos importantes:
- Eficiência = fazer o máximo possível, da melhor forma possível, com o mínimo de recursos necessários.
- Eficácia = fazer o que realmente deve ser feito, e somente o que deve ser feito.
Focando na melhor eficiência e na melhor eficácia, e considerando entregas pequenas em intervalos curtos de tempo, atinge-se o máximo da agilidade.
Fazer software correndo (fazer com pressa, na correria), nada tem haver com agilidade.
Reflexão 2 – Entrega de Valor x Desperdício
“Para quem não mede, qualquer resultado pode parecer bom. Entregar software se não for entrega de valor é desperdício, por exemplo.”
Imagine que você quer emagrecer. Então depois de um regime você emagreceu. Isso é bom? Depende.
Se você emagreceu mais quilos que seu corpo precisa, não é bom, se menos quilos que seu corpo precisa, também não é.
No exemplo acima, antes de fazer o regime então é necessário (por exemplo): medir o peso atual, o peso ideal, massa magra, gordura, altura etc.
Do ponto de vista de produto, entregar um sistema que seu escopo não gera valor para quem o contratou, mesmo que seja um sistema lindo, sem bugs, na melhor tecnologia possível, de pouco serve.
Obs1.: o que citamos acima é igual a desperdício.
Do ponto de vista de processo, medidas como – bugs por histórias/requisitos, velocidade por story points/pontos de função, percentual de code smell, cobertura de testes unitários etc. – são indicadores fundamentais para sabermos se a produção está boa, ou não.
Obs2.: o cúmulo da ineficiência é fazer muito bem aquilo que não deveria ser feito.
Reflexão 3 – Estoque de Funcionalidades
“Estocar funcionalidades é desperdício garantido. Construa aos poucos e construa apenas o necessário.”
Imagine que seu cliente pediu um sistema com 20 funcionalidades. Mas num primeiro momento, ele irá utilizar apenas 5 funcionalidades.
As outras 15 ele utilizará num futuro breve, quando resolver algumas pendências mais urgentes, contratar equipe adicional etc.
Quando você entregar o sistema, 15 funcionalidades – 75% do escopo – ficará estocado, sem uso, sem necessidade. Isso é desperdício.
E quando seu cliente for utilizar as 15 funcionalidades, devido ao tempo que passou, talvez muitos requisitos deste escopo já não façam mais sentido.
Ainda, quando começar a utilizar, perceberá defeitos que não foram vistos antes, porque 75% do escopo estava estocado, sem uso.
E aí o período de garantia já passou, e o retrabalho deverá ser pago como trabalho novo, e por aí vai.
O foco deve ser em entregas curtas, rápidas, tecnicamente viáveis, operacionalmente viáveis, e sempre bem priorizadas.
Reflexão 4 – MVP de “escopo fechado”
“Um MVP (Produto Mínimo Viável) de software é um produto que sofrerá ajustes, e melhor ainda se forem muitos ajustes. Diferente disso, é sorte. E sorte não existe.”
Um dos maiores desafios de produzir MVP, é pensar MVP. Ter mindset de MVP.
Pensar MVP é pensar em experimentar, em ter versão alpha, versão beta; é focar em entregar com velocidade, ter feedback o quanto antes, detectar erros o mais cedo possível, e corrigir logo que o erro for detectado.
E sorte realmente não existe. Existe foco e disciplina, e ter isso como hábito.
A imagem acima mostra um verdadeiro MVP.
Reflexão 5 – Pressa != Velocidade
“Pressa é diferente de velocidade. Não é viável fazer software de qualidade com correria. Mas é possível se ter velocidade sendo produtivo, e assim ter software de qualidade.”
Correria não é boa prática. Nem mesmo no atletismo.
No atletismo, o corredor usa técnica, método, busca ter cadência, monitora ritmo, respiração, batimento cardíaco. Fazendo isso de maneira disciplinada, ele consegue ter velocidade.
Imagine produzir software, uma atividade quase artesanal, na correria. Alguns efeitos são fatais neste contexto, como a garantia de uma taxa altíssima de bugs, equipe rapidamente desmotivada, cliente recebendo uma péssima (péssima mesmo) entrega etc.
Ser produtivo fatalmente leva a entregar software de qualidade. E um profissional produtivo, muitas das vezes, não é aquele que entrega no menor intervalo de tempo, mas aquele que entrega em tempo hábil, com qualidade.
Reflexão 6 – Agilidade != Scrum
“Agilidade é uma coisa, Scrum é outra coisa .Tem muitas empresas que usam Scrum e são menos ágeis, no contexto do Manifesto Ágil, que algumas empresas que usam Waterfall.”
Pensar produção de software no contexto do “Agile” não tem muito a ver com Scrum. O Scrum nos traz coisas muito legais, é orientado a timebox (“pedaços de tempo” definidos e proporcionais ao objetivo dos eventos [reunião, sprint etc.]), produção baseada em backlog priorizado etc.
O Manifesto Ágil é mais um “mindset”. Sem a mentalidade ágil, aplicar Scrum pode ser que não mude nada.
Mas com mentalidade ágil, mesmo com a aplicação de Waterfall podemos entregar mais, e melhor.
Reflexão 7 – Timebox de Sprint
“Sprint maior que 4 semanas não é um Sprint. É um projeto Waterfall de curto prazo.”
No Scrum, um Sprint deve ter entre uma (mínimo) e quatro (máximo) semanas. Dentro de um Sprint, um ciclo completo de produção ocorra, e tenhamos software executável como entrega ao final do Sprint.
Mas existem empresas/equipes que tem Sprints de 6 semanas, 8 semanas, 12 semanas. Fazendo Sprints longos assim perde-se todo o valor que as entregas curtas e rápidas nos dá, como feedback rápido, descoberta rápida do erro, correção rápida etc.
No final, é como rodar um projeto em Waterfall, com um prazo curto. Lembrando que, para projetos muito pequenos, talvez este modelo seja mais aderente mesmo…