Treinamento Scrum - Português

Preview:

Citation preview

SCRUMDesenvolvimento Ágil de SoftwareJonas Flesch - me@jonasflesch.com

DESPERDÍCIO

Nunca Raramente Às Vezes Frequentemente Sempre

Pesquisa do Standish Group nas maiores empresas de projetos dos EUA, revelou

que 64% das features pedidas pelos clientes são pouco ou nunca utilizadas

12 PRINCÍPIOS ÁGEIS

01Entrega contínua e desde cedo de

software com valor : satisfação do cliente

02Mudanças são bem-vindas: vantagem

competitiva para o cliente

03Produção em ciclos curtos: entrega frequente de software funcionando

04Pessoas de negócio e desenvolvedores

devem trabalhar em conjunto

05Equipe de indivíduos motivados, com o

suporte e a confiança necessários

06Conversação face a face é o método mais

eficaz de comunicação

07Software em funcionamento é a medida

de progresso do projeto

08Ritmo sustentável de trabalho, sem

correria e horas extras

09Excelência técnica e bom design

10Simplicidade:

A arte de maximizar o trabalho não realizado é essencial

11Equipes auto-organizadas:

empowerment!

12Melhoria contínua: inspeção e adaptação

SCRUM

• Scrum é baseado em processos empíricos

• Processos definidos dizem como devem ser executados

• Quando os processos são muito complicados para se definir como, processos empíricos são recomendados

SCRUM

• Transparência

• Inspeção

• Adaptação

PAPÉIS: A EQUIPE SCRUM

PRODUCT OWNER- Responsável pelo backlog e pelo valor- Assegura o valor do trabalho sendo

realizado pela equipe- Assegura que a equipe entende os itens

do backlog

SCRUM MASTER- Ensina Scrum e garante que ele é

seguido- Remove impedimentos

- Facilita o gerenciamento do backlog- Ajuda na comunicação

- Facilita eventos do Scrum quando necessário

TIME DE DESENVOLVIMENTO

- Auto organizado;- Multi-funcional;

- Não contém sub-equipes.

EVENTOS DO SCRUM

SPRINT

• Coração do Scrum;

• Tempo fixo (um mês ou menos);

• Nenhuma mudança que afeta os objetivos da sprint é realizada;

• Não se mexe na equipe;

• O escopo pode ser renegociado quando mais é aprendido;

PLANNING

• Responde duas perguntas:

• O que vai ser entregue no incremento da próxima Sprint?

• Como o trabalho para alcançar este incremento vai ser feito?

DAILY SCRUM

• O que foi alcançado desde a última reunião?

• O que vai ser feito até a próxima reunião?

• Quais são os impedimentos?

SPRINT REVIEW

• Inspeciona-se o resultado da Sprint e se adapta o Product Backlog se necessário;

• Recomenda-se quatro horas para uma Sprint de um mês;

• O Product Owner se inteira do que foi feito e do que não foi feito;

• O grupo colabora sobre o que fazer em seguida;

RETROSPECTIVA

• Inspenciona-se como foi a Sprint quanto a:

• Pessoas

• Relacionamentos

• Processos

• Ferramentas

• Cria-se um mapa dos pontos fracos e um plano de melhoria

ARTEFATOS DO SCRUM

PRODUCT BACKLOG

• Ordenado: itens são ordenados de acordo com a prioridade de sua implementação – de forma a maximizar o ROI do cliente

• Estimável: julgar e formar uma opinião sobre o tamanho do Product Backlog ou de uma parte relevante dele (ex. próxima Sprint ou Release)

PRODUCT BACKLOG• Emergente: lista incompleta e dinâmica em constante evolução. O

ambiente evolui e clientes e Time de Desenvolvimento aprendem sobre o produto

• Gradualmente refinado: de acordo com a ordenação

• itens do alto: menor granularidade, maior detalhe

• itens de baixo: maior granularidade, menor detalhe

DINÂMICAMitos e Fatos

MITOS E FATOS: PRODUCT OWNER1. O P. O. é o “proxy” ou representante do cliente, transmitindo seus desejos ao Time de Desenvolvimento

2. Embora deva ser influenciado por diferentes pessoas, o P. O. é o único que pode modificar o Product Backlog

3. O P. O. deve balancear necessidades e desejos dos diferentes stakeholders do projeto

4. O melhor P. O. é o próprio cliente ou alguém escolhido por ele

