Muito obrigado em escolher um treinamento oficial High IT!liveuniversity.com/downloads/Material -...

• Muito obrigado em escolher um treinamento oficial High IT!

• Temos o prazer de tê-los como alunos e transmitir toda a nossa experiência e conhecimento de maneira única e inovadora aos nossos clientes.

EXIN Agile Scrum Foundation- © HSI Institute. Todos os direitos reservados.

2

Bem Vindo ! Welcome ! Bienvinida !

3

Check-In


Nome e empresa Experiência profissional Objetivo

4

Agenda


• Mindset Agile;

• Conceitos de Agile e Scrum;;

• Práticas scrum;

• Papéis no Scrum;

• Eventos Scrum;

• O backlog e a sua importância;

• Definição de pronto;

1 dia

• Planejamento e estimativas Scrum;

• Planejamento e estimativas scrum;

• Estimativas scrum;

• Monitorando projetos com Scrum;

• Monitoramento Scrum;

• Conceitos avançados do Scrum;

• Scrum em diferentes situações;

2 dia

• A filosofia ágil é mais conhecida na área de desenvolvimento de software, mas os seus princípios estão cada vez mais sendo aplicados em outros tipos de projetos.

• O Scrum é a metodologia ágil mais utilizada e é apropriada para os profissionais que trabalham nas áreas de:

• Gerenciamento de Projetos;

• Desenvolvimento de Software;

• Gerenciamento de Serviços de TI;

• Gerenciamento de Negócios.

5

Público alvo


6

HSI Institute

ISO 27002 Foundation - © HSI Institute. Todos os direitos reservados.

Maior instituto das Américas de desenvolvimento de conteúdos de treinamentos oficiais.

Atua em conjunto com os principais institutos de certificação profissional, como o EXIN, APMG e CompTIA.

Fornece seus conteúdos e credenciamentos para sua rede de parceiros credenciados.

7

Conheça também nossos outros títulos

ISO 27002 Foundation - © HSI Institute. Todos os direitos reservados.

Possuímos um dos maiores portfolios de treinamentos credenciados de todo o mundo. Consulte seu provedor de treinamento para o desenvolvimento de novas competências !

Governança de TI

Serviços

Susten

tabilid

ade

Plan

ejamen

to

Seguran

ça

ITIL ISO 20000

Cloud computing

ISO 27002 ISO 27001

Secure Programing Ethical Hacking

GREEN IT Prince 2

Agile SCRUM

Gestão de TI

Empresa / Negócios

COBIT5

Ger. de Informação do Negócio (BIM)

• Mindset Ágil • Conceitos de Agile e Scrum;

• Práticas Scrum • Papéis no Scrum;

• Eventos Scrum; • O backlog e a sua importância;

• Definição de pronto;

• Planejamento e Estimativas Scrum • Planejamento Scrum; • Estimativa Scrum;

• Monitorando projetos com Scrum • Monitoramento Scrum;

• Conceitos avançados de Scrum • Scrum em diferentes situações;

8

Conteúdo abordado


Capítulo 1 Introdução ao agile scrum

Programa planejado de trabalho que requer uma quantidade definitiva de tempo, esforço e

planejamento para ser concluído quando atingir as suas metas e objetivos.

10

O que é um projeto?


(A – Capítulo 1)

Cumprir o orçamento

Período fixo de tempo

Atender aos requisitos de qualidade

11

Origens do gerenciamento de projeto moderno


(A – Capítulo 1)

Metodologia Waterfall

Desenvolvimento:

Integração

Teste

Desenho

Requisitos 01

02

03

04

05

06 Implantação

Disciplina formal

do século XX

Muralha

da China

2 Guerra mundial Processos formais passo

a passo.

1970 Metodologia

Waterfall

Em 2009, uma empresa de software chamada Standish Group realizou um estudo sobre o sucesso e falhas de projetos de software nos Estados Unidos. Os resultados do estudo mostraram que:

12

Sucesso e fracasso de projetos de software


(A – Capítulo 1)

24% 32% 44% Mal sucedidos Bem sucedidos Com gaps

45%

Durante o crescimento da tecnologia alguns processos foram deixados para trás, trazendo problemas com o escopo inflado e funcionalidades desnecessárias no projeto.

Pense a respeito das diversas aplicações e inúmeras funcionalidades. Quantas são realmente usadas no dia-a-dia?

A organização Standish Group realizou um estudo visando

obter informações em relação ao número de recursos solicitados e os recursos realmente utilizados!

13

O problema com o status quo


(A – Capítulo 1)

uso Pouco

utilizado Raramente

utilizado SEMPRE

uso Frequente

19%

16%

13%

utilizado NUNCA

7%

As sementes de técnicas ágeis foram plantadas anos atrás. Em 1986, na publicação do artigo "New Product Development Game in the Harvard

Business Review ” com uma etratégia de desenvolvimento rápida e flexível para atender a demanda de produtos em ritmo acelerado.

14

Apresentando o gerenciamento ágil de projetos – agile scrum


(A – Capítulo 1)

Este grupo criou o Manifesto Ágil, uma declaração de valores para o desenvolvimento de software bem sucedido.

Em 2001, um grupo de especialistas em software e projetos se reuniram para determinar o que os seus projetos de sucesso tinham em comum.

Definição: Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente

entregam produtos com o mais alto valor possível.

15

O que é SCRUM?


(B)

Scrum

Difícil de dominar

Simples de

entender

Leve

Foco em

Pessoas Comunicações

Produto Flexibilidade

16

Ciclo de vida preditivo x Ciclo de vida adaptativo

Interação 1 Interação 2 Interação 3 Interação 4 Interação 5

Incremento (produto)




• Analisar • Desenhar • Construir • Integrar • Testar





17

Considerações do modelo de ciclo de vida adaptativo

Interação 1 Interação 2 Interação 3 Interação 4 Interação 5





Cada processo de desenvolvimento é executado uma vez para cobrir todas as funcionalidades

Funcionalidade 1 Funcionalidade 2 Funcionalidade 3

Mini-Waterfall (cascata) Errado

Cada processo de desenvolvimento é executado separadamente para cada funcionalidade

Funcionalidade 1 Funcionalidade 2 Funcionalidade 3

Mini-Agile Certo

Entendendo o manisfesto agile

Estamos descobrindo maneiras melhores de desenvolver softwares fazendo-o nós mesmos e ajudando os outros a fazê-lo.

Através deste trabalho, passamos a valorizar mais os itens de cima do que os de baixo:

19

Manifesto agile


(A – Capítulo 1)

01 Indivíduos e

interações

02 Softwares em

funcionamento

03 Colaboração

do cliente

08 Processos e

ferramentas

07 Documentação

abrangente

06 Negociação de

contratos

04 Responder as

mudanças

05 Seguir um

plano

20

Entendendo o manifesto agile


(A – Capítulo 2)

1990 A internet

aumentava a

pressão para a TI se adaptar rapidamente

1990 As práticas de

projeto waterfall não

permitiam a

agilidade necessária;

2001 17 pioneiros se reuniram em Utah – Snowbird para

criar:

1. Manifesto Agile

2. Princípios do Agile (12 Conceitos)

3. Aliança Agile

Quando as interações humanas se concentram na resolução de problemas, um propósito unificado pode emergir. Além disso, os acordos acontecem através de processos e ferramentas que são muito mais simples do que os convencionais.

Uma conversa simples sobre uma questão de projeto pode resolver muitos problemas em um tempo relativamente curto. Já uma conversa por e-mail, planilhas e documentos pode exigir um tempo maior.

Considere o que irá significar se valorizarmos mais os indivíduos e interações.

21

Valor 1: Indivíduos e interações entre eles mais que processos e ferramentas


(A – Capítulo 2)

Prós Contras

Em projetos ágeis, a única maneira de medir se cumprimos com os requisitos do produto é de produzir a funcionalidade do produto associado com os requisitos;

Tarefas que distraem o desenvolvimento devem ser avaliadas para ver se as mesmas auxiliam ou atrapalham o produto de trabalho;

Todos os projetos exigem alguma documentação. Em projetos ágeis, no entanto, os documentos devem ser apenas suficientes para atender o projeto;

As equipes de projetos ágeis produzem menos documentos (e mais simplificados), que exigem menos tempo para se manterem e proporcionam uma melhor visibilidade sobre possíveis problemas.

24

Valor 2: Software em funcionamento mais que documentação abrangente


(A – Capítulo 2)

Documentos

Documentos

O histórico das abordagens de gerenciamento de projetos geralmente envolve os clientes em três pontos-chave:

26

Valor 3: Colaboração com o cliente mais que negociação de contratos


(A – Capítulo 2)

Fim do projeto: Alteração de Escopo

Início do projeto:

Os pioneiros nas metodologias ágeis entendem que as colaborações, em vez de confronto, produzem um produto melhor, mais enxuto e mais funcional.

Equipes de projetos tradicionais, muitas vezes encontram-se cegamente seguindo um plano, perdendo oportunidades de criar produtos mais valiosos.

27

Valor 4: Responder a mudanças mais que seguir um plano


(A – Capítulo 2)

28

Os 12 princípios agile


(A – Capítulo 2)

1 • Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

2 • Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

3 • Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

4 • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

5 • Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

6 • O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

7 • Software funcional é a medida primária de progresso.

8 • Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

9 • Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

10 • Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

11 • As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.

12 • Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

O framework

30

O conceito ágil


