Métodos Ágeis de Gerência de Software

Transcrição

1 Métodos Ágeis de Gerência de Software Rodrigo de Toledo (CSM) 10 maio 2008 (Formação)

2 Plano Introdução: Motivação Histórico Princípios Scrum: Scrum flow Personagens, artefatos e meetings Prática: Velocity, Sprint, Review Aplicações, mitos e restrições Conclusão: Metodologias ágeis no mundo Scrum e CMMI Metodologias ágeis na Petrobras Hoje, a curto prazo e a longo prazo

3 Introdução

4 Motivação Métodos Ágeis Metodologias apropriadas a essa nova ciência: a engenharia de software O que tem de tão interessante: Processos iterativos, people-oriented, Cross-functional teams, inspeção/adaptação, Alta produtividade (4 a 10 vezes maior) Satisfação de todos: clientes, usuários, gerentes e desenvolvedores

5 Motivação Métodos Ágeis Mudanças de paradigma

6 Termos Métodos Ágeis: se contrapõem às metodologias de engenharia clássica, geralmente aplicados ao desenvolvimento de software. Ex: XP, Scrum, Crystal, Lean (RUP?)... Iteração: Etapas curtas (2 a 4 semanas) de planejamento/desenvolvimento. O processo iterativo se contrapõem ao processo em cascata. Adaptação: Passa a ser a verdadeira opção à natureza imprevisível do desenvolvimento de software. Troca-se o par planejamento/controle por inspeção/adaptação. Self-organization: As pessoas são responsáveis pelo seu próprio trabalho. (people-oriented x process-oriented) Time-box: Todas as etapas devem estar contidas no seu tempo e isso é mais importante que a completude do escopo.

7 Motivação - Caos Desenvolvimento caótico Code and fix ou Quick and dirty Um cara só faz tudo - generalista Imprevisível Pode funcionar para aplicações pequenas Pontos negativos: Dono do código Baixo reuso Dificuldade para manutenção...

8

9 Motivação - Engenharia Metodologias de engenharias Eng. de sw é muito nova comparada com as demais Por que não usar outras metodologias clássicas? Eng. Civil, mecânica, aeronáutica... Planejamento Implementação Linha de montagem Cada etapa tem um responsável diferente - especialistas Benefícios: Gerenciamento facilitado (pessoas são peças) Reuso possível Mais formalidade no relacionamento com o cliente

10 Motivação - Engenharia Metodologias de engenharias Questionamentos: Esforço no planejamento é muito maior que nas outras engenharias É previsível? Desenvolvimento de sw é considerado a atividade mais complexa do ser humano. Pontos negativos: Software não é prédio Perda de flexibilidade Falsas verdades

11 Motivação - Engenharia Construir software NÃO É igual a construir prédio Metáforas são perigosas (mas quase inevitáveis) Nosso peão é um arquiteto (criativo, artista) Desde a primeira prova de programação Peão feliz/infeliz (muro/igreja) Se derrubar uma parede errada, basta fazer um ctrl+z Falta um tijolo no prédio falta um ; no código Não estamos presos a leis físicas (e.g., gravidade) Mudanças tecnológicas maiores em impacto e freqüência.

12 Motivação - Engenharia Perda de Flexibilidade Mudanças externas constantes Decorrentes da imprecisão dos requisitos Falha de quem está levantando Incapacidade do cliente em detalhar (ex: construção customizada de um carro) Frase comum: o problema deste projeto é que os requisitos vivem mudando Decorrentes das mudanças do negócio

13 Motivação - Engenharia Perda de Flexibilidade (Jeff Sutherland et al. 08) Ziv s Uncertainty Principle: Uncertainty is inherent and inevitable in software development processes and products Humphrey s Requirements Uncertainty Principle: For a new software system the requirements will not be completely known until after the users have used it. Wegner s Lemma: It is not possible to completely specify an interactive system

14 Motivação - Engenharia Mitos sobre as metodologias de engenharia: Esforço maior apenas no início do projeto Pessoas são apenas peças do processo Quanto mais informação escrita melhor Previsibilidade Processos criativos não são fáceis de planejar ((A engenharia de software é ao mesmo tempo uma ciência precisa/matemática e um exercício criativo/humano)) Pior ainda: Fingir que é previsível Documentos que não são lidos Documentos para descrever como algo será feito escritos depois desse algo feito Fim do projeto! Bom projeto tem fim? O que é um produto de sucesso? No prazo, no custo e de acordo com o plano Não Maior Business Value

