Modelo de Gestão de Projetos Scrum para Desenvolvimento de Software

O Scrum é um dos modelos de gestão de projetos utilizado pelo Instituto Modal, especialmente – mas não exclusivamente – para projetos de desenvolvimento de software.

Referências adicionais estão disponíveis em:

• Guia do Scrum: Um guia definitivo para o Scrum: As regras do jogo. Disponível em: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-PortugueseBR-3.0.pdf

Revisões #

Versão	Data	Alterações / Comentários	Revisor(es)
1.0.0	26/05/2022	Criação do documento.	Edmilson Veras
1.0.0	01/12/2022	Adequações para padrão Wiki. Inclusão das seções “O que é Scrum?” e da seção “Conceitos do Scrum e como são aplicados”. Revisão.	Bruno Souza
1.0.0	07/12/2022	Revisão geral.	Edmilson Veras
1.0.0	12/12/2022	Melhoria na descrição dos critérios de aceite. Incluída a seção “Time Scrum”. Revisão de texto.	Bruno Souza
1.0.0	20/12/2022	Inclusão da seção “Ferramenta de Gestão”.	Bruno Souza

O que é Scrum? #

O Scrum é um framework para gestão de projetos que utiliza a metodologia ágil. O vídeo a seguir apresenta uma visão geral do que é Scrum:

No Instituto Modal, os rituais do Scrum a serem seguidos incluem:

1. A realização de reuniões de planejamento (planning), refinamento (grooming), revisão (review), retrospectiva (retrospective) e diária (daily).
2. O uso de sprints com timeboxes definidos e iguais.
3. Utilização de ferramentas que facilitem a comunicação entre a equipe, incluindo ferramenta de gestão de projetos, de videoconferência, compartilhamento de conhecimento etc.

Conceitos do Scrum e como são aplicados #

Time Scrum #

O Time Scrum é composto por uma equipe com 3 a 9 pessoas – essa quantidade é uma referência e pode ser alterada caso necessário. No Time Scrum não existem tarefas pré-definidas para o desenvolvedor, testador, analista etc. A principal característica do Time Scrum é que as pessoas trabalham juntas para completar com sucesso um Sprint.

O Time Scrum deve possuir algumas características fundamentais para um projeto de sucesso:

• Colaboração: todos são responsáveis pelo sucesso do Sprint, e não somente o Scrum Master ou o Gerente do Projeto.
• Multidisciplinaridade: o Time Scrum conta com profissionais de diferentes áreas, trazendo visões distintas e complementares, sem que uma perspectiva seja necessariamente mais importante do que a outra.
• Auto-Organização: o próprio Time Scrum é responsável pelo andamento das tarefas – cada desenvolvedor “puxa” qualquer história de usuário que esteja pronta para o desenvolvimento, sem que o Scrum Master tenha que atribuí-la.
• Tamanho Certo: o Time Scrum é enxuto ao ponto de que todos os profissionais consigam desenvolver um ritmo de trabalho consistente, porém grande o suficiente para que ninguém fique sobrecarregado.
• Cultura: o Time Scrum compartilha uma visão única de sucesso, orientada à produtividade e ao trabalho com alegria, companheirismo e resultados.

Papeis no Time Scrum #

O Time Scrum possui os seguintes papéis:

• Scrum Master: é o “Guardião do Scrum”, responsável por garantir que os rituais do Scrum sejam seguidos por todos.
• Time DEV: é o time de profissionais que desenvolve as histórias de usuário, sem que haja necessariamente uma distinção entre desenvolvedor, testador, infraestrutura etc.
• Product Owner (PO): atua como um “procurador” do cliente, responsável por trabalhar com gerenciamento de produto em qualquer área. Seu papel envolve o cuidado com o que será produzido, analisando desde a estratégia de negócios ao design do produto. Entre suas responsabilidades, está a definição do escopo do produto que será criado, ou seja, a preparação das histórias de usuário e a priorização do que deve ser feito primeiro.

Além desses papéis essenciais, o Time Scrum também pode ter colaboradores eventuais para atividades específicas necessárias ao desenvolvimento de uma ou mais histórias.