(A – Capítulo 3)

Tempo

X

Requisitos

Desenho

Desenvolvimento

Teste

Implantação

Urgente-Alta-Média-Baixa-Opcional Funcionalidades Urgentes

Funcionalidades Urgentes

Desenho

Requisitos

Desenvolvimento integrado

Demo e feedback Teste

Funcionalidades Altas

Funcionalidades Altas

Funcionalidades Médias

Funcionalidades Médias

Funcionalidades Baixas

Funcionalidades Baixas

Funcionalidades Opcionais

Funcionalidades Opcionais

A estrutura ágil aborda os principais desafios de métodos históricos de projetos que não estão adaptados para ciclos devida de desenvolvimento contemporâneos;

Quando temos um prazo iminente crítico, o instinto natural é ser ágil e deixar as formalidades de lado;

Abordagens

opostas

Waterfall

Agile

Tempo

Recursos Tempo

31

O framework de gerenciamento de projetos agile


(B) Produto final

Funcionalidades

completas

Vislumbrar

Plano de implantação

Lista de funcionalidades

Adaptar

Explorar

Encerrar

Especular

1. Qual das seguintes alternativas melhor descreve a(s) característica(s) essencial(ais) da metodologia Agile?

a. Modelo V

b. Pragmático e previsível

c. Iterativo e incremental

d. Rápida prototipagem

2. Qual das seguintes NÃO é uma afirmação do manifesto ágil?

a. Seguir um plano mais do que responder à mudanças

b. Indivíduos e interações entre eles mais que processos e ferramentas

c. Colaboração do cliente mais que negociação de contratos

d. Softwares em funcionamento mais que documentação abrangente

32

Exercício 1


3. De acordo com os princípios ágeis, qual deve ser a velocidade do desenvolvimento?

a. A velocidade pode ser sustentada indefinidamente

b. Devagar, de modo que a qualidade pode ser construída

c. O mais rápido possível - a velocidade é a essência do Agile

d. Aumentar a velocidade constantemente

4. Selecione a sequência correta das fases do framework do Agile Scrum?

a. Vislumbrar, Especular, Adaptar, Explorar, Encerrar

b. Vislumbrar, Especular, Explorar, Adaptar, Encerrar

c. Vislumbrar, Explorar, Especular, Adaptar, Encerrar

d. Especular, Vislumbrar, Explorar, Adaptar, Encerrar

33

Exercício 1


Complementos do framework Agile

Crystal

O Crystal foi criado com o princípio de ser uma abordagem de desenvolvimento de software que priorizasse a adaptabilidade;

Possui como característica a comunicação cooperativa e a entrega de software útil em funcionamento;

36

Crystal


(C)

Crystal

Clear

1-8

Yellow

10-20

Orange

(web)

20-50

Red

50-100

Os métodos Crystal são focados nos

talentos e nas habilidades das pessoas;

Cada método Crystal é caracterizado

por uma cor, de acordo com o número

de envolvidos;

Crystal

37

As 7 propriedades do crystal


(C)

Crystal

Ambiente técnico

ágil

Entregas frequentes

Melhoria reflexiva

Comunicação

osmótica Fácil acesso

Segurança pessoal

Foco

39

Metodologia de desenvolvimento de sistemas dinâmicos (DSDM)


(D)

Seu objetivo é entregar softwares no tempo e com custo estimados através do

controle e ajuste de requisitos ao longo do desenvolvimento;

Metodologia de desenvolvimento de software baseada

em "Desenvolvimento Rápido de Aplicação" (RAD); Enfatiza

o envolvimento constante do usuário;

40

Metodologia de desenvolvimento de sistemas dinâmicos (DSDM) - princípios


(D)

1. envolvimento 2. autonomia 3. entregas

4. eficácia 5. feedback 6. reversibilidade

7. previsibilidade 8. Ausência de

testes no escopo 9.. comunicação

41

Metodologia de desenvolvimento de sistemas dinâmicos (DSDM) – principais técnicas


(D)

Timeboxing

MoSCoW

Prototipagem

Testes

Grupos de trabalho

Modelagem

Gerenciamento de configuração

Para fazer Em

andamento Completo

tarefa

tarefa tarefa tarefa

tarefa

tarefa

Sprint 1

Para fazer Em

andamento Completo

tarefa

tarefa tarefa tarefa

tarefa

tarefa

Sprint 2

MoSCoW Must

(Deve ter)

Should

(Deveria ter)

Could

(Poderia ter)

Would

(Desejável ter)

Must

Must

Must

Must

Must

Must

Must

Must

Should

Should

Should

Must

Want

Want

Could

Could

Tempo

Esforço

Programação pareada

43

Programação pareada


(A – Capítulo 15)

Alocar os desenvolvedores para trabalharem

em grupos de dois;

Ambos os desenvolvedores sentam no

mesmo computador e trabalham como uma

equipe para criar um requisito do produto;

Os desenvolvedores passam o teclado e o

mouse para colaborar. Como estão em pares,

torna-se mais fácil para encontrar e corrigir

erros rapidamente.

Desenvolvimento orientado a testes

Uma pesquisa do Departamento de Comércio dos EUA, publicada em 2002, revelou que falhas de software são tão

comuns e tão danosas:

45



(A – Capítulo 15 e D)

60 bilhões de prejuízo anual;

50% dos defeitos são encontrados somente no final do projeto;

1/3 poderia ter sido eliminado com uma estrutura de testes melhor;

46




Usando TDD, quando acabamos, realmente acabamos. Dificilmente precisa retornar ao código, pois, falhas já foram detectadas e corrigidas durante a confecção dos testes.

Método que começa com um desenvolvedor criando um teste para um

requisito que ele precisa criar.

Depois executa o teste, que deve falhar, pois, o requisito ainda não existe e

desenvolve até o sucesso do teste e então refatora o código.

A definição de finalizado é expressada através de critérios, isso é, temos etapas até que uma funcionalidade seja considerada pronta, essas etapas variam de projeto para projeto e geralmente são definidas no seu inicio;

Definir tais critérios não é uma tarefa fácil e deve ser uma concessão entre o product owner, time e scrum master.

Exemplos de critérios que podem ser utilizados:

Testar unitariamente (utilizar o desenvolvimento orientado a testes)

Testar a integração com outros componentes (quando for o caso)

Testar segundo os critérios de aceitação estabelecidos pelo cliente

Com a entrada da nova funcionalidade, avaliar a necessidade de fazer refatoração em algum módulo do sistema

Atualizar a documentação (quando necessário)

47

Definição de finalizado


(D)

Integração contínua

A integração contínua é uma abordagem que

mantém o código de todos integrados e constrói

estruturas de implementação juntamente com o

resto da aplicação;

49

Integração contínua



Ajuda a garantir a qualidade, permitindo que a

equipe de desenvolvimento verifique se existem

conflitos em uma base regular. A integração

contínua é essencial para testes automatizados

em projetos ágeis.

Refatoração

Refatoração é o processo de modificar um sistema de software para melhorar a estrutura interna do código sem alterar

seu comportamento externo;

51

Refatoração


(D)

Refatoração

Evita a deterioração

Aumenta o entendimento

do código

Facilita a manutenção

Evita inclusão de defeitos

Extreme programming (XP)

53

Extreme programming (XP)


(C)

• É chamada de extrema porque possui práticas comprovadas ao extremo:

• Se o teste for bom, vamos testar o

tempo todo; • Se as revisões de código são boas,

reveja o tempo todo; • Se o design é bom, refatore o tempo

todo; • Se a integração é boa, integre o tempo

todo; • Se a simplicidade é boa, faça a coisa

mais simples que poderia funcionar; • Se iterações curtas são boas, tornaremos

a mais curta possível.

Metodologia de desenvolvimento de

software, nascida nos Estados Unidos

ao final da década de 90;

Auxilia a criação de sistemas de melhor

qualidade, que são produzidos em

menos tempo e de forma mais

econômica que o habitual;

54

Valores do extreme programming (XP)


(C)

Comunicação

Coragem

Feedback

Respeito

Simplicidade

55

Práticas de XP


(A – Capítulo 4)

1. Jogo de

planejamento

5. Propriedade coletiva

do código

9. Design simples

2. Toda equipe

6. Ritmo sustentável

10. Desenvolvimento

orientado a testes

3. Padrões de

codificação

7. Programação em

pares

11. Integração contínua

4. Sistema de metáfora

8. Melhoria de design

12. Refatoração

13. Pequenos

lançamentos

Bus factor (Fator ônibus)

57

Bus factor (Fator ônibus)


(C)

O número mínimo de desenvolvedores que você tem a perder

antes de perder a capacidade de continuar o projeto (mesmo

adicionando novos desenvolvedores), é chamado de Bus Factor

(Fator ônibus) ou Truck Factor (Fator Caminhão).

1. Qual das seguintes é a melhor descrição da programação pareada (em pares)?

a. Um testador e um desenvolvedor trabalham juntos em uma história

b. O product owner e o desenvolvedor discutem a lógica

c. Dois desenvolvedores trabalham no mesmo terminal

d. O product owner e o desenvolvedor trabalham no mesmo terminal

2. Indique se a afirmação é verdadeira ou falsa: Com desenvolvimento orientado a teste, não saberemos se um requisito funciona corretamente, porque não podemos testar enquanto criamos o requisito.

a. Verdadeira

b. Falsa

58

Exercício 2