15 Video

16 Histórico Métodos Ágeis Anos 80 (qualidade) Nonaka e Takeuchi: Toyota, Xerox, 3M, Fujifilm... Knowledge Management Papers: The New New Product Development Game, 1986 The knowledge-creating company Algumas histórias ou lendas: Força tarefa japonesa Grupo de consultoria (Toyota consulting) Qualidade começou anos 70 com americano SmallTalk (Xerox, 1980) OO, metaclasses, dev. environment, virtual machine (1983), unit test

17 Histórico Métodos Ágeis Anos 90 (Eng.Sw.) XP (Kent Beck e Ron Jeffries, ~97) 5 valores, 14 princípios, 24 práticas Outra lenda: Kent Beck desafia QA s (GQS) em 2001 TDD Scrum (Jeff Sutherland, Ken Schwaber, Mike Beedle 93~95~99) Mais gerencial que XP Crystal (Alistair Cockburn) Coleção de métodos Mais flexível que XP Lean (from manufacturing)

18 Histórico Métodos Ágeis Anos 2000 Grande divulgação Diversos exemplos de uso 2001 Agile Manifesto Agile Alliance Últimos anos Google, Yahoo, Borland, Sega (todas as grandes empresas de jogos), MS

19 Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick

20 Principles behind the Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from selforganizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

21 Video Mr. Walter Falls and A. Giles

22 About SCRUM Sprint Done Product Backlog Selected Backlog Visibility Story Points Sprint Backlog Stand-up Meeting Retrospectives Burn-down Chart Task Board Product Owner Planning POKER Scrum Master Time Box Team

23 SCRUM

24 Scrum Metaprocesso (framework) Metodologia que diz que metodologias não são tão importantes Adaptável 1ª regra: as regras podem ser alteradas* Promete alta qualidade software robusto Promete alta produtividade 4 a 10 vezes mais produtivo Mais business value ou valor agregado * Existem algumas pré-condições

25 Scrum Primeiros Conceitos Sprint: iteração período de 2 a 4 semanas de trabalho da equipe Daily sprint: 1 dia de trabalho da equipe Product backlog: Lista de requisitos em formato user-story Ordenada por prioridade Selected backlog: Lista de tarefas a serem realizadas durante a sprint Baseada nas maiores prioridades do product backlog De acordo com a capacidade da equipe em uma sprint

26 Scrum

27 Scrum - Personagens

28 Scrum - Personagens Apenas três Não tem relação direta com cargos e hierarquias Product Owner Time Scrum Master

29 Scrum - Personagens Product Owner Fornece a visão do negócio Mantém os itens do product backlog atualizados e priorizados A cada início de sprint auxilia a elaborar o selected backlog Maximiza ROI ("valor agregado") Aceita ou rejeita o que foi produzido Alta participação em início e fim de sprints Disponível para esclarecer dúvidas

30 Scrum - Personagens Scrum Master Facilitador Não tem autoridade Conduz reuniões e eventos Mantém o Scrum funcionando Remove empecilhos e obstáculos Presta serviço ao time Protege o time Ajuda o time nas suas tarefas Ajuda o product owner nas suas tarefas

31 Scrum - Personagens Time Multidisciplinar sem papéis específicos Auto-gerenciado de 5 a 9 pessoas Comprometido com o objetivo e consigo mesmo esforçado, pontual etc. Autoridade para fazer o que for necessário para atingir o objetivo Comunicação constante transparência e diálogo

32

33 Scrum - Comprometimento Comprometimento x Envolvimento Porcos e galinhas Às vezes somos porcos, às vezes galinhas

34 Scrum - Princípios

35 Scrum - Princípios Processo iterativo e incremental (1/6) Modelo Tradicional NA TEORIA Modelo Ágil NA PRÁTICA

36 Scrum - Princípios Processo iterativo e incremental (1/6) Benefícios: confiabilidade do software antecipação de valor agregado aumento de confiança do cliente motivação do time Manifesto Ágil: devemos valorizar mais SOFTWARE FUNCIONAIS do que documentações extensas.

37 Scrum - Princípios Auto-organização (2/6) Acreditar na competência das pessoas O time tem capacidade de se autoorganizar Tarefas não devem ser atribuídas autoritariamente, mas voluntariamente pull tasks, not push atribuições ocorrem diariamente Manifesto Ágil: devemos valorizar mais INDIVÍDUOS e INTERAÇÕES que processos e ferramentas

