Introdução ao Scrum / Equipes de Qualidade e Teste no Mundo “Agile” - Criando equipes efetivas...
-
Upload
daniel-wildt -
Category
Documents
-
view
6.967 -
download
2
description
Transcript of Introdução ao Scrum / Equipes de Qualidade e Teste no Mundo “Agile” - Criando equipes efetivas...
Porto Alegre, 29/09/2004
Promoção! Pague 1 leve 2!Promoção! Pague 1 leve 2!Introdução ao Introdução ao ScrumScrum
Equipes de Qualidade e Teste no Mundo “Equipes de Qualidade e Teste no Mundo “AgileAgile””CriandoCriando equipesequipes efetivasefetivas parapara desenvolvimentodesenvolvimento de softwarede software
Promoção! Pague 1 leve 2!Promoção! Pague 1 leve 2!Introdução ao Introdução ao ScrumScrum
Equipes de Qualidade e Teste no Mundo “Equipes de Qualidade e Teste no Mundo “AgileAgile””CriandoCriando equipesequipes efetivasefetivas parapara desenvolvimentodesenvolvimento de softwarede software
Reunião GUMA Reunião GUMA –– Junho 2008Junho 2008Porto Alegre, 30/06/2008Porto Alegre, 30/06/2008
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 1][Slide 1]
Daniel Daniel WildtWildtFACENSA / FACENSA / javajava.net / XP.net / XP--RS GUMA / DUGRS GUMA / DUG--RS / RS / DevMediaDevMedia / JEDI/ JEDI
Daniel Daniel WildtWildtFACENSA / FACENSA / javajava.net / XP.net / XP--RS GUMA / DUGRS GUMA / DUG--RS / RS / DevMediaDevMedia / JEDI/ JEDI
Agenda
• Crenças• Princípios importantes• Equipes de Qualidade e Equipes de Teste no Mundo “Agile” -
Discussões
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 2][Slide 2]
Porto Alegre, 29/09/2004
CrençasCrençasCrençasCrenças
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 3][Slide 3]
Crença 1: Métodos ágeis não resolvem todos os problemas!
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 4][Slide 4]
Eles ajudam muito!
Só que eles não nasceram “do nada”.
E não são mágicos.
Crença 2: Comunicação é a origem dos problemas!
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 5][Slide 5]
Porto Alegre, 29/09/2004
Princípios ImportantesPrincípios ImportantesPrincípios ImportantesPrincípios Importantes
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 6][Slide 6]
O que é ser Ágil?
• Alguns princípios:• Maior prioridade é a satisfação do cliente e a entrega
contínua de software de valor agregado.• Pessoal da área de negócio e desenvolvimento devem
trabalhar unidos.• A medida primária de um projeto é software em
funcionamento• Em intervalos regulares o time vai refletir sobre como se
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 7][Slide 7]
• Em intervalos regulares o time vai refletir sobre como se tornar mais efetivo
• Construa projetos com profissionais motivados. Dê aos profissionais o ambiente necessário e dê suporte as necessidades da equipe. Principalmente, confie na equipe para ter o trabalho realizado.
• Mais em: http://www.agilemanifesto.org/principles.html
O que é ser Ágil? Manifesto ágil?
http://www.agilemanifesto.org
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 8][Slide 8]
Scrum = Métodos Ágeis? Existem outros?
• Agile Alliance http://www.agilealliance.orghttp://www.agilealliance.org/resources/usergroupshttp://www.agilealliance.org/articles
• Feature Driven Development - FDDhttp://www.featuredrivendevelopment.com/
• Lean Developmenthttp://www.poppendieck.com/
• Scrumhttp://www.controlchaos.com/
• MSF for Agile
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 9][Slide 9]
• MSF for Agilehttp://lab.msdn.microsoft.com/teamsystem/workshop/msfagile/
• Crystal http://alistair.cockburn.us/crystal/crystal.html
• DSDMhttp://www.dsdm.org/
• eXtreme Programminghttp://www.extremeprogramming.org/
Scrum
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 10][Slide 10]
http://www.codeproject.com/gen/design/scrum.asp?pri nt=true
Scrum
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 11][Slide 11]
http://www.jeffsutherland.com/oopsla/schwapub.pdf
Porto Alegre, 29/09/2004
Equipes de Qualidade e Equipes de Teste no Equipes de Qualidade e Equipes de Teste no Mundo “Mundo “AgileAgile” ”
DiscussõesDiscussões
Equipes de Qualidade e Equipes de Teste no Equipes de Qualidade e Equipes de Teste no Mundo “Mundo “AgileAgile” ”
DiscussõesDiscussões
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 12][Slide 12]
Não faça seu time desenvolver trabalho desnecessário
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 13][Slide 13]
E deixe sua equipe motivada e sabendo como contribuir com o dia a dia da empresa!
Lean? Muitos dos princípios presentes no Scrum estão no Lean.
• Lean é um processo cultural de eliminação sistemática de desperdícios através de mecanismos de melhoria contínua.
• Identifica valor na perspectiva do cliente• Disciplina para melhorar o fluxo de trabalho, focando naquilo
que o cliente necessita.• Produção enxuta • Princípios importantes:
• Eliminar desperdício (eliminate waste)• Construa com qualidade (build quality in)• Crie conhecimento (create knowledge – drive by
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 14][Slide 14]
• Crie conhecimento (create knowledge – drive by feedback)
• Taichii Ohno e Shigeo Shingo, responsáveis por termos como:• Just In Time Production• Stop the Line Culture (Jidoka, Autonomation)• Zero Inspection (mistake-proof)
• Toyota Production System (TPS), hoje conhecido como Lean Thinking, Lean Enterprise, Lean Manufacturing, entre outros.
Lean? Muitos dos princípios presentes no Scrum estão no Lean.
• O time de qualidade é um dos principais responsáveis porfazer acontecer a eliminação de desperdícios. • Realizar ações de melhoria contínua
• Eventos de Kaizen• Reuniões de Retrospectiva do Scrum• PDCA
• Identifica valor na perspectiva do cliente• No caso de Métodos Ágeis, o cliente deve estar presente• Presente = disponível para o time de projeto
• Produção enxuta
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 15][Slide 15]
• Produção enxuta• Nivelamento da produção (Heijunka)
• Faça a quantidade de análise que será possível ser construída• Codifique a quantidade de funcionalidades que poderão ser
testadas• E por consequência validadas pelo cliente• Encontre o ritmo do time e capacidade de produção
• Criação de conhecimento deve ocorrer com todo o time• Time de qualidade e testes, trabalhando junto com
desenvolvedores, atuando como consultores (apoiadores)• Alinhados com os parceiros de negócio (cliente)• E criando trabalho de qualidade, sempre.
Cuidado com o “by the book” e o “ouvi falar”. Use, adapte e melhore!
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 16][Slide 16]
Antes de fazer algo, busque boas práticas no mercado!
Saiba o benefício que as práticas vão trazer para as pessoas e para o ambiente.
Não conte mentiras para o seu time!
Quem faz a diferença é a equipe
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 17][Slide 17]
eXtreme Programming – Uma equipe Scrum avançada usa práticas XP
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 18][Slide 18]
http://www.xprogramming.com/
Seu cliente conhece o dia a dia do projeto? Você fala a verdade?
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 19][Slide 19]
Uso de comunicação e princípios de produção enxuta!
O cliente deve ser um aliado!
Não conte mentiras para o seu cliente!
Não prometa uma entrega e indique um tempo acima do estimado para ganhar credibilidade. Encontre a capacidade do seu time.
Confiança no time e Custo do time – Foco das métricas muda.
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 20][Slide 20]
Acompanhar o time? Não seria melhor acompanhar o produto que o time desenvolve?
Você não gerencia mais pessoas, gerencia um produtoque deve ser entregue e atender as necessidades dos clientes.
Desenvolva o time TODO!
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 21][Slide 21]
As pessoas vão aprender a fazer certo da primeira vez
A equipe troca experiências
Nivelamento do conhecimento de forma efetiva
Time mais experiente e gerando trabalho com maisqualidade.
O famoso gráfico burndown! Controle estilo “stock market”
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 22][Slide 22]
Analise o que o BurnDown está indicando, ele será um aliado para a melhoria contínua do time. E ele não mente.
Planejamento – Nada de prever o futuro
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 23][Slide 23]
Tipos? Release (baseado no backlog), Sprint/Iteração (prioridades do backlog) e Diário (Daily Meeting).
Priorize os itens de backlog baseado na sua necessidade para o negócio (ROI – Return of Investment)!
Velocidade do time (Burn down de horas) e backlog(escopo) são variáveis que sempre devem ser acompanhadas e visíveis ao cliente.
Planejamento – NÃO TENTE PREVER O FUTURO!!!! ☺☺☺☺
Defina o que vai ser feito dentro da janela do projeto!
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 24][Slide 24]
Defina o que vai ser feito dentro da janela do projeto!
Tarefas menores aumentam a motivação da equipe!
Melhor ter 10 tarefas de 4 horas do que 1 tarefa de 40 horas!
Estabeleça prioridades e faça aquilo que é necessário.
Não tente prever o futuro, e revise as previsões sempre.
O time sabe dizer quando está pronto. Pronto.
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 25][Slide 25]
Pronto?Pronto pode indicar que a codificação foi feita.Pronto pode indicar que a codificação + teste foi feito.
Pronto pode indicar que a codificação + teste + integração + regressão foi feita e que a instalação da funcionalidade pode ser realizada quando se desejar.
Evolua com o time o conceito de “pronto”.
O time sabe dizer quando está pronto. Pronto.
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 26][Slide 26]
O que fazer, se a codificação de uma tarefa terminou e falta o teste. Chegou o fim da iteração e o teste não está pronto nem a validação do cliente. A funcionalidade não está pronta.
A funcionalidade deve ser testada pelo cliente. O feedback dele é necessário e vital para o bom andamentodo projeto.
O burndown não mente!!!
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 27][Slide 27]
Adicionar mais recursos em um projeto atrasado não resolve o problema!
Manter o ritmo da equipe é necessário!
Achar que a velocidade da equipe pode dobrar a produção de uma semana para a outra não tende a se tornar realidade.
Failure Quality is not an option!
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 28][Slide 28]
Lembre do princípio Lean! Quality Built-in. Nada de deixar qualidade para depois da entrega.
O controle de qualidade é algo contínuo. Não estápresente em uma fase específica.
Não espere uma tarefa estar 100% pronta para começara verificar. Se algo está disponível para o cliente(protótipo de tela por exemplo), mostre e busquefeedback. Ande conforme o feedback!
Dica: busque soluções OpenSource antes de investir.
JUnitSelenium IDE
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 29][Slide 29]
Que tipo de teste? Exemplos de testes que um time pode usar
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 30][Slide 30]
http://www.ambysoft.com/essays/floot.html
Resumindo... O papel da equipe de qualidade no ambiente Ágil
• Após selecionar uma funcionalidade para ser trabalhada: • Iniciando…
• Desenvolvedores, testadores e com o cliente devementender a funcionalidade e o objetivo dela no negócio. Qual o benefício daquela funcionalidade parao negócio?
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 31][Slide 31]
o negócio?• Comunicação é o mais importante neste início!
• Descreva:• As tarefas que devem ser implementadas para
completar a tarefa. • Os testes de aceitação que devem ser executados
para indicar que a tarefa está pronta. • Estes testes de aceitação fazem sentido para toda
equipe (inclui cliente).
Resumindo... O papel da equipe de qualidade no ambiente Ágil
• Após selecionar uma funcionalidade para ser trabalhada: • Controle
• Uma funcionalidade deve seguir princípios comoINVEST
• I – Independent• N – Negotiable
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 32][Slide 32]
• N – Negotiable• V – Valuable• E – Estimable• S – Small• T – Testable
• Dica: Foque no Testable, ou seja, escrevaespecificações testáveis, para o desenvolvedor, para o testador e para o cliente.
Resumindo... O papel da equipe de qualidade no ambiente Ágil
• Após selecionar uma funcionalidade para ser trabalhada: • Execução
• Desenvolvedor e Testador acertam o plano de trabalho, foco de testes que serão trabalhados pelodesenvolvedor e foco de testes que o testador vaitrabalhar.
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 33][Slide 33]
trabalhar. • Cliente vai acompanhar e apoiar. • Focos:
• Desenvolvedor = Testes de Unidade e Qualidade do fonte• Testador = Testes Funcionais, Testes de Performance• Cliente = Validação
• Como validar se os testes são eficientes?• Ferramentas de cobertura de código (exemplo EMMA para
Java, NUnit para .NET, RCov para Ruby)• Q&A = Identificar outras métricas úteis para equipe.
Resumindo... O papel da equipe de qualidade no ambiente Ágil
• Após selecionar uma funcionalidade para ser trabalhada: • Execução
• Quando começar a testar?• Assim que existir algo testável.
• É necessário ter 100% da funcionalidade pronta parainiciar testes?
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 34][Slide 34]
iniciar testes?• Não, assim que o desenvolvedor e testador entram em
acordo sobre algo que já pode ser verificado, iniciar testes. • Se for possível obter feedback do cliente, fazer isto.
• E automação? Quando começar?• Dependendo da situação, é importante estabilizar a
construção da interface gráfica para se poder então trabalharna automação do teste.
• Por isto é importante chegar em um acordo cedo sobre a telaa ser construída. Inclusive com o aceite do cliente o quantoantes.
Resumindo... O papel da equipe de qualidade no ambiente Ágil
• Após selecionar uma funcionalidade para ser trabalhada: • Execução
• E o testador de performance? Quando ele entra?• No início do processo, quando se identifica que a
funcionalidade é crítica. Depois da tarefa pronta, ele poderodar testes e verificar a funcionalidade.
• E o pessoal de Auditoria, do Q&A (Quality and
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 35][Slide 35]
• E o pessoal de Auditoria, do Q&A (Quality and Assurance)? Eles existem?
• Sim, eles podem existir dentro do seu projeto. Só que elesnão podem ser preenchedores de checklists e calculadoresde percentuais!
• Devem funcionar como consultores, apoiando o projeto.• Devem ao encontrar algum problema ou falha na infra
estrutura do projeto, sugerir um plano de ação e proverconsultoria para o time, para que esta implantação e melhoriaocorra.
Resumindo... O papel da equipe de qualidade no ambiente Ágil
• Após selecionar uma funcionalidade para ser trabalhada: • Acompanhamento
• Quando se sabe do atraso de uma tarefa?• Como as tarefas são pequenas fica fácil da equipe saber
quando uma tarefa está fora dos padrões. • Só se avisa sobre o atraso na reunião diária?
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 36][Slide 36]
• Só se avisa sobre o atraso na reunião diária?• Não, assim que o time souber de algum atraso, todos devem
ser notificados, para que ações possam ser tomadas. • E aí? Faço hora extra?
• Mantenha o time motivado. Horas extras devem ser feitas emsituações de exceção. Encontre a capacidade de produçãodo time. Com isto se acerta expectativa do cliente. Aceite queo planejamento falhou. Melhore na próxima!
• Quando o cliente é avisado?• O cliente é avisado quando o time é avisado. O cliente faz
parte do time!!
Resumindo... O papel da equipe de qualidade no ambiente Ágil
• Após selecionar uma funcionalidade para ser trabalhada: • Acompanhamento
• Quando o projeto vai acabar?• Quando o cliente não tiver mais funcionalidades a serem
trabalhadas. Quando o ROI das funcionalidades que foramimplementadas está interessante para ele.
• E os defeitos? Como ficam?
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 37][Slide 37]
• E os defeitos? Como ficam? • Todo defeito deve ser tratado como um desperdício. • Encontre a causa raiz dos defeitos• Verifique a severidade, para identificar se é necessária
alguma ação imediata ou se o defeito pode entrar para o backlog do produto.
• Um defeito não entra no cálculo de capacidade de produção. Ele não faz parte da produção do time, ele é um desperdício, ele está atrasando o time para entregar novas funcionalidades.
Resumindo... O papel da equipe de qualidade no ambiente Ágil
• E o time? Como desenvolvo o time? O que é importante?
• Treinamentos de comunicação, programaçãoneurolinguística.
• Seu time precisa desenvolver liderança• Desenvolver o trabalho com os clientes.• Capacidade de ensino e aprendizado
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 38][Slide 38]
• Capacidade de ensino e aprendizado• Unir times de desenvolvimento, teste e negócio.• Colaboração• Claro, treinamento de Métodos Ágeis para o time
conhecer as metodologias que serão trabalhadas e osprincípios.
• Conhecer o Sistema Toyota de Produção, conhecer osprincípios. Dica: Leitura do “Toyota Way”.
• Focar nas chamadas “soft skills”.
Referências
• Beck, Kent; Andres, Cynthia. Extreme Programming explained: embrace change. 2ª edição. Pearson Education, 2005.
• Poppendieck, Mary; Poppendieck, Tom. Implementing Lean Software Development: From concept to Cash. Pearson Educatoin, 2007.
• Schwaber, Ken. Agile Project Management With
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 39][Slide 39]
• Schwaber, Ken. Agile Project Management With Scrum. Microsoft Press, 2004.
• Liker, Jeffrey. The Toyota Way. McGraw-Hill, 2004.• Koscianski, André; Soares, Michel dos Santos.
Qualidade de Software, São Paulo: Novatec, 2006.• Pressman, Roger S. Engenharia de Software. São
Paulo: Makron, 2002.
Referências
• Manifesto Ágil. Disponível na www em http://www.agilemanifesto.org
• Tinkha, Andy; Kaner, Cem. Exploring Exploratory Testing. Disponível na www em http://www.testingeducation.org/a/explore.pdf
• Método FLOOT de Scott Ambler. Disponível na www em http://www.ambysoft.com/essays/floot.html
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 40][Slide 40]
www em http://www.ambysoft.com/essays/floot.html• Complexidade Ciclomática. Disponível na www em
http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html
• Implementing Scrum (BLOG). Disponível na www emhttp://www.implementingscrum.com/cartoons/
Referências
• Qualidade em desenvolvimento Java para todos os gostos, por Daniel Wildt, apresentada no JustJava2006. Disponível na Internet:• https://fuja.dev.java.net/files/documents/3136/449
51/FACENSA_JustJava2006.pdf• INVEST in Good Stories, and SMART Tasks
• http://xp123.com/xplor/xp0308/index.shtml
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 41][Slide 41]
• http://xp123.com/xplor/xp0308/index.shtml
Apoios
• Grupo de Usuários XP do RS• http://xp-rs.blogspot.com• http://tech.groups.yahoo.com/group/xp-rs/
• SUCESU-RS• http://www.rs.sucesu.org.br/• http://www.rs.sucesu.org.br/grupos_usuario/GUMA
• Java.NET• http://weblogs.java.net/blog/dwildt/
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 42][Slide 42]
• http://weblogs.java.net/blog/dwildt/• DevMedia
• http://www.mrbool.com/space.asp?id=192313• http://www.devmedia.com.br/space.asp?id=42615
PerguntasPerguntas
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 43][Slide 43]
Daniel [email protected]
http://www.rs.sucesu.org.br/grupos_usuario/GUMAhttp://tech.groups.yahoo.com/group/xp-rs/
Obrigado!Obrigado!
Copyright © 2008 Daniel WildtCopyright © 2008 Daniel Wildt [Slide 44][Slide 44]