Gestão de Projetos de Software (5.ª Ed. At.) by Grupo Lidel

5.ª Edição Atualizada Esta obra apresenta uma abordagem metodológica precisa, rigorosa e moderna para a gestão de projetos de software, desde o momento inicial de planeamento estratégico até à entrega e operação do sistema. Tem como base as boas práticas recomendadas no PMBOK® Guide Fifth Edition (2012), no CMMI® e nas normas ISO 21500 e 10006. Integra as mais recentes perceções em termos de gestão de custos, prazos e recursos, engenharia de software e modelos de desenvolvimento ágil (capítulo autónomo e aumentado nesta nova edição), controlo de projetos e gestão da configuração.

5.ª Edição Atualizada

Mais compacta do que as suas antecessoras, esta nova edição está mais moderna, equilibrada e prática. Destina-se a todos os gestores de projeto e profissionais de software que pretendam implementar metodologias comprovadas de gestão de projetos nas suas organizações, bem como a professores e estudantes de licenciaturas em Engenharia Informática e Informática de Gestão e de cursos de pós-graduação e mestrados. Aborda, entre outros, os seguintes temas: • Enquadramento da gestão de projetos nas organizações; • Modelos de maturidade e o Project Management Office; • O CMMI® e a gestão de projetos; • Um modelo de gestão de projetos baseado no PMBOK® Guide; • O processo de planeamento: custos, prazos e recursos;

• Avaliação da exequibilidade de projetos; • Gestão dos riscos e da qualidade; • Gestão da configuração; • Gestão de recursos humanos; • Monitorização, controlo e encerramento do projeto; • Gestão do Valor Realizado; • Engenharia de software; • Metodologias ágeis de desenvolvimento de software.

Inclui, ao longo do livro, um conjunto significativo de diagramas, quadros, figuras e exemplos demonstrativos para melhor compreensão dos conceitos abordados. Nesta edição é disponibilizada uma lista de siglas, para uma leitura mais fluida do texto, bem como a correspondência dos principais termos técnicos para o português do Brasil e o inglês.

Textos complementares disponíveis na página do livro em www.fca.pt, até este se esgotar ou ser publicada nova edição atualizada ou com alterações.

ISBN 978-972-722-804-1

www.fca.pt

ANTÓNIO MIGUEL – Doutorado em Tecnologias e Sistemas de Informação, MBA e Engenheiro Eletrotécnico. Certificado em Gestão de Projetos pelo PMI (PMP ®), em Gestão do Risco pelo PMI (RMP ®) e pelo IRM (ICRM ®) e em Gestão da Mudança Organizacional (CMP ®) pelo Prosci Institute. Managing partner da PPMSKILLS, especialista em gestão de programas e de projetos e implementação de PMO, consultor, formador e professor universitário. Mais de 30 anos de experiência em empresas nacionais e multinacionais nas áreas de gestão de projetos, planeamento estratégico, marketing e gestão da qualidade. Autor dos livros Gestão Moderna de Projetos (7.ª Edição Atualizada e Aumentada), Avaliação de Projetos e Gestão do Risco e da Qualidade no Desenvolvimento de Software, e coautor do livro Gestão Emocional de Equipas – Em Ambiente de Projeto (5.ª Edição Atualizada), todos editados pela FCA.

com as recomendações do PMBOK Guide Fifth Edition • Alinhado (2012), do CMMI e das normas ISO 21500 e 10006 ®

com profundidade as metodologias de desenvolvimento • Aborda ágil e a engenharia de software

Distribuição

Lidel – edições técnicas, lda

Sede R. D. Estefânia, 183, R/C Dto. – 1049-057 LISBOA Tel: +351 213 511 448 * Fax: +351 213 522 684 Revenda: revenda@lidel.pt Exportação: depinternacional@lidel.pt Venda online: livraria@lidel.pt Marketing: marketing@lidel.pt

Livraria Av. Praia da Vitória, 14 – 1000-247 LISBOA Tel: +351 213 511 448 * Fax: +351 213 173 259 livraria@lidel.pt Edição

FCA – Editora de Informática

Av. Praia da Vitória, 14 – 1000-247 LISBOA Tel: +351 213 511 448 Email: fca@fca.pt

Copyright © janeiro 2015 (5.ª Edição Atualizada); maio 2008 (3.ª Edição Atualizada) FCA – Editora de Informática, Lda. ISBN: 978-972-722-804-1 Capa: Emília Calçada Impressão e acabamento: Tipografia Lousanense, Lda. – Lousã Depósito Legal N.º 386728/15 Livro segundo o Novo Acordo Ortográfico Todos os nossos livros passam por um rigoroso controlo de qualidade, no entanto, aconselhamos a consulta periódica do nosso site (www.fca.pt) para fazer o download de eventuais correções. Os nomes comerciais referenciados neste livro têm patente registada. Marcas Registadas de FCA – Editora de Informática, Lda. – ®

Reservados todos os direitos. Esta publicação não pode ser reproduzida, nem transmitida, no todo ou em parte, por qualquer processo eletrónico, mecânico, fotocópia, digitalização, gravação, sistema de armazenamento e disponibilização de informação, sítio Web, blogue ou outros, sem prévia autorização escrita da Editora, exceto o permitido pelo CDADC, em termos de cópia privada pela AGECOP – Associação para a Gestão da Cópia Privada, através do pagamento das respetivas taxas.

Índice Introdução ........................................................................................................................................ 1

Parte I − Enquadramento, Standards e Modelo de Gestão de Projetos de Software 1 – Enquadramento da Gestão de Projetos ................................................................................... 7 1.1 Definição de Projeto .................................................................................................................... 7 1.2 Projetos e Estratégia .................................................................................................................. 10 1.3 Diferenças entre Projetos de Software e Outros Projetos .......................................................... 10 1.4 Definição de Gestão de Projetos................................................................................................ 11 1.5 Restrições do Projeto ................................................................................................................. 12 1.5.1 Definição e Características.................................................................................................. 12 1.5.2 Deslizamento do Âmbito .................................................................................................... 13 1.5.3 Deslizamento do Esforço .................................................................................................... 13 1.5.4 Deslizamento da Funcionalidade ........................................................................................ 13 1.6 Influências Organizacionais nos Projetos .................................................................................. 14 1.6.1 Sistemas Organizacionais ................................................................................................... 14 1.6.2 Culturas e Estilos Organizacionais...................................................................................... 15 1.6.3 Estrutura Organizacional..................................................................................................... 16 1.7 Project Management Office....................................................................................................... 17 1.7.1 Objetivos do Project Management Office ........................................................................... 17 1.7.2 Necessidade de um Project Management Office................................................................. 18 1.7.3 Fornecimento de Gestores de Projeto ................................................................................. 19 1.7.4 Desenvolver os Gestores de Projeto .................................................................................... 22 1.8 Classificação dos Projetos ......................................................................................................... 23 1.9 O Sucesso dos Projetos de Software ......................................................................................... 24 1.9.1 Expectativas das Partes Interessadas ................................................................................... 25 1.9.2 Fatores Críticos de Sucesso dos Projetos de Software ........................................................ 27 1.9.3 A Curva do Esforço ............................................................................................................ 29 1.10 Papel e Responsabilidades do Gestor de Projeto ..................................................................... 30 2 – Normalização da Gestão de Projetos ..................................................................................... 33 2.1 Standards para os Projetos de Software..................................................................................... 33 2.2 Norma ANSI PMBOK® Guide .................................................................................................. 34 2.2.1 Ciclo de Vida dos Projetos de Software .............................................................................. 35 2.2.2 Características das Fases dos Projetos ................................................................................ 40 2.2.3 Ciclo de Vida do Produto .................................................................................................... 41 2.2.4 Processos da Gestão de Projetos ......................................................................................... 42 2.2.5 Grupos de Processos da Gestão de Projetos ........................................................................ 42 2.2.6 Áreas de Conhecimento da Gestão de Projetos ................................................................... 43 2.3 Norma ISO 21500 ..................................................................................................................... 46 2.4 Capability Maturity Model Integration ..................................................................................... 48 © FCA – Editora de Informática

