seja ágil com scrum

Jonathan Maia – PSM I TM

jonathanmaia@gmail.com

www.eunati.com.br

Gerenciamento de projetos e atividades com Scrum

Jonathan Maia - Professional Scrum Master I

www.eunati.com.br

Seja Ágil Com Scrum

www.eunati.com.brSeja Ágil Com Scrum

3Jonathan Maia – PSM I TM

www.eunati.com.brUtilização deste material

➔Com exceção dos textos e figuras de fontes externas, o conteúdo desta apresentação está sob a licença:

➔ Creative Commons Attribution – NonCommercial - ShareAlike 4.0 International (CC BY-NC-SA 4.0);

➔ Resumo da licença e texto legal:

https://creativecommons.org/licenses/by-nc-sa/4.0/

https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode

➔Este material pode ser alterado ou distribuído gratuitamente, desde que:

➔ Não seja para fins comerciais; ➔ Não seja utilizado em ambientes educacionais com

fins lucrativos;➔ Os créditos sejam mantidos ao autor, com a

presença dos slides 2, 6 e 7;➔ Bom proveito!

➔O material deste curso pode ser utilizado para:

➔ Estudos e disseminação de conhecimentos sobre agilidade e Scrum;

➔ Preparações para certificações Scrum;➔ Preparações para concursos públicos.

www.eunati.com.brMini Currículo

➔Jonathan Maia:➔ Certificação Professional Scrum Master I TM (2015);➔ Pós Graduação em Gerência de Projetos de TI pela

Universidade do Sul de Santa Catarina (2010-2011);➔ Graduação em Ciências da Computação pela

Universidade Federal do Ceará (2004-2008);➔ Atua nas áreas de desenvolvimento de sistemas enterprise e gerenciamento de projetos, com experiência prévia em data warehousing e infraestrutura de redes;

www.eunati.com.brMini Currículo

➔Jonathan Maia:➔ Analista de TI do TRT Ceará (2010 até hoje); ➔ Instrutor credenciado na Escola Judicial do TRT

Ceará;➔ Ex Analista de TI da Dataprev e do Serpro (2009);➔ Ex Estagiário e Analista de TI do PoP Ceará da

Rede Nacional de Ensino e Pesquisa (2005-2009);➔ Blog: www.eunati.com.br➔ LinkedIn: https://goo.gl/Jii7Ur➔ E-mail: jonathanmaia@gmail.com

www.eunati.com.brSumário

➔ Introdução;➔Gerenciamento de projetos;➔Agile;➔Scrum - inspirações;➔Estrutura do framework;➔Equipe e papéis;➔Eventos;

www.eunati.com.brSumário

➔Artefatos;➔Técnicas;➔Na prática;➔No Brasil e governo➔Conclusão;➔Recursos extras;➔Bibliografia.

Introdução

www.eunati.com.brIntrodução

➔“Se o machado está cego e sua lâmina não foi afiada, é preciso golpear com mais força; agir com sabedoria assegura o sucesso”

Rei Salomão (935 AC)

➔"Aquele que tudo defende, nada defende"

Frederico II da Prússia (Século XVIII)

➔XGH - eXtreme Go Horse [1]:➔ Ausência total ou parcial de gerenciamento de

projetos e atividades.

➔Princípios XGH:➔ Pensou, não é XGH;➔ Existem 3 formas de resolver um problema: a

correta, a errada e a XGH, que é igual à errada, só que mais rápida;

➔ XGH é totalmente reativo;➔ XGH não tem prazo;➔ Quanto mais XGH você faz, mais precisará fazer;➔ Até surgir um pouco de ordem, XGH não é

perigoso.

Gerenciamento de projetos

www.eunati.com.brGerenciamento de projetos

➔Por que gerenciar projetos ?➔ Compromisso dos envolvidos (stakeholders);➔ Comunicação eficiente;➔ Obter os recursos necessários;➔ Satisfação geral;➔ Alcançar resultados almejados.

➔Guia PMBOK [2]:➔ “Projeto é um esforço temporário empreendido para

criar um produto, serviço ou resultado exclusivo”

➔Projetos típicos utilizam modelo cascata/cachoeira.

➔Características (C) e Problemas (P) do gerenciamento tradicional e do modelo cascata.

➔C: Planos e cronograma detalhados no início do projeto através de documentos, gráficos e diagramas:

➔ P: Quantos diagramas de Gantt elaborados no início do projeto e corretos você já viu ?

➔ P: Pessoas contratadas só para atualizar artefatos;➔ P: Frustração porque planos não se concretizam;➔ P: Artefatos enormes que não serão lidos por

ninguém (sem significado);➔ P: Artefatos tornam-se mais importantes que

produtos (mapa vs terreno).

➔C: Especificação detalhada e antecipada dos requisitos. BRUF (Big Requirements Up Front):

➔ P: Difícil detalhar requisitos no começo do projeto;➔ P: Como cliente só pode pedir uma vez, pede mais

requisitos que os necessários;➔ P: Custos excessivos para cliente.

➔C: Riscos, costumeiramente, não são gerenciados diariamente:

➔ P: Riscos negativos são as causas do fracasso de projetos.

➔C: Mudanças durante o projeto são caras:➔ P: Embora o PMBoK possua o processo “Controle

Integrado de Mudanças”, mudanças em projetos com planejamento prévio excessivo são caras;

➔ É possível evitar mudanças?

www.eunati.com.brAgile

➔"Desperdício é mais um crime contra a sociedade que uma perda nos negócios"

Taiichi Ohno [3]

➔Ohno é um dos pais do Sistema Toyota de Produção [4] e do KanBan [5].

➔No ano de 2001, 17 expoentes da área de Tecnologia assinaram o Manifesto Ágil [6]:

➔ Valores e princípios que norteiam agilidade;➔ Signatários: Ken Schwaber (Scrum), Jeff Sutherland

(Scrum), Martin Fowler (Thoughworks, UML, Design Patterns), Kent Beck (XP), Ron Jeffries (XP), Ward Cunningham (XP), Arie van Bennekum (DSDM), Alistair Cockburn (Crystal), Mike Beedle, James Grenning, Jim Highsmith, Andrew Hunt, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Dave Thomas.

Fonte externa: http://agilemanifesto.org/iso/ptbr

➔Gigantes que usam métodos ágeis [7] [8]: ➔ Intel, Microsoft, Google, Nokia, Adobe, NSA, Yahoo,

GE, …

➔Órgãos/empresas do Governo Brasileiro que usam métodos ágeis:

➔ Serpro, Dataprev, Ministério Planejamento, Ministério da Educação, Ministério do Turismo, Conselho Nacional de Justiça (CNJ), Conselho Superior da Justiça do Trabalho (CSJT), Banco Central, Caixa Econômica Federal, Tribunal de Contas da União, ...

➔Métodos ágeis:➔ Gartner Group já indica-os em suas consultorias;➔ Utilizados nas mais diversas áreas (startups [9],

engenharia, arquitetura, educação, saúde, casa, ...).

www.eunati.com.brScrum na prática

Fonte externa: Projeto EduScrum. Disponível em: http://eduscrum.nl

➔Vídeo:➔ Nerdologia 95 - O Poder do Coletivo;➔ www.youtube.com/watch?v=eANH5f1ul7s

Fonte externa: www.youtube.com/watch?v=eANH5f1ul7s

➔Poder do coletivo:➔ Performances individuais variam menos que

performances coletivas (canais de comunicação);➔ Focar em indivíduos ao invés de focar na equipe é

erro comum;➔ Estimativas de grupos são melhores que

estimativas individuais.

➔Elementos chave dos métodos ágeis:➔ Inspeção e adaptação;➔ Desenvolvimento iterativo e incremental;➔ Equipes auto-organizáveis;➔ Equipes multifuncionais;➔ Envolvimento dos usuários;➔ Maximização do ROI;➔ Aceitar mudanças;

➔ Inspeção e Adaptação:➔ Periodicamente, revise o que já fez;➔ Verifique se deve continuar o que está fazendo;➔ Verifique se pode melhorar desempenho do que

está fazendo.

➔Desenvolvimento iterativo e incremental:➔ Alternativa ao modelo cascata;➔ Projeto deve possuir possui iterações (repetições),

nas quais um Incremento (versão potencialmente utilizável) do produto é disponibilizado.

➔Desenvolvimento iterativo e incremental:➔ Iterações permitem diminuir ciclos de inspeção e

adaptação;➔ Incrementos adiantam feedback e trazem valor;➔ MVP (Minimun Viable Product) – Incremento com

requisitos mínimos para liberação aos usuários.

➔Equipes auto-organizáveis:➔ Equipes que definem como irão produzir um

Incremento do produto e quanto são capazes de produzir;

➔ Métodos ágeis devem ser implantados de baixo para cima, com interesse das equipes, e não como imposição superior.

➔Equipes multifuncionais:➔ Equipes que possuem todas as habilidades

necessárias ao projeto;➔ Não que dizer que cada membro da equipe deve

possuir todas habilidades.

➔Envolvimento dos usuários:➔ Feedbacks constantes e em curtos intervalos de

tempo produzem produtos mais adequados;➔ Constante disponibilidade do cliente para colaborar

em dúvidas, alterações, e prioridades em um projeto.

➔Maximização do ROI:➔ ROI – Return of Investment;➔ Produtos de projetos (softwares, serviços,

construções, ...) removem restrições em processos de negócios para que a empresa possa alcançar objetivos estratégicos;

