Curso Projetos ágeis com SCRUM

Introdução a Gestão de Projetos e ao SCRUM

Módulo I - Introdução ao SCRUM

• Autor: Thiago Sano
• Origem: Digital Innovation One

Aula I - Introdução a Gestão de Projetos e ao SCRUM

Conceitos básicos

O desafio do desenvolvimento de software é tornar os objetivos de negócio em software. Os objetivos de negócio são transformados em requisitos e depois passam pelo processo de desenvolvimento que podem conter as etapas abaixo para criar um software:

• Concepção
• Análise e Design
• Desenvolvimento
• Testes
• Implantação

A realidade do desenvolvimento de software

As estatísticas dizem que:

• 20 % das funcionalidades do software costumam gerar 80 % ou mais do benefício esperado.
• 80 % das funcionalidades do software nunca, rararemente ou às vezes são utilizadas.

Gestão de Projetos Tradicional x Gestão de Projetos Ágil

Tradicional (Waterfall)

Só permite que o projeto avance quando uma fase está inteiramente completa. As fases do projeto são:

1. Requirement (requirement doc, prepare use cases)
2. Design (software architecture, map the stackholders)
3. Implementation (construct the software, data storage & retrieval)
4. Verification (install, test and debug)
5. Maintenance (check erros, optmize capatibilities)

Ágil

Software construído por partes (incremental) e cada parte executa-se em um ciclo (iterativo) As fases de cada ciclo:

1. Requisitos
2. Análise
3. Construção
4. Testes
5. Liberação

Diferenças de abordagem

Em projetos tradicionais, você corre o risco de descobrir que estava errado depois de meses. Com o SCRUM, você descobre que estava errado em no máximo 30 dias.

O que é ser Ágil

• Ágil não é ser rápido;
• Rapidez (mudança) e desembaraço;
• Fazer coisas complexas de forma simples;
• Equipe comprometida com os objetivos;
• Maior valor para o cliente;
• Ter capacidade de responder rapidamente a mudanças.

O que é o SCRUM

• SCRUM é um dos frameworks de gerenciamento de projetos ágeis;
• Projetos usando equipes pequenas e multidisciplinares produzem os melhores resultados.

Pilares do SCRUM

• Transparência
  • Conversar mais e escrever menos;
  • Demonstrar o software constantemente aos usuários e obter feedbacks constates.
• Adaptação
  • Requisitos mudam ao longo do tempo;
• Inspeção
  • Aprender progressivamente com o uso do software

Razões para adotar o SCRUM

• Desenvolvimento e entregue em partes menores (2 a 4 semanas), com constante feedback dos usuários;
• Melhor gerenciamento de riscos (redução de incertezas);
• Comprometimento, motivação e transparência da equipe (Daily Meeting);
• Maior valor para o negócio (priorização do backlog);
• Usuários envolvidos durante todo o ciclo;
• Aplicação das lições aprendidas (melhoria contínua).

Características do time SCRUM

• Equipes capazes de se auto-organizarem
• As tarefas são do time e todos sãos responsáveis
• Forte comprometimento com os resultados

Exercício final - Módulo I - Aula I

1) Qual característica de um projeto ágil?

a) Escopo definido na fase inicial do projeto

b) Escopo definido ao longo do projeto

c) Resistente à mudanças

d) Aumento de pessoas para que o projeto seja rápido

e) Cliente paga mais caro para o projeto seja mais rápido

Resposta: B

2) Quais são os pilares do SCRUM?

a) Desenvolvedores e Gerente

b) Processos e Mudanças

c) Adaptação, Transparência e Inspeção

d) Comunicação e Status Report

e) Risco, Escopo e Custos

Resposta: C

Aula II - Papéis e Responsabilidades de cada um do time

Papeis e responsabilidades

Product Owner (PO)

• Representante da área de Negócios;
• PO não é um Comitê, é uma pessoa;
• Define as funcionalidades do software (Product Backlog);
• Prioriza as funcionalidades de acordo com o valor do negócio;
• Garante que o time de desenvolvimento entenda os itens dos Backlog no nível necessário.

Scrum Master (SM)

• Garantir o uso correto do SCRUM;
• Scrum Master não é Gerente de Projetos;
• Age como facilitador;
• Auxilia o Product Owner no planejamento e estimativas do backlog;
• Auxilia a equipe a remove impedimentos;
• Treina o time em autogerenciamento e interdisciplinaridade;

Time de Desenvolvimento (DEV; 3-9 pessoas)

• Possui habilidades suficientes para desenvolver, testar, criar e desenhar, ou seja, tudo que for necessário para entregar o software funcionando.

Exercício final - Módulo I - Aula II

1) Quem é o responsável por priorizar o Backlog?

a) Scrum Master

b) Time DEV

c) Área de Negócios

d) Product Owner

Resposta: D

2) Quem é o responsável por garantir que o time utilize da melhor forma o SCRUM?

a) Scrum Master

b) Time DEV

c) Área de Negócios

d) Product Owner

Resposta: A

3) Quem é o responsável por desenhar, construir e entregar o software funcionando?

a) Scrum Master

b) Time DEV

c) Área de Negócios

d) Product Owner

Resposta: B

Aula III - Cerimônias do SCRUM

Conceitos básicos da Cerimônias do SCRUM

Time Box

Tempo máximo para fazer uma cerimônia ou sprint

Exemplo:

• Daily Meeting com Time Box de no máximo 15 minutos;
• Sprint com Time Box de 30 dias corridos.

Sprint

O significado da palavra é corrida ou arrancada. É o principal evento do SCRUM e cada Sprint tem o período de 30 dias corridos (ou menos).

Composição de uma Sprint:

• Planejamento da Sprint (Planning);
• Reuniões Diárias (Daily Meeting)
• Revisão da Sprint (Review)
• Retrospectiva da Sprint

Cerimônia do Planejamento da Sprint

Participantes

• Product Owner
• Time DEV
• Scrum Master

Time Box para a Sprint

• Time Box de 8 horas para uma Sprint de 30 dias, as primeiras 4 horas são para decidir o que fazer e as outras 4 horas são para decidir como fazer.

Cerimônia

• Após a priorização do Backlog pelo Product Owner, as primeiras 4 horas são utilizadas para explicar o que ele quer, qual a importância.
• Nas próximas 4 horas no time DEV define como fazer, quanto tempo é necessário, uma das ferramentas para estimativas pode ser o Planning Poker.

Reuniões Diárias (Daily Meeting)

Participantes da Reunião diária

• Product Owner (Opcional)
• Time DEV
• Scrum Master

Time Box da Reunião diária

• Time Box de no máximo de 15 minutos.

Cerimônia da Reunião diária

• O Time DEV responde a 3 perguntas:
  • O que fez no dia anterior
  • O que está programado para o dia
  • Se existe algum impedimento
• Reunião feita em pé e sempre no mesmo horário e local definido pelo time, também conhecida como Standup Meeting.
• Atualização do quadro KANBAN para visibilidade do andamento da sprint.

Revisão da Sprint (Review)

Participantes da Revisão da Sprint

• Product Owner
• Time DEV
• Scrum Master
• Stakeholder (Opcional)

Time Box da Revisão da Sprint

• Time Box de no máximo de 4 horas (Sprint 30 dias).

Cerimônia da Revisão da Sprint

• Ocorre no último dia da Sprint;
• O Time DEV apresenta para o Product Owner (PO) o trabalho feito;
• Todo feedback sobre o desenvolvimento é registrado para a próxima Sprint;
• O Product Owner (PO) decide o que vai ou não para Produção.

Retrospectiva da Sprint

Participantes Retrospectiva da Sprint

• Time DEV
• Product Owner
• Scrum Master

