Para além do Scrum Guide: Como melhorar implementações do Scrum em projetos de desenvolvimento de Software

Você já deve ter ouvido ou lido que o Scrum é um “Framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos” não é verdade? Essa frase está presente nas páginas iniciais do Scrum Guide, o guia básico do Scrum escrito pelos criadores da metodologia, a saber Ken Schwaber e Jeff Sutherland.

Desenvolvido no início dos anos 90, teve seu primeiro guia publicado em 2010 e conta com uma versão mais recente publicada em 2020, porém ainda que entendido como uma metodologia pouco prescritiva, se comparado com metodologias de projetos tradicionais, o Scrum Guide objetiva ser um guia para que equipes de desenvolvimento de soluções e produtos digitais possam entender, em linhas gerais, o funcionamento do framework.

Confesso que à primeira vista a palavra “framework” me deixou curioso. Anos atrás, quando comecei o processo de transição de trabalho de metodologias tradicionais para uma menos prescritiva e adaptativa, essa palavra despertou em mim as seguintes dúvidas: “O que é um framework e como o Scrum se beneficia disto?”

Após anos de prática do Scrum e muita leitura, julgo estar mais familiarizado no conceito e trago aqui algumas elucidações sobre estas questões.

Tecnicamente, podemos entender framework como uma estrutura de código (funções e componentes) com a finalidade de criar uma base genérica e funcional que possibilite o desenvolvimento de soluções mais complexas. Tratando de desenvolvimento de software, o foco dos frameworks está na possibilidade de reaproveitar códigos já existentes facilitando o trabalho dos desenvolvedores, otimizando o tempo de desenvolvimento de uma solução e diminuindo os ciclos de integração de software. Portanto, para Ken Schwaber e Jeff Sutherland (também desenvolvedores) o Scrum não seria diferente.

Tratar uma metodologia como um framework é disponibilizar um conjunto de regras e processos que funcionem de forma genérica, moldando-se e adaptando-se aos diferentes cenários, suas complexidades e incertezas. Dito isto, o Scrum se beneficia como metodologia e como framework pois possibilita aos times customizá-lo, dentro (é claro) dos limites inerentes ao Scrum e suas regras.

Outro fator importante é identificar os TradeOffs quando falamos sobre metodologias, pois quanto menos prescritiva for, maior será a abertura para o exercício da criatividade e adaptabilidade e em contrapartida, maior será também o sentimento de ambiguidade sobre ela.

É muito importante que Scrum Masters e Agilitas dominem uma série de ferramentas e técnicas para compor e aprimorar o framework.

Entender o funcionamento do Scrum como framework é fundamental para embarcar dentro dele outras ferramentas e processos visando a melhoria contínua dos ciclos de inspeção e adaptação. Sim, isso é incrivelmente possível e é disto que este artigo trata.

Neste artigo iremos extrapolar o Scrum Guide, trazendo aqui algumas boas práticas que podem ser executadas dentro de um projeto de desenvolvimento de software utilizando o Scrum. Basicamente, vamos beber em três fontes principais, são elas:

• Processos de Discovery;
• Método Kanban;
• Extreme Programming;

Em Processos de Discovery iremos olhar para o fluxo anterior a execução do Scrum, porém extremamente importante no processo do desenvolvimento da solução. Aqui, vamos abordar de forma geral três ferramentas que ajudam os times Scrum a estruturar o conceito da solução bem como um plano de ação para a sua execução, são elas:

• Lean Inception;
• Product Backlog Building;
• Arquitetura Mínima Viável (MVA);

No Método Kanban iremos abordar algumas práticas importantes de gestão de fluxo visando a implementação do Upstream e como as equipes Scrum podem otimizar a formação do backlog de cada iteração.

• Definindo um fluxo de Upstream;

Por último e não menos importante, iremos abordar algumas boas práticas de engenharia advindas do Extreme Programming e como as equipes Scrum podem incluí-las no framework, são elas:

• Desenvolvimento orientado a testes (TDD);
• Refatoração;
• Pareamento;

A ideia principal é proporcionar aos times Scrum uma miríade de ferramentas e técnicas para torná-lo menos ambíguo e focado no desenvolvimento de soluções de software.

É evidente que todas as ferramentas e práticas descritas neste artigo foram abordadas de forma simplificada, portanto não hesite em aprofundar o conhecimento em cada tópico apresentado aqui.

Trate este artigo como uma espécie de “Lib” para o Scrum.

Processos de Discovery : Lean inception

Desenvolvido pelo facilitador Paulo Caroli, a Lean Inception é um workshop colaborativo onde um grupo de pessoas, no nosso caso o time Scrum e Stakeholders, executam uma série de atividades dentro do timebox de uma semana para estruturar da melhor forma possível o MVP

(Produto Mínimo Viável) da solução. Note que essa agenda de atividades tem como finalidade o planejamento do MVP, bem como suas características fundamentais baseadas no conceito de Lean Startup. A execução do MVP será realizada pela equipe através da implementação do Scrum, portanto uma boa prática é rodar uma sessão de Lean Inception antes do desenvolvimento, caso a natureza da solução seja compatível com as nuances de um MVP.

Veja abaixo a agenda sugerida do workshop Lean Inception:

Neste artigo, não iremos detalhar todas as atividades da Lean Inception, porém é importante destacar a atividade de Revisão Técnica, UX e Negócios, onde a equipe Scrum realiza a análise das ideias levantadas na atividade de Brainstorming de Features. Essa análise considera três variáveis, Esforço Técnico, Valor de Negócio e Usabilidade (UX). O objetivo é descartar algo que não agrega valor para o MVP, identificando o score final de cada item. Na atividade Sequenciador de Features a equipe determina a sequência do desenvolvimento e em seguida realiza uma estimativa de baixo nível que pode (e deve) ser ajustada de acordo com a performance do time em relação as entregas.

O workshop finaliza com a apresentação de um Showcase dos resultados descobertos pelo time Scrum para os principais stakeholders e patrocinadores do projeto após a execução da Lean Inception.

Processos de Discovery : Product Backlog Building (PBB)

O Product Backlog Building (PBB) foi criado pelo especialista em produtos Fabio Aguiar em conjunto com o facilitador Paulo Caroli e diferente da Lean Inception é uma dinâmica voltada exclusivamente para o Product Backlog. O termo Backlog foi introduzido no Scrum em meados da década de 90 e desde então vem sendo um dos artefatos principais do Scrum. Como o Scrum Guide não aborda detalhes sobre o processo de construção do Backlog, temos um terreno fértil para a necessidade do PBB.

Executado pelo time Scrum de forma colaborativa dentro de um timebox de no máximo 2 dias, o PBB visa o preenchimento de um Canvas (Canvas PBB). Esse Canvas consolida as boas práticas de construção do Backlog facilitando o processo de descoberta e desenvolvendo o entendimento compartilhado do produto.

De acordo com Paulo Caroli, o PBB pode ser executado após uma Lean Inception já que o foco da Lean Inception está na descoberta do MVP enquanto o PBB foca no desenvolvimento do Backlog do MVP.

Há também a possibilidade do time Scrum executar o PBB sem a necessidade da Lean Inception, visto que nem todos os cenários terão a necessidade de um desenvolvimento orientado a MPV. Vale destacar que nesse caso o período do processo inicial do Discovery pode ser reduzido, entretanto uma boa prática no desenvolvimento de software está na adoção do Dual Track Agile, possibilitando um ciclo de retroalimentação contínuo entre os processos de Discovery e Delivery.

Este artigo não tem como premissa detalhar o Dual Track Agile, porém entraremos em mais detalhes na sessão sobre Método Kanban.

Abaixo, uma pequena ilustração dos passos necessários para a realização do PBB:

Processos de Discovery : Arquitetura Mínima Viável (MVA)

O Termo Arquitetura Mínima Viável (MVA) pode, à priori, parecer incomum para muitas pessoas e times Scrum. Esse termo foi desenvolvido pelo facilitador Paulo Caroli e pelo desenvolvedor Alexandre Corrêa no livro Lean Software Engineering.

Diferente do termo MVA, é muito comum que equipes Scrum desenvolvam MVPs sem pensar muito em sua arquitetura e que inevitavelmente esse MVP precisará ser descartado (Pivotar) ou evoluído, caso o MVP satisfaça as hipóteses de negócio levantadas durante uma Lean Inception de sucesso.

Portanto o MVA precisa estar no meio termo entre nenhum ou muito planejamento. Lembre-se que times Scrum precisam pensar através de uma perspectiva Lean, ou seja, eliminar toda

forma de desperdício no que se refere a escrever código que não será utilizado ou não agregará valor a área de negócios (Gold Plated).

Olhar para os requisitos não funcionais pode ajudar o time Scrum no planejamento do MVA, como por exemplo, acessibilidade, custo, fatores regulatórios e LGPD, tolerância a falhas, auditoria, integridade, testabilidade, escalabilidade, performance, rastreabilidade (Logs) entre outros.