➔ Princípio de Pareto: 80% do valor do produto está em 20% das funcionalidades;

➔ Por que não maximizar o ROI iniciando pelas funcionalidades (20%) que trazem maior valor ao negócio ?

➔Maximização do ROI - Exemplo real [11]:➔ Contrato de R$ 10 milhões em 20 meses (R$ 500

mil por mês) com cláusula de cancelamento antecipado (cliente paga 20% do valor restante);

➔ Nos três primeiros meses cliente pagou R$ 1,5 milhões e produto chegou aos 20% desejados;

➔Maximização do ROI - Exemplo real [11]:➔ Empresa lucra R$ 1,7 milhões adicionais (20% de

R$ 8,5 milhões) e pode pegar outro projeto;➔ Cliente paga R$ 3,2 milhões (R$ 1,5 + 1,7 milhões)

em algo que poderia custar R$ 10 milhões e tem produto que atende suas necessidades essenciais 17 meses mais cedo.

➔Aceitar mudanças:➔ Mudanças são naturais a medida que projeto

avança.

➔Métodos ou frameworks ágeis: ➔ Scrum [11] [12]➔ Lean (Sistema Toyota de Produção) [4]➔ Lean Startup [9]➔ XP (eXtreme Programming) [13]➔ DSDM➔ Crystal

Scrum - inspirações

www.eunati.com.brScrum - inspirações

➔Comprometimento vs Envolvimento:

Fonte externa: blog.crmzen.com.br/post/64866403186/ porcos-e-galinhas-x-comprometimento-e-envolvimento

Fonte externa:Sutherland, Jeff; Schwaber, Ken. Guia do Scrum: Uma Guia Definitivo Para o Scrum

➔Scrum [12]:➔ “Framework no qual pessoas podem tratar

problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível”

➔ “Embora seja possível implementar somente partes do Scrum, o resultado não é Scrum. Scrum existe somente na sua totalidade, funcionando bem como um container para outras técnicas, metodologias e práticas.” (ScrumBut)

➔Scrum: ➔ Leve;➔ Simples de entender;➔ Difícil de dominar.

➔Scrum:➔ Papéis (Roles);➔ Eventos (Events);➔ Artefatos (Artifacts);➔ Regras (Rules).

➔Scrum:➔ Em 1993 Jeff Sutherland utilizou princípios do

Scrum na Easel Corporation [11];➔ Em 1995 Ken Schwaber e Jeff Sutherland

formalizaram primeira versão do Scrum e publicaram na OOPSLA'95 (Object-Oriented Programming, Systems, Languages & Applications da ACM).

➔Scrum.org [14] foi fundada em 2009 por Ken Swaber e fornece diversas certificações Scrum:

➔ PSM I (Professional Scrum Master ITM);➔ PSM II (Professional Scrum Master IITM);➔ PSD I (Professional Scrum Developer ITM);➔ PSPO I (Professiona Scrum Product Owner ITM);➔ PSPO II (Professiona Scrum Product Owner IITM);

➔Certificação Professional Scrum Master I TM:➔ Apenas em inglês;➔ Taxa de U$150 dólares;➔ 60 minutos;➔ 80 questões de múltipla escolha, múltiplas

respostas ou verdadeiro/falso;➔ Score mínimo de 85% (68 questões);➔ Não precisa de curso especifico;➔ Via web.

➔Case FBI – EUA [11]:➔ Em 2010, FBI cancelou projeto de uma década que

poderia ter evitado 11 Setembro;➔ Vários formulários e relatórios em papel e sistemas

existentes totalmente desintegrados;➔ Começaram com projeto Virtual Case File (U$ 170

milhões);➔ Em 2005, projeto Sentinel (U$ 450 milhões) foi

anunciado com prazo para 2009;

➔Case FBI – EUA [11]:➔ Em 2010, só 50% estava concluído e seriam

necessários mais 6 a 8 anos e U$ 350 milhões para conclui-lo;

➔ Modelo cascata foi utilizado em ambos projetos;➔ CIO Jeff Johnson decidiu internalizar

desenvolvimento no FBI;

➔Case FBI – EUA [11]:➔ Reduziu equipe de 220 para 40 e propôs entregar

sistema com gasto de 20 milhões;➔ Utilizou Scrum com iterações (Sprints) de duas

semanas;➔ Do início do fim do projeto, equipes triplicaram a

produtividade;➔ Em 20 meses, o projeto foi finalizado e

disponibilizado em todo FBI.

➔Jeff Sutherland:➔ Piloto de reconhecimento na guerra do Vietnã;➔ Doutor em medicina estatística;➔ Trabalhou na concepção dos caixas ATM;➔ Utilizou diversas fontes de inspiração para

desenvolver Scrum com Ken Schwaber.

➔Principais inspirações para Scrum:➔ Rugby;➔ Shuhari do Aikido;➔ Ciclo de Deming (PDCA);➔ Ciclo OADA da aviação de combate;➔ The new new product development game;➔ Sistema Toyota de Produção;

➔Principais inspirações para Scrum:➔ Empiricismo;➔ Tipos de desperdício de Taiichi Ohno;➔ Interferência dual de tarefas;➔ Esgotamento do ego;➔ Definição de Pronto;➔ Time-box.

➔Rugby:➔ 15 pessoas em cada time;➔ Scrum – Formação com 8 de cada lado.

Fonte externa: upload.wikimedia.org/wikipedia/commons/ 0/0b/Scrum_ASM_Clermont-Saracens.jpg

➔Vídeo:➔ Scrum no Rugby;➔ www.youtube.com/watch?v=jUz1ytcnn3c

➔Shuhari do Aikido [15]:➔ Filosofia oriental;➔ Shu: Conhece regras e segue-as. Nunca se distrai;➔ Ha: Regras já dominadas e começa a inovar;➔ Ri: Descarta as regras e é livremente criativo;➔ Scrum visa que trabalho organizado e ágil seja algo

natural.

➔Ciclo de Deming (PDCA) - 1950:➔ Plan, Do, Check, Act/Adjust;➔ Planeja, Faça, Inspecione, Aja/Ajuste;➔ Utilizado na reconstrução do Japão pós segunda

guera;➔ Insumo para Sistema Toyota de Produção.

➔Ciclo OADA da aviação de combate (Guerra Vietnã – 1965) [11]:

➔ Observar - Coletar dados;➔ Avaliar - Levantar alternativas de ação;➔ Decidir – Decidir por uma alternativa;➔ Agir.

➔The new new product development game (1986) [16]:

➔ Artigo de Harvard de 1986 dos administradores japoneses Hirotke Takeuchi e Ikujiro Nonaka;

➔ Analisaram produtividade da Honda, Xerox, 3M, HP, etc;

➔ Descobriram equipes multifuncionais, auto-organizáveis e com objetivos transcendentes;

➔ Executivos removiam obstáculos das equipes;➔ Comparou equipes ao Scrum do Rugby.

➔Sistema Toyota de Produção (1988):➔ Desenvolvido por Taiichi Ohno [4];➔ Ideia de fluxo de produção calmo e rápido;➔ Gerência deve identificar e remover obstáculos do

fluxo, evitando desperdício;

➔Sistema Toyota de Produção:➔ Kaizen (do japonês melhoria) - Melhoria continua;

“Hoje melhor que ontem, amanhã melhor que hoje!”➔ Correção antecipada de defeitos de produção➔ Fracasse rápido para corrigir problemas

antecipadamente;➔ Qual maior característica dos carros da Toyota ?

➔Teorias empíricas de controle de processo – Empiricismo [12]:

➔ Processos Definidos vs Empíricos;➔ Processos definidos: Variáveis conhecidas, poucas

mudanças e repetitivos;➔ Processos empíricos: Com mudanças, não

repetitivos e conhecimento vem da experiência.

➔Empiricismo – pilares:➔ Transparência (aspectos significantes do processo

devem estar visíveis aos responsáveis pelos resultados);

➔ Inspeção;➔ Adaptação.

➔Empiricismo:➔ Transparência deve permear todos aspectos:

decisório, financeiro, político, etc;➔ Transparência gera confiança;➔ Prática para fomentar transparência, inspeção e

adaptação: remover divisórias entre membros do time.

➔Tipos de desperdício listados por Taiichi Ohno [4] [11]:

➔ Muri: desperdício pela irracionalidade (falha no planejamento);

➔ Mura: desperdício pela inconsistência (falha na ação);

➔ Muda: desperdício pelos resultados (falha na inspeção/adaptação).

➔ Interferência dual de tarefas: ➔ Nosso cérebro não consegue fazer bem duas

coisas ao mesmo tempo;➔ Dirigir falando ao celular é tão perigoso quanto

dirigir bêbado. [17]

➔ Interferência dual de tarefas: ➔ Pesquisa de Gerald Weinberg [18]:

Número de projetos

simultâneos

Porcentagem do tempo disponível

por projeto

Perda com a troca de contexto

1 100% 0%

2 40% 20%

3 20% 40%

4 10% 60%

5 5% 75%

➔ Interferência dual de tarefas: ➔ Minimize trocas de contexto na equipe;➔ Tarefas pela metade não trazem valor.

➔ Interferência dual de tarefas – Dinâmica:➔ Primeiro passo: escreva as linhas e cronometre

