Slide 1

Slide 1 text

Scrum Desenvolvimento e gerência de projetos Danilo Cabello Unicamp 08 Setembro 2010 Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 1 / 17

Slide 2

Slide 2 text

Santo Graal Santo Graal ou Santo Gral é uma expressão medieval que designa normalmente o cálice usado por Jesus Cristo na Última Ceia. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 2 / 17

Slide 3

Slide 3 text

Santo Graal Santo Graal ou Santo Gral é uma expressão medieval que designa normalmente o cálice usado por Jesus Cristo na Última Ceia. Ele está presente nas Lendas Arturianas, sendo o objetivo da busca dos Cavaleiros da Távola Redonda, único objeto com capacidade de devolver a paz ao reino de Artur. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 2 / 17

Slide 4

Slide 4 text

Santo Graal Santo Graal ou Santo Gral é uma expressão medieval que designa normalmente o cálice usado por Jesus Cristo na Última Ceia. Ele está presente nas Lendas Arturianas, sendo o objetivo da busca dos Cavaleiros da Távola Redonda, único objeto com capacidade de devolver a paz ao reino de Artur. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 2 / 17

Slide 5

Slide 5 text

Geralmente se atribui a procura deste cálice à tentativa de conquistar à perfeição. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 3 / 17

Slide 6

Slide 6 text

Geralmente se atribui a procura deste cálice à tentativa de conquistar à perfeição. Tudo isso pra dizer que: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 3 / 17

Slide 7

Slide 7 text

Geralmente se atribui a procura deste cálice à tentativa de conquistar à perfeição. Tudo isso pra dizer que: Scrum não é o Santo Graal do desenvolvimento de software. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 3 / 17

Slide 8

Slide 8 text

Geralmente se atribui a procura deste cálice à tentativa de conquistar à perfeição. Tudo isso pra dizer que: Scrum não é o Santo Graal do desenvolvimento de software. Atualmente nenhuma metodologia ou processo é o cálice sagrado. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 3 / 17

Slide 9

Slide 9 text

Geralmente se atribui a procura deste cálice à tentativa de conquistar à perfeição. Tudo isso pra dizer que: Scrum não é o Santo Graal do desenvolvimento de software. Atualmente nenhuma metodologia ou processo é o cálice sagrado. Mas algumas pessoas podem tentar te ludibriar como se fosse. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 3 / 17

Slide 10

Slide 10 text

Geralmente se atribui a procura deste cálice à tentativa de conquistar à perfeição. Tudo isso pra dizer que: Scrum não é o Santo Graal do desenvolvimento de software. Atualmente nenhuma metodologia ou processo é o cálice sagrado. Mas algumas pessoas podem tentar te ludibriar como se fosse. Fique esperto com as promessas milagrosas. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 3 / 17

Slide 11

Slide 11 text

Geralmente se atribui a procura deste cálice à tentativa de conquistar à perfeição. Tudo isso pra dizer que: Scrum não é o Santo Graal do desenvolvimento de software. Atualmente nenhuma metodologia ou processo é o cálice sagrado. Mas algumas pessoas podem tentar te ludibriar como se fosse. Fique esperto com as promessas milagrosas. Faça adaptações nos processos sempre que julgar necessário. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 3 / 17

Slide 12

Slide 12 text

A origem da engenharia de software tradicional Atenção: os próximos slides possuem muita opinião pessoal. :D Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 4 / 17

Slide 13

Slide 13 text

A origem da engenharia de software tradicional Atenção: os próximos slides possuem muita opinião pessoal. :D Houve uma época que: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 4 / 17

Slide 14

Slide 14 text

A origem da engenharia de software tradicional Atenção: os próximos slides possuem muita opinião pessoal. :D Houve uma época que: Não existia computador. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 4 / 17

Slide 15

Slide 15 text

A origem da engenharia de software tradicional Atenção: os próximos slides possuem muita opinião pessoal. :D Houve uma época que: Não existia computador. Mas já existiam as indústrias e seu maquinário. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 4 / 17

Slide 16

Slide 16 text

A origem da engenharia de software tradicional Atenção: os próximos slides possuem muita opinião pessoal. :D Houve uma época que: Não existia computador. Mas já existiam as indústrias e seu maquinário. Os processos de desenvolvimento de uma máquina eram meticulosos. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 4 / 17