E se tratando de MVPs, a engenharia precisará satisfazer dois fatores fundamentais que são:

• Velocidade de Desenvolvimento: Garantir que a parte de engenharia do time Scrum tenha uma performance de entrega compatível com a característica evolucionária do MVP, mas garantindo um desenvolvimento sustentável;
• Evolucionabilidade: Capacidade que a arquitetura tem de quão fácil ou difícil será para implementar mudanças sem comprometer todo o código (nível de acoplamento);

Uma boa prática no planejamento do MVA é utilizar uma Iteração Zero onde os engenheiros podem definir os detalhes técnicos importantes como pipeline de entrega, ambiente de desenvolvimento, controle de versão, automatização de testes, features toggles etc, antes de desenvolverem os itens do backlog da primeira iteração.

Entraremos em mais detalhes sobre boas práticas de desenvolvimento na sessão sobre Extreme Programming.

Método Kanban: Definindo um fluxo de Upstream

Desenvolvido em meados de 2010 por David. J. Anderson e Don Reinertsen, o Kanban é um método evolucionário e incremental focado na mudança de processos organizacionais. Baseado no TPS (Sistema Toyota de Produção), teoria das restrições e na abordagem Lean, o Kanban vem auxiliando a indústria de software através de implementações de sistemas puxados planejados para limitar e orientar o trabalho em progresso em diferentes tipos de cenários e complexidades.

Diferente do Scrum, o Kanban é muito menos prescritivo, porém detém um corpo de conhecimento muito sólido evitando ambiguidades nas iniciativas de implementação de sistemas Kanban. Seu foco está na melhoria contínua e evolucionária dos fluxos e processos e vai muito além do Team Level, proporcionando também uma abordagem organizacional voltada a serviços e fluxo de valor focados no cliente.

Na sessão anterior falamos sobre como times Scrum podem trabalhar no planejamento do Backlog executando a dinâmica do PBB e utilizando o que chamamos de Dual Track Agile.

Não obstante, o Kanban pode ajudar times Scrum a visualizar e gerenciar o fluxo de refinamento de itens do backlog no que chamamos de fluxo de Upstream.

É muito comum em implementações Scrum a utilização da gestão visual, normalmente um taskboard cobrindo o fluxo de desenvolvimento dos itens do backlog. Uma boa prática nos sistemas Kanban é delimitar as fases de fluxos relacionadas ao Discovery e Delivery, os quais denominamos Upstream e Dowstream.

Estruturar o fluxo de Upstream significa dar visibilidade a todo o trabalho de refinamento e granularidade que um determinado item do Backlog necessita para estar “pronto para desenvolvimento”. Nele, estão delimitadas todos as fases necessárias para que a equipe Scrum se sinta segura para puxar os itens para a próxima iteração, normalmente no Scrum representado pelo evento da Sprint Planning.

Importante ressaltar no parágrafo anterior a importância da palavra destacada “puxar”, visto que sistemas Kanban caracterizam-se como sistemas puxados, diferente de sistemas empurrados. Esse fator é primordial na estruturação de um fluxo contínuo de entrega e pode auxiliar equipes Scrum a acelerar de forma eficiente o fluxo de Upstream (Discovery) impactando positivamente o Downstream (Delivery)

Algumas práticas podem auxiliar equipes Scrum na estruturação do fluxo de Upstream:

• Estruturar um quadro Kanban adicionando o fluxo de Upstream, dando visibilidade a todas as fases necessárias para o refinamento dos itens;
• Compor o Definition of Ready dos itens de acordo com o fluxo e fases do Upstream;
• Realizar reuniões periódicas de refinamento, visto que times Scrum precisam refinar e preparar os itens para a futura iteração, realizando assim um processo de refinamento contínuo;

É muito importante que o Upstream funcione como uma espécie de funil de ideias, evitando que itens sejam levados para o Delivery sem ativar valor real ao cliente, promovendo um cenário enxuto e livre de desperdícios (Lean) mesmo que esses itens já tenham passados por uma Lean Incepition e/ou PBB. De acordo com o feedback e maturidade que o time Scrum ganha ao desenvolver o produto, alguns itens podem ser descartados ou itens novos podem surgir – lembre-se que o Backlog é um artefato orgânico e dinâmico.

Outra grande vantagem dessa implementação é tornar explícito os tamanhos dos itens. Itens com tamanhos homogêneos garantem melhor previsibilidade que serão finalizados até o final da iteração. O ideal (e sempre que possível) é que o time Scrum consiga refinar itens de forma funcional, não tão pequenos que não ativem o valor necessário para o negócio e não tão grandes que não caibam em uma iteração.

Vale destacar que no Kanban, o processo de previsibilidade e melhoria de fluxo tende a ser mais sofisticado pela adoção de alguns métodos, a exemplo o uso da Teoria das Filas e aplicação da Lei de Little (WIP, Throughput e Lead Time), Gráfico de Dispersão e Gráfico CFD e métodos probabilísticos (Forecasting).

É possível que equipes Scrum também utilizem esses métodos, mas não entraremos em detalhes neste artigo.

Abaixo, uma pequena ilustração de um hipotético fluxo de Upstream para um time Scrum onde a fase “Ready for Replenishment” pode ser substituída por “Pronto para Desenvolvimento” ou “Pronto para a Sprint”:

Extreme Programming: Desenvolvimento orientado a Testes (TDD)

O Extreme Programming (XP) foi criado pelos desenvolvedores Kent Beck e Ward Cunninghan em meados dos anos 80 e teve seu primeiro livro publicado (Extreme Programming Explained: Embrace change) nos anos 2000. Importante destacar que Kent Beck é um dos signatários do Manifesto Ágil e que o XP é uma das metodologias ágeis mais próximas do processo de desenvolvimento de software. Enquanto o Scrum se mostra genérico o bastante para ser aplicado em vários cenários, contextos e diferentes tipos de projetos, o XP conserva em sua essência um dos objetivos principais do Manifesto Ágil: “Software funcionando é a medida primária do progresso”.

Dentro do ciclo de vida do Extreme Programming, destacamos neste artigo três boas práticas de desenvolvimento de software que podem ser utilizadas por equipes Scrum.

Porém, antes de falarmos sobre os aspectos gerais das práticas do XP, precisamos pensar como elas podem ser executadas dentro do Scrum.

Sugerimos duas formas de formalizar as abordagens do XP. A primeira é incluir as práticas nos acordos do time, a segunda, porém bastante peculiar, é incluí-las como parte do Definition of Done dos itens no fluxo de Downstream (Delivery).

Importante lembrar que o Definition of Done é tido como o compromisso do artefato “Incrememento” e sua função no framework é criar a transparência necessária que indica que um item do backlog foi transformado em um incremento de software. A adoção das boas práticas do XP por times Scrum é um compromisso inadiável com a qualidade dos entregáveis e como todo aspecto que envolva qualidade, desejamos que seja inegociável.

Em linhas gerais, a aplicação do TDD compreende que os desenvolvedores escrevam testes que possam validar o comportamento de um determinado código, sendo que para cada comportamento exigido pela aplicação, existirá um teste para aprová-lo. Entretanto o que se pede é que exista uma suíte de testes que possam validar continuamente a qualidade do código, para que seja possível submetê-lo aos testes de aceitação, atrelando os itens do backlog ao Definition of Done do Scrum.

Robert C. Martin, em seu livro “Desenvolvimento Ágil Limpo” descreve de forma simples as três regras do TDD, são elas:

• Não escreva nenhum código de produção antes de elaborar um teste que falhou devido à falta desse mesmo código.
• Não escreva mais testes do que o suficiente para identificação da falha – e falhas na compilação ainda contam como falhas.
• Não escreva mais código de produção do que o suficiente para passar nos testes.

Portanto a ideia principal é que os desenvolvedores refaçam esse ciclo de código de produção/ testes seguindo essas três regras. A princípio, pode parecer dispendioso e “contraproducente”, porém a prática do TDD resulta em um aprendizado constante sobre o código e quanto mais se aprende, menos erros e bugs são gerados em produção, economizando dinheiro e evitando retrabalhos no projeto. E é claro, a qualidade agradece.

Extreme Programming: Refatoração

Em 1 de janeiro de 1999, Martin Fowler e Kent Beck publicaram o livro Refactoring: Improving the Design of Existing Code (Refatoração: Aperfeiçoando o Design de Códigos Existentes).

Neste livro, os autores abordam uma das máximas da qualidade de software: Refatorar é preciso, é uma vantagem competitiva, tecnológica e econômica para produtos e negócios digitais. Em linhas gerais, podemos entender como Refatoração a prática de melhorar o código existente sem, é claro, modificar o comportamento esperado de uma dada estrutura de código.

Tal como uma obra de arte e contrariando o senso comum, desenvolver software requer muito poder de abstração e criatividade. E como toda boa obra de arte, ela estará terminada quando o artista considerar ter terminado, do contrário a obra nunca acaba, correto? Felizmente isso não acontece com desenvolvedores, embora possamos considerá-los como “artesões de softwares”.