Capítulo 2 Práticas Scrum

Papéis no Scrum

61

Introdução aos papéis e responsabilidades

EXIN Agile Scrum Foundation- © HSI Institute. Todos os direitos reservados. (A – Capítulo 6)

Product owner Scrum master

Equipes de desenvolvimento

Time scrum

Stakeholders Agile mentor

Definição

Às vezes chamado de representante do cliente em ambientes não-scrum. É o especialista no

produto e nas necessidades e prioridades do cliente, por isto, toma decisões sobre o que

o produto faz e também aquilo que não faz. Responsável pelo backlog de produtos (product

backlog).

62

Product owner


(A – Capítulo 6)

Product

Owner

Desenvolve estratégia, direção e metas

Reúne, prioriza e gerencia os requisitos

do produto

Aceita, rejeita e

apresenta os trabalhos

completos

Responsável pelo orçamento e rentabilidade

Transfere conhecimento do produto e decide as datas de lançamento

63

Product owner


(A – Capítulo 6)

Características de um bom product owner

Responsabilidade Um bom product owner...

Responsável pelo orçamento e rentabilidade • Entende que as funcionalidades do produto podem oferecer o

melhor retorno sobre o investimento;

• Gerencia orçamentos de forma eficaz

Decide as datas de lançamento • Compreende as necessidades de negócios em relação a prazos;

Trabalha em conjunto com o time de desenvolvimento • Trabalha com a equipe de desenvolvimento para entender as

capacidades;

• Possui boa atuação com os desenvolvedores;

• Habilmente descreve as funcionalidades do produto;

• Aproveita a si mesmo para perguntas e esclarecimentos a cada dia.

Aceita ou rejeita trabalhos • Compreende requisitos e assegura que as funcionalidades

concluídas funcionam corretamente.

Apresenta os trabalhos completos no final de cada sprint • Claramente apresenta as realizações da sprint antes de a equipe

de desenvolvimento demonstrar a funcionalidade de trabalho

da sprint.

Características de um bom product owner

Responsabilidade Um bom product owner...

Fornece estratégia e direção para o projeto • Visiona o produto concluído;

• Firmemente entende a estratégia da empresa.

Fornece conhecimento do produto • Já trabalhou com produtos similares no passado;

• Compreende as necessidades dos usuários do produto.

Compreende as necessidades dos clientes e partes interessadas • Compreende os processos de negócios relevantes;

• Cria um canal de entrada e feedback contínuo dos clientes;

• Possui boa atuação com as partes interessadas da organização.

Gerencia e prioriza os requisitos do produto • Concentra-se em eficiência;

• Permanece flexível;

• É decisivo;

• Transforma o feedback das partes interessadas em funcionalidades

valiosas focadas nos clientes;

• É prático sobre a priorização de recursos financeiros valiosos,

funcionalidades de alto risco, e melhorias estratégicas do sistema.

Fornece estratégia e direção para o projeto • Já trabalhou com produtos similares no passado;

• Compreende as necessidades dos usuários do produto.

Definição

Às vezes chamado de facilitador do projeto em ambientes não-scrum; Responsável

por apoiar a equipe de desenvolvimento, abrindo barreiras organizacionais, e

mantendo os processos fieis aos princípios ágeis;

64

Scrum master


(A – Capítulo 6)

Scrum master

Atua como um treinador do processo

Promove cooperação entre as partes

interessadas e equipe scrum

Ajuda a remover os impedimentos do

projeto

Facilita a construção de um consenso na equipe scrum

Protege a equipe scrum de distrações

organizacionais

65

Scrum master


(A – Capítulo 6)

Características de um bom scrum master

Responsabilidade Um bom scrum master...

Defende os valores e as práticas Scrum • É um especialista em processos de scrum;

• É apaixonado por técnicas ágeis.

Remove obstáculos e evita interrupções • Tem influência organizacional e pode resolver problemas

rapidamente;

• É articulado, diplomático e profissional;

• É um bom comunicador e um bom ouvinte;

• É firme sobre a necessidade da equipe de desenvolvimento para

focar apenas o projeto e na sprint atual.

Promove uma estreita cooperação entre as partes interessadas

externas e a equipe scrum

• Olha para as necessidades do projeto como um todo;

• Evita panelinhas e ajuda a quebrar silos no grupo.

Facilita a construção de um consenso • Compreende técnicas para ajudar grupos de chegar a acordos.

É um líder-servo • Não precisa ou deseja ser responsável ou ser chefe;

• Garante que a equipe de desenvolvimento tem a informação que

necessita para trabalhar, usar ferramenta e acompanhar a evolução;

• Verdadeiramente deseja ajudar a equipe scrum.

Definição

Pessoas que criam o produto. Os programadores, testadores, designers, escritores e

qualquer outra pessoa que tem um papel de "colocar a mão na massa"

no desenvolvimento de produtos.

66

Time de desenvolvimento


(A – Capítulo 6)

Equipes de

desenvolvimento

Diretamente responsável pela criação de entregas

do projeto

Auto-organizada e auto-gerenciada Cross-funcional

Dedicada a um projeto para toda a duração do projeto

Idealmente alocada. Trabalhando em conjunto

na mesma área e escritório

67

Time de desenvolvimento


(A – Capítulo 6)

Características de um bom membro de equipe ágil

Responsabilidade Um bom membro de equipe ágil...

Cria o produto • Gosta de criação de produtos;

• É especializado em pelo menos um dos postos de trabalho

necessários para criar o produto;

Auto-organização e auto-gestão • Exala iniciativa e independência;

• Compreende como trabalhar com impedimentos para atingir

metas;

Multifuncional • Tem curiosidade;

• Voluntariamente contribui para áreas fora de sua especialidade;

• Gosta de aprender novas habilidades;

• Compartilha com entusiasmo o conhecimento;

Dedicado e alocado • É parte de uma organização que compreende os ganhos de

eficiência e eficácia associadas ao foco e equipes alocadas;

• O agile mentor é alguém que possui experiência na implementação de projetos ágeis e irá

compartilhar suas experiências através de feedbacks e conselhos valiosos.

• Atua como orientador e não faz parte da equipe scrum, sendo muitas vezes alguém fora

da organização – não tendo considerações pessoais ou políticas.

68

Stakeholders e agile mentor


(A – Capítulo 6)

Agile mentor

Stakeholders

• Os stakeholders são qualquer pessoa com interesse no projeto; O grupo é extenso e pode

incluir pessoas de diferentes departamentos, ou até mesmo de empresas

diferentes. Alguns exemplos:

o Clientes, pessoas técnicas, departamentos jurídicos, vendas, gerentes de contas,

marketing, especialistas, product owner, etc.

Definição

• O scrum não menciona o papel “gerente”. A equipe do scrum realiza a sua"auto-gestão" e é

apoiada pelo scrum master;

• A equipe possui orientações do product owner em termos do trabalho que é

necessário, bem como a sua priorização;

69

Gerente no scrum


(A – Capítulo 6)

Gerente no

Scrum

Se mantem atualizado e representa a equipe em

fóruns externos

Papel ativo na seleção e recrutamento de

membros

Desenvolve habilidades e administra os

reconhecimentos e recompensas

Protege a equipe nas disputas de priorização e

escalonamento

Apresenta a cultura e ajuda a entender o

projeto como um todo.

O scrum refere-se a cada membro da equipe como um "desenvolvedor" e não faz distinções dos papéis ou funções;

No entanto, com base em suas necessidades específicas, podemos querer considerar a atribuição de funções específicas, como por exemplo:

70

Outros papéis


(A – Capítulo 6)

• Mantém

repositório de

código;

• Automatiza

controle de

código fonte,

Gerente de

Configuração

Testador

automatizado

• Constrói

frameworks para

automação de

testes;

• Auxilia nos testes

orientados.

Arquiteto

• Decide sobre a

estrutura, modelo,

etc;

• Revisa o design e

códigos;

• Possui um “roteiro

técnico”.

71

Gerente de Projetos tradicional


(C)

Product owner Scrum master

Equipes de desenvolvimento

Gerente de Projetos

As responsabilidades de gerenciamento de

projetos são distribuídos entre os três papéis

de Scrum e não há gerenciamento de

projeto centralizado em Scrum.

Além dos valores do Manifesto Agile, os cinco valores fundamentais para as equipes scrum são:

72

Estabelecendo novos valores


(A – Capítulo 6)

Uma equipe de desenvolvimento ágil funciona de forma diferente de uma equipe usando uma abordagem waterfall;

Membros da equipe de desenvolvimento devem mudar seus papéis com base nas prioridades de cada dia;

73

Mudando a filosofia


(A – Capítulo 6)

Funcionalidade

cross Auto Gestão Comportamento

maduro Auto organização

Equipes de tamanho

limitado

74

Funcionalidade cross


(A – Capítulo 6)

Trabalham para

expandir habilidades

Ajudam quem enfrenta

obstáculos São flexíveis Colocam de lado os rótulos

organizacionais

A funcionalidade cross faz com que as equipes de desenvolvimento sejam mais eficientes e

também ajuda a eliminar pontos únicos de falha;

;

Em projetos tradicionais, membros experientes são estereotipados por ter uma única habilidade;

Abordagens ágeis juntam as pessoas envolvidas na criação de produtos em um grupo coeso;

75

Auto organização


(A – Capítulo 6)

Compromisso com as suas

metas de sprint

