Como usar Scrum com mais produtividade e menos dor

Lidar com Desenvolvimento de Software não é a coisa mais limpa e fácil. Abrange uma miríade de questões, técnicas e não técnicas. O aspecto técnico é certamente muito mais complexo e requer hard skills, mas ao mesmo tempo pode ser gerenciado de alguma forma, usando as táticas e ferramentas certas. O mundo não técnico, por outro lado, tem muito mais graus de liberdade. Tem a mesma variabilidade e imprevisibilidade da natureza humana.

Como em qualquer outro processo de fabricação de produtos, várias práticas recomendadas foram implementadas e testadas desde os primeiros anos da aventura de desenvolvimento de software. As metodologias ágeis são um conjunto de diferentes formas de lidar principalmente com a extrema variabilidade dos requisitos, e também com a falta de foco nos objetivos mais importantes para entregar o produto final.

Às vezes, essas metodologias vão além de seu propósito original e o resultado líquido está longe do ideal. Scrum é uma dessas metodologias. É descrito mais como uma estrutura. É baseado em um conjunto básico de princípios, regras, eventos e papéis. Discutimos neste artigo como essa estrutura pode ser usada com julgamento e flexibilidade e evitar algumas interpretações estritas que podem estar longe do ideal.

Brevemente Introdução ao Scrum

As metodologias Ágeis são baseadas nos seguintes princípios gerais, definidos no chamado “Manifesto Ágil”:

• "Indivíduos e interações sobre processos e ferramentas"
• "Software que trabalha sobre uma documentação completa"
• "Colaboração com o cliente acima da negociação do contrato"
• "Responder à mudança seguindo um plano"

(Fonte: Manifesto Ágil )

De acordo com o Manifesto Ágil, nas afirmações acima, enquanto os itens da direita são importantes, os da esquerda são mais.

Do ponto de vista do processo de desenvolvimento, todas as metodologias ágeis implicam um processo iterativo e incremental em vez do clássico modelo Waterfall: todo o desenvolvimento é feito de uma série de etapas incrementais, e cada etapa é feita das mesmas fases que caracterizam todo um projeto em cascata: coleta de requisitos, análise, design e codificação. Ou seja, cada etapa representa um incremento em todo o desenvolvimento e pode ser vista como um projeto completo por si só.

A metodologia Scrum pode ser vista como uma declinação particular dos princípios acima. Scrum é uma estrutura dentro da qual uma equipe pode usar seus próprios processos para desenvolver algum produto de software específico. É caracterizada basicamente por Papéis , Eventos e Artefatos .

Os papéis são:

• A Equipe : pode incluir analistas, desenvolvedores, testadores e, em geral, todo tipo de profissional envolvido no projeto. Deve funcionar de maneira auto-organizada dentro dos limites das sessões de planejamento do Scrum.

• O Scrum Master : coordena todos os processos Scrum, organiza as reuniões, etc.

• O Dono do Produto : ele/ela tem a responsabilidade pelo produto. Ele/ela gerencia o chamado Backlog do Produto , que contém todas as características necessárias expressas de forma clara. Ele pode discuti-los com a equipe, receber ajuda dela, mas é o único responsável.

  
  

Os eventos são:

• O Sprint : representa um único incremento no desenvolvimento iterativo. Tem geralmente uma duração de duas semanas a um mês.

• Sprint Planning : é uma reunião com duração máxima de 4 horas para Sprints de duas semanas e de no máximo oito horas para Sprints de um mês. É organizado e agendado pelo Scrum Master e inclui a Equipe e o Dono do Produto. Nesta reunião, uma série de funcionalidades do Product Backlog são selecionadas, avaliadas e discutidas para serem desenvolvidas na Sprint atual. Os recursos são selecionados com base em sua prioridade.

• Daily Scrum Meetings : são reuniões diárias de no máximo quinze minutos. Eles são agendados pelo Scrum Master. Nessas reuniões, cada membro da equipe descreve o que fez para implementar as tarefas atuais, os problemas ocorridos e como superar possíveis dificuldades. O Scrum master cuida do agendamento e coordenação dessas reuniões e de sua correta execução.