5. O P. O. deve ser apenas uma pessoa – deve haver apenas um ponto de decisão sobre o produto para o Time de Desenvolvimento

6. O P. O. em geral pode acumular o papel do ScrumMaster sem problemas

7. O P. O. deve colaborar de perto com o Time de Desenvolvimento para maximizar o valor entregue ao cliente

8. O P. O. deve cobrar do Time de Desenvolvimento o compromisso de que todos os itens escolhidos para o Sprint sejam desenvolvidos

9. A presença do P. O. não é obrigatória na reunião de Sprint Planning – basta o Time de Desenvolvimento escolher os itens do alto do Product Backlog

10. O P. O. é responsável por definir o produto certo a ser desenvolvido

MITOS E FATOS: PRODUCT OWNER1. MITO: O P. O. é o “proxy” ou representante do cliente, transmitindo seus desejos ao Time de Desenvolvimento

2. Embora deva ser influenciado por diferentes pessoas, o P. O. é o único que pode modificar o Product Backlog

3. O P. O. deve balancear necessidades e desejos dos diferentes stakeholders do projeto

4. MITO: O melhor P. O. é o próprio cliente ou alguém escolhido por ele

5. O P. O. deve ser apenas uma pessoa – deve haver apenas um ponto de decisão sobre o produto para o Time de Desenvolvimento

6. MITO: O P. O. em geral pode acumular o papel do ScrumMaster sem problemas

7. O P. O. deve colaborar de perto com o Time de Desenvolvimento para maximizar o valor entregue ao cliente

8. MITO: O P. O. deve cobrar do Time de Desenvolvimento o compromisso de que todos os itens escolhidos para o Sprint sejam desenvolvidos

9. MITO: A presença do P. O. não é obrigatória na reunião de Sprint Planning – basta o Time de Desenvolvimento escolher os itens do alto do Product Backlog

10. O P. O. é responsável por definir o produto certo a ser desenvolvido

MITOS E FATOS: SCRUM MASTER1. Para ser efetivo, o ScrumMaster já deve ter trabalhado como membro de um Time de Desenvolvimento

2. O ScrumMaster trabalha para que o Scrum seja corretamente utilizado, ensinando-o e reforçando seus valores e regras

3. O ScrumMaster deve trabalhar para remover impedimentos ao trabalho do Time de Desenvolvimento, mas apenas aqueles que não exigem mudanças organizacionais

4. ScrumMaster é o papel mais importante em um projeto que usa Scrum

5. O ScrumMaster deve ter boas habilidades interpessoais para facilitar a resolução de conflitos e promover a boa comunicação

6. O ScrumMaster deve proteger o Time de Desenvolvimento de interferências externas

7. O ScrumMaster o deve gerenciar o trabalho do Time de Desenvolvimento

8. O ScrumMaster trabalha em direção a se tornar cada vez mais necessário

9. Os ScrumMasters que trabalham o expediente inteiro nesse papel realizam melhor o seu trabalho

10. Ao opinar, impor ou interferir nas decisões de trabalho do Time de Desenvolvimento, o ScrumMaster torna-se menos eficiente

MITOS E FATOS: SCRUM MASTER1. MITO: Para ser efetivo, o ScrumMaster já deve ter trabalhado como membro de um Time de Desenvolvimento

2. O ScrumMaster trabalha para que o Scrum seja corretamente utilizado, ensinando-o e reforçando seus valores e regras

3. MITO: O ScrumMaster deve trabalhar para remover impedimentos ao trabalho do Time de Desenvolvimento, mas apenas aqueles que não exigem mudanças organizacionais

4. MITO: ScrumMaster é o papel mais importante em um projeto que usa Scrum

5. O ScrumMaster deve ter boas habilidades interpessoais para facilitar a resolução de conflitos e promover a boa comunicação

6. O ScrumMaster deve proteger o Time de Desenvolvimento de interferências externas

7. MITO: O ScrumMaster o deve gerenciar o trabalho do Time de Desenvolvimento

8. MITO: O ScrumMaster trabalha em direção a se tornar cada vez mais necessário

9. Os ScrumMasters que trabalham o expediente inteiro nesse papel realizam melhor o seu trabalho

10. Ao opinar, impor ou interferir nas decisões de trabalho do Time de Desenvolvimento, o ScrumMaster torna-se menos eficiente

