Princípios ágeis revisitados: técnicas e práticas - Blog da Caelum: desenvolvimento, web, mobile, UX e Scrum
Quando falamos de métodos ágeis, é muito comum que pessoas liguem tais discursos exclusivamente com processos e soft skills. Contudo, se pretendemos trabalhar "em um ritmo constante, indefinidamente" é importante pensar também no material de trabalho de um time de desenvolvimento: no código, no ambiente de desenvolvimento, etc.
Todo desenvolvedor passa, eventualmente, por códigos de dificílima manutenção. Isso acontece por diversos fatores: ausência de testes, baixa prioridade na refatoração de códigos já existentes, falta de padronização… e as muitas e muitas gambiarras que se acumulam com o tempo.
A agilidade lembra que o time todo responsável pelo que produz — e também é responsável por como se sentirão os próximos desenvolvedores (talvez você mesmo, no futuro?) que tiverem que lidar com esse código! Como Joe Yoder bem colocou, todo código tende a virar uma Grande Bola de Lama, então cuidados com ele têm que ser contínuos!
Pense na pior classe do seu sistema. Você tem uma noção clara de qual é ela? Por que você a considera muito ruim? Muito provavelmente, a resposta tem forte relação com a complexidade dela — seja em linhas de código, em uma forte centralização de responsabilidades, em lógicas complicadas todas em um mesmo arquivo, etc.
Já passamos do tempo de valorizar aquele desenvolvedor "tão bom que ninguém entende o código dele". Ou então aquele sistema que faz tudo o que você pode imaginar e mais um pouco. Quanto mais simples o código, melhor. Quanto menos funcionalidades pudermos ter, melhor também.
Quando pensamos em um time mais tradicional, um pequeno subgrupo de pessoas é responsável (e responsabilizável) pelas decisões arquiteturais, do que vai ser feito e, em casos mais extremos, até do design de classes – isto é, de como algo será feito.
Em intervalos regulares, o time reflete sobre como se tornar mais efetivo e, então,
sintoniza e ajusta comportamentos de acordo.
Não importa o quão bem seu time funcione ou o quão fantástico seu produto seja, não existe um "melhor impossível" quando lidamos com pessoas e projetos evolutivos. Com o passar do tempo, valorizamos coisas diferentes e, sem inspecionarmos a nós mesmos, poderíamos até nos afastar de nossos princípios mais básicos. E, se esse fenômeno acontece dentro de cada indivíduo, certamente acontece ainda mais em times.
É importante tirar tempo para parar e pensar no que está bem, no que deveríamos melhorar, no que poderíamos melhorar… e decidir ações a respeito desses itens, que nos levem a um lugar melhor — seja lá o que for melhor para seu time!
Separar um dia da iteração (ou da semana, ou do mês…) para focar os esforços do time apenas na melhoria do código pode trazer enormes benefícios a médio prazo: sabendo que outro refactor day acontecerá no futuro, a tendência é que as pessoas passem a perceber e se incomodar com códigos feios.
E retrospectivas não são o único momento no qual podemos ajudar outros a melhorarem. Feedbacks dados continuamente podem ser poderosos para melhorias e até da motivação pessoal. Lembre-se que há quem reaja melhor a feedbacks positivos e aqueles que reagem melhor a feedback negativo — observe seus colegas para obter melhores resultados com feedbacks bem colocados!
Ismael Soares 27/10/2015 at 13:43 #
Muito bom Ceci! Ótimo resumo.
Jesiel 27/10/2015 at 14:22 #
Gabriel Gaspar 27/10/2015 at 19:27 #
Excelente série de posts, serão revisitados por mim algumas vezes, com certeza! =)
Ivan Lampert 28/10/2015 at 08:02 #
Sou adepto às metodologias e acredito em seus resultados, mas uma coisa que ainda vejo acontecer, são empresas aderindo de forma parcial ou mal compreendido alguns conceitos, o que resulta em frustrações, com isto gestores e participantes da experiência tem a visão errada e negativa sobre as práticas.
Percebo isto em conversas com pessoas que tiveram problemas com a adoção de metodologias ágeis, vejo que estes "problemas" são ocorridos em virtude de não empregarem os conceitos de modo eficaz. Tento argumentar, mas o estrago foi feito. Trauma na certa!
Cecilia Fernandes 28/10/2015 at 19:13 #
Oi galera, obrigada pelo feedback!
na minha percepção, muitas empresas têm entendido agilidade como se ela se resumisse ao scrum e, de fato, isso é muito perigoso. Voltar para as raízes e olhar para o Manifesto Ágil e os Princípios, exercitar a interpretação de cada um deles e pensar em como os estamos violando no nosso ambiente talvez seja uma boa dinâmica pra propor pra essa galera.
Marcus Ferreira 03/11/2015 at 09:28 #
Como a Cecilia falou na resposta ao Ivan as empresas estão precisando voltar para as raízes do desenvolvimento ágil e também olhar as várias metodologias, ver qual a mais adequada para a realidade da empresa, ao invés de focar somente no scrum.
Ceci Fernandes 03/11/2015 at 14:41 #
Isso aí, Marcus!
Eu, particularmente, acho que todo mundo devia aprender sobre XP (eXtreme Programming) além das práticas de código que o método sugere. A forma de pensar sobre o processo que XP propõe é um belo reflexo do pensamento ágil e, por isso mesmo, acho mega importante conhecer.
Pompeu 28/01/2016 at 09:02 #
Muito bom o texto, parabéns! Trabalho na Totvs e eles estão tentando implantar metodologias ágeis, na minha visão estão falhando miseravelmente!! Pra eles Agile se resume à um Scrum meia-boca, não se preocupam com a qualidade, apenas em entregar a funcionalidade, quase nenhum código tem testes automatizados e os testes são feitos manualmente por uma equipe de Quality Assurance que deixa passar muitos erros.
Por exemplo, já li que cada Sprint deve entregar uma nova funcionalidade e agregar valor ao produto, certo? Porém aqui a Sprint só passa de um monte de tarefas aleatórias que devem ser feitas pelos desenvolvedores. Eles utilizam uma ferramenta chamada JIRA que mais atrapalha do que ajuda a equipe, tem um analista que é obrigado a cadastrar todas as tarefas nesse sistema, uma trabalheira danada, nada Ágil.
Ceci Fernandes 01/02/2016 at 14:12 #
Oi Pompeu, obrigada!
É triste, mas acontece bastante ainda, que empresas e times confundam agilidade com a aplicação de um processo, mesmo. Uma potencial forma de começar uma mudança para a melhor é adotar o hábito de fazer Retrospectivas e Daily Meetings (Daily Scrum, se preferirem o nome :-)).
Você também perguntou se "cada Sprint deve entregar uma nova funcionalidade e agregar valor ao produto". A resposta vai até além! Cada Sprint deveria entregar algumas funcionalidades novas e cada uma delas deve ter valor, do ponto de vista do usuário.
Uma ferramenta que você pode usar para isso (que faz parte do próprio Scrum) é sempre pedir uma Meta de Sprint – uma frase que descreve o valor dessa iteração para o produto. Vide sessão Sprint Goal em http://scrumguides.org/scrum-guide.html#events-planning
Outra literatura que pode ajudar é a técnica de Story Mapping, proposta pelo Jeff Patton. Conversar com os POs sobre essa técnica pode ajudar na situação que você reportou. 🙂
Disfunções na aplicação de agilidade são beeeem frequentes, de toda forma. Tente não se desanimar com elas. Quem sabe você ajuda a mudar a cultura para uma mais ágil, fazendo essas pequenas mudanças!
Pompeu 04/02/2016 at 15:06 #
Obrigado pela resposta Cecilia!
Gostaria de saber se na sua opinião é possível utilizar-se de metodologias ágeis com qualquer tecnologia? As vezes me pergunto se nem sempre é possível "ser ágil" quando se tem uma linguagem que nem suporta automação de testes e que nem é 100% orientada à objetos, que é o caso do sistema que damos manutenção…
Cecilia Fernandes 04/02/2016 at 17:35 #
Oi Pompeu, eu não vejo agilidade como algo booleano, então eu creio que sim!
Da visão do cliente, por exemplo, um time ágil é o que se adapta às mudanças de necessidades e se preocupa em agregar o maior valor possível a cada momento. Nessa visão, técnicas de priorização, escrita de requisitos no formato de User Stories, medições de satisfação e busca constante por feedback são as práticas mais impactantes.
Olhando mais para o lado do desenvolvedor, um time ágil preza pela qualidade e simplicidade do produto, já que é mais fácil garantir que seremos capazes de manter um ritmo constante indefinidamente com um código que não quebra a cada mudança. Nesse sentido, queremos quebrar nosso código em partes menores e simples (que independe de OO e ferramental). Também gostaríamos de garantir o funcionamento e, se frameworks de teste não estiverem disponíveis, podemos preparar simplesmente executáveis que montam um cenário, rodam uma função específica e imprimem true se passarem – é uma automatização menos avançada, mas já ajuda bem.
Aí, quanto a não ser OO… dá pra fazer código bem bonito e isolado em Orientação a Objetos, assim como dá de forma procedural. E dá pra fazer caca em ambos, também. 🙂