As restrições de todo projeto, custo, escopo e tempo, indicam quando a obra termina, porém antes de apresentá-la ao público, é preciso refiná-la. No processo de Refatoração, a parte de engenharia da equipe Scrum irá realizar muitas mudanças, nomes, polimorfismo, funções maiores divididas em funções menores, classes repletas de métodos divididas em classes menores, dependências mitigadas etc. E tudo isso sem que os testes falhem. Portanto, a prática de rafatorar está condicionalmente atrelada a prática do TDD, pois a equipe Scrum precisará de uma boa suíte de testes para testar contra o produto da Refatoração.

Tendo isso em mente, para que equipes Scrum possam realizar corretamente o processo de Refatoração, será preciso realizar quatro passos em um ciclo conhecido como Vermelho/ Verde / Refatore, a saber:

• Escreva um teste que falhe (vermelho);
• Faça com que o teste passe (verde);
• Limpe o código (Refatore);
• Repita o ciclo;

Esse processo é muito importante pois por mais que o código funcione, há uma diferença entre código funcional e código limpo. Normalmente os desenvolvedores estarão preocupados em fazer com que o código funcione e seja aprovado nos testes. Portanto, otimizar o código para

executar o mesmo comportamento, com menos código, tornando mais legível e manutenível, será o diferencial para times Scrum e projetos de sucesso.

Extreme Programming: Pareamento

No meio acadêmico, particularmente na produção de artigos científicos, tornou-se comum o uso de um método de revisão chamado de peer review ou Revisão por pares. Essa prática consiste em submeter um artigo para a revisão de um ou mais cientistas, sugerindo ajustes e revisões para que o trabalho possa ser publicado com qualidade ao crivo do método científico.

Portanto, tendo o desenvolvimento de software como um dos braços fundamentais da Ciência da Computação, isso não seria diferente. Uma das práticas mais utilizadas pelos desenvolvedores é a programação em dupla ou pareamento e basicamente consiste na mesma prática descrita acima: Uma dupla de desenvolvedores se unem de forma colaborativa para resolverem algum problema, um determinado comportamento que precisa ser abstraído em forma de código.

Times Scrum podem tirar grandes proveitos da programação em dupla, seja em cenários para resolver problemas complexos, seja em cenários onde desenvolvedores mais experientes possam auxiliar os juniores, seja em um cenário cada vez mais remoto, onde a interação entre os integrantes resulta no atingimento das metas das Sprints.

Entretanto, a prática de pareamento não deve ser obrigatória ou compulsória: é interessante ter itens do backlog que possam ser trabalhados de forma paralela por dois desenvolvedores, mas um sempre será o responsável pela entrega, embora haja responsabilidade e posse coletiva do código. Portanto, não é uma boa prática esperar que uma dupla de desenvolvedores fique 100% dedicados ao pareamento. Há motivos funcionais para o pareamento, entre eles a revisão de código, facilitando o aceite dos Pull Requests para um gerenciador de repositório, por exemplo.

Não há como não concordar que duas cabeças pensam sempre melhor do que uma, mesmo sabendo que há situações em que um desenvolvedor irá programar melhor sozinho, porém considere que times Scrum podem realizar programação em dupla sempre que acharem necessário. Mais uma vez, a qualidade de software agradece.

Conclusões

Quero agradecer a você, caro leitor, pela resiliência necessária para finalizar a leitura e desejo, do fundo do meu coração, que este artigo possa te ajudar na execução prática do Scrum.

O dia a dia de equipes Scrum é repleto de desafios, resolvendo problemas e construindo soluções fantásticas para novas ideias de negócios e produtos digitais. Desenvolver software com qualidade e método requer consistência, adaptação, foco, abertura e muita negociação com todas as partes interessadas. Esperamos que esses métodos e ferramentas aqui apresentados possam enriquecer ainda mais a experiência do desenvolvimento de software em equipes Scrum tornando-as antifrágeis, autoconfiantes e preparadas para os mais diversos cenários.

Nossa equipe de especialistas em agilidade na Lambda3 não se limita apenas ao Scrum Stricto Sensu, sabemos que resultados extraordinários requer diversificação de práticas e métodos.

Caso você tenha interesse e queira saber como podemos te ajudar a melhorar os serviços e produtos digitais na sua empresa, ou queira investir e tirar aquela ideia do papel, entre em contato com nosso time comercial.