tempo gasto;➔ Segundo passo: escreva as colunas e cronometre

tempo gasto.

➔ Interferência dual de tarefas – Dinâmica:

1 2 3 4 5 6 7 8 9 10

I II III IV V VI VII VIII IX X

A B C D E F G H I J

➔ Interferência dual de tarefas - Dinâmica - Avaliação:

➔ Em qual passo você gastou mais tempo ?➔ Você consegue enxergar alguma correlação com as

atividades realizadas em sua unidade de trabalho ?➔ O que você pode fazer para evitar a interferência

dual de tarefas ?

➔Esgotamento do ego:➔ A cada hora adicional de trabalho em um dia,

embora pessoa ainda não esteja fisicamente cansada, sua capacidade de tomar decisões é diretamente afetada.

➔Esgotamento do ego:➔ Pesquisa com magistrados de Israel em 2011 [19];➔ Análise de mais de 1000 decisões sobre liberdade

condicional;➔ Logo após a chegada ao trabalho ou lanche, a

probabilidade de concessão da condicional aumentava em 60%;

➔ Com mais horas de trabalho, magistrados tomavam decisões que minimizavam riscos.

➔Experiência na empresa OpenView Venture (financeira) de Scott Maxwell [11] :

➔ Trabalhar mais é sinal de fracasso e não de sucesso;

➔ Trabalho em excesso ou heroico não deve ser o padrão nem encarado como positivo (desperdício Muri de irracionalidade – falha no planejamento).

➔Experiência na empresa OpenView Venture (financeira) de Scott Maxwell [11] :

➔ Cargas de trabalho menores trazem melhorias na saúde emocional e física (tempo para atividades), relacionamentos familiares, projetos pessoais, ...

➔ Ambientes de pressão, com membros trazendo tensão ao time, também são negativos à produtividade.

➔Definição de Pronto (Done):➔ Deve ser comum para todo o time;➔ Deve evoluir com o tempo (mais rigorosa);➔ Times trabalhando no mesmo produto devem

compartilhar mesma Definição de Pronto.

➔Time-box: ➔ Prazo inflexível de tempo alocado para tarefa ou

evento específico;➔ Ao atingir tempo máximo, tarefa ou evento deve ser

encerrado imediatamente;➔ Evento pode encerrar antes do Time-box.

➔Fábrica de aviões - Dinâmica [20][11]:

➔Fábrica de aviões:➔ Equipes com aproximadamente sete pessoas;➔ Força aérea deseja novo avião;➔ Avião deve possuir 12 janelas;➔ Avião deve possuir uma cabine;➔ Avião deve possuir símbolos da aeronáutica na

cauda e nas asas;➔ Equipe que produzir mais aviões será a vencedora.

➔Fábrica de aviões - Parte 1:➔ Organização das equipes (cada uma com um

nome);➔ Um minuto para dar estimativa de quantos aviões

conseguirão montar em três minutos de execução.

➔Fábrica de aviões - Parte 2:➔ Equipes tem três minutos para montar protótipo e

atualizar estimativa;➔ Equipes devem auto organizar-se;➔ Ao sinal, atividades devem ser paradas

imediatamente;➔ Comecem!

➔Fábrica de aviões - Avaliação:➔ O avião voa ?➔ Onde está a porta ?➔ Quantas vezes temos que dar estimativas sem

nenhuma noção de velocidade do time e sem escopo claramente definido?

➔ A estimativa melhora após a produção do protótipo ?

➔Fábrica de aviões - Parte 3:➔ Dois ciclos de produção;➔ Ciclo de produção possui seis minutos (2 para

planejar, 3 para executar, 1 para inspecionar);➔ Ao final do planejamento, equipes deverão atualizar

estimativa de produção do ciclo;➔ Ao final da inspeção, equipes deverão informar

quantos aviões produziram;

➔Fábrica de aviões - Parte 3:➔ Estimativas e produção serão controlados em

planilha;➔ Aviões não finalizados não devem ser

contabilizados e retornam para próximo ciclo;➔ Sinal será dado no final de cada etapa;

➔Fábrica de aviões - Parte 3:➔ Um membro não construirá aviões, mas APOIARÁ o

processo;➔ Instrutor será o responsável por aceitar aviões;➔ Comecem!

➔Fábrica de aviões - Avaliação:➔ Como foi o trabalho em equipe ?➔ E a definição da velocidade de produção do time ?➔ E a inspeção, funcionou ?➔ Estimativas e execução evoluíram com os ciclos ?➔ Seria melhor entregar todos aviões apenas no

final ?➔ E se usássemos essa lógica em projetos diversos ?

Estrutura do framework Scrum

www.eunati.com.brEstrutura do framework

➔Papéis:➔ Mestre Scrum (Scrum Master);➔ Dono do Produto (Product Owner);➔ Time de Desenvolvimento (Development Team).

➔Eventos:➔ Sprint;➔ Planejamento da Sprint (Sprint Planning);➔ Reunião Diária (Daily Scrum);➔ Revisão da Sprint (Sprint Review);➔ Retrospectiva da Sprint (Sprint Retrospective).

➔Artefatos:➔ Backlog do Produto (Product Backlog);➔ Backlog da Sprint (Sprint Backlog);➔ Incremento (Increment).

Equipes e papéis

www.eunati.com.brEquipes e papéis

➔Time Scrum (Scrum Team) é composto por:➔ Mestre Scrum (Scrum Master);➔ Dono do Produto (Product Owner);➔ Time de Desenvolvimento (Development Team);

➔“Time Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade.” [12]

➔Erro fundamental de atribuição:➔ Costuma-se atribuir erros unicamente aos

indivíduos, esquecendo-se das influências do sistema ao seu redor;

➔ Embora preze pela transparência máxima, o Scrum não motiva a atribuição de falhas unicamente a indivíduos, mas busca continuamente localizar os problemas no processo de produção que causaram as falhas.

➔Experimento Stanley Milgram (década de 60) [21]:

➔ Professor de psicologia da Universidade de Yale;➔ Reproduzido em diversos países;➔ Como tantos foram seduzidos pelo nazismo?➔ Faríamos diferente?➔ Objetos da pesquisa eram colocados em uma sala

por alguém com jaleco branco, com aspecto de autoridade;

➔Experimento Stanley Milgram:➔ Possuíam dispositivo que “aplicava” choques cada

vez mais intensos em um ator;➔ Quando alguém queria parar, o cientista mandava

continuar, pelo bem da pesquisa;➔ Quase todos continuavam dando choques;➔ O sistema era o culpado pelos resultados.

➔Vídeo:➔ Experimento de Stanley Milgram;➔ www.youtube.com/watch?v=VT3wKbBNo64

Fonte externa: www.youtube.com/watch?v=VT3wKbBNo64

➔Dono do Produto:➔ Responsável por maximizar o Retorno de

Investimento (ROI) e o trabalho do Time de Desenvolvimento;

➔ Não necessariamente é o cliente, mas atua como representante de seus interesses;

➔ É uma pessoa e não um comitê, embora possa delegar algumas de suas atividades;

➔Dono do Produto:➔ Relacionamento intenso com cliente e com Time de

Desenvolvimento;➔ Deve ter autonomia para tomar decisões em

relação ao produto.

➔Dono do Produto é responsável pelo gerenciamento do Backlog do Produto [12]:

➔ Expressar claramente os Itens do Backlog do Produto (PBI);

➔ Ordenar os PBIs para alcançar as metas e missões;➔ Garantir o valor do trabalho realizado pelo Time de

Desenvolvimento;

➔Dono do Produto é responsável pelo gerenciamento do Backlog do Produto:

➔ Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir;

➔ Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

➔“Esposas são excelentes Donas do Produto: elas sabem o que querem e os maridos implementam”;

➔Mestre dos Magos é um péssimo exemplo de Dono do Produto.

Fonte externa: http://www.renegade-revolution.com/wp-content/uploads/2014/03/DD-DM-screenshot.jpg

➔Dono do Produto:➔ É o único que pode alterar do Backlog do Produto;➔ Escopo de uma Sprint tem de ser negociado e

esclarecido com Dono do Produto;➔ Só Dono do Produto pode cancelar uma Sprint

(objetivo obsoleto);

➔Dono do Produto:➔ Novas funcionalidades devem ser solicitadas ao

Dono do Produto;➔ Tem autoridade para aceitar ou rejeitar trabalhos

realizados pelo Time de Desenvolvimento;➔ Define se faz sentido liberar (release) um

Incremento do produto.

➔Dono do Produto - cadeia de comando:➔ Idealmente, não deve ser chefe do Mestre Scrum

nem do Time de Desenvolvimento;➔ Responsável pelo macro gerenciamento do projeto;➔ Não deve exercer micro gerenciamento nem

comando/controle.

➔Time de Desenvolvimento:➔ Profissionais que realizam trabalho necessário para

entregar Incremento do produto ao final da Sprint atendendo à definição de Pronto (Done);

➔ Único título é o de Desenvolvedor (Developer);

➔Time de Desenvolvimento:➔ Não possui sub-times. A responsabilidade é

compartilhada pelo sucesso ou fracasso;➔ Auto-organizados e multifuncionais;➔ Possui autonomia para definir atividades

necessárias para contemplar objetivo da Sprint (ex: protótipos, testes, …);

➔Time de Desenvolvimento:➔ Embora não recomendável, Dono do Produto e

