Aplicação de Scrum em Ambiente de
Desenvolvimento de Software
Educativo
Michele de Vasconcelos Leitão
Orientadora: Cristine Gusmão
Sumário
Motivação
Caso de Estudo: Ambiente
Metas
Metodologias Ágeis
Caso de Estudo: Scrum
Caso de Estudo: Resultados






2
eComp - POLI - UPE
Motivação
Aplicação de Scrum em
Ambiente de Desenvolvimento de Software Educativo
3
eComp - POLI - UPE
Motivação
Software nos negócios
Falta de gerenciamento nos processos:





4
Atrasos na entrega do projeto
Produtos de baixa qualidade
Aumento significativo dos custos
eComp - POLI - UPE
Motivação
Emprego dos métodos tradicionais utilizados no
desenvolvimento
Os métodos ágeis oferecem respostas rápidas às novas
exigências de desenvolvimento:




requisitos mutáveis e não totalmente esclarecidos; e
entrega do produto com valor tangível.
Dificuldades na implantação de métodos de
desenvolvimento:



5
característica comportamental: a resistência à mudança;
queda inicial na produtividade.
eComp - POLI - UPE
Caso de Estudo:
Ambiente
Aplicação de Scrum em
Ambiente de Desenvolvimento de Software Educativo
6
eComp - POLI - UPE
Caracterização do Ambiente
Processo de Desenvolvimento






Desenvolvimento de softwares educacionais
Grupos de equipes responsáveis por cada matéria
São produzidas em média 3 aulas por mês, por equipe
Não há uso de qualquer ferramenta ou metodologia
Direcionada individualmente para os coordenadores de cada
equipe




7
definição da distribuição e alocação de tarefas
definição e seleção de competências
definição da matriz de responsabilidades e canais de comunicação
geração dos artefatos durante o desenvolvimento
eComp - POLI - UPE
Impactos
Descentralização de informação
Responsabilidade de geração de artefatos para a
coordenação
Instabilidade no relacionamento da equipe:






8
Desmotivação da equipe, por não se sentir “parte do
processo”;
Não reconhecimento da hierarquia do coordenador pela
equipe;
Forte dependência da equipe nas direções da coordenação.
eComp - POLI - UPE
Metas
Aplicação de Scrum em
Ambiente de Desenvolvimento de Software Educativo
9
eComp - POLI - UPE
Metas

Metas específicas:



adaptar e implantar o método escolhido;
testar a eficiência, no que diz respeito a entrega do produto de
qualidade e em tempo hábil;
projetar melhorias no ambiente de desenvolvimento:



10
comunicação direta e sem falhas;
interatividade, independência e transparência na tomada de decisões
entre equipe e gerência;
otimização e homogeneidade do tempo de desenvolvimento da
equipe.
eComp - POLI - UPE
Metodologias Ágeis
Aplicação de Scrum em
Ambiente de Desenvolvimento de Software Educativo
11
eComp - POLI - UPE
Metodologia Ágeis

Desenvolvedores e consultores de software se juntaram
para compartilhar valores e princípios que eram utilizados
em suas práticas
 Agile Software Development Alliance
12
eComp - POLI - UPE
Manifesto Ágil

Princípios básicos de métodos ágeis:
 Honestidade ao código de
trabalho;
 Eficácia das pessoas que trabalham
em conjunto; e
 Foco no trabalho em equipe.

Características do grupo de desenvolvimento:
 Bem informado
 Competente
 Autorizado a considerar o eventual ajuste durante o processo
de ciclo de vida do desenvolvimento
13
eComp - POLI - UPE
Abordagens Ágeis - XP

XP – EXtreme Programming



Crystal family of methodologies




Voltado para pequenas e médias equipes
Ambiente físico é fator crucial
Normas de política podem ser substituídas por práticas equivalentes
de outras metodologias.
Limitações de espaço físico e horário de trabalho são impeditivos
Incrementos possuem menor periodicidade
Scrum


