Scrum

Scrum para desenvolvimento e gerência de projetos

Transcript

1. Scrum Desenvolvimento e gerência de projetos Danilo Cabello Unicamp 08 Setembro 2010 Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 1 / 17
2. 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
3. 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
4. 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
5. Geralmente se atribui a procura deste cálice à tentativa de conquistar à perfeição. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 3 / 17
6. 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
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. 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
29. 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
30. 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
31. 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
32. 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
33. 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
34. 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
35. 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
36. 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
37. 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
38. 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
39. 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
40. 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
41. 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
42. 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
43. Scrum: artefatos Product Backlog: uma lista priorizada em alto nível de requisitos do produto. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 8 / 17
44. 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
45. 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
46. 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
47. 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
48. 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
49. 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
50. 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
51. 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
52. 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
53. 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
54. 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
55. 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
56. 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
57. 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
58. 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
59. Scrum: fluxo Fluxo simplificado do Scrum: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 11 / 17
60. Adaptações Empreendemia Como cada caso é um caso realizamos as seguintes adaptações: Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 12 / 17
61. 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
62. 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
63. 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
64. 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
65. 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
66. 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
67. 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
68. 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
69. 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
70. 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
71. Demonstração do Pivotal Tracker Demonstração do uso do Pivotal Tracker em nosso projeto. Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 15 / 17
72. Dúvidas ??? Danilo Cabello (Unicamp) Scrum 08 Setembro 2010 16 / 17
73. 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