INSTRUTOR: FERNANDO CUNHAEmail: fecunhainfo@gmail.comhttps://www.linkedin.com/in/fernandocunha2

Workshop Scrum

Agenda- Parte I

• INTRODUÇÃO• HISTÓRIA• SCRUM• VALORES DO SCRUM• PILARES• PAPÉIS E RESPONSABILIDADES• EVENTOS E ARTEFATOS

Agenda – Parte ||

• HISTÓRIAS• ESTIMATIVAS• BURNDOWN CHARTS • MITO OU VERDADE• FERRAMENTAS• CONCLUSÃO• AVALIAÇÃO

O que é!?O QUE É DESENVOLVIMENTO ÁGIL?

ou Método ágil é um conjunto de metodologias de desenvolvimento de software.

O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software, ou seja, projetos que visam entregar um software como produto.

Um pouco de história...

As definições modernas de desenvolvimento de software ágil evoluíram a partir da metade de 1990. Surgiram em virtude da grande regimentação e micro gerenciamento usado o modelo em cascata para desenvolvimento.

Alguns métodos ágeis:

• Scrum (1986);• Crystal Clear;• Programação extrema (XP)(1996);• Adaptive Software Development;• Feature Driven Development;• Dynamic Systems Development Method (1995);

O Manifesto ÁgilEm 2001, um grupo de profissionais, entre eles os criados do Scrum Jeff Sutherland e Ken Schwaber (criadores do Scrum), criaram o "The Agile Manifest", contendo 12 princípios:

01 - Satisfazer o cliente através da entrega continua e adiantada de software com valor agregado;

02 - Mudanças nos requisitos são bem-vindas;

03 - Entregar frequentemente software funcionando;

04 – Pessoas, negócios e desenvolvedores no mesmo time;

05 - Indivíduos motivados;

06 - Colaboração - conversas face a face;

O Manifesto Ágil07 - Software funcionando é a medida do progresso;

08 - Os processos ágeis promovem desenvolvimento sustentável;

09 - Continua atenção a excelência técnica e bom design aumenta a agilidade;

10 - Simplicidade - a arte de maximizar a quantidade de trabalho não realizado é essencial;

11 - As melhores arquiteturas, requisitos e design surgem de equipes auto organizáveis;

12 - Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz;

ScrumÉ um framework com o qual as pessoas podem resolver

problemas complexos e adaptáveis.

Scrum consiste em um Time Scrum e seus Papéis, Eventos e Artefatos.

Ele se baseia na teoria de controle empírico, onde diversos imprevistos ocorrem.

Time Scrum = auto organizado

Valores de Scrum:Foco - CoragemSinceridade - ComprometimentoRespeito

ScrumPilares:01 - Transparência

Seja mais específico?

02 – InspeçãoInspecionar o que?

03 – AdaptaçãoDê um exemplo por favor?

Todos os jargões devem ser compartilhados (Definition of Done, a definição de “pronto” dos clientes e da equipe são a mesma).

Averiguar com frequência os artefatos (backlog do produto, backlog do Sprint, burndown…) e progressos do projeto, para encontrar problemas ou oportunidades;

Principalmente através dos eventos: Sprint Planning Meeting - Daily Scrum - Sprint Review - Sprint Retrospective;

PAPÉIS E RESPONSABILIDADES

Product Owner

Esse papel é o responsável pela Visão do que você vai construir ou entregar em seu projeto.

Dentro de suas responsabilidades, o Product Owner(PO) leva em consideração os riscos e os benefícios, o que é possível, o que pode ser feito, em outras palavras, é quem diz o que precisa e o que não precisa ser feito em relação ao produto que está sendo desenvolvido.“Sem um Product Owner, não há Scrum” Jeff Sutherland

“Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. “ Guia do Scrum™

Ele o responsável pelo resultado do projeto e conhece as necessidades

Scrum Master