• A Sprint Review : é uma reunião no final da primavera atual. Leva duas horas para Sprints de duas semanas e quatro para Sprints de um mês. É organizado pelo Scrum Master e os participantes são a equipe Scrum, o Scrum Master, o Product Owner e todas as partes interessadas necessárias de acordo com a decisão do Product Owner. O incremento atual é discutido. O que deu certo e o que deu errado é descrito e, ao final, o Product Backlog é atualizado, se necessário.

• A Retrospectiva da Sprint : é uma reunião de uma hora para Sprints de duas semanas e duas horas para Sprints de um mês. Ocorre logo após a revisão do Sprint e antes do planejamento do próximo Sprint. Nesta reunião, com base na experiência da última iteração, todas as ações para melhorar e agregar qualidade ao produto final são discutidas e planejadas para a próxima Sprint.

  
  

Os artefatos são:

• Product Backlog : é um documento evolutivo contendo todos os requisitos do produto. Cada item é chamado de User Story e possui atributos como descrição, ordem, estimativa e valor. Os itens de ordem superior são mais claros e detalhados.
• Sprint Backlog : contém os itens do Product Backlog selecionados para a próxima Sprint combinados com o planejamento necessário.
• User Story : como dissemos acima, uma User Story é um item do Product Backlog. Uma User Story segue uma estrutura textual comum: " Como um <tipo de usuário>, eu quero <fazer alguma tarefa>, para que <eu possa atingir algum objetivo>. Ela também deve ter uma série de Critérios de Aceitação, cada um com o seguinte esquema: Dada <alguma pré-condição>, Quando <o usuário executar alguma tarefa> Então <ocorrer alguma alteração no status do sistema>.
• Burn-Down Chart : é um gráfico em que o eixo horizontal representa o tempo e o eixo vertical a quantidade de trabalho restante a ser feito para cada etapa no tempo. A quantidade de trabalho pode ser medida pelos chamados Story Points . O Story Point é uma unidade de medida de trabalho que leva em consideração todas as variáveis que podem influenciar o trabalho de desenvolvimento, como habilidades, complexidade, ferramentas e assim por diante.
• Incremento : é o incremento total até o momento, ou seja, a soma dos itens do Product Backlog concluídos até o momento mais todos os outros itens já concluídos nas iterações passadas.

Não confunda Scrum com alguma forma de doutrina

Você pode considerar os itens listados acima como uma base pela qual um conjunto de profissionais pode operar. Eles podem ser vistos como uma ferramenta útil, mas o que realmente traz coesão, intercomunicação e eficácia em um projeto são as próprias pessoas. O fato é que, mesmo com todas essas prescrições rigorosamente seguidas e todo o comprometimento do Scrum Master, um projeto pode cair no caos e falhar miseravelmente.

Isso ocorre porque as pessoas costumam confundir regras, metodologias e estruturas com algum tipo de mecanismo divino que supostamente leva os humanos ao caminho certo. É uma falha psicológica comum. Uma consideração muito importante é que a realidade é diferente das teorias, e é um animal muito complexo e selvagem. Se você acha que pode domá-lo com uma lista de regras e padrões, está fadado ao fracasso.

O verdadeiro propósito do Scrum é minimizar a quantidade de "ruído de fundo" no processo de desenvolvimento e melhorar o foco nas coisas mais importantes. Se usado com a flexibilidade e modéstia corretas, pode ser eficaz nesse sentido.

Na seção a seguir, descrevo um caso de uso real, no qual fiz uma viagem ao mundo do Scrum. Foi uma jornada de pessoas inexperientes, inclusive eu, dispostas a abraçar os princípios ágeis de forma consistente pela primeira vez. Muitos projetos em que trabalhei antes eram feitos de forma iterativa, mas sem toda a cerimônia de um framework ágil real.

Um caso de uso real

Falamos aqui de um caso de uso real, no qual foi feita uma adoção nada estrita do framework Scrum. O projeto consistia em um sistema de software destinado a rastrear todas as atividades envolvidas em um laboratório de anatomia patológica, desde a coleta de espécimes de tecido e tratamento em várias etapas até a distribuição final das lâminas de tecido. O sistema também deveria ser integrado em fases específicas com máquinas externas de automação, por meio de drivers de software específicos.