Mestre Scrum podem fazer parte do Time;➔ Como é auto-organizado, pode decidir pela

remoção de membros da equipe que não se ajustam, com o devido apoio do Mestre Scrum.

Fonte externa: dungeonsanddragonscartoon.com/ dungeons-dragons-3.jpg

➔Time de Desenvolvimento:➔ “Pequeno o suficiente para ser ágil e grande o

suficiente para entregar Incremento da Sprint”;➔ Mínimo 3 e máximo 9 pessoas.

➔Lei de Brooks [22]: ➔ “Adicionar pessoas em projeto atrasado irá atrasá-lo

ainda mais”;➔ Aumenta os canais de comunicação e é necessário

deslocar membros do time para treinar o novato.

➔Estudo de Lawrence Putman [23] [24]:➔ 491 projetos de TI;➔ Projetos com 35 a 95 mil linhas de código.

Fonte externa: Putnam, Lawrence et al. Small is Beautiful-Once Again, Familiar Metric Management.

➔Estudo de Lawrence Putman:➔ Equipes com até sete pessoas concluíram projetos,

em média, em 75% do tempo utilizado por equipes com mais de sete pessoas;

➔ Quanto maior equipe, mais canais de comunicação existem, aumentando complexidade de gerenciamento.

Tamanho Equipe Canais de Comunicação

➔Mestre Scrum:➔ Servo líder para Time Scrum;➔ Garante aderência à teoria, práticas e regras do

Scrum na organização;➔ Gerencia processo Scrum na organização,

facilitando interações;

➔Mestre Scrum:➔ Facilita eventos do Scrum quando requisitado ou

necessário, garantindo sua realização;➔ Garante transparência dos artefatos;➔ Combate estilo comando/controle;➔ Hank atuava como mestre Scrum (constantemente

removendo obstáculos e impedimentos) e como membro do Time de Desenvolvimento (não é o ideal, embora possível).

Fonte externa: 2.bp.blogspot.com/-70zw_E_j-4g/TjahEm KJcKI/ AAAAAAAAIb0/wyuHJX3di_Y/s1600/magic_bow.png

➔Mestre Scrum trabalhando para Dono do Produto:

➔ Encontrar técnicas para o gerenciamento efetivo do Backlog do Produto (criação, priorização, etc);

➔ Ensiná-lo a claramente comunicar a visão, objetivo e itens do Backlog do Produto para o Time de Desenvolvimento.

➔Mestre Scrum trabalhando para Time de Desenvolvimento:

➔ Remover impedimentos para o progresso;➔ Treinar autogerenciamento e interdisciplinaridade;➔ Blindar de interferências externas;➔ Melhorar interações entre Dono do Produto e Time

de Desenvolvimento.

➔Mestre Scrum trabalhando para Organização e Time Scrum:

➔ Liderando e treinando a organização na adoção do Scrum;

➔ Planejando implementações Scrum dentro da organização;

➔ Causando mudanças que aumentam a produtividade do Time Scrum.

Eventos

www.eunati.com.brEventos

➔Eventos Scrum:➔ Sprint;➔ Planejamento da Sprint (Sprint Planning);➔ Reunião Diária (Daily Scrum);➔ Revisão da Sprint (Sprint Review);➔ Retrospectiva da Sprint (Sprint Retrospective).

➔Eventos Scrum:➔ São todos Time-boxed;➔ Minimizam reuniões não definidas no framework.

➔Tempo:➔ Por que não aproveitar melhor o tempo ?➔ Não gastamos tempo demais em tarefas não

prioritárias ?

➔Cone das incertezas [25] [26]: ➔ Nossas estimativas iniciais são muito ruins e vão

melhorando com o tempo;➔ Por que não fazer planos iniciais mais superficiais e

refiná-los durante o projeto ?➔ Scrum foca no Planejamento da Sprint.

➔Visão do Produto:➔ Antes da primeira Sprint, é aconselhável (não

obrigatório) elaborar a Visão do Produto;➔ Responsabilidade do Dono do Produto;➔ Indica objetivo do projeto;➔ É o escopo inicial de alto nível.

➔Sprint:➔ “O coração do Scrum é a Sprint, um Time-boxed de

um mês ou menos, durante o qual um Pronto, versão incremental potencialmente utilizável do produto, é criado.” [12]

➔Sprint:➔ É um container para todos outros eventos do

Scrum;➔ Limita riscos de custos e complexidade a um mês

(transparência, inspeção e adaptação);➔ Deve ter durações constantes;➔ A próxima Sprint inicia-se logo após o término da

anterior.

➔Sprint - duração:➔ Não mais que um mês;➔ Não tão longa que o risco seja inaceitável para o

Dono do Produto;➔ Não tão curta que eventos de negócio não possam

ser sincronizados com desenvolvimento.

➔Durante a Sprint:➔ Não são feitas mudanças que possam por em

perigo a meta da Sprint;➔ As metas de qualidade não diminuem;➔ O escopo pode ser clarificado e renegociado entre o

Dono do Produto e o Time de Desenvolvimento.

➔Cancelamento da Sprint:➔ Apenas quando a meta da Sprint torna-se obsoleta

(incomum);➔ Apenas Dono do Produto pode cancelar Sprint;➔ Itens Prontos são revisados e podem ser aceitos;➔ Itens incompletos são estimados novamente e

voltam para o Backlog do Produto;➔ Inicia-se nova Sprint após o cancelamento.

➔Planejamento da Sprint (Sprint Planning):➔ “O trabalho a ser realizado na Sprint é planejado na

reunião de Planejamento da Sprint. Esse plano é criado com o trabalho colaborativo de todo o Time Scrum.” [12]

➔Planejamento da Sprint:➔ Time-box máximo: 8 horas para Sprint de um mês;➔ Para todo Time Scrum.

➔Planejamento da Sprint - Tópicos:➔ Tópico 1 - O que pode ser entregue como resultado

do Incremento da Sprint?➔ Tópico 2 - Como será realizado o trabalho

necessário para entregar o Incremento ?

➔Tópico 1 - O que pode ser entregue como resultado do Incremento da Sprint?

➔ Sugestão de Time-box (não está no guia): 4 horas para Sprint de um mês;

➔ Para todo Time Scrum;➔ Entradas: Backlog do Produto, Incremento mais

recente, capacidade projetada e desempenho do Time de Desenvolvimento;

➔Tópico 1:➔ Saídas: Itens do Backlog do Produto Selecionados

(SPBIs), Meta ou Objetivo da Sprint (Sprint Goal);➔ Com o Backlog do Produto priorizado, o Time de

Desenvolvimento poderá indicar quais são os SPBIs da Sprint;

➔ Lógica: se Time de Desenvolvimento implementa, Time de Desenvolvimento estima e diz quanto fará na Sprint.

➔Tópico 1 – Refinamento (Grooming):➔ Refinamento do Backlog do Produto e estimativas

dos Itens do Backlog do Produto;➔ Pode ser realizado aqui;➔ Caso já tenha sido realizado, estimativas podem ser

revistas;➔ Apenas Time de Desenvolvimento poderá estimar

➔Tópico 1 - Meta da Sprint:➔ Direção para Time de Desenvolvimento durante

Sprint;➔ Não pode ser alterada durante a Sprint;➔ Dá certa flexibilidade ao Time de Desenvolvimento

quanto ao que será completado na Sprint;➔ Deve ser uma frase curta, de preferência que possa

ser medida ao final da Sprint;➔ Deve ser elaborada após a seleção dos SPBIs.

➔Tópico 2 - Como o trabalho necessário para entregar o Incremento será realizado?

➔ Sugestão de Time-box (não está no Guia): 4 horas para Sprint de um mês;

➔ Para Time de Desenvolvimento, embora todos do Time Scrum possam participar e devam estar disponíveis para dúvidas.

➔Tópico 2:➔ Entradas: Itens do Backlog do Produto

Selecionados (SPBIs), Meta ou Objetivo da Sprint (Sprint Goal);

➔ Saídas: Backlog da Sprint (Itens do Backlog do Produto Selecionados e Plano para entregá-los);

➔Tópico 2:➔ SPBIs podem ser clareados ou negociados com

Dono do Produto;➔ Time de Desenvolvimento inicia desenho do

sistema;➔ Trabalhos para primeiros dias da Sprint são

decompostos em tarefas de um dia ou menos;

➔Tópico 2:➔ Tarefas podem ser estimadas em horas;➔ Montagem do quadro KanBan;➔ Podemos dizer que o Backlog da Sprint é composto

pelos Itens do Backlog do Produto Selecionados e pelas Tarefas necessárias para entregá-los.

➔Durante Sprint:➔ Qualquer membro do Time de Desenvolvimento

pode adicionar ou remover tarefas do Backlog da Sprint;

➔ Time de Desenvolvimento auto organiza-se na atribuição de tarefas.

Fonte externa: upload.wikimedia.org/wikipedia/ commons/4/4a/Daily_sprint_meeting.jpg

➔Reunião Diária (Daily Meeting):➔ “A Reunião Diária do Scrum é um evento Time-

boxed de 15 minutos, para que o Time de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas.” [12]

➔Reunião Diária:➔ Nasceu a partir de uma reunião diária de uma hora

realizada por uma equipe de alta produtividade da Borland [11]. Nessa equipe, cada programador produzia mil linhas de código por semana;

➔ Também conhecida como Standup Meeting, Daily Meeting ou Daily Scrum, é uma peça chave para inspeção e adaptação.