III

Gestão de Projetos de Software

2.4.1 Enquadramento ................................................................................................................... 48 2.4.2 Cobertura dos Corpos de Conhecimento ............................................................................. 49 2.4.3 Compatibilização de Diferentes Abordagens ...................................................................... 51 2.4.4 Componentes das Áreas de Processo .................................................................................. 54 2.4.5 Relações entre Áreas de Processo ....................................................................................... 57 3 – Modelo de Gestão de Projetos de Software ........................................................................... 61 3.1 Fases do Desenvolvimento de Projetos de Software ................................................................. 61 3.1.1 Seleção e Avaliação do Projeto ........................................................................................... 63 3.1.2 Organização e Planeamento Detalhado do Projeto ............................................................. 63 3.1.3 Monitorização, Controlo e Encerramento do Projeto .......................................................... 66 3.1.4 Suporte Pós-instalação ........................................................................................................ 67 3.2 Pontos de Decisão entre Fases................................................................................................... 68 3.3 Repositório do Projeto ............................................................................................................... 69

Parte II − Seleção e Avaliação do Projeto 4 – Seleção Estratégica do Projeto ............................................................................................... 73 4.1 Planeamento Estratégico de Tecnologias e Sistemas de Informação ........................................ 73 4.2 Estratégia e Projetos .................................................................................................................. 74 4.2.1 Estratégia de TSI e Contribuição para o Negócio ............................................................... 75 4.2.2 Fases da Estratégia .............................................................................................................. 76 5 – Avaliação Financeira e Técnica do Projeto ........................................................................... 79 5.1 Introdução ................................................................................................................................. 79 5.2 Descrição da Fase ...................................................................................................................... 79 5.3 Avaliação Financeira do Projeto ............................................................................................... 81 5.3.1 Métodos de Avaliação ......................................................................................................... 82 5.4 Avaliação Técnica do Projeto .................................................................................................... 86 5.4.1 Fatores que Influenciam o Risco ......................................................................................... 87 5.4.2 Regras Globais do Risco nos Projetos ................................................................................ 87 5.4.3 Matriz de Avaliação dos Riscos .......................................................................................... 88 5.5 Relatório do Estudo de Exequibilidade ..................................................................................... 88 Parte III − Organização e Planeamento Detalhado do Projeto 6 – Definição dos Requisitos e do Âmbito do Projeto ................................................................. 93 6.1 Definição dos Requisitos do Projeto ......................................................................................... 93 6.2 Matriz de Rastreabilidade dos Requisitos ................................................................................. 94 6.3 Descrição do Âmbito do Projeto ............................................................................................... 95 6.4 Criação da Estrutura de Decomposição do Trabalho ................................................................ 97 6.4.1 Definição ............................................................................................................................. 97 6.4.2 Uso da EDT ...................................................................................................................... 100 6.4.3 Desenho da EDT ............................................................................................................... 101 6.4.4 Regras Básicas do Desenvolvimento da EDT/EDTC ....................................................... 101 6.4.5 EDT para Pequenos Projetos............................................................................................. 103 6.4.6 EDT Intermédia para Grandes Projetos ............................................................................ 104 6.4.7 Critérios de Integridade da EDT ....................................................................................... 104 6.4.8 Criação da EDT................................................................................................................. 107 IV

Índice

6.4.9 Representação da EDT ...................................................................................................... 108 7 – Estimativa de Prazos, Recursos e Custos ............................................................................ 111 7.1 O Problema em Perspetiva ...................................................................................................... 111 7.2 Dificuldade das Estimativas .................................................................................................... 113 7.3 Quem Deve Estimar?............................................................................................................... 114 7.4 Estimar a Partir da EDT .......................................................................................................... 114 7.4.1 Estimar o Esforço para a Realização das Atividades ........................................................ 115 7.4.2 Variabilidade do Esforço .................................................................................................. 115 7.4.3 Métodos para Estimar o Esforço das Atividades............................................................... 116 7.5 Estimar a Duração das Atividades ........................................................................................... 119 7.5.1 Duração de um Projeto ...................................................................................................... 119 7.5.2 Número de Recursos versus Duração da Atividade .......................................................... 120 7.6 Determinar os Requisitos de Recursos .................................................................................... 121 7.7 Estimar o Custo ....................................................................................................................... 121 7.8 Técnicas para Estimar o Esforço ............................................................................................. 121 7.8.1 Análise dos Pontos de Função .......................................................................................... 123 7.9 Estimar a Partir de Uma Data de Fim Fixada .......................................................................... 126 7.10 Precisão das Estimativas ....................................................................................................... 126 7.11 Compreender os Compromissos ............................................................................................ 128 7.12 Estimar Projetos de Manutenção e Novos Desenvolvimentos .............................................. 131 7.13 Estimar Pequenos Projetos .................................................................................................... 131 7.14 Estimar um Projeto num Novo Domínio ............................................................................... 132 7.15 Aptidão para Desenvolver Software ...................................................................................... 132 7.16 Algumas Sugestões Úteis ...................................................................................................... 133 8 – Construção do Cronograma do Projeto .............................................................................. 135 8.1 Diagrama de Rede do Projeto .................................................................................................. 135 8.2 Método do Caminho Crítico .................................................................................................... 136 8.2.1 Técnica da Atividade na Seta ............................................................................................ 137 8.2.2 Método do Diagrama de Precedência ............................................................................... 139 8.2.3 Criação de um Cronograma Inicial do Projeto .................................................................. 145 8.2.4 Cálculo do Caminho Crítico ............................................................................................. 148 8.2.5 Caminho Quase Crítico ..................................................................................................... 150 8.3 Análise da Rede Inicial do Projeto .......................................................................................... 151 8.3.1 Compressão do Prazo ........................................................................................................ 151 8.3.2 Reserva de Contingência ................................................................................................... 152 8.4 Disponibilidade de Recursos ................................................................................................... 153 8.4.1 Nivelamento de Recursos.................................................................................................. 154 8.4.2 Estratégias Comuns de Nivelamento de Recursos ............................................................ 154 8.4.3 Estratégias Alternativas de Calendarização de Atividades ............................................... 156 9 – Gestão do Risco do Projeto ................................................................................................... 159 9.1 Introdução ............................................................................................................................... 159 9.2 Natureza do Risco ................................................................................................................... 160 9.3 Processos da Gestão do Risco ................................................................................................. 161 9.3.1 Planeamento da Gestão dos Riscos ................................................................................... 162 © FCA – Editora de Informática V

Gestão de Projetos de Software

