Embed Size (px)
DESCRIPTION
InfoCES2010 - Marcos Miguel - SCRUM
Citation preview
Marcos Miguel [email protected]
MBI (Master in Business Intelligence) UFJF
Bacharel em Sistemas de Informação pelo CES/JF
Diretor de desenvolvimento da Projetus Informática
Professor do Centro de Ensino Superior de Valença
Agenda O Introdução
O Conceitos
O Papéis
O Envolvimento x Comprometimento
O Cerimônias
O Artefatos
O Caso de uso
O Conclusões
O Dúvidas
O Referências
Mais
uma
metodologia?
Problemas no desenvolvimento de Softwares
O Caos pela mudança constante de requisitos
O Estimativas de tempo, custo e qualidade do
produto totalmente irreais
O Os desenvolvedores não sabem exatamente
como está indo o andamento do projeto e
acabam mentindo ou se enganando sobre
seus próprios resultados
Perdendo no revezamento...
O O estilo de “corrida de revezamento” aplicado ao desenvolvimento de produtos pode conflitar com os objetivos de velocidade e flexibilidade máximas. Ao invés disto, um estilo holístico, integrado, onde a equipe busca, como em um jogo de futebol, de forma integrada, chegar ao gol, com passes de bola, pode servir melhor às atuais necessidades competitivas.
Adequado de “The New New Product Development Game”, Hirotaka Takeuchi e Ikujiro Nonaka, Harvard Business Review, January 1986.
Origens do Scrum O Jeff Sutherland
O Uso inicial do scrum na Easel em 1993
O IDX e mais de 500 pessoas usando Scrum
O Ken Schwaber
O ADM
O Apresentação na OOPSLA 96 com Sutherland
O Três livros sobre Scrum
O Mike Beedle
O Padrões para o Scrum na PLOPD4
O Ken Schwaber and Mike Cohn
O Fundaram a Scrum Alliance em 2002,
O Inicialmente junto com a Agile Alliance
Quem usa o Scrum?
O Microsoft
O Yahoo
O Google
O Electronic Arts
O High Moon Studios
O Lockheed Martin
O Philips
O Siemens
O Nokia
O Capital One
O BBC
O First American Real Estate
O Lexis Nexis
O Sabre
O Salesforce.com
O Time Warner
O Turner Broadcasting
O Projetus Informática
O Globo.com
Scrum tem sido usado para
O Software comercial
O Desenvolvimento interno
O Desenvolvimento contratado terceirização)
O Projetos de preço fixo
O Aplicações Financeiras
O Aplicações certificadas pela Isso 9001
O Sistemas embarcados
O Sistemas disponíveis 24x7
O Video games
O Sistemas para suporte à vida
O Sistemas para controle de satélites
O Websites
O Software para handhelds
O Telefones celulares
O Aplicações para redes
O Algumas das maiores aplicações em produção
Características
O Equipes que se auto-organizam
O O produto evolui em uma série de “Sprints” de 2 a 4 semanas
O Os requerimentos são listados em um “ProductBacklog”
O Não há prática de engenharia prescrita (o Scrum adequa-se a todas)
O Usa regras generativas na criação de um ambiente ágil para a entrega de projetos
O É uma das “metodologias ágeis”
Conceitos
O Scrum é baseado nas melhores práticas aceitas pelo mercado, utilizadas e provadas por décadas
O É definido como uma teoria de processos empíricos
O É um framework conceitual
O Jim Coplien certa vez observou: "Todos irão gostar de Scrum; ele é o que já fazemos quando estamos pressionados contra a parede."
Conceitos
O Baseia-se em 3 Pilares:
O TRANSPARÊNCIA
O aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados
O quando alguém inspeciona um processo acredita que algo está pronto
O INSPEÇÃO
O Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas
Conceitos O ADAPTAÇÃO
O Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo
O Existem três pontos para inspeção e adaptação em Scrum: O A Reunião Diária: inspecionar o progresso em direção à meta
da Sprint e realizar adaptações que otimizem o valor do próximo dia de trabalho
O Revisão da Sprint e de Planejamento da Sprint:: inspecionar o progresso em direção à Meta da Release e para fazer as adaptações que otimizem o valor da próxima Sprint
O Retrospectiva da Sprint: revisar a Sprint passada e definir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora e gratificante
Resumo do processo
O O produto é definido: quais são os seus requisitos? O que realmente o cliente quer? O responsável por esta tarefa é o que chamamos de Proprietário do Produto (Product Owner)
O O Proprietário do Produto define quais são as funcionalidades do programa que mais importam, criando assim o que chamamos de Product Backlog
O Com as prioridades definidas, uma pessoa é definida para ser o ScrumMaster, uma espécie de coordenador do projeto. O ScrumMaster, junto com o Proprietário do Produto e o Time de desenvolvimento definem o que chamamos de Sprints.
O Cada Sprint possui uma parte de todo o Product Backlog, e devem ser trabalhados de acordo com as prioridades definidas no Product Backlog. Os Sprints devem ser preparados de uma forma de que durem de 2 a 4 semanas, e que no final de cada período tenham um produto apresentável para o cliente
O Os Sprints vão sendo feitos até o Product Backlog acabar e o PO definir que o projeto está pronto
Conteúdo
O Scrum emprega os eventos com duração fixa (time-boxes) para criar regularidade
O Entre os elementos do Scrum que têm duração fixa: O Reunião de Planejamento da Release
O Reunião de Planejamento da Sprint
O Sprint
O Reunião Diária
O Revisão da Sprint
O Retrospectiva da Sprint
O O coração do Scrum é a Sprint, que é uma iteração de um mês ou menos, de duração consistente com o esforço de desenvolvimento.
O Todas as Sprints utilizam o mesmo modelo de Scrum e todas as Sprints têm como resultado um incremento do produto final que é potencialmente entregável.
Conteúdo
O Scrum utiliza quatro artefatos principais:
O Backlog do Produto: é uma lista priorizada de tudo que pode ser necessário no produto
O Backlog da Sprint: é uma lista de tarefas do produto potencialmente entregável
O Burndown: é uma medida do backlog restante pelo tempo
O Burndown de Release: mede o Backlog do Produto restante ao longo do tempo de um plano de release
Papeis
O PRODUCT OWNER (PO)
O Representa os interesses do cliente.
O Ele tem que ser a interface entre o cliente e o time de desenvolvedores
O Definir as características e conteúdo do produto;
O Decidir sobre a data de término;
O Ser responsável pela rentabilidade do produto;
O Prorizar as funções de acordo com o valor de mercado e com o cliente;
O Ajustas recursos e priorizar tarefas a cada 30 dias, como necessário;
O Aceitar ou rejeitar o resultado do trabalho.
O PO pode ser um membro do Time, mas frequentemente leva a conflitos.
Papeis
O SCRUMMASTER O Líder da equipe de desenvolvimento e durante o trabalho, fica
mais em contato com o PO. Ele gerencia e repassa o trabalho que foi decidido durante o planejamento pelo Proprietário do Produto.
O Assegurar que a equipe de desenvolvimento funcione plenamente e seja produtiva;
O Ajudar na cooperação entre todas as funções e papéis do time;
O Proteger a equipe de interferências externas;
O Assegurar-se de que a metodologia está sendo seguida, incluindo chamadas para reuniões diárias (Daily Scrum Meetings), revisões de atividade (Sprint Reviews) e reuniões de planejamento das atividades (Sprint Planning).
O Ajuda o Time a entender e usar autogerenciamento interdisciplinaridade
O Ajuda o Time a fazer o seu melhor em um ambiente
O “Remove impedimentos“
O ScrumMaster pode ser um membro do Time, mas frequentemente leva a conflitos.
Papeis O SCRUMMASTER
O Além de comandar as reuniões diárias, o ScrumMaster têm três principais responsabilidades:
O Precisa saber quais atividade foram concluídas, quais foram iniciadas, quaisquer novas tarefas que foram descobertas e qualquer estimativa que possa ter mudado. Isto permite a ele atualizar sempre o Burndown Chart, que permite mostrar quanto trabalho falta para um Sprint acabar, dia por dia. Ele também tem que sempre olhar cuidadosamente para o número de tarefas em aberto. Estes trabalhos em aberto devem ser minimizados o máximo possível para garantir um trabalho sempre limpo e eficiente.
O Deve avaliar as dependências superficiais e bloqueios que causam prejuízos ao andamento do Projeto. Estes itens devem receber prioridades e serem acompanhados. Um plano de solução deve ser implementado de acordo com a ordem de prioridade destes impedimentos. Alguns podem ser resolvidos pelo time, outros podem ser resolvidos através de vários times, e outros podem precisar de envolvimento da gerência, pois podem ser problemas relacionados à empresa que bloqueiam qualquer membro do time a fazer qualquer coisa. Como exemplo deste tipo de impedimento externo, temos as questões judiciais.
O O ScrumMaster deve perceber e resolver problemas pessoais ou conflitos entre os integrantes do time de desenvolvimento SCRUM. Este tipo de problema deve ser clarificado pelo ScrumMaster e resolvido por diálogo com o time, ou então o ScrumMaster terá que ter ajuda da gerência ou do departamento de Recursos Humanos. Alguns estudos apontam que 50% dos problemas de desenvolvimento acontecem por razões pessoais. O ScrumMaster precisa estar sempre atento ao time para fazer dele totalmente funcional e produtivo.
Papeis
O TIME
O Desenvolvedores com todas as habilidades necessárias para transformar os requisitos do PO em um pedaço potencialmente entregável do produto ao final da Sprint
O Possui conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, projeto de interface de usuário ou projeto de banco de dados
O O conhecimento é compartilhado e todos contribuem
O Ninguém nem mesmo o ScrumMaster - diz ao time como transformar o Backlog do Produto em incrementos de funcionalidades entregáveis. O Time descobre por si só
O A sinergia que resulta disso melhora a eficiência e eficácia geral do Time como um todo
O Tamanho ideal de 5 a 9 membros
Envolvimento
X
Comprometimento
Envolvimento
X
Comprometimento
Envolvimento x Comprometimento
O Baseados nesta historinha, existem dois
tipos de pessoas em projetos Scrum:
O Galinhas: Apenas envolvidas com o projeto
O Todos os demais
O Porcos: Totalmente comprometidos com o
projeto
O Time SCRUM (Time, SrumMaster, PO)
Cerimônias
Reunião de Planejamento do Sprint O PO desenvolve um plano para o projeto de software bem próximo ao cliente para definir todas as funcionalidades que o cliente quer no seu produto. A partir desta lista, ele também tem que definir as prioridades de cada funcionalidade de acordo com várias variáveis: valor de mercado, importância de base, importância para o cliente, entre outras. Esta lista final é o que chamamos de Product Backlog e é a base para a reunião de planejamento do Sprint.
O Nesta reunião, o ScrumMaster trabalha junto com o PO e a Equipe de Desenvolvimento para definir qual a carga de tempo que cada funcionalidade do Product Backlog terá. Isto ajuda o PO a definir prazos reais para o projeto e o habilita a poder verificar como está o andamento do projeto durante todo o período de desenvolvimento. Esta carga de tempo e esforço é definida de acordo com o tamanho do(s) time(s), horas disponíveis e o nível de produtividade do time.
O Quando as prioridades e prazos das funcionalidades do software são definidas por completo, o PO sai de cena e o ScrumMaster começa a trabalhar juntamente com a Equipe de Desenvolvimento para a quebra destas tarefas grandes em pequenas tarefas, divididas por todos os integrantes da equipe de desenvolvimento. Esta reunião de planejamento geralmente dura até 4 horas e é ela quem define o Sprint Backlog, um dos artefatos SCRUM.
O Uma vez definido o Sprint Backlog, com a listagem de todas as tarefas, seus responsáveis e seus prazos, o processo de desenvolvimento começa.
Reunião Diária
O Tempo: Até 15 minutos
O Cada membro da equipe deve responder à três perguntas: O O que você fez desde a última reunião diária dentro deste
projeto?
O O que você fará entre agora e a próxima reunião diária dentro deste projeto?
O O que te impede de fazer seu trabalho da maneira mais eficaz possível?
O Scrum Master é responsável por organizar
O Galinhas não têm permissão de falar ficam na periferia
O Porcos ou galinhas que não obedecerem as regras acima podem ser convidadas a se retirar da reunião (galinhas) ou removidas da equipe (porcos)
Reunião de Revisão do Sprint
O No final do período do Sprint, a reunião de revisão do Sprint é feita. Nesta reunião, a equipe de desenvolvimento, junto ao ScrumMaster, se reúne com o PO (e convidados, caso ele achar adequado, como por exemplo o cliente ou acionistas do projeto). Esta reunião dura aproximadamente 4 horas.
O Na primeira parte da reunião, o resultado do Sprint é apresentado para o PO.
O As funcionalidaes são revisadas
O PO define quais itens do Product Backlog foram completados no Sprint, discutindo então com os membros da equipe e o cliente quais serão as novas prioridades.
O Primeiro passo para criar um novo Sprint, caso seja necessário, pois dessa primeira parte da reunião, um novo Product Backlog é gerado.
O Na segunda parte da reunião, o ScrumMaster se reunie com a equipe de desenvolvimento e revisa os altos e baixos do ciclo. O time conversa para saber o que foi bom e como se pode melhorar ainda mais o ambiente, as ferramentas e o convívio entre o time e suas funções. Esta parte é basicamente um aprimoramento interno.
O Depois que esta reunião é finalizada, um novo ciclo Sprint pode começar
Product Backlog Funcionalidade Prioridade
Modelagem de dados 1
Cadastro e gerenciamento de usuários 2
Conversão de vídeo para visualização na Internet (Codec) 3
Cadastro e gerenciamento de vídeos pelos usuários 4
Layout (Aparência) da página 5
Comentários para os vídeos e usuários 6
Notas para vídeos (ranking) 7
Proteção contra SPAM 8
Canais (grupos) de vídeos e usuários 9
Sistema de legendagem de vídeos 10
Reconhecimento de sons dos vídeos 11
Reunião de Planejamento do Sprint
uncionalidade Prioridade Custo-horas
Modelagem de dados 1 32
Cadastro e gerenciamento de usuários 2 26
Conversão de vídeo para visualização na Internet (Codec) 3 80
Cadastro e gerenciamento de vídeos pelos usuários 4 48
Layout (Aparência) da página 5 28
Comentários para os vídeos e usuários 6 20
Notas para vídeos (ranking) 7 16
Proteção contra SPAM 8 20
Canais (grupos) de vídeos e usuários 9 26
Sistema de legendagem de vídeos 10 64
Reconhecimento de sons dos vídeos 11 92
Meta do primeiro Sprint Funcionalidade Prioridade Custo-horas
Modelagem de dados 1 32
Definição de dados 1.1 8
Organização de tabelas 1.2 12
Relacionamento 1.3 8
Implementação em SGBD 1.4 4
Cadastro e gerenciamento de usuário 2 26
Formulários 2.1 6
Interação com cadastro na base de
dados 2.2 6
Visualização de perfil 2.3 6
Mudança de dados 2.4 4
Relacionamento entre usuários 2.5 4
Sprint Backlog
Burndown Chart
Ferramentas
O VersionOne
O http://www.versionone.com/
O Pronto
O http://pronto.bluesoft.com.br/
O FireScrum
O http://www.firescrum.com/
Scrum Board
Scrum Board
Caso de Uso
Ferramenta VersionOne
Tempo de desenvolvimento por Sprint (Rendimento da equipe)
Tempo
0
50
100
150
200
1 Sprint2 Sprint
3 Sprint4 Sprint
5 Sprint6 Sprint
Tempo
Tempo
Índice de problemas resolvidos
Gráfico Mantis
Ferramenta de Controle de Bugs
Conclusões
O O Scrum é um metodologia de desenvolvimento que tem despontado e trago resultados satisfatórios para muitas equipes
O “Não basta ser
uma equipe,
é preciso ser
um time”
DUVIDAS?
Referencias
O ScrumGuide: Guia oficial do Scrum em
http://www.scrum.org/scrumguides
O Implements Scrum: Mais informações
http://www.implementingscrum.com
Outros links:
www.mountaingoatsoftware.com/scrum
www.scrumalliance.org
