ANÁLISE DE SISTEMAS
SCRUM
Ministério da Educação Secretaria de Educação Profissional e Tecnológica Instituto Federal de Educação, Ciência e Tecnologia de São Paulo
Campus Presidente Epitácio
Professora Andrea Padovan Jubileu
HISTÓRIA DO SCRUM
A metodologia SCRUM, como outras metodologias consideradas ágeis, foi fortemente influenciada por boas práticas adotadas pela indústria japonesa. (“HONDA & TOYOTA”).
Em um artigo feito por TAKEUCHI e NONAKA EM 1986 aonde eles descrevem projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados;
HISTÓRIA DO SCRUM
Associaram estas equipes altamente eficazes à formação Scrum do Rugby(Forma de recomeçar o jogo quando acontece uma infração ou quando a bola sai para fora do jogo).
O uso desta terminologia parece adequada porque no Rugby cada time age em conjunto. Cada membro desempenha um papel importante.
Jeff Sutherland vice-presidente de engenharia da
Easel. Percebeu que seu time de software precisava de uma metodologia mais adequada.
Contou com a ajuda de John Scumniolates e Jeff
Mackenna e concebeu, documentou e implementou o
O QUE É O SCRUM
• É um framework simples para gerenciar projetos
complexos;
• Ele é uma metodologia ágil;
• Possui 3 pilares fundamentais:
• Transparência=> dos processos e dos requisitos e
entrega;
• Inspeção=> de tudo que está sendo feito;
• Adaptação=> tanto no processo, quanto no produto
Stakeholders
Os interessados no projeto.
São os que vão utilizar o Sistema; dar suporte; ou que vão ser afetados de alguma forma por ele.
As necessidades dos Stakeholders são expressar por historias de usuário (User Stories).
User Stories
User Stories são similares a casos de uso. Aonde
ambos são usados para organizar requisitos.
Diferença de caso de uso para User Stories
Os casos de uso descrevem ações de interação
seguindo uma narrativa impessoal entre o usuário e o sistema. Já nas User Stories o foco é nos objetivos do usuário e como o sistema alcançara esses objetivos.
Product Owner
Possui o poder total sobre o produto.
Decide quais recursos e funcionalidades, e qual a ordem que será feito.
Responsável por manter a comunicação entre as partes.
Deve colaborar ativamente com o Scrum Master e
Product Owner
Características:
1º Saber como gerenciar com sucesso as expectativas dos stakeholders.
2º Ter uma visão clara e conhecimento do produto.
3º Saber como transformar a visão de um produto em um backlog do produto.
4º Estar disponível para participar ativamente com a equipe.
5º Ser bem organizado. Que consiga manusear múltiplas atividades.
Scrum Master
É responsável por ajudar a todos os envolvidos a
entender e abraçar os valores, princípios e práticas
do Scrum.
Ele age como um técnico, executando a liderança
do processo.
Tem o papel de facilitador. Ele deve ajudar a equipe
a resolver o problema.
Responsável por proteger a equipe contra
interferências externas.
Scrum Master
Assume um papel de liderança na remoção de
impedimentos que podem atrapalhar a
produtividade.
Scrum Master
Características:
1º
Ter um conhecimento aprofundado, na teoria e
na prática.
2º
Excelentes habilidades de líder;
3º
Fortes habilidades organizacional;
4º
Ótimas habilidades de comunicação;
5º
Ótimas habilidades de apresentação;
Time Scrum
No desenvolvimento tradicional de software são
abordados vários tipos de trabalhador, tais
como: arquiteto, programador, testador,
administrador de banco de dados, Designer, e
assim por diante.
Time de Desenvolvimento é a junção de todas
estas pessoas em uma equipe multidisciplinar.
Time Scrum
E responsável pela concepção, construção e
testes de produto.
A ideia principal é que a equipe de
desenvolvimento se auto organiza para
determinar a melhor maneira de realizar o
trabalho para atingir a meta estabelecida pelo
Product Owner.
Time Scrum
Um time de desenvolvimento tem tipicamente
entre 5 a 9 pessoas; e seus membros devem ter
todas as habilidades necessárias para produzir
com qualidade o produto.
Atividades e Artefatos Principais
Visão => o Product Owner tem uma visão do que ele
deve criar para atender aos stakeholders.
Product Backlog => funcionalidades do produto.
É feito a primeira reunião de Planejamento de Sprint, para definir o Sprint Backlog.
Product Backlog
O Product Owner, em conjunto com as demais
partes interessadas no produto, definem os itens
do Product Backlog.
Em seguida, ele garante que os itens do Backlog
sejam colocados na ordem correta(valor, custo,
conhecimento e risco), de modo que os itens de
alto valor, aparecera no topo do Backlog.
Product Backlog
O Product Backlog é um documento que sempre
está evoluindo.
Os itens podem ser adicionado, excluídos e
revisados pelo Product Owner por conta de
mudanças de negócios.
Sprint Planning
O product backlog pode representar muitas semanas ou até meses de trabalho.
Serve para determinar quais itens do Product Backlog é importante para construção do Sprint.
Product Owner, junto com o time de desenvolvimento e ScrumMaster, devem realizar o Sprint Planning
Sprint Planning
Tanto o Product Owner quanto a equipe de desenvolvimento devem chegar um acordo sobre o Objetivo da Sprint.
Tendo o objetivo em mãos deve-se determinar quais itens vão ter maior prioridade no Backlog da sprint.
Sprint Backlog
Uma lista de tarefas que o Scrum Team se compromete a fazer em uma sprint.
A equipe define a quantidades de itens do Product Backlog para o Sprint Backlog.
Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando para refletir que tarefas são
completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. É usado um grafico chamado
Burndown Chart.
Burndown chart – Mede o progresso da sprint e
dá indicativos do processo de trabalho da equipe.
Representa diariamente o processo do trabalho
Sprints
O trabalho é realizado em interações ou Ciclos que dura 2 à 4 semanas chamados de Sprints.
Cada trabalho realizado nas Sprints deve criar algo de valor tangível para o cliente ou usuário.
São timeboxed (duração fixa) para que tenham sempre um início e fim.
Daily Scrum
Todos os dias uma reunião é marcada no mesmo
horário.
Os membros de desenvolvimento devem realizar
uma reunião de duração de 15 minutos ou
Daily Scrum
3 Perguntas básicas da reunião diária:
1º
O que fiz ontem que ajudou o time a atingir a
meta do sprint?
2º
O que vou fazer hoje para ajudar o time a
atingir a meta do sprint?
3º
Existe algum impedimento que não permita a
mim ou ao time atingir a meta do sprint?
Ao término destas perguntas todos conseguem
visualizar como está o desenvolvimento do sprint
em relação à meta.
Sprint Review
O objetivo desta atividade é verificar e adaptar o
produto que está sendo construído.
Está é uma reunião informal.
Apresentação do incremento destina-se a
motivar e obter comentários e promover a
colaboração.
Sprint Retrospective
O objetivo do Sprint Retrospective é verificar
necessidade de adaptação no processo de
trabalho. Diferente do Sprint Review que o
objetivo é buscar necessidade de adaptação no
produto.
Ocorre antes da reunião de planejamento do
próximo Sprint.
Kanban Board
É uma tabela que serve para determinar tarefas
exemplo: para executar, em andamento ou
finalizada.
Kanban permite um controle detalhado de
produção com informações sobre quando, quanto
e o que produzir.
Definição de Pronto
É considerado como resultado do Sprint.
Para saber quando uma finalidade do produto está
concluída é utilizado Definition of Done (DoD).
Este documento consiste em uma lista de todas as
atividades que são necessárias para a entrega do
produto.
O Que é Ganho Com Isso?
O ScrumTeam e os demais stakeholders do
projeto passam a utilizar um vocabulário único,
seguro e irrestrito para a palavra 'Pronto’.
A confiança dos demais stakeholders aumenta
em relação ao ScrumTeam.
Os Releases passam a ser mais previsíveis em
termos de qualidade (Aquele susto ao final do
projeto deixa de existir).
O Que é Ganho Com Isso?
Qualquer impedimento é rapidamente identificado.
Para o Time Scrum “PRONTO” é usado para
quando o trabalho está completo no incremento do
produto.
Referencias.
Disponível em: <http://www.mindmaster.com.br/scrum>. Acesso em 24 de Maio de 2016. Disponível em: <https://www.youtube.com/watch?v=7lhnYbmovb4#t=303.940313 >.
Acesso em 24 de Maio de 2016.
Disponível em: < https://www.scrumalliance.org/>. Acesso em 24 de Maio de 2016. Disponível em: < http://www.significados.com.br/kanban/ >Acesso em 24 de Maio de 2016.
Disponível em: < http://www.mindmaster.com.br/definition-of-done/> Acesso em 24 de Maio de 2016.
Disponível em: < https://www.scrumalliance.org/why-scrum> Acesso em 24 de Maio de 2016.
Disponível em: <https://www.scrumalliance.org/why-scrum/why-use-scrum> Acesso em 24 de Maio de 2016.
Disponível em: <
https://www.youtube.com/watch?v=LKr8-iarpfg&index=2&list=PLqdbJp55yaKkdWjU7HCCXDe-5SlSnVtoj> Acesso em 24 de Maio de 2016.
Referencias.
SCROCCO; JOSÉ, Henrique Teixeira. METODOLOGIA ÁGEIS: Engenharia de Software. 1 ed. São Paulo: érica,2014.
ANDREW, Phan; PHUONG-VAN, Pham. SCRUM EM AÇÃO:
Gerenciamento e Desenvolvimento Ágil de Projeto de Software. 1 ed. São Paulo: Novatec Editora ltda, 2011.
MIKE, Cohn. DESENVOLVIMENTO DE SOFTWARE COM O SCRUM:
Aplicando Métodos Ágeis com Sucesso. 1 ed. São Paulo, 20011.