14
Possui muitas das características do XP, exceto restrições quanto à
localização geográfica da equipe.
Melhor aplicada com equipes ainda menores que o delimitado pelo
XP e Crystal.
eComp - POLI - UPE
Caso de Estudo:
Scrum
Aplicação de Scrum em
Ambiente de Desenvolvimento de Software Educativo
15
eComp - POLI - UPE
Scrum

As primeiras referências na literatura ao
termo “Scrum”


O termo “Scrum” deriva de uma estratégia
no jogo de rúgbi


Artigo de Takeuchi e Nonaka: The New Product
Development Game [1986]
Introduzido para definir práticas adaptativas
utilizadas em times auto-gerenciáveis.
Formalizado por Jeff Sutherland e Ken
Schwaber

16
Artigo The Scrum Development Process [1994].
eComp - POLI - UPE
Scrum - Pilares




Transparência
Inspeção
Adaptação
Pontos de inspeção e adaptação em
Scrum:



17
Daily Scrum Meeting
Sprint Planning Meeting e Sprint Review
Sprint Retrospective
eComp - POLI - UPE
Scrum - Framework

Papéis




Artefatos





Product Owner
Scrum Master
Scrum Team
Product Backlog
Sprint Backlog
Scrum Board
Burndown Chart
Etapas





18
Release Planning Meeting
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Sprint Retrospective
eComp - POLI - UPE
Scrum - Papéis e Responsabilidades

Pigs x Chickens

19
Chickens não podem dizer aos pigs como fazer seu trabalho.
eComp - POLI - UPE
Scrum - Papéis e Responsabilidades

Product Owner:




Definir as características do produto e prioridade de
execução dos requisitos;
Gerenciar o ROI, garantindo a lucratividade do
produto ao aceitar/recusar os resultados do trabalho
desenvolvido;
Garantir que os especialistas de domínio estejam
disponíveis para o time.
O Product Owner está representado pela alta
gerência da empresa, que é responsável pelo
contato com o cliente.
20
eComp - POLI - UPE
Scrum - Papéis e Responsabilidades

Scrum Master:





Garantir que o trabalho da equipe seja funcional e
produtivo;
Acompanhar o desenvolvimento;
Remover os impedimentos;
Garantir o uso do Scrum de maneira correta.
O papel do Scrum Master equivale ao do
coordenador de equipe.
21
eComp - POLI - UPE
Scrum - Papéis e Responsabilidades

Scrum Team:




Responsável por atingir juntos os objetivos definidos
em cada sprint;
Selecionar os itens priorizados que irão ser
executados em cada iteração;
Demonstrar o trabalho desenvolvido ao Product
Owner.
A equipe é composta por 6 pessoas, entre
programadores, designers e pedagogo.
22
eComp - POLI - UPE
Scrum - Papéis e Responsabilidades

Correlação com o Ambiente


Aspecto Analisado
Distribuição e alocação de tarefas


e seleção de competências

Definição da matriz de
Ambiente
Executado pelo coordenador de

Scrum

Executado pelo Scrum Master

Inerentes à metodologia,
equipe

responsabilidades e os canais de
Executados pelo coordenador de
equipe
representados por ferramentas
comunicação

Geração dos artefatos
23

Executados sem pré-definição

Definidos pela metodologia,
sob a responsabilidade do
implementados e adaptados pelo
coordenador de equipe
Scrum Master
eComp - POLI - UPE
Scrum - Framework

Papéis




Artefatos





Product Owner
Scrum Master
Scrum Team
Product Backlog
Sprint Backlog
Scrum Board
Burndown Chart
Etapas





24
Release Planning Meeting
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Sprint Retrospective
eComp - POLI - UPE
Scrum - Artefatos e Ferramentas

Product Backlog:



Lista de itens priorizados elencando o que deve ser
desenvolvido na sprint.
Corresponde à matriz de temas de aulas, totais, a serem
produzidas durante toda a duração do projeto.
Sprint Backlog:


25
Lista de tarefas extraídas do Product Backlog, com as quais a
equipe se compromete a fazer durante uma sprint.
É composto pelas aulas propriamente ditas.
eComp - POLI - UPE
Scrum - Artefatos e Ferramentas

Scrum Board





26
Stories: aulas divididas em
páginas.
To Do: tarefas listadas para
cada página por membro.
In Progress: tarefas em
execução.
Impediments: problemas
encontrados no
desenvolvimento.
Meetings: comunicação
interna da equipe.
eComp - POLI - UPE
Scrum - Artefatos e Ferramentas

Método Planning Poker

Montar o Burndown Chart
James Grenning, 2002
 Mike Conh, 2005 - Agile Estimating and Planning
Cada tarefa é discutida de modo sucinto. Cada participante dá
sua nota de complexidade com base na escala definida para
cada tarefa.


27
eComp - POLI - UPE
Scrum - Artefatos e Ferramentas


Escala utilizada no baralho: 1, ½, 2, 3, 5, 8, 13, 21, 40 e 100.
Todas as tarefas listadas na seção To Do são mensuradas, de
forma que somadas preenchem o valor total de pontos no
gráfico.
28
eComp - POLI - UPE
Scrum - Artefatos e Ferramentas

O gráfico Burndown (Burndown
Chart) mostra a correlação entre a
quantidade de trabalho restante e
o progresso das equipes na
redução deste trabalho.

Formas de registrar o
trabalho executado no
gráfico:
por quantidade de
tarefas; e
por pontos de
complexidade dessas
tarefas.


29
eComp - POLI - UPE
Scrum - Artefatos e Ferramentas

Correlação com o Ambiente



Nova realidade na dinâmica de desenvolvimento da empresa: a
geração de artefatos.
Formalizar toda a documentação necessária, sem haver geração de
artefatos em excesso.
Diagramas de estado de cada página da aula em execução na
sprint



30
Elaborados pela coordenação de equipe;
Detalham o fluxo de ocorrência dos eventos e animações definidas
para cada página;
Minimizam a dependência da equipe no coordenador, eliminando as
dúvidas frequentes no roteiro, acelerando o desenvolvimento e
reduzindo o número de manutenções e alterações feitas por página.
eComp - POLI - UPE
Scrum - Framework

Papéis




Artefatos





Product Owner
Scrum Master
Scrum Team
Product Backlog
Sprint Backlog
Scrum Board
Burndown Chart
Etapas





31
Release Planning Meeting
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Sprint Retrospective
eComp - POLI - UPE
Scrum - “Time-Boxes”


Scrum utiliza “caixas de tempo” (time-boxes) para criar
regularidade no processo de desenvolvimento.
Elementos, ou etapas, time-boxed:






32
Release Planning Meeting
Sprint Planning Meeting
Sprint
Daily Scrum Meeting
Sprint Review Meeting
Sprint Retrospective Meeting
eComp - POLI - UPE
Scrum - Etapas da Sprint

Release Planning Meeting


Estabelecer plano e metas que a equipe Scrum e o resto das
organizações possam compreender e se comunicar.
Questões que guiam a reunião:
 “Como podemos transformar essa visão em um produto vencedor
da melhor maneira possível?”
 “Como podemos atender ou exceder a satisfação do cliente e o
Retorno sobre o Investimento?”
33
eComp - POLI - UPE
Scrum - Etapas da Sprint

Sprint Planning Meeting

A iteração é planejada, sendo selecionadas as estórias a serem
implementadas durante a sprint baseando-se num Product Backlog
pré-definido e priorizado.

Sprint Planning 1:



Sprint Planning 2:


34
Decidir o que será feito na sprint.
O Product Owner e o Scrum Master selecionaram as estórias do
cronograma contendo as aulas pré-selecionadas do Product Backlog.
Decidir como serão construídas as funcionalidades selecionadas no
Product Backlog.
A equipe definiu como construir a aula no Sprint Backlog durante a
sprint.
eComp - POLI - UPE
Scrum - Etapas da Sprint

Daily Scrum Meetings