Finalmente, no framework Scrum, o cliente é um participante ativo do projeto, cabendo a ele responsabilidades específicas e o acompanhamento permanente de tudo o que acontece.

Backlog do produto #

É uma lista ordenada / priorizada de tudo que deve ser necessário no produto. O backlog é composto por itens de backlog do produto (PBIs – Product Backlog Items), que podem ser qualquer coisa – requisitos de mercado, casos de uso e especificações, por exemplo (ver História de Usuário).

• Na ferramenta Taiga, utilizada para gestão dos projetos, utilizaremos as histórias de usuário para criar os itens de backlog do produto
  • Para a necessidade de um usuário do sistema, os requisitos serão escritos em forma de Histórias de Usuário, com os devidos critérios de aceite.
  • Para outras especificações, na forma mais adequada à necessidade.

Backlog da Sprint #

É uma lista ordenada / priorizada de Itens do Backlog do Produto que a equipe acredita poder concluir durante a Sprint. Esses itens são extraídos da parte superior do backlog do produto (priorização feita pelo Product Owner – PO) durante a reunião de planejamento da Sprint.

Incremento de Produto #

É a soma dos Itens do Backlog do Produto, entregues em cada Sprint.

História de Usuário #

É uma qualificação do backlog do produto que descreve uma pequena parte do projeto que, ao ser concluída, apresente um aspecto do resultado do produto que seja funcional e útil para o cliente / usuário.

Uma história de usuário segue geralmente a seguinte estrutura:

1. Descrição da história seguindo o modelo:
   ”COMO <papel do usuário do sistema>, DESEJO / PRECISO / QUERO <ação a ser executada pelo sistema> PARA <objetivo a ser atingido pela ação>.”
   Exemplo:
   “COMO membro de uma equipe da unidade policial, DESEJO visualizar detalhes de um processo de forma cronológica PARA acompanhar o andamento processual no PJe.”
2. Critérios de Aceite, que são os requisitos necessários para o desenvolvimento e validação da história (ver Critérios de Aceite). Pode haver vários critérios de aceite para a mesma história.
3. Anexos, que podem ser protótipos de telas, regras de negócios, documentos ou outros artefatos que facilitem a execução da história.

Deve ser considerado o acrônico INVEST para a atividade de refinamento das histórias de usuário – Independente, Negociável, Valiosa, Estimável, Small (Pequena) e Testável.

• Independente: significa que a história não depende de outras histórias para ser executada, ou seja, poderá ser realizada em qualquer momento, independente da ordem cronológica definida pelo PO.
• Negociável: trata da negociação entre a equipe de negócio e a equipe técnica para buscar apenas a essência do requisito e não o seu detalhamento, pois uma história poderá evoluir ao longo do projeto.
• Valiosa: é a capacidade da história em agregar valor ao cliente e ao produto.
• Estimável: refere-se à capacidade de estimar a dimensão de uma determinada história para poder ser priorizada com o objetivo final de permitir o planejamento do roadmap futuro.
• Small: histórias pequenas e capazes de serem estimadas, porém, não tão pequenas que não agreguem valor ao cliente. Uma história grande demais tira o foco do desenvolvimento, o que exige quebrá-la em duas ou mais histórias menores e que permitam a entrega do valor em uma Sprint.
• Testável: a história deve ser passível de teste, ou seja, é necessário validar se os critérios de aceite foram atendidos de maneira satisfatória para poder ser verificada a sua conclusão.

Além das histórias de usuário, também pode existir itens de backlog (que, no sistema de gestão adotado pela NBTI, também se chamam histórias de usuário). Os itens de backlog seguem a mesma ideia geral das histórias, no entanto, possuem uma perspectiva mais técnica, voltada para construção de funcionalidades necessárias que não passam, necessariamente, pela necessidade da definição de um usuário. Alguns exemplos de itens de backlog seriam a preparação de um ambiente de trabalho / desenvolvimento / homologação / produção; o desenvolvimento de um serviço de backend a ser consumido; a elaboração de um documento de referência, relatório técnico ou similar etc.

Neste documento, para simplificar, será utilizada o termo “história de usuário” (ou simplesmente “história”) para designar tanto itens de backlog quanto histórias propriamente ditas, exceto quando necessário fazer uma diferenciação.

Critérios de Aceite #

Para a definição dos critérios de aceite de uma história de usuário, utiliza-se a técnica BDD (Behavior-Driven Development, ou Desenvolvimento Orientado por Comportamento). O BDD é técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação, focando o comportamento do software. Isso significa que os testes orientam o desenvolvimento, ou seja, primeiro se escreve o teste e depois o código.

BDD ajuda a simplificar a comunicação usando cenários descritos pelo cliente ou PO. Cada cenário é dividido em três blocos definidos pelas palavras-chave:

• Given (DADO) – dado um contexto;
• When (QUANDO) – quando acontecer um evento;
• Then (ENTÃO) – então se espera que aconteça algo.

Exemplo:

”DADO que <tal ação seja executada pelo usuário>, ENTÃO <executar alguma ação>.”

“DADO que <tal evento aconteça>, ENTÃO <executar alguma ação>.”
Na prática:
“DADO que a aba de movimentações seja iniciada ENTÃO montar uma estrutura contendo o histórico de interações do processo.

1. A timeline será montada por ‘itens da lista de movimentação’
2. Um ‘Item da lista de movimentação’ será montado com as seguintes informações:
   1. Os eventos relacionados a entrega da petição, seja ela inicial, incidental ou avulsa
   2. Os dados de ‘Documentos’ e ‘Movimentações’ retornados do endpoint ‘Consultar processo’
   3. Os ‘itens da lista de movimentação’ devem ser, por padrão, organizados e apresentados do mais recente para o mais antigo.”

Tarefa #

Uma tarefa é a menor unidade de uma história de usuário que represente uma atividade concreta, finita e mensurável a ser executada. Uma história terá uma ou mais tarefas necessárias a sua finalização. Além disso, todas as tarefas necessárias para a conclusão da história devem estar listadas na própria história.

De maneira semelhante ao que acontece nas histórias, o time pode usar o acrônico SMART para quebrar as histórias em tarefas:

• Específica (Specific): toda tarefa deve ter uma responsabilidade única, ser coesa com seu objetivo e entregar apenas uma parte de uma história de usuário, e todas juntas contribuem para atingir os critérios de aceitação da história de usuário.
• Mensurável (Measurable): não importa a unidade de medida, embora o ágil encoraje muito mais o uso de pontos do que de horas. O importante é medir, seguindo os critérios técnicos do time, para garantir a entrega no timebox do Sprint.
• Alcançável (Achievable): as tarefas devem ser alcançáveis pelos seus responsáveis, com as competências e recursos necessários para conseguir entregá-la.
• Relevante (Relevant): as tarefas devem agregar valor à história e tem que ser explicáveis e justificáveis. Elas são quebradas para auxiliar os desenvolvedores a organizarem seu trabalho. Se a tarefa não agrega valor, então ela é irrelevante para a história e, portanto, não deve ser feita.
• Temporal (Time-Boxed): as tarefas precisam ter um tempo definido para serem concluídas, delimitadas a um timebox específico. Não é necessário fazer uma estimativa formal em horas ou dias, mas deve haver uma expectativa de conclusão.

Épico #

Tecnicamente, um Épico é uma grande Estória de usuário – tão grande que levaria um tempo demasiadamente longo para que se encaixe no acrônimo INVEST.

Para o presente modelo de implementação do framework Scrum, consideramos o Épico como um conjunto de histórias de usuário suficientes para justificar o lançamento de uma nova versão do produto. Dessa forma, um Épico deverá incluir:

• todas as histórias de usuário necessárias para o lançamento da nova versão do produto;
• um item de backlog específico para registrar as tarefas de deploy da nova versão.

O Épico deve conter pelo menos as seguintes informações:

• Data da Entrega, para informar a data de entrega das histórias para o cliente
• Versão, para informar a versão da release, a tag a ser entregue

Após a entrega de um Épico é conveniente realizar uma reunião de retrospectiva para que o time Kanban possa avaliar em conjunto o andamento dos trabalhos, apontar boas práticas e propor melhorias para a execução do projeto.

