QUALIDADE DE SOFTWARES

Transcrição

1 QUALIDADE DE SOFTWARES Orlando Queiroz Jr, ITIL, MBA-FGV PMI Member:

2 PRÁTICAS DE ORGANIZAÇÕES MADURAS

3 Práticas das organizações maduras Interação com o cliente Fator de fracasso: alteração dos requisitos e escopo Inevitável, porém deve ser entendido pelas duas partes Ver o cliente como um parceiro com interesse comum O sucesso do projeto Toda não conformidade com o planejado é informada ao cliente Cliente é incentivado a se comunicar com os desenvolvedores Manter diálogo constante entre as partes

4 Práticas das organizações maduras Gerenciamento de projetos Planos de projeto realísticos e honestos Propor custos ou prazos reduzidos: desleal e desastrosa Análise e gerência contínua de riscos Busca de métricas mais precisas para calcular prazos e custos Projetos anteriores servem de base Diminuem a possibilidade de fracasso

5 Práticas das organizações maduras Métricas Alimentam suas bases de projetos anteriores constantemente Métricas auxiliam a definição de tarefas e alocação de recursos Medidas para conhecer o desempenho individual e coletivo Relatórios de emprego de tempo, por exemplo Pode trazer receio aos desenvolvedores Constantemente avaliados Deve haver um feedback positivo do gerente do projeto Não punir erros, mas sim aprimorar estimativas Honestidade deve ser considerada um valor importante

6 Práticas das organizações maduras Treinamento e coaching Treinamentos formais para novos contratados Apresentar os padrões usados na empresa Programas de reciclagem para os mais antigos Sentem-se valorizados Pode ser necessário, em novos projetos, processos, linguagens ou ferramentas ainda não conhecidas Coaching: funcionários mais experientes acompanham e auxiliam o desenvolvimento da carreira dos mais novos

7 Práticas das organizações maduras Revisões por pares É difícil um desenvolvedor encontrar seus próprios erros Designa-se outro para realizar uma revisão Cada artefato produzido passa pela revisão de outro funcionário Documento de requisitos, diagramas de análise ou código Deve haver preocupação em evitar atritos Está sendo julgado o trabalho feito, não quem o fez

8 Sistema Kaizen - 改 善 Método x Filosofia de trabalho Método: maneira de solucionar um problema em que as informações são conhecidas de antemão Métodos dos elementos finitos Filosofia: sentido menos concreto. Relacionado a forma como se pensa Transparência, lealdade Vários fatores influenciam o comportamento Interpretação da lei Pouca gente é honesta ao preencher relatórios de tempo

9 Sistema Kaizen Bases do sistema 5S (Toyota) Método de trabalho com foco no indivíduo Kai = mudança, Zen = para o melhor Soluções baseadas em práticas de trabalho e disciplina Figura: Organização de pastas Aplicadas a toda a empresa e no espaço individual do funcionário Objetos, papéis, canetas devem estar organizados Princípio: reduzir o valor não agregado Identificadas 7 fontes de desperdício Produção em excesso, tempo de espera, transportes, estoques inúteis, processo de fabricação, movimentos inúteis, peças defeituosas

10 Sistema Kaizen Os 5 S Seiri (descarte): tudo que é desnecessário pode ser jogado fora Seiton (arrumação): organização do espaço e métodos de trabalho Seisoh (limpeza): sua, do espaço de trabalho e das ferramentas Seiketsu (asseio): padronização. Ferramentas guardadas sempre no mesmo lugar, na mesma posição Shitsuke (disciplina): progresso. Disciplina na postura interna das pessoas

11 Sistema Kaizen Aplicação à construção de software Problemas como desperdício de má organização são resultado do trabalho das pessoas Seiri: simplificação. Implementar somente funções necessárias Seiton: diagramas e demais documentos devem ser identificados e, quando preciso, referenciar-se entre si de forma clara e precisa Seisoh: rotinas não utilizadas devem ser descartadas (diagramas, documentos e qualquer arquivo que não tenha mais aplicação) Seiketsu: nomenclatura de identificadores, formato de comentários e outros elementos deve seguir um padrão Shitsuke: atitude interna das pessoas, desvinculado do trabalho. Qualidade de vida no ambiente de trabalho

12 IMPLEMENTANDO UM MODELO DE DESENVOLVIMENTO DE SOFTWARE UTILIZANDO UMA ABORDAGEM ÁGIL

13 Itens a serem observados Vamos conhecer os dois mundos A Melhoria de Processos O Pensamento Ágil Comparativo Abordagem Tradicional x Ágil Juntando os dois mundos Cuidados na Aplicação da Abordagem Ágil Conclusão

14 Motivação: Dilemas da Construção de Software Fracassos são frequentes em projetos de software: Prazos e orçamentos não cumpridos Expectativas não satisfeitas Retorno muito menor que o esperado Impossível satisfazer ao mesmo tempo custo, prazo, escopo e qualidade Qualidade Custo Escopo Prazo A Busca por uma Solução Construir software = construir projetos de engenharia Receita para o sucesso: investir muito tempo e recursos em uma fase detalhada de planejamento e design garantir o sucesso da execução com gerenciamento e processos bem definidos

15 Motivação: Dilemas da Construção de Software Um Novo Problema... Por mais que as metodologias tenham definido processos e controles, os resultados estão longe dos esperados... Esta receita não funciona para o desenvolvimento de software: Um software é, pela sua própria natureza, intangível É impossível antever todas as suas funcionalidades As necessidades emergem durante todo o seu desenvolvimento, e vão amadurecendo até a sua implantação A utilização do software aprimora os seus recursos A mudança é, portanto, inevitável! A mudança, necessária, passa a ser amaldiçoada!

16 VAMOS CONHECER OS DOIS MUNDOS : A MELHORIA DE PROCESSOS

17 A Abordagem Tradicional No intuito de aumentar, medir e garantir a qualidade, surgiram vários guias, normas e modelos... Mostram O QUE fazer Mas cabe a cada organização definir o seu modo de trabalhar com qualidade... Definir COMO fazer Organização Macro-processos Processos Sub-Processos Funcionam como bússolas : fornecem um direcionamento, mas não o mapa Possuem conceitos semelhantes, com alguns objetivos e práticas comuns, mas com enfoque principal diferente Modelos, Normas Procedimentos, Instruções, Registros, Indicadores Atividades Tarefas Pessoas

18 Normas Série ISO 9000 Sistema de Gestão da Qualidade Consenso internacional sobre boas práticas de gerenciamento para garantir o atendimento aos requisitos do cliente e melhoria contínua Aplicável a qualquer tipo de organização Nasceu para a manufatura Problemas para software Não contempla as especificidades da área de software Teve uma versão para software, mas sem popularidade (ISO )

19 A Gestão Tradicional Segundo o PMBOK Project Management Body of Knowledge (PMBOK) Conjunto de melhores práticas em gestão de projetos Padrão mundial (comunicação, conhecimento e expectativas) Base da metodologia do PMI e da certificação PMP Importante: a existência de melhores práticas não implica em uso uniforme para todos os projetos é necessário verificar em cada caso se são apropriadas ou não... principalmente para software!! Processos de Iniciação Processos de Monitoramento e Controle Processos de Planejamento Processos de Encerramento Processos de Execução

20 A Melhoria de Processos Segundo o CMMI CMMI: Capability Maturity Model Integration 5 4 Foco na melhoria contínua dos processos Processos melhorados continuamente: organização ágil, eficaz e eficiente Processos medidos e controlados Controle quantitativo de processos: variação reduzida dos resultados, com objetivos de qualidade e produtividade alcançáveis Em Otimização Gerenciado Quantitativamente 3 Processos comuns à toda a organização Processos comuns, dados comparáveis: custos previsíveis, busca de maior produtividade, abordagem proativa Definido 2 1 Processos caracterizados para cada projeto Melhores planos, compromissos mais razoáveis, ações corretivas: prazos de execução cumpridos, com abordagem menos reativa Processos imprevisíveis, mal controlados, reativos Pouca disciplina, compromissos mal estabelecidos: não se pode reproduzir sucessos anteriores Inicial Gerenciado Fonte: Software Engineering Institute

21 O Modelo CMMI para Desenvolvimento (V1.3) Nível Ger. Processo Ger. Projeto Engenharia Suporte 5 OPM: Gerência da Performance Otimizando Organizacional 4 Gerenciado OPP: Desempenho do QPM: Gerência Quantitativa Processo Organizacional de Projetos Quantitativamente 3 Definido OPD: Definição do Processo Organizacional OPF: Foco no Processo Organizacional OT: Treinamento Organizacional IPM: Gerência Integrada de Projetos RSKM: Gerência de Riscos RD: Desenvolvimento de Requisitos TS: Soluções Técnicas PI: Integração de Produtos VER: Verificação VAL: Validação CAR: Análise de Causas e Resoluções DAR: Análise de Decisões e Resoluções 2: Gerenciado 1 Inicial PP: Planejamento de Projetos PMC: Monitoramento e Controle de Projetos REQM: Gerência de Requisitos SAM: Gerência de Acordos com Fornecedores CM: Gerência de Configuração PPQA: Garantia da Qualidade do Processo e do Produto MA: Medição e Análise

22 A Melhoria de Processos e o Programa MPS.BR Principal Objetivo Melhoria de processo do software brasileiro, a custos acessíveis, em todas as regiões do país Meta 1 já cumprida! Desenvolvimento do modelo MPS.BR (guias) Capacitação no MPS.BR (cursos, provas e workshops) Credenciamento de instituições (implementar/avaliar) Meta 2 já cumprida! Implementação e Avaliação do MPS.BR em empresas no Brasil Meta 3 Disseminação do projeto para a América Latina

23 O Modelo de Referência do Programa MPS.BR Nível Processos Atributos de Processo A B C D E F G (nenhum processo específico) Gerência de Projetos GPR (evolução) Gerência de Riscos GRI Desenvolvimento para Reutilização DRU Gerência de Decisões GDE Verificação VER Validação VAL Projeto e Construção do Produto PCP Integração do Produto ITP Desenvolvimento de Requisitos DRE Gerência de Projetos GPR (evolução) Gerência de Reutilização GRU Gerência de Recursos Humanos GRH Definição do Processo Organizacional DFP Avaliação e Melhoria do Processo Organizacional AMP Medição MED Gerência de Portfólio de Projetos GPP Garantia da Qualidade GQA Gerência de Configuração GCO Aquisição AQU Gerência de Requisitos GRE Gerência de Projetos GPR AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP3.2, AP 4.1 e AP 4.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP3.2 AP 1.1, AP 2.1 e AP 2.2 AP 1.1 e AP 2.1

24 Correspondência CMMI MPS.BR Definido Em Otimização Gerenciado Quantitativamente Gerenciado

25 Comparativo entre os Modelos MR-MPS Versão 2009 CMMI Versão 1.3 CMMI V1.3 e o MR-MPS V 2009 Nível Processo Nível Área de Processo A RAPs adicionais (sem processo específico) 5 B C D E F G RAPs adicionais (sem processo específico) Gerência de Projetos (GPR - evolução) Desenvolvimento para Reutilização (DRU) Gerência de Decisões (GDE) Gerência de Riscos (GRI) Desenvolvimento de Requisitos (DRE) Projeto e Construção do Produto (PCP) Integração do Produto (ITP) Verificação (VAL) Validação (VER) Gerência de Recursos Humanos (GRH) Aval. e Melhoria do Processo Organizacional (AMP) Definição do Processo Organizacional (DFP) Gerência de Projetos (GPR - evolução) Gerência de Reutilização GRU Medição (MED) Gerência de Configuração (GCO) Aquisição (AQU) Garantia da Qualidade (GQA) Gerência de Portfólio de Projetos (GPP) Gerência de Requisitos (GRE) Gerência de Projetos (GPR) Gerência da Performance Organizacional (OPM) Análise e Resolução de Causas (CAR) Desempenho do Processo Organizacional (OPP) Gerência Quantitativa do Projeto (QPM) Análise de Decisão e Resolução (DAR) Gerência de Riscos (RSKM) Desenvolvimento de Requisitos (REQM) Solução Técnica (TS) Integração do Produto (PI) Verificação (VER) Validação (VAL) Treinamento Organizacional (OT) Foco no Processo Organizacional (OPF) Definição do Processo Organizacional (OPD) Gerência Integrada de Projetos (IPM) Medição e Análise (MA) Gerência de Configuração (CM) Gerência de Acordo com Fornecedores (SAM) Garantia da Qualidade de Processo e Produto (PPQA) Gerência de Requisitos (REQM) Planejamento do Projeto (PP) Monitoramento e Controle de Projeto (PMC)

26 A Essência da Melhoria de Processos O que de tudo isso realmente importa?

27 Visão Atual da Melhoria de Processos Manifesto pela Melhoria de Processos de Software Software Process Improvement (SPI) Manifesto Os valores de SPI envolvem: Pessoas: tem que envolver pessoas ativamente e afetar suas atividades diárias Conheça a cultura e foque nas necessidades Motive todas as pessoas envolvidas Baseie melhorias em experiências e medições Crie uma organização que aprende Negócio: é o que você faz para tornar um negócio um sucesso Apóie a visão e os objetivos da organização Use modelos dinâmicos e adaptáveis quando necessário Utilize gerência de risco Mudança: é fortemente relacionado com mudança Gerencie a mudança organizacional durante seu esforço de melhoria Garanta que todos os envolvidos entendam e concordem com o processo Não perca o foco Janeiro eurospi.net

28 CONHECENDO OS DOIS MUNDOS : O PENSAMENTO ÁGIL

29 O Pensamento Ágil: A Quebra de Paradigma Abordagem Tradicional: Por que não Escopo Qualidade Qualidade Escopo Custo Prazo Custo Prazo Parte de um escopo fechado Define-se custo e prazo Se necessário, manipula a qualidade Por que não... Ter um prazo predefinido Ter um custo fixo, definido em função do prazo Manter os níveis de qualidade Manipular o escopo? Fazer o mais simples agora, e refinar depois? Mudar quando for necessário? Libertar-se do excesso de documentação? Usuários pagam por software, não por documentação A QUALIDADE é que faz a diferença...

30 Metodologias Ágeis: Origem O Manifesto pela Agilidade Estamos evidenciando maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: Indivíduos e interação 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 tendo valor os itens à direita, valorizamos mais os itens à esquerda.

31 Os 12 Princípios da Agilidade Princípio 1: A mais alta prioridade é a satisfação do cliente, por meio da liberação mais rápida e contínua de software funcionando Princípio 2: Receba bem as mudanças de requisitos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente Fonte: SilverStream

32 Os 12 Princípios da Agilidade Princípio 3: Libere software frequentemente (em intervalos de 2 semanas até 2 meses), dando preferência para uma escala de tempo mais curta Princípio 4: Mantenha pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhando juntos a maior parte do tempo do projeto Fonte: SilverStream

33 Os 12 Princípios da Agilidade Princípio 5: Realize projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para realizar o trabalho Princípio 6: O método mais eficiente e efetivo para repassar informação entre uma equipe de desenvolvimento é pela comunicação face-a-face Fonte: SilverStream

34 Os 12 Princípios da Agilidade Princípio 7: Software funcionando é a principal medida de progresso de um projeto de software Princípio 8: Processos ágeis promovem desenvolvimento sustentado assim, patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica sempre Fonte: SilverStream

35 Os 12 Princípios da Agilidade Princípio 9: A atenção contínua para a excelência técnica e um bom projeto (design) aprimoram a agilidade Princípio 10: Simplicidade a arte de maximizar o trabalho que não precisa ser feito é essencial, devendo ser assumida em todos os aspectos do projeto Fonte: SilverStream

36 Os 12 Princípios da Agilidade Princípio 11: As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas Princípio 12: Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento Fonte: SilverStream

37 O PENSAMENTO ÁGIL: ABORDAGENS ÁGEIS PARA O DESENVOLVIMENTO

38 A Abordagem Ágil para o Desenvolvimento: XP Extreme Programming Características: Metodologia leve (uma filosofia de desenvolvimento de software) É de domínio público, voltada para o desenvolvimento Emprega ao extremo boas práticas da engenharia de software Rever o código programação em pares faz revisão de código o tempo todo Testar o código testes automatizados e constantes, com integração contínua Envolver o cliente cliente presente e fazendo parte da equipe do projeto Descrita por meio de valores, princípios e práticas Possui uma comunidade que compartilha e aplica estas idéias - Critérios para julgar o que vemos, pensamos e fazemos - São abstratos, amplos e universais facilita prestar contas do valor ponte dá propósito à prática - Ações que seguem os princípios, sustentando os valores definidos - São úteis, se complementam e se amplificam

39 XP Extreme Programming: Valores Comunicação Fundamental para a compreensão do trabalho a ser feito e entrosamento da equipe Simplicidade É preferível fazer algo simples e gastar um pouco mais para alterar, se necessário, do que fazer algo complicado e não utilizar Sistemas simples são mais fáceis de serem testados Simplicidade Comunicação Respeito Realimentação Coragem Realimentação (feedback) É muito importante ter uma idéia clara sobre a situação atual do sistema Maior realimentação facilidade de comunicação, teste e aprendizado Coragem Algo que não funcione adequadamente deve ser descartado e refeito, de forma mais simples Respeito (entre a equipe e ao projeto incluído na 2ª Ed) Dá sustentação a todos os demais (mais básico de todos os valores) Saber ouvir, saber compreender e respeitar o ponto de vista do outro

40 XP Extreme Programming: Princípios (1ª Ed) Objetivo: Proporcionar a pequenas / médias equipes um ambiente de desenvolvimento cooperativo, capaz de atingir altos níveis de produtividade e um elevado grau de confiança Realimentar rapidamente Assumir a simplicidade Aceitar a mudança Medir honestamente Não gerar sobrecarga Comunicar de forma aberta e honesta Adaptar-se à cultura e condições locais Aceitar responsabilidades Extreme Programming Fazer mudanças incrementais Executar trabalho com qualidade Ensinar aprendendo Investir pouco no início Jogar para vencer Fazer experimentos concretos Trabalhar a favor do instinto das pessoas

41 XP Extreme Programming: Resumo Práticas (1ª Ed 2ª Ed) Fonte:

42 XP Extreme Programming: Papéis em Projetos Maior especialização de papéis: abordagem mais inclusiva Edição 1: cliente, programador, tester, coach, tracker Edição 2: destaca outros papéis típicos do desenvolvimento de software Diversidade de pessoas beneficia toda a equipe Cada papel deve compreender suas responsabilidades na equipe Cada um deve contribuir com tudo que pode para a equipe Papéis podem variar e uma mesma pessoa pode exercer vários papéis Interação deve seguir princípios de fluxo e benefício mútuos Programador Cliente Técnico (coach) Acompanhador (tracker) Testador (tester) Executivos Recursos Humanos Gerentes de Produto Gerentes de Projeto Usuários Escritores Técnicos Arquitetos Testadores (testers) Projetistas de Interação Programadores

43 A Abordagem Ágil para o Desenvolvimento: Lean Programming Abordagem Lean Derivada do Sistema Toyota de Produção Busca da forma ótima de produzir pela eliminação de desperdício e automação inteligente visando melhorar o valor global para o cliente Eliminar estoque, defeitos, trabalho que não agrega valor, sobrecarga Parar a linha de produção quando um defeito é identificado Abordagem Just in Time: nada deve ser produzido, transportado ou comprado antes da hora exata Obter as coisas certas, no lugar certo, no hora certa e na quantidade certa Atingir o fluxo perfeito de trabalho Minimizar desperdício Ser flexível e apto à mudança Testada e experimentada em vários contextos nas duas últimas décadas

44 Lean Programming Práticas básicas da abordagem Lean para software 1: Eliminar desperdício Gerar só artefatos que agreguem valor ao produto final, de forma eficiente 2: Minimizar estoque Minimizar documentação e artefatos intermediários (maior abstração) 3: Maximizar o fluxo Reduzir o ciclo de desenvolvimento usar abordagem iterativa e incremental 4: Produzir sob demanda Especificar requisitos o mais tarde possível, estar aberto à mudança 5: Dar autonomia aos trabalhadores Deixar a equipe tomar decisões e se auto-organizar, dar visibilidade 6: Atender aos requisitos do cliente Desenvolver o mais crítico primeiro, obter feedback a cada iteração

45 Lean Programming Práticas básicas da mentalidade Lean para software (cont.) 7: Fazer certo da primeira vez Desenvolver dirigido por testes, aplicar refactoring quando evoluir 8: Abolir otimização local Não gerenciar escopo além do necessário ele será auto gerenciado em um domínio claro, com ciclos iterativos de prazo fixo e com foco no uso pretendido 9: Ser parceiro na cadeia cliente fornecedor Fornecer o melhor software possível (> valor agregado, > custo-benefício) 10: Criar a cultura de melhoria contínua Excelência = habilidade para adaptar a ambientes de grande mudança Desenvolvimento iterativo, refactoring, aprendizado contínuo Resultado: maior qualidade e menor tempo e custo da produção de software

46 O PENSAMENTO ÁGIL: ABORDAGENS ÁGEIS PARA O GERENCIAMENTO

47 A Abordagem Ágil para o Gerenciamento: APM: Agile Project Management Princípios: Baseado em Sistemas Adaptativos Complexos Revoadas, cardumes, enxames Comportamento coletivo: ordem, auto-organização, inteligência coletiva, adaptação a ambientes dinâmicos, habilidade em lidar com a mudança Organizações: sistemas adaptáveis, com seres inteligentes Confiança na habilidade coletiva para resolver problemas Imprevisibilidade limita planejar: enfatizar a adaptabilidade Papel do Gerente de Projeto: líder adaptável Promove o trabalho colaborativo em equipe, defende o projeto e remove obstáculos para sua progressão

48 APM: Agile Project Management Possui 6 práticas simples P1: Visão Direcionada Estabeleça uma visão direcionadora para o projeto e reforce-a continuamente, por meio de palavras e ações P2: Trabalho e Colaboração em Equipe Facilite a colaboração e o trabalho em equipe reforçando relacionamentos P3: Regras Simples Estabeleça e apóie um conjunto de práticas-chave P4: Informação Aberta Forneça acesso aberto à informação P5: Toque leve Aplique somente o controle suficiente para manter a ordem emergente P6: Vigilância Ágil Aplique um contínuo monitoramento, aprendizado e adaptação ao ambiente

