Clean Agile, XP e Scrum - Evitando a "ressaca"

Abr 22 (pt)

O board ágil do seu time está com diversos cards estacionados na mesma coluna durante dias e nada é entregue?

O pessoal de negócios está frustrado tendo constantemente que redefinir prazos e estratégias?

Sensação de muito trabalho e pouco resultado?

Se comprometeram com algo e descobriram só depois que não conseguiam cumprir?

O clima está ruim e a situação só parece piorar?

Você pode estar vivendo o que Robert C. Martin (Uncle Bob) nomeou em seu livro Clean Agile como "ressaca ágil". Dificilmente alguém que trabalha com software nunca passou por isso. Principalmente quando há a ausência de pessoas sêniores no time ou estamos lidando com softwares complexos: O código-fonte está espalhado por diversos projetos, é extensivo demais, mal documentado ou mal escrito.

A ideia do ágil é abrangente, complexa (apesar de não parecer) e com vários "frameworks ágeis" diferentes espalhados por aí. Similarmente, softwares também. E quanto mais complexo é um problema, mais difícil é de explicar e entendê-lo. Além disso, nossa transmissão de conhecimento muitas vezes é falha (viés de confirmação, excessos e lacunas de informação), cada ouvinte pode interpretar e replicar a mesma informação de maneiras diferentes, isso pode acabar moldando uma realidade, uma verdade ou um comportamento social.

Voltando ao tema principal, é possível enxergar no mercado uma mistura de interpretações do "ágil" sendo aplicadas ao mesmo tempo, em busca de um resultado idealizado e "teórico" que muitas vezes não se comprova na prática. Essas interpretações podem estar longe do manifesto principal e seus princípios, gerando muita expectativa frustrada, apontar de dedos e poucos resultados.

"A metodologia ágil tomou a indústria de software de assalto, Mas, como um telefone sem fio, as ideais originais da agilidade foram distorcidas e simplificadas, chegando às empresas como uma promessa de "um processo para entregar o software mais rápido"

– Robert C. Martin, Clean Agile, p. 170

Quem é Robert C. Martin

Mais conhecido como Uncle Bob, Robert C. Martin é engenheiro de software desde 1970, consultor internacional, palestrante, autor de vários livros sobre TI e um dos 17 signatários originais do manifesto àgil em 2001. 

Recentemente, ele resolveu voltar ao tema "agilidade" e lançar o livro Clean Agile, onde explica sobre ideias originais do manifesto e faz algumas críticas a como o mercado as absorveu.

O desenvolvimento "ágil limpo"

Segundo o livro, a definição de ágil em sua forma "limpa" (a ideia original, sem ruídos) é:

"Um processo em que um projeto é subdividido em iterações. A saída de cada iteração é calculada e usada para avaliar continuamente o planejamento. As funcionalidades são implementadas de acordo com o valor de negócio agregado, de modo que as coisas mais valiosas sejam implementadas primeiro. O nível de qualidade é mantido o mais alto possível. O cronograma é principalmente gerenciado conforme a manipulação do escopo"

– Robert C. Martin, Clean Agile, p. 32

O resto (Scrum, XP, Kanban) são apenas ferramentas ou frameworks para facilitar e/ou guiar a utilização do ágil.

