Ícone do LinkedIn Ícone do RSS Ícone do Lnk.Bio

11 Ago 2019 | 3 minutos • Agilidade

Manifesto Ágil

Agile 101

Ingrid Machado

Ingrid Machado

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

Image de capa do post 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!

O link do post foi copiado com sucesso!

Mais conteúdos de Ingrid Machado

Imagem de capa do post Métricas de fluxo

15 Mai 2023 • Agilidade

Métricas de fluxo

Atualmente, trabalho em um time em que migramos do Scrum para o Kanban. Seguimos trabalhando com o Jira, mas agora usamos um novo quadro. E, com essa mudança, passamos a usar uma ferramenta para a ...

11 minutos

Imagem de capa do post Iniciando com um novo time

25 Fev 2022 • Agilidade

Iniciando com um novo time

Quem acompanha o que eu escrevo já deve ter percebido o quanto eu gosto de listas e roteiros para encarar diversas situações. Eu até recebi um feedback sobre como eu me saio bem quando eu tenho um ...

6 minutos

Imagem de capa do post Retrospectiva

18 Fev 2022 • Agilidade

Retrospectiva

Trabalhar por um período indefinido no mesmo time exige que se mantenha a melhoria contínua como prática. De outra forma, a manutenção do trabalho de qualidade é inviável. Pensando nisso, a agilida...

6 minutos

linkedin icon
LINKEDIN
Twitter icon
TWITTER
RSS icon
RSS
Lnk.Bio icon
LNK.BIO

Ingrid Machado © 2019 - 2024

• Ingrid Machado © 2019 - 2024

• Layout por Victoria Facundes • Desenvolvido por Cristhian Rodrigues

VOLTAR AO TOPO

voltar para o topo