Time Box da Retrospectiva da Sprint

• Time Box de no máximo de 3 horas (Sprint 30 dias).

Cerimônia da Retrospectiva da Sprint

• Ocorre no último dia da Sprint;
• O Time DEV de maneira transparente se reune para falar sobre as lições aprendidas, quais erros ocorreram no desenvolvimento, na review, no planejamento da Sprint, ou dúvidas sobre informações que não foram esclarecidas com o Product Owner;

Aula IV - Gestão de Projetos Tradicional x Ágil

Diferença prática

Exemplo Nubank

Gestão de Projetos Tradicional

No planejamento inicial do projeto poderíamos ter todas as funcionalidades:

• Cartão de crédito;
• Benefícios;
• Conta digital;
• Empréstimos;

Gestão de Projetos Ágil

No planejamento inicial do projeto poderíamos o mínimo produto viável, ou seja, o mínimo esforço de desenvolvimento

• Cartão de crédito

Receber os feedbacks, melhorar a funcionalidade inicial e depois partir para a próxima funcionalidade, sempre ouvindo o cliente e vendo o que faz a diferença.

Módulo II - Fundamentos de um projeto Ágil

• Autor: Diego A S Pereira
• Origem: Digital Innovation One

Aula I - Papéis e responsabilidades do Product Owner

Quem é o Product Owner (PO)

O Product Owner (PO) representa o profissional que tem a visão do que será desenvolvido, as necessidades a serem atendidas, o público que vai utilizar os serviços e os objetivos a serem alcançados.

Cerimônias obrigatórias do Product Owner (PO)

• Planejamento da Sprint (Planning);
• Revisão da Sprint (Review).

Responsabilidades do Product Owner (PO)

• Define a ordem que as atividades serão desenvolvidas;
• Responsável por validar se os itens entregues nas Sprints estão gerando valor;
• Responsável por ajustar as Sprints caso necessário;
• Responsável por cancelar a Sprint quando as atividades planejadas não puderem mais serem entregues ou caso ele entenda que o valor esperado não será mais atingido;
• Deve fazer presente para sanar as dúvidas do Time DEV;
• Deve melhorar o Planejamento (Planning) da próxima Sprint caso hajam dúvidas na atual;
• Não deve aguardar até a Revisão da Sprint (Review) para validar o Desenvolvimento, sempre que possível deve fazer presente nas Reuniões Diárias (Daily Meeting);

Reponsabilidades do Product Owner (PO) no Planejamento da Sprint (Planning)

• Refinar o Product Backlog para a escolha dos itens para Sprint Backlog;
• Compartilhar com os demais quais são os possíveis itens da Sprint para que eles possam questionar durante o Planejamento da Sprint (Planning);

Release Planning

É a liberação ou lançamento do software ou de uma nova versão oficial do produto de software. Cada vez que um produto de software é criado ou modificado, o fabricante e seus desenvolvedores decidem sobre como distribuir o novo produto ou informar as modificações no produto.

Tipos de Release Planning

Release Planning de Múltiplas Squads

Vários times de desenvolvimento realizado atividades que podem um não estar relacionadas e que ao final da Sprint serão agrupadas em uma única Release.

Release Planning de Projeto

Demanda muito grande onde é necessária dividir em várias histórias e consequentemente em várias Sprints.

Reponsabilidades do Product Owner (PO) no Release Planning

• Definir as maiores entregas de valor para o cliente;
• Priorizar as maiores entregas de valor para serem desenvolvidas primeiro;
• Organizar as Sprints para seja possível captar o retorno do cliente de maneira mais breve possível;
• Com o retorno do cliente ir ajustando as histórias para que elas entreguem sempre mais valor;
• Organizar a entrega das releases de maneira que entregue mais valor com menos impactos para o cliente;

Exercício final - Módulo II - Aula I

1) Qual a característica melhor descreve uma atividade do PO?