Além disso, o livro comenta sobre os doze princípios ágeis que devem ser seguidos (podemos conferir aqui http://agilemanifesto.org/iso/ptbr/principles.html)

Uncle bob também cita que o framework XP (Extreme Programming) é o "mais bem definido, completo, menos confuso e o melhor representante do cerne essencial da agilidade", e o utiliza para explicar conceitos do ágil.

XP, um breve resumo

O XP (Extreme Programming) é um framework àgil criado por Kent Beck que nos traz práticas para desenvolvimento de software, representadas no modelo abaixo:

No círculo externo (Roxo), temos 📊 práticas de negócio.

  • Testes de aceitação: basicamente significa que cada demanda (histórias, tarefas e spikes, por exemplo) devem ter seus critérios de aceitação, critérios necessários para termos a conclusão e aceitação de uma demanda. Esses critérios podem ser validados através de testes de aceitação e estão bem alinhados com o conceito de Definition of Done.
  • Pequenas versões: devemos planejar a entrega de software aos poucos, funcionalidade por funcionalidade, de forma gradativa.
  • Planejamento (Planning): o ato de planejar a iteração, definindo como podemos dividir um projeto em funcionalidades, épicos, histórias, tarefas e spikes.
  • Equipe como um todo: a equipe (P.O, P.M, Devs, QA, Gerentes) deve trabalhar em conjunto do início ao fim do projeto, a comunicação deve ser fácil entre as partes. O resultado é de todos.

No círculo do meio (Azul-escuro), temos 👥 práticas da equipe.

  • Integração contínua: o ato de integrar as mudanças feitas ao código principal (produção) constantemente, uma por uma. (Não acumular sequências de mudanças integrando todas de uma vez só)
  • Uso de metáforas: similar a linguagem ubiqua do DDD (Domain Driven Design), todos da equipe devem falar a mesma lingua, inclusive, o código deve refletir essa lingua na forma que é escrito. Particularmente, gosto de dizer que um código legível é aquele em que uma pessoa não técnica conseguiria entrar, ler e pressupor o que está acontecendo com facilidade.
  • Ritmo sustentável: devemos desenvolver em um rítmo previsível. O objetivo não é finalizar rápido, é a equipe ter um ritmo constante e saudável.
  • Propriedade coletiva: qualquer membro da equipe pode verificar e melhorar qualquer módulo do projeto a qualquer momento. O conhecimento deve ser distribuído entre todos.

No círculo interno (Azul-claro), temos 💻 práticas técnicas.

  • TDD (Test Driven Developent): devemos escrever testes automatizados e se possível praticar TDD.
  • Pair programming: devemos estimular a programação em pares, principalmente em cenários em que há a necessidade de troca de conhecimento, mentorias e atenção a demandas muito críticas. É uma escolha que cabe as pessoas programadoras e a equipe (não é algo obrigatório).
  • Refatoração: Temos que entregar um código melhor do que encontramos. Caso haja a necessidade ou oportunidade de refatoração, refatore.
  • Design Simples: "É a prática de escrever apenas o código necessário com uma estrutura que o deixe mais simples, menor e mais expressivo": 
  1. Execute todos os testes
  2. Expresse a intenção
  3. Elimine a duplicação 
  4. Reduza os elementos.

Falando um pouco mais sobre a Planning no XP

Esta é a prática central de todo o framework, o planejamento ocorre em uma reunião chamada Iteration Planning onde:

  1. Verificamos os dados gerados pela última iteração.
  2. Histórias (escritas préviamente pelas pessoas de negócio) são apresentadas e validadas pelos critérios de DoR (Definition of Ready). O livro Clean Agile cita a utilização do acrônimo INVEST (Independente, negociável, valiosa, estimável, pequena (small) e testável) como um exemplo de Definition of Ready
  3. Histórias são estimadas pelas pessoas técnicas. A estimativa pode ser feita em pontos de 1 a 6, tamanho de camisa (p, m, g) ou fibonacci para medir esforço ou estimativa de três pontos caso queiramos estimar tempo.
  4. Histórias Spike são criadas caso alguma história ainda não seja estimável: Não há informação ou conhecimento técnico suficiente para que consigamos entrega-la ou não conseguimos garantir que ela é INVEST.
  5. DoD (Definition of Done / testes de aceitação) das histórias são escritos.
  6. O que faremos na próxima iteração é definido pela equipe como um todo.

Podemos também ter uma segunda reunião de Iteration Planning após a primeira, apenas com o time técnico, para a quebra das histórias em tarefas SMART (Definition of Ready para tarefas), em um board específico "linkado" com o board de histórias.

Segundo o livro, a Iteration Planning é naturalmente bem extensa:

"A reunião deve ser programada para ter um vigésimo da duração da iteração. A IPM (Iteration Planning Meeting) para uma iteração de duas semanas deve exigir cerca de metade de um dia."

– Robert C. Martin, Clean Agile, p. 70

Em uma iteração zero de um projeto, temos um planejamento diferente, em uma reunião chamada Release Planning. Basicamente é a mesma coisa da Iteration Planning, com a diferença de que não definiremos o que faremos para uma única iteração e ainda não temos dados gerados. Focamos em questões globais (em alto nível, sem muitos detalhes) para o projeto como um todo (todas as iterações).

Resumindo os fluxos de um projeto XP tendo o planejamento como a prática central, temos:

Scrum vs XP

Diferente do Scrum, o XP considera práticas técnicas, o que o torna alinhado com o princípio "Continuous attention to technical excellence and good design enhances agility". Inclusive, frameworks como o Scrum necessitam de completementação técnica para funcionar no ambito de desenvolvimento. No Scrum Guide, por exemplo, não temos nenhuma citação clara e explícita sobre práticas técnicas, dando margem a diversas interpretações…

  • Quando damos atenção para as etapas de design de software?
  • Quando uma demanda de negócio está preparada para ser implementada?
  • O que fazemos quando não sabemos como implementar determinada demanda de negócio?

Uma má interpretação do Scrum, sem complementação técnica, pode soar como um "Faz aí dentro da sprint o mais rápido possível", o que é um grande problema:

  • Não existem definições de boas práticas e padrões para desenvolvimento técnico de software.
  • O time não tem uma definição formada sobre quando uma demanda está pronta para ser executada (definition of ready / INVEST) (o Scrum Guide cita apenas definition of done)
  • Discoveries e planejamentos da parte técnica acontecem durante a implementação de uma demanda, e não antes. Causando imprevistos frequentes.

Dessa forma, informações técnicas importantes podem surgir em momentos inapropriados, como após prazos, metas e "goals" já estarem combinados. Portanto, para funcionar em equipes de desenvolvimento o Scrum precisa ser complementado e uma das formas é utilizar o XP.

Mesclando XP com Scrum

Particularmente, prefiro evitar reuniões muito longas, entendo que a exaustão mental acumulada pode fazer com que tomemos decisões erradas. Gosto de trabalhar dividindo as atividades da reunião de Iteration / Release Planning do XP em reuniões menores:

  • A parte de estimativa, criação de histórias, tarefas e spikes / discovery técnicos ficam em uma reunião denominada Backlog Refinement (que acontece sem formalidade durante a iteração, conforme demanda)
  • A parte de planejamento da iteração e comprometimento (sprint goal) fica em uma reunião denominada Planning
  • A revisão dos resultados e dados gerados pelas iterações ficam em uma reunião denominada Review

Além dessas, também gosto de utilizar uma reunião denominada Retrospectiva (geralmente logo após da Review), onde refletimos sobre a iteração e buscamos oportunidades de melhoria, deixando o fluxo mais parecido com o abaixo:

Se trocarmos o nome "Iteração" por "Sprint" e adicionarmos a daily temos todos os Scrum Events definidos no Scrum Guide https://scrumguides.org/scrum-guide.html#scrum-events.

Além disso também podemos trabalhar na nossa Planning, as perguntas do Scrum Planning:

  • Why is this Sprint valuable?
  • What can be Done this Sprint?
  • How will the chosen work get done?

Utilizando práticas do framework XP "temperadas" com os eventos do Scrum, podemos ter um modelo ágil que, respeitando o manifesto e todos os seus princípios, aproveita os benefícios dos dois frameworks.

Daily Meetings

Sobre as famosas "dailys", trago uma citação do livro Clean Agile:

"No decorrer dos anos, tem havido muita confusão sobre "The Daily Scrum" e as "Reuniões diárias (vulgo Standup Meeting). Deixe-me esclarecer essa confusão. Segue o que se aplica à Reunião Diária:

• Esta reunião é opcional. Muitas equipes seguem com as coisas muito bem sem ter uma.

• Pode ter uma frequência menos do que diariamente. Opte pelo cronograma que se adeque à sua realidade.

• Deve durar cerca de dez minutos, ainda que a equipe seja grande.

• Essa reunião segue uma fóruma simples.">

– Robert C. Martin, Clean Agile, p. 113

O autor continua:

"A ideia básica é que os membros da equipe fiquem de pé em um círculo e respondam as seguintes perguntas:

1. O que fiz desde a última reunião?

2. O que farei até a próxima reunião?

3. Existe algum impedimento em meu caminho?"

– Robert C. Martin, Clean Agile, p. 113

Apesar das ideias do autor serem um pouco diferentes do que está definido no Scrum Guide, de acordo com minha experiência profissional, apenas tenho que concordar.

Atualmente as dailys do meu time são assíncronas (mandamos por texto) é rápido e funciona super bem. Caso seja necessário nos aprofundar em algo entramos em uma call síncrona e está resolvido.

  • Entramos em call ou chat síncrono conforme necessidade
  • Economizamos tempo
  • Nos mantemos focados

Evitando a Ressaca

Se eu pudesse elencar 3 práticas principais que evitam uma grande "ressaca àgil", mas onde empresas ainda acabam pecando, baseadas no livro "Clean Agile" e minha experiência profissional, seriam:

1. Atenção ao "design" de software

Design é uma etapa essencial no processo de desenvolvimento de software.

"Toda iteração no projeto, do começo ao fim, terá um pouco de análise, design e implementação. Em um projeto ágil estamos sempre analisando e projetando"

"As atividades de análise, arquitetura, design e implementação de requisitos são constantes durante toda a iteração"

– Robert C. Martin, Clean Agile, p. 24/25

Todas as pessoas que desenvolvem software fazem design, conscientemente ou não.

Antes de iniciar a escrita do código é necessário um tempo de análise da demanda e do ambiente de desenvolvimento em questão, para entender regras de negócio, esforço e padrões do projeto. Em outras palavras, é necessário entender o que teremos que fazer tecnicamente e quais as melhores práticas a se utilizar. É necessário planejar a parte técnica.

Imagine que uma pessoa desenvolvedora pegou uma tarefa com o prazo de uma semana para finalizar e depois de 7 dias desenvolvendo descobriu que a tarefa envolve muito mais esforço do que se sabia no início, e pode levar até um mês para ser finalizada. 

Para melhorar a atenção ao design, podemos criar histórias Spike no board, quando necessário ou mesmo criar um board próprio apenas para discovery técnico de histórias e épicos. Spikes são fundamentais para definição de estratégias de implementação técnica do código e quebra de tarefas.

Também é importante adotar práticas como TDD e Refatorações no cotidiano

2. Mantenha o ritmo sustentável

Desenvolvimento de software é muito mais como uma "maratona" do que como uma corrida de velocidade.  Se mantermos o ritmo, vamos mais longe. 

O importante é sermos previsíveis, mais do que rápidos. Dessa forma, conseguimos métricas e estimativas de prazos mais assertivas.

"Gerentes dispostos a incentivar os desenvolvedores a trabalharem mais rápido estão usando toda a transparência do processo para microgerenciá-los. Agile coaches, sem um pingo de experiência comercial nem técnica, estão treinando gerentes e dizendo às equipes de desenvolvimento o que fazer. Os gerentes estão definindo as roadmaps, os marcos e os empurrando goela abaixo das equipes de desenvolvimento">

– Robert C. Martin, Clean Agile, p. 171

Se tentarmos ir rápido demais, uma hora ficaremos esgotados.

Por estarmos esgotados estaremos mais propensos a causar bugs e erros de design nos sistemas.

Bugs e erros de design desaceleram entregas,

Entregas desaceleradas causam problemas na gestão, 

Problemas na gestão aumentam a pressão e o ciclo vicioso da "ressaca ágil" continua.

3. DoR (Definition of Ready) e DoD (Definition of Done)

A entrada de demandas pouco "refinadas" no "pipeline" de desenvolvimento causam muitos problemas, dentre eles:

  • Retrabalho
  • Sensação de insegurança
  • Perda de tempo
  • Expectativas frustradas

Da mesma forma, "finalizar" uma demanda sem termos uma definição de pronta bem definida pode causar os mesmos problemas se entregarmos algo diferente do que o time de negócio esperava, ou faltando detalhes importantes.

(obs:. Entenda "demanda" como um card de história escrito pelo pessoal de negócio)

Antes de se comprometer com uma demanda na iteração, separe um tempo para refiná-la junto com a equipe:

A etapa de refinamento das demandas pode ocorrer em uma reunião marcada específicamente para isso, no momento da planning (reunião de planejamento) ou em qualquer outro momento em que o time esteja reunido. 

É importante que todo o time esteja presente no refinamentos de demandas pois assim todas as pessoas envolvidas ganham ciência do que é cada uma delas, têm a oportunidade de discuti-las dando opiniões, e se sentem mais seguras caso elas se responsabilizem futuramente pela entrega de alguma das demandas.

Conclusão

Clean Agile é um dos livros mais leves e precisos que li em relação ao tema, o autor realmente capta todo o sentimento envolvendo o ágil nos dias atuais e nos traz "de volta às origens" como prometido. Classifico o livro como necessário para todos que desejam aumentar a performance e melhorar a saúde mental do time em que trabalham mudando perspectivas, quebrando falácias e ruídos em relação ao ágil.

Sobre o modelo que trouxe, já contribui para aplica-lo em alguns times e trago aqui um gráfico baseado em uma experiência real de "antes e depois" em relação a tempo das tarefas do estado inicial ao concluído.

Por volta de abril e maio, resolvemos mudar o mindset e a dar mais atenção ao refinamento das tarefas, spikes e critérios de aceitação além de outras ideias do XP juntas a um fluxo e eventos baseados no Scrum, ganhamos em:

  • Previsibilidade (rítmo sustentável)
  • Confiança
  • Saúde mental

Vale ressaltar que times, projetos e empresas tem suas especificidades e o aprendizado com melhorias contínuas também faz parte do modelo ágil. Portanto não existe um modelo perfeito, mas é sempre bom partir de ideias bem estabelecidas e princípios sólidos para obter o máximo de vantagens.


Ei, o que achou desse artigo?

Compartilhe e dê sua opinião clicando em uma das redes abaixo:


Muito obrigado!