Ir para o conteúdo principal

Framework Scrum

A SETIC utiliza o framework SCRUM para suportar a área de desenvolvimento de software que atualmente é responsabilidade da Coordenação de Desenvolvimento de Software – CODE.

Ele é baseado no conhecimento adquirido e na tomada de decisões com base no que é observado. Ele segue uma abordagem iterativa e incremental para garantir a previsibilidade e controle de riscos.

O Time Scrum é formado por três papéis:

·         Product Owner - É responsável por maximizar o valor do produto resultante do trabalho do Scrum Team, suas principais atividades:

o   Desenvolver e comunicar explicitamente a meta do produto;

o   Criar e comunicar claramente os itens do Product Backlog;

o   Ordenar os itens do Product Backlog;

o   Garantir que o Product Backlog seja transparente, visível e compreensível.

·         Scrum Master - é responsável por estabelecer o Scrum conforme definido no Guia do Scrum. Eles fazem isso ajudando todos a entender a teoria e a prática do Scrum, tanto no Time Scrum quanto na organização, suas principais atividades:

o   Treinar os membros do time em autogerenciamento e cross-funcionalidade;

o   Ajudar o Time Scrum a se concentrar na criação de incrementos de alto valor que atendem à Definição de Pronto;

o   Provocando a remoção de impedimentos ao progresso do Time Scrum;

o   Ajudar a encontrar técnicas para a definição eficaz de meta do Produto e gerenciamento do Product Backlog;

o   Liderar, treinar e orientar a organização na adoção do Scrum;

o   Planejar e aconselhar implementações de Scrum dentro da organização;

o   Ajudar os funcionários e os stakeholders a compreender e aplicar uma abordagem empírica para trabalhos complexos;

·         Developer – é responsável por desenvolver um incremento utilizável a cada sprint, suas principais atividades:

o   Criar um plano para a Sprint, o Sprint Backlog;

o   Introduzir gradualmente qualidade aderindo a uma Definição de Pronto; 

o   Adaptar seu plano a cada dia em direção à meta da Sprint;

o   Responsabilizar-se mutuamente como profissionais.

Cinco eventos (reuniões) garantem que todo o processo seja transparente, inspecionável e adaptado se necessário, são eles:

·         Sprint – é o tempo que o Time Scrum desenvolverá um incremento utilizável;

·         Sprint Planning – é o planejamento das atividades que serão desenvolvidas dentro de uma sprint;

·         Daily Scrum – Reunião diário entre os Developer para alinhamento e foco no que precisa ser entregue;

·         Sprint Review – Fornecer aos interessados pelo produto uma oportunidade de inspeção para que sejam determinadas adaptações caso necessário.

·         Sprint Retrospectiva – Reunião entre o Time Scrum para corrigir os processos e verificar maneiras de aumentar a qualidade e eficácia.

Para entender o framework por completo, sugestionamos a leitura do Scrum Guide: https://scrumguides.org/download.html.

 

 

O SCRUM 

 

O SCRUM é propositalmente incompleto para que cada organização o adapte (desde que siga sua estrutura principal da forma indicada) da melhor maneira que atenda ao contexto atual inclusive na utilização de outras técnicas ou métodos.

Com isso a CODE também faz uso do Kanban Board para deixar visível o trabalho em andamento atualmente através da ferramenta JIRA da Atlassian e para estimar o trabalho a ser desenvolvido, faz uso dos Story Points, seguindo os valores da tabela de Fibonacci.

Explicando o Story Points, veja esta imagem:


Qual o peso deste elefante?

Fica difícil de responder, certo?

E agora, qual elefante é mais pesado? O Azul ou o verde?


A princípio responde-se que é o azul, visto que ele é visivelmente maior que o verde, certo?

Mas e se eu falar que o elefante verde é de aço e o azul é de isopor? Sua resposta estaria incorreta.

Os Story points nos ajudam neste quesito, na indagação do que precisa ser feito, como é feito, do que é feito, por quem é feito etc.  E nós na CODE levamos em consideração a complexidade, esforço e incerteza quando vamos mensurar um trabalho a ser desenvolvido, e para gerar informação seguimos a sequência de Fibonacci (1, 2, 3, 5, 8 e 13) dando “valor” ao nosso trabalho. Como isso ocorre: No dia da Planning o Product Owner lista o que precisa ser trabalhado dentro da sprint e os desenvolvedores vão mensurar o trabalho seguindo o conceito complexidade, esforço e incerteza, nossos times atualmente tem uma média de 4 desenvolvedores e eles votam de forma anônima, qual o valor do trabalho na visão dele e depois é comparado com os demais, para definição do valor final, cada time tem autonomia para definir sua regra, mas no geral seguimos duas, Ex:1 segue a pontuação da maioria ou Ex2. pegam a pontuação que fica entre as conflitantes.

EX1:


 

EX2: