Agilidade com Responsabilidade - Agile Day 2008 - POA

Agilidade com Responsabilidade Engº Adail Muniz Retamal adail@heptagon.com.br

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agilidade com Responsabilidade - Agile Day 2008 - POA

0 comments

Notes on slide 1

1 Favorite