Metodologia de Desenvolvimento Ágil – Scrum

Por: Rodrigo Borges

Caro aluno,

o Scrum é uma metodologia ágil, e como toda metodologia ágil, se baseia em um documento escrito por alguns profissionais que já trabalhavam com tais metodologias, o manifesto ágil. O manifesto é baseado em valores e princípios que veremos abaixo.

Os valores são definidos assim:

  1. Indivíduos e interações mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

Após listarem esses valores, os autores alertam para um item muito cobrado nas provas: “embora existam valores nos itens a direita, valorizamos mais os itens a esquerda.”.

As bancas costumam dizer que as metodologias ágeis não gostam de processos e ferramentas e esse trecho a cima mostra que eles veem valor sim, só que são contra fazer um processo por fazer ou usar uma ferramenta por usar. Essas ações não adicionam valor ao produto! O que adiciona, é usar os itens da direita porque a equipe vê a possibilidade de agregar valor e não somente porque um processo exige.

Também são definidos os 12 princípios das metodologias ágeis que são:

  1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
  2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas.
  3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
  4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
  5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
  7. Software funcional é a medida primária de progresso.
  8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
  9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
  10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
  11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
  12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

O Scrum

O Scrum, como uma metodologia ágil, herda todos os princípios e valores descritos acima, se é que podemos dizer que ele herda, pois o manifesto surgiu depois do Scrum e do Extreme Programming (XP). O nome se refere a uma jogada do Rubgy onde os jogadores de 2 times se juntam e ambos os times tentam obter a posse da bola. Bom, não conheço o Rubgy e poucos apontam os motivo exato de se usar o nome dessa jogada, mas parece que a ideia de times juntos querendo chegar ao mesmo objetivo que é a posse de bola tem relação com unir o PO com o time scrum de desenvolvimento em busca do software correto.

O que devemos saber é que ele é um framework de gerenciamento de projetos que usa metodologias ágeis para entregar um sistema que o usuário goste e perceba seu valor.

Começaremos listando os papéis que compõe o time Scrum:

  • Product Owner (PO) – dono do produto: um representante do cliente para definir o que será feito, especificando e tirando as dúvidas da equipe. Ele deve ser o ponto único de representação de todos os stakeholders, tratando definições e demandas diferentes por parte dos stakeholders.
  • Srum Master (SM) – mestre scrum: é um facilitador, cujo objetivo maior é ajudar o time a atingir os níveis mais altos, buscando manter o compromisso deles com os valores Scrum, o framework Scrum e com o que foi combinado (entregas da sprint, por exemplo).
  • Development Team (DT) – time de desenvolvimento: decide como cumprirá o trabalho definido pelo PO. Eles são estruturados e encorajados a organizar e gerenciar seu próprio trabalho. Algumas de suas características são:
    • Auto-organizados
    • Multifuncionais
    • Não existe subdivisão do time, embora existam especialidades específicas para certas pessoas.

O scrum começa com o PO definindo o product backlog, ou seja, uma lista de funcionalidades a serem feitas. Normalmente, elas começam em um nível de definição simples, sem detalhes importantes para o desenvolvimento. Essas funcionalidades são os product items que podem ser feitos por meio de users stories (abordarei mais abaixo) e, quando estão muito básicos são chamadas de epics. Um exemplo de epic seria um item dizer “cadastrar usuário”, perceba que não sei que dados eu preciso obter para cadastrar. Preciso do telefone dele, do endereço, do nome completo, terá que cadastrar uma senha?

Agora que o PO tem uma ideia do que ele quer, ele prioriza, define um objetivo para a sprint e, junto com o time de desenvolvimento, define na reunião chamada de Sprint Planning Meeting (reunião de planejamento da sprint) quais os itens do product backlog serão contemplados na sprint que irá começar. O time dedesenvolvimento vai buscar mais informações junto ao PO sobre cada item para que possa entender exatamente o que deve ser feito e quais os critérios de aceitação. Nessa hora os itens de backlog se tornam mais detalhados. Todos os itens escolhidos farão parte do Sprint backlog.