49 A Abordagem Ágil para o Gerenciamento: SCRUM Metodologia (framework) cujo nome deriva de uma estratégia usada no rugby Possui como espinha dorsal um Sprint Período (em geral de 30 dias) durante o qual a equipe de desenvolvimento irá correr atrás de seu objetivo (Sprint Goal), implementando uma lista de requisitos predefinidos (Sprint Backlog) Sempre apresenta um executável no final da Sprint Idéia: iterações curtas e focadas melhoram a visibilidade para acompanhar o desenvolvimento Mais voltado para o gerenciamento de projetos com equipes pequenas e requisitos instáveis ou desconhecidos 24 h 30 dias Backlog: lista priorizada de requisitos Product Backlog Sprint Backlog Sprint Incremento de trabalho do sw

50 SCRUM: Principais Papéis Os papéis nos SCRUM são responsabilidades no processo e não posições na organização - Lidera a equipe de desenvolvimento - Resolve possíveis impedimentos - Assegura que a equipe possui as condições necessárias para alcançar os objetivos do Sprint - Realiza reuniões diárias com a equipe para acompanhar atividades Product Owner - Ponto focal com a visão do cliente - Responsável pelo Product Backlog - Reúne mudanças e prioriza funcionalidades - Realiza o aceite do produto ao final do sprint - Gerencia a rentabilidade do projeto (ROI) Scrum Master Scrum Team - Time = equipe de desenvolvimento - É auto organizável e responsável pelos resultados - Interage com o Product Owner para determinar o objetivo do Sprint, priorizar as funcionalidades e definir tarefas detalhadas

51 SCRUM: Fluxo de Atividades Fonte:

52 SCRUM: Principais Atividades Estimation Meeting Preparação para o Sprint Planning Criação / revisão do Product Backlog Projeto macro da arquitetura e definição de pacotes Relização de estimativa formal Estima somente o tamanho e não o tempo para execução Serve de entrada para o planejamento de versões (releases) Sprint Planning Meetings (1,2) Reuniões para rever, fazer considerações e organizar o Sprint 1) define Selected Product Backlog a partir do Product Backlog (foco: Release) 2) define o Sprint Backlog a partir do Selected Product Backlog (foco: Sprint) Define o objetivo do próximo Sprint (Sprint Goal)

53 SCRUM: Principais Atividades A Execução de um Sprint A equipe constrói as funcionalidades definidas no Sprint Backlog, visando atingir o objetivo (Sprint Goal) Ocorre em 30 dias e possui escopo fixo neste período A equipe se auto-organiza para executar o trabalho Trabalha alinhada com os padrões e regras para sua execução O progresso das atividades é acompanhado Daily Scrum Meetings Reunião diária de 15 minutos (em pé) Mesmo local e hora, todos os dias Cada participante responde O que foi realizado desde a reunião anterior? O que será realizado até a próxima reunião? Existe algum obstáculo / impedimento para prosseguir? Questões são apenas identificadas para posterior tratamento Benefícios: integra a equipe, compartilha conhecimentos, identifica e trata problemas com rapidez, acompanha progresso e minimiza riscos

54 SCRUM: Principais Atividades Acompanhamento das atividades Gráfico Burndown Atualizado diariamente durante o Daily Scrum Término anormal de um Sprint Sprints podem ser cancelados antes dos 30 dias se: a equipe perceber que não irá atingir o objetivo (sprint goal) O objetivo passar a ser irrelevante devido a circunstâncias externas Próximos passos Conduzir nova Sprint Planning Meeting na qual a razão do término anormal será revisto

55 SCRUM: Principais Atividades Geração de novas funcionalidades Trabalho considerado pronto quando: Código está limpo e aderente a padrões Foi refatorado, rodou teste unitário Foi feito check-in e foi integrado ao produto Done! Sprint Retrospective Meeting Reunião para discutir e opinar sobre o Sprint A idéia central é identificar formas da equipe ser mais produtiva e melhor em Sprints futuros Relacionado a 3 perguntas: What went well o que deu certo / foi bom What could have been better questões / problemas detectados What could have been improved melhorias a implementar

56 SCRUM: Ferramentas Agile Radiator : quadro de acompanhamento

57 O PENSAMENTO ÁGIL: COMPARATIVO ABORDAGEM TRADICIONAL X ÁGIL

58 Abordagem Tradicional x Ágil: Diferenças Abordagem Tradicional Abordagem Ágil Preditivo: detalhar o que ainda não é bem conhecido Rígido: seguir especificação predefinida, a qualquer custo Burocrático: controlar sempre, para alcançar objetivo planejado Orientado a processos: segui-los possibilita garantir a qualidade Documentação gera confiança Sucesso = entregar o planejado Gerência = comando-e-controle voltado para trabalho em massa, ênfase: papel do gerente, com planejamento e disciplina fortes Adaptativo: conhecer problema e resolver crítico primeiro Flexível: adaptar-se a requisitos atuais, que podem mudar Simplista: fazer algo simples de imediato e alterar se necessário Orientado a pessoas: motivadas, comprometidas e produtivas Comunicação gera confiança Sucesso = entregar o desejado Gerência = liderança/orientação trabalhadores do conhecimento, ênfase: criatividade,flexibilidade atenção às pessoas