Ele vai orientar o restante da equipe em relação à estrutura de processos do Scrum, além de ajudar a eliminar qualquer obstáculo que os esteja deixando mais lentos ou que impeça o progresso das atividades.  é o responsável também pela aplicação das regras. Uma parte fundamental desse papel é proteger a equipe e mantê-la focada nas tarefas em mãos.

“O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum” Guia do Scrum™

O que ele é:• Facilitador (garante que o processo seja seguido)• Protege o time• Remove impedimentos• Auxiliar o PO

O que ele não é:• Programador• Analista de negócio• Líder da equipe, pois a equipe é auto-organizada

Developer Team

Em Scrum, todo o desenvolvimento é feito pelo Development Team. Para isso, é necessário que ele seja composto de pessoas de diferentes perfis profissionais, como: analistas, arquitetos, designers, desenvolvedores, testadores etc.

“O Development Team deve ser auto-suficiente”

O Time é responsável por desenvolver incrementos potencialmente entregáveis do produto, segundo a Definition of Done (DOD) pré-estabelecida.

O time auto-gerenciado tem autoridade sobre o trabalho que fazem, assim também como são responsáveis por ele.

“Responsável por desenvolver o produto...”“Promove a colaboração...”

• Normalmente pequeno (até 8 pessoas);• Reforçam o conceito de DONE!• Não ficam esperando por tarefas, vão e pegam

(Pro-Ativos).• Orientado a entrega.

Quem é o gerente?

No Scrum não existe uma gerência centralizada, no entanto, existe a gerencia descentralizada:Product Owner, gerenciando o que de ser entregue, Scrum Master auxiliando a equipe para o Scrum seja executado e a equipe que é autogerenciada.

Developer Team

Os 4 estágios da auto-organização, por Bruce Tuckman (psicólogo 1965)

Forming:É o início da formação do Time, onde ninguém ainda se conhece;

Storming:É quando os membros do time passam a se conhecer e ainda não estão habituados ao comportamentouns dos outros.

Norming:É quando o membros começam a aparar as arestas, criando algumas normas ou regras implícitas;

Performing:Quando o time começa a funcionar de forma sincronizada e com isso melhorando o desempenho. O Scrum Master tem papel fundamental atuando como facilitador principalmente.

• Histórias / Tarefas• Product backlog• Sprint backlog• Burndown charts

Artefatos

• Sprint planning• Sprint review• Sprint retrospective• Daily scrum meeting

Eventos

EVENTOS

SprintO Scrum possui alguns eventos de duração fixa (time-boxed) realizados em intervalos regulares.

Cada um destes eventos são oportunidades para inspeção e adaptação.

Sprint

Todo o desenvolvimento em Scrum é feito de forma iterativa e incremental, essas interações são chamadas Sprints.

Cada Sprint tem duração de até um mês, mas geralmente tem duração de duas semanas, o que permite feedbacks constantes do Product Owner (PO) quanto ao produto sendo desenvolvido.

A Sprint consiste em um container de outros eventos que são: Sprint Planning, Daily Scrum, Sprint Review e Sprint Restrospective

Sprint Planning

Objetivo: Planejar o que será feito na Sprint

Quando: Sempre antes do início de cada Sprint

Quem participa: Scrum Master, Developer Team e Product Owner se necessário

Tempo: 8 horas para Sprint de 1 mês e é reduzido de forma proporcional.

Sprint PlanningFuncionamento: A reunião é dividida em duas partes e tem igual duração.

Parte 01:O Development Team faz a previsão das funcionalidades que serão desenvolvidas durante o Sprint.

Somente o Development Team é capaz de avaliar o que consegue realizar durante a Sprint.

A saída dessa reunião é a Meta do Sprint, ou seja, o itens selecionados do (Product Backlog), que deverão serem desenvolvidos. (esboço do Sprint Backlog).

Sprint Planning

Parte 02:É uma reunião de planejamento que o Development Team decide como transformará os itens selecionados em um incremento durante o Sprint.

