Lições Aprendidas na Implementação do MR-MPS utilizando a Abordagem Ágil

1. Lições Aprendidas na Implementação do MR-MPS utilizando a Abordagem Ágil Ana Liddy Cenni de Castro Magalhães Panorama Softsul Especial – Agosto/2010TECNOPUC – Porto Alegre

2. Motivação ... sofrem alterações visando melhorar ... As empresas em seus “ecossistemas”... ... com MPS e abordagem ágil... “água e óleo”?

3. Agenda • Conhecendo os “dois meios” • A Melhoria de Processos e o MPS.BR • O Pensamento Ágil • Comparativo Abordagem Tradicional x Ágil • Lições Aprendidas na Aplicação da Abordagem Ágil • Implementação do MR-MPS • Condução de Programas de Melhoria • Avaliação Formal • Conclusão

4. A Melhoria de Processos e o MPS.BR Manifesto pela Melhoria de Processo de Software Software ProcessImprovement(SPI) Manifesto “Nós acreditamos que 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 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 - 2010 - eurospi.net

5. 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 A Abordagem Tradicional de Melhoria Organização Macro-processos Processos Sub-Processos Atividades PMBOK ISO 9000 Tarefas MR-MPS CMMI Dev Modelos, NormasProcedimentos,Instruções,Registros, Indicadores Pessoas 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

6. A Melhoria de Processos Segundo o MPS.BR

7. O Pensamento Ágil: 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.” Fevereiro - 2001 - www.agilemanifesto.org

8. Principais características: Metodologia “leve”, de domínio público 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 A Abordagem Ágil para o Desenvolvimento:XP – Extreme Programming Kent Beck, Eric Gamma facilita “prestar contas”do valor “ponte” dá propósito à prática • Comunicação • Simplicidade • Feedback constante • Coragem • Respeito • Equipe multidisciplinar • Programação em par • Ciclos curtos • Desenv. orientado a testes • Integração contínua • ...

9. A Abordagem Ágil para o Desenvolvimento:Lean Programming Mary e Tom Poppendieck • Principais características • Abordagem “enxuta”, derivada do Sistema Toyota de Produção • Otimiza a produção pela eliminação de desperdício e automação inteligente • Abordagem Just in Time: produzir, transportar ou comprar na hora exata • Testada e experimentada em vários contextos nas duas últimas décadas • Principais práticas aplicadas a software • Eliminar desperdício: gerar só artefatos que agreguem valor ao produto final • Minimizar estoque: minimizar documentação e artefatos intermediários • Maximizar o fluxo: reduzir o ciclo de desenvolvimento • Produzir sob demanda: especificar o mais tarde possível, estar aberto à mudança • Dar autonomia à equipe: para se auto-organizar, tomar decisões • Atender requisitos do cliente: iniciar pelo mais crítico, ter feedback • Fazer certo da primeira vez: desenvolver orientado a testes,aplicar refactoring quando evoluir • Objetivo: maior qualidade, menor tempo e custo para a produção de software

10. A Abordagem Ágil para o Gerenciamento:APM - Agile Project Management Jim Highsmith et al. • Principais características: • Baseado em Sistemas Adaptativos Complexos • Comportamento e inteligência coletiva: revoadas, cardumes, enxames • Ênfase: ordem, auto-organização, adaptação a ambientes dinâmicos • Organizações: sistemas adaptáveis, com seres inteligentes • Confiança na habilidade coletiva para resolver problemas • Imprevisibilidade limita planejar: enfatizar a adaptabilidade • Principais práticas • Estabelecer e reforçar uma visão direcionadora • Reforçar relacionamentos e a colaboração da equipe • Estabelecer e apoiar um conjunto de regras simples • Fornecer acesso aberto à informação • Manter a ordem emergente,com vigilância ágil e adaptável

11. A Abordagem Ágil para o Gerenciamento:SCRUM Ken Schwaber 24 h 30 dias Backlog: lista priorizada de requisitos Product Backlog Sprint Backlog Sprint Incremento de trabalho do sw • Principais características • 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 • Principais práticas • Estimativa baseada em planning poker • Planejamento orientado a estórias • Reuniões diárias de acompanhamento • Reuniões de retrospectiva da Sprint • Gestão à vista