59 Abordagem Tradicional x Ágil: Diferenças Abordagem Tradicional Desenvolvedor hábil (variedade) Cliente pouco envolvido Requisitos conhecidos, estáveis Retrabalho/reestruturação caro Planejamento direciona os resultados (incentiva controlar) Conjunto de processos, com metodologia definida Premia a garantia da qualidade Foco: grandes projetos ou os com restrições de confiabilidade, planej. estratégico / priorização (exigem mais formalismo) Objetivo: controlar, em busca de alcançar o objetivo planejado (tempo, orçamento, escopo) Abordagem Ágil Desenvolvedor ágil (colaborador) Cliente comprometido (autonomia) Requisitos emergentes, mutáveis Retrabalho/reestruturação barata Resultados direcionam o planejamento (incentiva mudar) Conjunto de valores, com atitudes e princípios definidos Premia o valor rápido obtido Foco: projetos de natureza exploratória e inovadores, com equipes pequenas/médias (exigem maior adaptação) Objetivo: simplificar processo de desenvolvimento, minimizando e dinamizando tarefas e artefatos

60 Abordagem Tradicional x Ágil: Similaridades As abordagens possuem pontos positivos e negativos Partem de pressupostos diferentes! Podem coexistir e conviver bem em um mesmo ambiente as boas práticas são compatíveis e podem funcionar bem, mesmo sem contemplar integralmente um modelo ou norma Importante: considerar, criteriosamente, o ambiente e uso correto O ciclo de vida ágil é semelhante aos outros Definir o que o cliente quer e iniciar o projeto Planejar o projeto, calculando esforço Executar o plano, construindo a solução Monitorar resultados e entregar ao cliente Ciclos mais rápidos, executados várias vezes Necessário buscar o ponto de equilíbrio, avaliando riscos Planejamento aperfeiçoa a agilidade Agilidade dá eficiência ao planejamento

61 Iniciativas de integração dos dois mundos

62 Iniciativas de integração dos dois mundos Agile Process Maturity Model (APMM) Scott W. Ambler - IBM Objetivo: disponibilizar um framework que forneça um contexto para a grande variedade de metodologias ágeis atuais

63 Iniciativas de integração dos dois mundos "Juramento de Não-Lealdade Eu prometo não desconsiderar nenhuma idéia baseada na sua origem, mas considerar idéias vindas de todas as escolas e tradições, com o objetivo de encontrar aquelas que melhor se encaixem em cada situação. Criado por Alistair Cockburn Um dos signatários do Manifesto Ágil Objetivos Integrar "pessoas de uma escola de pensamento atacando idéias de outra" Identificar "pessoas que não se importem com a origem das idéias, mas com o seu significado e o que elas são capazes de produzir"

64 APLICAÇÃO DA ABORDAGEM ÁGIL: OBSERVAÇÕES PROBLEMAS DE IMPLEMENTAÇÃO

65 Contexto Características das organizações que estão realizando implementação MPS ágil Objetivo da implementação Obtenção de nível de maturidade Melhoria de processos e produtos existentes Crença em ser a abordagem adequada Adoção da abordagem ágil Já nasceu ágil (trabalham com XP / Scrum desde seu início) Seguia a abordagem tradicional e experimentou a ágil Órgãos governamentais e empresas particulares Ad-hoc que percebeu na abordagem ágil uma boa opção

66 Lições Aprendidas: Contexto Características das organizações que estão realizando implementação CMMI / MPS ágil (cont.) Formas de implementação XP: de forma adaptada Dificuldade em seguir todas as práticas XGD: extreme Game Development Scrum: de forma completa ou adaptada Adaptação devido a equipes grandes e/ou distribuídas Adequação: sprints, backlogs, planning poker, reuniões rápidas XP e Scrum: de forma adaptada Filosofia ágil para desenvolvimento e gerência Metodologia própria baseada em XP e Scrum, com influência de Lean Programming Evangelizador interno influenciou equipe de processos Baseado no OpenUP Transição do RUP

67 Lições Aprendidas: Implementação A quebra de paradigma É difícil quebrar posicionamentos radicais Avaliar as condições da empresa para assimilar as práticas ágeis e/ou modelos de maturidade antes de iniciar o programa de melhoria Palavra chave: MOTIVAÇÃO ( motivo para ação ) A falta de motivação para uso da nova abordagem dificulta o processo É necessário manter o foco e evitar sobrecarga Importante tanto para a equipe quanto para o implementador

68 Lições Aprendidas: Implementação O respeito à cultura local Seguir à risca uma metodologia não é uma boa abordagem Cada empresa tem suas características e o bom senso deve prevalecer Buscar a migração da forma mais suave possível Adotar passos pequenos (introduzir as práticas aos poucos) Criar consciência da necessidade de uma prática usando métricas Avaliar a experiência obtida na adoção da prática Buscar a compatibilidade com os processos e artefatos já em uso Ambientes nos quais a abordagem ágil é inadequada Cultura local valoriza o excesso de documentação Comprometimento medido por horas extras de trabalho Dificuldade para realizar mudanças Demora para obtenção de feedback Impossibilidade de realizar testes automatizados Resistência cultural

69 Lições Aprendidas: Implementação Cuidados na contratação e envolvimento de consultoria Importante: não modificar os valores da organização Adequar o modelo à realidade da organização e não o contrário Buscar no mercado empresas de consultorias que tenham experiência com as duas abordagens Que saiba lidar com as dificuldades culturais na implementação híbrida Presença constante da consultoria consome maior número de horas Alinhar claramente os objetivos definidos no início do projeto É necessário o comprometimento de todos os envolvidos

70 Lições Aprendidas: Implementação Necessidade e nível de detalhamento da documentação O importante é documentar e não o documento em si Ex 1: filmar sessão de levantamento de requisitos Ex 2: fotografar quadro para evidenciar acompanhamento Difícil estabelecer nível de detalhamento e documentação MPS exige documentação técnica mais detalhada da solução A abordagem ágil dispensa documentação detalhada Importante: buscar o equilíbrio Preservar o essencial da documentação, em especial a parte técnica Documentação pesada dificulta a gestão e a capacidade de reação quando ocorrem mudanças de requisitos

71 Lições Aprendidas: Implementação Uso de ferramentas Utilizar ferramenta de controle apropriada Quadro + post-it dificulta manter o histórico O uso de ferramenta que ofereça abstração do quadro traz agilidade e visibilidade, sem perder a filosofia Scrum O apoio de ferramenta ajuda na implementação Empresas que aplicam XP empregam diversas ferramentas Empresas ágeis tendem a usar ferramentas de software livre (free e/ou open source)

72 Lições Aprendidas: Implementação Nível G Abordagem de Gerência de Projetos com Scrum (1/2) Planejar o cronograma de forma mais macro Deixar o detalhamento das tarefas para o quadro de apoio Monitoramento periódico = reuniões diárias Evidência = foto do quadro ou registro na ferramenta Opcionalmente, gerar relatos simples (atas) das reuniões diárias Revisões em marcos = sprint reviews Projeto delimitado pelo número de sprints Escopo do projeto = total de pontos dos sprints previstos Depende do método de estimativa e da velocidade da equipe Estabelecido e relacionado ao backlog do produto Principais impactos Foco em avaliação formal induz o uso de quadro mais rico e/ou de registros em ferramenta Detecção antecipada de defeitos aliviou custos Reuniões diárias dão ritmo ao projeto e incentivam a comunicação e a colaboração visando resolver impedimentos

73 Lições Aprendidas: Implementação Nível G Abordagem de Gerência de Projetos com Scrum (2/2) Realização de estimativas É preciso um tempo para compreender melhor o problema e estimar de forma mais adequada A velocidade inicial pode não ocorrer como o esperado Algumas práticas de estimativa podem ser adaptadas Papel do Scrum Master x Gerente de Projetos (GP) Scrum Master GP: papel diluído dentro da equipe nem todo o avaliador tem conseguido entender isso Papéis na equipe de desenvolvimento Em empresas com funções específicas é difícil implantar times Scrum de fato, onde todos fazem de tudo Cada integrante do time precisa saber exatamente o seu papel e seus limites de atuação

74 Lições Aprendidas: Implementação Nível G Cuidados com a gerência de requisitos e escopo A rastreabilidade dos requisitos até o código fica meio nebulosa com o conceito da estória A estória possui uma relação n para n com os requisitos e casos de uso e não é documentada em detalhes Apesar do Scrum propor escopo aberto, modelos de maturidade requerem definir um escopo, sendo necessário adaptá-lo Método ágil perde parte da agilidade em prol do modelo de maturidade e pode introduzir desperdício dependendo de como é feito

75 Lições Aprendidas: Implementação Nível F Considerações em relação ao nível F do MR-MPS Sugestão: manter equipes organizacionais para cada processo de apoio (GCO, GQA, MED) para todos os projetos Reduz o impacto destas atividades sobre o time do projeto, que pode realizar seu trabalho de forma ágil Participam das reuniões de planejamento da sprint para garantir o alinhamento ao processo e verificar potenciais conflitos A simples existência de auditoria de GQA Gerou o compromisso da equipe com a aderência às atividades realizadas e aos artefatos gerados segundo o novo processo Contribuiu para a institucionalização do novo processo A implantação da disciplina de MED Mostrou que a existência de métricas auxilia a identificação de impedimentos, podendo ajudar no planejamento da equipe Dificuldades apontadas com GCO e GQA Definir o momento certo de aplicação de baselines e o conteúdo das auditorias a realizar

76 Lições Aprendidas: Implementação Nível E Cuidados na definição dos processos O processo resultante tem que ter a cara da empresa, e não uma aplicação à risca do modelo ou método de referência Montar SEPG com conhecimentos diversificados Estar sempre aberto para buscar soluções inovadoras Não se apaixonar pelos processos Estar aberto a mudanças mesmo após uma avaliação bem sucedida Permitir que o processo se estabilize Necessário rodar nos projetos e colher medidas consistentes Preservar a adaptabilidade e flexibilidade da abordagem ágil Enfocar atividades de adaptação do processo para uso nos projetos Buscar suprir as necessidades geradas pelos processos Pesquisar por métodos e ferramentas alternativas Considerar também a interação existente entre os vários processos Utilizar ferramenta para documentar o processo

77 Lições Aprendidas: Implementação Nível D Cuidados com a engenharia Detalhar mais na hora de desenvolver e documentar de forma objetiva Conciliar interesses registrando melhor as evidências, porém sem preocupar em alcançar avaliação máxima (totalmente implementado) Buscar a documentação enxuta, com elementos essenciais Escolher arquiteturas descomplicadas acelera a programação por sempre procurar a simplicidade Passar a usar o XP não foi fácil, mas foi muito proveitoso o retorno Necessário mudar a forma de trabalhar e a postura da equipe Pressão de tempo e necessidade de ferramenta inibem o uso do XP Difícil gerar evidências das boas práticas do XP Outros resultados observados A propriedade coletiva do código Possibilitou disseminar o conhecimento pela equipe A liberação frequente de releases Aumentou a expectativa dos clientes por software rodando

78 Lições Aprendidas: Implementação Nível C Valores e práticas ajudam a gerenciar e mitigar riscos A busca da simplicidade diminui a complexidade O feedback antecipa a detecção de erros A comunicação aberta minimiza problemas de informação A quebra em iterações e o planejamento constante ajudam a controlar prazo e custos O cliente disponível e a entrega em releases diminuem o risco de se obter produtos inadequados Reuniões diárias de acompanhamento são muito úteis Possibilitam identificar mais cedo a iminência de um risco, permitindo atuar a tempo de minimizar suas conseqüências