Slide 17

Slide 17 text

A origem da engenharia de software tradicional Atenção: os próximos slides possuem muita opinião pessoal. :D Houve uma época que: Não existia computador. Mas já existiam as indústrias e seu maquinário. Os processos de desenvolvimento de uma máquina eram meticulosos. O produto era um punhado de metal e engrenagens. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 4 / 17

Slide 18

Slide 18 text

A origem da engenharia de software tradicional Atenção: os próximos slides possuem muita opinião pessoal. :D Houve uma época que: Não existia computador. Mas já existiam as indústrias e seu maquinário. Os processos de desenvolvimento de uma máquina eram meticulosos. O produto era um punhado de metal e engrenagens. Se o cliente quisesse alterações teria que fazer uma máquina nova. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 4 / 17

Slide 19

Slide 19 text

A origem da engenharia de software tradicional Atenção: os próximos slides possuem muita opinião pessoal. :D Houve uma época que: Não existia computador. Mas já existiam as indústrias e seu maquinário. Os processos de desenvolvimento de uma máquina eram meticulosos. O produto era um punhado de metal e engrenagens. Se o cliente quisesse alterações teria que fazer uma máquina nova. O cliente mantinha sua máquina até depreciar ou ter dinheiro pra uma nova. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 4 / 17

Slide 20

Slide 20 text

A origem da engenharia de software tradicional Atenção: os próximos slides possuem muita opinião pessoal. :D Houve uma época que: Não existia computador. Mas já existiam as indústrias e seu maquinário. Os processos de desenvolvimento de uma máquina eram meticulosos. O produto era um punhado de metal e engrenagens. Se o cliente quisesse alterações teria que fazer uma máquina nova. O cliente mantinha sua máquina até depreciar ou ter dinheiro pra uma nova. Eis que surgiu o computador, os programas de computador, e... Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 4 / 17

Slide 21

Slide 21 text

Tentaram seguir com o mesmo método de produção de maquinário para o processo de produção de software, mas: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 5 / 17

Slide 22

Slide 22 text

Tentaram seguir com o mesmo método de produção de maquinário para o processo de produção de software, mas: O cliente não tinha ideia do que ele precisava, e/ou do que um software era capaz. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 5 / 17

Slide 23

Slide 23 text

Tentaram seguir com o mesmo método de produção de maquinário para o processo de produção de software, mas: O cliente não tinha ideia do que ele precisava, e/ou do que um software era capaz. Todos os mínimos detalhes eram definidos antes da produção do programa, alegando que quanto mais tarde no processo fosse encontrada a necessidade de alteração, mais caro seria. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 5 / 17

Slide 24

Slide 24 text

Tentaram seguir com o mesmo método de produção de maquinário para o processo de produção de software, mas: O cliente não tinha ideia do que ele precisava, e/ou do que um software era capaz. Todos os mínimos detalhes eram definidos antes da produção do programa, alegando que quanto mais tarde no processo fosse encontrada a necessidade de alteração, mais caro seria. O cliente perguntava: “Dá pra fazer isso?” e o desenvolvedor respondia: “Sim.” ou “Não.” Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 5 / 17

Slide 25

Slide 25 text

Tentaram seguir com o mesmo método de produção de maquinário para o processo de produção de software, mas: O cliente não tinha ideia do que ele precisava, e/ou do que um software era capaz. Todos os mínimos detalhes eram definidos antes da produção do programa, alegando que quanto mais tarde no processo fosse encontrada a necessidade de alteração, mais caro seria. O cliente perguntava: “Dá pra fazer isso?” e o desenvolvedor respondia: “Sim.” ou “Não.” O cliente continuava sem saber como esse tal de software era feito por dentro (bytes?). Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 5 / 17

Slide 26

Slide 26 text

Tentaram seguir com o mesmo método de produção de maquinário para o processo de produção de software, mas: O cliente não tinha ideia do que ele precisava, e/ou do que um software era capaz. Todos os mínimos detalhes eram definidos antes da produção do programa, alegando que quanto mais tarde no processo fosse encontrada a necessidade de alteração, mais caro seria. O cliente perguntava: “Dá pra fazer isso?” e o desenvolvedor respondia: “Sim.” ou “Não.” O cliente continuava sem saber como esse tal de software era feito por dentro (bytes?). E recebia um produto que ele não conseguia tocar, que cabia em um disquete, CD, pen drive, ou até no e-mail. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 5 / 17