Após o planejamento, a sprint pode começar e terá uma duração de 2 a 4 semanas a depender da escolha do time. É nela que os itens serão codificados e considerados prontos, permitindo que o software seja um incremento do produto que é potencialmente entregável ao usuário.

O que o parágrafo anterior significa? Vamos falar primeiro sobre a definição de pronto: é a decisão daquilo que deve ser feito para que o item seja considerado pronto para ser entregue aos stakeholders e, comumente, envolve o desenvolvimento e testes unitários, além de alguma verificação de qualidade. Mas cada equipe escolhe uma definição de acordo com a necessidade do projeto; vi local onde o pronto era o entregável estar em homologação e testado pelo PO. Por outro lado, um software para uma usina nuclear ou para o controle de uma aeronave, provavelmente terá uma definição de pronto que englobe mais testes e controles de qualidade.

O software potencialmente entregável é aquele que pode ser entregue ao usuário, pois é funcional, muito embora não costume ser entregue por não ter todas as funcionalidades necessárias. Vamos a um exemplo: ao final da primeira sprint, uma equipe finalizou a tela de login, a de cadastro de usuário e a de permissões de acesso (permite que o administrador adicione e remova permissões dos usuários), todas telas de um sistema de vendas. Ele é entregável!? É! Se o usuário quiser, poderá usar. Mas ele ainda não faz o que ele quer: não controla vendas ainda e nem sequer cria uma venda.

Continuando com as fases, todos os dias, durante a sprint, existe a daily scrum ou reunião diária (também chamada de standup meeting ou reunião em pé) que é de até 15 minutos com todo o time de desenvolvimento e todos ficam em pé (isso não é uma crença ou superstição, mas pelo fato de você ficar em pé, terá uma tendência em falar menos e focar apenas no que é fundamental! Já participei de muita daily meeting de 30 minutos em pé e, sentado, algumas chegaram a 2 horas, isso não é scrum e só toma tempo de desenvolvimento com informações inúteis ou que você já sabe). Na reunião, cada um tem que responder de forma concisa a 3 perguntas:

  • O que eu fiz entre a última reunião e agora (normalmente, entre ontem e hoje)?
  • O que eu irei fazer entre hoje e a próxima reunião (normalmente, de hoje até amanhã)?
  • Quais os meus impedimentos para fazer o trabalho?

O objetivo é fomentar o conhecimento e a ajuda entre os membros, você pode estar trabalhando e alguém pode lhe dar dicas que te ajudem a fazer o trabalho mais rápido ou pode ter um impedimento que precisa ser levado para o PO. Também, permite que o time se auto-gerencie através da definição daquilo que cada um já fez.

Após a sprint, esperamos ter um produto potencialmente entregável e teremos 2 eventos de cerca de 4 horas cada um, são eles a:

  • Sprint review (revisão da sprint): o time demostra o incremento da sprint para o PO e outros stakeholders em busca de um aceite, mas cada item do backlog é analisado e, muitas vezes, são pedidas algumas alterações que entram no backlog do produto.
  • Retrospective meeting (reunião de retrospectiva): o objetivo dessa reunião é olhar para o processo de forma crítica para apontar os pontos positivos e negativos de modo que os positivos possam ser maximizados e os negativos possam ser corrigidos ou minimizados.

Artefatos:

  • Produtc backlog
  • Sprint backlog
  • Incremento do produto potencialmente entregável

Eventos:

  • Sprint Planning Meeting
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Fonte: https://www.onlinebooksreview.com/articles/best-scrum-book

Ferramentas

Algumas ferramentas costumam ser utilizadas na metodologia ágil para auxiliar no processo. A seguir, listo algumas delas.

User stories

A user stories ou história de usuário é uma forma simples e direta de dizer o que usuário deseja naquela funcionalidade. Ela costuma seguir o seguinte padrão : “EU, enquanto ator> [quero / preciso / …] (a ação)> para funcionalidade>.” Vamos a um exemplo: “Eu, enquanto caixa do supermercado preciso lançar cada item comprado e quantidade para que o sistema possa calcular o total da compra”.