Identificar as suas tarefas Estimar o esforço para os

requisitos e tarefas. Concentrar na

comunicação

A auto-organização pode levar algum esforço extra em um primeiro momento, pois,

ao invés de cumprir as ordens dos gerentes de projeto, desenvolvemos a solução.

Equipes auto-organizadas tiram proveito do conhecimento e da vasta experiência dos

membros da equipe de desenvolvimento.

76

Autogestão


(A – Capítulo 6)

Permitir liderança

para que ela flua

Contar com processos e

ferramentas agéis

Relatar o progresso

regularmente de forma

transparente

Gerenciar problemas dentro do

desenvolvimento

Criar um contrato

na equipe e

inspecionar

Equipes de desenvolvimento ágeis devem possuir muito controle sobre como eles

funcionam;

A autogestão está intimamente relacionada com a auto-organização; O controle vem com a responsabilidade de garantir o sucesso do projeto;

77

Equipes de tamanho limitado


(A – Capítulo 6)

Limite o tamanho

da equipe

Incentive o desenvolvimento de

habilidades Facilite a boa

comunicação

Mantenha a equipe

em uma únidade

Promova a comunicação face

a face

Manter o tamanho da equipe em dez pessoas ajuda a ser coesa e evitar subgrupos;

Equipes agéis são pequenas, quanto maior o tamanho, maior a sobrecarga na gestão de tarefas e comunicação

78

Comportamento maduro


(A – Capítulo 6)

Tomar a iniciativa Sucesso e fracasso

como equipe Confiar na capacidade de

tomar boas decisões

As equipes de desenvolvimento podem adaptar o seu comportamento e aumentar

o seu nível de maturidade;

A responsabilidade e maturidade são itens necessários para entrega dos resultados dos projetos e na tomada de decisões.

1. Qual dos seguintes NÃO é adequado incluir na definição da função de um scrum master?

a. Garantir que a equipe entregue de acordo com o plano

b. Remover problemas e bloqueio para a equipe scrum

c. Treinador da equipe sobre as práticas de scrum

d. Organizar as reuniões scrum

2. No meio de uma iteração, um membro da equipe está confuso sobre como testar um requisito particular. Quem é responsável por resolver o problema?

a. Scrum master

b. Product owner

c. Gerente funcional

d. Cliente

79

Exercício 3


3. O líder de uma equipe de "auto-gestão" deve:

a. Construir a equipe certa e confiar nela para concluir o trabalho

b. Escutar a equipe e sempre obedecer aos seus desejos

c. Esforçar para um consenso dentro da equipe em todos os momentos

d. Acompanhar de perto o que a equipe está fazendo para garantir que ela pode entregar

80

Exercício 3


Eventos Scrum

Cada evento possui um tempo máximo pré-determinado, que garante uma quantidade adequada de tempo em cada evento sem desperdício.

82

Time-boxing


(D)

O time-boxing deve ser entendido como

um intervalo de tempo para realização de

uma atividade;

O conceito de time-boxing também é aplicado

para as sprints (com duração de 2 semanas ou

1 mês).

83

Time-boxing - vantagens


(D)

1. Reuniões

mais focadas

e objetivas,

conforme o

assunto a ser

trabalhado;

2. Os gestores e a

equipe possuem

melhor visão da

velocidade de

trabalho e de

quantos itens do

backlog

entregues em

cada sprint;

4. Eliminação do

desperdício

de tempo;

3. Equipe mais

focada nos

itens a

serem

entregues;

5. Evita

postergar

tarefas mais

difíceis de

serem

realizadas

6. Valorização

do tempo

de trabalho

da equipe;

7. Dedicação exclusiva para a atividade dentro do time-boxing.

84

Sprint


(D)

Product owner

1 2 3 4 5 6 7 8

Lista de

Prioridades:

funcionalidades,

bugs, etc.

Backlog do produto

Input de clientes,

Equipes, etc.

A equipe seleciona na

lista o que é capaz de

entregar até ao final

da sprint

Reunião de planejamento

da Sprint

Desmembramento

das tarefas

Backlog da sprint Data final da sprint e

entregáveis da equipe

não são alterados

Sprints de

1-4 semanas

Trabalho finalizado

Retrospectiva da sprint

Revisão da sprint A equipe

Scrum master

Reunião diária

scrum

Representa um time-boxing onde um conjunto de atividades devem ser executadas.

85

Sprint


(D)

Duração de

1-4 semanas

Step 1 Step 2 Step 3 Step 4

Metodologias ágeis são iterativas, dividem o trabalho em sprints;

Cada sprint é precedida por uma reunião de planejamento da sprint;

O desenvolvimento de cada sprint deve terminar na data conforme a previsão da time-boxing;

Em projetos ágeis, planejamentos são realizados ao longo de todo o projeto - e em uma base diária;

Durante a reunião diária scrum, cada membro da equipe de desenvolvimento realizam as três afirmações seguintes (com o foco de habilitar uma melhor coordenação da equipe):

Ontem, eu terminei [itens concluído];

Hoje, eu vou assumir [tarefas];

Meus impedimentos são [impedimentos];

86

Reunião diária scrum


(A – Capítulo 9)

Duração máxima de 15 minutos.

01

02

03

87

Reunião diária scrum


(D)

Product owner

1 2 3 4 5 6 7 8

Lista de

Prioridades:

funcionalidades,

bugs, etc.

Backlog do produto

Input de clientes,

Equipes, etc.




da sprint


da Sprint

Desmembramento

das tarefas



não são alterados

Sprints de

1-4 semanas

Trabalho finalizado



Scrum master

Reunião diária

scrum

A revisão da sprint é uma reunião para

analisar e demonstrar as histórias de

usuários concluídas pela equipe de

desenvolvimento.

É aberta a qualquer pessoa interessada

em rever as realizações da sprint. Isso

significa que todas as partes interessadas

tem a chance de ver o progresso sobre

o produto e fornecer feedback;

88

Revisão da sprint



Os feedbacks podem potencialmente serem

considerados itens de backlog;

Somente serão apresentados os itens

considerados como completos (desenvolvido,

testado, integrado e documentado).

89

Revisão da sprint


(D)

Product owner

1 2 3 4 5 6 7 8

Lista de

Prioridades:

funcionalidades,

bugs, etc.

Backlog do produto

Input de clientes,

Equipes, etc.




da sprint


da Sprint

Desmembramento

das tarefas



não são alterados

Sprints de

1-4 semanas

Trabalho finalizado



Scrum master

Reunião diária

scrum

Não utilize de power point. Consulte o backlog da Sprint;

Toda a equipe scrum deve participar da reunião;

Quem estiver interessado na reunião pode participar;

O product owner apresenta a meta da implantação, o objetivo da sprint, e as novas funcionalidades incluídas;

A equipe de desenvolvimento demonstra o que foi concluído durante a sprint.

A demonstração deve ser o mais próximo possível do ambiente de produção previsto;

As partes interessadas podem fazer perguntas e fornecer feedback sobre o produto demonstrado.

90

Revisão da sprint - reunião



Reunião onde o scrum master, o product owner, e a equipe de

desenvolvimento discutem como foi a realização da sprint e o que eles

podem fazer para melhorar a próxima Sprint;

Se a equipe scrum interage regularmente com as partes interessadas externas, então as percepções das partes interessadas podem ser valiosas;

O objetivo da retrospectiva é melhorar continuamente os processos;

Os resultados da retrospectiva da sprint podem ser únicos para a equipe.

91




2015

Calendário

92



(D)

Product owner

1 2 3 4 5 6 7 8

Lista de

Prioridades:

funcionalidades,

bugs, etc.

Backlog do produto

Input de clientes,

Equipes, etc.




da sprint


da Sprint

Desmembramento

das tarefas



não são alterados

Sprints de

1-4 semanas

Trabalho finalizado



Scrum master

Reunião diária

scrum

A importância do backlog

94

Backlog de produto


(A – Capítulo 8 e C)

A descrição dos requisitos;

Um backlog do produto deve conter

no mínimo

associadas ao projeto

histórias de usuários

todas as

Lista de

Product Owner

Responsável pela criação e

manutenção do backlog

dos produtos;

Equipe scrum

Utiliza o backlog no

planejamento de

implantação e durante

o projeto;

Ordem das histórias priorizadas

Estimativa de esforço

A lista de histórias de usuários da sprint priorizadas

A estimativa de esforço relativo para cada história de usuário;

As tarefas necessárias para desenvolver cada história de usuário;

O esforço, em horas, para concluir cada tarefa.

95

Backlog da sprint


(A – Capítulo 8)

• O backlog da sprint inclui: • A lista de histórias de usuários dentro da sprint em ordem de prioridade;

• A estimativa de esforço relativo para cada história de usuário;

• As tarefas necessárias para desenvolver cada história de usuário;

• O esforço, em horas, para concluir cada tarefa.

• Lista de histórias de usuários associadas a sprint atual e tarefas

relacionadas. Ao planejar a sprint, devemos: • Estabelecer metas para a sprint;

• Escolher as histórias de usuários que suportam essas metas;

• Quebras as histórias de usuários em tarefas específicas de desenvolvimento;

• Criar um backlog da sprint.

Backlog da sprint

Backlog da sprint

Simples descrição de um requisito do produto em termos do que essa exigência deve realizar para quem.

96

Histórias de usuário


(A – Capítulo 8 e C)

Título <nome para a história do usuário>

