1.
“ um framework para desenvolver produtos complexos em ambientes complexos” Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO

2.
Agenda <ul><li>PARTE 1 </li></ul><ul><li>Um pouco de história </li></ul><ul><li>Agilidade </li></ul><ul><li>Scrum </li></ul><ul><ul><li>Pilares </li></ul></ul><ul><ul><li>Papéis </li></ul></ul><ul><ul><li>Ciclo do Scrum </li></ul></ul><ul><li>PARTE 2 </li></ul><ul><li>Scrum vs. Métodos Tradicionais </li></ul><ul><li>Caso real: Aplicação de Scrum em projeto na Petrobras </li></ul>

3.
Um pouco de história... <ul><li>D écada de 50 : a gestão de projetos é reconhecida como disciplina, nascida a partir da administração </li></ul><ul><li>Henri Fayol : </li></ul><ul><ul><li>Seu trabalho é a base para a gestão de projetos tradicional </li></ul></ul><ul><ul><li>O gestor possui 5 funções básicas: </li></ul></ul><ul><li>O gráfico de Gantt é adotado como ferramenta para listar, acompanhar e controlar a execução das tarefas contidas em um projeto. </li></ul><ul><li>Até então a gestão de projetos é voltada para grandes projetos de engenharia e construção civil . </li></ul>Planejar Organizar Comandar Controlar Coordenar

4.
Um pouco de história... <ul><li>D écada de 60 : o desenvolvimento de software começa a ganhar complexidade. </li></ul><ul><li>Para gerenciar projetos de software , as empresas utilizam a medotologia tradicional antes aplicada a projetos de engenharia e construção civil. </li></ul><ul><li>Problemas começam a surgir: desenvolvimento de software exige mudanças frequentes </li></ul><ul><li>Winston Royce ( 1970 ): artigo criticando a abordagem tradicional para a gestão de projetos de software , que fica conhecida como waterfall . </li></ul>

5.
Um pouco de história... <ul><li>Waterfall , por Winston Royce (1970) </li></ul>

6.
Um pouco de história...

7.
Um pouco de história... <ul><li>Waterfall segue o conceito Big Design Up Front (BDUF) . </li></ul><ul><li>Os defensores do BDUF acreditam que o tempo gasto revisando exaustivamente a especificação garante a ausência de mudanças crític a s na fase de execução. </li></ul><ul><li>McConnell (1996): “c orrigir erros ainda na fase de especificação gasta entre 50 e 200 vezes menos tempo do que se o erro fosse encontrado durante a execução do projeto” . </li></ul>

8.
Um pouco de história... <ul><li>Meredith & Mantel: “p roblemas de comunicação e entendimento do que deve ser feito são responsáveis por falhas nos projetos ” . </li></ul><ul><li>Metodologias tradicionais sugerem que : </li></ul><ul><ul><li>M udanças devem ser evitadas a todo custo. </li></ul></ul><ul><ul><li>Se não for possível evitá-las, o gerente de projetos deve gerenciá-las . </li></ul></ul><ul><li>Para as metodologias tradicionais, a mudança pode ter um efeito devastador </li></ul>

9.
Um pouco de história... <ul><li>DeGrace & Stahl (1990): Fatores que tornam questionável o uso de BDUF para projetos de software: </li></ul><ul><ul><li>Requisitos não são completamente compreendidos no início do projeto; </li></ul></ul><ul><ul><li>Usuários só sabem exatamente o que querem após ver uma versão inicial do software ; </li></ul></ul><ul><ul><li>Requisitos mudam durante o processo de desenvolvimento; </li></ul></ul><ul><ul><li>Novas ferramentas e tecnologias tornam a estratégia de desenvolvimento imprevisível. </li></ul></ul><ul><li>Isso se aplica a diversos outros tipos de projeto </li></ul><ul><li>BDUF é considerado adequado apenas para projetos estáveis, com pouca ou nenhuma mudança . </li></ul>

10.
Um pouco de história... <ul><li>Se você ainda não conhece o problema, como especificá-lo corretamente? </li></ul><ul><li>Solução é usar o método: </li></ul><ul><ul><li>Cálculo Hipotético Utilizando Técnicas Estatísticas </li></ul></ul>