12. Abordagens Ágeis: Visão Crítica • Principais virtudes • Equipes integradas e colaborativas • Divisão de responsabilidades e papéis bem definidos • Forma de trabalho ágil e flexível • Possibilita inúmeras mudanças no decorrer do projeto • Foco em produtividade e resultado de valor • Minimiza riscos e maximiza qualidade • Principais críticas • Dificuldade de manutenção pela falta de documentação • Efetividade da programação em pares: custo x benefício • Dificuldade de se ter o cliente presente e envolvido • Dificuldade de estabelecer contrato com escopo variável • Requer colaboração e confiança entre equipe e cliente • Sucesso dependente da competência das pessoas • Restrições de escala (tamanho da equipe, local físico) • Necessidade de combinar abordagens (ex: XP e Scrum)

13. 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-lospossibilita garantir a qualidade Documentaçãogera 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 problemae 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çãotrabalhadores do conhecimento, ênfase: criatividade,flexibilidadeatenção às pessoas Abordagem Tradicional x Ágil: Diferenças Abordagem Tradicional Abordagem Ágil

14. Desenvolvedorhábil (variedade) Clientepouco envolvido Requisitosconhecidos, estáveis Retrabalho/reestruturaçãocaro Planejamentodireciona os resultados (incentiva controlar) Conjunto de processos, com metodologia definida Premiaa 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) Desenvolvedor ágil (colaborador) Cliente comprometido (autonomia) Requisitosemergentes, mutáveis Retrabalho/reestruturação barata Resultadosdirecionam o planejamento (incentiva mudar) Conjunto de valores, comatitudes 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 Abordagem Tradicional x Ágil: Diferenças Abordagem Tradicional Abordagem Ágil

15. Abordagem Tradicional x Ágil: Similaridades Necessário buscar o ponto de equilíbrio, avaliando riscos Planejamento aperfeiçoa a agilidade Agilidade dá eficiência ao planejamento • 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

16. Agenda • Conhecendo os “dois meios” • A Melhoria de Processos e o MPS.BR • O Pensamento Ágil • Comparativo Abordagem Tradicional x Ágil • Lições Aprendidas na Aplicação da Abordagem Ágil • Implementação do MR-MPS • Condução de Programas de Melhoria • Avaliação Formal • Conclusão

17. Colaboradores Alexandre Vasconcelos (UFPE) Ana Marcia Debiasi Duarte e Nikolai Dimittri (Innovit) Ana Sofia Marçal (UNIFOR) Anne Elise Katsurayama e Analia Irigoyen (Promove) 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)

18. Lições Aprendidas: 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. Lições Aprendidas: Implementação • Uso de ferramentas • Utilizar ferramenta de controle apropriada • Quadro + post-itdificulta 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)

25. 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

26. 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

27. 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 de scrum propor escopo aberto, modelos de maturidade requerem definir um escopo, sendo necessário adaptar o Scrum • Método ágil perde parte da agilidade em prol do modelo de maturidade e pode introduzir desperdício dependendo de como é feito

28. 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

29. 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 • Facilita a correção, evolução e a rápida liberação de novas releases

30. 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 • Possibilitou evoluir melhor a aplicação, de forma incremental

31. 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

32. 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

33. 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

34. Lições Aprendidas: Avaliação Formal • 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 • 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

35. Agenda • Conhecendo os “dois meios” • A Melhoria de Processos e o MPS.BR • O Pensamento Ágil • Comparativo Abordagem Tradicional x Ágil • Lições Aprendidas na Aplicação da Abordagem Ágil • Implementação do MR-MPS • Condução de Programas de Melhoria • Avaliação Formal • Conclusão

36. Buscando “o melhor dos dois meios”... • 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

37. Buscando “o melhor dos dois meios”... • 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 • 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

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

39. 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) 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)

40. ??Dúvidas ? ? Obrigado! analiddy@gmail.com