38 Scrum - Princípios Comunicação (transparência) (3/6) Através de reuniões diárias a comunicação é feita pessoalmente Controles visuais Reuniões regulares de retrospectiva A cada mudança de sprint Verificação de obstáculos Melhora contínua Problemas vêem rapidamente a superfície group programming (collective code ownership) Resultado das atribuições diárias e Equipes cross-functional (especialista-generalista)

39 Scrum - Princípios Time-box (4/6) O tempo da sprint é mandatório (assim como qualidade) Qualidade Todos os meetings tem tempo fixo: Daily-meeting Sprint Planning Etc... Único que pode alterar Fixos custo/esforço Tempo Escopo

40 Scrum - Princípios Menos planejamento, mais ação (5/6) Retardar decisões Por causa da complexidade Não há conflito com: "não deixe para amanhã o que pode ser feito hoje" Um é ação e outro é planejamento Retardar uma decisão e retomá-la apenas no momento apropriado: cenário mais atualizado novas prioridades mais conhecimento sobre as condições Manifesto Ágil: devemos valorizar mais REAGIR A MUDANÇAS do que seguir um plano.

41 Scrum - Princípios Menos planejamento, mais ação (5/6) Mais código e menos documentação prévia Manifesto Ágil: devemos valorizar mais SOFTWARE FUNCIONAIS do que documentações extensas. REPETINDO Planejamento Fibonacci (1,1,2,3,5,8,13,21...) Escala progressiva Detalhes do planejamento devem ser inversamente proporcionais à distância no tempo Scrum tem 3 escalas: projeto, sprint, dia Não discutir muito o processo: Tentar primeiro e melhorar para a próxima sprint

42 Scrum - Princípios Cliente é um parceiro (6/6) Participação ao longo do projeto Acompanhamento mensal Disponibilidade para dúvidas Mudanças de requisitos são bem-vindas a qualquer momento Manifesto Ágil: devemos valorizar mais COLABORAÇÃO COM O CLIENTE do que negociação de contratos.

43 Scrum Phases Diferença entre estratégia e tática Já vimos: Product Backlog Selected Backlog Falta vermos: User story Story point Task e Sprint Backlog Task Board Burn-down Chart

44 Scrum Flow

45 Scrum - Artefatos

46 Scrum Artefatos User Story (backlog items) Product e Selected Backlogs são compostos por user stories. Campos: ID, Título (ou descrição sucinta) Valor Valor medido pelo product owner (business value) Não precisa ter valores absolutos, podem ser relativos Story points Descrição mais detalhada Suficiente para compreensão de time Pode ser uma descrição da interação com o usuário ou uma prévia da lista de tarefas Outros possíveis campos: Me <name>, as <user role>, would like to <feature>, so that <value> Sprint number How to demo

47 Scrum Artefatos Story Points Medida de esforço de implementação Associado a cada story Valores concretos ou relativos? Pode ser associado a uma referência concreta ex: Homem-dia de trabalho Pode ser simplesmente um valor relativo Ex: Escolhe-se a story mais simples e pontua com valor 2 Usa-se uma série adaptada de Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40 e 100 Medida para determinar a VELOCITY da equipe

48 Scrum Artefatos Tasks Cada story deverá ser quebrada em tarefas Idealmente, tarefas correspondem a 1 dia de trabalho São a menor unidade de divisão Cada tarefa vira um Post-it As atribuições das tarefas às pessoas ocorre diariamente Sprint Backlog Conjunto de tasks de cada uma das stories da sprint corrente

49 Scrum Artefatos Task Board

50 Scrum Artefatos Task Board To do, doing, done Conceito de DONE Pode ter outras colunas, exemplos: commited reviewed Burn-down chart Outros conteúdos: Post-it chart Limbo Impediments Notícias Mesa retrátil

51 Scrum Artefatos Burn-down Chart São dois: Por sprint Produto completo Contagem de pontos Pontos parciais das stories Total de pontos da story

52 Scrum - Meetings

53 Scrum - Meetings São 6 diferentes meetings MEETINGS... Daily meetings Daily meetings Sprint i Sprint i +1 Estimation Review Retrospecitve Estimation Sprint Planning 2 Sprint Planning 1 Obs: São permitidos observadores externos (mas galinhas não tem voz)...

