Agilidade com Responsabilidade - Agile Day 2008 - POA

1,935 views
1,787 views

Published on

Palestra proferida pelo Heptaman no Agile Day 2008, em Porto Alegre-RS

Published in: Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,935
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
64
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Agilidade com Responsabilidade - Agile Day 2008 - POA

  1. 1. Agilidade com Responsabilidade Engº Adail Muniz Retamal adail@heptagon.com.br
  2. 2. Roteiro © 2008
  3. 3. Teoria das Restrições Israel/EUA Aplicações Origem Eliyahu M. Goldratt • Manufatura, Logística • Cadeia de Suprimentos “A Meta”, 1984 • Marketing, Vendas • Gerenciamento de Projetos • TI, Operações, Educação • Hospital, Governo TOC Estratégia & Tática Processo de 1. O que mudar? Melhoria Contínua 2. Para o que mudar? Princípios e 3. Como causar a mudança? Ferramentas de 4. E o que garante a MCP? 1. Identificar Raciocínio 2. Explorar 3. Subordinar 4. Elevar • Premissas 5. Voltar a 1 (inércia!) • ARA, EN, ARF, RN, APR, AT, E&T • Medidas de Desempenho © 2008
  4. 4. O Que Mudar? © 2008
  5. 5. Processo de Produção Processo de Produção Idéias e Entender Pensar Fazer Necessidades o que fazer como fazer Produto Verificar o que foi feito Processo de Produção de Software Requisitos Análise Desenho Construção (Design) Erro Erro Erro Testes de Testes de Testes Produto Aceitação Integração/Sistema Unitários © 2008
  6. 6. Má Qualidade O produto não atende às O Que Mudar? A Realidade Atual Falta de Confiabilidade Não poder contar com as expectativas do cliente Inflexibilidade Incapacidade de promessas da equipe acompanhar as mudanças Para tentar cumprir prazo e/ou custo, corta-se escopo, testes, documentação O produto fica Os projetos inchado, complexo O negócio e o atrasam Falta de Visibilidade e inflexível aprendizado Não saber como está são dinâmicos o projeto/produto Lei de Parkinson, Há funciona- Gostamos de arquitetar Síndrome do Noção errônea de p/ o presente e p/ o futuro lidades que não Estudante, Multitarefa valor gera conflitos (real ou imaginário) agregam valor de prioridades Os requisitos Há pressão para se Os clientes pedem Forçamos os clientes devem ser cumprir as tarefas tudo o que imaginam a pedirem tudo o que “congelados” no prazo prometido que vão precisar querem no início do projeto Estimativas são Exigimos estimativas tomadas como precisas para a Adotamos o ciclo compromissos duração das tarefas de vida em série Devemos evitar (cascata) mudanças nos planos Detalhamos bem o Queremos um forte cronograma do projeto, controle sobre o até ao nível das tarefas escopo, prazo e custo © 2008
  7. 7. Má Qualidade O produto não atende às Falta de Confiabilidade Inflexibilidade expectativas do cliente Não poder contar com as Incapacidade de promessas da equipe acompanhar as mudanças Para tentar cumprir prazo e/ou custo, corta-se escopo, testes, documentação O produto fica Os projetos inchado, complexo O negócio e o atrasam Falta de Visibilidade e inflexível aprendizado Não saber como está são dinâmicos o projeto/produto Lei de Parkinson, Há funciona- Gostamos de arquitetar Síndrome do Noção errônea de p/ o presente e p/ o futuro lidades que não Estudante, Multitarefa valor gera conflitos (real ou imaginário) agregam valor O projeto demora e custa de prioridades Há pressão para se mais que o prometido, e Os requisitos Os clientes pedem Forçamos os clientes devem ser cumprir as tarefas tudo o que imaginam a pedirem tudo o que no prazo prometido entrega menos e pior do que vão precisar querem no início do “congelados” projeto que se esperava Estimativas são Exigimos estimativas tomadas como precisas para a Adotamos o ciclo compromissos duração das tarefas de vida em série Devemos evitar (cascata) mudanças nos planos Detalhamos bem o Queremos um forte cronograma do projeto, controle sobre o até ao nível das tarefas escopo, prazo e custo © 2008
  8. 8. O Conflito da Empresa? Meta Necessidades Ações/Vontades B D Responder às mudanças mais rápido Ser ágil A que a concorrência Continuar lucrando, mesmo num ambiente turbulento de negócios Satisfazer os clientes com promessas Ser responsável confiáveis C D’ © 2008
  9. 9. O Conflito do Desenvolvedor de Software? Meta Necessidades Ações/Vontades D B Sentir o gosto do Implementar “coisas desafio legais” de se fazer A Ser um desenvolvedor feliz (motivado e empregado) Manter-se Implementar o que é necessário importante para o na empresa negócio C D’ © 2008
  10. 10. Processo de Produção Processo de Produção Idéias e Entender Pensar Fazer Necessidades o que fazer como fazer Produto Verificar o que foi feito Processo de Produção de Software Requisitos Análise Desenho Construção (Design) Erro Erro Erro Testes de Testes de Testes Produto Aceitação Integração/Sistema Unitários © 2008
  11. 11. Estratégias de Desenvolvimento Requisitos Em cascata Requisitos (waterfall) Análise Desenho Versão 2 Teste Análise Versão 1 Construção Teste Entrega Incremental Requisitos Análise Análise Construção Desenho Desenho Desenho Construção Construção Teste Teste Evolucionário Entrega © 2008
  12. 12. Tecnologia: Necessária, Mas Não Suficiente A tecnologia pode trazer benefícios se e somente se ela diminui uma limitação. Muito antes da tecnologia estar disponível, nós desenvolvemos modos de comportamento, Eliyahu Goldratt políticas, métricas e regras para Criador da Teoria das Restrições nos ajudar a acomodar à limitação. © 2008
  13. 13. Tecnologia: Necessária, Mas Não Suficiente A nova tecnologia é implantada, mas os benefícios não aparecem As pessoas continuam se comportando sob as mesmas regras A nova tecnologia As regras estão “na Uma nova tecnologia tem o potencial para As regras não são veia” das pessoas e é proposta para diminuir a limitação reavaliadas da organização melhorar a operação A operação já Nós desenvolvemos existe há algum regras para operar tempo com a limitação Nós temos uma Nós temos uma operação limitação © 2008
  14. 14. Para O Que Mudar? © 2008
  15. 15. Agilidade! a.gi.li.da.de sf (lat agilitate) 1. Qualidade do que é ágil. 2. Desembaraço, ligeireza, presteza de movimentos. 3. Mobilidade, perspicácia, vivacidade. Geralmente associa-se Agilidade com: – Rapidez, Flexibilidade, Leveza – Resumo: Habilidade para mudar m P = m.g © 2008
  16. 16. Responsabilidade Processo de Responsabilidade™ RESPONSABILIDADE cristopherAVERY.com OBRIGAÇÃO DESISTIR VERGONHA Nenhum aprendizado JUSTIFICAR pessoal ocorre aqui. CULPAR PROBLEMA NEGAÇÃO © 2008
  17. 17. Os 7 Hábitos das Pessoas Altamente Eficazes Conhecimento O que fazer? Por que fazer? Stephen Covey Hábitos Habilidade Desejo Como fazer? Querer fazer © 2008
  18. 18. Os 7 Hábitos das Pessoas Altamente Eficazes Dependência 1. Seja proativo Vitória Particular 2. Comece com o objetivo em mente 3. Primeiro o mais importante Independência 4. Pense ganha-ganha 5. Procure primeiro compreender, depois ser compreendido Vitória Pública 6. Crie sinergia Interdependência 7. Afine o instrumento © 2008
  19. 19. As Cinco Disciplinas da Organização Que Aprende 5. Pensamento sistêmico 4. Domínio pessoal 3. Modelos mentais 2. Construção de uma visão Peter Senge compartilhada 1. Aprendizagem em equipe © 2008
  20. 20. As Leis da Quinta Disciplina 1. Os problemas de hoje vêm das “soluções” de ontem 2. Quanto mais você empurra, mais o sistema empurra de volta 3. O comportamento melhora antes de piorar 4. A saída mais fácil normalmente nos leva de volta para dentro 5. A cura pode ser pior do que a doença 6. Mais rápido significa mais devagar 7. Causa e efeito não estão próximos no tempo e espaço 8. Pequenas mudanças podem produzir grandes resultados, mas frequentemente as áreas de maior alavancagem são as menos óbvias © 2008
  21. 21. Uma Organização que Aprende é... Onde as pessoas expandem continuamente sua capacidade de criar os resultados que elas verdadeiramente querem Onde padrões de pensamento novos e expansivos são nutridos Onde a aspiração coletiva é libertada Onde as pessoas estão continuamente aprendendo a ver o todo juntas Onde as pessoas são o principal meio de alavancagem para os processos de mudança © 2008
  22. 22. O Conflito do Fornecedor de Software Meta Necessidades Ações/Vontades D B Satisfazer a Implementar mudanças percepção de que satisfarão os valor pelos desejos dos clientes o A clientes mais rápido possível Crescimento sustentável (Ganhar mais dinheiro agora e no futuro) Não implementar Continuar a ser mudanças que um fornecedor de ameaçarão a capacidade software confiável de entrega C D’ © 2008
  23. 23. Evaporando a Nuvem Porque... Porque... • Existe concorrência • Não há pressão nos clientes • Os clientes estão mais exigentes para aceitar qualquer oferta • O ritmo do negócio exige feita pelo fornecedor D B Satisfazer a Implementar mudanças percepção de que satisfarão os valor pelos desejos dos clientes o A clientes mais rápido possível Crescimento sustentável (Ganhar mais dinheiro agora e no futuro) Não implementar Continuar a ser mudanças que um fornecedor de ameaçarão a capacidade software confiável de entrega C D’ Porque... Porque... • Quanto maior e mais complexa for a • Quanto mais complexo for o produto, cadeia de entrega, maior o risco de uma maior o risco de uma mudança poder mudança poder causar estragos causar estragos © 2008
  24. 24. Uma Direção Para A Solução Suposição: As mudanças que aumentam a satisfação do cliente ao mesmo tempo ameaçam a capacidade de entrega D B Satisfazer a Implementar mudanças percepção de que satisfarão os valor pelos desejos dos clientes o A clientes mais rápido possível Crescimento sustentável (Ganhar mais dinheiro agora e no futuro) Não implementar Continuar a ser mudanças que um fornecedor de ameaçarão a capacidade software confiável de entrega C 1. A satisfação do cliente é atingida D’ 2. A “venda de valor” prudente principalmente através da venda e implantação de sistemas orientados ao valor – entrega alivia a carga no rápida e sistemática de melhorias desenvolvimento, implantação e significativas no resultado financeiro serviços. © 2008
  25. 25. Quais regras devemos usar agora? Orientação por visão e valor para o cliente – Requisitos mudam, à medida que se aprende – Resposta à mudança é essencial para o sucesso Desenvolvimento dirigido por funcionalidades – Função completa com valor para o cliente – Desenvolvidas e testadas rapidamente, e adaptadas Ciclo de vida iterativo e incremental – Plano de liberação, com ciclos de 2 a 4 semanas – Cada iteração gera funcionalidades completas e testadas, potencialmente entregáveis Ambiente colaborativo – Equipe trabalha muito próxima – Documentação suficiente (suportar a iteração e evolução) – Feedback freqüente, adaptação e aprendizado © 2008
  26. 26. Ciclo de Vida da Gestão Ágil de Projetos Antevisão Plano de Liberação Especular Explorar Ação Adaptativa Funcionalidades Adaptar Completadas Lista de Funcionalidades Produto “Agile Project Management” Final Fechar Jim Highsmith, 2004 © 2008
  27. 27. Principais Benefícios da Gestão Ágil Inovação Contínua – Entregar de acordo com os requisitos atuais do cliente Adaptabilidade do Produto – Entregar de acordo com os requisitos futuros do cliente Cronogramas Reduzidos de Entrega – Satisfazer janelas de mercado – Melhorar o Retorno Sobre o Investimento (RSI) Adaptabilidade das Pessoas e Processos – Responder rapidamente às mudanças no produto e no negócio Resultados Confiáveis – Suportar o crescimento e a lucratividade do negócio © 2008
  28. 28. Práticas Ágeis de Qualidade Ciclos Curtos (Time Box) ou Fluxo Contínuo Test Driven Requirements/Development Domain Driven Design Feature Driven Development Testes Unitários Integração e Testes Contínuos Refactoring Colaboração Entre Desenvolvedores – Programação em Pares – Revisão por Pares e Inspeções Cliente/Dono do Produto mais Próximo Retrospectivas © 2008
  29. 29. Receitas de Agilidade Decompor o trabalho em Entregar um fluxo estável de elementos pequenos, bem software com valor e com sucesso, granulados, com tamanhos por similares Fortalecer equipes colaborativas, Priorizar confiantes e motivadas; Enfatizar qualidade por todo o Responder ao feedback e adaptar à ciclo de vida mudança, e Fazer freqüentes versões Construir com qualidade desde o incrementais para produção início Daniel Vacanti Karl Scotland Modus Cooperandi Availagility Focar na Qualidade David Anderson AgileManagement.Net Reduzir (ou limitar) o Trabalho em Progresso Equilibrar a Demanda com relação ao Ganho (Vazão) Priorizar Crédito Extra: Reduzir a variação no processo e no seu fluxo © 2008
  30. 30. Métricas, Estoques e Perdas Matéria-Prima Trabalho em Progresso Arquitetura Requisitos Especificações Cenários Alterações Alterações Alterações Idéias e Análise Desenho Construção Necessidades (Design) Perdas Erro Erro Erro Testes de Testes de Testes Produto Integração/Sistema Aceitação Unitários Código pronto Planos de Testes Planos de Testes Código p/ liberação Cenários Gerais Cenários Localizados a testar Produto Acabado Trabalho em Progresso © 2008
  31. 31. Como Causar a Mudança? © 2008
  32. 32. O Processo da Mudança Idéia Modelo de Mudança de transformadora Virgínia Satir Catalisador p/ mudança Antigo Prática & Novo Caos Status quo Integração Status quo Vale do Desespero Produtividade Ganho Tempo © 2008
  33. 33. Princípios Guias da Gestão Ágil de Projetos Entrega do Produto Liderança-Colaboração Encorajar a excelência Simplificar técnica Entregar Encorajar valor para a o cliente exploração Utilizar Construir entrega equipes iterativa de adaptativas funcionalidade © 2008
  34. 34. Planejamento em Camadas Feito pela equipe de projeto Feito pela gerência superior © 2008
  35. 35. Exemplos © 2008
  36. 36. Scrum 7. Reuniões 6. Dia Diárias (em pé) 5. Iteração 4. Tarefas (2 a 4 sem.) 3. Escopo da Corrida detalhadas 8. Incremento de Produto pela equipe (pode ser liberado para uso) (Sprint) 1. Visão (RSI, marcos, 2. Lista de Espera (Backlog) de funcionalidades versões) do produto, priorizada pelo Dono do Produto © 2008
  37. 37. Feature Driven Development (FDD) Requisitos Concepção e Planejamento Desenvolver Construir Planejar Mais forma que conteúdo um Modelo a Lista de por Abrangente Features Feature Plano de Desenvolvimento Modelo de Objetos Construção Detalhar Construir Progresso Mais conteúdo na forma por por Feature Feature Produto Pacotes de Trabalho © 2008
  38. 38. Scrum & FDD Construção 7. Reuniões 6. Dia 4 5 Diárias (em pé) DPF CPF 5. Iteração 4. Tarefas (2 a 4 sem.) 3. Escopo da Corrida detalhadas 8. Incremento de Produto pela equipe (pode ser liberado para uso) (Sprint) 1. Visão 2. Lista de Espera (Backlog) de funcionalidades (RSI, marcos, do produto, priorizada pelo Dono do Produto versões) Concepção e Planejamento 1 2 3 DMA CLF PPF © 2008
  39. 39. Agile CMMI Nível Foco Áreas de Processos Produtividade Melhoria Qualidade 5: Em OID: Inovação e Implantação Organizacional Contínua do Otimização CAR: Análise e Prevenção de Defeitos Processo 4: Gerenciado Gerência QPM: Gerenciamento Quantitativo de Projeto Scrum + FDD + TOC Quantitativam. Quantitativa OPP: Performance do Processo Organizacional RD: Desenvolvimento de Requisitos TS: Solução Técnica PI: Integração de Produtos VER: Verificação VAL: Validação Padronização 3: Definido OPF: Foco no Processo Organizacional do Processo OPD: Definição do Processo Organizacional OT: Treinamento Organizacional IPM: Gerência Integrada de Projeto RSKM: Gerência de Riscos DAR: Análise e Tomada de Decisão REQM: Gerência de Requisitos PP: Planejamento de Projeto Gerência PMC: Monitoramento e Controle de Projeto 2: Gerenciado Básica de SAM: Gerência de Acordos com Fornecedores Projetos MA: Medição e Análise PPQA: Garantia da Qualidade do Processo e do Produto CM: Gerência de Configuração Risco 1 :Inicial Retrabalho © 2008
  40. 40. Conclusão Agilidade e Responsabilidade não são antagônicos, mas mutuamente necessários Agilidade busca entregar sistematicamente um fluxo de valor para o cliente Responsabilidade, uma via de mão dupla, busca estabelecer a confiança necessária entre cliente e fornecedor A Gestão Ágil de Projetos é uma excelente proposta para implantar uma cultura ágil responsável © 2008
  41. 41. Heptabraço! Adail Muniz Retamal adail@heptagon.com.br www.heptagon.com.br © 2008

×