Execução do Projeto #

Ferramenta de Gestão #

Foi escolhida a ferramenta Taiga para a gestão de projetos, que pode ser acessada pela URL https://scrum.modal.org.br/.

O Taiga trabalha tanto com o framework Scrum quanto o Kanban, sendo simples, de fácil aprendizado e apresentando todos os recursos e funcionalidades essenciais.

Deve ser concedido acesso ao Taiga para o cliente, com perfil que permita:

• ler e comentar histórias de usuários, tarefas e épicos
• criar problemas (issues)
• ler e comentar as páginas da Wiki do próprio Taiga
• outras permissões podem ser concedidas conforme as necessidades do projeto e o perfil do cliente

Colunas das histórias #

As colunas das histórias representam a situação de cada história, marcando a sua etapa no ciclo de execução dentro do Sprint.

Novo #

• Esta coluna tem somente a descrição da história de usuário.
• A responsabilidade em criar um item de backlog é de qualquer integrante do projeto, porém as histórias de usuário são do Product Owner (PO).

Preparando #

• Nesta coluna é puxada a história para preparação.
• No caso de História de usuário:
  • A responsabilidade pela preparação é do PO
  • O time DEV e o Cliente participa da preparação entendendo e direcionando os critérios para que a história de usuário seja clara, consistente e testável.
• A responsabilidade em mover um item de backlog para esta coluna é de qualquer integrante do projeto, porém as histórias de usuário são do PO.

Preparado #

• Esta coluna representa que a história de usuário foi preparada e validada pelo cliente.
• No caso de história de usuário, representa que os Critérios de Aceite foram definidos, refinados e priorizados pelo PO.
• Nesta coluna, na reunião de planejamento da Sprint, a história é dividida em tarefas e pontuada pelo time DEV.
• A responsabilidade em mover um item de backlog para esta coluna é de qualquer integrante do projeto, porém as histórias de usuário são do PO.

Desenvolvendo #

• Nesta coluna é puxada a história de usuário refinada, pontuada e que faz parte de uma Sprint.
• O desenvolvedor pode criar tarefas, além daquelas já definidas na reunião de planejamento da Sprint.
• A responsabilidade em mover a história para esta coluna é do desenvolvedor, o primeiro que iniciar o desenvolvimento.

Desenvolvido #

• A história de usuário nesta coluna representa que o desenvolvimento foi concluído.
• Nesta coluna, os testes internos e rotineiros podem ser executados antes da publicação no ambiente de homologação.
• Poderão ser abertos problemas para que o(s) desenvolvedor(es) que implementou(ram) a história possa(m) corrigi-los.
• A responsabilidade em mover a história de usuário para esta coluna é do desenvolvedor, o último a concluir o desenvolvimento.

Publicando #

• Nesta coluna é puxada a história de usuário que faz parte de uma entrega e será publicada no ambiente de homologação.
• O Scrum Master (SM) deve criar um Épico para representar a entrega e anexar todas as histórias que farão parte dele.
• A responsabilidade em mover a história de usuário para esta coluna é do desenvolvedor principal.

Publicado #

• A história de usuário nesta coluna representa que ela foi disponibilizada no ambiente de homologação e está pronta para o Teste de Homologação.
• O Épico referente à entrega deve ser atualizado com as seguintes informações:
  • Data da Entrega, para informar a data de entrega das histórias para o cliente
  • Versão, para informar a versão da release, a tag a ser entregue
• A responsabilidade em mover a história de usuário para esta coluna é do Scrum Master.

Homologando #

• Nesta coluna é puxada a história de usuário para o teste de homologação do cliente.
• Poderão ser abertos problemas para que o desenvolvedor que implementou a história possa corrigi-los.
• Uma vez a história esteja homologada, sem problemas abertos, o cliente deve movê-la para a coluna Pronto.
• A responsabilidade em mover a história de usuário para esta coluna é do PO.

Pronto #

• Esta coluna representa que a história de usuário foi aceita e homologada pelo cliente.
• No caso de história de usuário, representa que os critérios de aceite da história foram atendidos e homologados pelo cliente.
• A responsabilidade em mover o item de backlog para esta coluna é do cliente, porém as histórias de usuário são do PO.

