O mundo ágil do SCRUM Alexsandro Marques 02/09/2009

Alexsandro Marques Coordenador de Projetos da Provider Sistemas Scrum Master Graduando em Ciência da Computação Certified Scrum Product Owner Coordenador do User Group Scrum Recife

Metas Apresentar alguns conceitos chave do Scrum Entender porque o Scrum é diferente Fazer com que vocês tenham mais interesse sobre o assunto

Motivação

32% Sucesso (no prazo, dentro do orçamento e com escopo completo) * Fonte: Standish Group 32%  Sucesso (no prazo, dentro do orçamento e com escopo completo) 44%  Mudaram (atrasaram, estourou o orçamento, e/ou reduziram escopo) 24%  Falharam (cancelados ou nunca usados)

Falta de envolvimento do usuário Falta de suporte da direção Requisitos e especificações incompletas Falta de suporte da direção Falta de Pessoas e Recursos

Evite situações com grandes chances de resultar em falha

Manifesto Ágil Manifesto para o Desenvolvimento Ágil de Software Há alguns anos, um grupo de profissionais veteranos na área de software decidiram se reunir em uma estação de esqui, nos EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo.

Indivíduos e interações mais que processos e ferramentas

mais que documentação abrangente Software Funcionando mais que documentação abrangente

Colaboração do cliente mais que negociação de contratos

mais que seguir um plano Responder às mudanças mais que seguir um plano

Princípios do de Software Desenvolvimento Ágil de Software

12 Princípios Software funcionado Construir projetos com pessoas motivadas Manter um ritmo constante Comunicação cara a cara Satisfazer o cliente Atenção contínua à excelência técnica 12 Princípios Avaliações regulares Equipes de negócios e desenvolvimento juntas Receber bem mudanças de requisitos Entregar software em menor tempo Simplicidade Equipes organizadas

SCRUM

Uma linguagem de programação Uma IDE de desenvolvimento

NÃO

iterativo e incremental Scrum é um processo iterativo e incremental para desenvolvimento de produtos O Scrum foi criado oficialmente na década de 90, por Ken Schwaber e Jeff Shuterland, com a ajuda de Mike Beedle, John Scumniotales e Jeff McKenna. A sua criação foi na realidade feita de maneira completamente independente, em duas frentes: de um lado, Ken Schwaber, e do outro Jeff Shuterland. Em 1995-1996, Ken e Jeff se reuniram e documentaram o processo do Scrum como se conhece hoje em dia. Em 2001, Ken Schwaber e Jeff Shuterland fizeram parte do grupo de profissionais que assinou o Agile Manifest.

valor de negócio O objetivo é entregar o máximo de possível no menor tempo

evidenciar os problemas Ajuda à evidenciar os problemas

Cuidado!

O Scrum NÃO é a solução para os seus problemas

Projetos Scrum progridem em uma Um período constante leva Sprints Projetos Scrum progridem em uma série de “sprints” Ocorre em um período de duas a quatro semanas Um período constante leva a um melhor “ritmo” O produto é projetado, codificado e testado durante o sprint

Scrum Framework Papéis Product Owner Scrum Master Time Cerimônias (reuniões) Sprint Planning 1 e 2 Daily Scrum Review & Retrospective Artefatos Product Backlog Sprint Backlog Burnup/Burndown Charts

Papéis e Responsabilidades

Product Owner Time Scrum Master

Porco Galinha Product Owner (dono do produto) Scrum Master Team (Time/Equipe) Um Porco é alguém que tem sua pele em jogo. Mike Cohn se refere, muito felizmente, às pessoas com este papel como “Pessoas que têm seu bacon na linha.” Porcos são considerados os principais membros do time. Realizadores. Pessoas que fazem o trabalho. Galinha Presidentes Diretores Fonte: http://www.implementingscrum.com

Product Owner Define as funcionalidades do produto Decide datas de lançamento e conteúdo Responsável pela rentabilidade (ROI)‏ Prioriza funcionalidades de acordo com as necessidades do cliente Ajusta funcionalidades e prioridades Aceita ou rejeita o resultado dos trabalhos O Product Owner, ou simplesmente PO, representa o cliente, patrocinadores e/ou financiadores do projeto.

Scrum Master Trabalhar com o Product Owner Cuidar do Time Manter o processo funcionando Garantir a comunicação entre os envolvidos “comando e controle” Permitir que o time se auto-organize para realizar o trabalho Garantir que as vias de comunicação estejam livres e acessíveis Garantir e ajudar que o time siga o processo do Scrum Cuidar e proteger a equipe de interferências externas, de modo a garantir que a produtividade do time não seja a afetada Remover impedimentos (obstáculos) que o time encontrar Agir como facilitador na reunião de Daily Scrum

Time (2 - 9) Responsável por entregar os ítens do Sprint Backlog Compromisso com as entregas Estimar os itens do Backlog Gerenciar o próprio progresso Auto organizados Permitir que o time se auto-organize para realizar o trabalho Garantir que as vias de comunicação estejam livres e acessíveis Garantir e ajudar que o time siga o processo do Scrum Cuidar e proteger a equipe de interferências externas, de modo a garantir que a produtividade do time não seja a afetada Remover impedimentos (obstáculos) que o time encontrar Agir como facilitador na reunião de Daily Scrum --------------------------------------------------------------- O time de Scrum é formado por pessoas comprometidas em realizar o trabalho proposto. Um time de Scrum tem diversas responsabilidades entre elas participar das cerimônias, as cerimônias são reuniões, formais ou não, que acontecem em momentos distintos da Sprint.