Eu estava envolvido neste projeto como arquiteto de software. Tive que cooperar com o gerente de projeto para delinear as principais questões e elaborar um projeto básico de arquitetura. Se você seguir os princípios ágeis ao extremo, pensar na arquitetura de antemão não é a melhor coisa. Até mesmo o projeto arquitetônico é visto em um cenário iterativo. Na maioria das situações, porém, você ainda precisa de uma base para começar e deve discuti-la com todas as partes interessadas envolvidas.

Abordei este estudo preliminar de arquitetura tentando ter uma separação clara dos contextos, em uma abordagem estruturada baseada em vistas , pontos de vista e perspectivas . Seguir tal abordagem é importante para ter uma separação clara dos problemas e também para personalizar a discussão com base no tipo particular de partes interessadas.

Uma parte da arquitetura discutida foi de fato a fase de desenvolvimento e sua organização. A própria empresa ainda não havia adotado nenhuma metodologia ágil. No entanto, de acordo com o gerente e demais pessoas envolvidas, queríamos preencher essa lacuna e optamos por nos inspirar no framework da metodologia Scrum.

Não fomos treinados em Scrum, mas estávamos todos conscientes de seus fundamentos. As principais diretrizes que tínhamos em mente para o projeto, tanto metodológicas quanto técnicas, eram:

• Um conjunto básico de práticas a seguir, para nos concentrarmos no objetivo parcial e geral em uma abordagem iterativa (Scrum em nossa decisão final).
• Rastreamento de atividades/fontes por ferramentas de automação.
• Abordagem de Desenvolvimento Orientado a Comportamento juntamente com testes de unidade e integração .

Práticas de Scrum

Motivados pela necessidade de impor uma estrutura sólida de metodologia, mas forçados por nossa falta de habilidades profundas, optamos por adotar algumas das principais regras do Scrum sem ir longe demais. Em primeiro lugar, uma abordagem iterativa era muito importante em nossa mente. O Scrum abrange isso através dos chamados Sprints, que podemos considerar as unidades iterativas de trabalho. Cada Sprint deve cobrir um número escolhido de recursos do backlog e tem uma duração de tempo específica.

Escolhemos duas semanas para a duração de nossos sprints. Antes de começar o negócio real, montamos um Sprint número zero convencional de uma semana para fazer trabalhos preliminares e tarefas organizacionais. Nesta Sprint preliminar, também escrevemos a versão inicial do backlog, com todas as funcionalidades listadas por prioridade. Não adotamos um método específico para avaliar os esforços da tarefa, apenas uma discussão normal entre os membros da equipe.

No início de cada Sprint , quanto às regras do Scrum, discutimos o trabalho já feito, avaliamos todos os problemas encontrados e escolhemos as funcionalidades a serem implementadas no próximo Sprint .

O gerente de projeto desempenhou o papel de Dono do Produto, apoiado por um especialista no domínio. Isso fazia sentido na situação específica porque não havia nenhum gerente de produto real envolvido e o próprio gerente de projeto tinha todo o conhecimento dos requisitos do cliente. Quanto ao Scrum Master, fiz isso por um tempo e depois passei a função para outro colega, mesmo que nós dois não estivéssemos totalmente treinados nisso.

Nossa equipe era heterogênea, com pessoas de diferentes cidades. Fomos forçados então a organizar uma versão virtual de reuniões em pé, agendando chamadas pelo Skype todos os dias no mesmo horário. As reuniões duravam cerca de 15 minutos. Alguns membros da equipe têm alguma forma de resistência em relação a isso, talvez por interpretarem como uma forma de controle, o que não é.

Passamos um tempo conscientizando-os sobre o real significado das reuniões diárias: uma breve discussão entre os companheiros para focar nas principais questões, aprimorar a comunicação e buscar formas de melhorar e facilitar o trabalho de todos. Por um tempo, eles continuaram dizendo que era uma perda de tempo e uma fonte de distração do trabalho real, mas no final conseguimos convencê-los.