➔Reunião Diária - Três perguntas: ➔ O que fiz ontem para atender à meta da Sprint ?➔ O que farei hoje para para atender à meta da

Sprint ?➔ Vejo algum obstáculo que impeça a mim ou ao Time

de Desenvolvimento no atendimento da meta da Sprint?

➔Reunião Diária:➔ Time-box máximo: 15 minutos diários;➔ Apenas Time de Desenvolvimento participa, embora

outros possam assisti-la;➔ Todos devem estar presentes e de pé;➔ Reuniões devem acontecer no mesmo local e

horário;

➔Reunião Diária:➔ Time de Desenvolvimento é responsável pela

condução da reunião;➔ Só não acontece nos dias dos outros eventos

Scrum;➔ Discussões detalhadas, adaptações ou

replanejamentos devem ser realizados após a reunião;

➔Reunião Diária:➔ Antes do início da reunião, quadro KanBan deve

estar atualizado;➔ Ao final da reunião, trabalho restante da Sprint pode

ser exibido (Gráfico de Burndown atualizado).

➔Revisão da Sprint (Sprint Review):➔ “A Revisão da Sprint é executada no final da Sprint

para inspecionar o Incremento e adaptar o Backlog do Produto, se necessário. Durante a reunião de Revisão da Sprint, o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint.” [12]

➔Revisão da Sprint:➔ Time-box máximo: 4 horas para Sprint de um mês;➔ Time Scrum e demais partes interessadas

convidadas pelo Dono do Produto participam;➔ Dono do Produto esclarece quais SPBIs foram

“Prontos” e quais não foram “Prontos”;

➔Revisão da Sprint:➔ Time de Desenvolvimento discute o que foi bem,

quais problemas ocorreram na Sprint e como resolveram;

➔ Time de Desenvolvimento demonstra o Incremento “Pronto”;

➔Revisão da Sprint:➔ Dono do Produto apresenta Backlog do Produto e

presentes podem colaborar em sua construção/priorização (para próxima Sprint);

➔ Possíveis datas de conclusão do projeto podem ser estimadas;

➔ O que não está “Pronto” retorna ao Backlog do Produto.

Fonte externa:https://pixabay.com/en/live-jump-joy-lifestyle-1003646/

➔Felicidade:➔ “Somos recompensados pelas chegadas, não pelas

jornadas.”➔ A frase acima é verdadeira ? ➔ Se sim, é o ideal ?

➔Felicidade – Pesquisa:➔ The Benefits of Frequent Positive Affect: Does

Hapiness Lead to Success? [27]➔ 275 mil participantes;➔ A felicidade leva ao sucesso em quase todos

domínios na vida: casamento, saúde, amizade, comunidade e trabalho;

➔ Não é em decorrência do sucesso que pessoas são felizes;

➔ Aumento da “felicidade” de uma equipe aumenta sua produtividade.

Fonte externa: heizerrenderom.files.wordpress.com/ 2015/02/zappos-call-center.jpg

➔Felicidade – Sapataria Zappos:➔ Case narrado pelo CEO Tony Hsieh no livro

Satisfação Garantida [28];➔ Decidiu criar conexões entre funcionários de

diversos níveis hierárquicos da empresa;➔ Encoraja encontros ao acaso entre funcionários;➔ Saltou de 1 milhão de dólares em vendas no ano

2000 para quase 1 bilhão de dólares em 2008, totalizando um crescimento de 125% ao ano;

➔ Comprada pela Amazon em 2009.

➔Felicidade:➔ Felicidade não é complacente, mas encorajadora:

use alegria como força motriz;➔ Bolha da felicidade: às vezes as produtividade

melhora, pessoas ficam felizes com resultados e acomodam-se;

➔Felicidade:➔ Melhoria deve ser contínua;➔ Mestre Scrum é responsável por detectar bolhas de

felicidade através da medição da velocidade em Sprints e evitá-las;

➔ Equipe precisa de um tolo sábio (às vezes transparente demais).

➔Retrospectiva da Sprint (Sprint Retrospective) [12]:

➔ Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;

➔ Identificar e ordenar os principais itens que foram bem e as potenciais melhorias;

➔ Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;

➔Retrospectiva da Sprint:➔ Time-box máximo: 3 horas para Sprint de um mês;➔ Para todo Time Scrum;➔ Mestre Scrum deve encorajar Time Scrum em

busca da melhoria contínua e da transparência (por isso não é interessante que seja chefe hierárquico do Time);

➔ Definição de Pronto pode ser evoluída.

➔Retrospectiva da Sprint – Três perguntas:➔ O que fizemos de bom na Sprint e devemos

manter?➔ O que pode ser melhorado ?➔ Como vamos implementar ações de melhoria ?

➔Retrospectiva da Sprint:➔ As ações de melhoria elencadas devem entrar no

próximo Backlog da Sprint;➔ Não basta elencar problemas, é necessário propor

planos de ação;➔ Palavras chave: transparência, inspeção e

adaptação;➔ Essa reunião pode ser utilizada, inclusive, para

definir o afastamento de membros do Time Scrum.

➔Retrospectiva da Sprint – Métrica da Felicidade [11]:

➔ Proposta por Jeff Sutherland;➔ Não está no Guia Scrum.

➔Retrospectiva da Sprint – Métrica da Felicidade - Perguntas:

➔ De 1 a 5, como você se sente em relação ao seu papel na empresa ?

➔ Por que você se sente assim ?➔ O que tornaria você mais feliz no próximo Sprint ?

➔Retrospectiva da Sprint – Métrica da Felicidade - Ações:

➔ Fazer a média da felicidade da equipe;➔ Manter registros para posterior comparação com

velocidade da equipe;➔ Escolher aprimoramentos mais importantes e

adicioná-los ao Backlog da próxima Sprint, preferencialmente, com testes de aceitação.

➔Vídeo:➔ The Power of Scrum;➔ www.youtube.com/watch?v=eNe0UEsBalA

Fonte externa: www.youtube.com/watch?v=eNe0UEsBalA

Artefatos

www.eunati.com.brArtefatos

➔Artefatos Scrum:➔ Backlog do Produto (Product Backlog);➔ Backlog da Sprint (Sprint Backlog);➔ Incremento (Increment).

➔“Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos.” [12]

➔“O Mestre Scrum deve trabalhar com o Dono do Produto, Time de Desenvolvimento, e outras partes envolvidas para entender se os artefatos estão plenamente transparentes.” [12]

➔Visão do produto (Product View):➔ Não é explicitamente citada como artefato do Guia

Scrum;➔ Aconselhável, mas não obrigatória;➔ Deve ser curta e de alto nível;➔ Dono do Produto é o responsável pela visão;➔ A partir da Visão, nasce o Backlog do Produto.

➔Backlog do Produto (Product Backlog):➔ “O Backlog do Produto é uma lista ordenada de

tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Dono do Produto é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação.” [12]

➔Backlog do Produto:➔ É um artefato dinâmico, que existirá enquanto o

produto existir;➔ Deve estar disponível para todos interessados.

➔Backlog do Produto - Itens:➔ Os Itens do Backlog do Produto (PBI) possuem os

atributos de descrição, ordem, estimativa e valor;➔ PBIs devem ser expressos em linguagem de

negócio e não em linguagem técnica.

➔Backlog do Produto:➔ Embora possam existir vários Times Scrum

trabalhando no mesmo produto, o Backlog do Produto sempre será único;

➔ Pode ser mantido em uma planilha eletrônica ou em softwares específicos.

Fonte externa: https://answers.atlassian.com/upfiles/rbplanning.png

➔Refinamento (Grooming):➔ Detalhamento, priorização e estimativas;➔ Processo colaborativo entre Dono do Produto e

Time de Desenvolvimento;➔ O Dono do Produto é responsável pelo

detalhamento e priorizações;➔ O Time de Desenvolvimento é responsável pelas

estimativas (Poker);

➔Refinamento (Grooming):➔ Time de Desenvolvimento define quando PBIs estão

Preparados (Ready) para seleção no Backlog da Sprint;

➔ Não deve consumir mais que 10% da capacidade do Time de Desenvolvimento;

➔Refinamento (Grooming):➔ Quanto maior a prioridade do PBI, mais detalhado

ele deve estar;➔ Recomenda-se ter PBIs priorizados e estimados

para três Sprints;➔ Interessante manter reuniões de Refinamento

(Grooming) no mesmo horário, local e com Time-box.

➔Backlog da Sprint (Sprint Backlog):➔ “O Backlog da Sprint é um conjunto de itens do

Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o Incremento do produto e atingir o objetivo da Sprint.”[12]

➔Backlog da Sprint:➔ Torna visível o trabalho do Time de

Desenvolvimento;➔ Time de Desenvolvimento é o único que pode

alterar o Backlog da Sprint;➔ Sempre que um novo trabalho é identificado, o Time

de Desenvolvimento adiciona-o ao Backlog da Sprint;

➔Backlog da Sprint:➔ Alterações nos SPBIs precisam ser negociadas com

Dono do Produto;➔ Conforme o trabalho é realizado ou completado, a

estimativa do trabalho restante é atualizada;➔ Pode ser mantido em uma planilha eletrônica, em

um software específico ou em um Quadro de Tarefas (KanBan).

➔ Incremento (Increment):➔ “O Incremento é a soma de todos os itens do

