• Save
Scrum em 1h.
Upcoming SlideShare
Loading in...5
×
 

Scrum em 1h.

on

  • 1,538 views

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

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

Statistics

Views

Total Views
1,538
Views on SlideShare
1,522
Embed Views
16

Actions

Likes
5
Downloads
0
Comments
0

2 Embeds 16

http://www.slideshare.net 14
http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • Para cada Backlog Item do Product Backlog <br /> O Product Owner deve explicar a hist&#xF3;ria por tr&#xE1;s do item <br /> Cada membro da equipe deve mostrar a sua estimativa para o item <br /> Se as estimativas da equipe forem diferentes, o menor e o maior valor devem ser explicados at&#xE9; que cheguem em um acordo <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

Scrum em 1h. Scrum em 1h. Presentation Transcript

  • SCRUM
  • 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.
  • ESTA PALESTRA • Visão Geral sobre Gestão Ágil e SCRUM • Minha experiência • Despertar a curiosidade
  • MOTIVADORES • Gestão De Projetos 1.0 • Software x Engenharia Civil • Pessoas, comportamentos e criatividade • Alto índice de falhas • Honestidade e Transparência
  • PREMISSAS
  • PREMISSAS • Lei de Ziv
  • PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.”
  • PREMISSAS • Lei de Ziv • “Especificações nunca serão completamente compreendidas.” • Lei de Humphrey
  • 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).”
  • 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
  • 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.”
  • 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
  • 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.
  • 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.
  • 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
  • PRINCÍPIOS • Time responsável e comprometido • Honestidade • Transparência • Partes potencialmente entregáveis • Timebox
  • HONESTIDADE X CONFORMIDADE
  • SCRUM ROLES •Product Owner •Scrum Master •Team
  • 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.
  • CHICKENS AND PIGS
  • CENOURAS E CHICOTES
  • FASES
  • FLUXO DO SCRUM
  • O QUE É UM BACKLOG ITEM? Como <user role> eu quero <feature> para que <business value>
  • 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
  • ESTIMATIVA PLANNING POKER • Chile • Argentina • Venezuela • Brasil • Uruguai • Paraguai • Egito • Itália 1, 2, 3, 5, 8, 13, 21
  • SPRINT PLANNING 1 • Definir o Sprint Goal e o Selected Product Backlog
  • 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!
  • KANBAN
  • MÉTRICAS • Sprint Burndown • Product Burndown • Velocity per Sprint • Business Value Evolution
  • 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
  • DONE! • Quando uma tarefa esta realmente concluída?
  • 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
  • ABNORMAL TERMINATION • Sprints podem ser cancelados antes do final do Sprint
  • 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
  • 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
  • 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.”
  • ESCALABILIDADE COM SCRUM
  • 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
  • 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.
  • INDO ALÉM • XP • Pair Programming • BDD - TDD • Lean • Kanban • etc
  • DÚVIDAS? • marciooya@gmail.com • Twitter @marciooya • (31) 9722-7170