9.3.2 Identificação dos Riscos.................................................................................................... 163 9.3.3 Avaliação Qualitativa dos Riscos...................................................................................... 166 9.3.4 Avaliação Quantitativa dos Riscos.................................................................................... 168 9.3.5 Planeamento das Respostas aos Riscos ............................................................................. 174 9.3.6 Monitorização e Controlo dos Riscos ............................................................................... 175 9.4 Conclusão e Recomendações .................................................................................................. 175 10 – Gestão da Qualidade do Projeto ........................................................................................ 177 10.1 Introdução.............................................................................................................................. 177 10.2 Custo da Qualidade ............................................................................................................... 178 10.3 Atributos da Qualidade.......................................................................................................... 179 10.4 Norma ISO 10006/2006 ........................................................................................................ 181 10.4.1 Objetivos ......................................................................................................................... 181 10.4.2 Princípios da Gestão da Qualidade ................................................................................. 181 10.5 Sistema da Qualidade do Software ........................................................................................ 185 10.5.1 Normas ............................................................................................................................ 186 10.5.2 Revisões e Testes ............................................................................................................ 186 10.5.3 Gestão da Configuração .................................................................................................. 187 10.5.4 Formação ........................................................................................................................ 188 10.5.5 Gestão de Fornecedores e Subcontratados ...................................................................... 188 10.6 Implementação do Sistema da Qualidade .............................................................................. 189 10.7 Métricas da Qualidade ........................................................................................................... 190 10.7.1 Métricas do Produto ........................................................................................................ 190 10.7.2 Métricas do Processo ...................................................................................................... 191 10.7.3 Métricas Orientadas para os Objetivos do SQS .............................................................. 191 10.7.4 Características das Métricas ............................................................................................ 192 11 – Gestão das Comunicações e das Partes Interessadas ....................................................... 195 11.1 Introdução.............................................................................................................................. 195 11.2 Processo da Gestão das Partes Interessadas........................................................................... 195 11.2.1 Identificação e Avaliação das Partes Interessadas .......................................................... 196 11.3 Tipos de Comunicações no Projeto ....................................................................................... 198 11.4 Barreiras à Comunicação....................................................................................................... 199 11.5 Processo das Comunicações .................................................................................................. 201 11.6 Estrangulamentos na Gestão de Projetos ............................................................................... 203 11.7 Armadilhas da Comunicação ................................................................................................. 204 12 – Gestão da Configuração ...................................................................................................... 207 12.1 Introdução.............................................................................................................................. 207 12.2 Componentes da Gestão da Configuração ............................................................................. 208 12.2.1 Identificação da Configuração ........................................................................................ 209 12.2.2 Controlo da Configuração ............................................................................................... 209 12.2.3 Registo da Configuração ................................................................................................. 210

Parte IV − Monitorização, Controlo e Encerramento do Projeto 13 – Monitorização e Controlo do Projeto ................................................................................ 215 13.1 Enquadramento...................................................................................................................... 215 13.1.1 Objetivo dos Controlos ................................................................................................... 216 VI

Índice

13.1.2 Equilíbrio do Sistema de Controlo .................................................................................. 216 13.2 Verificação e Validação ........................................................................................................ 217 13.2.1 Revisões .......................................................................................................................... 218 13.2.2 Testes .............................................................................................................................. 228 13.2.3 Planeamento e Execução dos Testes ............................................................................... 234 13.3 Relatórios de Progresso ......................................................................................................... 235 13.3.1 Tipos de Relatórios de Progresso .................................................................................... 236 13.3.2 Tipos de Informação a Relatar ........................................................................................ 240 13.3.3 Frequência dos Relatórios de Progresso.......................................................................... 243 13.3.4 Desvios............................................................................................................................ 243 13.4 Relatórios Gráficos ................................................................................................................ 244 13.4.1 Gráficos de Gantt ............................................................................................................ 244 13.4.2 Gráficos de Marcos ......................................................................................................... 244 13.5 Nível de Detalhe dos Relatórios ............................................................................................ 249 13.5.1 Gestor de Equipa ............................................................................................................. 249 13.5.2 Gestor de Projeto............................................................................................................. 249 13.5.3 Gestão de Topo ............................................................................................................... 249 13.6 Reuniões de Revisão do Projeto ............................................................................................ 250 13.7 Escalada de Problemas .......................................................................................................... 251 13.7.1 Estratégias ao Nível do Gestor de Projeto ....................................................................... 252 13.7.2 Estratégias ao Nível do Gestor de Recursos.................................................................... 252 13.7.3 Estratégias ao Nível do Cliente ....................................................................................... 252 13.7.4 Hierarquia da Estratégia de Escalada .............................................................................. 253 13.7.5 Reuniões de Gestão de Problemas .................................................................................. 254 14 – Gestão do Valor Realizado ................................................................................................. 255 14.1 Introdução.............................................................................................................................. 255 14.2 Conceito de Valor Realizado ................................................................................................. 256 14.2.1 Conceitos Básicos ........................................................................................................... 258 14.3 Gestão do Valor Realizado e Gestão do Risco ...................................................................... 260 14.3.1 Definição dos Pacotes de Trabalho ................................................................................. 261 14.3.2 Inspeções de Software e Definição dos Pacotes de Trabalho.......................................... 262 14.3.3 Estimar Recursos da Tarefa ............................................................................................ 263 14.3.4 Uso do Valor Realizado na Estimativa do Custo e do Prazo .......................................... 264 14.3.5 Determinação do Valor Realizado .................................................................................. 264 14.3.6 Inspeções do Software e Progresso das Tarefas .............................................................. 265 14.4 Indicadores do Desempenho do EVM ................................................................................... 265 14.5 Conclusão .............................................................................................................................. 266 15 – Gestão das Alterações ao Projeto ....................................................................................... 267 15.1 Objetivos ............................................................................................................................... 267 15.2 Âmbito e Impacto .................................................................................................................. 268 15.2.1 Âmbito da Alteração ....................................................................................................... 268 15.2.2 Benefícios da Alteração .................................................................................................. 269 15.2.3 Efeitos nos Recursos ....................................................................................................... 269 15.2.4 Efeitos no Desempenho .................................................................................................. 269 © FCA – Editora de Informática

VII

Gestão de Projetos de Software

15.2.5 Impacto Noutras Áreas.................................................................................................... 270 15.2.6 Riscos .............................................................................................................................. 270 15.3 Revisão e Autorização ........................................................................................................... 270 15.3.1 Quem Revê e Autoriza .................................................................................................... 270 15.3.2 Como Rever e Autorizar ................................................................................................. 270 15.3.3 Quando Rever e Autorizar .............................................................................................. 272 15.4 Planeamento e Implementação .............................................................................................. 272 16 – Encerramento do Projeto.................................................................................................... 275 16.1 Enquadramento...................................................................................................................... 275 16.2 Encerramento Administrativo ............................................................................................... 276 16.2.1 Resultados/Entregáveis ................................................................................................... 276 16.3 Encerramento dos Contratos.................................................................................................. 277 16.4 Lições Aprendidas ................................................................................................................. 277 16.4.1 Objetivos ......................................................................................................................... 277 16.4.2 Relatório de Encerramento do Projeto ............................................................................ 278 16.5 Conclusão .............................................................................................................................. 281

Parte V − Aspetos Fundamentais da Gestão de Equipas em Ambiente de Projeto 17 – Formação de Uma Nova Equipa ........................................................................................ 285 17.1 O Desafio da Formação de Equipas ...................................................................................... 285 17.2 Espírito de Equipa: Um Processo Contínuo .......................................................................... 287 17.3 Armadilhas da Gestão ........................................................................................................... 289 18 – Liderança de Equipas ......................................................................................................... 291 18.1 Enquadramento...................................................................................................................... 291 18.2 Estilos de Liderança .............................................................................................................. 291 18.3 Teoria da Liderança Situacional ............................................................................................ 293 18.4 Liderança Eficaz .................................................................................................................... 296 18.5 Impacto Organizacional da Liderança ................................................................................... 297 18.6 Características Comuns em Líderes Eficazes ........................................................................ 297 19 – Delegação de Tarefas........................................................................................................... 299 19.1 Introdução.............................................................................................................................. 299 19.2 Barreiras à Delegação ............................................................................................................ 299 19.3 Vantagens da Delegação ....................................................................................................... 300 19.4 Estilos de Delegação ............................................................................................................. 300 19.4.1 Delegação Por Resultados Esperados ............................................................................. 300 19.4.2 Delegação Por Definição de Funções.............................................................................. 301 19.5 Como Delegar ....................................................................................................................... 301 19.6 Princípios Cardinais da Delegação ........................................................................................ 302 20 – Motivação de Equipas ......................................................................................................... 303 20.1 Natureza da Motivação .......................................................................................................... 303 20.2 Um Modelo Simplificado da Motivação ............................................................................... 304 20.2.1 Teorias das Necessidades ................................................................................................ 305 20.2.2 Teorias Cognitivas .......................................................................................................... 310 20.3 A Motivação na Prática ......................................................................................................... 314 20.3.1 As Pessoas Individualmente............................................................................................ 314 VIII

