Ir para o conteúdo principal

Implantação da Metodologia Scrum

1. O que é Scrum

 

O Scrum é uma metodologia ágil para gestão de planejamento de projetos de software. Os projetos são divididos em ciclos que chamamos de sprint, que representa a timebox das atividades que precisam ser executadas. 

Seu principal objetivo, é entregar um software com a maior qualidade possível dentro de séries, compostas por pequenos intervalos de tempo definidos (sprints), que na maioria das implementações tem aproximadamente um mês de duração. 

 

image.png

 

2. Composição (Atores) 

 

Os integrantes do processo, deverão assumir os seguintes papeis:

2.1. Scrum Master

É o responsável pela realização das tarefas (valores e práticas) e pelo sucesso direto do Scrum. Trabalha constantemente para reduzir a não conformidade do produto entregue ao cliente, sendo que isto pode ser feito através de rápidas respostas aos prováveis impedimentos que poderão surgir durante a execução do projeto. É considerado também, como um interlocutor entre a tecnologia e os negócios, e deve realizar as seguintes atividades: 

 

  • organizar as reuniões diárias; 

  • representar o gerente do projeto e o técnico; 

  • gerenciar todo processo Scrum na organização; 

  • remover os impedimentos do projeto. 

 

2.2. Product Owner 

É representada por uma pessoa e não um comitê, que além de defender os interesses do negócio tem como objetivo manter e priorizar o desenvolvimento os itens do Product Backlog. Desempenha o papel formal para assumir as responsabilidades do projeto, sendo responsável pela liberação e escolha dos itens que passarão à outra fase (conhecida como Sprint Backlog) para o desenvolvimento do produto de software. 

 

2.3. Equipe Scrum 

É responsável pelas ações para atingir os objetivos de cada Sprint, através de encontros com o Scrum Master. Determina por exemplo, a criação do Sprint Backlog e revisa os itens da lista do Product Backlog verificando os impedimentos que precisam ser retirados para o sucesso do projeto. Sua composição será: Gerente de Projeto, Analista de Teste e Analista de Desenvolvimento. 

 

2.3.1. Gerente de Projeto 

Responsável pela definição de papéis, atribui demandas, acompanha e documenta o andamento da sua equipe através de ferramentas e técnicas apuradas, administrando os custos e integrando os colaboradores para trabalharem juntas por um só objetivo. 

 

2.3.2. Analista de Teste 

Responsável por identificar e definir os testes exigidos, monitorar o processo de teste em detalhes e os resultados em cada ciclo de teste avaliando a qualidade geral. Seu objetivo é garantir que o produto seja entregue respeitando as qualidades pretendidas pelo cliente. 

 

2.3.3. Analista de Desenvolvimento 

Responsável por executar as demandas, desenvolvendo, implantando e mantendo sistemas de acordo com metodologia e técnicas adequadas, visando atender aos objetivos estabelecidos quanto à qualidade, custos, prazos e benefícios. 

 

3. Ciclo de vida

 

O ciclo de vida de cada sprint será de duas semanas, com objetivo de liberar a release somente das demandas que foram incluídas. Caso haja uma demanda prioritária, onde deverá ser liberada em uma release no meio do ciclo da sprint, o Gerente ficará responsável em alinhar com o Scrum Master para escalar somente esta demanda na frente. 

 

4. Prática (Fluxo do Scrum) 

 

O método Scrum não requer ou fornece qualquer método específico para desenvolvimento de software, apenas estabelece conjuntos de regras e práticas gerenciais que devem ser adotadas para o sucesso de um projeto. A seguir, um detalhamento das seguintes práticas adotadas pelo método Scrum que deverá ser implementada. 

 

4.1. Reunião Diária (Daily Scrum) 

As do Scrum são realizadas, na maioria das vezes, diariamente ou em dias alternados, com duração de aproximadamente quinze minutos, e tempo limite de no máximo trinta minutos. Este tempo alocado para as reuniões possibilita a identificação dos obstáculos ou impedimentos ao projeto. Essas reuniões não objetivam a resolução dos problemas, pois os mesmos são tratados a posterior com somente efetiva participação dos stakeholders no problema. 

 

Rotineiramente, o Scrum Master durante a reunião, levanta três questões para cada membro da equipe: 

  • O que foi finalizado desde a última reunião do grupo? O Scrum Master registra quais tarefas foram completadas e quais ainda estão pendentes. 
  • Quais foram as dificuldades encontradas durante o trabalho? O Scrum Master registra todas as dificuldades encontradas para posteriormente encontrar uma maneira de resolvê-las. 
  • Quais são as atividades específicas que a pessoa planeja finalizar para o próximo encontro? O Scrum Master ajuda os integrantes da equipe a escolher as tarefas mais importantes. Devido ao curto espaço de tempo, em média 24 horas, as tarefas são geralmente pequenas. 

A reunião realizada pelo grupo tem vários objetivos sendo que a maior parte dos esforços está concentrada no Product Backlog. Cada item da lista que foi trabalhado, automaticamente é retirado da lista, ou seja, quanto menos itens na lista, melhor para o Scrum Master, por isso, existe uma grande preocupação do Scrum Master em concentrar o trabalho nas tarefas mais importantes, que reduzirão o Product Backlog, proporcionando um maior progresso para a equipe. A reunião também possibilita que todas as pessoas fiquem informadas sobre o progresso e as dificuldades encontradas. 

 

4.2. Reunião de Sprint (Sprint Review Meeting) 