54 Scrum - Meetings Sprint Planning 1 Material: Product backlog atualizado, priorizado e estimado. Informações práticas sobre próximo sprint pessoas, tempo de sprint etc. Envolvidos: Product owner + time + scrum master Objetivo: Definir sprint backlog Procedimento: sprint backlog é preenchido com os itens de maior prioridade do product backlog até completar o número de story points correspondente a velocity do time. O product owner poderá então propor alterações para incluir, excluir e alterar o escopo das stories. Freqüência: todo início de sprint

55 Scrum - Meetings Sprint Planning 2 Material: Sprint backlog priorizado e detalhes do sprint (incluindo o objetivo). Informações práticas sobre próximo sprint (pessoas, tempo de sprint etc.). Envolvidos: Time + scrum master (+ product owner) Objetivo: Definir tarefas de cada story do sprint. Procedimento: Divisão das stories em tarefas de 1 dia, criando post-its para a coluna to do do VRSIVIEP:painel de tarefas. Lembrar que as tarefas devem incluir: Aprendizado de tecnologia desconhecida Programação Teste Code review Documentação Freqüência: todo início de sprint

56 Scrum - Meetings Planning Poker ou Estimation meeting Envolvidos: time Material: cartas do planning poker com os valores: Procedimento: 1. Identificar no product backlog o item que o time julga ser o de menor esforço e pontuamos como A partir do product backlog fazemos um "pre-selected" backlog com os itens mais urgentes na visão do prod. owner, ou seja, Luciano+Ismael. Para cada item: 4. Lemos a story relativa ao item e verificamos se não há desentendimento. 5. Fazemos uma rodada de PP entre os membros do time. 6. Os membros que tiverem dado menor e maior valores fazem uma breve defesa do porque. Repetimos itens 4 e 5 até convergir 8. O valor é associado ao item, você pode verificar naquele arquivo sprint1.txt que passei para você os valores atribuídos aos 9 itens do sprint1. Freqüência: algumas poucas vezes e de maneira rápida ao longo do sprint

57 Scrum - Meetings Daily meetings ou Satand-up meetings ou Scrum meetings Envolvidos: time. Material: Painel de tarefas; post-it; canetas. Procedimento: De pé, máximo de 15 minutos, não é para discutir/resolver problemas 3 perguntas atualizando o Task Board: o que eu fiz ontem? o que farei hoje? tenho algum empecilho? Sincronização de conhecimento atualização do burn-down Freqüência: diária

58 Scrum - Meetings O que eu fiz ontem? O que vou fazer hoje? Tenho algum obstáculo? 1 2 3

59 Scrum - Meetings Retrospective Material: informações do VRSIVIEP:painel de tarefas já organizados. post-its e flip-chart Envolvidos: Time, scrum master (+ product owner) Objetivo: Rediscutir o processo de desenvolvimento (visando sua melhora) Procedimento: Repassar a sprint cronologicamente 5 min de WWWs (What Went Well & What Went Wrong) em post-it Discutir os itens organizando o impediment backlog who is in control?. Fechamento: cada individuo faz sua conclusão (Se a retrospective for anterior a review, pode-se preparar a review com o time.) Freqüência: a cada fim de sprint

60 Scrum - Meetings Review Material: informações do painel de tarefas Envolvidos: time + scrum master + product owner Objetivo: Revisar último sprint e andamento global do projeto Procedimento: Revisar detalhes da última sprint: objetivo, stories, burndown chart etc. Demo do último incremento do projeto. Pode incluir a demonstração de documentos e outros. (Se a review for posterior a retrospective, pode-se discutir impediments) Freqüência: a cada fim de sprint

61 Scrum Flow

62 Ainda sobre SCRUM Sprint, um resumo Done, Velocity Infraestrutura Escalabilidade Aprendizado Exemplo Prático

63 Scrum - Sprint Sprint, um resumo Iteração de 2 a 4 semanas Termina com uma deployable version Não pode ter sua data postergada O que fazer se atrasar? A descrição da sprint deve conter: Data início e fim Pessoas envolvidas (time) Objetivo Total de pontos Sprint backlog Botão Vermelho

64 Gráfico de Baleia Requerimentos Projeto Código Teste Ao invés de completar uma coisa por vez equipes Scrum fazem um pouco de cada coisa, todo o tempo.