Como <usuário ou pessoa>

Eu gostaria de <ação>

Para que <benefício>

Quando eu <ação>

Isso acontece <ação> VS

I N V E S T

97

Histórias de usuários épicas



Research v/s Action;

Spike v/s Implementation;

Main flow v/s Alternate flow;

Buy v/s Build;

Batch v/s Onlin; Single user v/s Multi-user;

API only v/s User interface;

Generic UI v/s Custom UI;

Static v/s Dynamic;

Ignore errors v/s Handle errors;

Transient v/s Persistent; Etc..

Técnicas que podem ser utilizadas

A regra de ouro usual é de que "uma história pode ser concluída dentro da iteração".;

Épicas são requisitos muito grandes que suportam uma funcionalidade e contêm

várias ações. Torna-se necessário quebrá-las antes de criar um requisito de produto,

preservando a propriedade que cada história de usuário possua. previamente.

98

Refinando os itens do backlog de produto


(C)

Backlog de produto

Product Owner

Responsável por ordenar

(priorizar) os itens, e a

equipe de

desenvolvimento é a

responsável por estimar

Refinamento de Itens do Backlog representa o ato de rever e

revisar itens do Backlog de produto, normalmente envolve a

adição de detalhes, estimativas, e ordem para eles.

Espaço de trabalho

100

Espaço de trabalho


(D)

Um dos mais importantes requisitos de

espaço de trabalho é de ter a equipe

co-localizada em uma sala

individual, em vez de tê-las distribuídas

em seus departamentos organizacionais

1. Quem deve escrever os critérios de aceitação para uma história de usuário?

a. A equipe de desenvolvimento

b. O product owner

c. A equipe de teste

d. O scrum master

2. Qual dos seguintes itens podem estar contidos no backlog do produto?

a. Requisito funcional

b. Atividade de refatoração

c. Correção de bug para um defeito

d. Todas acima

101

Exercício 4


3. Qual é o tamanho máximo de uma história de usuário no scrum?

a. 5 dias-homem de trabalho

b. 20 pontos da história

c. 8 dias ideais

d. 5 dias-homem de desenvolvimento e 2 dias de teste

4. Qual dos seguintes é o requisito mais impróprio para ser adicionado no backlog?

a. O sistema deve fornecer uma resposta em 0,25 segundo

b. O sistema deve produzir um relatório de todas as transações feitas em um dia

c. O sistema deve ser implementado utilizando banco de dados oracle

d. O sistema deve funcionar corretamente no internet explorer, firefox e chrome

102

Exercício 4


5. Um membro da equipe quer discutir uma possível mudança para o processo de revisão de projeto para evitar erros. Qual é o melhor fórum para discutir isso?

a. Reunião diária scrum

b. Revisão da sprint

c. Retrospectiva da sprint

d. Planejamento na primavera

6. Qual das seguintes NÃO é verdadeiro sobre as reuniões diárias scrum?

a. Atender a essas reuniões é útil para os gestores para obter informações de status

b. Toda a equipe participa

c. A reunião não pode durar mais de 15 minutos

d. Conversas paralelas não são permitidas

103

Exercício 4


Capítulo 3 Planejamento e estimativas scrum

Planejamento scrum

Planejamento é fundamental para o sucesso do projeto ágil;

106

Introdução ao planejamento


(A – Capítulo 7)

Abandone o conceito: "Planeje o trabalho, em seguida, trabalhe de acordo com o plano“;

Adote o “just-in-time”;

107

Planejamento no agile – roadmap de valor


(A – Capítulo 7)

Descrição: As metas para o produto e seu

alinhamento com a estratégia da empresa

Proprietário: Product owner

Frequência: Pelo menos anualmente

Estágio 1 - Visão

Descrição: Visão holística das características dos

produtos que criam a visão do produto


Frequência: Pelo menos uma vez a cada 2 anos

Estágio 2 – Roadmap do produto

Descrição: Tempo da implantação para uma

funcionalidade específica do produto


Frequência: Uma vez a cada quatro meses

Estágio 3 – Plano de implantação 1 – 4 semanas

24 horas

Descrição: Estabelecer e coordenar as prioridades

do dia

Proprietário: Equipe de desenvolvimento

Frequência: Diariamente

Estágio 5 – Reunião diária scrum

Descrição: Demonstrar o produto de trabalho

Proprietário: Product owner e time de

desenvolvimento

Frequência: No final de cada sprint

Estágio 6 – Revisão da sprint

Descrição: Refinamento do ambiente e processos

para otimizar a eficiência

Proprietário: Equipe scrum

Frequência: No final de cada sprint

Estágio 7 – Retrospectiva da sprint

Estágio 4 – Planejamento da sprint

Descrição: Estabelecer metas e tarefas específicas

da iteração

Proprietário: Product owner e time de

desenvolvimento

Frequência: No início de cada sprint

108

Planejamento baseado em necessidades


(A – Capítulo 7)

Início

Amplo e

holístico

Estágio

avançado

Detalhamento

Maior

eficiência

109

Planejamento em vários níveis (planning onion)


(D)

Estratégia

Portfólio

Produto

Implantação

Iteração

Dia

110

Planejamento da versão de entrega


(A – Capítulo 7)

Plano de implantação Revisão do backlog

do produto

Implantação

Grupo de funcionalidades

do produto utilizáveis

a implantar na

produção

Planejamento Estabeler o conjunto

de funcionalidades e

data de lançamento

Versão do SW Grupo de funcionalidades

mínimas para comercialização,

que podemos efetivamente

implantar e promover no

mercado;

111

Planejamento da versão de entrega


(A – Capítulo 7)

1. Determine as

condições de

satisfação;

2. Estimar as histórias

de usuários; 3. Selecione a duração

da sprint;

4. Estime a velocidade;

5. Priorize as histórias

e data de

implantação;

Faça em qualquer sequencia

6. Selecione as

histórias e data de

implantação;

112

Planejamento da sprint


(A – Capítulo 8)

1 – 4 semanas

Sprint

Definição: Sprint é uma

consistente iteração de tempo

em que a equipe cria um grupo

específico de capacidades do

produto do começo ao fim;

Sprints devem ter o mesmo

comprimento dentro de um

projeto;

Sprints geralmente duram uma,

duas, três, ou quatro semanas;

• Planejamento da sprint no início de

cada uma delas;

• Reuniões diárias scrum;

• Tempo de desenvolvimento;

• Revisão da sprint e uma

retrospectiva da sprint no final de

cada sprint;

Cada sprint inclui o seguinte:

No primeiro dia de cada sprint, a equipe scrum deve realizar a reunião de planejamento da sprint;

113

A reunião de planejamento da sprint


(A – Capítulo 8)

Timeboxing: Não devem

durar mais que duas horas

por semana;

Dividir a sprint em duas partes:

• Definir a meta da sprint e

escolher histórias de

usuários da sprint;

• Quebrar as histórias de

usuários em tarefas

individuais.

114

Definindo a meta da sprint e escolhendo as histórias de usuários


(A – Capítulo 8)

Product owner A equipe

• No início da reunião de planejamento da sprint, o product owner e a equipe de

desenvolvimento devem determinar uma meta para a sprint.

• Através da meta da sprint determinamos as histórias de usuários que pertencem a

esta sprint. Também obtemos um outro olhar em relação as estimativas para essas

histórias e podemos propor alterações nas estimativas, para os casos onde seja

necessário.

• A segunda parte da revisão de histórias de usuários irá confirmar se as estimativas

de esforço para cada história de usuário estejam corretas. Ajustar a estimativa se

necessário.

• Uma vez que definimos a meta da sprint, histórias de usuários para a sprint, e o

compromisso com a meta, iremos para a segunda parte do planejamento da

sprint.

Scrum master

(auxlia)

Como um cliente de mobile banking, quero fazer login na minha conta para que eu possa ver o saldo da contas, transações anteriores e pendentes. Login e acesso as contas, visualizar balanço das contas, visualizar transações pendentes, visualizar transações prioritárias;

115

Quebrando histórias de usuários em tarefas individuais


(A – Capítulo 8)

Título

Como

Eu gostaria de

Para que

Desmembramento

das tarefas

A equipe

Após quebrar as histórias

em tarefas deve ser

atribuído um número de

horas para cada tarefa;

• Criar uma tela de autenticação contendo um nome de usuário e senha, com um botão enviar;

• Criar uma tela de erro para o usuário solicitando reinserir as credenciais;

• Criar uma tela de login (a inclusão da lista de contas será concluída na próxima história de usuário);

Exemplo:

Sprint 1: 25 por cento do

que a equipe pensa que

pode realizar.



pode realizar.



pode realizar.

Sprint 4 e demais: 100

por cento.

Velocidade, em termos ágeis, é a velocidade de trabalho de uma equipe de desenvolvimento;

É medida pelo número de pontos da história de usuário que a equipe de desenvolvimento completa em cada sprint;

116

Velocidade


(A – Capítulo 7 e 13)

Pontos da história de usuário são números relativos, que descrevem a quantidade de esforço necessário para desenvolver uma história de usuário;

Pontos da história é uma pontuação relativa para representar o valor e o esforço para cada requisito.

01

04

117

Pontos da história e o planning poker


(E – Capítulo 8)

3

A

5

B

7

C

3

E

3

D

0 0,5 1 2 5 3 8

13 20 40 100 ?