a) Recebe a demanda e passa para o time

b) Escreve a história e valida com o demandante

c) Entende a demanda e extrai o maior valor possível

d) Escreve a história e deixa o time avaliar os impactos

Resposta: C

2) Qual o papel do PO dentro do Time?

a) Ajuda o Time da entender a demanda e tira as dúvidas ao longo da Sprint

b) Coordena as pessoas do Time e acompanha suas atividades

c) Remove os impedimentos que impactam o desenvolvimento da Sprint

d) Responsável por manter o time abastecido com Café

Resposta: A

Aula II - Analisando o escopo e definindo prioridades

A definição do escopo do projeto é a parte mais crítica do processo de desenvolvimento do projeto, pois é nesse momento que será definido o que será desenvolvido, são dos artefados dessa etapa que serão extraídos os objetivos que serão atingidos. Uma forma eficiente de definir o escopo corretamente é inverter a ordem e começando a entender primeramente o objetivo ou valor que você quer atingir.

Product Backlog

É composto por Épicos e Histórias

Épicos (Epic)

Incremento sem muito detalhamento, ajuda a te direcioanr dos caminhos que deve seguir.

História (User Stories)

Detalhamento dos Épicos, um Épico normalmente se divide em várias Histórias, onde ficam descritos o que deve acontecer e suas regras de negócio.

Escrevendo uma História

• Nome da História
• Descrição da História (Eu, Como, Quero, Quando)
• Regras de Negócio (Separar regras de front-end de regras de back-end)
• Tela (Link ou imagem das telas a serem desenvolvidas)
• KPI (Quais os objetivos/valor a História precisa atingi)
• Tagueamento (Como a História será Tageada para pode mensuarar os KPIs)
• Critério de Aceite (Qual o passo a passo de todos os caminhos felizes possíveis a História deve cumprir para que ela seja considerada aceita)

Riscos

Positivos

Muito ignorado nos projetos, porém um dos fatores de maiores ganhos no desenvolvimento de sistemas.

Negativos

Itens que podem afetar o prazo, custo ou escopo de um projeto de maneira que pode acabar inviabilizando-o.

Exercício final - Módulo II - Aula II

1) Qual método é mais indicado para definir o Escopo do projeto?

a) Ler a solicitação junto com o Time de Desenvolvimento

b) Pedir para o Demandante escrever o que ele quer

c) Entender qual o ganho antes de definir o escopo

d) Escreve o escopo baseado no seu conhecimento do produto

Resposta: C

2) O que compõe um Product Backlog?

a) História e Escopo

b) Escopo e Atividade

c) Épico e Atividade

d) Épico e História

Resposta: D

3) Qual a importância de mapear Riscos Positivos?

a) Para o Time poder descansar

b) Poder priorizar outros itens no Backlog

c) Cobrar a entre dos outros Times

d) Conhecer a legislação vigente

Resposta: B

Aula III - Papel do PO na transformação digital

A transformação digital é um processo no qual as empresas fazem uso da tecnologia para melhorar o desempenho, aumentar o alcance e garantir resultados melhores. É uma mudança estrutural nas organizações dando um papel essencial para a tecnologia.

O PO é o orquestrador da comunicação, responsável por juntar todas as partes do planejamento. Será cada vez mais responsável pelo sucesso do Produto.

Módulo III - Conceitos e atividades essenciais para o sucesso de um Projeto Ágil

• Autor: Diego A S Pereira
• Origem: Digital Innovation One

Aula I - Aprenda sobre os conceitos e planejamento de tarefas

Histórias x Tarefas

De forma resumida a diferença entre Épico, História, Tarefas.

Épico

É um elemento que não está muito detalhado, ou é muito grande ou possui muita incerteza, por isso, ele é divido em Histórias. Um Épico é um conjunto de Histórias

História

É um elemento sucinto para escrita de requisitos necessários para a construção de um produto. Uma História é um conjunto de Tarefas.