O QUE UMA USER STORY NÃO É

UMA MOCKUP

CASO DE USO

LEMBRETE

SIMPLES AGRUPADOR DE

TAREFAS

O QUE É USER STORY

QUEM?

O QUÊ?

POR QUÊ?

Como um <PERFIL>, eu posso/gostaria/devo <FUNÇÃO> para

<VALOR>

Como um COMPRADOR, eu posso PESQUISAR

LIVROS para ESCOLHER O QUE VOU COMPRAR

DINÂMICA• Planejando um Hotel:

• Os membros do time representam os investidores que estão construindo um hotel

• Os grupos tem 5 minutos para decidir qual será o diferencial do hotel

• Depois serão 10 minutos para priorizar um backlog com 14 requisitos do hotel

PLANEJANDO UM HOTEL

• Agora imagine que durante a construção o dinheiro acabou assim que o 5o Item ficou pronto.

• Mesmo com apenas 5 dos 14 itens, o hotel atende aos objetivos propostos no início do exercício?

Eu, passageiro, gostaria de adquirir passagens aéreas no site da Gol, pois assim posso economizar tempo na busca

pela melhor opção

COMPRAR PASSAGEM AÉREA NO SITE DA GOL

USANDO MILHAS

SMILESPROGRAMA PARCEIROS

DELTA AIR FRANCE

USANDO DINHEIRO

PAGAMENTO BOLETO

PAGAMENTO CARTÃO

VISA MASTER

A/V 5X A/V 5X

COMPRAR PASSAGEM AÉREA

SMILES

AIR FRANCE

USANDO DINHEIRO

PAGAMENTO BOLETO

PAGAMENTO CARTÃO

VISA MASTER

A/V 5X A/V 5X

USANDO MILHAS

PROGRAMA PARCEIROS

DELTA

COMPRAR PASSAGEM AÉREA

USANDO MILHAS

SMILESPROGRAMA PARCEIROS

DELTA AIR FRANCE

USANDO DINHEIRO

PAGAMENTO BOLETO

PAGAMENTO CARTÃO

VISA MASTER

5X A/V 5XA/V

CRITÉRIOS DE ACEITAÇÃO

• Qual é o formato de um alerta?

• Quais são os meios de emissão?

• Repetidamente implica em qual frequência?

• Qual é o critério para determinar um atraso?

UM ALERTA DEVERÁ SER REPETIDAMENTE EMITIDO ASSIM QUE O

SISTEMA DETECTAR ATRASO EM UM PEDIDO

CRITÉRIOS DE ACEITAÇÃO

• Tem como objetivo definir os limites do que deve ser feito no desenvolvimento da User Story;

• Os Critérios de Aceitação guiam o Time para evitar a adição de características sem valor nas funcionalidades, ao mesmo tempo em que garante o mínimo necessário para entregar o valor proposto;

• São expressos por frases curtas e simples;

CRITÉRIOS DE ACEITAÇÃO

• Os Critérios de Aceitação são adicionados às User Stories durante as sessões de refinamento do Backlog;

• Eles devem ser escritos pelo Product Owner em conjunto com o Time, visando obter um conhecimento compartilhado sobre o que deve ser feito;

CRITÉRIOS DE ACEITAÇÃO

• Os Critérios de Aceitação também guiam o Time na definição dos Testes de Aceitação;

• Critérios de Aceitação são parte da Definição de Pronto.

RETROSPECTIVA

• “Independente do que descobrirmos, nós entendemos e realmente acreditamos que todo mundo fez o melhor trabalho

que pode, dado o conhecimento que tinha no momento, as suas habilidades, os recursos disponíveis, e a situação”

TESTE DE SEGURANÇA• 5 – Sem problema, eu vou falar sobre qualquer coisa.

• 4 – Eu vou falar sobre quase tudo; algumas coisas serão difíceis.

• 3 – Eu vou falar sobre algumas coisas, mas as outras será difícil

• 2 – Eu não vou falar muito, vou deixar o grupo trazer as coisas

• 1 – Eu irei sorrir, dizer que tudo está bem e concordar com os chefes

TRÊS L`S

• Liked - Gostei - coisas que eu realmente gostei

• Learned - Aprendi - coisas que eu aprendi

• Leaked - Faltantes - Coisas que eu senti falta

me@jonasflesch.com

Jonas Flesch

Recommended