Cerimônias

Sprint Planning Sprint Planning 1 Sprint Planning 2 Daily Scrum Sprint Review Sprint Retrospective

TIMEBOX!

Sprint Planning Planning - 4 horas 2 horas Planning 1 Planning 2

Definir o objetivo da Sprint Planning 1 Participam Time Scrum Master Product Owner Reunião de estratégia Definir o objetivo da Sprint Comprometimento do Time

Planning 1 O Time, e somente o Time, pode decidir e se comprometer a respeito do Trabalho que será executado.

Dividir as estórias em tarefas Planning 2 Participam Time Scrum Master Reunião de planejamento tático Dividir as estórias em tarefas Reunião de designer de software

Reunião de curta duração(15 minutos) Daily Scrum Reunião de curta duração(15 minutos) Reunião publica, onde todos participam Apenas os membros da equipe ScrumMaster E o Product Owner podem falar

Daily Scrum As três perguntas: #1 O que eu fiz desde a última reunião? #2 O que eu vou fazer até a próxima reunião? #3 Quais os problemas estão impedindo a realização do meu trabalho? - Nos ajudam a analisar nossa velocidade/ritmo; - Fazem com que todo o time esteja a par do que está acontecendo em todo o projeto; - Identificam impedimentos; Integram diariamente o time; - E, principalmente, nos fornecem um termômetro sempre atualizado de "Como está o nosso projeto?"

Review Se preparar para a review Reunião com duração de 2 horas Todos participam Apresentação dos resultados obtidos durante a Sprint Reunião informar, sem slides Se preparar para a review

Reunião com duração de 2 horas Reunião de portas fechadas Retrospective Reunião com duração de 2 horas Participam Time Scrum Master Product Owner* Reunião de portas fechadas Detectar pontos de melhorias

Artefatos

Burnup/Burndown Charts Product Backlog Sprint Backlog Burnup/Burndown Charts

Product Backlog O Product Backlog é uma lista de todas as funcionalidades desejadas no produto, estimadas pelo time e priorizadas pelo Product Owner. Nós as chamamos de estórias, ou algumas vezes apenas de itens do backlog.

Escrevendo ESTÓRIAS * User Stories

Uma estória de usuário, ou user story, é um requisito de sistemas de software formulado com uma ou duas sentenças em linguagem natural. Cada user story é limitada e pequena, de forma a caber perfeitamente em um pequeno papel de post-it. Isso é feito para de forma a garantir que estórias muito grandes sejam sempre quebradas e granularizadas. Se a sua estória esta grande demais para o post-it, diminua o post-it.

User stories são uma maneira rápida de lidar com requisitos do cliente A intenção com a user story é ser capaz de responder mais rápido e com menos overhead as mudanças nos requisitos voláteis do mundo real.

Como “usuário do sistema” Quero “funcionalidade” Para “valor de negócio” Mike Cohn

CRITÉRIOS DE ACEITAÇÃO Na parte de trás da estória, normalmente são escritos os critérios de aceitação. Critérios de aceitação funcionam como um abalizador de entendimento do que é “pronto” entre o desenvolvedor e o cliente, para aquele requisito específico. Criam entendimento sobre quando a tarefa está pronta

Exemplo de uma User Story Como Gestor, Quero que as informações pessoais dos clientes fiquem gravadas em formato criptografado no banco de dados, Para garantir a privacidade e a segurança dos dados dos meus clientes. Critérios de aceitação: - Ter os dados armazenados no banco de dados e arquivos de troca do sistema usando algoritmo de criptografia do tipo chave publica/chave privada. Mike Cohn

Sprint Backlog O Sprint Backlog é a lista de tarefas que o time se comprometeu com o Product Owner a implementar durante a Sprint, após a reunião de Sprint Planning 1 & 2.

Burnup/Burndown Charts Os gráficos de Burndown e Burnup são a melhor ferramenta do time para manter registro da velocidade atual do trabalho.

Sprint Burndown

Sprint Burn Up

Problemas comuns na adoção de Scrum

Product Owner pouco presente Sem Visão Sem release plan Sem product backlog

Falta estimativa Falta priorização Falta acompanhamento Se o Product Backlog não é mantido Falta estimativa Falta priorização Falta acompanhamento

Se as cerimônias não acontecem Falta planejamento Falta comprometimento para entregas PO pode aceitar itens que não estão prontos

Sem retrospectivas Falta de uma maneira de melhorar o trabalho do time (lembram do ballpoint?) Mesmos erros acontecem sempre Impedimentos não são removidos

O que é difícil em Scrum? Detalhes podem escapar se não for gerenciado corretamente Criar e manter um Product Backlog requer trabalho

Então... Scrum é um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível. Isto permite a rápida e contínua inspeção do software em produção (em intervalos de duas a quatro semanas).

Então... As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade. Entre cada duas a quatro semanas todos podem ver o real software em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um “Sprint”.

Quem usa? Microsoft Yahoo Google Philips Siemens Nokia Globo.com Provider Sistemas*

Curso de Gerenciamento de Projetos com Scrum Próximos passos www.alexsandromarques.wordpress.com www.qualiti.com.br Curso de Gerenciamento de Projetos com Scrum 12 e 19 de Setembro

Perguntas

Dicas www.alexsandromarques.wordpress.com www.scrum.org.br www.scrumalliance.org http://br.groups.yahoo.com/group/scrum-brasil alexoliveira.marques@gmail.com