Produção #

• Esta coluna representa que a história de usuário deve subir para o ambiente de produção.
• É responsabilidade do Cliente e/ou do SM mover a história para essa coluna.
• Cabe ao DEV principal tomar as providências para que o item seja disponibilizado para produção.

Fluxo do ciclo de desenvolvimento da História #

Fluxo do ciclo de preparação de outros artefatos #

Colunas das Tarefas #

As colunas das tarefas representam a situação de cada tarefa, marcando a sua etapa no ciclo de desenvolvimento da história.

Novo #

A tarefa nesta coluna representa que a sua execução ainda não foi iniciada.

Em Andamento #

A tarefa nesta coluna representa que a sua execução está sendo realizada.

Fechado #

A tarefa nesta coluna representa que a sua execução foi concluída.

Precisa de Informação #

A tarefa nesta coluna representa que existe algum impedimento para a continuidade da sua execução.

Fluxo do ciclo de vida de tarefas #

Problemas #

Um “problema”, no contexto da gestão de projetos, é uma funcionalidade, recurso ou outro aspecto de uma história que não cumpre um ou mais critérios de aceite.

Caso um problema seja identificado durante o desenvolvimento de uma tarefa, ele deve ser tratado e resolvido diretamente pelo desenvolvedor da tarefa, de maneira imediata.

No entanto, problemas também são identificados:

1. Após a mudança da coluna da história de Desenvolvendo para Desenvolvido, quando devem ser realizados os Testes pelo time Scrum antes de liberar a história para homologação do cliente;
2. Enquanto estiver sendo homologada pelo cliente, após a conclusão dos testes do time Scrum.

Três tipos de problemas devem ser relatados assim que identificados durante a fase de testes internos e/ou pelo cliente, durante a homologação:

1. Erro (Bug) – inconsistência, erro, não aderência ao escopo da história.
2. Pergunta – utilizada pelo Desenvolvedor quando um problema está sem evidência ou não está claro o entendimento.
3. Melhoria – um novo aspecto, classificado e entendido como uma evolução da história e que pode provocar duas situações:
   • Faz parte do escopo, então será priorizado o desenvolvimento nas Sprints seguintes.
   • Não faz parte do escopo, então será levado para a gestão do contrato.

Diretrizes na abertura dos problemas: #

• Problemas abertos nos testes de homologação do cliente: Incluir tag “homologação”
• Problemas abertos nos testes rotineiros da equipe Scrum: incluir a tag “rotineiro”
• Incluir tag com o número da história com o símbolo #. Exemplo: #25
• Incluir tag com o nome da Sprint na qual a história foi desenvolvida. Exemplo: “sprint 1”
• Se o problema foi fechado mas, por algum motivo, não foi resolvido, é preciso abrir outro.

Uma vez aberto um problema, idealmente o mesmo deve ser resolvido pelo desenvolvedor imediatamente – quanto mais tempo demorar o início da solução do problema, maior será a dificuldade para a sua solução!

Fluxo do ciclo de vida dos problemas do tipo BUG #

Fluxo do ciclo de vida dos problemas do tipo PERGUNTA #

Fluxo do ciclo de vida dos problemas do tipo MELHORIA #

Considerações finais #

O framework Scrum traz muitos benefícios para a execução de projetos de diversos tipos, sendo mais comumente usado no desenvolvimento de softwares.

Sua aplicação pode (e deve) ser ponderada com a realidade do projeto e a cultura do cliente, sendo possível adaptar alguns de seus aspectos para melhorar o andamento dos trabalhos. Entretanto, recomenda-se fortemente que sejam mantidos os seguintes princípios fundamentais:

1. Rituais de reuniões do Scrum (reuniões diárias, de planejamento, de revisão e retrospectiva da Sprint);
2. Sprints com o mesmo timebox, ou seja, a mesma duração, para viabilizar o acompanhamento do ritmo da equipe;
3. Evitar com todas as forças que uma mesma equipe participe de mais de um projeto simultaneamente!