Como o time é autogerenciado, se coordena para decompor os itens em unidades de uma dia ou menos, o suficiente para os primeiros dias do Sprint.

Após essa organização o Sprint Backlog está completo.

Daily Scrum

Objetivo: Comunicação e sincronização do trabalho. Ela faz parte do ciclo de Inspeção e adaptação do Scrum.Através dessa análise diária é possível corrigir algum problema no processo.

Quando: Diariamente

Quem participa: Scrum Master, Developer Team e Product Owner (opcional)

Tempo: 15 minutos

Daily Scrum

Funcionamento:

Cada membro da equipe responde para os outros membros:

• O que fiz desde a última Daily Scrum?• O que pretendo fazer até a próxima Daily

Scrum?• Existe algo me impedindo de concluir

alguma tarefa?

Daily Scrum

Funcionamento:

Após a última atualização do – Guia do Scrum™ 2013

• O que fiz ontem que ajudou o time a atingir a meta do sprint?

• O que vou fazer hoje para ajudar o time a atingir a meta do sprint?

• Existe algum impedimento que não permita a mim ou ao time atingir a meta do sprint?

Sprint Review

Objetivo: Inspecionar o que o Development Team produziu, colher opiniões dos presentes da reunião e caso necessário, adaptar o plano para o Sprint seguinte.Nessa cerimônia o PO valida ou não o Sprint.

Quando: No final de cada Sprint

Quem participa: Scrum Master ,Developer Team e Product Owner ou qualquer interessado no Produto.

Tempo: 2 horas

Sprint Review

Funcionamento:

• O Time comenta dos problemas enfrentados e soluções encontradas

• O Time demonstra algumas funcionalidades produzidas no Sprint

• O PO valida ou não o Sprint, de acordo com a Meta estabelecida

• Se necessário o Time adapta o plano para o novo Sprint

Sprint RetrospectiveObjetivo: Aprimoramento do processo, a interação com os membros do Time Scrum, as práticas utilizadas, o que funcionou e o que precisa ser melhorado na próxima Sprint.

*Os membros do Time, não devem encarar alguma crítica como pessoal

Quando: Imediatamente após o Sprint Review.

Quem participa: Scrum Master ,Developer Team e Product Owner (opcional)

Tempo: 3 horas, caso a Sprint seja de 1 mês.

Ciclo de Reuniões Completo

a

Estimativa Planning 1 Planning 2 Daily Review Retrospective

• Estima o tamanho das próximas Histórias relevantes, gerando o product backlog priorizado;

• Preparação para o release planning;• Visão de negócio;• 2 horas

Ciclo de Reuniões Completo

a

Estimativa Planning 1 Planning 2 Daily Review Retrospective

• Define o objetivo da iteração e quais Histórias serão atacadas;

• Agenda todas as próximas reuniões com seus objetivos e participantes;

• Selected Backlog é criado;• Discute-se pontos de atenção.• 4 horas para Sprint de 01 mês

Planejamento do Sprint (Planning 2)

a

Estimativa Planning 1 Planning 2 Daily Review Retrospective

Preparando-se para a guerra...

• Tarefas são criadas e tempos estimados COLABORATIVAMENTE!

• Tarefas são menores que um dia;• Cada membro escolhe suas tarefas;• Sprint Backlog é criado;• 4 horas para Sprints de 1 mês

Scrum meeting

a

Estimativa Planning 1 Planning 2 Daily Review Retrospective

A hora da verdade...

• 15 minutos diários!• Todos ficam em pé.• Não é para se resolver problemas.• Somente pessoas do time são envolvidas.• Um fala por vez.• Ajuda a evitar reuniões desnecessárias.

Sprint Review

a

Estimativa Planning 1 Planning 2 Daily Review Retrospective

O que aconteceu durante o Sprint.

• Tem a forma de uma demo;• Tudo que o time completou é