Backlog do Produto completados durante a Sprint e o valor dos Incrementos de todas as Sprints anteriores. Ao final da Sprint, um novo Incremento deve estar “Pronto”, o que significa que deve estar na condição utilizável e atender a definição de “Pronto” do Time Scrum. Este deve estar na condição utilizável independente do Dono do Produto decidir por liberá-lo realmente ou não.” [12]

Técnicas

www.eunati.com.brTécnicas

➔Técnicas usualmente utilizadas com Scrum (não necessariamente mencionadas pelo Guia):

➔ Quadro de Tarefas ou KanBan (Task Board);➔ Poker de Planejamento (Planning Poker);➔ Velocidade da Sprint (Sprint Velocity);➔ Gráfico Burndown (Burndown Chart);➔ Histórias de Usuário (User Stories);➔ Planejamento de Liberações (Relase Planning).

➔Quadro de Tarefas ou KanBan (Task Board):➔ KanBan é uma palavra japonesa.;➔ Kan = Visual, Ban = Cartão ou Quadro;➔ Taiichi Ohno é um dos pais do Sistema Toyota de

Produção [4] e do KanBan [5];➔ Usualmente utilizado para representar o Backlog da

Sprint.

Fonte externa: upload.wikimedia.org/wikipedia/ commons/d/d3/Simple-kanban-board-.jpg

Fonte externa: www.atlassian.com/wac/agile/kanban/sectionWrap/00/column/00/moreContent/03/imageBinary/agile_kanban_board.png

Fonte externa: https://www.clearvision-cm.com/wp-content/uploads/2013/11/Untitled-drawing.jpg

➔Quadro de Tarefas – Sugestões de colunas (devem refletir fluxo da equipe):

➔ Fazer;➔ Fazendo;➔ Feito;➔ Impedimento.

➔Quadro de Tarefas:➔ Podem haver cores diferentes para correções,

testes, equipes, etc;➔ Quadro KanBan deve ter a maior transparência

possível, de maneira a facilitar a inspeção e adaptação;

➔ Junto ao KanBan, em geral, é adicionada a Meta da Sprint e um Gráfico Burndown;

➔ Deve ser atualizado antes da Reunião Diária.

➔Poker de Planejamento (Planning Poker):➔ Baseado no método de Delphi;➔ “Em linhas gerais, o método de Delphi consulta um

grupo de especialistas a respeito de eventos futuros através de um questionário, que é repassado continuadas vezes até que seja obtida uma convergência das respostas, em um consenso, que representa uma consolidação do julgamento intuitivo do grupo. Pressupõe-se que o julgamento coletivo, ao ser bem organizado, é melhor do que a opinião de um só indivíduo.” [29]

➔Poker de Planejamento:➔ Estimativas comparativas são mais fáceis de

elaborar que estimativas absolutas (ex: em horas);➔ Para tanto, o Scrum utiliza os Pontos de História

(Story Points);➔ Utiliza números da Sequencia de Fibonnaci, que

são recorrentes na natureza;➔ Distanciam-se de maneira suficiente para sabermos

a diferença entre eles.

➔Poker de Planejamento - Baralho:➔ 0 indica que algo já está feito;➔ 40 e 100 são estimativas altas que ainda precisam

ser mais detalhadas;➔ O infinito indica que é algo que levaria tempo

considerável (gigante) a ser realizado;➔ A interrogação indica que desenvolvedor ainda não

consegue estimar;➔ Alguns baralhos possuem carta para pausa.

➔Poker de Planejamento:➔ Para estimativas do Backlog do Produto, o ideal é

utilizar Pontos de História com Poker;➔ Apenas Time de Desenvolvimento (executores)

deve elaborar as estimativas.

➔Poker de Planejamento – Como jogar:➔ Passo 1: Selecionar uma História de dois pontos

para iniciar;➔ Passo 2: Dono do Produto seleciona PBI e

questiona estimativa ao Time de Desenvolvimento;➔ Passo 3: Cada Desenvolvedor seleciona uma

estimativa;➔ Passo 4: Todos mostram cartas ao mesmo tempo;

➔Poker de Planejamento – Como jogar:➔ Passo 5: Caso a maior divergência possua distância

de uma carta, pode selecionar a carta de maior valor ou fazer a média e Retornar para o Passo 2;

➔ Passo 6: Caso a maior divergência possua distância de mais de uma carta, os Desenvolvedores da maior e da menor estimativa devem justificar suas estimativas;

➔Poker de Planejamento – Como jogar:➔ Passo 7: Novas rodadas de estimativas realizadas

até convergência (Passo 5);➔ Passo 8: Retornar ao Passo 2.

➔Poker de Planejamento – Dinâmica:➔ Estimar as Histórias de Usuário a seguir;➔ Cada Desenvolvedor deve fazer uma estimativa em

um pedaço de papel;

➔Poker de Planejamento – Dinâmica:➔ HIST1 - Desenvolvedor deve redigir relatório da

viagem de 2 dias da semana passada para RH. Pontos: 2

➔ HIST2- Desenvolvedor deve redigir relatório da viagem de 5 dias da semana passada para RH. Pontos: ?

➔ HIST3 - Diretor do RH deve agrupar e revisar relatórios da viagem de 2 dias de 9 servidores para apresentação à diretoria. Pontos: ?

➔ HIST4 - Diretor do RH deve apresentar em 30 minutos relatórios agrupados ao Presidente do órgão. Pontos: ?

➔Velocidade da Sprint (Sprint Velocity):➔ A velocidade indica quantos Pontos de História o

Time Scrum consegue entregar por Sprint, em média;

➔ Velocidade não é garantia futura (empirismo);➔ Velocidade varia de projeto para projeto, embora o

Time Scrum seja o mesmo;➔ É interessante manter os registros da velocidade do

Time Scrum e, se possível, fazer o cruzamento com métrica da felicidade ou outras métricas de produtividade.

➔Gráfico Burndown (Burndown Chart):➔ Indica trabalho restante a ser realizado em período

de tempo;➔ Eixo X: Tempo;➔ Eixo Y: Trabalho restante (em Pontos de História ou

em horas);➔ Gráfico Burndown da Sprint deve ser atualizado

antes da Reunião Diária.

Fonte externa: http://www.scrum-institute.org/images_scrum/Sprint_Burndown.jpg

Fonte externa: http://www.scrum-institute.org/images_scrum/Simple_Burndown_Chart.jpg

➔Histórias de Usuário (User Stories):➔ Podem ser usadas em substituição aos casos de

uso, descrições textuais, ...➔ Como um <ator>, eu gostaria de <ação> para

<objetivo>;➔ Quanto maior a prioridade de uma História, maior

deve ser seu detalhamento;

➔Histórias de Usuário:➔ Uma História deve caber em uma Sprint, caso

contrário, quebre-a em Histórias menores;➔ Estimativas dos tamanhos das Histórias são

chamadas de Pontos de História;➔ Um Épico dá origem a um conjunto de Histórias

relacionadas;

➔Histórias de Usuário Preparadas (Ready) - Critérios INVEST [30]:

➔ Independente;➔ Negociável (deve ser convite para conversa);➔ Valiosa;➔ Estimável;➔ Pequena (Small); ➔ Testável (critérios de aceitação).

➔Planejamento de Liberações (Relase Planning):

➔ Embora todo Incremento produzido ao final de uma Sprint deva obedecer aos critérios de Pronto (Done), nem todo Incremento precisa ser Liberado (Released) para o Cliente.

➔ Dono do Produto é o responsável pelo Planejamento de Liberações;

➔Planejamento de Liberações:➔ Uma Liberação pode incluir trabalho de mais de

uma Sprint;➔ Sprints de Liberação ou Sprints de Release são

aquelas nas quais uma liberação do Incremento será realizada. Tais Sprints podem contem operações adicionais necessárias à liberação (equipe de vendas, preparação do suporte, treinamento, …);

➔Planejamento de Liberações:➔ Product Burndown ou Release Burndown é uma

ferramenta gráfica para o Planejamento de Liberações: precisa da Velocidade do Time e da Estimativa de cada PBI;

➔ No inicio do projeto, velocidade ainda é incerta, portanto, plano de liberações também.

Fonte externa: http://www.scrum-institute.org/images_scrum/Simple_Burndown_Chart.jpg

Scrum na prática

Fonte externa: Projeto EduScrum. Disponível em: http://eduscrum.nl

➔Escalando Scrum:➔ Scrum pode ser utilizado por várias equipes

trabalhando no mesmo Backlog do Produto;➔ Backlog do Produto e Definição de Pronto devem

ser compartilhados por todas equipes;➔ Cada Time deve possuir seu próprio Dono do

Produto e seu Mestre Scrum;➔ Cada Dono do Produto ou Mestre Scrum pode

servir mais de um Time de Desenvolvimento.

➔Escalando Scrum - Scrum de Scrum (Scrum of Scrum):

➔ Reunião com um representante de cada Time de Desenvolvimento para alinhamento;

➔ Pode ser realizada duas ou três vezes por semana, logo após as Reuniões Diárias dos Times, com Time-box;

➔ Na reunião, cada representante “descreve” o que seu time está fazendo e depois repassa ao seu Time.

➔Escalando Scrum:➔ Ao final das Sprints, é necessário integrar trabalho

dos Times;➔ Não é obrigatório que todas equipes comecem