11.
Um pouco de história... <ul><li>Se você ainda não conhece o problema, como especificá-lo corretamente? </li></ul><ul><li>Solução é usar o método: </li></ul><ul><ul><li>C álculo H ipotético U tilizando T écnicas E statísticas </li></ul></ul>

12.
Um pouco de história... <ul><li>Se você ainda não conhece o problema, como especificá-lo corretamente? </li></ul><ul><li>Solução é usar o método: </li></ul><ul><ul><li>CHUTE </li></ul></ul>

13.
Um pouco de história... <ul><li>Questões importantes: </li></ul><ul><ul><li>Ainda existem projetos com pouca ou nenhuma mudança? </li></ul></ul><ul><ul><li>O que acontece quando um projeto com muitas mudanças é gerenciado da forma tradicional? </li></ul></ul><ul><li>“ A pior coisa que pode acontecer é o cliente receber exatamente aquilo que comprou” </li></ul>

14.
Um pouco de história...

15.
Um pouco de história... Fonte: Standish Group Chaos Report – Sucesso em Projetos de Software Recente pesquisa no Brasil com gerentes de projeto aponta a mudança de escopo (71%) como o fator principal para insucesso em projetos de software

16.
Agilidade

17.
Manifesto Ágil <ul><li>&quot;Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: </li></ul><ul><li>Indivíduos e interação entre eles mais que processos e ferramentas Software 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.&quot; </li></ul>2001 - representantes de processos leves de desenvolvimento de software se reuniram para discutirem o que seus processos possuíam em comum. O resultado foi o Manifesto Ágil :

18.
Princípios Ágeis <ul><li>Satisfação do cliente através da entrega rápida e frequente de produto funcional </li></ul><ul><li>Produto funcional é a principal medida de progresso do projeto </li></ul><ul><li>Mudanças são vistas como parte natural do processo e são bem-vindas </li></ul><ul><li>Cooperação diária entre a equipe de projeto e o pessoal de negócios </li></ul><ul><li>Comunicação aberta dentro da equipe </li></ul>

19.
Princípios Ágeis <ul><li>Equipe de pessoas motivadas, com o suporte necessário e confiança </li></ul><ul><li>Atenção contínua para o bom design e excelência técnica </li></ul><ul><li>Simplicidade. Nada de desperdícios! </li></ul><ul><li>Equipes autogerenciadas: Empowerment! </li></ul><ul><li>Foco maior nas pessoas do que nos processos </li></ul><ul><li>Melhoria contínua </li></ul>

21.
Aplicação <ul><li>Métodos Ágeis não servem apenas para desenvolvimento de software ! </li></ul>

22.
Aplicação <ul><li>Métodos ágeis podem ser utilizados em projetos em que há: </li></ul><ul><li>Ambiente de mudanças frequentes </li></ul><ul><ul><li>Requisitos </li></ul></ul><ul><ul><li>Tecnologia </li></ul></ul><ul><ul><li>Leis e regras </li></ul></ul><ul><li>Ambiente de i ncertezas </li></ul><ul><li>Necessidade de entrar rapidamente no mercado </li></ul><ul><ul><li>O portunidades </li></ul></ul><ul><ul><li>R esponder a uma ameaça </li></ul></ul>