Técnicas de estimativa

  • Pontos por história: é uma técnica que usa valores baseados em um item que serve de métrica base, normalmente um que seja bem simples para ser o valor 0 e os demais serão relativos a ele. Os valores possíveis costumam ser baseados na sequência de fibonacci: 0, 1, 2, 3, 5, 8, 13, 20, 40 ou 100. Os maiores números são chamados de épicos e devem ser subdivididos para que caibam em uma sprint e sejam mais facilmente controlados.
  • Planning poker: a técnica é usada para definir o valor de um item e é feita com um baralho com os números apresentados na técnica acima. Costuma ter também o símbolo de infinito para indicar que a tarefa é grande demais e pode ter outro símbolo para indicar a necessidade de mais esclarecimentos por parte do PO. Quando usada, o PO começa apresentando o item para que os membros entendam o que precisa ser feito e cada membro escolhe um valor a ser apresentado ao mesmo tempo por todos. Normalmente, os extremos (menor e maior valores) apresentam a sua justificativa e é votado de novo até que se obtenha um valor de consenso – o valor do item de backlog.
  • Dias ideais ou horas ideais: é uma estimativa baseada em dias ou horas para se fazer uma atividade.

Quadro Kanban

O time scrum é auto gerenciável, logo ele precisa de alguma forma de fazer isso com simplicidade. O quadro Kanban é um conjunto de listas que tem o que falta iniciar, o que está sendo feito e o que foi feito, outras etapas podem ser inseridas conforme a necessidade e costumam refletir as etapas necessárias para o item ser considerado pronto, podemos ver um exemplo de kanban na figura abaixo. Os itens são tickets, normalmente em post it, com um resumo da atividade e a estimativa de execução, se algum integrante da equipe tiver pego a tarefa para fazer, o ticket terá alguma marca indicando quem está ou já trabalhou nele.



Fonte: https://pluga.co/blog/gestao-empresarial/tipos-de-kanban/

Burndown Chart

É uma forma gráfica de exibir o trabalho realizado e o trabalho esperado ambos em um gráfico decrescente, estimando se a equipe conseguirá cumprir o prazo ou não. Ele pode ser aplicado a uma sprint ou ao projeto todo; no primeiro, indica como está a execução em relação ao esperado para a sprint e, no último, em relação ao projeto. O problema em relação ao projeto é que ao longo do tempo entram novos product items no backlog, o que aumenta a quantidade de pontos total a serem feitos.

Abaixo, fiz um exemplo de um burndown chart de uma sprint de 30 dias. Perceba que existe o desejo de finalizar os 45 pontos por história na sprint, o que nos cria uma reta amarela indicando qual a conclusão diária de pontos para que se chegue ao final da sprint com tudo terminado.

A curva laranja nos diz quantos pontos de história temos ainda por fazer e se estamos dentro ou fora da meta. O ideal é que esteja sempre abaixo da linha amarela, pois estaremos finalizando mais pontos do que o previsto até aquele momento e, se a situação se mantiver até o final, o trabalho será finalizado antes do último dia previsto para a sprint.

Fonte: O autor (2020)

Listo a seguir algumas questões sobre:

E criei um caderno de questões sobre o tema:

Referências Bibliográficas:

Manifesto for Agile Software Development. Disponível em: <https://agilemanifesto.org/ >. Acesso em: 21 dez. 2019.

Scrum Guides. um Guia do Scrum. <https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf >. Acesso em: 21 dez. 2019.

Principais técnicas de estimativas empregadas no Scrum. <http://www.metodoti.com/2019/06/principais-tecnicas-de-estimativas-empregadas-no-scrum >. Acesso em: 04 jan. 2020.

Rodrigo Borges

Bacharel em Ciência da Computação (PUC-Rio) 2003 Pós Graduação em Criptografia e Segurança em Redes (UFF) 2009 MBA Gerenciamento de Projetos (FGV-Rio) 2012 Aprovado e classificado nos seguintes concursos: EAOT-FAB/2006, Dataprev/2012, TRE-MT/2015, TRT-MT/2016, TRE-Pe/2017, TRE-Pr/2017, TRE-RJ/2017, STM/2018, TRT-SP, entre outros.