apresentado;• O PO aceita ou não o Sprint;• Normalmente leva 2 horas;

Retrospectiva do Sprint

a

Estimativa Planning 1 Planning 2 Daily Review Retrospective

Lavando roupa suja.

• 3 hrs para Sprint de 1 mês;• Discute-se o que não funcionou e

o que funcionou.• O time todo participa, inclusive o

cliente pode ser convidado!

Tempos e reuniões

a

Estimativa Prioriza e prepara o

Product BL2 horas

Planning 1Seleciona os itens do Product Backlog

1 hora

Planning 2Cria-se as tarefas e

owners2 horas

DailyRevê o andamento

do projeto15 minutos

ReviewVerifica se as metas

foram atingidas1 hora

RetrospectiveAnalisa os pontos

fortes e fracos15 a 30 min

a

Estimativa

Planning 1

Planning 2

Daily

Review

Retrospectiva

24h

• O ciclo se repete até o fim de todos itens do Backlog;• É muito importante trabalhar com versionamento de código fonte e documentação;• Para cada novo Sprint sugere-se criar uma

Branch de desenvolvimento;• Ao fim de cada Sprint, cria-se uma TAG para representar o entregável IMUTÁVEL;• Então esta TAG é comitada para o HEAD (merge);

Boas Práticas de Engenharia de Software

ARTEFATOS

• Product Backlog• Sprint Backlog • Definition of Done – Regras• Product Increment – Entrega• Task Boards

O que é:É uma lista ordenada criada pelo Time Scrum, mas onde

somente o PO pode inserir, remover e reordenar os itens e que cada item deve ter um valor de negócio associado (Business Value), onde podemos medir o retorno do projeto e priorizar a realização dos itens.

Objetivo:• Criação de todos os itens desejáveis do Produto.

Product Backlog

Product Backlog

a

Pontos importantes:• Além dos itens de negócio ou funcionais, os itens não-funcionais

também devem constar na lista como: Desenvolvimento de arquitetura, análise de tempo de resposta e itens de infraestrutura.

• O formato utilizado para estes itens é o de User Stories.

• Os itens mais importantes ou os de maior conhecimento, ficam no topo e serão implementados antes.

O que é:É o conjunto de itens selecionados para serem implementados durante a Sprint, mais o plano para transformá-los em um incremento.

Objetivo:Tornar visível o trabalho necessário para o Team Development atinja a meta do Sprint.Para isso somente o Time, pode adicionar tarefas, caso descubram, no decorrer do Sprint, que mais trabalho seja necessário.

É utilizado o task board para facilitar a visibilidade das atividades.

Sprint Backlog

a

Entendendo os diferentes Blacklogs

Blacklog

Prod

uctSão todos os

itens desejados no produto como um todo. Sejam funcionais ou não funcionais. Re

leas

eSão os itens que irão ser contemplados em um release. Um release tem um planejamento maior, pode ter janelas de meses ou anos dependendo do produto.

Sprin

tSão os itens que serão implementados no intervalo estabelecidos do Sprint, e farão parte portando do ciclo de desenvolvimento.

O que é:Como Scrum não define quaisquer práticas de engenharia de software para o Development Team, por outro lado recomenda-se que utilize práticas ágeis para garantir a qualidade do entregável.

Objetivo:É ter uma definição do que é uma funcionalidade “pronta”.Por exemplo: teste unitários e integrados ok e homologada pelo PO.

O DoD é importante para que todo o time saiba o que é “pronto”, desde do cliente ao Development

Definition of Done

Ao final de cada Sprint, o Development Team entrega o incremento do produto, resultado do que foi produzido durante o Sprint.

Esse resultado permite que o Product Owner (PO) perceba o valor do investimento e decida ou não coloca-lo em produção e esse é um dos princípios do Scrum.

Product Increment

Scrum – Visão Geral do Ciclo de Vida

a

Task boards