O significado dos valores é relativo – uma história de pontuação 8 demanda aproximadamente quatro vezes mais esforço que uma história de

pontuação 2. Porém o tempo de execução (trabalho) não importa, somente o esforço.

Para começar a estimar, a equipe deve pegar a história que julga ser a de menor esforço e atribuir a pontuação 2. Esta primeira história é chamada de

referência, e as demais histórias deverão seguir uma pontuação relativa a essa primeira.

No caso da equipe jogar as cartas para estimar, e a carta vencedora for a carta de interrogação ou a 100, a equipe deve devolver a história ou tarefa ao product owner;

Sem um acordo sobre a estimativa de uma história ou tarefa, mais uma rodada deve ser realizada, com breves discussões entre elas;

Caso o limite seja atingido sem o acordo, a equipe deve optar pela estimativa mais alta e encerrar as discussões da história;

Geralmente o número de rodadas limita-se no máximo a quatro por história;

Em uma equipe, a velocidade do mais lento deve ser considerada a velocidade da equipe toda.

118

Dicas – planning poker


(E – Capítulo 8)

01

02

03

04

05

119

Definindo horas por pontos de histórias


(E – Capítulo 8)

História 1

3 pontos História 2

3 pontos

História 3


1 ponto

Sprint 1

Sprint 2

Total de 10 pontos

10 pontos = 8 horas de esforço

História 1


10 pontos

História 3


10 pontos

Total de 40 pontos

40 pontos = 20 horas de esforço

É rápido e fácil;

Tomada de decisão é visível;

Experiência positiva sem um confronto.

120

Estimativa de afinidade


(E – Capítulo 8)

Muitas delas são provavelmente similares com uma quantidade similar de esforço para serem concluídas.

Categorize rapidamente as histórias de usuários e aplique as estimativas para essas categorias de histórias.

Vantagens:

O planning poker pode ser eficaz, mas e se temos muitas histórias de usuário?

121

Triangulação

Selecione o conjunto de histórias e escreva uma história em uma nota de post-it ou em um cartão;

Solicite aos membros da equipe para classificar as histórias da menor a maior;

O exercício pode exigir alguma discussão e iterações para que a equipe concorde com a ordem

da classificação.

122

Estimativa de afinidade - processo


(E – Capítulo 8)

Menor Maior

Itens

minúsculos

Itens

pequenos Itens grandes Itens gigantes

Forneça para a equipe alguns "baldes" para que seja depositado as histórias. Com tamanhos de roupas ou pontos.

123

Estimativa de afinidade - processo


(E – Capítulo 8)

PP

>0

P

>5

M

>10

G

>15

GG

>20

A história somente pode estar contida em um balde. Colete as informações e faça um sumário.

Dias ideais não tem distrações como: email, atividade pessoal, paradas pra café, etc

124

Dias ideais


(F)

Quantos dias durante uma semana podemos

considerar como dias ideais de trabalho?

Este item deve ser considerado e ajustado para que o planejamento e capacidade tenha sucesso.

O agile usa seis horas ideais por dia (para um dia com oito horas) de cada membro da equipe.

125

Ordenando os itens do Backlog de Produto

Product owner

Cabe ao Product Owner encontrar a melhor maneira possível de ordenar os itens do Backlog de Produtos, mas os critérios habituais estão relacionados com os seguintes conceitos:

Benefícios; Custos; Riscos;

1. Se as novas funcionalidades estão sendo adicionadas em sprint de 3 semanas, quando deveria ocorrer o teste para essas funcionalidades?

a. Na sprint subsequente

b. Assim que o desenvolvedor terminar a funcionalidade ou parte da funcionalidade

c. Durante a última semana da sprint

d. Quando todos as funcionalidades estiverem concluídas e entregues formalmente pela equipe de desenvolvimento

2. Quem é o mais adequado para facilitar uma reunião de retrospectiva da sprint?

a. Product owner

b. Scrum master

c. Cliente

d. Gerente

126

Exercício 5


