Princípios ágeis revisitados: técnicas e práticas

No terceiro post da série sobre os princípios ágeis, vamos complementar as primeiras partes, voltadas para entrega de valor e comunicação, com os quatro princípios finais, que falam de desenvolvimento em si e do importante tópico da melhoria contínua.

Vamos direto ao ponto!

Atenção contínua a excelência técnica e bom design engrandecem a agilidade.

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!

Simplicidade — a arte de maximizar a quantidade de trabalho não realizado — é essencial.

Embora simplicidade na comunicação e nos processos sejam bastante importantes, é neles que frequentemente pensamos, novamente! Decidi, então, focar em como esse princípio se aplica na engenharia.

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.

As melhores arquiteturas, requisitos e design emergem de times auto-organizados.

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.

Por mais que o responsável seja a pessoa mais experiente do time, o fato de um indivíduo tomar uma decisão que deverá ser acatada pelos outros é arriscado de várias formas! Preferimos, em agilidade, que o time todo seja envolvido nessas decisões. Embora o processo de decisão possa se tornar mais complexo assim, vemos as vantagens:

  • Membros do time se sentem mais responsáveis pelo produto desenvolvido;
  • Eles se sentem, também, com mais autonomia e mais liberdade;
  • Quando identifica-se um problema, o foco é na busca por soluções mais do que em apontar culpados;
  • Iniciantes têm a oportunidade, desde mais cedo, de entender o processo de raciocínio das decisões e, assim, evoluem mais rápido;
  • Mais questionamentos são levantados e o entendimento geral do produto é maior.

Dá trabalho? Sim. Mas essa descentralização chega até mesmo a melhorar a moral, aumentar a velocidade de aprendizado e reduzir o turnover no time!

Em intervalos regulares, o time reflete sobre como se tornar mais efetivo e, então,
sintoniza e ajusta comportamentos de acordo.

Esse é, simplesmente, o mais importante entre todos os princípios ágeis, na minha opinião. Ele nos lembra do importante foco na melhoria contínua, que é base da agilidade!

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!

Práticas relacionadas

E, como os outros princípios, estes também são aplicados na forma de diversas práticas ágeis:

Métricas de código
É muito difícil dizer se um dado código é bom, mas é consideravelmente fácil dizer que um código é ruim! Vários projetos se propõem a tirar métricas do seu código e, se for usar alguma delas, a dica é começar com regras bem relaxadas e ir deixando-as mais estritas conforme melhora os pontos mais tensos do seu código.
Refactor Day
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.
Anzeneering
Misturando a palavra japonesa anzen (segurança) com engineering, surgiu o termo. A proposta é bem interessante: pense em como tornar seu ambiente mais seguro, tanto em aspectos pessoais, quanto na parte técnica. Várias das práticas já comentadas em posts passados figuram nesse grande guarda-chuva de conceitos e vale dar uma olhada no post que cunhou o termo para entendê-lo.
Propriedade Coletiva de Código
Vindo de XP, essa política diz que não existe uma pessoa que é responsável por um trecho de código específico: todos devem ter um senso de responsabilidade sobre todo o código, com autonomia para alterá-lo, extendê-lo ou palpitar sobre ele, seja lá quem o tenha feito.
Times multifuncionais
Em vez de trabalhar em times especializados que, até por isso, dependem fortemente uns dos outros para entregar valor, preferimos que os times sejam formados por pessoas de diferentes especialidades, tanto para aumentar sua autonomia, quanto para termos pontos de vista variados ao pensar na evolução do produto que estamos desenvolvendo!
Retrospectivas
Embora já tenha falado delas na parte II dos posts sobre princípios ágeis, vale relembrar: se você ainda não está fazendo retrospectiva, comece já. Se quiser variar a sua, recomendo dar uma olhada nas diversas opções que o Caroli e o TC sugerem no blog Fun Retrospectives, que ainda está em inglês, mas deve ganhar traduções logo mais.
Feedback
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!

Conhecer os princípios ágeis é o básico para qualquer agilista praticante e vale relembrá-los de quando em quando. E, claro, cada princípio poderia ser explicado e pode ser aplicado das mais diversas formas. Que tal fazer essa discussão com seus colegas e atualizar os princípios que você considera ultrapassados? É um excelente exercício!

Tags:

12 Comentários

  1. Ismael Soares 27/10/2015 at 13:43 #

    Muito bom Ceci! Ótimo resumo.

  2. Jesiel 27/10/2015 at 14:22 #

    Muito bom!!

  3. Gabriel Gaspar 27/10/2015 at 19:27 #

    Excelente série de posts, serão revisitados por mim algumas vezes, com certeza! =)

  4. 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!

  5. Cecilia Fernandes 28/10/2015 at 19:13 #

    Oi galera, obrigada pelo feedback!

    Oi Ivan,
    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.

  6. Marcus Ferreira 03/11/2015 at 09:28 #

    Muito bom!

    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.

  7. 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.

  8. 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.

  9. 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!

  10. 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…

  11. 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. 🙂

    fazermos testes automatizados quando já há ferramentas prontas para fazê-los,

Deixe uma resposta