Melhorar a comunicação
Eliminar outras reuniões
Identificar e remover obstáculos ao desenvolvimento
Destacar e promover a rápida tomada de decisões
Melhorar o nível de conhecimento de todos sobre projeto.
Três questões que guiam a reunião:




35
“O que tem realizado desde a última reunião?”
“O que pretende fazer antes da próxima reunião?”
“Quais são os impedimentos para realizar seu trabalho com eficácia?”
Se mostraram as mais complicadas de adaptar, devido às divergências de
horários entre os membros da equipe.
eComp - POLI - UPE
Scrum - Etapas da Sprint

Sprint Review Meeting




36
Ponto de inspeção ao fim de cada iteração.
Mostrar o produto da sprint e servir como estímulo para a
continuação de mais sprints bem sucedidas.
Devido aos pequenos atrasos ocorridos nas iterações e às
interferências do Product Owner, somente uma Sprint Review Meeting
foi realizada, resumindo os release de duas sprints.
A única ressalva da reunião foi a ausência do Product Owner, que
obteve a ata da reunião posteriormente.
eComp - POLI - UPE
Scrum - Etapas da Sprint

Sprint Retrospective

Inspecionar como se desenvolveu a sprint no que diz respeito às
pessoas, relações de processos e ferramentas.

Vantagens
Manter o controle das tarefas a serem feitas, evitando



esquecimento.
Organizar as etapas do desenvolvimento, auxiliando

Prover uma visão do projeto todo para a equipe
inteira.
Alterar as dimensões das áreas de To Do e Done no
Scrum Board.

determinar o início, meio e fim.

Definir um padrão para determinar as dependências
entre as tarefas nos post-its.

Permitir maior flexibilidade nos horários das Daily
Scrum Meetings.
Permitir toda a equipe de ter noção da complexidade

de todas as tarefas.
Inserir uma melhor divisão do desenvolvimento,

permitindo detectar um padrão.
Perceber o andamento do projeto, através do

Burndown Chart.
37
Melhorias
eComp - POLI - UPE
Scrum - Ciclo de Desenvolvimento
38
eComp - POLI - UPE
Scrum - Ciclo de Desenvolvimento

Correlação com o Ambiente


39
Escolha de uma metodologia simples de ser rapidamente
assimilada e aplicada pelos coordenadores.
Devido à sua adaptabilidade, atende essas exigências de
simplicidade e rápida aplicabilidade.
eComp - POLI - UPE
Caso de Estudo:
Resultados
Aplicação de Scrum em
Ambiente de Desenvolvimento de Software Educativo
40
eComp - POLI - UPE
Coleta e Análise de Dados

Análise Comportamental da Equipe

Máximo de aceitação da metodologia:






41
interesse pelas reuniões diárias
participação ativa na Sprint Planning Meeting
comprometimento com as Sprint Review e Sprint Retrospective
Scrum Board: “uma ferramenta que fornece uma visão global do
projeto”.
Planning Poker: cumplicidade gerada entre os membros da
equipe.
O uso do Violet UML ficou restrito ao Scrum Master, tendo a
equipe acesso às imagens geradas dos diagramas de estado,
bem como seus arquivos fonte.
eComp - POLI - UPE
Coleta e Análise de Dados

Análise de Eficiência da Metodologia Scrum no
Desenvolvimento das Tarefas





Otimização e homogeneidade do tempo de desenvolvimento da
equipe.
Critérios os aspectos de prazo, qualidade e custos para a avaliação
da eficiência da metodologia Scrum.
Prazo
 As aulas, a priori desenvolvidas numa média de 3 por semana, passaram a ser
produzidas 2 semanalmente.
Qualidade
 Produto com menos erros, adequado ao uso (cumprindo as requisições de
usabilidade) e satisfazendo os requisitos do Product Owner.
Custos
 Aspectos:
 de tempo de produção; e
 de aquisição de ferramentas.
42
eComp - POLI - UPE
Coleta e Análise de Dados


Ambiente Pré-Implantação
Hierarquia da equipe composta pelas três instâncias:


alta gerência, coordenador de equipe, equipe.


Papel da alta gerência: gerenciar os coordenadores
Ambiente Pós-Implantação
Hierarquia da equipe composta pelas três instâncias:
Product Owner, Scrum Master e Scrum Team.

Papel do Product Owner: colaborar com Scrum Master
de equipe e contatar os clientes. A alta gerência não
e equipe na seleção e manutenção das prioridades de
participa do desenvolvimento em nenhuma etapa.
acordo com o valor de negócio da empresa.
Papel do coordenador de equipe: líder. Responsável

Papel do Scrum Master: facilitador. É responsável por
por guiar a equipe para obter resultados de acordo
remover os impedimentos da equipe no processo de
com suas próprias definições do produto e premissa
desenvolvimento, não sendo responsável por definir
básicas determinadas pela empresa. Responsável
esse processo, mas por assegurar que a metodologia
por remover as dúvidas frequentes da equipe quanto
Scrum seja seguida quanto às etapas, aos artefatos e
ao processo de desenvolvimento, visto que este é
papéis.
definido pela experiência do coordenador.
43
eComp - POLI - UPE
Coleta e Análise de Dados



Ambiente Pré-Implantação
Papel da equipe: desenvolver os objetos de


Papel do Scrum Team: É responsável por ser auto-
aprendizagem de acordo com a documentação de
organizada e por selecionar os itens priorizados que
roteiro gerada e as instruções do coordenador e
irão ser executados em cada sprint, com total
reportar todas as dúvidas e problemas ao
liberdade e comprometimento para desenvolver os
coordenador, sempre que surgirem. Possui total
objetos de aprendizagem de acordo com as etapas
dependência do coordenador para sua organização.
definidas pela metodologia Scrum.
Processo de desenvolvimento: iterações sem etapas

definidas ou delimitadas.

Ambiente Pós-Implantação
Ciclo de desenvolvimento: produção do roteiro,
Processo de desenvolvimento: sprints com etapas
pré-definidas e obrigatórias.

Ciclo de desenvolvimento: produção do roteiro,
seguida do desenvolvimento (com testes periódicos,
seguida da Sprint Planning Meeting (para validação do
mas sem padronização) e publicação do objeto de
roteiro com equipe e Product Owner) e do
aprendizagem.
desenvolvimento (com verificações diárias – Daily
Scrum Meetings). O fim do desenvolvimento é
seguido pela execução da Sprint Review (para
validação do Product Owner) e a publicação do objeto
de aprendizagem.
44
eComp - POLI - UPE
Conclusão e Trabalhos Futuros

Falta de gerenciamento nos processos


Justifica a necessidade da adoção de processos que utilizem
práticas ágeis.
Metodologia ágil Scrum: adequada para o uso em
ambientes de desenvolvimento de softwares educativos


45
Sua aplicação engloba todas as etapas do desenvolvimento,
através de pequenas e médias adaptações.
Remove a obrigatoriedade de geração de vasta documentação.
eComp - POLI - UPE
Conclusão e Trabalhos Futuros


As etapas definidas fornecem importantes dados relativos à
produtividade das equipes e são importantes elementos na
construção de um processo adaptativo com constantes
melhorias e foco na comunicação.
Aspecto comportamental:

46
Boa adaptabilidade e aceitação da equipe à metodologia.
eComp - POLI - UPE
Conclusão e Trabalhos Futuros

Dificuldades Encontradas



Daily Scrum Meetings ficaram comprometidas;
Atrasos e interferências causadas pelo Product Owner.
Trabalhos Futuros


47
Implantar o processo de Gerenciamento de Qualidade, no qual
o controle da qualidade seja feito através de avaliação
periódica do desempenho geral do projeto;
Implantar o método em todas as equipes da empresa, de modo
a analisar as outras formas de adaptação da metodologia.
eComp - POLI - UPE
Aplicação de Scrum em Ambiente de
Desenvolvimento de Software
Educativo
Michele de Vasconcelos Leitão
Orientadora: Cristine Gusmão