Slide 27

Slide 27 text

Tentaram seguir com o mesmo método de produção de maquinário para o processo de produção de software, mas: O cliente não tinha ideia do que ele precisava, e/ou do que um software era capaz. Todos os mínimos detalhes eram definidos antes da produção do programa, alegando que quanto mais tarde no processo fosse encontrada a necessidade de alteração, mais caro seria. O cliente perguntava: “Dá pra fazer isso?” e o desenvolvedor respondia: “Sim.” ou “Não.” O cliente continuava sem saber como esse tal de software era feito por dentro (bytes?). E recebia um produto que ele não conseguia tocar, que cabia em um disquete, CD, pen drive, ou até no e-mail. Por não poder tocar em seu produto o cliente não sabia mensurar o custo de adaptações. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 5 / 17

Slide 28

Slide 28 text

Tentaram seguir com o mesmo método de produção de maquinário para o processo de produção de software, mas: O cliente não tinha ideia do que ele precisava, e/ou do que um software era capaz. Todos os mínimos detalhes eram definidos antes da produção do programa, alegando que quanto mais tarde no processo fosse encontrada a necessidade de alteração, mais caro seria. O cliente perguntava: “Dá pra fazer isso?” e o desenvolvedor respondia: “Sim.” ou “Não.” O cliente continuava sem saber como esse tal de software era feito por dentro (bytes?). E recebia um produto que ele não conseguia tocar, que cabia em um disquete, CD, pen drive, ou até no e-mail. Por não poder tocar em seu produto o cliente não sabia mensurar o custo de adaptações. Utilizavam (alguns ainda utilizam) um método de produção de maquinário industrial pra produção de software. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 5 / 17

Slide 29

Slide 29 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 30

Slide 30 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 31

Slide 31 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Alguns princípios que são compartilhados entre as metodologias ágeis: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 32

Slide 32 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Alguns princípios que são compartilhados entre as metodologias ágeis: Cooperação constante entre pessoas que entendem do “negócio” e desenvolvedores. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 33

Slide 33 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Alguns princípios que são compartilhados entre as metodologias ágeis: Cooperação constante entre pessoas que entendem do “negócio” e desenvolvedores. Colaboração com clientes mais do que negociação de contratos. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 34

Slide 34 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Alguns princípios que são compartilhados entre as metodologias ágeis: Cooperação constante entre pessoas que entendem do “negócio” e desenvolvedores. Colaboração com clientes mais do que negociação de contratos. Softwares funcionais são entregues frequentemente (semanas, ao invés de meses). Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 35

Slide 35 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Alguns princípios que são compartilhados entre as metodologias ágeis: Cooperação constante entre pessoas que entendem do “negócio” e desenvolvedores. Colaboração com clientes mais do que negociação de contratos. Softwares funcionais são entregues frequentemente (semanas, ao invés de meses). Softwares funcionais são a principal medida de progresso do projeto. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 36

Slide 36 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Alguns princípios que são compartilhados entre as metodologias ágeis: Cooperação constante entre pessoas que entendem do “negócio” e desenvolvedores. Colaboração com clientes mais do que negociação de contratos. Softwares funcionais são entregues frequentemente (semanas, ao invés de meses). Softwares funcionais são a principal medida de progresso do projeto. Mudanças tardias de escopos são bem recebidas. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 37

Slide 37 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Alguns princípios que são compartilhados entre as metodologias ágeis: Cooperação constante entre pessoas que entendem do “negócio” e desenvolvedores. Colaboração com clientes mais do que negociação de contratos. Softwares funcionais são entregues frequentemente (semanas, ao invés de meses). Softwares funcionais são a principal medida de progresso do projeto. Mudanças tardias de escopos são bem recebidas. Rápida adaptação às mudanças. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 38

Slide 38 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Alguns princípios que são compartilhados entre as metodologias ágeis: Cooperação constante entre pessoas que entendem do “negócio” e desenvolvedores. Colaboração com clientes mais do que negociação de contratos. Softwares funcionais são entregues frequentemente (semanas, ao invés de meses). Softwares funcionais são a principal medida de progresso do projeto. Mudanças tardias de escopos são bem recebidas. Rápida adaptação às mudanças. Responder a mudanças mais do que seguir um plano. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 39

