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:
