Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Gestão Ágil de Projetos com Scrum

No description
by

priscila nesello

on 5 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Gestão Ágil de Projetos com Scrum

Como resolver isso? Introdução Características
Métodos àgeis GESTÃO ÁGIL de PROJETOS com SCRUM Cerimônias e Artefatos San Francisco Budapest Equipe Multifuncional (cc) photo by Metro Centric on Flickr (cc) photo by Franco Folini on Flickr (cc) photo by jimmyharris on Flickr Stockholm (cc) photo by Metro Centric on Flickr Adaptabilidade:
Habilidade e capacidade de adaptação rápida do processo para atender e reagir a mudanças de última hora nos requisitos e/ou no ambiente, ou a situações ou riscos não previstos inicialmente. Iteratividade:
Envolve vários ciclos curtos, dirigidos por características do produto, nos quais certo conjunto de atividades é completado em poucas semanas; estes ciclos são
repetidos muitas vezes para refinar as entregas. Discussão em grupo: Por que Métodos Ágeis?

O que determina o sucesso ou fracasso de um projeto? Como o Scrum funciona Dinâmica 15 min
Agrupar sucessos e fracassos em categorias Sucesso Fracasso Compare Grupo 1 Grupo 2 Grupo 3 Clientes Pessoas Processos Um método para ser caracterizado ágil, deve apresentar, em um grau
adequado ao contexto do produto do projeto, as características de adaptabilidade, incrementalidade, iteratividade, colaboratividade,
cooperação, orientação à pessoas, parcimônia (leanness) e restrição de prazo. Quantos dos problemas encontrados se enquadram em... Colaboratividade:
É uma atitude entre membros da equipe de desenvolvimento, entre os quais se encoraja a comunicação para disseminar informação e apoiar integração rápida de incrementos. Cooperação:
Interação aberta e com proximidade entre os vários stakeholders (especialmente entre cliente e equipe); o cliente deve tomar parte ativa no processo de
execução e prover feedback de forma regular e frequente. Orientação a pessoas:
Favorecimento de pessoas sobre processos e tecnologias; a equipe é encorajada a aumentar sua produtividade, qualidade e desempenho; a comunicação e a cooperação dentro das equipes são aspectos
considerados fundamentais e necessários. As reuniões diárias em pé e os workshops de reflexão dão às pessoas a chance de manifestar suas preocupações. Incrementalidade:
Não tentar construir o produto do projeto todo de uma só vez; o produto é partido em incrementos (pequenas releases com novas funcionalidades) que podem ser desenvolvidos em paralelo em ciclos rápidos; quando o incremento é completado e validado, ele é integrado ao projeto. Parcimônia:
Eliminação de perdas ou habilidade de fazer mais com menos recursos;
característica que o processo ágil tem, de requerer o mínimo necessário de
atividades para mitigar riscos e alcançar metas; deve-se remover todas as atividades desnecessárias do projeto. Restrição de Prazo:
Estabelecimento de limite de tempo para cada iteração programada. Grandes volumes de desenvolvimento são quebrados em múltiplas entregasque possam
ser executadas incremental e concorrentemente de modo previsível. Outras:
Transparência ou clareza ;
Auto-organização,
Emergência;
Períodos de reflexão e introspecção;
Incorporação de feedback rápido;
Modularidade;
Convergência;
Equipes pequenas;
Testes constantes;
Equipes locais,
Cortesia. José Fortuna Abrantes, Guilherme Horta Travassos Manifesto Ágil:
Em 2001, um grupo de especialistas em software se reuniu no resort Snowbird, em Utah, para rascunhar o que ficou conhecido como Manifesto Ágil (www.agilemanifesto.org):

"Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e ajudando outros a fazê-lo. Ao longo deste trabalho começamos a valorizar:
indivíduos e interações em vez de processos e ferramentas;
software funcional em vez de negociação de contrato;
colaboração com o cliente em vez de negociação de um contrato;
respostas à mudança em vez de seguimento de um plano.
Ou seja, mesmo havendo valor nos itens da direita, valorizamos mais os itens da esquerda." Fundamentos Scrum Forma de reiniciar o jogo, seja após um incidente, seja depois que a bola saiu de jogo. A idéia é manter o jogo (desenvolvimento de software) rolando. Por que as equipes às vezes falham com Scrum? 1. Profissionais desacostumados a metodologia;
2. Projetos tão complexos a ponto de precisar de técnicas mais avançadas que reduzam sua complexidade para que seja possível controlá-lo;
3. Empresas despreparadas para o Scrum ou suas equipes não sabem como usar segundo as restrições atuais da empresa. [©2001 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.] Declaração de Interdependência:
Enquanto o Manifesto Ágil lida com desenvolvimento de software, a "Declaração de Interdependência" (Declaration of Interdependence, ou DOI) da Gestão de Projeto Ágil, que outro grupo de especialistas elaborou em 2005, focaliza mais o gerenciamento de projetos (http://pmdoi.org):

"Somos uma comunidade de líderes de projeto que tem sido altamente bem-sucedida em entregar resultados. Para alcançar tais resultados:
aumentamos o retorno do investimento, tornando o fluxo contínuo de valor o nosso foco;
entregamos resultados confiáveis, engajando os clientes em interações frequentes e propriedade compartilhada;
esperamos incertezas e gerenciamos levando-as em conta, por meio de iterações, antecipação e adaptação;
promovemos criatividade e inovação reconhecendo que os indivíduos são a fonte última de valor e criamos um ambiente em que eles fazem a diferença;
impulsionamos o desempenho por meio do compromisso do grupo em obter resultados e da responsabilidade compartilhada pela eficácia do grupo;
melhoramos a eficácia e a confiabilidade por meio de estratégias situacionais específicas, processos e práticas." Fundamentos [©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.]
1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
3. Entregar software funcionando com frequencia, na escala de semanas até meses, com preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. Além desses quatro valores, o Manifesto Ágil tem doze princípios: Origem do Scrum Historicamente, o termo Scrum surgiu em um artigo publicado por Hirotaka Takeuchi e Ikujiro Nonaka na Harward Business Review de 1986. Nesse artigo entitulado "The new new product development game" ("O novo novo jogo do desenvolvimento de produtos"), Takeuchi e Nonaka descreveram uma abordagem holística, na qual equipes de projeto são compostas de pequenas equipes multifuncionais, trabalhando com sucesso rumo a um objetivo comum, que os autores compararam à formação Scrum do rugby. Origem do Scrum Origem do Scrum Enquanto trabalhava na construção de uma ferramenta de Análise e Projeto Orientados a Objetos (Object-Oriented Analysis and Design, ou OOAD), Jeff Sutherland, então vice-presidente de engenharia da Easel, Inc., percebeu que sua equipe de software precisaria de uma versão aprimorada do Desenvolvimento Rápido de Aplicações (Rapid Application Development, ou RAD).
O que ele queria era um processo semelhante ao Scrum, em que, ao final de iterações curtas, o CEO da Easel pudesse ver a demonstração de código funcional em vez de gráficos Gantt em papel. Hirotaka Takeuchi Ikujiro Nonaka Jeff Sutherland Durante este mesmo período, Ken Schwaber estava pesquisando ativamente sobre como poderia ajudar sua empresa, Advaced Development Methods (ADM), a melhorar seu processo de software com objetivo de aumentar a produtividade das equipes.

Após profunda análise de como outras vendedoras de software independentes (Independent Software Vendors, ou ISV) bem-sucedidas contruíriam softwares, Ken percebeu que o processo de desenvolvimento de todas elas era semelhante, no sentido de que todas usavam processos empíricos e exigiam inspeção e adaptação constantes. Ken Schwaber A pedido da Object Management (OMG) em 1995, Jeff e Ken trabalharam em conjunto para resumir o que haviam aprendido ao longo dos anos; eles criaram uma nova metodologia, que foi chamada de Scrum, descrita em um artigo de Schwaber, "Scrum and the perfet storm" ("Scrum e a tempestade perfeita"), disponível em www.controlchaos.com/my-articles. Conceitos Iteração: 1. Influência recíproca de dois ou mais elementos;
2. Fenômeno que permite a certo número de indivíduos constituir-se em grupo, e que consiste no fato de que o comportamento de cada indivíduo se torna estímulo para outro Interação: 1. Repetição 1. Um projeto é considerado bem sucedido se for entregue no prazo, dentro do orçamento e com os requisitos originalmente previstos;

2. Um projeto é considerado fracassado se for cancelado antes de sua finalização ou se nunca for utilizado após à sua conclusão; e

3. Um projeto é considerado contestado se for entregue depois do prazo, acima do orçamento ou com menos atributos e funcionalidades do que originalmente previstos. Sobre
Projetos: User Histories Vantagens do Scrum http://www.dicionariodoaurelio.com/ http://www.dicionariodoaurelio.com/ Periodicamente o The Standish Group, um instituto de pesquisa americano, publica o relatório “CHAOS Summary report”.
O relatório de 2009, mostrou dados preocupantes:
apenas 32% dos projetos foram considerados bem sucedidos;
enquanto 24% foram classificados como fracassados; e,
os restantes 44% ganharam o status de contestado.

Do relatório publicado em 2009, para o relatório de 2011, a taxa de projetos rotulados como sucesso aumentou de 32% para 37% enquanto a taxa de projetos rotulados como fracasso diminuiu de 24% para 21%. A taxa de projetos com o rótulo de contestado também decresceu de 44% para 42%. Complementar a esta pesquisa, foram apontadas quatro razões para a melhoria significativa encontrada, entre elas a adoção de metodologias ágeis.
Em conformidade com esta informação, o Scrum criado em 1996 por Ken Schwaber e Jeff Sutherland tem sido largamente utilizado nos últimos 5 anos e reúne atividades de monitoramento e feedback, reuniões rápidas e diárias a equipe, visando identificação e correção de quaisquer deficiências e/ou impedimentos na execução dos projetos. (Schwaber, 2004) Como ganhar dinheiro resolvendo problemas que você não conhece, com pessoas desconhecidas, em um tempo curto e com poucos recursos (e se divertindo)? Um mecanismo de redução de risco: todos nós somos responsáveis pelo planejamento e execução de projetos, sabemos a importância de reduzir o nível de risco ou incerteza a zero, ou para o menor possível;
Um ciclo de vida de projeto mais enxuto;
Um processo de planejamento de projeto mais adaptativo. Diferentemente do processo sequencial usado dentro do ambiente em cascata, que considera a estabilidade do projeto como sua fundação, no Scrum a mudança é considerada a única constante;
Uma estrutura de projeto baseada na motivação e no orgulho das pessoas. Mais do que tudo, talvez este seja um dos princípios mais importantes da metodologia Ágil e do Scrum. Cartão de História Segundo Passo:
Coletar requisitos para o Backlog de Produto Perguntas:
Quais são os objetivos ou metas de negócio?
Por que você necessitaria desse projeto? Exemplo: Primeiro Passo:
identificar os stakeholders e seus objetivos Específico: todos terão o mesmo entendimento do que são os objetivos;
Mensurável: podemos determinar objetivamente se os objetivos foram alcançados;
Alcancável: Os stakeholders concordam sobre o que são os objetivos;
Realista: devemos ser capazes de realizar os objetivos do projeto com os recursos que temos;
Baseadas em tempo: daremos tempo suficiente para realizar os objetivos SMART Objetivos e métricas dos stakeholders.
Métricas podem ser critérios como redução dos gastos (30%), número de chamadas de serviço (35%) ou número de usuários registrados (35%). Técnica: Floresta
(Produto) Árvores Galhos Folhas (Histórias) Consistente: um requisito consistente não entra em conflito com outro requisito;
Inequívoco: os revisores de uma declaração de requisito devem ser capazes de extrair a mesma interpretação deça, independente de seus papéis;
Testável: devemos ser capazes de criar casos de teste para um requisito. Se um requisito não for testável, tentar determinar se ele está implementado de forma correta torna-se uma questão de opinião;
Factível: deve ser possível implementar cada requisito dentro das capacidades e limitações conhecidas do ambiente de sistema;
Independente: nenhuma história de usuário (PBI) deve depender de outra história de cliente. Coleta visual de Requisitos para o Backlog de Produto Durante este passo você se reunirá com os stakeholders, cada um em seu papel específico para tentar entender as necessidades de e transformá-las em requisitos do produto do projeto. CUTFIT Da mesma forma que o Product Owner pode usar as regras SMART para verificar os objetivos dos stakeholders, ele e a equipe podem usar as regras CUTFIT, para identificar se suas histórias ou PIBs (Product Backlog Itens), estão escritas de maneira apropriada, prontas para que a equipe de desenvolvimento possa estimá-las e desenvolvê-las. As árvores e a floresta Você para de escrever a história quando:
1. o cliente não consegue decompor essa história em outras histórias ponta a ponta, ou seja, histórias que abranjam todas as camadas da aplicação;
2. a equipe consegue derivar tarefas dessas histórias, variando de 4 a 8 horas, para começar o trabalho de execução;
3. a equipe consegue começar a estimar os pontos dessa história utilizando a técnica baseada em critérios, para estimar o número de pontos da história. Fronteiras do Produto Objetivos do Cliente Equipe Árvore de Gerenciamento de Sala Árvore de Gerenciamento de Usuário Árvore de Gerenciamento de Reserva Galho Novo de Gerenciamento de Usuário Galho Atual de Gerenciamento de Usuário Incluir uma sala;
Excluir uma sala Editar cobrança;
Cancelar conta;
Cadastro Reservar uma sala;
Cancelar uma sala FLORESTA (PRODUTO)
Produto de Software para Reserva de Sala Privada ÁRVORES
1. Gerenciamento da sala
2. Gerenciamento do usuário
3. Gerenciamento da resera GALHOS
2.1 Gerenciamento de usuário atual
2.2 Gerenciamento de usuário novo FOLHAS
3.1 Incluir uma sala; 1.2 Excluir uma sala;
2.1.1 Editar informações de cobrança;
2.1.2 Cancelar conta; 2.2.1 Cadastro
3.1 Reservar uma sala; 3.2 Cancelar uma sala PRIORIZAÇÃO Os stakeholders vão querer focalizar primeiro as histórias que trouxerem o maior valor para sua empresa ou unidade de negócio. Depois que essa decisão é tomada, um cartão de história, pode ser usado para descrever algumas das tarefas de alto nível que os clientes gostariam de realizar com todos os casos de teste ("verificar se...") que devem ser realizados para essa história: Na posição de cliente, devo ser capaz/desejo [...], o que ajuda a [objetivos]
Tarefas: _________________
Verificar: ________________
Verificar: ________________ Conceitos Ciclo de vida do Scrum Equipe composta de:
um Scrum Master;
um Product Owner (Dono do produto);
Equipe do Projeto. Com todas as habilidades necessárias para construir o produto do projeto. Scrum Master Product Owner Trabalha com as partes interessadas para definir o Backlog de Produto e para ser responsável pelos resultados do negócio
Coleta requisitos para o Backlog de Produto
Colabora com o ScrumMaster e a equipe para fazer o Planejamento de Releases e o Planejamento das Sprints
Colabora com o ScrumMaster para proteger a equipe de distúrbios externos
Guia e treina a equipe no sentido de alcançar as metas do Planejamento de Realeses e do Planejamento das Sprints
Acompanha de perto o progresso do projeto
Fica responsável para dar feedback à equipe A Equipe do Projeto Se auto-gerencia e se auto-organiza
Responsável por estimar, por conta própria, os itens do Backlog ou as User Stories (histórias de cliente)
Tem o poder de transformar itens do Backlog de Produto, ou histórias, em tarefas nas quais possam trabalhar
Fica de olho no progresso do projeto
Responsável por demonstrar os resultados do Sprint para o Product Owner e partes interessadas, ao final de cada sprint Serve como guardião da estrutura de processo do Scrum
Guia e treina a equipe no sentido de alcançar as metas dos lançamentos e dos Sprints
Trabalha com o Product Owner para proteger a equipe de distúrbios externos
Ajuda a ficar de olho no progresso do projeto, conforme necessário, para auxiliar a equipe
Organiza a Retrospectiva da Sprint para ajudar a equipe de Scrum a melhorar seu desempenho nos processos e no projeto 1. Product Owner: responsável por obter informações dos stakeholders, ou representantes para elaborar uma lista de requisitos e criar um Backlog de Produto. Costumam ser coletados como histórias curtas, durante um workshop de um ou dois dias, anteriormente à reunião de Planejamento das Realeses (Planejamento de Lançamentos) e à reunião de Planejamento de Sprints. O objetivo-chave do Planejamento das Realeses é permitir que a equipe de Scrum identifique todos os lançamentos que o produto do projeto deve ter, com uma agenda de entregas prováveis. Duração do
Planejamento de Realeses:
quatro horas no caso de uma equipe de Scrum com Sprints de quatro semanas. 2. Além do Planejamento de Realeses a equipe de Scrum também deve passar por alguns Planejamentos de Sprints;

Durante a primeira parte da reunião, o Product Owner percorrerá os requisitos, na forma de histórias de usuário, para decidir, com o feedback da equipe, quais deveriam fazer parte de quais Sprints e quais são seus objetivos. A primeira reunião serve para responder à questão "O quê". Duração do
Planejamento de Sprints:
em torno de oito horas, no caso de Sprints de quatro semanas, e deve ser ajustada para quatro horas no caso de Sprints de duas semanas. 3. Durante a segunda parte da reunião de Planejamento de Sprints, que focaliza o "Como", a equipe de desenvolvimento tentará identificar as tarefas "tasks" a partir das histórias previamente escolhidas e deduzir quanto tempo (em horas) a equipe levará para transformar essas tarefas em incrementos de produto potencialmente entregáveis.

A menos que a equipe utilize algum tipo de software de planejamento, todas as tarefas de desenvolvimento que fazem parte do Sprint normalmente são registradas em um Quadro de Tarefas (Task Board), algum tipo de quadro-branco em uma parede, para fácil alocação e rastreamento por parte da equipe. notes Cerimônias e Artefatos Tão logo as reuniões de Planejamento de Realeses e Planejamento de Sprints tenham terminado, inicia-se o trabalho propriamente dito dos Sprints, como os 15 minutos do Daily Scrum (Scrum Diário) e Daily Standup (algo como Reunião Diária em Pé). 4. Originalmente, a Reunião Diária poderia durar até cerca de 30 minutos, mas, como parte da evolução ou ajuste do Scrum, sua duração poder ser cada vez mais reduzida, podendo chegar aos 15 minutos. Duração de uma Sprint:
de uma a quatro semanas. 5. Antes do final de cada Sprint, a equipe se reunirá com o Product Owner, como parte do Mecanismo de Inspeção e Adaptação do Scrum que é conhecido como Revisão de Sprint, organizada pelo Scrum Master. Duração da Revisão de Sprints:
quatro horas, no caso de um Sprint de quatro semanas, duas horas, no caso de um Sprint de duas semanas. 6. Logo após a Revisão do Sprint, mas antes do Sprint seguinte, a Equipe de Scrum também se reunirá para percorrer uma Retrospectiva do Sprint. Diferentemente dos processos tradicionais, em que o gerente do projeto é responsável por organizar reuniões de status semanais para acompanhar o status do projeto, no Scrum a equipe se reunirá todo dia, não para inspecionar o estado do projeto, e sim, para inspecionar o progresso da equipe rumo ao objetivo do Sprint. Para manter o registro do progresso da equipe rumo ao objetivo do Sprint, um Gráfico de Burndown (Gráfico de Consumo) será criado. Mesmo que a criação desse Gráfico de Burndown seja responsabilidade da equipe, pode ser atualizado pelo Scrum Masters sempre que não tiver tempo para isso. Objetivo:
1. Discutir o que foi e o que não foi feito (Equipe e Product Owner)
2. Demonstrar para o Product Owner aquilo que foi feito e obter o seu feedback.
3. Obter atualizações do Product Owner relativas a quaisquer mudanças na direção do mercado ou do produto. Objetivo:
identificar o que funcionou e o que não funcionou durante o Sprint atual. A intenção é ver como os participantes poderiam tornar sua colaboração ainda mais eficaz ao seguir para o próximo Sprint de duas semanas. RESUMO Montar Grupos de ate 7 pessoas;
Escolher o Product Owner;
Escolher o Scrum Master;
Solicitar o tema do projeto;
Conhecer o cliente e suas necessidades;
Definir o Product Backlog;
Definir as Sprints;
Desenhar o quadro de Ciclo de Vida do Projeto;
Montar o quadro de Gestão à vista;
Apresentar o quadro com os Product Backlog e as Sprints. Vivenciando a experiência do Scrum Atingindo resultados por meio das equipes Planning Poker Trata-se de uma técnica de estimativa usada em equipes de Projeto Ágil para estimar, coletivamente, o tamanho relativo de suas histórias usando uma métrica denominada ponto de história. Para ser efetivo no uso do Planning Poker, supõe-se que a equipe de projeto seja composta de generalistas que tenham experiência com as diferentes tarefas relacionadas ao projeto. Dificuldades com Planning Poker:
Pontos de História não comparáveis entre várias equipes gera um risco de impacto negativo, em uma implementação de escala corporativa;
Problemas culturais: a influência de pessoas mais velhas e pessoas em papéis de liderança geralmente inibe os membros da equipe no momento de fazer uma estimativa diferente. Metodologias Ágeis
“Agile is not a set of
practices, but a core set of
beliefs and principles.”
Jim Highsmith É uma tentativa de refinar
as metodologias iterativas
tirando o foco do processo e dando mais ênfase nas pessoas! Fluxo Projeto Tradicional Andrew Pham e Phuong-Van Pham (2011) Fluxo Projeto Scrum Andrew Pham e Phuong-Van Pham (2011) Backlog de Produto, Release e Sprint Andrew Pham e Phuong-Van Pham (2011) Sprints, Burndown e Daily Scrums Criado por Flavio Steffens de Castro - www.agileway.com.br Tipos de Certificações Empresas que utilizam Scrum
Full transcript