Slide 39 text

Metodologias ágeis Em um mundo globalizado que exige respostas cada vez mais rápidas, a afirmação de que fabricar software era um processo tão travado como o da produção de máquinas foi desmentida rapidamente. E as metodologias ágeis surgiram para tentar “consertar” essa mentira. Alguns princípios que são compartilhados entre as metodologias ágeis: Cooperação constante entre pessoas que entendem do “negócio” e desenvolvedores. Colaboração com clientes mais do que negociação de contratos. Softwares funcionais são entregues frequentemente (semanas, ao invés de meses). Softwares funcionais são a principal medida de progresso do projeto. Mudanças tardias de escopos são bem recebidas. Rápida adaptação às mudanças. Responder a mudanças mais do que seguir um plano. Desenvolvimento iterativo e incremental. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 6 / 17

Slide 40

Slide 40 text

Scrum: papéis Product Owner: a voz do cliente, dono do produto, sabe as funcionalidades necessárias e o que é prioridade. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 7 / 17

Slide 41

Slide 41 text

Scrum: papéis Product Owner: a voz do cliente, dono do produto, sabe as funcionalidades necessárias e o que é prioridade. ScrumMaster: é o facilitador, sua função é remover impedimentos e garantir que o Scrum seja realizado. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 7 / 17

Slide 42

Slide 42 text

Scrum: papéis Product Owner: a voz do cliente, dono do produto, sabe as funcionalidades necessárias e o que é prioridade. ScrumMaster: é o facilitador, sua função é remover impedimentos e garantir que o Scrum seja realizado. Equipe: toda a equipe de desenvolvimento, normalmente entre 5 e 10 pessoas com habilidades variadas (designer, programador). Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 7 / 17

Slide 43

Slide 43 text

Scrum: artefatos Product Backlog: uma lista priorizada em alto nível de requisitos do produto. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 8 / 17

Slide 44

Slide 44 text

Scrum: artefatos Product Backlog: uma lista priorizada em alto nível de requisitos do produto. Sprint Backlog: a lista de tarefas que serão entregues nesse sprint. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 8 / 17

Slide 45

Slide 45 text

Scrum: artefatos Product Backlog: uma lista priorizada em alto nível de requisitos do produto. Sprint Backlog: a lista de tarefas que serão entregues nesse sprint. Sprint Burn Down Chart: gráfico indicador de progresso do sprint. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 8 / 17

Slide 46

Slide 46 text

Scrum: artefatos Product Backlog: uma lista priorizada em alto nível de requisitos do produto. Sprint Backlog: a lista de tarefas que serão entregues nesse sprint. Sprint Burn Down Chart: gráfico indicador de progresso do sprint. Sprint: período de 2 a 4 semanas em que a equipe se compromete a entregar uma lista de tarefas. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 8 / 17

Slide 47

Slide 47 text

Scrum: reunião diária A reunião diária tem por objetivo alinhar toda equipe, princípios: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 9 / 17

Slide 48

Slide 48 text

Scrum: reunião diária A reunião diária tem por objetivo alinhar toda equipe, princípios: Reunião pontual. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 9 / 17

Slide 49

Slide 49 text

Scrum: reunião diária A reunião diária tem por objetivo alinhar toda equipe, princípios: Reunião pontual. Toda equipe presente. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 9 / 17

Slide 50

Slide 50 text

Scrum: reunião diária A reunião diária tem por objetivo alinhar toda equipe, princípios: Reunião pontual. Toda equipe presente. 15 minutos independente do tamanho da equipe. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 9 / 17

Slide 51

Slide 51 text

Scrum: reunião diária A reunião diária tem por objetivo alinhar toda equipe, princípios: Reunião pontual. Toda equipe presente. 15 minutos independente do tamanho da equipe. Deve acontecer no mesmo local e horário todo dia. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 9 / 17

Slide 52

Slide 52 text

Scrum: reunião diária A reunião diária tem por objetivo alinhar toda equipe, princípios: Reunião pontual. Toda equipe presente. 15 minutos independente do tamanho da equipe. Deve acontecer no mesmo local e horário todo dia. Cada membro da equipe deve responder: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 9 / 17

