Scrum em 1h.

1,292 views

Published on

Palestra de introdução a SCRUM para a Faculdade Pitágoras

Published in: Education
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,292
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
1
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide



























  • Para cada Backlog Item do Product Backlog
    O Product Owner deve explicar a história por trás do item
    Cada membro da equipe deve mostrar a sua estimativa para o item
    Se as estimativas da equipe forem diferentes, o menor e o maior valor devem ser explicados até que cheguem em um acordo















  • Scrum em 1h.

    1. 1. SCRUM
    2. 2. SOBRE MIM • Márcio Youji Oya • Comecei como programador em 1997, depois me tornei DBA na Telemar, desenvolvedor web, gerente de TI, diretor de TI da Lazo Digital, fundador e ex-sócio da Plan B Comunicação Online e consultor pela Oya Solutions. • Desde 2006 faço parte da Assessoria de Informática da Fundep, desenvolvendo sistemas web e treinando equipes em Agile usando SCRUM. Treinamos e coordenamos mais de 6 equipes, mais de 40 pessoas no projeto de migração de plataforma dos softwares da Fundação nos últimos 2 anos. • Formado em Ciência da Computação pela PUC-MG em 2000. • Certified Scrum Master pela Teamware com Boris Gloger. • Fascinado por pessoas, tecnologia, inovação e empreendedorismo.
    3. 3. ESTA PALESTRA • Visão Geral sobre Gestão Ágil e SCRUM • Minha experiência • Despertar a curiosidade
    4. 4. MOTIVADORES • Gestão De Projetos 1.0 • Software x Engenharia Civil • Pessoas, comportamentos e criatividade • Alto índice de falhas • Honestidade e Transparência
    5. 5. PREMISSAS
    6. 6. PREMISSAS • Lei de Ziv
    7. 7. PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.”
    8. 8. PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.” • Lei de Humphrey
    9. 9. PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.” • Lei de Humphrey • “O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem assim).”
    10. 10. PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.” • Lei de Humphrey • “O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem assim).” • Lei de Wegner / Teorema de Godel
    11. 11. PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.” • Lei de Humphrey • “O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem assim).” • Lei de Wegner / Teorema de Godel • “Um sistema interativo nunca estará completamente especificado e/ou testado.”
    12. 12. PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.” • Lei de Humphrey • “O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem assim).” • Lei de Wegner / Teorema de Godel • “Um sistema interativo nunca estará completamente especificado e/ou testado.” “É típico adotar a abordagem de modelagem teórica quando todos os fatores pelos quais um processo opera estão razoavelmente bem entendidos. Quando o processo é complicado demais para a abordagem teórica, uma abordagem empírica é a melhor escolha.” Process Dynamics, Modeling, and Control, Ogunnaike e Ray, Oxford University Press, 1992
    13. 13. MANIFESTO ÁGIL Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
    14. 14. PRINCÍPIOS 1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. 2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. 3. Entregar freqüentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. 4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. 5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. 6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. 7. Software funcionando é a medida primária de progresso. 8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. 9. Contínua atenção à 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 designs emergem de equipes auto-organizáveis. 12.Em intervalos regulares, a equipe reflete sobe como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
    15. 15. O QUE É O SCRUM? • Modo empírico de gerenciar projetos de desenvolvimento de software • Feito de um conjunto simples de regras e garante que todos os membros da equipe sintam a responsabilidade de um projeto • Inspeção e adaptação com base em feedback • Usado para gerenciar projetos complexos desde 1990 • Entrega de funcionalidades de negócio em 30 dias • Escalabilidade na distribuição de projetos grandes e longos • Compatível com CMM Level 3 e ISO 9001 • Extremamente simples mas de difícil implementação
    16. 16. PRINCÍPIOS • Time responsável e comprometido • Honestidade • Transparência • Partes potencialmente entregáveis • Timebox
    17. 17. HONESTIDADE X CONFORMIDADE
    18. 18. SCRUM ROLES •Product Owner •Scrum Master •Team
    19. 19. PAPÉIS NO SCRUM Atividade Papel Responsabilidade Gerencia a Product O Product Owner estabelece, mantem viva e comunica a visão do produto. Ele demonstra que o visão Owner projeto é alcançável e o financia criando a visão dos releases e do Product Backlog inicial. Product O Product Owner monitora o projeto, mantém de acordo com o ROI estabelecido. Ele atualiza as Gerencia o prioridade do Product Backlog para assegurar-se que as tarefas de maior valor funcional sejam Owner ROI produzidas primeiro. Ele prioriza o Product Backlog and mede o sucesso para assegurar que o projeto está no caminho certo. Gerencia as Team Durante uma iteração o time seleciona e desenvolve os requisitos de maior prioridade do Product iterações de Backlog. Coletivamente, o time expande os itens do Product Backlog para tarefas mais explícitas no Sprint Backlog e gerenciam o trabalho e a sua própria organização para entregar os itens desejados desenvolvimento naquela iteração. O time se gerencia para cumprir o compromissos. Scrum Master O Scrum Master é responsável por ajustar a equipe acima tentando assegurar o sucesso do projeto Gerencia o e otimizar a cultura organizacional para encontrar os objetivos no projeto. Isto envolve organizar a processo Sprint Planning Meeting, a Sprint Review Meeting, protegendo a equipe dos distúrbios externos, realizando as Daily Scrum Meetings, e removendo impedimentos para o progresso do projeto. Product Owner O Product Owner toma decisões sobre quando criar um release oficial. Por uma série de razões não Gerencia os é desejável liberar um realease a cada incremento. O Product Owner toma esta decisões de releases maneira consistente com base na visão de investimento que foi estabelecida para o projeto.
    20. 20. CHICKENS AND PIGS
    21. 21. CENOURAS E CHICOTES
    22. 22. FASES
    23. 23. FLUXO DO SCRUM
    24. 24. O QUE É UM BACKLOG ITEM? Como <user role> eu quero <feature> para que <business value>
    25. 25. PRODUCT BACKLOG • Lista de funcionalidades, tecnologia a ser aplicada, issues • Issues são situações/assuntos do projeto que terão o trabalho definido mais tarde • Itens priorizados e estimados • Maior detalhamento sobre os itens de maior prioridade • O Product Owner é responsável pela priorização • Qualquer um da equipe pode contribuir • Mantido e fixado em local visível • Derivado do plano de negócio e da visão estabelecida, que tem que ser criada em conjunto com o cliente • Estimation Meeting
    26. 26. ESTIMATIVA PLANNING POKER • Chile • Argentina • Venezuela • Brasil • Uruguai • Paraguai • Egito • Itália 1, 2, 3, 5, 8, 13, 21
    27. 27. SPRINT PLANNING 1 • Definir o Sprint Goal e o Selected Product Backlog
    28. 28. SPRINT PLANNING 2 • Define as tarefas para realizar o Sprint Backlog e alinha ao Sprint Goal • Junta a estimativa com a realidade da equipe e do projeto • Design é detalhado nesta sessão • Vamos ao quadro!
    29. 29. KANBAN
    30. 30. MÉTRICAS • Sprint Burndown • Product Burndown • Velocity per Sprint • Business Value Evolution
    31. 31. DAILY MEETING • Objetivo: Sincronizar a equipe - Quais as tarefas foram realizadas ontem? - Quais as tarefas serão desempenhadas hoje? - Quais os impedimentos encontrados durante o seu trabalho? • Mover as tarefas dentro do quadro de acordo com a sua execução • Resultados - Atualização do Impediment Backlog - Atualização do Sprint Backlog - Atualização dos gráficos Burndown • Novas funcionalidades que surgirem serão armazenadas para avaliação ao final do Sprint
    32. 32. DONE! • Quando uma tarefa esta realmente concluída?
    33. 33. IMPEDIMENTS BACKLOG • Recursos • Skills • Prazo Impossível • Infra-estrutura • Ausência de feedback do cliente • Escopo não definido • Problemas Contratuais • Falta de Prioridade • Falte de unidade entre equipes • Burocracia
    34. 34. ABNORMAL TERMINATION • Sprints podem ser cancelados antes do final do Sprint
    35. 35. SPRINT REVIEW •O team deve apresentar os resultados do Sprint e as novas funcionalidades desenvolvidas • Se surgirem novas funcionalidades ou alteração, os novos itens irão para o Backlog para serem estimados e priorizados • O team deve reportar os impedimentos durante o desenvolvimento • Ao final todos envolvidos no projeto devem entender a evolução do projeto e os impedimentos
    36. 36. SPRINT RETROSPECTIVE •O processo é aprimorado ao final de cada Sprint • Facilitado pelo ScrumMaster •O que aconteceu de bom que nós podemos utilizar como melhoria? • ScrumMaster basea a prioridade de acordo com o team •A equipe planeja a solução dos problemas de sua responsabilidade
    37. 37. RETROSPECTIVA “Independente do que nós descubramos, nós compreendemos e acreditamos verdadeiramente que todos fizeram o melhor trabalho que poderiam, deram o que sabiam naquele momento, seus conhecimentos e suas habilidades, os recursos disponíveis, e a situação disponível.”
    38. 38. ESCALABILIDADE COM SCRUM
    39. 39. RESUMO • Roles: Product Owner, Team, ScrumMaster • Artifacts: Product Backlog, Selected Product Backlog, Sprint Backlog, Impediment Backlog • Scrum Meetings: Daily Scrum Meeting, Estimation Meeting, Sprint Planning 1, Sprint Planning 2, Sprint Review Meeting, Retrospective
    40. 40. COMEÇANDO • Ensine os conceitos, teoria e práticas do SCRUM • Apresente a Visão do Projeto, Objetivos e timelines • Ensine o Sprint Planning • Defina o Product Backlog para pelo menos 3 sprints • Faça um brainstorm dos possíveis impedimentos • Faça um brainstorm sobre o próximo Sprint - aceite da equipe • A equipe define o Sprint Backlog • Ensine Daily Meeting, Sprint Review e auto-organização • Discuta sobre ferramentas, práticas e arquiteturas.
    41. 41. INDO ALÉM • XP • Pair Programming • BDD - TDD • Lean • Kanban • etc
    42. 42. DÚVIDAS? • marciooya@gmail.com • Twitter @marciooya • (31) 9722-7170

    ×