Objetivos dos quadrosO objetivos dos quadros é dar maior visibilidade no andamento das histórias.O quadro padrão do Scrum possui 4 colunas, são elas:

Sprint Backlog

To Do Doing Done

É onde ficam as

Estorias a serem

desenvolvidas no Sprint

São as tarefas

pertencentes as

estórias que estão aptas a serem

realizadas

São as tarefas

pertencentes as

estórias que estão

em desenvolvimento por

algum membro do

time

São as tarefas

finalizadas.A estória é

movida para essa colunas

, somente após todas as tarefas tenha sido finalizadas

Objetivos dos quadrosPara melhorar a visibilidade, o card de tarefa, poderá ter o nome de quem a está executando. Outro ponto importante é a necessidade de incluir outras colunas, como por exemplo :“Em Testes”, “Aguardando validação”, no entanto, cuidado para não virar um quadro Kanban.

Sprint Backlog

To Do Doing Done

É onde ficam as

Estorias a serem

desenvolvidas no Sprint

São as tarefas

pertencentes as

estórias que estão aptas a serem

realizadas

São as tarefas

pertencentes as

estórias que estão

em desenvolvimento por

algum membro do

time

São as tarefas

finalizadas.A estória é

movida para essa colunas

, somente após todas as tarefas tenha sido finalizadas

Testing

KanbanKanban foi um método criado pela Toyota, com o objetivo de sinalizar os passos de sua produção.O quadro Kanban possui algumas diferenças importantes em relação ao quadro Scrum.

As mais importantes são:KANBAN SCRUMWIP* – limitado diretamenteNo Kanban quando chega no limite de WIP, o trabalho para, pois é um sistema puxado

WIP – limitado por SprintNo Scrum o trabalho para somente quando as atividades do Sprint finalizam

TimeBox opcionais TimeBox por SprintEstimativa opcional Estimativa prescritaNão possui Papéis definidos Possui 3 papéis (visto anteriormente)

Não possui colunas obrigatórias e a mesmas podem ser subdividas

Possui 4 colunas padrões

WIP* – Work In Progress

Boards

KANBAN SCRUM

Exercício 01:Crie um quadro Kanban, e crie as colunas levando em consideração um equipe de infraestrutura de sustentação.

Obs: coloque os WIPs de cada coluna.

PARTE II

• HISTÓRIAS• ESTIMATIVAS• REPORTS• MITO OU VERDADE• FERRAMENTAS• CONCLUSÃO• AVALIAÇÃO

•História de Usuário• História Técnica•Estrutura da História•Técnicas para escrever histórias

Histórias

HistóriaDefinição: Segundo AgileAlliance, a estórias são escritas através de entrevista com o cliente ou com o PO, e o time divide o trabalho através de incrementos funcionais, chamados de “users stories”.

Uma outra definição da Adaptworks, um pouco mais direta é que a Estória representa uma funcionalidade ou característica do produto “narrada” pelo ponto de vista do usuário.

Lembrando que cada estória deverá entregar um Valor ao produto, que está sendo desenvolvido.

Estrutura de uma História de Usuário

Quem? O que? Por que?

Como um <usuário>, Gostaria de

<funcionalidade>para <valor de

negócio> Exemplo 01:

Como um auxiliar de contabilidade,Gostaria de poder emitir boletos bancários para facilitar o controles dos recebimentos.

Exemplo 02:

Como um Cliente,Eu gostaria de visualizar os planos existentes para decidir qual plano devo comprar.

Técnica de Validação de Histórias

I NDEPENDENTE

N EGOCIÁVEL

V ALIOSAE STIMÁVELP EQUENA

T ESTÁVEL

Os 3Cs segundo Ron Jeffries

Cards – histórias são escritas em cartões ou post-its (cards), naturalmente forçando as histórias serem pequenas

Conversation – A história escrita no cartão serve como um lembrete, tornando-se um convite ao diálogo (conversation)