Slide 53

Slide 53 text

Scrum: reunião diária A reunião diária tem por objetivo alinhar toda equipe, princípios: Reunião pontual. Toda equipe presente. 15 minutos independente do tamanho da equipe. Deve acontecer no mesmo local e horário todo dia. Cada membro da equipe deve responder: O que você fez desde a última reunião? Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 9 / 17

Slide 54

Slide 54 text

Scrum: reunião diária A reunião diária tem por objetivo alinhar toda equipe, princípios: Reunião pontual. Toda equipe presente. 15 minutos independente do tamanho da equipe. Deve acontecer no mesmo local e horário todo dia. Cada membro da equipe deve responder: O que você fez desde a última reunião? O que você fará hoje? Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 9 / 17

Slide 55

Slide 55 text

Scrum: reunião diária A reunião diária tem por objetivo alinhar toda equipe, princípios: Reunião pontual. Toda equipe presente. 15 minutos independente do tamanho da equipe. Deve acontecer no mesmo local e horário todo dia. Cada membro da equipe deve responder: O que você fez desde a última reunião? O que você fará hoje? Tem algo te impedindo de realizar o que planeja? Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 9 / 17

Slide 56

Slide 56 text

Scrum: cerimônias ou reuniões Sprint Planning: tem por objetivo definir o que deve ser feito no sprint, atualiza-se o Product Backlog, detalha-se melhor as tarefas mais prioritárias e o time assume a responsabilidade de realizar as tarefas que conseguem, baseados na medida de desempenho dos sprint anteriores. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 10 / 17

Slide 57

Slide 57 text

Scrum: cerimônias ou reuniões Sprint Planning: tem por objetivo definir o que deve ser feito no sprint, atualiza-se o Product Backlog, detalha-se melhor as tarefas mais prioritárias e o time assume a responsabilidade de realizar as tarefas que conseguem, baseados na medida de desempenho dos sprint anteriores. Sprint Review: tem por objetivo confirmar o que foi concluído e o que não foi, o software funcional é exibido ao cliente, trabalho incompleto não pode ser exibido. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 10 / 17

Slide 58

Slide 58 text

Scrum: cerimônias ou reuniões Sprint Planning: tem por objetivo definir o que deve ser feito no sprint, atualiza-se o Product Backlog, detalha-se melhor as tarefas mais prioritárias e o time assume a responsabilidade de realizar as tarefas que conseguem, baseados na medida de desempenho dos sprint anteriores. Sprint Review: tem por objetivo confirmar o que foi concluído e o que não foi, o software funcional é exibido ao cliente, trabalho incompleto não pode ser exibido. Sprint Retrospective: tem por objetivo melhorar o processo de Scrum respondendo duas perguntas principais: O que foi bom durante o sprint? O que poderia melhorar pro próximo sprint? Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 10 / 17

Slide 59

Slide 59 text

Scrum: fluxo Fluxo simplificado do Scrum: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 11 / 17

Slide 60

Slide 60 text

Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17

Slide 61

Slide 61 text

Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: ScrumMaster faz parte da equipe de desenvolvimento: como a empresa é muito pequena fizemos essa adaptação que deve ser evitada em situações melhores. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17

Slide 62

Slide 62 text

Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: ScrumMaster faz parte da equipe de desenvolvimento: como a empresa é muito pequena fizemos essa adaptação que deve ser evitada em situações melhores. Product Owner é um dos sócios, não é desenvolvedor, e o pedido de funcionalidades de outras pessoas passam por ele. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17

Slide 63

Slide 63 text

Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: ScrumMaster faz parte da equipe de desenvolvimento: como a empresa é muito pequena fizemos essa adaptação que deve ser evitada em situações melhores. Product Owner é um dos sócios, não é desenvolvedor, e o pedido de funcionalidades de outras pessoas passam por ele. Ferramenta de Feedbacks na rede gera tarefas pro Product Backlog. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17

Slide 64

Slide 64 text

Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: ScrumMaster faz parte da equipe de desenvolvimento: como a empresa é muito pequena fizemos essa adaptação que deve ser evitada em situações melhores. Product Owner é um dos sócios, não é desenvolvedor, e o pedido de funcionalidades de outras pessoas passam por ele. Ferramenta de Feedbacks na rede gera tarefas pro Product Backlog. A reunião diária é meio bagunçada e pode ser realizada via Skype, pois nem todos funcionários trabalham full-time. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17