Índice

20.3.2 A Equipa ......................................................................................................................... 314 20.4 Conclusão .............................................................................................................................. 315 21 – Gestão de Conflitos.............................................................................................................. 317 21.1 Introdução.............................................................................................................................. 317 21.2 Como Se Chega ao Conflito .................................................................................................. 317 21.3 Onde Pode Ocorrer o Conflito ............................................................................................... 319 21.4 Sintomas do Conflito ............................................................................................................. 319 21.5 Reduzir e Resolver o Conflito ............................................................................................... 319 21.5.1 Alterar os Fatores Situacionais........................................................................................ 320 21.5.2 Apelar para Objetivos de Ordem Superior ...................................................................... 320 21.5.3 Uso de um Modo Interpessoal......................................................................................... 320 21.6 Conclusão .............................................................................................................................. 322

Parte VI − Engenharia de Software e Modelos Ágeis de Desenvolvimento 22 – Modelos de Desenvolvimento de Engenharia de Software............................................... 325 22.1 Enquadramento...................................................................................................................... 325 22.2 Visão Global do Desenvolvimento de Software.................................................................... 326 22.2.1 Fases do Desenvolvimento.............................................................................................. 327 22.2.2 Modelo Genérico do Processo de Desenvolvimento ....................................................... 329 22.3 Modelos de Desenvolvimento Clássicos ............................................................................... 330 22.3.1 Modelo em Cascata ......................................................................................................... 331 22.3.2 Modelo em V .................................................................................................................. 334 22.4 Modelos de Desenvolvimento Evolutivos ............................................................................. 336 22.4.1 Modelo Estruturado de Prototipagem ............................................................................. 336 22.4.2 Modelo de Entregas Incrementais ................................................................................... 340 22.4.3 Modelo em Espiral .......................................................................................................... 341 23 – Modelos Ágeis de Desenvolvimento de Software .............................................................. 345 23.1 Enquadramento...................................................................................................................... 345 23.2 Ciclo de Vida Genérico do Desenvolvimento Ágil ............................................................... 346 23.3 Modelos Ágeis e Modelos Tradicionais – Diferenças ........................................................... 348 23.3.1 Abordagem Iterativa versus Abordagem Sequencial ...................................................... 348 23.3.2 Alteração do Paradigma das Restrições .......................................................................... 349 23.3.3 Priorização das Funcionalidades a Implementar ............................................................. 350 23.3.4 Outras Diferenças............................................................................................................ 352 23.4 Dynamic Systems Development Method Atern ...................................................................... 353 23.4.1 Fases do Modelo ............................................................................................................. 353 23.4.2 Premissas-Base do Modelo ............................................................................................. 355 23.4.3 Princípios do Modelo ...................................................................................................... 355 23.4.4 Intervenientes no Modelo de Desenvolvimento – Papéis e Responsabilidades .............. 357 23.4.5 Técnicas Utilizadas no DSDM Atern .............................................................................. 359 23.4.6 Fatores Críticos de Sucesso do DSDM Atern ................................................................. 360 23.5 Extreme Programming .......................................................................................................... 361 23.5.1 Criação de uma Solução Spike ........................................................................................ 363 23.5.2 Desenvolvimento de User Stories ................................................................................... 364 23.5.3 Desenvolvimento Iterativo .............................................................................................. 365 © FCA – Editora de Informática

Gestão de Projetos de Software

23.5.4 Velocidade do Projeto ..................................................................................................... 366 23.5.5 Movimentar as Pessoas ................................................................................................... 366 23.5.6 Regras e Práticas do Método XP ..................................................................................... 367 23.5.7 Aspetos Controversos do Método XP ............................................................................. 368 23.5.8 Quando Usar o Método XP ............................................................................................. 369 23.6 Scrum..................................................................................................................................... 369 23.6.1 Características ................................................................................................................. 370 23.6.2 Iterações de Trabalho (Sprints) ....................................................................................... 371 23.6.3 Reuniões do Scrum ......................................................................................................... 374 23.6.4 Artefactos do Scrum ........................................................................................................ 378 23.6.5 Gestão do Risco .............................................................................................................. 379 23.7 Análise Comparativa dos Modelos Ágeis ............................................................................. 383

Lista de Siglas, Glossários, Bibliografia e Índice Remissivo Lista de Siglas .............................................................................................................................. 387 Glossário....................................................................................................................................... 393 Glossário de Termos Português Europeu/Português do Brasil/Inglês .................................... 417 Bibliografia e Referências Bibliográficas .................................................................................. 421 Índice Remissivo .......................................................................................................................... 431

Introdução De acordo com dados da Gartner e outras agências de pesquisa, as despesas com projetos de software e de Tecnologias de Informação (TI) representam mais de 25% das despesas totais com projetos de todos os tipos, no mundo inteiro. Nas principais economias do mundo, milhões de pessoas trabalham nos setores das TI e de software, sendo expectável que este número aumente significativamente nos próximos anos, tendo em conta o rápido crescimento deste setor. Em que consiste a gestão de projetos de software e o que a distingue da gestão de outros tipos de projetos? Como o software é utilizado em muitas indústrias e, cada vez mais, nas nossas vidas diárias, ele tornou-se parte da maioria das coisas que vemos ou com que interagimos. Os nossos veículos agora têm computadores. Os nossos objetos de uso diário – sistemas de música, sistemas de ar condicionado, máquinas de lavar, telemóveis, etc. – agora possuem um tipo qualquer de computador incorporado. Nas fábricas e linhas de montagem usam-se sofisticados robôs industriais com avançados sistemas de controlo por software. Uma das indústrias em que mais se investe em TI é a indústria das telecomunicações – em especial aplicações para smartphones e tablets. Assim, um projeto de software ou de TI poderá ser a implementação de um sistema de Enterprise Resource Planning (ERP) abrangendo uma empresa inteira, destinado a possibilitar capacidades de business intelligence, gerir operações de armazenamento, gerir operações de produção, etc. As tarefas envolvidas num projeto desse tipo incluirão o desenvolvimento de sistemas de software, a aquisição do hardware onde o software irá funcionar, a instalação do software nos equipamentos informáticos, a preparação e instalação de redes de computadores e finalmente a configuração do sistema de software de modo que ele possa funcionar na rede de computadores. Um outro projeto de desenvolvimento de software poderá consistir no desenvolvimento de uma aplicação à medida, baseada em requisitos específicos de um cliente e a sua implementação em código-fonte. Este código-fonte é depois testado para assegurar que não tem erros e que pode ser usado pelos utilizadores finais sem problemas de maior. Num projeto de manutenção evolutiva, um software já existente pode ser modificado para remover erros e defeitos, adicionar novas funcionalidades, transitá-lo para outro sistema operativo, etc. Os projetos de desenvolvimento de software requerem não apenas aptidões de gestão de projetos, mas igualmente boas aptidões de engenharia de software. O objetivo de qualquer projeto de desenvolvimento de software é o desenvolvimento/manutenção de um produto de software através da aplicação dos bons princípios da gestão de projetos e da engenharia de software, de modo que o projeto seja realizado com o mínimo custo, no mínimo prazo e com a melhor qualidade do produto final. © FCA – Editora de Informática

Gestão de Projetos de Software