Sprints na mesma data (limitaria Donos de Produto e Mestres Scrum que atendem vários Times);

➔ NexusTM [32] é o Framework da Scrum.org que agrega diversos dos conceitos acima.

➔Passos para iniciar Scrum:➔ Definir Dono do Produto, Mestre Scrum e Time de

Desenvolvimento;➔ Dono do Produto deve criar e priorizar Backlog do

Produto inicial;➔ Iniciar Sprint;➔ Realizar Reunião de Planejamento da Sprint

(resultados: Meta da Sprint, Backlog da Sprint e Definição de Pronto);

➔Passos para iniciar Scrum:➔ Montar Quadro KanBan com Burndown;➔ Realizar Reuniões Diárias;➔ Realizar Reuniões de Refinamento (Grooming);➔ Realizar Reunião de Revisão da Sprint;➔ Realizar Reunião de Retrospectiva da Sprint;➔ Liberar Incremento (opcional);➔ Iniciar próxima Sprint.

➔Dinâmica - Scrum na fábrica de origamis:➔ Baseada na dinâmica da Fábrica de aviões [20]

[11];➔ Exercitar conceitos do Scrum em aproximadamente

uma hora;➔ Utilizar Time-box;➔ Para fins didáticos, Time-boxes dos eventos não

estão proporcionais aos recomendados pelo Guia;

➔Dinâmica - Scrum na fábrica de origamis:➔ Uma Sprint de dois dias (cada dia com apenas três

minutos para produção, totalizando seis minutos para toda produção);

➔ Cliente deseja montar estrutura de proteção:➔ 4 aviões Gripen para encomenda da Aeronáutica;➔ 5 aviões Rafale para encomenda da Aeronáutica;➔ 3 navios destroyer para Marinha;➔ 6 navios couraçados para Marinha.

➔Dinâmica - Scrum na fábrica de origamis - Parte 1:

➔ Time-box de um minuto;➔ Definir Dono do Produto, Mestre Scrum e Time de

Desenvolvimento.

➔ Time-box de 5 minutos;➔ Dono do Produto irá montar Backlog do Produto

com as devidas priorizações junto ao cliente (instrutor).

➔ Time-box de quinze minutos;➔ Realizar Reunião de Planejamento da Sprint;➔ Jogar Poker do Planejamento (imagine que a

produção de dois origamis tem 2 Pontos de História);

➔ Gerar Meta da Sprint➔ Definição de Pronto;➔ Montar Quadro KanBan com Burndown e Meta da

Sprint.

➔ Simulação do primeiro dia da Sprint;➔ 3 minutos de produção.

➔ Time-box de oito minutos;➔ Atualizar Quadro KanBan e Burndown;➔ Realizar Reunião Diária;➔ Três perguntas:

➔ O que fizemos ontem para alcançar meta da Sprint?➔ O que faremos hoje para alcançar meta da Sprint?➔ Algum obstáculo ?

➔ Simulação do segundo dia de produção;➔ 3 minutos de produção.

➔ Time-box de oito minutos;➔ Realizar Reunião de Revisão da Sprint;➔ Apresentação do Incremento para cliente;➔ Verificar velocidade do Time.

➔ Time-box de oito minutos;➔ Realizar Reunião de Retrospectiva da Sprint;➔ Levantar métrica da felicidade:

➔ De 1 a 5, como você se sente em relação ao seu papel na empresa ?

➔ Por que você se sente assim ?➔ O que tornaria você mais feliz no próximo Sprint ?

➔Dinâmica - Scrum na fábrica de origamis - Avaliação:

➔ Quais foram as maiores dificuldades ?➔ Os papéis foram exercidos adequadamente ?➔ O Time-box dos eventos foi obedecido ?➔ Como foi a manutenção dos artefatos ?➔ É possível utilizar os princípios aprendidos em sua

unidade de trabalho?

➔Scrum Pessoal:➔ Utilizar alguns dos princípios da agilidade para

organização de tarefas pessoais;➔ Sprints mais curtas, de uma ou duas semanas;➔ Planejamento da Sprint mais curto possível, com

estimativas;➔ Software Trello é gratuito, possui acesso web e

mobile.

Scrum no Brasil e governo

www.eunati.com.brScrum no Brasil e governo

➔Estudo de Melo et al [34]:➔ The Evolution of Agile Software Development in

Brazil – 2013;➔ 67,1% dos entrevistados relataram aumento na

velocidade de conclusão dos projetos.

➔Estudo de Melo et al - Métodos ágeis mais utilizados:

➔ Scrum (51,2% do total);➔ Scrum com XP (22,5% do total);➔ Totalmente customizado (8,1% do total);➔ XP (7,2% do total).

➔Estudo de Melo et al - Principais preocupações relacionadas à adoção de métodos ágeis:

➔ Falta de documentação (apontada por 51% dos entrevistados);

➔ Falta de previsibilidade (apontada por 43% dos entrevistados );

➔ Falta de planejamento inicial (apontada por 41% dos entrevistados).

➔Estudo de Melo et al - Principais barreiras relacionadas à adoção de métodos ágeis:

➔ Incapacidade de mudar a cultura organizacional (apontada por 50,7% dos entrevistados);

➔ Falta de pessoal com conhecimentos específicos (apontada por 43,3% dos entrevistados);

➔ Resistência geral à mudança (apontada por 41,4% dos entrevistados);

➔ Falta de colaboração do cliente (apontada por 38% dos entrevistados).

➔ II Seminário de Metodologia Ágil do SISP (MPOG): [33]

➔ Guia ágil em desenvolvimento colaborativo envolvendo BACEN, MPOG, MEC, MTUR, Serpro, CSJT, CNJ, TCU, UNB, etc;

➔ Foco em Scrum, XP e Lean.

➔Bacen:➔ Coaching Agil;➔ ROI: peso do cliente / peso do Poker.

Fonte externa: II Seminário de Metodologia Ágil do SISP. Disponível em: http://www.sisp.gov.br/guiaagil/wiki/eventos

➔Acórdão TCU 2314 de 2013 [35]:➔ Motivação: Investimentos de diversas instituições

públicas federais em treinamento e desenvolvimento (interno e mediante fábrica de software) utilizando métodos ágeis;

➔Acórdão TCU 2314 de 2013 - Riscos relativos a processos:

➔ 1) Contratação de desenvolvimento de software com adaptação de metodologia ágil que desvirtue sua essência. Exemplos: uma Sprint pode referir-se a mais de um sistema, o papel de Dono do Produto ser desempenhado por mais de uma pessoa, Mestres Scrum da contratante e da contratada;

➔ 2) Alteração da metodologia ágil adotada no instrumento convocatório no decorrer da execução contratual;

➔Acórdão TCU 2314 de 2013 - Riscos relativos a processos:

➔ 3) Ausência de definição dos artefatos ou alteração dos artefatos exigidos da contratada no instrumento convocatório durante a execução contratual;

➔ 4) Exigência de artefatos desnecessários ou que se tornam obsoletos rapidamente;

➔ 5) Utilização de contrato para desenvolvimento de software por metodologias tradicionais para desenvolvimento por métodos ágeis;

➔Acórdão TCU 2314 de 2013 - Riscos relativos a pessoas:

➔ 6) Falta de comprometimento ou colaboração insatisfatória do responsável indicado pela área de negócios no desenvolvimento do software;

➔ 7) Falta do conhecimento necessário do indicado pela área de negócios para o desenvolvimento do software;

➔ 8) Excessiva dependência da visão do indicado pela área de negócios;

➔Acórdão TCU 2314 de 2013 - Riscos relativos a pessoas:

➔ 9) Equipe da empresa contratada não ter expertise em desenvolvimento de software com métodos ágeis. Atestados de capacidade técnica;

➔ 10) Dificuldade de comunicação entre a equipe de desenvolvimento da contratada com o indicado pela área de negócios;

➔Acórdão TCU 2314 de 2013 - Riscos relativos a produtos:

➔ 11) Alteração constante da lista de funcionalidades do produto;

➔ 12) Iniciação de novo ciclo sem que os produtos construídos na etapa anterior tenham sido validados;

➔ 13) Falta de planejamento adequado do software a ser construído;

➔ 14) Pagamento pelas mesmas funcionalidades do software mais de uma vez, em virtude de funcionalidades impossíveis de serem implementadas em um único ciclo, ou em virtude da alteração de funcionalidades ao longo do desenvolvimento do software;

➔ 15) Não disponibilização do software em ambiente de produção para a utilização e avaliação dos reais usuários;

➔ 16) Forma de pagamento não baseada em resultados. Súmula – TCU 269.

➔Acórdão TCU 2362 de 2015 [36]:➔ Motivação: Contratação de desenvolvimento e

manutenção de sistemas informatizados organizações componentes da Administração Pública Federal, em especial quando utilizados métodos ágeis de desenvolvimento;

➔Acórdão TCU 2362 de 2015 [36]:➔ “191 - As organizações que estão usando

métodos ágeis foram unânimes em afirmar que, apesar das dificuldades iniciais decorrentes da mudança de metodologia, os resultados alcançados até aqui são animadores. Segundo os gestores dessas organizações, as entregas de sistemas desenvolvidos com base em métodos ágeis têm sido mais rápidas e com maior qualidade.”

➔Acórdão TCU 2362 de 2015 [36] – Características para sucesso:

➔ “192.1 - Que se avalie, antes do início de determinado projeto, se o uso de métodos ágeis é o mais adequado para ele”;

➔ “192.2 - Que a organização esteja comprometida com o uso da metodologia, de forma que os Product Owners (PO) … estejam disponíveis para trabalhar ao lado das equipes de desenvolvimento”;

➔ “192.3 - Que o desenvolvimento com métodos ágeis priorize equipes presenciais, a fim de facilitar as iterações, característica marcante do modelo”;

➔ “192.4 - Que as áreas demandantes estejam aptas a validar os produtos entregues e solicitar ajustes o mais cedo possível, a fim de que a força do desenvolvimento ágil, centrada em entregas rápidas, não seja comprometida”;

➔ “192.5 - Que as equipes de desenvolvimento conheçam profundamente a metodologia que estiver sendo utilizada, fazendo uso das cerimônias, como reuniões, e aceitando como naturais as solicitações de mudanças e melhorias”;

➔Acórdão TCU 2362 de 2015 [36]:➔ “193 - Acrescente-se que os gestores

entrevistados cujas organizações utilizam métodos ágeis não relataram incompatibilidade entre a sua utilização e o pagamento baseado em resultados. Segundo aqueles gestores, a aferição dos resultados tem sido feita a cada release entregue, por meio da contagem de pontos de função efetivamente executados”;

➔Acórdão TCU 2362 de 2015 [36]:➔ “194. Tendo em vista que o uso de métodos ágeis

incentiva a melhoria constante do produto, por meio de entregas incrementais, há o risco potencial de se pagar mais de uma vez pelo mesmo produto, considerando-se as diversas entregas. Para mitigar tal risco, caso uma determinada entrega acrescente funcionalidades a entregas anteriores (já pagas), o novo pagamento considera apenas o que foi modificado do produto em decorrência da nova release entregue”;

Conclusão, extras e bibliografia

www.eunati.com.brConclusão

➔Métodos ágeis são realidade no mercado e governo;

➔Conceitos simples e baseados no empirismo;➔Benefícios diversos para clientes e equipes;➔Possibilidade de adaptações às realidades

locais.

www.eunati.com.brRecursos extras

➔Ferramentas Open Source para Scrum:

www.opensourcescrum.com

➔Simulados gratuitos certificações Scrum:

https://www.scrum.org/Assessments/Open-Assessments/Scrum-Open-Assessment

www.eunati.com.brRecursos extras

➔Materiais, vídeos e apresentações sobre Scrum:

www.mountaingoatsoftware.com

www.mitchlacey.com/resources

www.infoq.com/br/agile/

epf.eclipse.org/wikis/scrum/

www.tiexames.com.br/novosite2015/curso_Scrum_Master.php

www.eunati.com.brBibliografia

➔ [1] Extreme Go Horse. Disponível em: <http://www.gohorseprocess.com.br>. Acesso em: 27/08/2015;

➔ [2] PMI. Um guia do conhecimento em gerenciamento de projetos, Guia PMBOK 5ª. ed. - EUA: Project Management Institute, 2013;

➔ [3] Wikipedia. Taiichi Ohno. Disponível em: <https://pt.wikipedia.org/wiki/Taiichi_Ohno>. Acesso em 28/07/2015;

➔ [4] Ohno, Taiichi. Toyota production system: beyond large-scale production, Productivity press, 1988. ISBN 8573071702;

➔ [5] Moura, Reinaldo A. KanBan: A simplicidade no controle da produção, São Paulo, IMAN, 1989. ISBN 890965;

➔ [6] Manifesto Ágil. Disponível em: <http://agilemanifesto.org/iso/ptbr/>. Acesso em 30/07/2015;

➔ [7] ClydeBank Business. Agile Project Management QuickStart Guide: a simplified beginner's guide to agile project management, ClydeBank Media, 2014;

➔ [8] ClydeBank Business. Scrum QuickStart Guide: a simplified beginner's guide to mastering Scrum, ClydeBank Media, 2014;

➔ [9] Ries, Eric. A Startup Enxuta, São Paulo, Leya, 2011. ISBN 9788581780139;

➔ [10] Youtube, Canal Nerdologia. Disponível em: <https://www.youtube.com/watch?v=eANH5f1ul7s>. Acesso em: 24/08/2015;

➔ [11] Sutherland, Jeff. Scrum: A arte de fazer o dobro na metade do tempo, Leya, 2014. ISBN 9788544100875;

➔ [12] Sutherland, Jeff; Schwaber, Ken. Guia do Scrum: Uma Guia Definitivo Para o Scrum, Scrum.Org e ScrumInc, 2013. Disponível em: <http://www.scrumguides.org>. Acesso em 04/08/2015;

➔ [13] Beck, Kent; Andres, Cynthia. Extreme Programming Explained: Embrace Change, Addison-Wesley, 2004;

➔ [14] Scrum.org. Disponível em: <http://www.scrum.org>. Acesso em 04/08/2015;

➔ [15] Wikipedia. Shuhari. Disponível em: <https://en.wikipedia.org/wiki/Shuhari>. Acesso em 06/08/2015;

➔ [16] Nonaka, Ikujiro; Hirotke Takeuchi. The new new product development game, Harvard Business Review, 1986;

➔ [17] Strayer, D.L.; Drews, F. A.; Crouch, D.J. A comparison of the cell phone driver and the drunk driver. Human Factors, 2006, 48, 2, pp 381-391;

➔ [18] Weinberg, Gerald. Software com qualidade (Quality Software Management), Makron Books, São Paulo, 1991;

➔ [19] Pesso, Avnaim et al. Extraneous Factors in Judicial Decisions, Proceedings of the National Academy of Sciences of The United States of America, EUA, 2011;

➔ [20] Steffens, Flávio; Prikladnicki, Rafael. Dinâmica Fábrica de Aviões 2.0, AgileWay, 2009. Disponível em: <http://agileway.com.br/2009/08/18/dinamica-fabrica-de-avioes-2-0/>. Acesso em 09/08/2015;

➔ [21] Milgram, Stanley. The perils of Obedience, Harper's Magazine, 1974;

➔ [22] Brooks , Frederick P. The Mythical Man-Month, Addison-Wesley, 1995 [1975];

➔ [23] Putnam, Lawrence; Myers, Ware. Small is Beautiful-Once Again, Familiar Metric Management, Quantitative Software Management Inc;

➔ [24] Putnam, Lawrence; Myers, Ware. Five Core Metrics: The Intelligence Behind Successful Software Management, Pearson, 2003;

➔ [25] Boehm, Barry. Software Engineering Economics, Prentice-Hall, 1981;

➔ [26] Microsoft MSDN. Estimating. Disponível em: <https://msdn.microsoft.com/en-us/library/hh765979.aspx>. Acesso em: 28/08/2015;

➔ [27] Lyubomirsky, Sonja et al. The Benefits of Frequent Positive Affect: Does Hapiness Lead to Success? Psychological Bulletin, Vol 131(6), 2005, pp. 803-55;

➔ [28] Hsieh, Tony. Satisfação Garantida (Delivering Happiness), Editora Thomas Nelson, 2010;

➔ [29] Coulter Wright, James; Alves Giovinazzo, Renata. Delphi – Uma ferramenta de apoio ao planejamento prospectivo. Caderno de Pesquisas em Administração, Universidade de São Paulo, V. 01, nº 12, 2ª Trimestre 2000;

➔ [30] Cohn, Mike. User Stories Applied For Agile Software Development. Addison-Wesley Professional, 2004;

➔ [31] EduScrum. Disponível em: <http://eduscrum.nl>. Acesso em 15/10/2015;

➔ [32] Schwaber, Ken. NexusTM Guide: The Definitive Guide To Nexus: The exoskeleton of scaled Scrum Development, Scrum.Org, 2015. Disponível em: <https://www.scrum.org/Portals/0/NexusGuide%20v1.1.pdf>. Acesso em 17/10/2015;

➔ [33] II Seminário de Metodologia Ágil do SISP. Apresentações disponíveis em: <http://www.sisp.gov.br/guiaagil/wiki/eventos>. Acesso em: 28/08/2015;

➔ [34] MELO, C. DE O. et al. The evolution of agile software development in Brazil, Journal of the Brazilian Computer Society, v. 19, n. 4, p. 523–552, 2013;

➔ [35] Tribunal de Contas da União. Acordão 2314 de 2013;➔ [36] Tribunal de Contas da União. Acordão 2362 de 2015.

www.eunati.com.brFim

seja ágil com scrum

Technology

psicología y scrum: desarrollo ágil de equiipos

compartilhando conceitos desenvolvimento Ágil e scrum

treinamento Ágil / scrum

scrum e pmbok: gerenciamento ágil de projetos

gerenciamento Ágil de projetos com scrum

desenvolvimento Ágil e scrum 101

scrum - metodo ágil

scrum desenvolvimento ágil

seja tester Ágil

desenvolvimento Ágil de software com scrum

gestión ágil de proyectos con scrum

desmitificando o ágil e o scrum

engenharia de software Ágil (scrum e fdd)

scrum. agenda manifesto Ágil origens do scrum componentes...

seja lento, seja Ágil: entendendo a cultura e o ecossistema...

scrum - uma metodologia ágil

desenvolvimento Ágil com xp e scrum

metodologia Ágil scrum

desenvolvimento Ágil com xp e scrum -...

scrum e o ambiente de desenvolvimento Ágil