3. Qual papel é responsável por ordenar os itens do product backlog (backlog de produtos?

a. Scrum Master

b. Equipe de desenvolvimento

c. Coach

d. Product Owner

4. Liste 3 vantagens da utilização da estimativa de afinidade

1. _____________________________________________________________

2. _____________________________________________________________

3. _____________________________________________________________

127

Exercício 5


Capítulo 4 Monitorando projetos com scrum

Monitoramento scrum

A sprint pode não precisar de todos os requisitos e tarefas do backlog da sprint para

ser concluída;

Uma sprint de sucesso deve possuir uma funcionalidade do produto de trabalho que cumpre com as metas da sprint e atenda a

definição da equipe scrum de pronto: desenvolvido, testado, integrado e

documentado;

130

Taxa de sucesso das metas das sprints



Ao longo do projeto, a equipe scrum pode controlar a frequência com que ela consegue atingir as metas da sprint e utilizar as taxas de

sucesso para saber se a equipe está amadurecendo ou precisa corrigir seu curso;

Taxas de sucesso da sprint é um ponto de partida útil para a inspeção e adaptação.

Um defeito fugitivo é um defeito que não foi encontrado pela equipe de garantia de qualidade;

Normalmente esses defeitos são encontrados por usuários finais após a versão de lançamento.;

A métrica de defeito é utilizada para determinar o número de novos defeitos fugitivos ao longo do período de tempo (dia, semana e mês).

131

Defeitos



x

x

Projetos ágeis devem ser realizados mais rápido do que projetos tradicionais;

Ao iniciar o desenvolvimento mais cedo e cortar os bloatware - requisitos desnecessários - equipes de projetos ágeis podem entregar produtos mais rapidamente;

Medir a duração total do projeto ajuda a demonstrar a eficiência.

132

Duração total do projeto



Tempo para o mercado é a quantidade de tempo que um projeto ágil leva para fornecer valor ao lançar produtos de trabalho e funcionalidades para os usuários.

133

Tempo para o mercado



As organizações podem perceber

valor de algumas maneiras

Quando um produto gera renda diretamente, o seu valor é o dinheiro que ele faz;

Quando um produto é para o uso interno de uma organização, o seu valor será a capacidade dos funcionários de utilização do produto, e conterá fatores subjetivos com base no que o produto pode fazer;

Os custos dos projetos ágeis estão diretamente relacionados a sua duração. Como os projetos ágeis são mais rápidos do que projetos tradicionais, eles também podem custar menos.

As organizações podem usar métricas de custo de projeto para planejar orçamentos e determinar o retorno sobre o investimento.

134

Custo total do projeto



Retorno sobre o investimento (ROI) é a renda gerada pelo produto, menos os custos do projeto. Em projetos ágeis, o ROI é fundamentalmente diferente do que é em projetos tradicionais.

Projetos ágeis têm o potencial de gerar renda em sua primeira versão e pode aumentar a receita em cada novo lançamento.

Gráficos utilizados no scrum

Poderosa ferramenta para a visualização do progresso e do trabalho restante. O gráfico mostra o seguinte:

• O trabalho (em horas) no primeiro eixo vertical;

• Tempo, em dias, no eixo horizontal;

136

Gráfico burn-down


(A – Capítulo 9)

Com o gráfico, podemos dizer como o trabalho está progredindo

• Esperado;

• Mais complicado;

• Menos complicado;

• Não participante;

• Mentir;

• Falhando rápido;

http://www.google.com.br/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&docid=oABhLhyAdKCoDM&tbnid=puQTbbh7a8FnMM:&ved=0CAUQjRw&url=http://backlogtool.com/help/usersguide/burn-down-chart/userguide289/&ei=xqDdU5LyC-XMsQTuv4HgDw&bvm=bv.72197243,d.cWc&psig=AFQjCNELS55KxKVwmoyKgQfG2Lxhi2ihew&ust=1407119914591583

137

Burn-Down Bars


(A – Capítulo 9)

138

Burn-Up Charts


(A – Capítulo 9)

139

Kanban


(A – Capítulo 9)

140

Diagrama de fluxo cumulativo


(A – Capítulo 9)

Um dos gráficos que lhe dão uma visão geral do que está acontecendo em um projeto ou produto de trabalho é o gráfico de diagrama de fluxo cumulativo.

Por um lado, no diagrama de fluxo cumulativo encontraremos informações sobre o estado típico de trabalho: o quanto de trabalho está completo, em andamento e em backlog, e qual é o ritmo do progresso, etc.

O verde mostra quantos itens foram entregues ao longo do tempo. Tudo o que está entre o azul e as curvas verdes é o material que está em testes. A área entre o vermelho e as linhas azuis mostram quantos itens estão em desenvolvimento. Finalmente, a parte de cima abaixo da linha laranja é o atraso - quantos itens ainda não foram iniciados.

A codificação de cores baseada em semáforo representa a urgência. O tamanho de cada box é relativo ao número de pontos de história que ele possui.

141

Diagrama parking lot


(A – Capítulo 9)

Em

andamento

Prazo perdido

No

prazo

Conta o número de novos defeitos fugitivos encontrados ao longo período do tempo (dia, semana, mês).

Uma boa apresentação é um gráfico de barras simples, onde cada barra mostra o número de defeitos fugitivos que foram encontrados (dia / semana / mês / trimestre / ano).

142

Gráfico de defeitos fugitivos


(A – Capítulo 9)

0

5

10

15

20

25

30

35

40

8/1/2014 9/1/2014 10/1/2014 11/1/2014 12/1/2014

Um gráfico de velocidade mostra a quantidade de esforço que a equipe relatou para completar cada sprint.

143

Gráfico de velocidade


(A – Capítulo 9)

144

Calendário niko niko


(A – Capítulo 9)

Ferramenta que torna visível o estado de espírito, sentimentos, motivação e moral da equipe.

É um grande display de informações críticas da equipe localizado em um local onde as pessoas possam visualizar e obter informações facilmente sobre como está o bom andamento do trabalho ao longo do tempo.

Ele mostra aos leitores as informações que eles precisam, sem ter que

pedir a alguém. Isso significa mais comunicação com menos interrupções e atualizações fáceis de se manter.

145

Radiador de informações


(A – Capítulo 9)

1. Qual das seguintes indica o número de defeitos que foram detectados pelo cliente?

a. Defeitos fugitivos

b. Defeitos densos

c. Defeitos por iteração

d. Regressão de defeitos

2. Após várias rodadas de planning poker, a equipe é incapaz de chegar a um acordo sobre a estimativa de uma história. Metade das pessoas acham que a história é de 8 pontos, e a outra metade está inclinando-se para 13 Qual estimativa deve ser utilizada?

a. 8

b. 13

c. A equipe deve decidir

d. O scrum máster decide

146

Exercício 6


3. O product owner pergunta para um membro da equipe o quanto de tempo que uma história tomaria se ele estivesse trabalhando somente nesta história. Qual medida de estimativa deve ser utilizada?

a. Dias ideias

b. Dias de calendário

c. Pontos de função

d. Pontos de histórias

4. Qual das seguintes alternativas melhor expressa o termo "implantação"?

a. Uma timebox de 1 a 4 semanas, que resulta no próximo incremento de software

b. A decisão de portfólio que indica a direção futura do produto

c. Um projeto que resulta na criação de uma versão de software oficial e suportado

d. A implantação de teste do software dado a um cliente interno para validar histórias

147

Exercício 6


5. Durante uma sprint, a equipe completou cinco histórias que possui os seguintes pontos de história 5, 8, 3, 8 e 13, respectivamente. 2 outras histórias possuem os seguintes pontos de história 8 e 2 e estão 50% completas. Qual é a velocidade da equipe?

a. 37

b. 42

c. 47

d. Não pode ser determinada à partir dos dados apresentados

6. Na segunda semana de uma sprint de duas semanas, a equipe percebe que ela não pode completar todos as histórias do backlog da sprint e está tentando descobrir qual funcionalidade pode ser retirada. Quem é responsável por tomar essa decisão?

a. Scrum máster

b. Product owner

c. Cliente

d. Gerrente

148

Exercício 6


7. Qual das seguintes indica o número de defeitos que foram detectados pelo cliente?

a. Defeitos fugitivos

b. Defeitos densos

c. Defeitos por iteração

d. Regressão de defeitos

8. Qual das seguintes NÃO é uma das melhores práticas para a utilização de métricas em scrum?

a. Acompanhar as tendências, não somente os números absolutos

b. Utilize as métricas para fazer metas individuais mensuráveis

c. Foco sobre o assunto, não no número

d. Simples de interpretar

149

Exercício 6


9. Quem é o responsável por monitorar um projeto scrum?

a. Gerente

b. Scrum máster

c. Equipe

d. Product owner

150

Exercício 6


Capítulo 5 Conceitos avançados do Scrum

Scrum em diferentes situações

153

Scrum em grandes projetos


(G)

45%

Restrição do número de

pessoas em uma equipe

scrum

Medição de desempenho da

equipe

Reunião scrum com 100 pessoas, 9

segundos?

Gerenciamento do escopo da

sprint

Divisão das pessoas em duas equipes ou mais;

154

Scrum of scrums


(G)

Equipe A

Equipe B

Equipe C Equipe de 30 pessoas

• Falta de visão unificada do

produto/serviço;

• Redundância de trabalho;

• Comunicação falha;

• Integration hell (diferentes partes do

produto com equipes diferentes);

• Dependências entre tarefas de times

diferentes;

• Gestão de mudanças complexas;

• Etc;

Problemas que podem ser enfrentados:

155

Técnicas para grandes projetos – replicação de papéis-chave


(G)

Equipe A Scrum master A Lider técnico A Equipe C Scrum master C Lider técnico C

Equipe B Scrum master B Lider técnico B

Product owner PMO Arquiteto chefe

156

Técnicas para grandes projetos – alinhamento das iterações


(G)

Semana 1 Semana 2 Semana 3 Semana 4

Equipe A Equipe A Equipe A Equipe A

Equipe B

Equipe C Equipe C

157

Técnicas para grandes projetos – reuniões diárias scrum escalonadas


(G)

Equipe A

Equipe B

Equipe C

Scrum of scrums

Lider técnico A

Lider técnico B

Lider técnico C

09:00

09:15

09:30

09:45

Trabalhando com equipes

distribuídas

Uma equipe scrum dedicada localmente é o mundo ideal para os projetos ágeis. No entanto, às vezes não é possível ter uma equipe scrum trabalhando em um só lugar.

As pessoas com as competências adequadas para um projeto podem trabalhar em diferentes escritórios; Existem ferramentas de colaboração, que permitem que as técnicas ágeis ainda sejam utilizadas;

159

Introdução



China Japão Coréia do Sul Índia Reino Unido Alemanha

160

Modelos de equipes scrum distribuídas



Scrums integrados

Scrum of Scrum

distribuído

Scrum isolados

Taxa de sucesso de equipes dedicadas e distribuídas scrum

Equipe scrum dedicada 83%

Equipe scrum distribuida mas fisicamente acessível

72%

Equipe scrum distribuída em todas as geografias

60%

Fonte: Agile Adoption Rate Survey Results (Scott W. Ambler, Ambysoft, Copyright© 2008).

161

Boas práticas com equipes scrum distribuídas

Use tecnologias de videoconferência para simular conversas face-a-face;

Se possível, envie os membros da equipe scrum para reunião

pessoalmente em um local central;

Use uma ferramenta de colaboração on-line;

Inclua imagens dos membros da equipe scrum 'em ferramentas de

colaboração on-line;

Seja consciente e flexível com as diferenças de fuso horário;

Se temos alguma dúvida sobre uma conversa ou um e-mail, peça

esclarecimentos;

Esteja ciente das diferenças linguísticas e culturais entre os membros.

Discuta assuntos não relacionados ao trabalho;



39%

79%

22%

66%

86%

162

Boas práticas com equipes scrum distribuídas


(A – Capítulo 2)

1. Priorizar a satisfação

do cliente através da

entrega adiantada e

contínua de valor

6. Método mais eficiente em transmitir informações é através de conversa cara a cara.

4. Pessoas de

negócios e

desenvolvedores

em conjunto no

projeto.

3. Entregar software

com frequência em

períodos curtos

7. Software funcional é a medida primária de progresso.

8. Software funcional é a medida primária de progresso.

9. Processos agéis promovem ambiente sustentável e constante.

12. Refletir regularmente para ser mais efetivo e ajustar e otimizar o comportamento.

Scrum para projetos de manutenção

e contratos de preço fixo

164

Scrum em projetos de manutenção


(D)

Práticas que podem ser utilizadas para este tipo de projetos com pouca ou nenhuma

adaptação

• Reuniões diárias scrum;

• Scrum of scrums;

• Radiadores de informações;

• Uso de páginas wiki para colaboração com o

cliente e equipe;

• Workshops de requisitos para a melhor

compreensão de defeitos complexos por

parte da equipe;

• Revisão e retrospectiva;

Metodologias ágeis

podem ser utilizadas

para projetos de

manutenção

(correções e

melhorias);

É importante entendermos a diferença das diferentes abordagens de projeto em um ambiente ágil:

165

Estrutura de custos de projetos ágeis



Projetos de preço fixo

• Fornecedor trabalha com o produto e cria lançamentos até que seja utilizada todo o dinheiro ou tenha sido entregue as características do produto;

Projetos de tempo fixo

• .Com projetos de tempo fixo, determinamos os custos com base no custo da equipe do fornecedor para a duração do projeto, juntamente com todos os custos de recursos adicionais, tais como hardware ou software;

Projetos de tempo e materiais

• Dentro de projetos de tempo e materiais, o trabalho com o fornecedor dura até que a funcionalidade do produto esteja completa o suficiente, sem levar em conta o custo total do projeto;

Projetos que não podem exceder

• São projetos em que o tempo e os materiais possuem um limite de preço fixo;

166

Contratos



Scrum master

O scrum master é responsável

por auxliar na criação de um

contrato (jurídico deve

trabalhar em conjunto);

Deve adicionar valor ao

contrato, trabalhando de

maneira estreita com o

fornecedor para melhor

alinhamento;

Negocia detalhes do contrato e

realiza encaminhamento para

aprovações internas;

167

Contratos



• A descrição do trabalho que o fornecedor irá entregar;

• Abordagens ágeis que o fornecedor poderá utilizar. Elas podem incluir :

• Reuniões que o fornecedor irá participar

• Entrega de funcionalidade de trabalho no final de cada sprint;

• A definição de feito;

• Artefatos que o fornecedor irá fornecer;

• As pessoas que o fornecedor irá alocar para o projeto.

• Se o fornecedor irá trabalhar no local de sua organização;

• Se o fornecedor irá usar o seu próprio scrum master e product owner.

• A definição do que pode constituir o final do engajamento: o final de um

orçamento fixo ou tempo fixo, ou suficientemente completo, a

funcionalidade de trabalho;

• Se o fornecedor não utiliza de abordagens ágeis, descrever como o fornecedor

e o trabalho do fornecedor irá integrar com a equipe e sprints desenvolvimento

do comprador.

Um contrato deve incluir no mínimo:

Transição de equipes ou projetos

para scrum

169

Transição para equipes ou projetos para scrum



Comece com uma ou poucas

equipes que estejam dispostas

a utilizar as metodologias

ágeis

Passo 1

Entenda o que você está tentando alcançar e

encontre uma maneira de efetuar a medição

Passo 2

Faça um piloto utilizando do maior tempo

possível

Passo 3

Esteja preparado para ajudar Passo 4

Compreenda que algumas equipes

e pessoas não vão gostar

Passo 5

1. Qual das seguintes NÃO está correta em relação a uma reunião scrum of scrums?

a. Os scrum masters de cada equipe realizam uma reunião diariamente

b. É um mecanismo para coordenar o trabalho de várias equipes

c. Possui foco nas inter-dependências

d. Não pode estar restrito apenas às questões utilizadas na reunião diária scrum

2. Todas as seguintes são boas práticas para o gerenciamento de projetos Scrum distribuídos, EXCETO:

a. Utilização de tecnologia para melhorar a colaboração

b. Definir um ponto único de contato para a comunicação entre sites

c. Realizar reuniões visuais utilizando de webcams

d. Compartilhamento da dor do fuso horário, enquanto realizar o agendamento de reuniões

170

Exercício 7


3. Se o cliente pede uma mudança, enquanto estamos trabalhando em um projeto scrum de preço fixo, qual é a melhor resposta?

a. Mudanças não são permitidas em um projeto de preço fixo

b. Mudanças são sempre bem-vindas e livres em um projeto scrum

c. Se a mudança é uma funcionalidade que ainda não foi iniciada, ela pode ser realizada

d. Ignorá-la o maior tempo possível até que o cliente se esqueça

171

Exercício 7


Conteúdo extra – Dez benefícios do gerenciamento

de projetos ágil

As práticas ágeis possuem diversos benefícios para as organizações. As principais são:

173

Os dez benefícios do gerenciamento de projetos ágil



Melhor qualidade do produto

Maior satisfação do cliente

Aumento da moral da equipe

Maior colaboração e propriedade

Estruturas personalizadas de equipe;

Métricas mais relevantes

Melhoria da visibilidade do desempenho

Melhor controle do projeto

Melhor previsibilidade do projeto

Riscos reduzidos

Métodos ágeis possuem excelentes salvaguardas para certificar que a qualidade seja a mais alta quanto seja possível.

174

Melhor qualidade do produto



Utilizando de uma abordagem proativa para a qualidade do produto;

Abraçando a excelência tecnológica, bom design e desenvolvimento sustentável;

Definindo e elaborando os requisitos em tempo;

Construindo critérios de aceitação em histórias para os usuários (casos de uso);

Incorporando a integração contínua e testes diários no desenvolvimento;

Utilizando ferramentas de teste automatizado;

Realizando retrospectivas da Sprint e a definição de pronto;

Equipes de projetos ágeis estão empenhadas em produzir produtos que satisfaçam os clientes;

175

Maior satisfação do cliente



Backlog atualizado

Funcionalidades

Satisfação do cliente

Parceria

Auto financiamento

Time to market

Product owner

Possuindo potencial para projetos de auto-financiamento;

Colaboração com os clientes em nível de

parceria;

Oferecendo produtos ao mercado o mais

rapidamente possível;

Determinação de um product owner que será um especialista

em requisitos do produto;

Mantendo o backlog de produto atualizado e priorizado;

Demonstrando a funcionalidade do trabalho para os clientes em

cada revisão da sprint;

Trabalhar com pessoas felizes que gostam de seus empregos pode ser gratificante e recompensador;

176

Aumento da moral da equipe



Uma equipe de autogestão permite que as pessoas sejam criativas, inovadoras e reconhecidas;

Concentrando-se em práticas de trabalho sustentáveis;

Incentivar uma abordagem de líder-servo auxilia as equipes scrum na sua autogestão

Ter um scrum master para servir a equipe scrum, remover os obstáculos e proteger a equipe;

Proporcionar um ambiente de apoio e confiança aumenta a motivação e a moral;

Tendo conversas face-2-face ajuda a reduzir a frustração de falhas na comunicação;

Funcionalidades cross permite que a equipe aprenda novas habilidades e cresçam;

A autogestão toma decisões que normalmente seriam feitas por um gerente nas mãos dos membros da equipe scrum;

Isso significa que os projetos ágeis podem fornecer oportunidades únicas para personalizar estruturas de equipe e ambientes de trabalho;

177

Estruturas personalizadas de equipe



As equipes scrum podem fazer suas próprias regras sobre com quem eles trabalham e como elas funcionam;

Equipes scrum podem tomar decisões sob medida para proporcionar o equilíbrio entre a vida profissional e pessoal;

As equipes de desenvolvimento podem organizar a sua estrutura de equipe em torno de pessoas com estilos e personalidades de trabalho específicos;

As equipes de desenvolvimento também podem se organizar em grupos de habilidades específicas;

Quando as equipes de desenvolvimento assumem a responsabilidade pelos projetos e produtos, podem produzir grandes resultados;

178

Maior colaboração e propriedade



Mantendo a equipe, product owner e o scrum master trabalhando em conjunto;

Realizando reuniões de planejamento de sprint;

Realizando reuniões diárias scrum lideradas pela equipe de desenvolvimento;

Conduzindo revisões da sprint;

Realizando retrospectivas da sprint;

Trabalhando em um ambiente colaborativo em conjunto;

Tomando decisões por consenso;

As métricas de projetos ágeis para estimar o tempo, custo, medir o desempenho e tomar decisões de projeto são mais relevantes e precisas do que as métricas de projetos tradicionais;

179




Estimativas

Custos


Determinar a

equipe

Refinar o tempo

Gráficos diários

Cronograma real

Refinar o esforço estimado, tempo e custos em uma base regular;

Determinar a equipe de desenvolvimento que irá

realizar o trabalho

Atualizar os gráficos todos os dias visando fornecer

métricas precisas;

Determinar cronogramas de projetos e orçamentos com base no desempenho

e capacidade de cada equipe;

Utilizar de estimativas relativas, em vez de horas ou dias;

Comparar o custo de desenvolvimento futuro com o

valor do desenvolvimento futuro;

Em projetos ágeis, cada membro da equipe do projeto tem a oportunidade de saber como o projeto está indo a qualquer momento;

180

Melhoria da visibilidade do desempenho



Fornecer informações diariamente em relação ao progresso

e problemas do desenvolvimento.

Comunicação aberta e honesta entre todas as

partes

Proporcionando medidas de desempenho diárias da

sprint

Demonstrar as realizações na revisão de sprint

Fisicamente mostrar o progresso através de placas na

área da equipe

Progresso informado

Reconhecimento da equipe

Resultados por sprint

Comunicação

Sprints

Equipes de projetos ágeis possuem oportunidades de controlar e corrigir o desempenho do projeto;

181

Melhor controle do projeto



As equipes podem ajustar as prioridades durante todo o projeto;

Abraçar a mudança permite que a equipe do projeto tenha reações a fatores externos;

Reuniões diárias scrum permite que a equipe scrum resolva rapidamente os problemas;

Atualizações diárias do backlog de sprints significa que os gráficos irão refletir com

precisão o desempenho da sprint;

Conversas face-2-face remove obstáculos para a resolução de falhas de comunicação;

Revisões de sprint permite aos participantes do projeto visualizarem os produtos de trabalho;

Retrospectivas da sprint permite que a equipe scrum faça ajustes no final de cada sprint;

Técnicas ágeis de gerenciamento de projetos ajudam a prever com precisão no decorrer do projeto;

182

Melhor previsibilidade do projeto



Tamanho dos sprints

Velocidade

Manter os mesmos tamanhos dos sprints e equipe de

desenvolvimento durante o projeto

Utilizar a velocidade da equipe de desenvolvimento

individual;

Utilizar as informações das

reuniões diárias scrum;

Reuniões diárias

Técnicas ágeis de gerenciamento de projetos praticamente eliminam a chance do fracasso absoluto do projeto ;

183

Riscos reduzidos



Geração de receita rápida com projetos de auto financiamento

Desenvolvendo sprints

Sempre ter um produto de trabalho

Desenvolvimento de requisitos para a definição por completo para cada sprint

Fornecimento de feedback constante

Receita rápida

Feedback constante

Requisitos por sprint

Produto

Sprints

• A – Agile Project Management for dummies

• B – Website scrum.org

• C – DSDM website http://www.dsdm.org

• D – High IT internal documentation

• E – Scrum e PMBOK unidos no gerenciamento de projetos – Fabio Faria

• F – Website https://agilo.agilofortrac.com/agilo-help/scrum/IdealHour

• G – Website Leandro Faria

184

Bibliografia


https://agilo.agilofortrac.com/agilo-help/scrum/IdealHour

Muito obrigado em escolher um treinamento oficial High IT!liveuniversity.com/downloads/Material -...

Documents

Transcript of Muito obrigado em escolher um treinamento oficial High IT!liveuniversity.com/downloads/Material -...