Rastreamento de atividades/fontes por ferramentas de automação

Além das práticas metodológicas, também precisávamos de ferramentas para resolver essas principais preocupações:

• Fazer o controle de versão do código, rastrear suas alterações e compartilhá-las com a equipe.

• Rastreamento das atividades e resolução de bugs: o que deve ser feito, quem está designado para o quê e o status disso.

• Correspondência de alterações de código-fonte com atividades.

  
  

O fluxo de informações em um projeto é muito complexo para depender apenas de práticas metodológicas para controlá-lo. Você precisa de um terreno sólido de ferramentas para facilitar o trabalho. Quanto mais tarefas você automatizar, mais poderá se concentrar em coisas importantes e produzir um produto melhor.

Para versionamento de código, usamos o Git, pois é a escolha mais natural. O Git pode ser usado de várias maneiras, e nós adotamos pessoalmente o Gitflow como um padrão de fluxo de trabalho.

Para acompanhar as atividades utilizamos o Redmine , que é uma plataforma geral voltada para o gerenciamento de projetos.

Para lidar com a terceira preocupação, integramos nosso repositório Git com o Redmine de forma que os commits do Git pudessem ser relacionados a tickets específicos do Redmine usando um código de identificação de problema no comentário do commit. Dessa forma, tivemos um mapeamento completo entre as atividades e as unidades de trabalho do Git.

Abordagem de Desenvolvimento Orientado a Comportamento juntamente com testes de unidade e integração

Estávamos fortemente dispostos a basear nosso processo de desenvolvimento em uma abordagem Behavior Driven. O BDD se encaixa muito bem com o Scrum e em geral com os princípios Ágeis, principalmente na parte que diz respeito à comunicação. Ele permite escrever cenários de teste em um formato que pode ser entendido por pessoas não técnicas e, com as ferramentas certas, fornece um relatório visual do status atual. Ele desenha os limites lógicos do produto e força o trabalho de desenvolvimento dentro desses limites.

Os testes funcionais do BDD eram apenas a camada externa de toda a instrumentação de teste. Também usamos testes unitários e de integração. Para não ficarmos sobrecarregados com a complexidade de tal ambiente de desenvolvimento, tivemos que usar as ferramentas e os recursos de automação certos.

As principais tecnologias envolvidas foram:

• Pepino : integrado ao aplicativo Spring Boot com serviços REST

• Outras ferramentas de teste: bibliotecas JUnit , Mockito e Spring Boot para dar suporte a testes de integração.

  
  

O seguinte mapa mental mostra um resumo das coisas discutidas acima:

Considerações

A adoção do Scrum, mesmo que de forma leve e flexível, valeu a pena? A resposta é sim. Sejamos claros, porém, não podemos vê-lo como a solução para todos os problemas e, se adotado sem entender seu próprio espírito, pode ser até prejudicial. A essência de uma metodologia é oferecer um esquema de mente coletiva para fazer as pessoas trabalharem juntas com o máximo de compartilhamento de informações e comprometimento, mas se as pessoas estiverem focadas em seguir as regras de uma cerimônia exótica em vez do trabalho real, o propósito original desaparece.

Uma Analogia Esportiva

Você pode entender melhor o que foi dito acima com uma analogia esportiva. Nem todas as pessoas gostam de futebol, mas quase todo mundo tem pelo menos uma ideia mínima de como funciona. Em primeiro lugar, é um jogo coletivo. Duas equipes se enfrentam em um campo de jogo tentando entregar uma bola dentro de um gol. Para fazer essa tarefa aparentemente simples, eles precisam misturar iniciativas individuais com estratégias e táticas coletivas. Essas estratégias e táticas são ensinadas previamente pelo treinador e representam uma grande porcentagem de todo o tempo gasto nas sessões de treino.

Para serem realmente eficazes, as regras coletivas acima descritas seguidas pelos jogadores de futebol devem ser executadas sem esforço, e sem sequer pensar que elas existem. Eles devem ser automáticos, como os gestos para dirigir um carro, por exemplo. Um requisito básico para atingir esse objetivo é que eles sejam simples o suficiente para serem totalmente absorvidos por todos os jogadores no tempo limitado necessário para se preparar para o campeonato.

