SCRUMDesenvolvimento Ágil de SoftwareJonas Flesch - [email protected]
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
Top Related