Confirmation– O cliente define (implícita ou explicitamente) um maneira de validar (confirmation) esse pedido. Geralmente com testes de aceitação.

História Técnica versus História de Usuário

Muitas vezes dentro dos projetos, no deparamos com requisitos técnicos e que em nenhum momento foi solicitado pelo o usuário ou PO, por exemplo, efetuar uma migração de um banco de dados e instalar e configurar um servidor.

Porém esses requisitos para o usuário final não agregam valor ao produto de forma direta, no entanto, sabemos que são mandatórios e até mesmo impedem que algum requisito funcional (user story) seja implementado.

O que fazer então?

História Técnica versus História de Usuário

Trazendo um pouco para o desenvolvimento cascata, esses requisitos geralmente são do tipo não-funcionais, no entanto, para convencermos o PO e o Cliente do projeto, devemos vinculá-los ao um ou mais requisitos funcionais (user story).

E com isso atualizar a estimativa de uma determinada historia afim de auxiliar o PO a escolher ou não adicionar a história em um determinado Sprint.

Requisitos funcionais definem as funcionalidades do sistema como deve reagir em condições específicas e como se comportar em determinadas situações. Podem ainda declarar o que o sistema não deve fazer. (PAULA FILHO, 2000).

Requisitos não funcionais são restrições sobre serviços ou funções oferecidas pelo sistema. Dentre elas destacam-se restrições de tempo, sobre o processo de desenvolvimento e de padrões. A descrição das restrições complementa a definição de requisitos (PAULA FILHO, 2000).

“Entendi, quer dizer então que uma User Story pode conter um ou mais requisitos funcionais ou requisitos de usuário e um Technical Story pode conter um ou mais requisitos não-funcionais e essas histórias podem estar vinculadas?”

USER STORYComo um auxiliar de contabilidade,Gostaria de poder emitir boletos bancários para facilitar o controles dos recebimentos.

USER STORYComo um Cliente,Eu gostaria de visualizar os planos existentes para decidir qual plano devo comprarTECHNICAL STORY

Como Arquiteto de Sistemas gostaria de projetar um servidor IIS versão 8 com banco de dados SQLSERVER versão 9 para suportar a aplicação de ERP XPTO

Sim!

História Técnica versus História de Usuário

a

Mapeamento de Histórias X Tarefas X Tarefa micro

• Como um administrador do site, desejo efetuar a manutenção dos usuários do mesmo;

• Adicionar/Editar usuário• Consultar Usuários (12h)

• Consultar Usuários• Esclarecer requisitos (1h)• Escrever caso de teste (2h)• Design GUI (2h)• Implementar Stored Procedure de busca de usuário (3h)• Integrar SP com Tela (2h)• Executar Test Cases e evidenciar (2h)

História

Tarefas Macro

Tarefa Micro

a

Mapeamento de Épico X História X Tarefa

• Implementar cálculo de Dólar Marroquino;

• Como um analista de crédito do Banco Bradesco eu desejo poder consultar o Forecast do Dólar marroquino ;

• Desenho da arquitetura (4h);• Criar layout do XML de invocação do fluxo (4h);• Criar página de parametrização do cálculo (8h);• Alterar motor de calculo para implementar algoritmo do Dólar Marroquino (24h);• Exportação de XLS de vértices e fatores (12h);• Escrever Test Cases.... Escrever Documentação... Arquitetura.. Executar TC...

Épico

História

Tarefas

Exercício 02:Em dupla, crie 2 histórias de usuário utilizando a técnica "INVEST"Após isso quebre em tarefas (mínimo duas tarefas por Historia)

•Planning Poker• Sequência Fibonacci•Velocidade da equipe

Estimativas

Estimativas de Software

Estimativa de software compõe uma das disciplinas de Engenharia Software e tem como objetivo elaborar: o esforço, prazo e o custo de uma determinada funcionalidade.