23.
Aplicação <ul><li>Exemplos: </li></ul><ul><li>Alexandre Magno (CST): Scrum Executivo – mudança organizacional </li></ul><ul><li>Projetos de Publicidade/Marketing </li></ul><ul><ul><li>Ex: Accenda (http://grupoaccenda.com.br) </li></ul></ul><ul><li>Projetos de Hardware </li></ul><ul><li>Infra-estrutura </li></ul><ul><li>Jogos olímpicos, Copa do mundo… </li></ul>

24.
O que é Scrum?

25.
Scrum... <ul><li>...é um framework para desenvolvimento de produtos complexos em ambientes complexos; </li></ul><ul><li>...não é um processo ou técnica: dentro de Scrum podem-se empregar diversos processos e técnicas; </li></ul><ul><li>...utiliza abordagem iterativa e incremental para melhorar a predizibilidade e o controle de riscos; </li></ul><ul><li>...gera entrega frequente de valor para o cliente; </li></ul><ul><li>...torna transparentes problemas das práticas de desenvolvimento, para que se possa melhorá-las; </li></ul><ul><li>...utiliza inspeção e adaptação para melhoria contínua, em ciclos de feedback. </li></ul>

26.
Scrum: Origens <ul><li>Ken Schwaber: www.controlchaos.com </li></ul><ul><li>Jeff Suttherland: jeffsutherland.com </li></ul><ul><li>Mike Beedle: www.mikebeedle.com </li></ul><ul><li>“ The New New Product Development Game” , de Takeuchi e Nonaka </li></ul><ul><li>Sistema de Produção da Toyota: modelo enxuto e just-in-time </li></ul>

27.
Processos Definidos X Empíricos <ul><li>Processo definido </li></ul><ul><ul><li>Ambientes controlados – ex: linhas de produção </li></ul></ul><ul><li>Processo empírico: </li></ul><ul><ul><li>Complexos e imprevisíveis </li></ul></ul><ul><li>Scrum é embasado na teoria de controle de processos empíricos </li></ul><ul><li>Três pilares sustentam a teoria de controle de processos empíricos: Transparência, Inspeção e Adaptação </li></ul>

28.
Pilares

29.
Os Pilares do Scrum <ul><li>#1: Transparência </li></ul><ul><ul><li>Aspectos que afetam o resultado do projeto devem ser visíveis para os que gerenciam estes resultados </li></ul></ul><ul><ul><li>O que é visto deve ser compreendido : se quem inspeciona o processo acredita que está pronto, isso deve corresponder à definição de pronto utilizada </li></ul></ul>

30.
Os Pilares do Scrum <ul><li>#2: Inspeção </li></ul><ul><ul><li>Deve haver inspeção no processo com frequência suficiente para se detectar variações inaceitáveis </li></ul></ul>

31.
Os Pilares do Scrum <ul><li>#3: Adaptação </li></ul><ul><ul><li>Ao se detectar variações inaceitáveis, o processo deverá ser ajustado o tão rápido quanto possível para se minimizar desvios ainda maiores </li></ul></ul>

32.
Introdução ao Ciclo do Scrum

33.
O Ciclo do Scrum BACKLOG DO PRODUTO BACKLOG DA SPRINT REUNIÃO DIÁRIA INCREMENTO DO PRODUTO POTENCIALMENTENTREGÁVEL 2-4 SEMANAS 24 HORAS O representante do cliente, o PRODUCT OWNER, levanta com o cliente requisitos mais prioritários no momento Ele então insere estes requisitos em uma lista priorizada, chamada BACKLOG DO PRODUTO A equipe então se reúne com o representante do cliente e decide, a partir dessa lista de requisitos, o que será feito no próximo ciclo de desenvolvimento: o BACKLOG DA SPRINT A equipe faz o trabalho no ciclo de desenvolvimento, chamado de SPRINT Em cada dia, a equipe faz uma reunião de 15 minutos para promover visibilidade e comunicação Ao final do ciclo de desenvolvimento, a equipe terá produzido um incremento no produto, que significa valor para o cliente A equipe então se reúne com o representante do cliente na REUNIÃO DE REVISÃO e apresenta o que foi feito E, em seguida, se reúne para a RETROSPECTIVA, onde verifica o que funcionou bem e o que pode melhorar no próximo ciclo de desenvolvimento

34.
Papéis

35.
Papéis no Scrum <ul><li>ScrumMaster: </li></ul><ul><ul><li>responsável por garantir que o processo é entendido e seguido </li></ul></ul><ul><li>Product Owner: </li></ul><ul><ul><li>responsável por maximizar o valor, para o cliente, do trabalho que o Time de Scrum faz </li></ul></ul><ul><li>Time de Scrum: </li></ul><ul><ul><li>é a equipe, que faz o trabalho propriamente dito </li></ul></ul>

36.
Papéis no Scrum: O ScrumMaster <ul><li>Garante a adesão do time aos valores do Scrum, práticas e regras </li></ul><ul><li>Ajuda o Time de Scrum e a organização a adotarem o Scrum </li></ul><ul><li>Remove os impedimentos que atrapalham o trabalho do Time de Scrum </li></ul><ul><li>Ajuda o Time de Scrum a usar o auto-gerenciamento e a multidisciplinaridade, a ser mais produtivo e a ter mais qualidade </li></ul><ul><li>O ScrumMaster não gerencia o Time de Scrum: o Time de Scrum é auto-organizável </li></ul>

37.
Papéis no Scrum: O Product Owner <ul><li>Gerencia a lista de requisitos (Backlog do Produto) através do contato frequente com o(s) cliente(s), e garantir sua visibilidade a todos </li></ul><ul><li>Assegura o valor do trabalho realizado pelo Time de Scrum: garante o ROI do cliente </li></ul><ul><li>Gerencia a visão do produto: estabelece, mantém e comunica </li></ul><ul><li>Gerencia as entregas do produto para o cliente </li></ul><ul><li>É sempre uma pessoa, e não um comitê. Mas pode ser aconselhado/influenciado por outras pessoas </li></ul><ul><li>Suas decisões devem ser respeitadas: ninguém mais pode mudar as prioridades </li></ul>

38.
Papéis no Scrum: O Time de Scrum <ul><li>É a equipe de desenvolvimento do projeto, com 5 a 9 membros, que: </li></ul><ul><li>Transformam a lista de requisitos (Backlog do Produto) em incrementos de funcionalidades potencialmente entregáveis em cada iteração </li></ul><ul><li>São multidisciplinares: todo conhecimento necessário para gerar o incremento </li></ul><ul><li>Não há títulos no Time de Scrum </li></ul><ul><li>Gerenciam a iteração de desenvolvimento </li></ul><ul><li>São auto-organizáveis: ninguém diz ao Time de Scrum como transformar o Backlog do Produto em incrementos entregáveis. </li></ul>

39.
O Ciclo do Scrum

40.
Backlog do Produto BACKLOG DO PRODUTO BACKLOG DA SPRINT REUNIÃO DIÁRIA INCREMENTO DO PRODUTO POTENCIALMENTENTREGÁVEL 2-4 SEMANAS 24 HORAS O Product Owner levanta com o(s) cliente(s) os requisitos mais prioritários naquele momento O Product Owner insere estes requisitos no BACKLOG DO PRODUTO

41.
O que é o Backlog do Produto ? <ul><li>É uma lista incompleta e dinâmica dos requisitos do produto, ordenados por prioridade de desenvolvimento </li></ul><ul><li>A prioridade é determinada por: valor que gerará ao cliente naquele momento, risco e necessidade </li></ul><ul><li>Contém funcionalidades, correções de bugs, tecnologias e melhorias que constituem a mudança que será implementada no produto </li></ul><ul><li>O Product Owner é o responsável por atualizar, priorizar e dar visibilidade ao Backlog do Produto </li></ul><ul><li>Nunca está completo – evolui à medida que o produto e o ambiente evoluem </li></ul><ul><li>Seus itens possuem descrição e estimativa em pontos de esforço . Itens do alto da lista são de menor granularidade e mais detalhados </li></ul>

42.
Reunião de Planejamento da Sprint BACKLOG DO PRODUTO BACKLOG DA SPRINT REUNIÃO DIÁRIA INCREMENTO DO PRODUTO POTENCIALMENTENTREGÁVEL 2-4 SEMANAS 24 HORAS O Time de Scrum então se reúne com o Product Owner e decide, a partir do Backlog do Produto, o que será feito no próximo ciclo de desenvolvimento: o BACKLOG DA SPRINT

43.
O que é a Reunião de Planejamento da Sprint ? <ul><li>Planejamento da iteração: </li></ul><ul><ul><li>Time de Scrum e Product Owner defininem que itens do Backlog do Produto serão implementados na Sprint e os quebram em tarefas - Backlog da Sprint </li></ul></ul><ul><li>1a. Parte: O quê? </li></ul><ul><ul><li>Escolha de itens mais prioritários do Backlog do Produto a serem implementados </li></ul></ul><ul><ul><li>Definição da Meta da Sprint </li></ul></ul><ul><li>1a. Parte: Como? </li></ul><ul><ul><li>Time de Scrum quebra itens em tarefas e estima o tempo que levará para realizar cada tarefa </li></ul></ul>

44.
O que é o Backlog da Sprint ? <ul><li>Composto por uma lista dos itens que serão desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas </li></ul><ul><li>Os itens são selecionados do Backlog do Produto na Reunião de Planejamento da Sprint </li></ul><ul><li>Cada item é quebrado em tarefas. Parte das tarefas é definida no Planejamento da Sprint, parte ao longo do Sprint </li></ul><ul><li>O Backlog da Sprint é modificado ao longo da Sprint – estimativas são atualizadas, tarefas podem surgir para os itens já existentes </li></ul><ul><li>Deve ter alta visibilidade </li></ul><ul><li>Pertence ao Time de Scrum </li></ul>

46.
A Sprint BACKLOG DO PRODUTO BACKLOG DA SPRINT REUNIÃO DIÁRIA INCREMENTO DO PRODUTO POTENCIALMENTENTREGÁVEL 2-4 SEMANAS 24 HORAS O Time de Scrum faz o trabalho no ciclo de desenvolvimento, a SPRINT

47.
O que é a Sprint ? (1/2) <ul><li>Sprint é a iteração (ciclo) de desenvolvimento </li></ul><ul><ul><li>Reunião de Planejamento da Sprint </li></ul></ul><ul><ul><li>Trabalho de Desenvolvimento </li></ul></ul><ul><ul><li>Revisão e Retrospectiva da Sprint </li></ul></ul><ul><li>Cada Sprint deve ter uma Meta </li></ul><ul><li>Tem duração fixa (de 2 semanas a 1 mês) e ocorrem uma atrás da outra </li></ul><ul><ul><li>Duração deve contemplar horizonte curto suficiente para que mudanças não alterem a Meta </li></ul></ul><ul><li>ScrumMaster deve assegurar que não seja feita nenhuma mudança que afete a Meta da Sprint </li></ul>

48.
O que é a Sprint ? (2/2) <ul><li>Cada Sprint deve ter como saída um incremento do produto potencialmente entregável </li></ul><ul><li>A Sprint pode ser cancelada se a Meta da Sprint perder o sentido – somente Product Owner pode decidir </li></ul><ul><li>É muito raro a Sprint ser cancelada </li></ul>

49.
A Reunião Diária BACKLOG DO PRODUTO BACKLOG DA SPRINT REUNIÃO DIÁRIA INCREMENTO DO PRODUTO POTENCIALMENTENTREGÁVEL 2-4 SEMANAS 24 HORAS Em cada dia, o Time de Scrum faz uma reunião de 15 minutos para promover visibilidade e comunicação

50.
O que é a Reunião Diária ? <ul><li>Reunião de 15 minutos realizada todo dia no mesmo local, à mesma hora. </li></ul><ul><ul><li>Visibilidade </li></ul></ul><ul><ul><li>Comunicação </li></ul></ul><ul><ul><li>Decisão rápida </li></ul></ul><ul><li>Cada membro do Time de Scrum detalha: </li></ul><ul><ul><li>O que ele completou desde a última reunião diária; </li></ul></ul><ul><ul><li>O que ele vai fazer antes da próxima reunião diária; </li></ul></ul><ul><ul><li>Quais obstáculos estão em seu caminho. </li></ul></ul><ul><li>O ScrumMaster deve remover os obstáculos encontrados </li></ul><ul><li>O gráfico de BURNDOWN deve ser atualizado! </li></ul>

51.
O que é o Burndown da Sprint ? <ul><li>É um gráfico que mostra a soma dos tempos estimados restantes das tarefas da Sprint pelo tempo </li></ul><ul><ul><li>Y: tempos estimados restantes </li></ul></ul><ul><ul><li>X: dias da Sprint </li></ul></ul><ul><li>Serve para acompanhar o progresso em direção ao final de um sprint </li></ul><ul><li>É feito inicialmente no Planejamento da Sprint e deve ser atualizado a cada dia da Sprint </li></ul>

52.
Incremento no Produto BACKLOG DO PRODUTO BACKLOG DA SPRINT REUNIÃO DIÁRIA INCREMENTO DO PRODUTO POTENCIALMENTENTREGÁVEL 2-4 SEMANAS 24 HORAS Ao final da Sprint, o Time de Scrum terá produzido um incremento PRONTO no produto, que significa valor para o cliente

53.
O que significa Pronto ? <ul><li>Ao final da Sprint, o trabalho desenvolvido deve estar pronto </li></ul><ul><li>Mas o que significa “pronto”? </li></ul><ul><li>O Time de Scrum e o Product Owner devem definir o que significa “pronto” </li></ul><ul><li>Quando alguém diz que algo está “pronto”, todos devem entender o que isso significa </li></ul><ul><li>Ex. de software: codificado, testado e documentado </li></ul>

54.
A Reunião de Revisão da Sprint BACKLOG DO PRODUTO BACKLOG DA SPRINT REUNIÃO DIÁRIA INCREMENTO DO PRODUTO POTENCIALMENTENTREGÁVEL 2-4 SEMANAS 24 HORAS O Time de Scrum então se reúne com o Product Owner e apresenta o que foi feito na REUNIÃO DE REVISÃO DA SPRINT

55.
O que é a Revisão da Sprint ? <ul><li>Reunião onde o Time mostra aos stakeholders o que foi feito durante a Sprint: </li></ul><ul><ul><li>Product Owner presente </li></ul></ul><ul><li>Time de Scrum demonstra o que fez e responde a perguntas </li></ul><ul><li>Product Owner verifica o que foi e o que não foi feito na Sprint </li></ul><ul><li>Deve prover entradas para a Reunião de Planejamento de Sprint seguinte </li></ul>

56.
A Reunião de Retrospectiva BACKLOG DO PRODUTO BACKLOG DA SPRINT REUNIÃO DIÁRIA INCREMENTO DO PRODUTO POTENCIALMENTENTREGÁVEL 2-4 SEMANAS 24 HORAS E, em seguida, o Time de Scrum se reúne para a RETROSPECTIVA, onde verifica o que funcionou bem e o que pode melhorar na próxima Sprint

57.
O que é a Retrospectiva da Sprint ? <ul><li>Reunião para inspecionar como correu a Sprint com relação às pessoas, relacionamentos, processos e ferramentas: </li></ul><ul><ul><li>Product Owner não deve estar presente </li></ul></ul><ul><li>Identificar e priorizar: </li></ul><ul><ul><li>O que foi bem? </li></ul></ul><ul><ul><li>O que pode melhorar? </li></ul></ul><ul><li>Identificar ações para melhorias - adaptação </li></ul>

58.
E o ciclo recomeça... BACKLOG DO PRODUTO 2-4 SEMANAS

59.
Exercício d e Priorização

60.
Planejando um Hotel <ul><li>Formem grupos de até 5 pessoas </li></ul><ul><li>Escolham um membro do grupo para ser o Product Owner </li></ul><ul><li>O Product Owner representa os clientes (demais membros do grupo) que estão construindo um hotel </li></ul><ul><li>O Product Owner deve priorizar (do maior para o menor) os itens que devem fazer parte do seu hotel com base no desejo dos seus clientes </li></ul>

61.
Planejando um Hotel <ul><li>Itens disponíveis para priorização: </li></ul>Internet no Quarto Camareira / Arrumadeira Piscina Escada Estacionamento Elevador Quartos Quartos Recepção Restaurante Cozinha do Hotel

62.
Planejando um Hotel <ul><li>Agora imagine que durante a construção o dinheiro acabou assim que o 5 º I tem ficou pronto. </li></ul><ul><li>Pergunta: </li></ul><ul><ul><li>Os primeiros 5 itens são suficientes para tornar o hotel viável? </li></ul></ul>

63.
Scrum vs. Métodos Tradicionais

64.
Desperdício Metodologias não-ágeis afirmam que devem ser gerados inúmeros documentos para o sucesso do projeto Termo de Abertura Declaração Preliminar de Escopo Plano de Gerenciamento do Projeto Pedidos de Mudança Relatório de Progresso Relatório de Desempenho Relatório de Aceite Relatório de Encerramento Cronograma Detalhado Análise de Earned Value Documento de Lições Aprendidas Diagramas de Sequência Diagrama de Componentes Diagrama de Colaboração Diagrama de Estados Diagrama de Casos de Uso Diagrama de Pacotes Diagrama de Atividades ...algo mais? O custo de produção e manutenção destes documentos compensa? Quantos destes documentos se manterão atualizados ? Quantos serão realmente úteis para o desenvolvimento do projeto?

65.
Desperdício Fonte: Standish Group CHAOS Report <ul><li>35% dos requisitos mudam </li></ul><ul><li>65% das funcionalidades nunca ou raramente serão utilizadas </li></ul>Em projetos típicos, 50% do tempo é gasto com requisitos, arquitetura e especificação Análise de Requisitos Especificação / Arquitetura Implementação Testes Manutenção e isso tudo é feito antes de se construir qualquer funcionalidade! e para piorar...

66.
Desperdício Afinal, o objetivo do projeto é o produto , e não a documentação! Com Scrum, o projeto deve ter somente a documentação suficiente e necessária . Ou seja, adote somente o que será usado .

67.
Desperdício A documentação do projeto não pode roubar tempo e recursos do desenvolvimento do produto. A documentação do produto é importante e não pode ser deixada de lado. Atenção!!!

68.
Maior Valor Primeiro Em metodologias não-ágeis , o cliente só percebe retorno ao investimento no final do projeto . Entrega

69.
Mudanças Frequentes Em metodologias tradicionais, a mudança é fonte de estresse! Mudança é indesejada! Mudança é arriscada! Mudança é cara! Mudança deve ser negociada! Como quase todo o planejamento é feito no começo do projeto, há pouquíssimo espaço para mudanças !

70.
Mudanças Frequentes O contrato com escopo amarrado deve nos defender ! O cliente vai querer mudar tudo! Cada mudança deve ser negociada com o cliente! Seu impacto deve ser quantificado! Cada mudança deve ser revista , aprovada , planejada , documentada e gerenciada !

71.
Mudanças Frequentes Como o Scrum lida com a mudança ? Scrum encara a mudança como parte natural do processo de desenvolvimento Mudanças solicitadas pelo cliente podem ser introduzidas no produto na sprint seguinte ! A resposta rápida à mudança pode se transformar em vantagem competitiva !

72.
Comunicação Em um projeto tradicional , quando o cliente é encorajado a participar? Análise de Requisitos Especificação / Arquitetura Implementação Manutenção Testes

73.
Comunicação Em um projeto tradicional , quando o cliente é encorajado a participar? Análise de Requisitos Testes de Aceitação

74.
Comunicação Em um projeto tradicional , quando o cliente é encorajado a participar? Análise de Requisitos Testes de Aceitação O c liente percebe o projeto como uma grande caixa preta , cujo conteúdo será revelado apenas no final do processo

75.
Comunicação Assim, ao final do projeto, o resultado dificilmente atenderá às necessidades do cliente naquele momento!

76.
Comunicação Como o Scrum lida com a comunicação ? O Product Owner está em frequente contato com o cliente para levantar suas necessidades O cliente recebe frequentemente novas versões ... ...e assim pode mais rapidamente dar feedback para a equipe

77.
Comunicação A relação com o cliente deixa de ser meramente comercial , e passa a contemplar: Parceria Cumplicidade Satisfação Fidelidade E assim, cria-se uma relação de longo prazo com o cliente. O cliente se sente envolvido no processo, compartilhando a responsabilidade

78.
Comunicação Em metodologias não-ágeis , como se promove a visibilidade no projeto para seus stakeholders ? Principalmente através de documentação ... ...que dá muito trabalho ...que não é eficiente ...que não se mantém atualizada ...que acaba deixada de lado Termo de Abertura Declaração Preliminar de Escopo Plano de Gerenciamento do Projeto Diagrama de Pacotes Relatório de Progresso Relatório de Desempenho Relatório de Aceite Relatório de Encerramento Diagrama de Atividades Análise de Earned Value Documento de Lições Aprendidas Diagramas de Sequência Diagrama de Componentes Diagrama de Colaboração Diagrama de Estados Diagrama de Casos de Uso Pedidos de mudança Cronograma Detalhado

79.
Comunicação No Scrum , a visibilidade no projeto é constantemente promovida! Reuniões diárias Kanban Equipe em um mesmo ambiente Envolvimento do cliente Gráficos de Burndown Entregas frequentes Reunião de Revisão Retros- pectiva ...são alguns exemplos.

80.
Scrum na Petrobras Case de Sucesso

81.
Obrigado! Rafael Sabbagh [email_address] Marcos Garrido [email_address]