Os bons princípios da gestão de projetos assegurarão uma boa produtividade. Por seu turno, os bons princípios da engenharia de software garantirão uma boa qualidade do produto final. Atualmente, os projetos exigem uma integração e inovação muito mais apertadas do que durante a última década, o que, só por si, obriga ao uso de formas mais criativas de desenho, construção, teste e implementação de produtos e serviços. Um gestor já não pode criar um cronograma de um projeto apenas através do preenchimento de um ou dois formulários. As empresas exigem muito mais dos seus projetos, do que antes. Uma forma de alcançar um resultado mais eficiente é adotar metodologias de projeto mais modernas, mais ágeis e mais “leves”. Para resolver os problemas históricos, os gestores de projeto e os executivos têm de ser inovadores e criativos. Como referido anteriormente, as atividades de um projeto de software abarcam duas dimensões principais: engenharia e gestão de projeto. A dimensão da engenharia trata da construção do sistema e concentra-se em questões como modelizar, codificar, testar, etc.; a dimensão da gestão de projeto trata do adequado planeamento e controlo das atividades de engenharia com o objetivo de satisfazer os objetivos para o prazo, o custo e a qualidade do projeto. Se um projeto é pequeno – digamos, uma ou duas pessoas a trabalhar durante uma ou duas semanas – ele pode ser executado de modo algo informal. O plano do projeto pode ser um email especificando a data de entrega requerida e talvez alguns marcos (milestones) intermédios. Os requisitos poderão ser igualmente comunicados num email, ou mesmo verbalmente numa reunião, e os produtos intermédios do trabalho, como documentos de desenho, poderão ser rascunhos em blocos de notas pessoais. No entanto, estas técnicas informais não se adequam a projetos de maior dimensão em que um grupo grande de pessoas poderá trabalhar durante diversos meses – o que corresponde à grande maioria dos projetos comerciais. Neste tipo de projetos cada tarefa de engenharia tem de ser cuidadosamente realizada seguindo metodologias bem testadas, e os produtos do trabalho têm de ser cuidadosamente documentados de modo que outros os possam rever. As tarefas no projeto têm de ser cuidadosamente planeadas e atribuídas a elementos do projeto, e depois monitorizadas à medida que são executadas. Por outras palavras, para executar com sucesso projetos de maior dimensão, o rigor e a formalidade destas duas dimensões tem de aumentar. A formalidade requer o uso de processos bem definidos para a realização das diversas tarefas, de modo que o resultado se torna mais dependente da adequação dos processos. A formalidade é ainda mais aumentada se forem usadas abordagens quantitativas nos processos através do uso de métricas apropriadas. O que é um processo? Tecnicamente, um processo para uma tarefa compreende uma sequência de passos que têm de ser seguidos para executar a tarefa. Numa organização, contudo, os processos que são recomendados aos seus engenheiros de software e gestores de projeto são muito mais do que uma sequência de passos; eles encapsulam aquilo que os engenheiros e gestores de projeto aprenderam ao longo do tempo sobre executar, com sucesso, projetos. Através do processo, os benefícios da experiência são transferidos a 2

Introdução

todos, incluindo novos membros da organização. Estes processos ajudam gestores e engenheiros a emular sucessos passados e a evitar armadilhas que possam conduzir a insucessos. É o conceito de boas práticas e de lições aprendidas. Para um projeto, os processos de engenharia, regra geral, especificam como realizar atividades de engenharia como definição de requisitos, desenho, testes, etc. Os processos de gestão de projeto, por seu turno, especificam como estabelecer marcos (milestones), organizar a equipa, gerir os riscos, monitorizar o progresso, etc. Este livro focaliza-se nos processos de gestão do projeto. O livro está organizado em sete partes: Parte I – Enquadramento, Standards e Modelo de Gestão de Projetos de Software Nesta parte analisam-se as características dos projetos e da gestão de projetos nos dias de hoje, bem como o papel das organizações de normalização da gestão de projetos, como o PMI®, a ISO/IEC e o SEI® (Capítulos 1 e 2), e apresenta-se um modelo de gestão de projetos de software cobrindo o ciclo de vida completo do projeto – desde a seleção estratégica do projeto, até à entrega e auditoria pós-implementação (Capítulo 3). Parte II – Seleção e Avaliação do Projeto Analisam-se aqui as metodologias e ferramentas adequadas para a seleção estratégica de projetos de sistemas de informação (SI), de acordo com a estratégia do negócio (Capítulo 4), e para a avaliação financeira e técnica do projeto (Capítulo 5). Parte III – Organização e Planeamento Detalhado do Projeto Nesta parte dissecam-se as etapas, metodologias e ferramentas da fase de definição detalhada (planeamento) do projeto, que se segue às etapas de seleção e avaliação. O primeiro tema abordado é o da definição dos requisitos e do âmbito do projeto (Capítulo 6), em que se analisam os objetivos da definição dos requisitos, bem como os conceitos de matriz de rastreabilidade e a Estrutura de Decomposição do Trabalho (EDT)1, entre outros. Seguem-se metodologias para estimar os prazos, recursos e custos (Capítulo 7) e a construção do cronograma do projeto (Capítulo 8). Finalmente, analisam-se os temas da gestão do risco (Capítulo 9), gestão da qualidade (Capítulo 10), gestão da comunicação e das partes interessadas (Capítulo 11) e da gestão da configuração (Capítulo 12). Parte IV – Monitorização, Controlo e Encerramento do Projeto O projeto foi devidamente planeado e iniciaram-se os trabalhos do desenvolvimento. É necessário monitorizar e controlar a execução do trabalho. O Capítulo 13 trata dos mecanismos de monitorização e controlo do projeto e aborda os temas do controlo

Na norma NP ISO 21500 a Work Breakdown Structure é oficialmente traduzida por Estrutura de Decomposição do Trabalho (EDT). Utilizaremos doravante o termo da norma portuguesa para designar a Work Breakdown Structure.

Gestão de Projetos de Software

da qualidade, dos relatórios de progresso, das reuniões de revisão do projeto e da escalada de problemas. No Capítulo 14 aborda-se o método de controlo de projetos através da gestão do valor realizado (Earned Value Management) e no Capítulo 15 dão-se orientações para uma implementação correta e eficaz de um sistema de gestão das alterações ao projeto. Finalmente, no Capítulo 16 analisa-se a fase de encerramento do projeto, uma fase importante em todo o ciclo de vida do projeto, evidenciando-se a importância de uma análise post mortem e da elaboração e análise do relatório de encerramento. Parte V – Aspetos Fundamentais da Gestão de Equipas em Ambiente de Projeto Uma componente fundamental da gestão de projetos é a gestão de recursos humanos. Nesta parte apresentam-se ideias para a formação de uma nova equipa (Capítulo 17) e analisam-se alguns dos aspetos mais importantes da gestão de equipas em ambiente de projeto – liderança (Capítulo 18), delegação de autoridade (Capítulo 19), motivação da equipa (Capítulo 20) e gestão de conflitos (Capítulo 21). Parte VI – Engenharia de Software e Modelos Ágeis de Desenvolvimento Nesta parte analisam-se, com algum detalhe, no Capítulo 22, as opções de engenharia de software que se colocam às equipas de projeto e comparam-se os diversos modelos existentes, desde os clássicos – em cascata e em V – até aos denominados modelos evolutivos – prototipagem, entregas incrementais e em espiral. No Capítulo 23 apresentam-se uma descrição e uma análise comparativa dos modelos ágeis de desenvolvimento de software mais utilizados – DSDM Atern, Extreme Programming (XP) e Scrum. Lista de Siglas, Glossários, Bibliografia e Índice Remissivo Nesta parte apresenta-se: uma lista com as siglas utilizadas ao longo do livro; um glossário de termos correspondentes em Português Europeu, Português do Brasil e Inglês; um glossário com os principais termos técnicos empregues ao longo do livro; um conjunto de obras que serviram como referência para o tratamento dos temas; e um índice remissivo que permitirá ao leitor encontrar o tema que mais lhe interessa através das palavras-chave. Os temas tratados são acompanhados por figuras, tabelas e quadros exemplificativos.