No último dia do Sprint, a Equipe Scrum e o Scrum Master apresentam os resultados do incremento numa reunião com o Product Owner, com duração de aproximada de 4 a 8 horas, que posteriormente, analisarão estes resultados decidindo sobre as novas atividades que poderão integrar o Product Backlog. Ressalta-se que o Scrum tem como premissa básica não exigir todos os pré-requisitos logo no início do projeto, pois estes são “descobertos” na medida em que o projeto evolui. 

 

5. Aplicação

 

A ferramenta que iremos utilizar na metodologia será o Gitlab onde os fluxos dos processos serão acompanhados através dos painéis de cada projeto. As atividades que serão executas será pela abertura das demandas (issues) que ficam armazenadas em cada projeto disponibilizadas no Gitlab. O personagem responsável para a abertura das demandas será o Analista de Teste que foi pré-definido pelo Scrum Master. 

 

6. Fluxo do Processo
 

Cada projeto aplicado no desenvolvimento terá a visão geral do painel com ciclo de vida da sprint no período de duas semanas com as seguintes etapas:  

 

  • 1 Backlog - Será preenchido com todas as demandas internas e externas abertas pelo Analista de Teste (receberá a etiqueta aberto). 

  • 2 Sprint - Terá todas demandas que fará parte do ciclo de vida da sprint no período de duas semanas (exemplo 01/02 a 15/02). 

  • 3 Desenvolvimento - São todas as demandas que estão sendo desenvolvida pelos Analista de Desenvolvimento. 

  • 4 Entregue - São todas as demandas que foram desenvolvidas pelos Analista de Desenvolvimento, que terão que ser analisadas pelo Gerente de Projeto. 

  • 5 Teste - São todas as demandas que deverão ser testadas pelo Analista de Teste. 

  • 6 Encerrado - São todas as demandas que foram aprovadas para a liberação de versão. 

  • 7 Fechado - São todas as demandas que foram definitivamente concluídas na versão liberada. 

 

Todas as demandas serão etiquetadas com suas prioridades, pesos de recursos, módulos envolvidos, e versão (se houver) e situação com objetivo seguir todo o processo do ciclo de vida da sprint. 

 

6.1. Etiquetas de Prioridades 

  • Prioridade 1 - São demandas emergenciais (estimado 72 horas). 

  • Prioridade 2 - São demandas que requerem uma atenção, pois podem gerar uma confusão no processo de trabalho ou valores inexato (estimado 7 dias). 

  • Prioridade 3 - São anomalias e adequações estéticas do sistema (estimado 30 dias). 

 

6.2. Peso de Recursos 

  • Peso 1São demandas que exijam a implementação de um recurso ou resultam em uma melhoria na experiência do usuário, onde não exija construção ou alteração do modelo de dados ou comunicação com sistemas terceiros (estimado 24 horas/componente/modulo)

  • Peso 2 - São demandas que exijam a implementação de um recurso ou resultam em uma melhoria na experiência do usuário com necessidade de construção ou alteração do modelo de dados (estimativa 48 horas/componente/modulo). 

  • Peso 3 - São demandas que exijam a implementação de um recurso ou resultam em uma melhoria na experiência do usuário com necessidade de comunicação com sistemas terceiros exigindo obtenção e a análise da documentação da integração compreendendo a formulação da saída de dados (estimativa 48 horas/endpoint/componente/modulo). 

  • Peso 4 - São demandas que exijam a implementação de um recurso ou resultam em uma melhoria na experiência do usuário com necessidade de comunicação com sistemas terceiros exigindo obtenção e a análise da documentação da integração compreendendo a formulação da saída de dados com necessidade de construção ou alteração do modelo de dados (estimativa 48 horas/endpoint/componente/modulo). 

 

6.3. Classificação de Situação 

  • Aberto - São todas as demandas abertas pelo Analista de Teste das demandas internas e externas. Deveram estar sendo preenchidas no quadro da Backlog. 

  • Análise - São todas as demandas que foram abertas, mas requer uma análise mais apurada. 

  • Execução - São todas as demandas que estiverem sendo executadas pelo Analista de Desenvolvimento. 

  • Revisão - Revisar o que foi desenvolvido pelo analista de desenvolvimento, caso não tenha atendido o que a solicitação das demandas.  O Analista de Teste deverá retornar para o quadro de desenvolvimento. 

  • Pausado - Pausar alguma demanda por falta de alguma informação ou precisa de uma análise mais complexa. Deverá retornar para o quadro de backlog com a etiqueta de pausado. 

  • Concluído - São todas as demandas que estiverem prontas para ser compilada e enviada para homologação. 

  • Homologação - São todas as demandas que foram compiladas e estão para analista de teste fazer sua análise, podendo ser aprovada ou rejeitada. 

  • Duplicado - São as demandas que já foram cadastradas, mas por não conferir acabaram registrando a mesma demanda. 

  • Improcedente - São as demandas que foram analisadas, mas que não foram aprovadas. 

  • Finalizado - São as demandas que foram aprovadas pelo Analista de Teste, prontas para publicação. 

 

Resultado 

 O resultado esperado dos projetos ao aplicando o Scrum são: 

  •  Equipe Comprometida - Todos irão participar ativamente em todas as atividades aumentando o nível de comprometimento e motivação.  
  • Melhor Visualização - Os projetos passam ser mais acessível a toda a equipe. 

  • Redução de Falhas - Todos os envolvidos passam a trabalhar detalhadamente a cada etapa do projeto, por isso é mais fácil detectar possíveis problemas e corrigi-los rapidamente. 

  • Flexibilidade em alterar Prioridades – A equipe consegue realizar alterações necessárias nas prioridades e sequência de atividades.