Tarefas

É o elemento técnico, o que deve ser feito para completar a História.

Critérios de Aceite, Estimativa e Planejamento de Tarefas

O que é um Critério de Aceite

É uma lista de critérios que precisam ser alcançados para que a User Story atenda os requisitos do usuário e seja aceita pelo Product Owner. Os critérios de aceitação têm o objetivo de: definir limites para as User Stories. Ajudar o PO a detalhar em alto nível o que é necessário para entregar valor ao cliente.

Estimativa

Planning Poker: É uma técnica ágil usada para estimar um conjunto de tarefas, não se trata de estimativas em horas e sim na dificuldade da atividade, sendo utiliado em dois momentos como na priorização de tarefas e na estimativa de esforço para concluí-las.

Por exemplo: Uma tarefa muito simples pode receber voto 1, já uma muito difícil pode receber voto 13, normalmente quando a Tarefa ou História recebe voto 20 é considerada que está muito grande e deve-se quebra-lá em mais Tarefas ou Histórias. Os membros do Time que derem o maior e o menor voto devem justificar o motivo de sua pontuação, pois eles podem ter pensando em algo que os membros do Time não tenham pensado.

Planejamento de Tarefas

Cada História é divida em Tarefas pelo Time de Desenvolvimento, o Time pode dimimuir as Histórias e quebra-lás caso sejam muito grandes. Com as Histórias mapeadas e as Tarefas descritas é definido a Sprint Backlog, o PO avalia qual é o item prioritário da Sprint, aquele que é considerado o objetivo principal, em teoria significa que se essa Atividade não for executada todo o restante da Sprint não faz mais sentido e que alguma mudança pode ser realizada durante a Sprint ou que ela será cancelada, pois o objetivo não será mais alcançado.

Exercício final - Módulo III - Aula I

1) Qual característica melhor descreve uma História?

a) Uma tarefa descrita em nível executivo

b) Uma tarefa descrita em nível de desenvolvimento

c) Uma tarefa descrita em nível de negócio

d) Uma tarefa descrita em nível de entrega

Resposta: C

2) O que é uma Tarefa?

a) Um conjunto de Histórias que o Time de Desenvolvimento deve desempenhar para entregar o projeto

b) Um conjunto de Atividades que o Time de Desenvolvimento deve desempenhar para entregar a História

c) Um conjunto de Épicos que o Time de Desenvolvimento deve desempenhar para entregar a História

d) Um conjunto de atividades que o PO deve desempenhar para entregar para o Time de Desenvolvimento

Resposta: B

3) O que é um Critério de Aceite?

a) É uma lista de demandas que o PO deve atingir na entrega das tarefas

b) É uma lista de critérios para que o Épico atenda aos requisitos do cliente

c) É uma lista de critérios para que a História atenda aos requisitos do cliente

d) É uma lista de cenários de teste

Resposta: C

4) O que é Planning Poker?

a) Uma atividade de integração do Time

b) Uma atividade de mensuração da capacidade do Time

c) Uma atividade de mensuração da complexidade do Épico descrito pelo cliente

d) Uma atividade de mensuração do esforço e complexidade das Tarefas ou Histórias.

Resposta: D

Relacionamento com Clientes / Stakeholders

Quem é o Stakeholder

O Stakeholder é uma pessoa ou um grupo que legítima as ações de uma organização e que tem um papel direto ou indireto na gestão e resultados dessa mesma organização. Desta forma, um Stakeholder pode se afetado positivamente ou negativamente, dependendo das suas politícas e forma de atuação.

Alguns exemplos de Stakeholder de uma empresa pode ser os seus funcionários, gestores, gerentes, proprietários, fornecedors, concorrentes, ONGs, clientes, o Etados, credores, sineicartos e diversas outras pessoas ou empresas que estejam com uam determinada ação ou projeto.

Aula II - Rotinas de um Time Ágil