“Segundo Martin Flower, os desenvolvedores, que são naturalmente otimistas, tendem a estimar para baixo. Isso acontece mesmo que não sofram, pelo menos explicitamente, pressão para reduzir suas estimativas.”

“E segundo Siobhan Keaveney e Kieran Conboy, no artigo Custo de estimativas no desenvolvimento de projetos ágeis, demonstram que quanto menores as iterações (tanto em escopo quanto em tempo), maior será a precisão das estimativas de um projeto..”

Estimativas História do Usuário

Quando utilizamos “História” é comum utilizarmos uma outra unidadede medida, ao invés do usual “tempo” utilizado frequentemente em metodologias Tradicionais, no caso de “História”, utilizamos a medidaStory Points.

Ela é uma unidade de medida relativa que leva em consideração o esforço necessário para realizar determinada tarefa.

Para estimar o Development Team utiliza a User Story com menor esforço e a Utiliza como base para estimar as outras.

Planning PokerUma das melhores formas de estimar Story Point é através do Planning Poker.

Funcionamento:• Cada membro fica com um baralho contendo uma carta com cada ponto

correspondente. (sequência de Fibonacci)• Após o PO explicar a história, cada um mostra o quanto acha que será o custo da

história.• Após discussões e explicações, o time mostra novamente a carta correspondente.

Pontos importantes:• Como o time é multidisciplinar, vários experts fazem a estimativa;• O diálogo e justificativas permitem maior entendimento da história;• Estudos mostram que em média de estimativas individuais levam a melhores

resultados;• O planning poker utiliza a sequencia de Fibonacci,• por ela ser uma função quadrática e resultando em um faixa de valor;

Velocidade do TimeA velocidade do Development Team é sempre medido também em Story Points, por exemploQuantos Story Points foram entregues pelo time em determinada Sprint.

Essa velocidade é utilizada pelo PO para fazer o planejamento dos próximos Sprints.

Como eu faço para cobrar do clientes Story Points?

Livro: Agile Estimating And PlanningMike Cohn

Exercício 03:Junte 2 duplas e baseando nas Historias de cada um, simule um estimativa utilizando Planning Poker.

Para simular o carta do Poker, utilize a sequência Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144)

BurndownObjetivo:Medir o progresso da Sprint

Funcionamento:

• No eixo horizontal os dias da Sprint, do primeiro dia ao último;

• No eixo vertical os pontos que foram planejados para compor a Sprint, partindo do máximo de pontos da Sprint (velocidade da equipe) até zero

Burndown

BurndownExemplo:Temos 8 Histórias no Sprint, totalizando 60 pontos, no dia 10/01 a equipe produziu mais do que o previsto, já no dia 11/01 produziu menos do que o previsto, ou seja, a leitura do gráfico quando a linha azul é igual ou superior a vermelha, a velocidade da equipe está boa e vice-versa.

CFD – Cumulative Flow Diagram

Objetivo:Demonstrar a quantidade de trabalho acumulado demonstrando a saúde do fluxo do processo Scrum, levando em consideração as semanas do projeto.

CFD – Cumulative Flow Diagram

