seja ágil com scrum

Jonathan Maia – PSM I TM

[email protected]

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


[email protected]

www.eunati.com.brSeja Ágil Com Scrum

3Jonathan Maia – PSM I TM

[email protected]

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

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




[email protected]


➔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!


[email protected]


➔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.


[email protected]

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;


[email protected]

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: [email protected]

http://www.eunati.com.br/

https://goo.gl/Jii7Ur

mailto:[email protected]


[email protected]

www.eunati.com.brSumário

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


[email protected]

www.eunati.com.brSumário

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


[email protected]


Introdução


[email protected]

www.eunati.com.brIntrodução


[email protected]


➔“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)


[email protected]


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

projetos e atividades.


[email protected]



[email protected]


➔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.


[email protected]


Gerenciamento de projetos


[email protected]

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.


[email protected]


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

criar um produto, serviço ou resultado exclusivo”


[email protected]



[email protected]


➔Projetos típicos utilizam modelo cascata/cachoeira.


[email protected]



[email protected]


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


[email protected]


➔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).


[email protected]


➔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.


[email protected]


➔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?


[email protected]


Agile


[email protected]

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].


[email protected]


➔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.


[email protected]


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


[email protected]




[email protected]


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

GE, …


[email protected]


➔Ó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, ...


[email protected]


➔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, ...).


[email protected]

www.eunati.com.brScrum na prática

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


[email protected]



[email protected]


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

http://www.youtube.com/watch?v=eANH5f1ul7s


[email protected]


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


[email protected]


➔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.


[email protected]


➔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;


[email protected]


➔ 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.


[email protected]


➔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.


[email protected]



[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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 ?


[email protected]


➔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;


[email protected]


➔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.


[email protected]


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

avança.


[email protected]


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


[email protected]


Scrum - inspirações


[email protected]

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

➔Comprometimento vs Envolvimento:

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


[email protected]


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


[email protected]


➔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)


[email protected]


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


[email protected]


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


[email protected]


➔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).


[email protected]


➔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);


[email protected]


➔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.


[email protected]


➔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;


[email protected]


➔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;


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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;


[email protected]


➔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.


[email protected]


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


[email protected]


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


[email protected]


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

http://www.youtube.com/watch?v=jUz1ytcnn3c


[email protected]


➔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.


[email protected]


➔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.


[email protected]



[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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;


[email protected]


➔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 ?


[email protected]


➔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.


[email protected]


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

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

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


[email protected]


➔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.


[email protected]


➔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).


[email protected]


➔ 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]


[email protected]


➔ 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%


[email protected]


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


[email protected]


➔ 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.


[email protected]


➔ 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


[email protected]


➔ 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 ?


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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).


[email protected]



[email protected]


➔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.


[email protected]


➔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.


[email protected]



[email protected]


➔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.


[email protected]


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


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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!


[email protected]


➔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 ?


[email protected]


➔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;


[email protected]


➔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;


[email protected]


➔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!


[email protected]


➔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 ?


[email protected]


Estrutura do framework Scrum


[email protected]

www.eunati.com.brEstrutura do framework

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


[email protected]


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


[email protected]


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


[email protected]



[email protected]


Equipes e papéis


[email protected]

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]


[email protected]


➔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.


[email protected]


➔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;


[email protected]


➔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.


[email protected]


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

http://www.youtube.com/watch?v=VT3wKbBNo64


[email protected]


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


[email protected]


➔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;


[email protected]


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

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

relação ao produto.


[email protected]


➔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;


[email protected]


➔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.


[email protected]


➔“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.


[email protected]


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


[email protected]


➔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);


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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);


[email protected]


➔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, …);


[email protected]


➔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.


[email protected]


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


[email protected]


➔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.


[email protected]


➔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.


[email protected]


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


[email protected]


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


[email protected]


➔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.


[email protected]



[email protected]


Tamanho Equipe Canais de Comunicação

2 1

3 3

4 6

5 10

6 15

7 21

8 28

9 36

10 45

11 55

12 66

13 78

14 91


[email protected]


➔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;


[email protected]


➔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).


[email protected]


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


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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.


[email protected]


Eventos


[email protected]

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).


[email protected]


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


[email protected]



[email protected]


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

prioritárias ?


[email protected]


➔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.


[email protected]



[email protected]


➔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.


[email protected]



[email protected]


➔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]


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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.


[email protected]



[email protected]


➔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]


[email protected]


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


[email protected]


➔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 ?


[email protected]


➔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;


[email protected]


➔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.


[email protected]


➔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

PBIs.


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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);


[email protected]


➔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;


[email protected]


➔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.


[email protected]


➔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.


