A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Luciano Soares de Souza. Agenda Problemas no Desenvolvimento de Software Metodologias Tradicionais "Old School" Metodologias Ágeis Scrum Considerações.

Apresentações semelhantes


Apresentação em tema: "Luciano Soares de Souza. Agenda Problemas no Desenvolvimento de Software Metodologias Tradicionais "Old School" Metodologias Ágeis Scrum Considerações."— Transcrição da apresentação:

1 Luciano Soares de Souza

2 Agenda Problemas no Desenvolvimento de Software Metodologias Tradicionais "Old School" Metodologias Ágeis Scrum Considerações Finais

3

4 A história se repete

5 Estatísticas Chaos Report Fonte: The Standish Group The Standish Group

6 Standish Group, % 80% Uso de Funcionalidades

7 Mas por que ?

8 Problemas A experiência de décadas seguindo pesadas práticas prescritivas tornou evidente que: Os detalhes são complexos para as pessoas. Os clientes ou usuários não tem certeza do que eles querem. Eles tem dificuldade de expressar tudo o que querem e pensam. Muitos detalhes do que eles querem só serão revelados durante o desenvolvimento. Na medida em que elas vêem o produto sendo construído, elas mudam de idéia. Forças externas (como um produto ou serviço da concorrência) trazem mudanças ou melhorias nos requisitos

9

10 Modelos Tradicionais Qualidade== Qualidade do Processo

11 Gestão Old School Reproduzir e Controlar

12 Problemas - Reproduzir Inibe aprendizado & criativiade

13 Problemas - Controlar Gerenciamento excessivo

14 Modelo Herdado

15 Modelo Cascata Meses!!!

16 Modelo Rup 2 semanas Bom resultado Não ataca o problema principal

17 Problema processo circularseparação das atividadesfacilidade de controle

18 Problema - Continuação problema na comunicação!

19 Problema de comunicação Demora-se muito tempo Interface de comunicação limitada e pouco expressiva Modelo linear e unidirecional

20 existe um mundo

21

22 Indivíduos e interações sobre processos e ferramentas Software funcionando sobre documentação extensa Colaboração com o cliente sobre negociação de contratos Responder a mudança sobre seguir um plano Manifesto Ágil

23 Modelo centralizado Todos os papéis presentes quando necessário

24 Sem ordem Atividades realizadas quando necessário

25 Planejamento Ágil

26

27 SCRUM Iterativo e Incremental Resposta às mudanças Maior valor para o negócio Práticas de engenharia livres Framework de processo

28 Visão Geral do Scrum

29 Papéis no Scrum

30 Product Owner Determina a Visão do Projeto Define as funcionalidades Determina o valor de negócio Responsável pelo ROI Prioriza funcionalidades Aceita ou rejeita o resultado do trabalho

31 Scrum Master Valores e Práticas do Scrum Resolve os impedimentos Conduz as reuniões diárias, de planejamento e revisão Escudo para interferências externas

32 Time Entre 5 e 10 pessoas Multi-funcional Auto organizável e Auto gerenciável Estima as funcionalidades Define as tarefas Levanta impedimentos (externos)

33 Processo Scrum

34 Product Backlog Criado a partir da Visão do Produto Contém todos os requisitos funcionais e não funcionais Geralmente escritos em User Stories Idealmente representado por itens que agregam valor aos usuários ou cliente Priorizado pelo Product Owner

35 Product Backlog - Exemplo Backlog item (BLI)Business Value (BV) [BLI001] As a standard user, search for a movie1000 [BLI002] As a standard user, search for movie reviews1000 [BLI003] As a standard user, view the top movies1000 [BLI004] As a standard user, search for theaters700 [BLI005] As a standard user, search for movie trailers700 [BLI006] As a standard user, create the user profile500 [BLI007] As a standard user, edit the user profile300 [BLI008] Integration with LDAP100

36

37 Sprint Planning 1 Reunião de no máximo 4 horas Revisar o product backlog Determinar o objetivo da sprint Selecionar parte do product backlog Estimar e priorizar IBLs (itens de backlog)

38 Estimando o Product Backlog 1 2 3

39 Estimando com Planning Poker 1 2 3

40

41

42 Sprint Planning 2 É um planejamento tático da equipe Os itens selecionados do Product Backlog são destrinchados em tarefas O resultado final é o Sprint Backlog

43 Sprint Backlog As tarefas não são atribuídas aos membros do time Cada membro escolhe sua tarefa diariamente Qualquer membro do time pode adicionar ou remover itens do Sprint Backlog (durante o daily meeting)

44 Sprint Backlog – Task Board IBLsTasks To DoWork In ProgressDone [IBL001] [IBL003] [IBL002] Require ments Analysis and Design Coding Test Code Review Deploy ment Require ments Analysis and Design Coding Test Code Review Deploy ment Require ments Analysis and Design Coding Test Code Review Deploy ment

45

46 Plannings 1 e 2 A B C F G H I D O que está dentro do Sprint Não pode ser alterado. - O que está fora do Sprint pode Ser alterado de acordo com a necessidade do cliente. - Ele pode alterar prioridades, inserir novas tarefas ou retirar tarefas existentes. - Algumas tarefas podem ser inseridas pela equipe. Ex: Montar ambiente para Integração contínua Prioridade Alta Baixa E Histórias

47

48 Sprint Um período de tempo entre 2 a 4 semanas Todos os Sprints devem possuir uma estrutura exatamente igual Funcionalidades construídas a partir dos IBLs selecionados Time define a organização necessária para efetuar o trabalho

49 Estrutura de um Sprint Planejamento – Sprint X Apresentação Sprint X Apresentação Sprint X Planejamento – Sprint X+1 Reunião diária Retrospectiva

50 Reunião Diária Objetivo Cada membro deve responder as seguintes perguntas: 1.O que você fez desde a última reunião diária? 2.O que você pretende fazer até a próxima reunião diária? 3.Existe algum problema que o impeça de realizar suas atividades? Impedimentos reportados aqui Duração 15 minutos (não mais que isso) Sugestão: Todos em Pé Qualquer pessoa pode participar, mas apenas o Scrum Master e os Membros da Equipe pedem falar

51 Quadro Kanban IBLsTasks To DoWork In ProgressDone [IBL001] [IBL003] [IBL002] Require ments Analysis and Design Coding Test Code Review Deploy ment Require ments Analysis and Design Coding Test Code Review Deploy ment Require ments Analysis and Design Coding Test Code Review Deploy ment dev 0 dev 1 imp

52 Sprint Burndown

53

54

55 Sprint Review (Demonstração) Objetivo Mostrar o que foi produzido no Sprint Participantes Product Owner, Scrum Master, membros do time, clientes, Usuários, Stakeholders e qualquer pessoa que esteja interessada no resultado da Sprint Qualquer participante pode falar, fazer perguntas ou observações

56 Sprint Review (Demonstração) Quand o time diz feito, o que isto significa? Conceito de pronto Não esconde trabalho não finalizado para manter a confiança do cliente O resultado da reunião deve ser um entendimento comum sobre o resultado da sprint e o estado do produto

57

58

59 Sprint Retrospective Objetivo Enumerar o que funcionou e o que não funcionou durante o Sprint Participantes Product Owner, Scrum Master e os membros do time Time deve encontrar soluções para os problemas mais críticos

60 Retrospectiva - Exemplo O que FuncionouO que não funcionou Testes Comunicação entre os membros Usuário Distante Reuniões Diárias Alguns membros chegam tarde Faltou melhor planejamento do Sprint

61

62

63

64 O Scrum não é... Não é a bala de prata Não te diz exatamente o que fazer Não resolve todos os seus problemas mas ajuda identificá-los de maneira mais fácil

65 Mais Informações Agille Alliance - Ótima fonte sobre métodos ágeis Scrum Alliance - Mountain Goat Software Site de um treinador de Scrum Masters Site do Ken Schwaber -

66 Obrigado!!! Dúvidas ?

67 Material Parte do material utilizado foi baseado nas apresentações disponibilizadas por: Igor Macaúbas Marcos Pereira Evandro João Agnes Luciano Félix Paulo Roberto Furtado Serra Eric Cavalcanti Luiz Eugênio Fernandes Tenório Renato Willi

68 Este trabalho está licenciado através da Atribuição-Uso Não-Comercial-Compartilhamento pela mesma Licença 3.0 Unported Você pode: Copiar, distribuir, exibir e executar a obra Criar obras derivadas Sob as seguintes condições: Atribuição. Você deve dar crédito ao autor original, da forma especificada pelo autor ou licenciante. Uso Não-Comercial. Você não pode utilizar esta obra com finalidades comerciais. Compartilhamento pela mesma Licença. Se você alterar, transformar, ou criar outra obra com base nesta, você somente poderá distribuir a obra resultante sob uma licença idêntica a esta Para cada novo uso ou distribuição, você deve deixar claro para outros os termos da licença desta obra. Qualquer uma destas condições podem ser renunciadas, desde que Você obtenha permissão do autor. Nothing in this license impairs or restricts the author's moral rights.


Carregar ppt "Luciano Soares de Souza. Agenda Problemas no Desenvolvimento de Software Metodologias Tradicionais "Old School" Metodologias Ágeis Scrum Considerações."

Apresentações semelhantes


Anúncios Google