Normalização da Gestão de Projetos 2 – Normalização da Gestão de Projetos

2.1 Standards para os Projetos de Software Os processos e procedimentos de muitas organizações de serviços e de desenvolvimento de software são baseados nos standards produzidos pelos comités conjuntos da International Standards Organization (ISO), da International Electrotechnical Commission (IEC) e do Institute for Electrical and Electronic Engineers (IEEE) para a engenharia de software, no PMBOK® Guide do Project Management Institute (PMI) e nos Capability Maturity Models Integrated (CMMI) do Software Engineering Institute (SEI). Alguns standards ISO/IEC e IEEE que foram harmonizados e emitidos como standards conjuntos (ISO/IEC/IEEE) incluem: • ISO/IEC/IEEE 12207 – Systems and software engineering – Software project life cycle processes; • ISO/IEC/IEEE 16326 – Systems and software engineering – Life cycle processes – Project management. Os CMMI, desenvolvidos e mantidos pelo SEI incluem: • CMMI for Development (CMMI-DEV); • CMMI for Services (CMMI-SVC); • CMMI for Acquisition (CMMI-ACQ). Estes modelos serão explicados ao longo do capítulo. Em 2013, o PMI e a IEEE Computer Society lançaram em conjunto um novo standard dedicado aos projetos de desenvolvimento de software – o Software Extension to the PMBOK® Guide Fifth Edition. O principal contributo desta extensão ao PMBOK® Guide é a descrição de processos que são aplicáveis à gestão de projetos de software com ciclos de vida adaptativos. Os métodos de desenvolvimento adaptativos e os ciclos de vida ajustam-se bem ao desenvolvimento de software e à gestão de projetos de software, porque tiram partido da natureza intangível do software. Usados em conjunto, o PMBOK® Guide e essa extensão fornecem uma visão equilibrada de métodos, ferramentas e técnicas para a gestão de projetos de software, adaptáveis aos diversos ciclos de vida desde os altamente previsíveis (modelos em cascata) até aos altamente adaptativos (modelos ágeis).

Gestão de Projetos de Software Ciclo de vida do desenvolvimento de software Implementação Testes Desenvolvimento

Estágios da gestão de projetos Encerrar

Desenho

Monitorizar e controlar

Requisitos Definição e justificação

Executar Planear

Iniciar Integração Âmbito Tempo Custo Qualidade Recursos humanos Comunicações Responsabilidades Partes interessadas da gestão de projetos Aquisições Risco

Figura 2.7 – Dimensões da gestão e desenvolvimento de projetos de software

2.3 Norma ISO 21500 A norma ISO 21500 – Guidance on Project Management foi oficialmente lançada em agosto de 2012. Pouco tempo depois foi lançada a versão Portuguesa da norma, a NP ISO 21500 – Guia para a Gestão de Projetos. As duas normas – ANSI e ISO – são muito semelhantes. Ambas apresentam um conjunto de processos organizados de modo idêntico, por fase da gestão do projeto e tópico da gestão e projetos. Os processos da ISO são mais orientados para uma abordagem em cascata da definição do âmbito, ao invés de uma abordagem iterativa. Deste modo, a norma ISO será eventualmente menos atrativa para as organizações orientadas para as metodologias Agile (ágeis). Ambos os standards – ANSI e ISO – estão estruturados em estágios da gestão de projetos (não em fases do projeto) e tópicos da gestão de projetos (áreas de conhecimento no PMBOK® Guide e grupos temáticos na ISO 21500). A Tabela 2.1 mostra os 39 processos da ISO 21500 e o respetivo agrupamento por grupos temáticos e grupos de processos.

Monitorização e Controlo do Projeto

uma pista sobre o nível de controlo a implementar. No ponto 13.4.2, iremos analisar estas situações com o gráfico de marcos. É muito fácil deixarmo-nos arrebatar por controlos e relatórios. Quanto mais controlos forem implementados, menor o risco do projeto e menor a probabilidade de o projeto vir a ter problemas. No entanto, como se mostra na Figura 13.1, existe um ponto a partir do qual a rentabilidade decresce. À parte o risco, existe outro impacto a considerar: para se ajustarem aos controlos do projeto, os membros da equipa terão de despender tempo a preparar e defender relatórios de progresso, diminuindo assim o tempo que dedicam ao trabalho do projeto. €

Custo Total

Controlo

Risco Tempo

Figura 13.1 – Custo total do controlo e do risco (adaptado de: [Vijay, 1995])

O gestor de projeto necessita de encontrar um equilíbrio entre a profundidade do sistema de controlo e o risco de resultados desfavoráveis. À semelhança da indústria de seguros, comparar o custo da apólice com o valor monetário da perda que resultará das consequências. Concetualmente, existe um ponto de equilíbrio que minimiza a exposição do custo total de ter escolhido um nível de controlo particular. O controlo implica igualmente rigidez e estrutura, e ambas tendem a limitar a criatividade. O gestor de projeto deve permitir aos membros da equipa alguma latitude para exercerem a sua individualidade. O custo do controlo deve ser ponderado face ao valor de dar poder aos membros da equipa para serem pró-ativos – e, portanto, assumirem riscos.

13.2 Verificação e Validação No desenvolvimento de software não podemos dar-nos ao luxo de ir até ao fim do processo de produção sem antes verificar se atingimos aquilo que propusemos atingir, isto é, sem verificar se o nosso produto de software funciona. É necessário realizar verificações de controlo da qualidade em cada etapa do desenvolvimento, idealmente em todos os produtos intermédios – especificação de requisitos, análise, desenho, programas (código), manuais do utilizador, documentação. Em suma, tudo. Para fazer isto, necessitamos de definir atributos da qualidade para cada um destes produtos intermédios. No desenvolvimento de software há a tendência para não utilizar © FCA – Editora de Informática

217

Gestão de Projetos de Software

termos antiquados da engenharia, como controlo da qualidade. Assim, utilizam-se cada vez mais os termos verificação e validação, os quais, em conjunto, têm o significado de controlo da qualidade: • Verificação – processo de verificar se o nosso produto de software foi bem construído; • Validação – processo de verificar se foi construído o produto de software adequado às necessidades. Existem duas grandes classes de técnicas de verificação e validação usadas no controlo da qualidade – as revisões e os testes.

13.2.1 Revisões As revisões constituem a primeira e principal forma de atividade de controlo da qualidade. Como o controlo da qualidade diz respeito à pesquisa de falhas nos vários produtos do desenvolvimento, embora a atividade de testes esteja igualmente preocupada com a procura de falhas, as revisões são mais eficazes pelo facto de procurarem falhas mais cedo do que os testes. As revisões são conduzidas durante o processo de desenvolvimento – não no final, como no caso dos testes. O controlo da qualidade tem como missão a deteção e eliminação de erros do produto, constituindo as revisões a linha da frente dessa missão. As revisões têm lugar durante o ciclo de vida do desenvolvimento e verificam a correção dos produtos de cada fase, relativamente aos respetivos inputs e outputs. As revisões podem assumir muitas formas: • Revisões por pares (peer reviews); • Walkthroughs; • Inspeções; • Auditorias; • Revisões de fim de fase. Independentemente da forma assumida, o objetivo primário de uma revisão é a identificação de defeitos nos produtos que estão a ser considerados. O SEI desenvolveu gráficos similares aos da Figura 13.2, que mostram que os custos dos defeitos aumentam quase exponencialmente à medida que permanecem nos produtos. As revisões têm como propósito descobrir os erros à medida que são cometidos, em vez de se depender de testes para a sua descoberta. Cada revisão tem um objetivo, uma audiência e um grupo de participantes específicos. Algumas revisões podem ser realizadas várias vezes durante o desenvolvimento, como, por exemplo, os walkthroughs do desenho. Outras, como, por exemplo, a auditoria funcional, são de uma tal magnitude que constituem eventos únicos, que são a base para decisões fundamentais sobre o produto. Em cada caso, contudo, o formato e o procedimento da revisão devem estar refletidos nas normas da organização.

