/ AGILIDADE

Manifesto Ágil

Foto de freestocks, via Unsplash

O que é o Manifesto Ágil

Quando falam em desenvolvimento ágil de software, uma das primeiras coisas que me vem à cabeça é o Manifesto Ágil. Ele sugere mudanças para entregar software de forma rápida e com qualidade:

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

  1. Indivíduos e interações mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

No momento estou trabalhando com dois times e tentando implementar o Scrum. Mas enquanto penso em soluções para resolver problemas do dia a dia ao mesmo tempo em que o time se mantém performático, reflito sobre os pontos do Manifesto Ágil.

Como disse no post anterior, ainda estou aprendendo sobre como devo desempenhar o meu papel. Então lendo o Manifesto Ágil novamente para esse post, tracei paralelos sobre o que sei até o momento e o que consigo aplicar:

Indivíduos e interações mais que processos e ferramentas

Acredito realmente que um time ágil deve interagir. As pessoas devem se conhecer ou, pelo menos, ter uma boa convivência. Mas isso não significa que vamos deixar de utilizar as ferramentas de acompanhamento e que não vamos respeitar o processo necessário para fazer um deploy em produção, por exemplo.

Mas o que me salta aos olhos nesse primeiro item é a valorização dos indivíduos. Trabalhamos com pessoas e não temos como saber se todos estão tendo um dia bom, seja no trabalho ou na vida pessoal. Por isso e por experiências pessoais, sei que o trabalho só vai ter qualidade se houver respeito e empatia entre todas as pessoas do time.

Software em funcionamento mais que documentação abrangente

A documentação é o software e todos os artefatos que foram gerados para desenvolver este software. E quando falo de artefatos, me refiro ao Product Backlog, ao Sprint Backlog e todos os desenhos que surgem durante a modelagem ágil. Não entrarei no detalhe, mas no futuro pretendo postar sobre cada um deles.

Ter uma documentação completa pode ser muito importante em determinadas situações, mas se o software não funciona, de nada adianta. Também não podemos esquecer que muitos artefatos são gerados e não são utilizados nem mesmo durante o desenvolvimento, ou seja, dinheiro e tempo jogados fora.

Colaboração com o cliente mais que negociação de contratos

How Projects Really Work

Fonte: The Project Cartoon

Você provavelmente conhece essa imagem. Ela é uma demonstração dos problemas enfrentados durante o desenvolvimento de projetos em que o cliente pede pelo software e só recebe um retorno sobre o que está sendo desenvolvido no final. Também já vi diversas vezes clientes que tinham uma necessidade e nem sabiam explicar qual era.

Se o cliente acompanha o que está sendo desenvolvido, consegue visualizar a evolução do produto e dar feedback constante, a chance de entregar o que ele realmente precisa é bem maior. Caso o que foi entregue não atenda às expectativas, é possível mudar de forma rápida e com um menor prejuízo quando comparado com um produto de software sem a mesma colaboração.

Responder a mudanças mais que seguir um plano

A definição do Scrum permite que mudanças sejam incorporadas, já que o Product Backlog é considerado um artefato mutável. Obviamente, não estamos totalmente preparados para mudanças diárias, mas sabemos que podemos absorver todas as demandas do cliente dentro de um período aceitável. Mas, como no tópico anterior, estando ciente do que o cliente necessita e sabendo dos ajustes a cada entrega é cada vez mais fácil responder a mudanças e finalizar o projeto de acordo com o esperado.

Conclusão

Esses são alguns comentários sobre o Manifesto Ágil, mas entendo que nem todos podem estar de acordo com o que prega o ágil ou o Scrum. Também é muito difícil seguir tudo ao pé da letra no dia a dia, mas sigo tentando tomar decisões baseado no que prega o Manifesto.

Tem alguma sugestão ou até mesmo correção? Os comentários estão abertos e gostaria de saber a tua opinião sobre o tema!



ingridmachado

Ingrid Machado

Engenheira de computação, especialista em engenharia de software.
Autora deste querido blog.

Mais posts