79 Lições Aprendidas: Condução de Programas de Melhoria Para uma empresa ágil, porque não usar a abordagem ágil para a condução do Programa de Melhoria? Tratar a implementação de processos como um projeto, que envolva planejamento e acompanhamento nos moldes do Scrum Backlog do projeto de melhoria = lista priorizada das melhorias a serem implementadas nos processos Sprints = iterações de evolução dos processos (com backlog próprio) Cuidados a serem tomados Necessário maior envolvimento de todos, não apenas do SEPG Risco: falta de projetos para realizar testes pilotos Principal vantagem Desenvolver os processos aos poucos e ao mesmo tempo ir implantando na empresa

80 Lições Aprendidas: Avaliação Formal Percepções dos Avaliadores: pontos de atenção Evidências objetivas que precisam ser fornecidas para a avaliação e que em geral são desconsideradas na abordagem ágil Análises em geral (viabilidade, indicadores, riscos, impacto,... ) Comprometimento da equipe e envolvimento dos stakeholders Registro de participação e decisões tomadas em reuniões Tratamento de problemas (impedimentos, não conformidades,...) com acompanhamento de ações até o fechamento Divulgação em geral (políticas, baselines, resultados de auditoria,...) Critérios definidos (análise de viabilidade, aprovação de requisitos, verificações, validações, gerenciamento de ativos reutilizáveis,...) Aprovações (em especial as obtidas a partir de critérios definidos) Controles necessários e pouco destacados na abordagem ágil Apropriação de horas, coleta de medidas e dados do processo Planejamento / acompanhamento / uso de indicadores para atividades não técnicas (gerenciais e de apoio) Descrição de processos alinhada à prática realizada

81 Lições Aprendidas: Avaliação Formal Percepções de quem já foi Avaliado Querer seguir à risca um modelo de maturidade usando metodologias ágeis pode não ser uma boa idéia Em várias situações a empresa preferiu abrir mão de um resultado totalmente implementado por um largamente ou até mesmo parcialmente, em prol do uso de uma prática na qual acreditava O uso da abordagem ágil com MPS ainda desperta muita polêmica Ainda não é senso comum entre implementadores e avaliadores Há insegurança da empresa e do implementador em relação à experiência e conhecimento do avaliador sobre a abordagem ágil Necessidade / capacidade de abstrair evidências que não são necessariamente documentos é vista como um grande risco Tal insegurança aumenta a ansiedade pela avaliação Ainda é necessário obter mais experiência... Poucas empresas ágeis já foram avaliadas

82 CONCLUSÃO

83 Buscando o melhor dos dois mundos... Principais Fatores de Sucesso Grande apoio da Alta Direção Cultura da organização de comunicação, colaboração e feedback Perfil das pessoas: capacidade de adaptação e de aprendizado Motivação e comprometimento dos envolvidos Apoio adequado de consultoria especializada Visão: buscar o que há de bom nas abordagens, chegar ao equilíbrio Ter a avaliação como consequência e não como o principal da melhoria Principais Desafios e Dificuldades Atender ao modelo sem perder a agilidade e simplicidade existente Alocação de pessoas em múltiplos projetos Disponibilidade dos funcionários para atividades de melhoria Pressões dos projetos: compromissos assumidos com os clientes, compatibilidade de agendas

84 Buscando o melhor dos dois mundos... Principais resultados obtidos Melhor desempenho das equipes Maior comprometimento, entrosamento e motivação Maior qualidade do gerenciamento do projeto Maior controle do projeto e visibilidade dos resultados Maior disciplina e organização para o desenvolvimento A equipe sabe o que fazer para atingir os objetivos do projeto Aumento da qualidade do produto final e da satisfação do cliente Alinhamento com o uso pretendido e foco em resultado Todos as partes precisam ceder é inevitável que se perca um pouco da agilidade é inevitável ter que controlar / registrar / evidenciar mais Modelos de Maturidade - Maior previsibilidade - Maior estabilidade - Maior confiabilidade Abordagem Ágil - Otimiza o desenvolvimento - Maior adaptabilidade - Maior flexibilidade

85 Conclusão Manifesto Ágil: par de alternativas se reforçam processos e ferramentas podem melhor capacitar os indivíduos e interações documentação ajuda as pessoas a entenderem um negociação de contrato pode ser parte integrante da colaboração do cliente software complexo seguir um plano pode ser o melhor modo para responder a mudança, quando esta for previsível pessoas ativamente envolvidas e suas proposições de valor são fundamentais!

86 Conclusão Geral atender aos requisitos com menor custo dentro do prazo com mais qualidade PRODUZIR MELHOR SOFTWARE O QUE FAZER Normas e modelos existentes COMO FAZER Métodos Processos Ferramentas Apontam um caminho: Não uma linha de trem, mas um plano de vôo!

87 Agradecimento aos Colaboradores Alexandre Vasconcelos (UFPE) Ana Marcia Debiasi Duarte e Nikolai Dimittri (Innovit) Ana Sofia Marçal (UNIFOR) Anne Elise Katsurayama e Analia Irigoyen (Promove) Carlos Barbieri (FUMSOFT Cristiano Schwening (EngSoft) Eliane Collins (Nokia Technology Institute - INdT) Fernando Kenji Kamei (UFPE) Gleison Santos (COPPE/Unirio) José Maria Monteiro (UFC) Ludmila Roizenbruch (Lab Hermes Pardini) Marcello Thiry e Alessandra Zoucas (Incremental) Márcia Alves e Isabella Campos (PowerLogic) Marcilio Ferreira S. Júnior (IFAL) Maria das Dores Resende e Renato Sales (AAIS) Maria Istela Cagnin (UFMS) Odisnei Galarraga (Software Process) Rafael Prikladnicki (PUC-RS) Teresa Maciel (UFRPE)

88 Dúvidas??? José Orlando L. Q. Júnior