218

Gestão de Projetos de Software

liderança depende não apenas da situação, mas igualmente da fase do ciclo de vida do projeto.

18.4 Liderança Eficaz Uma liderança eficaz tem duas funções principais: realizar o trabalho, fazer as coisas acontecerem, atingir resultados; e desenvolver relacionamentos eficazes. Para realizar o trabalho, é necessário que a equipa e cada membro individual compreendam: • Os objetivos da tarefa; • Como vai ser medido o desempenho; • Que autoridade é dada para a tomada de decisões; • Quais as recompensas e punições, se os objetivos e as normas não forem alcançados. Para desenvolver bons relacionamentos, o líder deve: • Prestar atenção às necessidades dos indivíduos da equipa; • Prestar atenção às necessidades da equipa, como um todo. Estas funções podem ser ilustradas do modo indicado na Figura 18.4, usando para o efeito a análise da liderança de John Adair [Adair, 1973]. Tarefa: − Clara; − Com objetivos; − Planeada; − Com recursos; − Controlada.

Equipa: − Normas; − Envolver; − Ideias; − Reunir; − Minimizar conflitos.

Indivíduos: − Compreender; − Responsabilizar; − Reconhecer; − Desenvolver.

Figura 18.4 – Fatores de liderança

296 © FCA – Editora de Informática

Modelos Ágeis de Desenvolvimento de Software 23 – Modelos Ágeis de Desenvolvimento de Software

23.1 Enquadramento As metodologias ágeis proporcionam uma abordagem à engenharia de software que visa ajudar as equipas de desenvolvimento a responder à imprevisibilidade da construção de software através de cadências de trabalho incrementais e iterativas, conhecidas como sprints. Em 1970, Winston Royce apresentou uma comunicação intitulada Managing the Development of Large Software Systems, em que delineava as suas ideias sobre o desenvolvimento sequencial (em cascata – ver ponto 22.3.1). Em resumo, a apresentação de Royce afirmava que um projeto poderia ser desenvolvido à semelhança de uma linha de montagem automóvel, em que cada peça é adicionada em fases sequenciais. Isto significa que cada fase do projeto tem de estar concluída antes do início da fase seguinte. Deste modo, a equipa recolhe primeiro todos os requisitos do projeto, depois define a arquitetura e o desenho, a seguir escreve todo o código, etc. Neste processo existe pouca ou nenhuma comunicação entre os grupos especializados que executam cada fase do trabalho. É fácil de constatar como esta metodologia de desenvolvimento está longe de ser otimizada. Em primeiro lugar, porque assume que todos os requisitos do projeto podem ser identificados antes de ocorrer qualquer desenho ou codificação. Muitos especialistas de software conhecem a falácia deste pressuposto: no final de um projeto, uma equipa poderá ter criado o software que lhe foi pedido para fazer mas, no intervalo de tempo que despenderam para o criar, as realidades do negócio modificaram-se tão dramaticamente que o produto final fica irrelevante. Neste cenário, a organização gastou tempo e dinheiro para criar software que ninguém quer. Teria sido possível assegurar que o produto final ainda seria relevante antes de ter sido concluído? As metodologias de desenvolvimento ágil procuram proporcionar muitas oportunidades para avaliar a direção de um projeto ao longo do ciclo de vida do desenvolvimento. Tal é alcançado através de cadências de trabalho regulares, conhecidas como iterações (sprints), no final das quais as equipas devem apresentar um incremento aceitável do trabalho. Deste modo, ao focalizarem-se na repetição de ciclos de trabalho curtos, bem como no produto funcional que produzem, as metodologias ágeis podem ser descritas como iterativas e incrementais.

345

Gestão de Projetos de Software

23.2 Ciclo de Vida Genérico do Desenvolvimento Ágil No modelo em cascata, as equipas de desenvolvimento apenas têm uma oportunidade para obter cada aspeto do projeto de forma correta. Num paradigma de desenvolvimento ágil, cada aspeto do desenvolvimento – requisitos, desenho, arquitetura, codificação, etc. – é continuamente revisitado ao longo do ciclo de vida do desenvolvimento. Como, a cada 2 semanas, a equipa reavalia a direção do projeto, há sempre tempo para o conduzir numa direção diferente. Os resultados desta abordagem “inspecionar e adaptar” reduz grandemente, quer os custos do desenvolvimento, quer o tempo de introduzir produtos no mercado (time-tomarket). Como as equipas conseguem recolher requisitos ao mesmo tempo que estão a fazer análise e desenho, o conhecido fenómeno de “paralisia da análise”61 não consegue impedi-los de fazer progressos. Por outro lado, como o ciclo de trabalho de uma equipa é limitado a 2 semanas, isso dá às partes interessadas repetidas oportunidades para calibrarem os entregáveis concluídos face ao mundo real. Todos os métodos de desenvolvimento de software, incluindo os ágeis, possuem algum tipo de ciclo de vida subjacente. Alguns dos métodos ágeis não lhe dão grande ênfase, ao passo que outros se baseiam fortemente nesse conceito. Alguns possuem ciclos de vida tão abstratos que é realmente difícil perceber quais as atividades a planear. E usam diferentes termos para a mesma coisa. Podemos, no entanto, definir um ciclo de vida genérico a que todos os modelos se submetem, com maior ou menor detalhe. Os elementos-chave são uma iniciação do projeto e um planeamento do projeto, seguidos por uma, ou mais, entregas (releases), construídas num ou mais intervalos de tempo de 3 a 4 semanas (timeboxes)62. Existem igualmente mais ou menos fases opcionais para elaborar os requisitos e para a arquitetura – frequentemente executadas em paralelo com o planeamento do projeto. O ciclo de trabalho de um projeto ágil segue as seguintes etapas: 1. O projeto inteiro é dividido em parcelas usando um modelo de priorização de funcionalidades. 2. O cliente e a equipa de desenvolvimento escolhem um conjunto de funcionalidades que devem ser implementadas durante uma iteração (Figura 23.1). 3. As funcionalidades são implementadas. 4. As funcionalidades são testadas e integradas. 5. As funcionalidades implementáveis são entregues ao cliente.

346

A “paralisia da análise” ocorre quando as pessoas não conseguem saltar de uma boa ideia para outra, por estarem bloqueadas com as implicações de cada ideia: “Se fizer isto, então isto poderá ocorrer, ou aquilo poderá acontecer. Talvez fosse melhor se eu fizesse aquela outra coisa”. A paralisia da análise resulta numa incapacidade de execução. Nada é realizado, porque não somos capazes de nos decidir sobre o movimento a executar. As iterações são timeboxed, significando isso que devem ser concluídas no tempo previsto, mesmo que tenha de se deixar cair alguma funcionalidade.

Modelos Ágeis de Desenvolvimento de Software

6. O cliente dá feedback sobre as funcionalidades entregues e a equipa faz a respetiva revisão. 7. Se o cliente aceitar o produto, este pode ser entregue para o mercado. 8. Se o cliente quiser qualquer alteração/modernização, volta-se à primeira iteração (a partir do passo 2 – priorização das funcionalidades). Daily review

Feedback Itens

Backlog

Iteração

Planear

Entrega (release)

Colaborar

Entregável

Entregar

Figura 23.1 – Conceito de iteração nas metodologias ágeis