demonstra as entregas (isto depende da sua definição de

“pronto” DoD

Trabalho em progresso (work-in-progress

(WIP )trabalhos iniciados mas não terminados).

demonstra o escopo (ou backlog) do projeto.

Mito ou Verdade

• Scrum não tem documentação?

Mito!na verdade Scrum é um framework que define o processo de trabalho, boas práticas e disciplinas de Engenharia de Software podem e devem ser inseridas conforme a necessidade da sua organização.Scrum não determina como criar, por exemplo, algum artefato, ele se remete apenas ao processo.Junto a Scrum, especificamos nosso software. Normalmente utilizamos UML.

Mito ou Verdade

O PMI (Project Manager Institute) dá valor ao movimento Agile e até possui uma

certificação específica para isso?

Verdade!• Desde de 2011 o PMI certifica profissionais para

práticas ágeis (PMI-ACP)

Mito ou VerdadeScrum pode ser utilizado em projeto de

qualquer tamanho ou natureza?

Mito!

• É possível utilizar em projetos grandes, no entanto, os resultados são mais facilmente alcançados em projetos de TI e com equipes pequenas, de 5 a 9 integrantes.

Mito ou Verdade

Até 2018 75% da TI terá métodos ágeis?

Verdade!

• De acordo com o Gartner, a TI bimodal (misturando os métodos ortodoxos de trabalho com métodos ágeis)

• associa dois modos de TI, um enfatizando escalabilidade, eficiência, segurança e precisão e um outro não sequencial, enfatizando agilidade e velocidade.

Mito ou VerdadeA gestão com Scrum é uma anarquia.

Mito!

• O Scrum exige que tudo seja planejado, o time é responsável pela organização e execução do trabalho, e se compromete a realizar o melhor trabalho possível em prol a meta da Sprint, além do PO ser responsável pelo ROI do projeto.

a

Ferramentas• https://trello.com/• http://myscrumhalf.com/?lang=en• https://kanbanflow.com/• https://

www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/ferramenta_scrum_gratu_c3_adta_free96?lang=en RATIONAL TEAM CONCERT

• https://jazz.net/downloads/jazz-foundation/releases/6.0.1• https://msdn.microsoft.com/pt-br/library/ff731587.aspx - TFS

Microsoft

Conclusões

a

Benefícios com adoção do Scrum• Respostas rápidas a mudanças;

• Maior qualidade;• Aumento de produtividade;• Maior assertividade e visibilidade;• Cooperação e autonomia;

• Não adianta dizer que Scrum não funciona, se o processo está sendo executada de forma errada

• Scrum não resolve os problemas técnicos, como elaboração de documentação e de requisitos complexos, mas colabora para isso

• Projetos desenvolvidos em Scrum, não finalizam mais rápido, a diferença é a entrega do produto de forma diferente;

• A chave do Scrum é a comunicação, como em qualquer outra metodologia de desenvolvimento de software

• Devido ao auto-gerenciamento do time, o mesmo é responsável pela a entrega, ou seja, se o time falhar todos falham

Fernando Cunha

10 questões objetivas.Tempo: 30 minutos

Avaliação

a

Referências • Scrum - Guia de Referência - Adaptworks Treinamentos• INNOVIT - GESTÃO DE PROJETOS E MELHORIA DE PROCESSOS - Agile Aliance• PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos,

métodos e padrões. São Paulo: LTC Editora, 2000.• http://agilemanifesto.org/iso/ptbr/• http://www.mindmaster.com.br/scrum-11-passos/• http://www.mindmaster.com.br/scrum-master/• http://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf• https://www.youtube.com/watch?v=9__bzr_lX88• http://www.mindmaster.com.br/manutencao-de-sistemas/• http://www.infoq.com/br/news/2009/05/kniberg-kanban-v-scrum• http://scrumguides.org/scrum-guide.html

a

Referências • http://guide.agilealliance.org/guide/user-stories.html• http://www.infoq.com/br/news/2013/03/estimativas-possibilidade• http://www.knowledge21.com.br/sobreagilidade/user-stories/como-e-user-story/• http://pt.slideshare.net/manoelp/exemplos-de-user-stories• http://blog.myscrumhalf.com/2012/04/mitos-do-scrum/• https://brasil.pmi.org/brazil/CertificationsAndCredentials/PMI-ACP.aspx• http://

www.baguete.com.br/noticias/28/04/2015/gartner-75-da-ti-tera-metodos-ageis-ate-2018• http://www.mountaingoatsoftware.com/topics/scrum• http://www.crisp.se/planningpoker/• http://www.planningpoker.com/detail.html• http://www.mountaingoatsoftware.com/books/1• http://www.trainning.com.br/download/GUIA_DO_SCRUM.pdf

Obrigado!86