Se você está focado em seguir a cerimônia do Scrum ao invés do trabalho real, você acaba trazendo o caos ao invés da ordem. Por outro lado, se você seguir uma abordagem mais pragmática, sendo flexível e até se livrando de todas as coisas que em nossa experiência específica não funcionam, você pode tirar o melhor proveito disso. Você pode até pensar em adiar algumas abordagens do Scrum se achar que são difíceis de seguir e tentar apresentá-las em uma fase posterior.

Gerenciando os gerentes

Vamos enfatizar um conceito: metodologias ágeis e Scrum especificamente, só podem funcionar se as pessoas da equipe estiverem dispostas a adotá-la ou pelo menos cientes de suas vantagens. Não pode funcionar se for introduzido apenas pelos gerentes de uma empresa para seguir o alvoroço geral e dizer ao mundo lá fora: "Viu? Somos ágeis!". Sejamos claros: se o objetivo é apenas marketing, seria melhor apenas fingir seguir essas metodologias. Não é necessário introduzir nos processos internos um ónus que tenha apenas uma finalidade promocional.

Moral da história: as metodologias ágeis só podem ter algum impacto positivo se forem adotadas pelos engenheiros junto com os gerentes e não apenas impostas pelos gerentes. A maioria dos gerentes, especialmente aqueles sem formação técnica, não sabe nada sobre como uma metodologia pode impactar o ciclo de vida de um projeto de software, enquanto os engenheiros sabem, especialmente os engenheiros seniores. Anos de experiência são melhores do que os melhores livros e os melhores cursos.

Além disso, com base em minha estranha experiência em empresas italianas, as organizações costumam ser ditadas por uma cultura que parece vir de algum tipo de herança medieval. Nesse contexto, os papéis do Scrum Master e até mesmo do Product Owner podem ser vistos simplesmente como uma fonte de autoridade em uma carreira, ao invés de papéis operacionais.

Eu experimentei essa dura realidade recentemente, para dizer a verdade. Normalmente essas pessoas não têm a menor ideia do que são os próprios princípios de uma metodologia, e ficam importunando as pessoas com regras que elas nem entendem.

Nesses ambientes horríveis, Extreme Programming e Scrum são apenas títulos sem sentido. Nesses contextos os gestores são fontes de entropia a serem tratadas, e para atingir um nível de produtividade decente a equipe deve administrar seu próprio trabalho e até mesmo os gestores, para diminuir sua má influência. Isso explica o título desta seção: "Gerenciando os gerentes".

Equilíbrio entre metodologia, práticas de teste, atividades de rastreamento e ferramentas relacionadas

No caso de uso descrito neste artigo, falamos sobre metodologia, mas também sobre estratégias de teste, rastreamento de atividades e ferramentas usadas para apoiá-las. Os melhores frameworks metodológicos não conseguem resolver sozinhos todas as questões complexas envolvidas no desenvolvimento de software.

Na verdade, o BDD, que abrange testes funcionais, é uma forma muito eficaz de compartilhar o conhecimento da lógica do sistema de software que está sendo desenvolvido. Cria um forte vínculo entre todos os membros da equipe e o Product Owner e melhora o foco nos aspectos mais importantes do projeto. Portanto, cobre parte dos problemas que o Scrum deveria cobrir.

Os testes de unidade e integração, por outro lado, estão mais envolvidos nos processos internos dos desenvolvedores de software, mas indiretamente tornam as mudanças mais fáceis de lidar, combinando bem com a abordagem iterativa do Scrum.

Conclusão

O desenvolvimento de software é um assunto complexo, mesmo em projetos mínimos gerenciados por um único desenvolvedor. Se um projeto precisa de uma equipe para ser desenvolvido, uma série de questões organizacionais surgem. As metodologias ágeis são uma tentativa de resolver esses problemas, mas seriam realmente úteis apenas se fossem tomadas como um grão de sal e evitando qualquer forma de ampliação sem sentido.