Daily e Restrospectiva

Daily

Deve ocorrer sempre no mesmo local e horário, sendo 15 minutos o ideal, sendo que a presença do PO e do Scrum Master não são obrigatórias.

É quando ocorre as três perguntas para cada membro do Time.

• O que eu fiz ontem
• O que vou fazer hoje
• Se tenho algum impedimento

É possível que o membro do Time fala algo a mais além das três perguntas, porém caso presente o Scrum Master pode intervir para que o assunto seja tratado em particular ou em outra Daily para não atrapalhar o restante da Daily

Restrospectiva

Acontece após a conclusão da Sprint, a presença do PO é muito importante, mas não é obrigatória, e caso necessário pode ser divida em duas partes sendo uma com o PO e outra sem para que o Time esteja mais a vontade para discutir.

Na Restrospectiva são discutidos os pontos bons e ruins da Sprint, o que deve-se melhorar, o que não se deve fazer, e o que podemos fazer já na próxima Sprint.

Refinamento e Review

Refinamento

É uma cerimônia não oficial do SCRUM, porém muito utilizada para que o Time discuta junto com PO como será a próxima Sprint, quais serão os Entregáveis, e adiantar possíveis dúvidas. Nesse momento é possível que o Time de Desenvolvimento realize várias perguntas para o PO para saber de que se trata a demanda, para isso boa parte das Histórias já devem estarem prontas, com a ideia de facilitar a Planning. Nessa cerimônia a presença de todos os membros do Time SCRUM é obrigatória.

Review

É a oportunidade do Time de Desenvolvimento apresentar o trabalho que foi realizado durante a Sprint. Com a presença obrigatória do PO e do SM, além de convidados e o stakholder. A ideia principal e ver e validar se a entrega está de acordo com o que foi solicitado inicialmente.

Maturidade da Equipe

Um Time nunca será maduro e a empresa não é madura, um time nunca será ágil se a empresa tem uma Gestão Tradicional (Waterfall), não adianta passar pela Sprint e tem que passar por um processo de gestão de mudança. o Amadurecimento do Time está diretamente ligado ao ambiente que o Time está. Pode-se medir o amadurecimento da equipe utilizando os pilares do SCRUM:

Transparência, Inspeção e Adaptação

• O Time possui transparência para saber ocorre ao seu redor, se sabe sobre as próximas demandas e sabe se a empresa está indo bem ou não. Ele se sente mais capaz e mais tranquilo para desenvolver suas atividades.
• Um Time maduro preocupa-se com a entrega que é feita ao cliente.
• Um Time maduro não é dependente do Scrum Master para resolver os problemas.
• Um Time maduro questiona e auxilia o PO nas suas Histórias.
• Um Time maduro é um Time que anda sozinho.

Exercício final - Módulo III - Aula II

1) Quem tem participação obrigatória da Daily?

a) O Time de Desenvolvimento e o SM

b) O Time de Desenvolvimento e o PO

c) O Time de Desenvolvimento apenas

d) O Time de Desenvolvimento, o SM e o PO

Resposta: C

2) Quem tem participação obrigatória da Retrospectiva?

a) O Time de Desenvolvimento e o SM

b) O Time de Desenvolvimento e o PO

c) O Time de Desenvolvimento apenas

d) O Time de Desenvolvimento, o SM e o PO

Resposta: A

3) Em que momento acontece o Refinamento?

a) O Refinamento acontece um passo antes da Daily

b) O Refinamento acontece um passo depois da Restrospectiva

c) O Refinamento acontece um passo antes da Planning

d) O Refinamento acontece um passo depois da Review

Resposta: C

3) Qual o principal objetivo da Review?

a) Verificar se o Time entregou o trabalho direito

b) Verificar se o PO entendeu a demanda

c) Verificar se a demanda foi priorizada na Sprint

d) Verificar se a demanda agrega valor ao negócio

Resposta: D