Slide 65

Slide 65 text

Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: ScrumMaster faz parte da equipe de desenvolvimento: como a empresa é muito pequena fizemos essa adaptação que deve ser evitada em situações melhores. Product Owner é um dos sócios, não é desenvolvedor, e o pedido de funcionalidades de outras pessoas passam por ele. Ferramenta de Feedbacks na rede gera tarefas pro Product Backlog. A reunião diária é meio bagunçada e pode ser realizada via Skype, pois nem todos funcionários trabalham full-time. Uso de pontuação para estimar as tarefas através do Pivotal Tracker. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17

Slide 66

Slide 66 text

Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: ScrumMaster faz parte da equipe de desenvolvimento: como a empresa é muito pequena fizemos essa adaptação que deve ser evitada em situações melhores. Product Owner é um dos sócios, não é desenvolvedor, e o pedido de funcionalidades de outras pessoas passam por ele. Ferramenta de Feedbacks na rede gera tarefas pro Product Backlog. A reunião diária é meio bagunçada e pode ser realizada via Skype, pois nem todos funcionários trabalham full-time. Uso de pontuação para estimar as tarefas através do Pivotal Tracker. Sprint Retrospective é utilizada como reunião geral da empresa, atualmente somos 6 pessoas. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17

Slide 67

Slide 67 text

Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: ScrumMaster faz parte da equipe de desenvolvimento: como a empresa é muito pequena fizemos essa adaptação que deve ser evitada em situações melhores. Product Owner é um dos sócios, não é desenvolvedor, e o pedido de funcionalidades de outras pessoas passam por ele. Ferramenta de Feedbacks na rede gera tarefas pro Product Backlog. A reunião diária é meio bagunçada e pode ser realizada via Skype, pois nem todos funcionários trabalham full-time. Uso de pontuação para estimar as tarefas através do Pivotal Tracker. Sprint Retrospective é utilizada como reunião geral da empresa, atualmente somos 6 pessoas. O Pivotal Tracker permite o trabalho separado, cada um na sua casa, por exemplo. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17

Slide 68

Slide 68 text

Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: ScrumMaster faz parte da equipe de desenvolvimento: como a empresa é muito pequena fizemos essa adaptação que deve ser evitada em situações melhores. Product Owner é um dos sócios, não é desenvolvedor, e o pedido de funcionalidades de outras pessoas passam por ele. Ferramenta de Feedbacks na rede gera tarefas pro Product Backlog. A reunião diária é meio bagunçada e pode ser realizada via Skype, pois nem todos funcionários trabalham full-time. Uso de pontuação para estimar as tarefas através do Pivotal Tracker. Sprint Retrospective é utilizada como reunião geral da empresa, atualmente somos 6 pessoas. O Pivotal Tracker permite o trabalho separado, cada um na sua casa, por exemplo. O P.O. participa ativamente da retrospectiva do sprint. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17

Slide 69

Slide 69 text

Fotos: retrospectiva Retrospectiva, lado esquerdo coisas ruins que podiam melhorar no próximo sprint, lado direito coisas boas que merecem ser levantadas e continuadas. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 13 / 17

Slide 70

Slide 70 text

Fotos: decisões Decisões de melhorias fruto da retrospectiva, cada participante tem direito a 3 votos no mesmo item ou não, de acordo com a votação, discutimos o que fazer pra solucionar o problema para o próximo sprint. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 14 / 17

Slide 71

Slide 71 text

Demonstração do Pivotal Tracker Demonstração do uso do Pivotal Tracker em nosso projeto. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 15 / 17

Slide 72

Slide 72 text

Dúvidas ??? Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 16 / 17

Slide 73

Slide 73 text

Referências http://pt.wikipedia.org/wiki/Santo_graal http://www.infoescola.com/cristianismo/santo−graal/ http://pt.wikipedia.org/wiki/Desenvolvimento_ágil_de_software http://pt.wikipedia.org/wiki/Scrum http://en.wikipedia.org/wiki/Scrum_(development) http://epf.eclipse.org/wikis/scrumpt/Scrum/customcategories/ scrum_overview_A34DDE47.html http://www.pivotaltracker.com/ Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 17 / 17