@truehenrique - Clean Agile, XP e Scrum

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

Abr 22 (pt)

O board 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? 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 e/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 movimento ágil é abrangente, complexa (apesar de não parecer) e com vários "métodos á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, métodos ou frameworks para facilitar e/ou guiar a utilização do ágil. Além dessa definição, os doze princípios da agilidade devem ser seguidos:

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
Contínua atenção à excelência técnica e bom design aumenta a agilidade.
Simplicidade–a arte de maximizar a quantidade de trabalho não realizado–é essencial.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

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 como uma base ideal 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":

Execute todos os testes
Expresse a intenção
Elimine a duplicação
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:

Verificamos os dados gerados pela última iteração.
Histórias são apresentadas pelas pessoas de negócio 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
Histórias podem ser quebradas em tarefas técnicas SMART e estimadas pelo time técnico. As estimativas podem ser feita de diversas maneiras: em pontos de 1 a 6, tamanho de camisa (p, m, g), fibonacci para medir esforço ou estimativa de três pontos caso queiramos estimar tempo.
Histórias Spike (ou de discovery) são criadas caso não haja informação ou conhecimento técnico suficiente para que consigamos entregar determinada história, ou não conseguimos garantir que ela é INVEST.
O que faremos na próxima iteração é definido pela equipe como um todo, utilizamos os dados gerados nas últimas iterações para nos apoiar (como a velocidade do time).

"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

obs:. Podemos ter uma segunda reunião de Iteration Planning após a primeira, apenas com o time técnico, para quebrar histórias em tarefas SMART ao invés de realizar a quebra em uma reunião só.

Planning em uma iteração zero

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

Scrum é um framework ágil desenvolvido para ser utilizado em ambientes complexos e com mudanças frequêntes, ele define papéis com responsabilidades (scrum master, developers, product owner), eventos (sprint, planning, daily, retrospectiva, review), artefatos (backlog de produto, backlog da sprint, incremento) e a relação entre eles. O Scrum é propositalmente incompleto e o ideal é que ele seja complementado com outras práticas, por exemplo, o scrum guide não define que devemos fazer TDD ou refatorações no código do sistema, mas define que "durante a sprint, a qualidade não deve diminuir", logo, adicionar essas práticas técnicas do XP em um Scrum é algo que enriquece ainda mais o projeto e alinha com o princípio ágil "Contínua atenção à excelência técnica e bom design aumenta a agilidade.".

Pontos similares entre Scrum e XP:

Os dois definem um evento denominado planning para planejar a iteração.
A iteração no XP, é análoga a Sprint do Scrum.
Product Backlog items são similares as User Histories.
Stand Up Meetings são similares as Dailys

Pontos do XP que agregam ao Scrum:

Apesar do Scrum citar que devemos escolher itens que estejam Ready para trabalharmos na iteração, não existe o conceito de Definition of Ready.
Histórias Spike são fundamentais para trabalharmos tarefas de discovery dentro da sprint.
As práticas técnicas, de equipe e de negócio podem incrementar ainda mais a qualidade das entregas
Podemos adicionar critérios de aceitação nas User Histories / Product Backlog Items

Definition of Done x Critério de aceitação

Esses 2 conceitos confundem muita gente, apesar de parecerem a mesma coisa, Defition of Done (do Scrum) é uma definição indepentende de item, enquando o critério de aceitação (do XP) e dependente de um item, exemplo de DoD: "Qualquer item do backlog, para ser considerado pronto, deve ter uma cobertura de testes de 95% ou mais". Exemplo de critério de aceitação: "O usuário deve conseguir clicar no item do menu e ver a página do carrinho de compras".

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, no XP concentramos muita responsabilidade em uma só reunião (Planning), mas seguindo a ideia dos Scrum Events, podemos separar essas reponsabilidades em reuniões mais curtas:

A parte de planejamento da iteração e comprometimento (Sprint goal) continua em uma reunião denominada Planning
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 e necessidade). O ideal é que essa reunião aconteça antes da planning para termos items Ready para a iteração.
A revisão dos resultados e dados gerados pelas iterações ficam em uma reunião denominada Review

Além dessas, também podemos ter uma reunião especifica para refletirmos sobre a iteração e buscarmos oportunidades de melhoria, a Retrospectiva (geralmente logo após da Review), 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 das duas ferramentas.

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 aumentam a previsibilidade e a produtividade de um time, evitando uma grande "ressaca ágil", 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:

Utilize INVEST para histórias e SMART para tarefas.
Escreva critérios de aceitação para a demanda.
Estime a demanda, e caso ainda não haja segurança, crie uma história de Spike para analisá-la e obter mais detalhes.

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!