Transferir como KEY, PPTX
Carregado porMárcio Oya
Scrum em 1h.
O documento fornece uma visão geral de Scrum, incluindo: 1) Scrum é um framework ágil para gerenciamento de projetos de software que enfatiza inspeção e adaptação contínuas com base em feedback; 2) Os papéis no Scrum incluem o Product Owner, Scrum Master e Equipe; 3) O Product Backlog, Sprints e Daily Meetings são elementos centrais do fluxo de trabalho do Scrum.
Mais conteúdo relacionado
Scrum em 1h.
- 1.
- 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. ESTA PALESTRA • Visão Geral sobre Gestão Ágil e SCRUM • Minha experiência • Despertar a curiosidade
- 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.
- 6. PREMISSAS • Lei de Ziv
- 7. PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.”
- 8. PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.” • Lei de Humphrey
- 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. 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. 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. 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
- 14. MANIFESTO ÁGIL Estamos descobrindomaneiras 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.
- 15. PRINCÍPIOS 1. Nossa maiorprioridade é 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.
- 16. 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
- 18. PRINCÍPIOS • Time responsável e comprometido • Honestidade • Transparência • Partes potencialmente entregáveis • Timebox
- 19.
- 20. SCRUM ROLES •Product Owner •Scrum Master •Team
- 21. 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.
- 22.
- 23.
- 24.
- 25.
- 26. O QUE ÉUM BACKLOG ITEM? Como <user role> eu quero <feature> para que <business value>
- 27. 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
- 28. ESTIMATIVA PLANNING POKER • Chile • Argentina • Venezuela • Brasil • Uruguai • Paraguai • Egito • Itália 1, 2, 3, 5, 8, 13, 21
- 29. SPRINT PLANNING 1 •Definir o Sprint Goal e o Selected Product Backlog
- 30. 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!
- 31.
- 32. MÉTRICAS • Sprint Burndown • Product Burndown • Velocity per Sprint • Business Value Evolution
- 33. 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
- 34. DONE! • Quando uma tarefa esta realmente concluída?
- 35. 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
- 36. ABNORMAL TERMINATION • Sprints podem ser cancelados antes do final do Sprint
- 37. 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
- 38. 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
- 39. RETROSPECTIVA “Independente do quenó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.”
- 40. ESCALABILIDADE COM SCRUM
- 41. 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
- 42. COMEÇANDO • Ensine osconceitos, 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.
- 43. INDO ALÉM • XP •Pair Programming • BDD - TDD • Lean • Kanban • etc
- 44. DÚVIDAS? • marciooya@gmail.com • Twitter @marciooya • (31) 9722-7170
Notas do Editor
- #29 Para cada Backlog Item do Product Backlog O Product Owner deve explicar a hist&#xF3;ria por tr&#xE1;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&#xE9; que cheguem em um acordo