No artigo anterior escrevi sobre a história da criação e origem do Manifesto para o Desenvolvimento Ágil de Software e que um dos resultados dessa criação foram os valores do agile manifesto, que será o tema abordado neste artigo. Então vamos a isso!
“Ao desenvolver e ao ajudar outros a desenvolver software, temos vindo a descobrir melhores formas de o fazer. Através deste processo começámos a valorizar:
Indivíduos e interacções mais do que processos e ferramentas Software funcional mais do que documentação abrangente Colaboração com o cliente mais do que negociação contratual Responder à mudança mais do que seguir um plano
Ou seja, apesar de reconhecermos valor nos itens à direita, valorizamos mais os itens à esquerda.”
Ao criar os 4 valores, os signatários do Manifesto concordaram em seguí-los e disseminá-los. Entretanto levou alguns anos até que a indústria da tecnologia percebesse e começasse a praticar esses valores.
Ao praticar e utilizar os valores do manifesto, muitos agilistas e empresas cometeram um engano (comum na época) de colocar muito foco no lado esquerdo dos valores e “ignorar” o lado direito. Mas o que isso quer dizer? Veja no exemplo abaixo:
Software funcional mais do que documentação abrangente
Este valor do Manifesto nos sugere ter mais foco no software funcionando do que uma documentação extensa. Um dos efeitos colaterais da interpretação do valor foi: Desenvolver e não documentar. E não é isso que sugere este valor.
O mesmo comportamento aconteceu nos outros valores do Manifesto. Foi dado muito de foco no item da esquerda e ignorado o item da direita (e vice-versa).
Um ponto de atenção, é que ao final do Manifesto, tem uma frase de imensa importância:
“Ou seja, apesar de reconhecermos valor nos itens à direita, valorizamos mais os itens à esquerda.”
Esta frase de fechamento do Manifesto nos diz que um item tem mais valor do que o outro e não que devemos fazer um item e não fazer o outro. Ou seja, deve-se ter um equilíbrio e vou dar mais alguns exemplos de disfunções dos valores do Manifesto.
“Indivíduos e interacções mais do que processos e ferramentas”
Este valor é uma gangorra pois eventualmente foi dado mais foco em um item do que no outro e vice versa.
Entretanto, ainda é “normal” encontrar equipas com mais foco em detalhar fluxos, processos e configurar as ferramentas do que nas pessoas e suas interações.
Exemplo: Muitas empresas configuram fluxos rígidos no Jira, Azure Devops ou outra ferramenta e com a isso a equipa não tem flexibilidade de ajustar às suas necessidades e interações.
Com isso, a equipa mete comentários e informações nos “Work Items” das ferramentas e não alinham os itens entre si. Muitas delas não precisam todas as etapas do workflow mas devem seguir com os itens por rigidez da tool.
Essas dificuldades fazem a equipa desistir de usar a tool, novas formas de trabalho e com isso atrapalha a melhoria contínua dos processos e pessoas.
Software funcional mais do que documentação abrangente
Este valor é o que teve mais disfunção na minha opinião porque muitas equipas focaram em desenvolver os projetos, colocar em produção entretanto não fizeram uma documentação mínima do projeto. Com isso, com a saída e entrada de novas pessoas nas equipas, fazer manutenção e evolução dos projetos passou a ser um desafio.
Já vi casos da equipa (ou um gestor de projetos) dizer que “a documentação está nas User Stories”. Mas quem vai aceder às Stories, localizar informação por informação e criar uma documentação? Como fazemos handover do produto para operações e suporte?
Este valor é o que precisamos ter maior equilíbrio de garantir o software funcional e documentar o que for necessário, sem se estender demais.
Colaboração com o cliente mais do que negociação contratual Responder à mudança mais do que seguir um plano
Estes 2 valores estão diretamente relacionados e me dá mais jeito falar deles juntos para falar dos exemplos.
Contexto: Eu trabalho numa equipa de desenvolvimento, estamos a desenvolver o sistema e após uma cerimónia de Sprint Review (Scrum), recebemos os feedbacks do cliente que o sistema não está a funcionar conforme ele deseja.
O cliente apresenta os pontos que precisam ser alterados, pede para que sejam colocados no Product Backlog, que sejam desenvolvidos na próxima Sprint (Scrum) e o Product Owner / Gestor de Projetos anotam esses feedbacks para validar o que será feito com eles.
O que “normalmente” acontece após a review, é que o PO / Gestor avisam o cliente que o pedido está fora do âmbito acordado, que se colocar os itens na próxima sprint vai “atrapalhar” o planeamento da sprint / entregas e em muitos casos apresentam um plano de âmbito e custo adicional para atender aos feedbacks e mudanças sugeridas pelo cliente na Sprint Review.
Neste caso, o “correto” seria negociar com o cliente a troca do âmbito das próximas sprints para poder incorporar os pedidos que ele fez. Ou seja, o que podemos deixar de fazer nas próximas sprints para que sejam feitos esses novos itens?
Consoante ao custo, poderíamos fazer uma gestão dos valores que foram incluídos e removidos das sprints para ao final do projeto fazer um balanço dos custos e fazer um acerto com o cliente.
Seja como for, sempre existirão formas de interpretar e praticar os princípios do Manifesto, mas o que não podemos deixar de lado é a consciência de manter o equilíbrio entre os 4 valores.
Quer perceber mais sobre o Manifesto e outros temas?
Inscreva-se em nossa newsletter para receber nossos conteúdos e novidades.
Até breve.
Referências:
Autor: Ricardo Caldas
Comments