Agradecimento. Adaptação do curso Scrum de Márcio Sete, ChallengeIT. Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks

Transcrição

1 S C R U M

2 Apresentação Tiago Domenici Griffo Arquiteto de Software na MCP, MCAD, MCSD, MCTS Web, Windows e TFS, ITIL Foundation Certified, MPS.BR P1 Experiência internacional e de offshoring

3 Agradecimento Adaptação do curso Scrum de Márcio Sete, ChallengeIT Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks

4 Diálogo: como andam nossos projetos? O que colaborou para que seus projetos tenham sido bem sucedidos? O que colaborou para que seus projetos tenham sido mau sucedidos?

5 Chaos Report 2009 (Standish Goup) Sucesso significa dentro do Tempo, custo e com todas as funcionalidades definidas no início do projeto Desafiado significa atrasado, com orçamento estourado e / ou com menos funcionalidades do que foi definido no início do projeto Fracassado significa cancelado antes do final do projeto ou entregue mas nunca utilizado

6 Uso de Funcionalidades 7% 45% 13% 16% Sempre Frequentemente Às vezes Raramente Nunca 19%

7 Caminho do conhecimento SCRUM RELEASE PLANNING MEETING THE SCRUMMASTER THE SPRINT THE PRODUCT OWNER DAILY SCRUM THE TEAM BURNDOWN PRODUCT BACKLOG SPRINT REVIEW SPRINT PLANNING MEETING SPRINT RETROSPECTIVE

8 Scrum

9 O que é SCRUM Processo iterativo e incremental Mais um framework que uma metodologia, mais atitude que um processo. Scrum é muito simples de enteder, mas difícil de adotar e praticar Ingrediente para o gerenciamento de projetos TimeBox. Em SCRUM tempo não é negociado.

10 Origem do Scrum Jeff Sutherland e Ken Schwaber desenvolveram algumas das práticas do Scrum ainda em 1994, inspirados pelo modelo LEAN (sistema TOYOTA de produção). Apresentado oficialmente na OOPLSA 96 (Object- Oriented Programing, Systems, Languages, And Applications)

11 Manifesto Ágil 11 a 13 de fevereiro de 2001 Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: Indivíduos e interações entre eles mais que processos e ferramentas Produto 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.

12 Nós seguimos estes princípios: Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software com valor. Receber mudanças nos requisitos, mesmo tarde no desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente. Entregar freqüentemente software que funciona, desde poucas semanas até poucos meses, com uma preferência pela menor escala de tempo. Pessoal de negócio e desenvolvedores devem trabalhar Juntos diariamente por todo o projeto.

13 Nós seguimos estes princípios: Construa projetos em torno de indivíduos motivados. Dêlhes o ambiente e o apoio necessários e confie neles para realizarem o trabalho. O método mais eficiente e eficaz de transmitir informação para e dentro da equipe de desenvolvimento é a conversa face-a-face. Software que funciona é a medida primordial de progresso. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

14 Nós seguimos estes princípios: Atenção contínua à excelência técnica e bom desenho (design) elevam a agilidade. Simplicidade (a arte de maximizar a quantidade de trabalho não realizado) é essencial. As melhores arquiteturas, requisitos e desenhos (designs) emergem de equipes auto-organizadas. Em intervalos regulares a equipe reflete sobre como se tornar mais eficaz, e então afina e ajusta seu comportamento de acordo.

15 O que não é o SCRUM e SCRUMbut Scrum não é um processo ou técnica para desenvolver produtos É um framework de gerenciamento de projetos e não de engenharia. Daily meetings semanais Eu uso scrum, mas a minha reunião diária é de 2 em 2 dias. Stand-up meetings sentados Scrum não é uma bala de prata

16 Fluxo do Scrum

17 Modelo tradicional: Waterfall

18 Desenvolvimento Iterativo Custo de Mudança requirement gathering analysis & design development testing deployment Customer happy, early release? 80% of a product s value comes from 20% of its features Tempo

19 O Iceberg do Scrum Processos: Reunião de Planejamento, Retrospectiva, Reunião diária, Planejamento de Releases e Sprints,... Ferramentas: Quadro Kanban, Ferramentas, Post-it, Product Backlog, Burndown,... Pessoas: ScrumMaster, Product Owner, Time,... Cultura: Time multtidisciplinar, auto-gerenciamento, valores, Envolvimento do cliente, Entrega frequente, liderança, Colaboração, respeito,...

20 Qual é o seu Scrum? SCRUM Empresa A Empresa B Empresa C

21 Timebox: 5 minutos Dinâmica: Bola Verde

22 Papéis no SCRUM Product Owner Responsável por garantir o ROI Responsável por conhecer as necessidades do cliente ScrumMaster Responsável por remover os impedimentos do time Responsável por garantir o uso do SCRUM Proteger o time de interferências externas Time Multi-disciplinar Auto-gerenciado Produz produto com qualidade e valor para o cliente

23 Pigs & Chickens

24 Dinâmica: Auto-gerenciamento

26 ScrumMaster: Limpando a Visão

27 Responsabilidades do ScrumMaster Remover a barreira entre desenvolvimento e cliente Ensinar o cliente a maximizar o ROI e atingir seus objetivos através do SCRUM Melhorar o dia-a-dia dos membros do time facilitando a criatividade e fortalecimento Combater a ilusão do comando-controle Priorizar os impedimentos e combatê-los Determinar onde o Scrum está, comparado com onde poderia estar Auxiliar o Product Owner com o Product Backlog Garantir o uso do Scrum Facilitar reuniões

28 Um ScrumMaster é um sheepdog

29 Diálogo: ScrumMaster como membro do time Quais seriam alguns dos desafios que um ScrumMaster iria ter caso ele também fosse um membro do time? O que poderia a judar a superar estes desafios?

30 ScrumMaster inútil é ScrumMaster morto

32 Responsabilidades do Product Owner Definir a visão do produto (product vision) Gerenciar o retorno do investimento (ROI) Apresentar ao time os requisitos necessários para a entrega do produto Priorizar cada requisito de acordo com seu valor para o negócio / cliente Gerenciar a entrada de novos requisitos e suas priorizações Planejar entregas (releases) Atuar como facilitador quando mais de um cliente estiver envolvido no projeto Garantir que especialistas de domínio estejam disponíveis para o time

33 Product Owner dentro do Táxi

35 Times Scrum Auto-organizados Multidisciplinares Composto por no máximo 9 integrantes Comprometidos com o trabalho Responsáveis por fazer aquilo que for necessário para atingir a meta da Sprint Comunicativos Organizados em um espaço físico apropriado para o trabalho Responsáveis pela resolução de conflitos

36 Comunicação do Time

37 Critérios de sucesso para times de Scrum Times pequenos Missão clara Liderança apropriada Todos os papeis necessários: ScrumMaster, Analista de Negócios, Tester, Desenvolvedor, Escritor técnico, etc. Bom entendimento das necessidades do cliente Garantia de que os recursos e pessoas necessárias estão disponíveis Auto-gerenciamento fluente Práticas de engenharia e outras disciplinas presentes

38 Diálogo: Times Scrum Quais são os desafios se membros da equipe não se sentem fazendo parte de um time? Como fazer para que todos se sintam membros do time?

39 Um típico time Scrum

40 Fluxo do Scrum

42 Product Backlog Lista inicial de necessidades que precisam ser produzidas para que a visão do produto seja atingida. A lista deve ser ordenada de acordo com o valor que cada necessidade representa para o cliente e o negócio Deve existir apenas 1 backlog e ele deve refletir tudo que precisa ser feito. Vai existir durante todo o ciclo de vida do projeto (não da sprint) É regularmente atualizado pelo PO para refletir as mudanças e necessidades do cliente, mudanças estratégicas ou tecnológicas, idéias novas, enfim... mudanças. Composto de vários ítens: funcionalidades, requisitos de desenvolvimento, exploração técnica, estudo, documentação, bugs, etc.

43 Porque não especificações? Alto consumo de tempo para escrever e ler; um tédio para escrever Trata o aprendizado do cliente como mudança de escopo (change request) Difíceis de se adequar ao desenvolvimento iterativo e incremental... Representar os requisitos do cliente mais que documentá-los Rachel Davis, Chair of Agile Alliance

44 Priorização do Backlog Esta priorização deve acontecer antes do início da Sprint Planning Meeting, mas pode ser refinada no seu decorrer. Boas técnicas de priorização: Kano Theme Screening Priorization Poker

45 A engenharia do Product Backlog 45% 7% 13% 16% 19% Se a priorização do backlog está na mão do cliente as funcionalidades que realmente importam (20% do gráfico acima) residem no topo do Product Backlog.

46 O nível certo de priorização

48 Planejamento por velocidade Ajuste de Prioridades Identificar a meta da Sprint Selecionar ítens do backlog Quebrar ítens em tarefas Determinar velocidade Estima (ou revisa estimativa) de ítens Estimar tarefas

49 Velocidade do time

50 Estimando o Product Backlog

51 Atividade: estimando tamanho de livros

52 Planejamento por compromisso Se compromete; ainda pode fazer mais Se compromete; mas não consegue incluir mais nada Ajuste de prioridades Selecionar um Ítem do Backlog Pergunta se time se compromete Finaliza Sprint Planning Identificar a meta da Sprint Quebra ítens em tarefas Estimar tarefas Não se compromete Remove o Ítem

53 Resultado de um planejamento de Sprint Itens Tarefas Meta

55 As duas perguntas mágicas Quanto vai custar? Quando estará pronto?

56 Planejamento de Releases Continua planejando Releases até que a visão do produto seja alcançada Selecionar um tamanho de Sprint Determinar as condições de satisfação Estimar os Itens do Backlog Estimar Velocidade Selecionar Itens e data do Release Priorizar User Stories

57 Dinâmica: Construir 3 convites

58 Do tamanho para a duração Tamanho Cálculo Duração 300 páginas 30 páginas por semana 10 semanas

60 Entregas Sushi X Entrega Sashimi

61 Diálogo: definindo pronto O que significa pronto em seu projeto atual? Você concorda com essa definição? Por que? Quais problemas de engenharia você percebe com essa definição de pronto? Como você pode corrigir isso?

62 Incremento do produto Potencialmente entregável!= entregável S1 S2 S3 S4 S1, S2, S3 e S4 são produtos potencialmente entregáveis R1 É UM ENTREGÁVEL! c

63 Ítens técnicos, arquitetura... Sempre entregar valor! Ítens com ROI visível S1 S2 S3 S4 S5 S6

64 Tamanho de Sprints Mudança constante no topo do product backlog: ideal trabalhar com sprints curtos Sindrome do estudante presente: ideal trabalhar com sprints curtos Dificuldade de entregar valor para o cliente ao fim das Sprints: ideal trabalhar com sprints curtos Time e / ou cliente exaustos com loops tão curtos: ideal trabalhar com Sprints longos

65 Sem mudanças durante a Sprint

66 Terminando a Sprint antes da sua finalização

68 SCRUM Daily Meeting

69 Diálogo: Daily Meeting Você acredita que uma reunião diária de 15 minutos pode atrapalhar seu time? Por que? Quais os ganhos que seu time pode obter realizando uma reunião diária? Que ações você, como ScrumMaster, poderia tomar para fazer com que seu time tivesse reuniões diárias de qualidade?

71 Scrum Board (Kanban)

72 Sprint Burn down

74 Review Meeting

76 O que foi bom? O que deve melhorar? O que foi bom? O que deve melhorar?

77 Product Backlog Contruir título e slogan do programa de divulgação do SCRUM Informar o que é SCRUM? Mostrar Fluxo do Scrum Mostrar porque o Scrum é importante para a empresa Informações sobre os papéis do Scrum Mostrar logo de empresas que já usaram Fornecer informações sobre o treinamento de Certified ScrumMaster Mostrar depoimentos de departamentos/projetos da empresa que utilizam Scrum Mostrar como conseguir mais informações

78 Referências Agille Alliance - Scrum Alliance - Ken Schwaber - AdaptWorks Manifesto Ágil - Team System -

79 Bate papo e Networking tiago.griffo@gmail.com Follow