A Figura 23.2 ilustra esquematicamente o ciclo de vida genérico das metodologias ágeis. Torna-se claro no diagrama da figura que é muito difícil calcular o tempo de desenvolvimento para os métodos ágeis. As metodologias ágeis dão ao cliente muitas oportunidades para alterar o produto em qualquer momento, mas exigem mais esforço às equipas de desenvolvimento e de consultoria. Testar

Testar

ARRANQUE: - Iniciar projeto; - Priorizar funcionalidades; - Desenvolver funcionalidades de elevada prioridade.

Desenvolver a funcionalidade 2 Testar Desenvolver a funcionalidade 1

Desenvolver a funcionalidade n

Entregar

- Cliente - Utilizador - Equipa de desenvolvimento em contacto permanente durante todo o desenvolvimento

Rever

Ok?

Sim

Não Próxima iteração desenvolvimento

Ajustar e monitorizar repriorização

Entregar para o mercado

Registar e incorporar alterações

Figura 23.2 – Ciclo de vida genérico das metodologias ágeis

347

Gestão de Projetos de Software

23.3.4 Outras Diferenças Os modelos sequenciais clássicos e os modelos de desenvolvimento ágil apresentam um variado conjunto de diferenças nos principais aspetos que enformam os projetos de desenvolvimento de software, nomeadamente no respeitante aos seguintes aspetos: fase de ideia e desenho, coordenação das ações, execução do projeto, filosofia de testes e entregáveis. A Tabela 23.1 ilustra as principais diferenças nos aspetos mencionados. Aspetos

Modelos Ágeis

Modelos Tradicionais

Ideia e desenho

− As partes mais críticas são desenhadas primeiro; − É possível adicionar novas partes às existentes.

− O cliente pode alterar os requisitos em qualquer altura, por isso as partes são desenhadas como elementos separados e a estrutura de um elemento não influencia significativamente os outros.

Coordenação das ações

− O cliente ou os seus representantes trabalham estreitamente com a equipa de desenvolvimento durante todo o processo de desenvolvimento; − Os problemas podem ser evitados e a imprecisão da documentação corrigida num curto espaço de tempo.

− A responsabilidade cai toda sobre a equipa de desenvolvimento; − O cliente raramente é envolvido no desenvolvimento.

Execução do projeto

− O desenvolvimento é iterativo e o projeto é executado em iterações curtas (2 a 4 semanas); − Cada nova versão do produto é atualizada com funcionalidades priorizadas; − Existe pouco planeamento.

− O processo de desenvolvimento é faseado; − A fase é muito maior do que uma iteração; − Cada fase termina com uma descrição detalhada dos requisites da fase seguinte.

Filosofia de testes

− Cada iteração tem a sua própria fase de testes; − Isso permite implementar testes de regressão de cada vez que são entregues novas lógicas ou funções.

− A fase de testes é executada somente após a fase de desenvolvimento, em virtude de partes separadas não serem totalmente funcionais para serem testadas; − A verificação dos requisitos só pode ser realizada no software completo.

Entregáveis

− As funcionalidades mais importantes são as primeiras a ser desenvolvidas; − Quando uma iteração termina, funcionalidades potencialmente utilizáveis são entregues ao cliente; − As novas funcionalidades são utilizáveis após a entrega.

− As funcionalidades são entregues todas de uma só vez, após uma longa fase de implementação; − O cliente não pode fazer alterações ao projeto, porque isso exige voltar a percorrer as fases de desenvolvimento anteriores.

Tabela 23.1 – Principais diferenças entre os modelos tradicionais e os modelos ágeis

352

Modelos Ágeis de Desenvolvimento de Software

As metodologias ágeis mais famosas incluem Scrum (1995), Crystal Clear, Extreme Programming (XP) (1999), Adaptive Software Development, Feature Driven Development, Dynamic Systems Development Method Atern (DSDM Atern) (1995), Feature Driven Development (1997) e Lean Software Development (2003). Vamos desenvolver aqui três dos mais famosos paradigmas de desenvolvimento ágil atual – DSDM Atern, XP e Scrum.

23.4 Dynamic Systems Development Method Atern 23.4.1 Fases do Modelo O modelo dinâmico do desenvolvimento de sistemas Atern, ou DSDM Atern, foi desenvolvido como uma extensão do modelo de desenvolvimento rápido de aplicações – Rapid Application Development (RAD)64 – e constitui um modelo de processo com um conjunto de controlos necessários ao seu funcionamento. O DSDM Consortium65 é o detentor do método e publica o manual de referência para membros. É um modelo com três grandes etapas: pré-projeto, ciclo de vida e pós-projeto. O ciclo de vida, por sua vez, desenrola-se em cinco fases – estudo de exequibilidade; análise de requisitos; modelo funcional; desenho e construção e implementação –, o que dá uma grande ênfase ao constante controlo da qualidade para garantir a adequação ao objetivo. Essas etapas e fases têm os seguintes objetivos: Pré-projeto Iniciação do projeto e acordo sobre os Termos de Referência para o trabalho. Estudo de Nesta fase é avaliada a situação do projeto, para ver se o DSDM exequibilidade Atern é a abordagem adequada. Há algumas situações em que o modelo pode ser adequado, embora existam igualmente algumas condições prévias a satisfazer para que o método tenha sucesso. O estudo de exequibilidade analisa ambas. Análise de Nesta fase é estabelecido o cenário empresarial para o trabalho, requisitos através do exame dos processos a serem suportados. As três elipses mostradas na Figura 23.7 pretendem evidenciar a forte iteração que se verifica neste modelo. Modelo A análise conduz a sucessivos protótipos, à medida que as iterações funcional convergem para os requisitos do sistema. Nesta etapa são explorados os atributos funcionais e não funcionais do sistema.

RAD é um modelo de processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias). O termo foi registado por James Martin em 1991 e tem substituído gradativamente o termo de prototipagem rápida que já foi muito utilizado no passado. http://www.dsdm.org

353

Gestão de Projetos de Software

Desenho e Os protótipos gerados na fase de desenho e construção evoluem construção para um sistema testado, suficientemente bem elaborado para poder ser usado pela organização (aquilo que se designa, no modelo em V, por sistema operacional). Implementação A fase de implementação acontece quando o sistema entra em exploração no ambiente organizacional. Esta fase é mostrada como uma outra iteração, embora esteja presente apenas para gerir a entrega do sistema, ao longo do tempo ou do espaço geográfico. Logo que o sistema esteja a ser utilizado, pode avaliar-se o seu desempenho face às necessidades do negócio – o resultado será ou o encerramento do projeto ou a reentrada num dos ciclos. Pós-projeto Avaliar os benefícios alcançados com a solução implementada (geralmente entre 6 meses e 1 ano após a implementação). A Figura 23.7 mostra graficamente, não só o desenrolar das diversas fases do modelo, como também o possível regresso às outras iterações (setas a tracejado) ou mesmo à análise de requisitos, se necessário. Pré-projeto

Estudo de Exequibilidade Análise de Requisitos

Acordar prazos Criar protótipo funcional

Modelo Funcional

Implementar Identificar protótipo funcional

Revisão funcional

Implementação

Treinar os utilizadores

Aprovação pelos utilizadores

Rever protótipo

Identificar protótipo do desenho Acordar prazos

Desenho e Construção

Identificar protótipo funcional

Criar protótipo do desenho

Figura 23.7 – Fases do modelo DSDM Atern

354

Pós-projeto

5.ª Edição Atualizada

Textos complementares disponíveis na página do livro em www.fca.pt, até este se esgotar ou ser publicada nova edição atualizada ou com alterações.

ISBN 978-972-722-804-1

www.fca.pt

com as recomendações do PMBOK Guide Fifth Edition • Alinhado (2012), do CMMI e das normas ISO 21500 e 10006 ®

com profundidade as metodologias de desenvolvimento • Aborda ágil e a engenharia de software