65 Scrum - DONE Design Codificação Unit-test Code review Refactoring Comentado Commited Documentado Deve estar bem acordado com o time

66 Scrum - Velocity Velocity Como calcular

67 Jogo das bolas Um único time As bolas devem passar por todos Bolas devem ser passadas ficando um tempo no ar Não podem ser passadas ao vizinho Mesmo ponto de início e fim 2 minutos por sprint 1 minuto para retrospectiva/review 5 iterações

68 Scrum Suporte Tecnológico Teste Unitário J-Unit Cpp-Unit NUnit Integração Contínua Hudson Scons Wiki (Visibilidade) Confluence Subversion TortoiseSVN Acompanhamento de issues Jira

69

70

71

72 Escalabilidade Times de 7 ± 2 pessoas Pode ser escalável Scrum of Scrum Ken Schwaber Diversas vezes implementou para centenas de desenvolvedores Mike Cohn Implementou para mais de 1000 Faz uso genérico do Scrum (além de des. de sw) Próximo objetivo: + de pessoas

73 Scrum of Scrum

74 Scrum of Scrum

75 Scrum - Relatórios Product backlog a cada sprint Análise das diferenças Análise de desempenho Burn-down charts, velocity Ações de melhorias realizadas

76 Scrum - Aprendizado Group programming Especialistas compartilham sua experiência Retrospective Todos aprendem sobre o processo e como melhorá-lo Essa é a explicação de porque os métodos ágeis se tornaram tão bons

77 Exemplo Prático - SiVIEP Sistema de Visualização Integrado de E&P Alta complexidade de requisitos: Multi-plataforma Realidade Virtual Renderização distribuída Interação com dispositivos 3D Suporte a grafo de cena Som 3D Cluster Distribuído Arquitetura de componentes Plug-in Acesso as funcionalidades via script Open source Plataforma de desenvolvimento para outras universidades Browser 3D

78 Exemplo Prático - SiVIEP Um pouco mais de ano de projeto antes do Scrum 5-6 pessoas ±10 sprints realizadas

79 Plataforma (PNA-I) Plataforma (PNA-II) Poços Reservatório Falhas da Superfície

80

81 Exemplo Prático - SiVIEP Adaptações do Scrum no SiVIEP: 3 dias úteis de trabalho por semana Estimation meeting acontece em conjunto com sprint planning 1 Limbo + Prod. Backlog candidates mesa retrátil Post-it chart (cor diferente para post-it novo) Inversão entre retrospective e review

82 PROCESSO CONVENCIONAL Meetings Daily meetings... 1 day 1 day Sprint i Estimation Review Retrospecitve Pontos positivos: Participação do Prod. Owner em 1 único dia Apenas 1 dia sem produção... Pontos negativos: - retrospective antes da review - Estimation na frente do prod. Owner Daily meetings Sprint i Estimation Sprint Planning 2 Sprint Planning 1 PROCESSO SIVIEP Meetings Daily meetings Sprint i 1 day Daily meetings Sprint i +1 Estimation Review Retrospecitve Sprint Planning 2 Sprint Planning 1.

83 Exemplo Prático V3O2 E&P Projeto antigo com diversos usuários ± 8 sprints realizadas 2 times de 5 pessoas (± scrum of scrum)

84 Tópicos para discussão Pontos negativos CMMI Futuro

85 Pontos negativos dos Métodos Ágeis Para times com pessoas experientes Ken Schwaber diz que funciona para idiotas Processo exigente, trabalha-se muito Google compensa com o esquema Perda de flexibilidade no horário Como tratar especialistas em equipes multidisciplinares? Como fazer o contrato (preço e escopo)? Como auditar e certificar? Atenção! Cuidado com os falsos mitos negativos: Só serve para grupos pequenos (FALSO) Não gera documentação (FALSO)

86 Contratos Fixed price / fixed date or Latest date / maximum cost Já existem diversos modelos de contrato prontos

87 Scrum & CMM Level 2: Christ Vriens, Certifying for CMM Level 2 and ISO9001 with XP@Scrum, May 2002 Ken Schwaber Primeira experiência ruim: Sistema web para um grande banco (CMM level3, há 3 anos), 1997 Encontro com Mark Paulk, 2002 Descobriu que o SCRUM já era CMM level 2 quase , fez pequenos ajustes para tornar SCRUM em CMM level 3 Jeff Sutherland Se tornou especialista em CMM (em conjunto com o Scrum) Certificou algumas empresas em CMMI com Scrum J Sutherland et al., Scrum and CMMI Level 5: The Magic Potion for Code Warriors, 2008