[email protected]



[email protected]


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


[email protected]


➔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]


[email protected]


➔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.


[email protected]


➔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?


[email protected]


➔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;


[email protected]


➔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;


[email protected]


➔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).


[email protected]



[email protected]


➔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]


[email protected]


➔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”;


[email protected]


➔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”;


[email protected]


➔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.


[email protected]


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


[email protected]


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

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


[email protected]


➔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.


[email protected]


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


[email protected]


➔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.


[email protected]


➔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;


[email protected]


➔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).


[email protected]


➔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;


[email protected]


➔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.


[email protected]


➔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 ?


[email protected]


➔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.


[email protected]


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

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


[email protected]


➔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 ?


[email protected]


➔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.


[email protected]


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

http://www.youtube.com/watch?v=eNe0UEsBalA


[email protected]


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


[email protected]


Artefatos


[email protected]

www.eunati.com.brArtefatos


[email protected]


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


[email protected]


➔“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]


[email protected]


➔“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]


[email protected]


➔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.


[email protected]


➔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]


[email protected]


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

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


[email protected]


➔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.


[email protected]


➔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.


[email protected]



[email protected]


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


[email protected]


➔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);


[email protected]


➔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;


[email protected]


➔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.


[email protected]


➔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]


[email protected]


➔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;


[email protected]


➔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).


[email protected]


➔ 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]


[email protected]


Técnicas


[email protected]

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).


[email protected]


➔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.


[email protected]


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


[email protected]


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


[email protected]


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


[email protected]



[email protected]


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

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


[email protected]


➔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.


[email protected]


➔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]


[email protected]


➔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.


[email protected]



[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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;


[email protected]


➔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;


[email protected]


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

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


[email protected]


➔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;


[email protected]


➔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: ?


[email protected]


➔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.


[email protected]


➔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.


[email protected]


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


[email protected]


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


[email protected]


➔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;


[email protected]


➔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;


[email protected]


➔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).


[email protected]



[email protected]


➔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;


[email protected]


➔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, …);


[email protected]


➔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.


[email protected]


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


[email protected]


Scrum na prática


[email protected]


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


[email protected]



[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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.


[email protected]


➔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);


[email protected]


➔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.


[email protected]



[email protected]


➔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;


[email protected]


➔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.


[email protected]


➔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.


[email protected]



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

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


[email protected]



➔ 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.


[email protected]



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


[email protected]



➔ 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 ?


[email protected]



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


[email protected]



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


[email protected]



➔ 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 ?


[email protected]


➔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?


[email protected]


➔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.


[email protected]



[email protected]


Scrum no Brasil e governo


[email protected]

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.


[email protected]


➔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).


[email protected]


➔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).


[email protected]


➔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).


[email protected]


➔ 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.


[email protected]


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


[email protected]


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


[email protected]




[email protected]


➔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;


[email protected]


➔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;


[email protected]


➔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;


[email protected]


➔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;


[email protected]


➔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;


[email protected]


➔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;


[email protected]



➔ 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;


[email protected]



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


[email protected]


➔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;


[email protected]


➔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.”


[email protected]


➔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”;


[email protected]



➔ “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”;


[email protected]



➔ “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”;


[email protected]


➔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”;


[email protected]


➔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”;


[email protected]


Conclusão, extras e bibliografia


[email protected]

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.


[email protected]

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

http://www.opensourcescrum.com/




[email protected]

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

http://www.mountaingoatsoftware.com/

http://www.mitchlacey.com/resources

http://www.infoq.com/br/agile/

http://epf.eclipse.org/wikis/scrum/

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

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


[email protected]

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;

http://www.gohorseprocess.com.br/

https://pt.wikipedia.org/wiki/Taiichi_Ohno


[email protected]


➔ [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;

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


[email protected]


➔ [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;

https://www.youtube.com/watch?v=eANH5f1ul7s

http://www.scrumguides.org/

http://www.scrum.org/


[email protected]


➔ [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;

https://en.wikipedia.org/wiki/Shuhari


[email protected]


➔ [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;

http://agileway.com.br/2009/08/18/dinamica-fabrica-de-avioes-2-0/

http://agileway.com.br/2009/08/18/dinamica-fabrica-de-avioes-2-0/


[email protected]


➔ [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;

https://msdn.microsoft.com/en-us/library/hh765979.aspx


[email protected]


➔ [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;

http://eduscrum.nl/

https://www.scrum.org/Portals/0/NexusGuide%20v1.1.pdf


[email protected]


➔ [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.

http://www.sisp.gov.br/guiaagil/wiki/eventos


[email protected]

www.eunati.com.brFim

seja ágil com scrum

Technology