1. Somente alunos matriculados no curso devem usá-lo
2. teste
3. Todos os membros são DESENVOLVEDORES
3.1. Não há papéis específicos, como testador ou analista de negócio
4. Scrum é um framework e não uma metodologia
4.1. Indicado para gerenciar desenvolvimento de produtos complexos
4.2. Propositalmente está incompleto, para que se possa empregar vários processos, técnicas e métodos com o framework
4.3. Porém não não é recomendado fazer alterações no vocabulário Scrum ao implantar na organização
5. Times devem ser autogerenciados
6. Responsabilidades no Scrum
6.1. Scrum Team
6.1.1. Os membros são multifuncionais - podem atuar em todas as atividades da sprint
6.1.2. São autogerenciáveis
6.1.2.1. Os membros decidem internamente quem faz o quê, quando e como
6.1.3. São multifuncionais
6.1.3.1. Os membros possuem todas as habilidades necessárias para criar valor a cada Sprint
6.1.4. Tamanho ideal: 10 ou menos pessoas
6.1.5. Inclui também o Product Owner e Scrum Master
6.1.6. O time inteiro é responsável por criar um Incremento valioso e útil a cada Sprint
6.1.6.1. Trabalham em ritmo sustentável
6.1.6.1.1. Horas extras não é uma boa prática
6.1.6.2. Coragem
6.1.6.2.1. Os membros do Scrum Team têm a coragem de, fazer a coisa certa e trabalhar em problemas difíceis
6.1.7. Responsabilidades específicas
6.1.7.1. Developers
6.1.7.1.1. Pessoas comprometidas em criar qualquer aspecto de um Incremento utilizável a cada Sprint.
6.1.7.1.2. Pode existir diferentes habilidades específicas de acordo com o produto que será desenvolvido
6.1.7.1.3. Principais responsabilidades
6.1.7.2. Product Owner
6.1.7.2.1. Pode ser alguém da área de negócio
6.1.7.2.2. Representa clientes e usuários
6.1.7.2.3. É o único dono do backlog do produto
6.1.7.2.4. Deve existir um para cada produto
6.1.7.2.5. Toda a organização deve respeitar suas decisões
6.1.7.2.6. Principais responsabilidades
6.1.7.3. Scrum master
6.1.7.3.1. Estabelece o Scrum conforme definido no Scrum Guide
6.1.7.3.2. Responsável pela eficácia do Scrum Team
6.1.7.3.3. São verdadeiros líderes que servem ao Scrum Team
6.1.7.3.4. Deve existir um para cada time
6.1.7.3.5. É uma posição de gestão
6.1.7.3.6. Principais responsabilidades
7. Determinam as tarefas necessárias para os itens selecionados para a sprint
8. www.tiexames.com.br
8.1. Mapa desenvolvido pela TIEXAMES
8.2. Não há garantia de aprovação no examep apenas decorando este mapa
8.2.1. Não divulgue este material
8.3. Incluímos o essencial para o exame
9. Fundamentos do Scrum
9.1. Emprega abordagem iterativa e incremental
9.1.1. Entregas pequenas e parciais a cada mês, pelo menos
9.1.2. Entrega do maior valor agregado mais cedo
9.1.3. Redução das incertezas por meio de entregas menores e rápidas
9.1.4. Permite a rápida e contínua inspeção
9.1.5. As necessidades do negócio determinam as prioridades do desenvolvimento
9.2. Foca na entrega de valor
9.2.1. O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team
9.3. Não precisam de um gerente de projeto (o Scrum master é um líder-servo e o PO se responsabiliza pelo produto)
9.3.1. Compostas por pessoas comprometidas
9.4. Não há líderes funcionais dentro do time
9.5. Pilares do Scrum
9.5.1. Transparência
9.5.1.1. Informações devem ser visíveis para todos
9.5.1.2. Problemas não podem ser escondidos
9.5.1.3. Informações são entendidas por todos da mesma maneira
9.5.1.4. Estimativas são dadas de acordo com o que cada desenvolvedor realmente acredita
9.5.1.5. Comprometer-se somente com aquilo que se acredita
9.5.2. Inspeção
9.5.2.1. Os artefatos do Scrum e o progresso em direção às metas acordadas devem ser inspecionados com frequência.
9.5.2.2. A inspeção é a base para a adaptação
9.6. Adaptação
9.6.1. Alterações no processo para evitar erros e problemas
9.6.2. Feita pelo Time Scrum
9.6.3. Os eventos do Scrum são aproveitadas para realizar inspeção e adaptação
9.6.4. O ajuste deve ser feito o mais rápido possível para minimizar novos desvios.
9.6.5. Espera-se que um Scrum Team se adapte no momento em que aprende algo novo por meio da inspeção
9.7. Valores do Scrum
9.7.1. Compromisso
9.7.1.1. O Scrum Team se compromete a atingir seus objetivos e suportar uns aos outros
9.7.2. Foco
9.7.2.1. O foco principal do Time Scrum é o trabalho da Sprint para fazer o melhor progresso possível em direção a essas metas.
9.7.3. Abertura
9.7.3.1. O Scrum Team e seus stakeholders são abertos quanto ao trabalho e os desafios
9.7.4. Respeito
9.7.4.1. Os membros do Scrum Team se respeitam quanto a serem pessoas capazes e independentes, e são respeitados como tal pelas pessoas com quem trabalham.
9.8. Scrum é baseado no empirismo e lean thinkin
9.8.1. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base no que é observado.
9.8.2. O lean thinking reduz o desperdício e se concentra no essencial.
10. Eventos no Scrum
10.1. Importante saber
10.1.1. O Scrum master deve garantir a realização de todos os eventos, mas não necessariamente participará de todos; ele não participa da reunião diária que é voltada para os desenvolvedores, mas de todos os outros eventos ele participará
10.1.2. Todos os eventos no Scrum são time-boxed
10.1.3. Todos os eventos são uma oportunidade para inspecionar e adaptar os artefatos do Scrum
10.1.4. O ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade
10.2. Sprint
10.2.1. Duração máxima de um mês
10.2.1.1. A duração pode ser baseada em diversos fatores
10.2.1.1.1. Nível de incerteza da tecnologia a ser usada
10.2.1.1.2. Frequência de alterações no Time Scrum
10.2.1.1.3. Nível de risco aceitável
10.2.1.1.4. Alinhamento com eventos do negócio (releases, por exemplo)
10.2.2. É o momento em que é feito o trabalho para transformar os itens do backlog do produto selecionados em incremento de produto funcionando
10.2.3. Composição
10.2.3.1. A Sprint é um contêiner para todos os outros eventos
10.2.3.2. Dentro de uma sprint ocorrem a reunião de planejamento da sprint, as reuniões diárias, o trabalho de desenvolvimento, uma revisão da sprint e a retrospectiva da sprint
10.2.4. Toda Sprint deve gerar no final um incremento de produto utilizável de acordo com a Definição de Pronto
10.2.5. Não existe sprint 0 no Scrum Guide para planejamento de infraestrutura/arquitetura (isto deve ser feito ao longo das sprints)
10.2.6. Inicia-se junto com a reunião de planejamento da sprint e termina junto com a reunião de retrospectiva
10.2.7. Termina quando sua time-box termina
10.2.7.1. Se sobrar tempo, novos itens do backlog do produto podem ser selecionados e desenvolvidos
10.2.7.2. Os itens que não forem completados podem voltar para o backlog do produto e serão repriorizados pelo dono do produto
10.2.7.3. Uma vez que termina uma sprint, uma nova sprint já é iniciada imediatamente
10.2.8. Mudanças devem ser evitadas quando a sprint está em execução
10.2.9. Somente o Product Owner o pode cancelar uma sprint antes do seu término
10.2.10. Durante a sprint, novas tarefas podem ser identificadas pelos Desenvolvedores para os itens do backlog do produto já selecionados
10.2.11. Itens do backlog da sprint podem ser removidos ou alterados se os Desenvolvedores perceberem que não darão conta de fazer tudo
10.2.11.1. Há necessidade de acordar com o Product Owber o que vai ser removido
10.2.12. Durante a sprint podem ser implementadas melhorias no processo sempre que for necessário
10.3. Planejamento da Sprint
10.3.1. Primeiro evento que ocorre na sprint
10.3.2. Serve para definir O QUE precisa ser feito e COMO deve ser feito
10.3.3. Todos do Time Scrum participam
10.3.4. Time-box de 8 horas para uma sprint de um mês
10.3.4.1. Proporcionalmente menor para sprints menores
10.3.4.2. 2 horas para cada semana de duração da sprint
10.3.5. Trata de 3 tópicos
10.3.5.1. Tópico 1
10.3.5.1.1. Por que esta Sprint é valiosa?
10.3.5.1.2. Define a Meta da Sprint
10.3.5.2. Tópico 2
10.3.5.2.1. O que pode ser feito nesta Sprint?
10.3.5.2.2. Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint atual. O
10.3.5.2.3. Participação do Product Owner é fundamental para definir O QUE fazer
10.3.5.2.4. Somente os Desenvolvedores podem dizer quantos itens são capazes de entregar no final da sprint
10.3.5.3. Tópico 3
10.3.5.3.1. Como o trabalho escolhido será realizado?
10.3.5.3.2. Os Desenvolvedores identificam as tarefas necessárias para os itens do backlog selecionados para a sprint (de acordo com a Definição de Pronto)
10.3.5.3.3. Cabe somente aos Desenvolvedores decompor os itens do Backlog do Produto em trabalhos menores
10.3.5.3.4. É criado o backlog da sprint (uma saída principal da reunião de planejamento)
10.4. Reunião diária
10.4.1. Seu propósito é inspecionar o progresso em direção a Meta da Sprint e adaptar o Sprint Backlog conforme necessário, ajustando o próximo trabalho planejado.
10.4.2. É uma reunião dedicada aos Desenvolvedores
10.4.2.1. A participação de todos os desenvolvedores é obrigatória
10.4.2.2. Desenvolvedores atualizam status das suas atividades antes da reunião
10.4.3. Sempre uma time-box de 15 minutos
10.4.3.1. Independente da duração da sprint
10.4.4. Ocorre todos os dias, exceto quando há reuniões de planejamento, revisão e retrospectiva da sprint
10.4.5. É mantida no mesmo horário e local todos os dias para reduzir a complexidade
10.4.6. A presença do Scrum master e Product Onwer é opcional
10.4.6.1. O Scrum master apenas deve garantir/facilitar a sua realização
10.4.6.2. A condução da reunião é feita pelos Desenvolvedores
10.4.6.3. Outros papéis podem estar presentes, se houver necessidade (faz parte da transparência)
10.5. Revisão da Sprint
10.5.1. Seu propósito é inspecionar o resultado da Sprint e determinar as adaptações futuras.
10.5.2. Ocorre no final de cada Sprint
10.5.3. Maior foco no produto e não no processo
10.5.3.1. O Scrum Team apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é discutido.
10.5.4. Todos do Time Scrum participam
10.5.4.1. Pode ser convidados stakeholders-chave para ajudar na verificação do incremento
10.5.5. Time-box de 4 horas para sprint de um mês
10.5.5.1. Proporcionalmente menor para Sprints menores
10.5.5.2. É uma hora para cada semana de duração da Sprint
10.5.6. Como resultado, o Product Backlog pode ser ajustado para atender a novas oportunidades
10.6. Retrospectiva da Sprint
10.6.1. Seu propósito é planejar maneiras de aumentar a qualidade e a eficácia.
10.6.2. Ocorre logo após a revisão de cada Sprint
10.6.3. Time-box de 3 horas para uma Sprint de um mês
10.6.3.1. Proporcionalmente menor para sprints menores
10.6.4. Todos do Time Scrum participam
10.6.4.1. O Scrum master também é um membro desta reunião devido a ele ser responsável pelo processo Scrum, o qual também é objeto de melhoria
10.6.5. Maior foco na melhoria do processo e não no produto
10.6.5.1. O Scrum Team inspeciona como foi a última Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definição de Pronto.
10.6.5.2. O Scrum Team discute o que deu certo durante a Sprint, quais problemas encontraram e como esses problemas foram (ou não) resolvido
10.6.6. Cada membro do Time Scrum deve falar abertamente sobre o que considera que foi bem e o que deve ser melhorado
10.6.7. O Scrum Team identifica as mudanças mais úteis para melhorar sua eficácia
10.6.7.1. As melhorias mais impactantes são endereçadas o mais rápido possível
10.6.7.2. Essas podem até ser adicionadas ao Sprint Backlog para a próxima Sprint.
11. Artefatos no Scrum
11.1. Importante saber
11.1.1. Os artefatos no Scrum são projetados para maximizar a transparência das principais informações
11.1.2. Cada artefato contém um compromisso para garantir que ele forneça informações que aumentem a transparência e o foco contra o qual o progresso pode ser medido
11.1.2.1. Para o Product Backlog, é a Meta do produto.
11.1.2.2. Para o Sprint Backlog, é a Meta da Sprint.
11.1.2.3. Para o incremento, é a Definição de Pronto
11.2. Backlog do produto
11.2.1. O Product Owner é o "dono" do Backlog do Produto
11.2.1.1. Isso significa que cabe a ele decidir o que entra ou sai desse Backlog
11.2.2. É uma lista ordenada de tudo aquilo que pode ser necessário no produto
11.2.2.1. Se espera que aquilo que tenha maior valor tenha uma prioridade maior.
11.2.3. O progresso é medido pela Meta do produto
11.2.3.1. É objetivo de longo prazo para o Scrum Team
11.2.4. Está em constante evolução
11.2.4.1. Deve refletir as mudanças no negócio
11.2.5. Disponível para todos visualizarem (transparência)
11.2.6. Recomenda-se apenas um Backlog do Produto, mesmo que haja vários Times trabalhando no mesmo produto
11.2.7. As estimativas dos itens devem ser feitas por quem vai realizar o trabalho (no caso, os Desenvolvedores)
11.3. Backlog da sprint
11.3.1. É uma saída principal gerada na reunião Planejamento da Sprint
11.3.2. É composto pela Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a Sprint (o que), bem como um plano de ação para entregar o Incremento (como)
11.3.2.1. Esta meta é criada durante o evento Sprint Planning
11.3.2.2. Pode conter como itens
11.3.2.2.1. Tarefas
11.3.2.2.2. Testes a executar
11.3.2.2.3. Casos de uso
11.3.2.2.4. História de usuário
11.3.3. O progresso é medido pela Meta da Sprint
11.3.3.1. Conforme os Developers trabalham durante a Sprint, eles mantêm a Meta da Sprint em mente. S
11.3.3.2. O escopo do Backlog da Sprint pode ser negociado com o Product Owner durante a Sprint, mas sem afetar esta Meta
11.3.4. É um plano feito por e para os Developers
11.3.5. Novas tarefas podem ser adicionadas durante a Sprint
11.3.5.1. Lembre que o detalhamento das tarefas pode continuar durante a sprint
11.3.6. Visível para todos (transparência)
11.3.6.1. Pode ser apresentado em um quadro kanban para ser visível para todos
11.3.7. Todas as tarefas são de responsabilidade do Time Scrum, ninguém vira dono exclusivo de um item
11.3.7.1. Um desenvolvedor pode voluntariamente assumir uma tarefa para fazer, mas todos são donos de todas as tarefas
11.3.8. O seu refinamento pode ser feito pelo Product Owner com apoio dos Desenvolvedores
11.3.8.1. Esta é uma atividade contínua
11.3.8.2. Ideal que os itens esteja preparados (ready) para seleção durante a Reunião de Planejamento da Sprint
11.3.8.3. Cabe aos desenvolvedores o dimensionamento dos itens do Backlog do Produto
11.3.8.4. Os itens com prioridade maior terão maior detalhamento para estarem preparados para entrar na próxima sprint
11.4. Incremento
11.4.1. É a soma de todos os itens do backlog do produto completados durante a sprint e o valor dos incrementos de todas as sprints anteriores
11.4.2. Ao final da sprint um novo incremento deve estar “pronto”
11.4.3. Deve estar na condição utilizável e atender à definição de “pronto” do time Scrum
11.4.4. Quando julgar que faz sentido, o Product Owner decidirá a sua implantação no ambiente de produção
11.4.5. Definição de "Pronto"
11.4.5.1. É usada para definir quando o trabalho está completado no incremento do produto
11.4.5.2. Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou mesmo apresentado na Sprint Revie
11.4.5.3. Orienta os Desenvolvedores sobre quantos itens do backlog do produto podem ser selecionados durante a reunião de planejamento
11.4.5.4. Se fizer parte de convenções, padrões ou diretrizes de desenvolvimento da organização, então todos os Times Scrum devem seguir o que já existe
11.4.5.5. Se esta definição é particular de cada projeto, então cabe ao Time Scrum criar uma definição de "pronto" apropriada
11.4.5.6. Se houver vários times Scrum trabalhando no mesmo produto, então a mesma definição deve ser acordada entre os times para que os incrementos possam ser integrados
12. Ferramentas/técnicas complementares
12.1. Lembre que estas ferramentas/técnicas são usadas na prática, mas não são obrigatórias segundo o Scrum Guide
12.2. Gráfico burndown da sprint
12.2.1. É uma ferramenta com objetivo primário de servir ao time de desenvolvimento
12.2.2. Os desenvolvedores podem atualizar
12.2.2.1. Lembre que a equipe é autogerenciada
12.2.3. Mostra a quantidade de trabalho restante em uma sprint
12.2.4. Útil para fazer o monitoramento do andamento da sprint
12.2.5. É uma ferramenta de gerenciamento visual e depende da transparência dos membros do time
12.3. Gráfico burndown da release
12.3.1. Mostra a quantidade de trabalho restante para concluir o backlog do produto naquele instante
12.3.2. O Product Owner é responsável por realizar o plano de releases
12.3.3. É uma "foto" da situação atual
12.3.4. Deve ser atualizado toda vez que o backlog do produto mudar
12.3.5. O Product Owner é responsável pela atualização
12.4. Planejamento da release
12.4.1. Ao final de cada sprint, o Product Owner decidirá se implanta o incremento liberado em produção