88 Scrum and CMMI Level 5 Establish and maintain an organizational policy for planning and performing Agile Methods Establish and maintain the plan for performing Agile Methods Provide adequate resources for performing Agile Methods Assign responsibility and authority for performing Agile Methods Train the people performing Agile Methods Place designated work products under appropriate level of configuration management Identify and involve the relevant stakeholders as planned Monitor and control Agile Methods against the plan and take appropriate corrective action Objectively evaluate adherence to the Agile Methods and address noncompliance Review the activities, status, and results of the Agile Methods with higher-level management and resolve issues Establish and maintain the description of Agile Methods Collect the results from using Agile Methods to support future use and improve the organization s approach to Agile Methods

89 Falhas no CMMI (corrigidas pelo Scrum) Respeita processos mas ignora pessoas Não foca em problemas organizacionais internos Associa erradamente qualidade de produto à qualidade do processo. (O que é um produto de sucesso?) Não é business-oriented Ignora infra-estrutura técnica e organizacional Foca em eficiência interna e ignora a competitividade externa

90 Métodos Ágeis aplicados no mundo Empreas Google, Yahoo, Microsoft, Electronic Arts, High Moon Studios, Lockheed Martin, Philips, Siemens, Nokia, Capital One, BBC, Intuit, Nielsen Media, First American Real Estate, BMC Software, Ipswitch, John Deere, Lexis Nexis, Sabre, Salesforce.com, Time Warner, Turner Broadcasting, Oce. Como introduzir: Ken Schwaber: democraticamente (bottom-up) Jeff Sutherland: institucionalmente (top-down) Mike Cohn: ambos os métodos são interessantes Mark Striebeck at Google: Ssh! We Are Adding a Process..., 2006

91 Métodos Ágeis aplicados no mundo Cenário ideal para começar: Grupo pequeno (<10) Projeto complexo Time interessado Product owner disponível Perfil ideal das empresas: Empresas que valorizam o bem-estar dos funcionários Informais Respeitem as horas de trabalho dos funcionários Pequenas ou grandes empresas (de software) Vocês conhecem alguma empresa assim?

92 Métodos Ágeis aplicados na Petrobras Justamente por essas características, a Petrobras proporciona boas possibilidades de uso Ágil Hoje Existem algumas iniciativas Mais por parte das prestadoras de serviços Escolher projetos mais propícios (E&P, CENPES...) Pouco desenvolvedores crachá verde Curto Prazo Nós podemos mudar o cenário (agora todos os 40 são ágeis) Deve ser feito democraticamente (ou não?) Longo Prazo Metodologia Agil (além de OO, R/3 etc...) Associar a CMMI?

93 Futuro dos métodos ágeis É possível usar SCRUM para outros desenvolvimentos que não sejam software? Essa pergunta me ocorre desde o meu curso de CSM Recentemente, no TMCE 2008: Agile PDM-implementation, Jörg Feldhusen, Frederik Bungert, Manuel Löwer Caso de uso na engenharia mecânica

94 Referências Sobre o SCRUM (by Ken Schwaber) Ken Schwaber e Mike Beedle Sobre a prática do Scrum Ken Schwaber Implementação do Scrum em diversas empresas Quase um romance Ken Schwaber pretendo ler

95 Referências Da Internet Jeff-Sutherland-7-Ways-To-Fail-With-Scrum.pdf Agile Project Management Sobre liderança ágil Scrum from the trenches Experiência de uso do Scrum em uma empresa na Suécia Altamente recomendável para quem está implementando Scrum pela primeira vez "Ssh! We are adding a process, Scrum na Google

96 Referências Outras: Nonaka e Takeuchi: The New New Product Development Game, 1986 The knowledge-creating company, 1995, 8000 referências ( para versão japonesa) Jeff Sutherland: Scrum and CMMI Level 5: The Magic Potion for Code Warriors, 2008 Agile development: lessons learned from the first scrum, 2004 Sobre implementação do Scrum em 1993

97 Agradecimentos Turma UP2*, AS-ES Uanderson Marcio Mascarenhas Saulo (videos) Dani e Carol Tecgraf