Distribuição
EDistribuição dição FCA – Editora de Informática, Lda. Lidel – edições técnicas,14 lda A – 1000-247 Lisboa Av. Praia da Vitória, Tel: +351 213 511 448 SEDE: R. D. Estefânia, 183, R/C Dto., 1049-057 LISBOA fca@fca.pt Lidel – edições técnicas, lda Internet: 21 354 14 18 – livrarialx@lidel.pt / Revenda: 21 351 14 43 – revenda@lidel.pt www.fca.pt Formação/Marketing: 21 351 14 48 – formacao@lidel.pt / marketing@lidel.pt
SEDE: R. D. Estefânia, 183, R/C Dto., 1049-057 LISBOA
Ens. Línguas/Exportação: 21 351 14 42 – depinternacional@lidel.pt Distribuição Internet: 21 354 14 18 – livrarialx@lidel.pt / Revenda: 21 351 14 43 – revenda@lidel.pt Fax: 21 Técnicas, 357 78 27Lda. – 2121352 Formação/Marketing: 35126 1484 48 – formacao@lidel.pt / marketing@lidel.pt Lidel – Edições Ens. Línguas/Exportação: 351 14 42Lisboa – depinternacional@lidel.pt Rua D. Estefânia, 183, R/C Dto. –21 1049-057 Fax: 21511 357 448 78 27 – 21 352 26 84 Tel: +351 213 LIVRARIAS: LISBOA: Av. Praia da Vitória, 14 – 1000-247 LISBOA – Tel.: 21 354 14 18, e-mail: livrarialx@lidel.pt lidel@lidel.pt PORTO: R. Damião de Góis, 452 – 4050-224 PORTO – Tel.: 22 557 35 10, e-mail: delporto@lidel.pt www.lidel.pt LIVRARIAS: LISBOA: Av. Praia da Vitória, 14 – 1000-247 LISBOA – Tel.: 21 354 14 18, e-mail: livrarialx@lidel.pt PORTO: R. Damião de Góis, 452 – 4050-224 PORTO – Tel.: 22 557 35 10, e-mail: delporto@lidel.pt
Livraria Av. Praia da Vitória, 14 A – 1000-247 Lisboa Tel: +351 213 511 448 * Fax: +351 213 173 259 livraria@lidel.pt Copyright © Fevereiro 2011
Copyright Fevereiro 2011 Copyright ©©2016, – Editora Lda. de Informática, Lda. FCA – Editora de FCA Informática, ISBN impressa: 978-972-722-824-9 FCA edição – Editora de Informática, Lda. ISBN: 978-972-722-679-5 1.ª edição impressa: maio 2016 ISBN: 978-972-722-679-5
Capa: José M. Ferrão – Look-Ahead
Capa: José M. Ferrão – Look-Ahead Paginação: Mendes ImpressãoCarlos e acabamento: Tipografia Rolo & Filhos, II – S.A. Impressãoeeacabamento: acabamento: TipografiaLousanense Rolo & Filhos, II – S.A. Impressão Tipografia – Lousã Depósito Legal N.º ……… Depósito DepósitoLegal Legaln.º N.º409442/16 ……… Capa: José M. Ferrão – Look-Ahead
de FCA Editora de Informática, Informática, Marcas Registadas Marcas Registadas de FCA –– Editora de Lda. –Lda. de FCA – Editora de Informática, Marcas Registadas
®
®
®
®
®
®
Este merece umauma explicação. O seuOpropósito é alertar leitor para a ameaça Estepictograma pictograma merece explicação. seu propósito é oalertar o leitor para a que ameaça que
Todos os nossos livros passam poroum rigoroso controlo de qualidade, no a consulta periódica representa para futuro da escrita, nomeadamente na entanto área daaconselhamos edição técnica e universitária, o do representa para o futuro da escrita, nomeadamente na área da edição técnica e universitária, o desenvolvimento da fotocópia. nosso site (www.fca.pt) para fazer omassivo download de eventuais correções. desenvolvimento massivo da fotocópia. O Código do Direito de Autor estabelece que é crime punido por lei, a fotocópia sem autorização
O Código do Direito de Autor estabelece que é crime punido por lei, a fotocópia sem autorização
dos proprietários do copyright. No entanto, esta prática generalizou-se sobretudo no ensino superior, Não nos responsabilizamos por desatualizações das No hiperligações presentes nesta obra, que foram verificadas à data superior, de dos proprietários do copyright. entanto, esta generalizou-se sobretudo noque ensino provocando uma queda substancial na compra deprática livros técnicos. Assim, num país em a publicação da mesma. provocando uma substancial na sentem compramotivação de livros para técnicos. Assim, num epaís literatura técnica é tãoqueda escassa, os autores não criar obras inéditas fazê-em que a
literatura escassa, os autoresde não motivação para criar obras inéditas e fazê-las publicar,técnica ficandoéostão leitores impossibilitados ter sentem bibliografia em português.
Os nomes comerciais neste livro têm patente registada portanto, que expressamente proibida reprodução, noem todo ou em parte, da Lembramos -lasreferenciados publicar, ficando os é leitores impossibilitados deater bibliografia português. obra sem autorização editora. Lembramos portanto, que da é expressamente presente
presente obra sem autorização da editora.
proibida a reprodução, no todo ou em parte, da
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 Geral Índice de Exemplos, Figuras e Tabelas
X
Agradecimentos XIII Prefácio XV 0 Introdução 1 0.1 Engenharia de Software 1 0.2 Porque falham os projetos de Tecnologias de Informação? 3 0.3 O que se procura com este livro? 4 0.4 A quem se destina este livro? 5 0.5 Como está organizado este livro? 6 1 Metodologia 7 1.1 Introdução 7 1.2 Adoção da Metodologia 8 1.2.1 Controlo Real do Projeto 8 1.2.2 Capacidade de Adaptação à Mudança 10 1.2.3 Entrega Constante de Valor ao Cliente 12 1.3 Aplicação da Metodologia 12 1.3.1 Fases da Metodologia 13 1.3.1.1 Conceção 14 1.3.1.2 Construção 15 1.3.1.3 Transição 16 1.3.2 Lidar Com os Riscos 17 1.3.3 Process Manager 18 1.3.4 Apoio Certo na Aplicação da Metodologia 19 1.4 Conclusão 20 2 Fase de Conceção 23 2.1 Introdução 23 2.2 Reunião de Validação do Caderno de Encargos 23 2.3 Business Vision e Enquadramento do Negócio 26 2.4 Documento de Visão e Enquadramento do Âmbito 31 2.4.1 Requisitos Funcionais 32 —V—
Desenvolvimento Ágil de Software – Guia Prático
2.4.2 Funcionalidades 34 2.4.3 Arquitetura de Alto Nível 38 2.4.4 Requisitos Não Funcionais 42 2.4.5 Identificação de Stakeholders 44 2.4.6 Fora do Âmbito 45 2.5 Estimativas Iniciais 47 2.5.1 Estimar Casos de Uso 47 2.5.2. Decompor em Tarefas 49 2.5.3. Substituição dos Pontos Atribuídos por Horas 50 2.5.4 Determinar a Capacidade e a Velocidade da Equipa 51 2.5.5 Custo Final 53 2.5.6 Conteúdo da Primeira Iteração 54 2.6 Análise da Oportunidade 55 2.6.1 Conhecimento do Negócio 56 2.6.2 Conhecimento Tecnológico 56 2.6.3 Viabilidade Financeira 57 2.7 Lista de Riscos 58 2.7.1 Identificação dos Riscos 58 2.7.2 Avaliação do Risco 59 2.7.3 Periodicidade na Avaliação dos Riscos 63 2.8 Plano de Release 63 2.8.1 Um Plano, Duas Perspetivas 64 2.8.2 Atualizar a Velocidade 67 2.8.3. Novo “Plano de Projeto” 68 2.8.4 Fases de Conceção e Transição no Plano de Release 70 2.9 Estratégia de Build e Deployment do Software 72 2.9.1 Geração de uma Build 72 2.9.1.1 Integração Contínua, Sempre! 73 2.9.1.2 Testes Unitários (Claro que Compensam!) 75 2.9.1.3 Analisar a Qualidade do Código 77 2.9.1.4 Automatizar os Testes de Sistema 78 2.9.2 Deployment 80 2.9.2.1 Testes de Capacidade 80 2.9.2.2 Testes de Aceitação 81 2.10 Definição da Estratégia de Testes 83 2.10.1 Testes Informais e Testes de Aceitação 85 2.10.2 Critérios de Qualidade 86 2.11 Discussão da Proposta 88 2.11.1 Obter Esclarecimentos Adicionais 88 2.11.2 Discutir o Valor da Proposta 90 2.12 Conclusão 90 — VI —
Índice Geral
3 Fase de Construção 93 3.1 Introdução 93 3.2 Repositório de Trabalho 94 3.2.1 Criar um Repositório de Trabalho 95 3.2.2 Repositório como Base para Plano de Release 96 3.2.3 Tipos de Itens 97 3.3 Plano da Iteração 98 3.3.1 Discussão dos Casos de Uso 99 3.3.2 Identificação e Planeamento das Tarefas 100 3.4 Detalhe de Casos de Uso 103 3.4.1 Erros Mais Comuns e Anti-Padrões 104 3.4.2 Escrever um Caso de Uso 106 3.4.3 Diagramas de Casos de Uso 109 3.5 Reuniões Diárias de Ponto de Situação 111 3.5.1 Quatro Perguntas Fundamentais 111 3.5.2 Formato da Reunião 112 3.5.3 A Quinta Pergunta 112 3.6 Código e Repositório 113 3.6.1 Submeter Corretamente o Código 113 3.6.2 Sinalizar a Submissão de Código 116 3.7 Gráfico de Execução da Iteração (Burndown Chart) 118 3.7.1 Alocação da Equipa 118 3.7.2 Estimativas do Plano da Iteração 119 3.8 Atualização do Estado das Tarefas 121 3.8.1 Elementos-Chave de uma Tarefa 121 3.8.2 Gestão do Estado de Cada Tarefa 122 3.8.3 É Mesmo Importante Atualizar as Tarefas 124 3.9 Guia de Estilos 126 3.9.1 Guia de Estilos e Protótipo de Usabilidade 127 3.9.2 Elementos-Chave no Guia de Estilos 128 3.10 Definição dos Casos de Teste Funcionais 133 3.10.1 Identificação e Descrição dos Fluxos a Testar 134 3.10.2 Matriz de Cobertura 136 3.10.3 Implementação das Propriedades 137 3.10.4 Dados de Teste 139 3.10.5 Automatização e Manutenção 140 3.11 Testes de Interface de Utilizador e de Usabilidade 141 3.11.1 Testes de Interface de Utilizador 142 3.11.2 Testes de Usabilidade 144 3.11.3 Como Definir os Casos de Teste 146 3.12 Pedidos de Alteração e Gestão do Âmbito 147 3.12.1 Pedido de Alteração 148 3.12.2 Gestão de Alterações 149 — VII —
Desenvolvimento Ágil de Software – Guia Prático
3.12.3 Gestão do Âmbito 151 3.13 Preparação da Iteração Seguinte 153 3.13.1 Papel dos Stakeholders 154 3.13.2 Papel da Equipa de Desenvolvimento 155 3.14 Gráfico de Concretização da Release (Burnup) 157 3.14.1 Dimensão e Evolução de uma Release 157 3.14.2 Data de Conclusão Planeada e Prevista 160 3.15 Reunião de Revisão da Iteração 162 3.15.1 Apresentação do Âmbito da Reunião 162 3.15.2 Demonstração do Software 165 3.16 Reunião de Avaliação da Iteração 167 3.16.1 Relatório 167 3.16.2 Diário do Projeto 171 3.17 Conclusão 172 4 Fase de Transição 175 4.1 Introdução 175 4.2 Plano de Comunicação 176 4.2.1 Comunicação ao Comité do Projeto 177 4.2.2 Comunicação ao Grupo de Trabalho 178 4.2.3 Comunicação a Toda a Organização 179 4.2.4 Comunicação para o Exterior 180 4.3 Manual de Release 181 4.3.1 Estrutura do Manual 182 4.3.2 Manual de Release ou de Deployment? 187 4.4. Deployment em Produção 188 4.4.1 Tarefas Fundamentais a Executar 188 4.4.1.1 Migração 188 4.4.1.2 Instalação 189 4.4.1.3 Comunicação 189 4.5 Definição e Execução da Estratégia de Formação 191 4.5.1 Formação Técnica 191 4.5.2 Formação Funcional 192 4.5.3 Estratégia e Avaliação da Formação 193 4.6 Tipos de Suporte e Manutenção 199 4.6.1 Suporte Pós-Produção 200 4.6.2 Manutenção Corretiva 200 4.6.3 Manutenção Preventiva 200 4.6.4 Manutenção Adaptativa 201 4.6.5 Manutenção Evolutiva 202 4.6.6 Investir na Manutenção 202 4.7 Níveis de Serviço 204 4.7.1 Solicitação dos Pedidos de Intervenção 205 — VIII —
Índice Geral
4.7.2 Horários 205 4.7.3 Tempos de Resposta 206 4.7.4 Indicadores de Serviço 207 4.7.5 Formas de Prestação do Serviço 208 4.8 Lessons Learned 209 4.8.1 Importância da Reunião de Avaliação da Iteração 210 4.8.2 Informação Relevante 210 4.9 Conclusão 212 5 Prevenir o Fracasso 215 5.1 Fracasso dos Projetos de Software 215 5.2 Gestão das Expectativas dos Stakeholders 215 5.3 Leve em Conta as Necessidades do Negócio 216 5.4 A Experiência Sai Mais Barata! 217 5.5 Avalie a Dimensão e a Complexidade do Projeto 219 5.6 Cuide dos Recursos Humanos 220 5.7 Adote Formalmente uma Metodologia 221 5.8 Aceite mas Monitorize o Risco 222 5.9 Reveja Regularmente a Viabilidade do Projeto 223 5.10 Invista na Qualidade 224 5.11 Não se Sobreponha aos Stakeholders 225 5.11.1 Os Stakeholders Sabem Mesmo do Negócio 225 5.11.2 Interface Gráfica: a Última Palavra é Sua 226 5.12 Esteja Atento às Parcerias 227 5.13 Liderança e Experiência do Gestor de Projeto 228 5.14 Audite os Seus Projetos 229 5.15 “Eduque” os Stakeholders 230 5.16 Conclusão 231 Anexo – Software Utilizado
233
Glossário – Termos Técnicos
237
Índice Remissivo
239
— IX —
Índice de Exemplos, Figuras e Tabelas 0 Introdução 1 Figura 0.1 – Onde e como investir? 1 1 Metodologia 7 Exemplo 1.1 – Modelo Waterfall 9 Figura 1.1 – Abordagem Waterfall vs. abordagem iterativa Figura 1.2 – Entrega única vs. entregas por iteração Figura 1.3 – Fases da metodologia Figura 1.4 – Atividades e artefactos na Fase de Conceção Figura 1.5 – Atividades e artefactos numa iteração tipo na Fase de Construção Figura 1.6 – Atividades e artefactos na Fase de Transição 2 Fase de Conceção Exemplo 2.1 – Estrutura típica da Business Vision Exemplo 2.2 – Ganhar a confiança do cliente Exemplo 2.3 – Descrição do âmbito (parte 1) Exemplo 2.4 – Descrição do âmbito (parte 2) Exemplo 2.5 – Descrição do âmbito (parte 3) Exemplo 2.6 – Descrição do âmbito (parte 4) Exemplo 2.7 – Comunicação inadequada Exemplo 2.8 – Descrição do âmbito (parte 5) Exemplo 2.9 – O problema da integração esporádica Exemplo 2.10 – Estratégia de testes Exemplo 2.11 – Quando a discussão da proposta é mal preparada
10 11 13 14 16 17 23 27 30 32 35 38 42 43 44 74 83 89
Figura 2.1 – Arquitetura de um sistema (por camadas) 40 Figura 2.2 – Arquitetura de um sistema (deployment) 41 Figura 2.3 – Tarefas para a estimativa de esforço 47 Figura 2.4 – Lista de casos de uso com estimativas 48 Figura 2.5 – Caso de uso decomposto em tarefas 49 Figura 2.6 – Estimativas de horas para casos de uso referência 50 Figura 2.7 – Estimativas do esforço global 51 Figura 2.8 – Capacidade e velocidade da equipa 52 Figura 2.9 – Custos unitários dos recursos 53 —X—
Índice de Exemplos, Figuras e Tabelas
Figura 2.10 – Lista de riscos 59 Figura 2.11 – Impacto e probabilidade na priorização do risco 60 Figura 2.12 – Lista de casos de uso com estimativas em pontos 64 Figura 2.13 – Capacidade e velocidade da equipa 65 Figura 2.14 – Plano de release (velocidade mínima) 66 Figura 2.15 – Plano de release (velocidade máxima) 66 Figura 2.16 – Plano de release revisto 67 Figura 2.17 – Plano de projeto 69 Figura 2.18 – Gestão da lista de casos de uso e respetivas tarefas 70 Figura 2.19 – Atividades na geração de uma build 73 Figura 2.20 – Painel de controlo da qualidade do código (SonarQube) 78 Figura 2.21 – Atividades para o deployment 80 Tabela 2.1 – Lista de Riscos (detalhada) 3 Fase de Construção Exemplo 3.1 – Erros comuns num caso de uso Exemplo 3.2 – Escrita adequada do caso de uso Exemplo 3.3 – Caso de uso Exemplo 3.4 – Importância do guia de estilos Exemplo 3.5 – Guia de estilos Exemplo 3.6 – Tipos de casos de teste funcionais (passo 1) Exemplo 3.7 – Tipos de casos de teste funcionais (passo 2) Exemplo 3.8 – Tipos de casos de teste funcionais (passo 3) Exemplo 3.9 – Tipos de casos de teste funcionais (passo 4) Exemplo 3.10 – Tipos de casos de teste de interface de utilizador Exemplo 3.11 – Tipos de casos de teste de usabilidade Exemplo 3.12 – Matriz de definição e monitorização dos casos de teste Exemplo 3.13 – Apresentação do âmbito da reunião de revisão Exemplo 3.14 – Relatório da reunião de avaliação
61 93 104 105 107 127 129 135 136 138 139 142 145 146 163 168
Figura 3.1 – Iteração tipo na Fase de Construção 93 Figura 3.2 – Construção do plano de release com os itens do repositório de trabalho 96 Figura 3.3 – Vários tipos de itens do repositório 97 Figura 3.4 – Plano de iteração pronto a ser detalhado 99 Figura 3.5 – Caso de uso dividido em tarefas 101 Figura 3.6 – Caso de uso com tarefas identificadas, estimadas e atribuídas 102 Figura 3.7 – Conteúdo de uma iteração 104 Figura 3.8 – Submissão de código no repositório (main line) 115 Figura 3.9 – Conflito na submissão de código 117 Figura 3.10 – Gráfico de execução da iteração (capacidade da equipa) 119 Figura 3.11 – Gráfico de execução da iteração (iteração concluída) 120 — XI —
Desenvolvimento Ágil de Software – Guia Prático
Figura 3.12 – Tarefa pronta a ser iniciada (ferramenta Scrumwise) 123 Figura 3.13 – Tarefa atualizada (ferramenta Scrumwise) 124 Figura 3.14 – Tarefas atualizadas quase no final da iteração (ferramenta Scrumwise) 125 Figura 3.15 – Pedido de alteração integrado no plano de release 150 Figura 3.16 – Criação de uma segunda release com o pedido de alteração 151 Figura 3.17 – Pedido de alteração registado no repositório de trabalho 152 Figura 3.18 – Alteração do plano de release 156 Figura 3.19 – Gráfico de concretização da release (inicial) 158 Figura 3.20 – Gráfico de concretização da release (projeto em execução) 159 Figura 3.21 – Gráfico de concretização da release e as datas planeadas e previstas 160 4 Fase de Transição Exemplo 4.1 – Comunicação tardia Exemplo 4.2 – Manual de release (versão simplificada) Exemplo 4.3 – Estratégia de formação (versão simplificada) Exemplo 4.4 – Definição de níveis de prioridade Exemplo 4.5 – Definição de tempos de resposta Exemplo 4.6 – Indicadores mínimos de serviço
175 176 183 194 206 207 208
5 Prevenir o Fracasso Exemplo 5.1 – O custo da inexperiência
215 218
— XII —
Prefácio “No princípio era o Verbo...”1 No caso em apreço, poderíamos antes dizer que no princípio era o Byte... Parece que esta afirmação foi feita no tempo dos dinossauros, mas não foi assim há tanto tempo que um dos principais fatores de preocupação era o número de bytes utilizados pela aplicação no armazenamento de dados. Na realidade, nem se passaram duas décadas desde a famosa noite do “bug do Milénio”, que obrigou a que todas as datas fossem armazenadas contendo quatro dígitos no ano. Esta obsessão com o armazenamento de dados devia-se ao elevado preço a que estava associado cada byte utilizado pelas aplicações. O leitor pode esboçar um leve sorriso ao pensar nisto, mas deverá lembrar-se que para levar os primeiros homens à Lua numa viagem de mais de 356 000 km pelo espaço, não foram usados mais de 64 KB, algo que a mais corriqueira das calculadoras tem hoje em dia à saída da fábrica. Com a queda a pique do preço da memória e do armazenamento em disco, o enfoque do desenvolvimento das aplicações libertou-se do pensamento obcecado pela poupança de espaço em disco e voltou-se para a qualidade do código. O objetivo passou a ser que as aplicações fizessem mesmo o que deveriam fazer e, se possível, que o código fosse escrito com a qualidade suficiente para não haver dúvidas de que era mesmo isso que sucedia. A preocupação com o problema é tal que até usamos a palavra bug para nos referirmos a um erro específico feito pelos programadores. O desenvolvimento das linguagens de programação e dos sistemas gestores de bases de dados veio reforçar esta mesma tendência, tentando aproximar a linguagem programada num computador da linguagem natural falada pelos humanos. O aparecimento das linguagens que suportam os princípios da programação orientada por objetos foi um enorme salto em frente, ao encapsular componentes, com maior ou menor inteligência, que resolvem tarefas específicas. Deixou, assim, o programador de se preocupar com os milhares de linhas de código para se focar em cada uma das componentes em particular que compõem o grande bolo final, da mesma maneira que um encenador contrata bons atores para poder contar com tudo o que já sabem, sem ter de lhes ensinar cada aspeto da representação de cada vez que têm que fazer alguma cena no palco. Evangelho de João 1:1.
1
— XV —
Desenvolvimento Ágil de Software – Guia Prático
E assim foi… Os informáticos – esses seres estranhos que vivem no “mundo das Trevas”, do emaranhado de fios, com barba por fazer e com uma alergia contagiante a fatos e gravatas – podiam finalmente descansar, porque tinham atingido um nível próximo da perfeição ao libertarem-se dos grilhões das limitações da memória e das linguagens de desenvolvimento. Ah… nada mais errado! Com o evoluir dos tempos, também o utilizador – esse ser que nem fazia parte da equação – passou a ser um elemento vital no processo de desenvolvimento. Por melhor que seja a aplicação, esta poderá nunca vir a ser usada se os utilizadores não a compreenderem ou se, de alguma forma, a rejeitarem. Assim, utilizadores e informáticos tiveram de passar a dialogar – algo que alguns informáticos fazem com enorme dificuldade e, muitas vezes, com uma tremenda falta de tato. As situações podem ser de tal modo complicadas e violentas que quase se torna necessário contratar um “negociador” entre as partes, como se de um sequestro se tratasse. Tradicionalmente, o fracasso na implementação de uma aplicação era sempre culpa dos utilizadores, vistos normalmente como indivíduos sem grande capacidade intelectual, totalmente incapazes de avaliar condignamente tamanha obra de arte – a peça de software acabada de instalar –, embora ninguém a consiga compreender. Com o aumento do poder dos utilizadores, também as organizações perceberam que estes são uma peça fundamental da engrenagem e, como tal, não devem ser menosprezados ou deixados fora do processo. A instalação de uma nova aplicação – que antigamente consistia, simplesmente, na cópia de uma disquete ou na instalação de uma aplicação a partir de um “setup.exe” – passou a ser um processo muito mais complexo, que requer uma atenção especial por parte da empresa, dos meios informáticos, dos utilizadores, da formação e da cultura da própria organização. As próprias mudanças na organização provocadas pelos novos meios informáticos levaram ao aparecimento de uma nova área denominada Gestão da Mudança. O desenvolvimento de software tornou-se uma área multidisciplinar que não é fácil de compreender ou dominar na totalidade. O processo de desenvolvimento, afinal, não tem fim! Antes faz parte de um ciclo, mais ou menos infinito, em que todas as partes têm de estar envolvidas. Daí a importância deste novo livro que, livre de preconceitos, nos propõe uma viagem completa e detalhada ao longo do processo do desenvolvimento ágil de aplicações. Cada um de nós pode, finalmente, segurar este documento escrito pela mão sábia do seu autor, Tiago Palhoto, um profissional reconhecido na área e com vasta experiência na utilização dos modelos e processos aqui descritos. O conteúdo resulta da sua experiência profissional e das muitas horas em que implementou os modelos e técnicas aqui descritos como consultor e como formador. Luís Damas (Licenciado em Informática, Mestre em Gestão de Informação e Consultor) — XVI —
0 Introdução 0.1 Engenharia de Software A engenharia de software tem conhecido, desde o seu início, uma constante evolução em todas as áreas. Linguagens e ferramentas de modelação, metodologias, tecnologias de implementação, arquiteturas tecnológicas e linguagens de programação, são algumas das áreas que têm vindo a sofrer transformações muito significativas, com particular destaque para os últimos 15 a 20 anos. Todas as entidades que produzem software procuram acompanhar esta tendência evolutiva, seja através da adoção dos novos conceitos, processos, tecnologias, seja através de ferramentas que definem atualmente o rumo desta disciplina. Este crescimento constante e multifacetado é, sem dúvida, o grande desafio deste século para as empresas produtoras de software, uma vez que traz consigo investimentos significativos, que poucas entidades conseguem suportar de forma global e integrada. A forma como cada empresa encara esta realidade é fundamental, já que para a definição do seu plano de crescimento, torna-se imperativo decidir quais os vetores de inovação em que vai investir. Formar as equipas e especializá-las nas linguagens de programação mais utilizadas? Adotar linguagens de modelação únicas? Investir na criação de aplicações suportadas pelo paradigma Service Oriented Architecture (SOA)? Apostar na implementação de uma metodologia de desenvolvimento de software (Figura 0.1)?
Figura 0.1 – Onde e como investir? —1—
Desenvolvimento Ágil de Software – Guia Prático
Não há dúvida de que nos últimos anos se tem assistido a uma aposta cada vez mais forte por parte das empresas nos vários quadrantes do desenvolvimento de software, mais precisamente em disciplinas como a Gestão de Projetos ou Testes e Qualidade, apenas para referenciar duas delas. Este investimento não surge por acaso. O aparecimento de entidades reguladoras e certificadoras que permitem a definição de normas e de boas práticas tem contribuído decisivamente para a formação de profissionais nestas áreas. Dois exemplos claros em Portugal são o PMI – Portugal Chapter (entidade que representa em Portugal o Project Management Institute1 – PMI®), que tem por objetivo a profissionalização dos gestores de projetos, e a ComTest.PT (entidade que representa em Portugal o International Software Testing Qualifications Board2 – ISTQB®), que tem por objetivo promover a profissionalização dos testers. Existe uma preocupação cada vez maior das empresas em assegurar a qualidade dos seus recursos, procurando formá-los e certificá-los nas áreas mais relevantes. Por outro lado, as entidades que contratam empresas para o desenvolvimento de sistemas de informação em regime de outsourcing exigem cada vez mais garantias por parte do seu fornecedor, de maneira a procurar minimizar o risco associado ao projeto. Esta é uma abordagem cada vez mais comum e que faz todo o sentido. Afinal, confiaria a responsabilidade do projeto de engenharia da sua casa de férias a alguém que não fosse um engenheiro devidamente habilitado? Todos estes dados apontam para que se exija cada vez mais o fornecimento de produtos e serviços de qualidade no desenvolvimento de sistemas de informação. A consciência que, quer fornecedores, quer clientes têm vindo a adquirir no que diz respeito à necessidade de especialização dos recursos nas várias disciplinas envolvidas (a par de fatores como a evolução tecnológica ou a utilização de linguagens universais de modelação e programação), só poderia ter como resultado um crescimento exponencial na qualidade e no valor do produto entregue aos clientes. Estranhamente, o cenário atual não é tão otimista como se poderia à partida pensar. As estatísticas têm vindo a mostrar ao longo dos anos que a taxa de sucesso dos projetos de desenvolvimento de software continua a ser baixa. De acordo com o documento Chaos Manifest de 2012, do Standish Group International3, apenas 39% dos projetos foram considerados bem-sucedidos. A pergunta que obrigatoriamente se coloca é porquê?
Associação internacional para os profissionais da gestão de projetos, programas e portefólios. Para mais informações consulte www.pmi.org/. 2 Organização que permite aos testers certificarem-se quanto à utilização de melhores práticas. Para mais informações consulte www.istqb.org/. 3 Organização de pesquisa e aconselhamento que se foca essencialmente na avaliação da performance de cada projeto. Para mais informações consulte www.standishgroup.com/about. 1
—2—
Introdução
0.2 Porque falham os projetos de Tecnologias de Informação? Existem muitas causas identificadas que justificam o fracasso de um projeto. A lista seguinte apresenta algumas das mais relevantes: Âmbito ambíguo ou indefinido; Incorreta aplicação de uma metodologia de desenvolvimento; Pouco envolvimento dos stakeholders e/ou utilizadores finais; Mau planeamento; Fraca liderança do gestor de projeto; Desconhecimento da tecnologia; Falta de preparação e experiência da equipa técnica; Perda do controlo na gestão da mudança de requisitos; Estimativas de tempo e recursos irrealistas; Má gestão da relação com parceiros; Gestão inapropriada do risco; Má gestão de expectativas do cliente; Má compreensão do ambiente da organização; Má compreensão do ambiente circundante; Dificuldade em interpretar corretamente os requisitos transmitidos pelo cliente bem como o seu alcance. Ao analisar a lista, rapidamente se aperceberá de dois aspetos comuns a todas as causas listadas: Intervenção humana desadequada; Falta de informação, de conhecimento ou de capacidade de quem intervém. Por outro lado, é também fácil verificar que as causas são multidisciplinares, ou seja, não estão apenas associadas à gestão de projeto, como é apontado tendencialmente. Problemas com a gestão de requisitos, implementação (desconhecimento de uma tecnologia), gestão de alterações e gestão da mudança são fatores suficientemente decisivos para transformar um projeto num verdadeiro pesadelo. A aplicação incorreta de uma metodologia de desenvolvimento é considerada uma das principais causas de uma grande parte dos falhanços dos projetos de Tecnologias de Informação (TI). A utilização de metodologias estruturadas e bem definidas no desenvolvimento de software continua a ser vista como um custo com pouco ou nenhum retorno. Não é viável continuar a encarar a implementação de um sistema de informação como um conjunto de tarefas de diferentes áreas, todas geridas e organizadas por um elemento (por norma o gestor de projeto) que é especialista apenas numa delas. O resultado acaba muitas vezes por ser uma panóplia de atividades e de artefactos a produzir (que terminam numa pasta, totalmente esquecidos) por um conjunto de técnicos que não conseguem estabelecer uma relação entre todos eles. Esta perspetiva, além de não trazer qualquer valor acrescentado ao projeto, torna-o ainda mais “pesado”. —3—
Desenvolvimento Ágil de Software – Guia Prático
Uma metodologia é um facilitador que reúne numa simbiose perfeita atividades, artefactos e algumas técnicas de engenharia, e que deve ser definida e adaptada de acordo com a dimensão, complexidade, grau de formalismo do projeto, etc. A metodologia pode ainda ser suportada por guidelines específicas (linhas orientadoras), definidas com o objetivo de ajudar na sua implementação. No fim, cada interveniente no projeto saberá exatamente quais as atividades que tem para desenvolver, que artefactos produzir, etc. A adoção de algumas metodologias na totalidade da sua extensão acaba por se tornar num problema ainda mais grave do que aqueles originados pela sua ausência. Este é um erro bastante comum e que é normalmente originado pela inexistência de um técnico responsável pela definição da metodologia. É este técnico que vai procurar adaptar uma framework como o Rational Unified Process4 (RUP), o Scrum5 ou qualquer outra metodologia, à realidade da empresa e dos projetos em causa. Talvez por isso seja cada vez mais frequente os clientes exigirem às organizações que se propõem implementar o projeto uma descrição da metodologia que vai ser utilizada. O process manager é a pessoa responsável por assegurar que para cada projeto é configurado o processo adequado e são definidas todas as atividades, artefactos e perfis relevantes para a sua execução. É também ao process manager que cabe, normalmente, o papel de produzir as guidelines necessárias, apesar de o poder fazer em colaboração com alguns dos elementos do projeto.
0.3 O que se procura com este livro? O aparecimento de um conjunto de metodologias “ágeis” orientadas para uma interação constante com o cliente, procurando a sua satisfação através da entrega de valor real, tem vindo a despertar a atenção e a revelar a importância da adoção de uma metodologia. São muitas as empresas que propõem aos seus clientes a utilização destas metodologias, prometendo resultados com um Time To Market (TTM) cada vez mais competitivo, propondo ao mesmo tempo uma forma de trabalho totalmente orientada para uma rápida implementação e constante satisfação das suas necessidades. Para aplicar corretamente uma metodologia, não basta apenas eleger aquela que parece ser a mais adequada. Saber que a metodologia é composta por determinadas atividades que originam vários outputs e compreender a ligação entre eles é também fundamental. O Scrum, por exemplo, preconiza a realização de uma reunião diária de 5 a 10 minutos com todos os elementos da equipa. Esta reunião tem como objetivo fazer um ponto de situação e avaliar a evolução das tarefas de cada recurso face ao dia anterior, determinando se estão atrasados, dentro do tempo previsto ou até mesmo adiantados. A reunião deve ser feita de pé para encorajar a rapidez da mesma. É, no entanto, bastante frequente encontrar alguns responsáveis de projeto, que preconizam a aplicação Processo de engenharia de software proprietário da IBM. Framework de gestão e desenvolvimento iterativa e incremental, criada formalmente em 1995.
4 5
—4—
Introdução
de uma metodologia ágil e dão como exemplo as reuniões diárias. Estas reuniões são, de facto, realizadas em pé, mas prolongam-se por quase uma hora, acabando por não permitir que todos os intervenientes participem, acabando por se perder o principal objetivo – determinar a evolução das tarefas face ao dia anterior de forma resumida e objetiva. A presenção de um process manager tem, neste caso, um papel fundamental. Com este livro procura-se formalizar a aplicação prática de uma metodologia de desenvolvimento de software e mostrar de que forma podem ser abordados e solucionados muitos dos problemas que surgem durante a execução de um projeto de TI. A aplicação da metodologia descrita neste manual tem por base os conceitos e as práticas transversais a várias metodologias, como por exemplo, a abordagem iterativa. Por outro lado, são também utilizados alguns elementos específicos, como por exemplo, o conceito de fase, preconizado pelo RUP. Importa igualmente salientar que a metodologia descrita neste manual foi adaptada e configurada de acordo com um conjunto de características comuns que a maioria dos projetos partilham entre si, independentemente da sua duração, complexidade, dimensão, grau de formalismo, tecnologia,orçamento disponível, etc. Esta metodologia pode ser adotada as it is ou adaptada de acordo com as especificidades do projeto em questão. Por último, mas não menos importante, com este manual procura-se acima de tudo demonstrar o quão importante é a adoção de uma metodologia de desenvolvimento para qualquer projeto de TI.
0.4 A quem se destina este livro? Com este manual procura-se criar uma ferramenta de referência para todos aqueles que, de alguma forma, estão envolvidos num projeto de desenvolvimento de software, qualquer que seja o seu papel. Nele vão poder encontrar um vasto leque de recomendações, artefactos, atividades, etc., que, ao longo dos anos, têm auxiliado e contribuído para o sucesso de inúmeros projetos. Este livro pode ser lido do início ao fim, permitindo ao leitor ter uma noção objetiva e prática do que está envolvido num projeto. Acaba por se tornar uma leitura completa, particularmente adaptada a quem está a dar os primeiros passos como responsável pelo processo de desenvolvimento. Também todos aqueles que, mesmo com bastante experiência, procuram novas soluções para os mais diversos tipos de problemas (sejam gestores de projeto, programadores, analistas de sistemas, testers, etc.) vão beneficiar com a leitura deste manual. Esta obra pode ainda ser utilizada como referência a um determinado tópico. Por exemplo, um gestor de projeto que procure informação sobre reuniões de avaliação da iteração ou um programador que procure mais dados sobre como efetuar o checkin do seu código, poderá consultar essa informação específica e solucionar o eventual problema ou dificuldade que tenha. De uma forma ou de outra, é bastante provável que encontre uma solução ou recomendação para problemas ou dúvidas que possa ter. —5—
Desenvolvimento Ágil de Software – Guia Prático
0.5 Como está organizado este livro? Como em qualquer projeto onde se pretende utilizar uma framework de desenvolvimento, é preciso dominar e estar familiarizado com os seus conceitos, conteúdos, etc. No Capítulo 1 procura-se explicar os principais fundamentos e as razões que levaram à escolha desta metodologia. Os Capítulos 2 a 4 demonstram a aplicação prática da metodologia com base na utilização de vários artefactos ou na realização de várias atividades, ao mesmo tempo que são reforçados todos os princípios e vantagens associados à metodologia. Cada um destes capítulos representa uma fase distinta no projeto, cada uma delas com objetivos distintos mas complementares. O Capítulo 2 aborda toda a temática relacionada com o início do projeto, a identificação do seu âmbito, dos principais riscos e da viabilidade do mesmo. Aborda ainda temas como a elaboração do plano de release ou a definição da estratégia de construção e disponibilização automática do software, pontos fundamentais que são a base de várias atividades na fase seguinte. O Capítulo 3 aborda as atividades e os artefactos mais importantes envolvidos na construção efetiva do sistema de informação. Os vários tipos de reuniões para controlo de cada iteração, o detalhe dos casos de uso, definição de casos de teste e ainda a estratégia adequada para a disponibilização de código no repositório central são alguns dos tópicos abordados. O Capítulo 4 representa a última fase do projeto, com atividades relacionadas com a passagem do sistema para produção, a necessidade de formação aos utilizadores finais ou o encerramento formal do projeto. Finalmente, o Capítulo 5 apresenta um conjunto de recomendações e de pontos fundamentais que contribuem significativamente para o sucesso de um projeto. Os stakeholders e as suas expectativas, a atenção a dar aos seus recursos ou ainda uma adequada gestão do risco são alguns dos tópicos abordados. Se é verdade que o facto de seguir todas aquelas recomendações não garante o sucesso do projeto, a não observação das mesmas assegura-lhe certamente um desfecho no mínimo dececionante.
—6—
2 Fase de Conceção 2.1 Introdução A palavra conceção tem, na sua essência, a capacidade de conceber, de imaginar algo que possa ser concretizado. Esse deve ser o resultado final desta fase, ou seja, uma ideia concreta, detalhada o suficiente, que permita decidir se é ou não viável. Se é fácil identificar o final da Fase de Conceção (está sempre associado ao cumprimento integral dos objetivos-chave, tal como foi descrito na secção 1.3.1), já o mesmo não é verdade para o seu início. Muitas entidades consideram a conceção da ideia como algo totalmente independente, principalmente quando estão perante uma relação de cliente-fornecedor, considerando que o início de um projeto ocorre apenas quando a decisão já foi tomada e todos os trabalhos preparatórios já foram concluídos. Isto significa que o projeto apenas se inicia formalmente na fase de Construção. A elaboração deste manual levou em conta a perspetiva do fornecedor de serviços, pelo que importa referir que se considerou o início da Fase de Conceção como o início do projeto. Tal acontece a partir do momento em que é recebido o convite para a apresentação de uma proposta. As secções seguintes procuram descrever as atividades e os artefactos mais relevantes para atingir com sucesso o final da Fase de Conceção, ajudando assim uma equipa a decidir se deve ou não avançar para a elaboração de uma proposta.
2.2 Reunião de Validação do Caderno de Encargos A receção de um convite para a apresentação de uma proposta de solução marca o início de um novo projeto, marcando também o arranque da Fase de Conceção. Anexado ao convite recebido vem associado o respetivo Caderno de Encargos, o qual, numa situação ideal, deverá fornecer toda a informação necessária para a apresentação de uma proposta. No entanto, a realidade mostra que nem sempre isso acontece. Falhas, omissões, imprecisões, etc., são alguns dos aspetos que impedem que a equipa possa propor uma solução adequada. Por esse motivo, é fundamental que o caderno seja analisado de imediato por alguns elementos-chave do potencial fornecedor de maneira a validar que pontos específicos necessitam de esclarecimentos adicionais. Estes elementos são, por norma, recursos com uma vasta experiência em áreas como — 23 —
Desenvolvimento Ágil de Software – Guia Prático
a análise de requisitos, definição de arquiteturas tecnológicas, aplicação de metodologias de desenvolvimento, etc. A primeira reunião para validação do Caderno de Encargos visa assegurar que a equipa que vai trabalhar na elaboração da proposta possui os dados necessários para o fazer. Esta reunião deve ser preparada pelos vários elementos que estarão envolvidos nesta tarefa. Assim, a pessoa encarregue de coordenar esse esforço deve enviar, previamente, o caderno, especificando junto de cada destinatário, qual a parte a que deverá dar prioridade na realização da sua análise. Não existe nenhuma regra que permita definir quem são as pessoas que vão contribuir. No entanto, no caso da realização de estimativas, deverá ser a equipa que vai estar no terreno a fornecer essa informação. Por norma, deverão estar envolvidos pelo menos um gestor de projeto, um arquiteto de software, um analista de sistemas e um process manager, cabendo-lhes a primeira análise ao caderno. Naturalmente que, dependendo da complexidade, outros perfis poderão estar envolvidos. O objetivo é conseguir que a informação estrutural seja validada tendo em conta os seguintes aspetos: Problema atual – É um elemento fundamental para assegurar que a equipa consegue perceber qual a realidade do seu cliente e quais os problemas que o levam a recorrer aos seus serviços; Âmbito da solução a implementar – Ainda mais importante que o problema atual é o âmbito da solução a implementar. É essencial garantir que toda a informação necessária para apresentar uma proposta que cubra o âmbito pretendido está disponível, dando sempre atenção à forma como este vem descrito, pois é muito frequente vir já sob a forma de funcionalidades. Tal poderá implicar algum trabalho extra, já que poderá ser necessário ter de perceber quais as reais necessidades do cliente, o que significa ter de lhe pedir alguns esclarecimentos adicionais. Poderá igualmente tentar “extrair” essas necessidades das próprias funcionalidades, apesar de ser mais arriscado devido à incerteza associada; Arquitetura e enquadramento tecnológico – Garantir que aquilo que propõe se enquadra na realidade e nas pretensões tecnológicas do cliente, sob pena de apresentar uma solução que, do ponto de vista operacional, não tem qualquer viabilidade. Por esse motivo, é muito importante perceber a realidade tecnológica atual do cliente e aquilo que é pretendido. Isto implica estar também atento a eventuais riscos tecnológicos, sendo um exemplo típico, a necessidade de interagir com outros sistemas existentes e não ter qualquer informação sobre a sua arquitetura, tecnologia, etc.; Metodologia a utilizar – É muito importante perceber o quão familiarizado está o cliente com a metodologia que propuser, isto porque nem sempre é claro qual a metodologia que o cliente espera que seja utilizada. Se o cliente não estiver familiarizado, deve considerar algumas sessões ou workshops para explicar como tudo vai funcionar. Deve igualmente prever algum acompanhamento ao longo do projeto para garantir que os conceitos, além de apreendidos, não são esquecidos pelo cliente; — 24 —
Fase de Conceção
Envolvimento da equipa do cliente – Tem de ficar bem claro logo desde início qual o papel que se espera que a equipa do cliente venha a ter no decorrer do projeto. Pode resumir-se ao acompanhamento e análise de alto nível, que é o mais comum. No entanto, não são raras as vezes em que a equipa do cliente solicita um envolvimento muito maior, incluindo a colocação de recursos nas atividades diárias da equipa técnica; Logística do projeto – Garantir que os aspetos relacionados com a logística do projeto (disponibilização do local de trabalho, máquinas, condições de faturação e pagamentos, etc.) não deixam dúvidas quanto às expectativas do cliente. Outro aspeto que é extremamente importante considerar e que, em grande parte dos casos é ignorado, diz respeito à autenticidade do convite recebido para apresentar uma proposta. Há sempre um enorme entusiasmo quando uma empresa é convidada a participar numa consulta ou sempre que um convite é lançado por um potencial cliente. Se na maior parte dos casos isto significa o possível estabelecimento de uma nova relação através de um novo projeto, por vezes não são mais do que hábeis tentativas no sentido de obter serviços de consultoria gratuitos. Não são raros os casos em que as entidades têm já um projeto pensado e procuram desenvolvê-lo internamente, não tendo, no entanto, parte do know-how necessário. Para tal, lançam convites para obter informações adicionais que de outra forma não conseguiriam obter. Contudo, se tomar atenção a alguns aspetos, poderão ser poupados vários dias de trabalho que, de outra forma, se tornariam totalmente inúteis. Eis alguns dos “sinais” a que se deve estar atento: Projeto para iniciar de imediato – Por vezes a ideia apresentada requer que se comece desde logo a “adiantar trabalho”, sem qualquer proposta ainda acordada. Aquilo que acaba por acontecer é que, depois de apresentado algo mais concreto e utilizável, a entidade acaba por decidir adiar o projeto (pelo menos é aquilo que lhe dizem), aproveitando naturalmente todo o material que entretanto lhe foi fornecido; Detalhes da implementação na proposta – Este é um dos casos mais comuns e ao qual se deverá estar mais atento. Solicitar numa proposta os detalhes sobre a implementação, tais como o desenho detalhado do sistema, é algo no mínimo impraticável do ponto de vista operacional e que normalmente indicia uma subtil tentativa de aproveitamento; Qualquer tecnologia é viável – Este ponto é semelhante ao anterior, tendo no entanto como principal elemento a arquitetura do sistema a implementar. Quando é solicitado que sejam apresentadas várias tecnologias numa proposta, na realidade pode significar que a entidade em causa, estando a considerar uma alteração na sua infraestrutura ou arquitetura, pretende obter uma lista com as várias possibilidades tecnológicas, devidamente fundamentadas, podendo depois escolher aquela que é mais adequada. Mais uma vez, receberá em determinado momento uma indicação que o projeto vai ser adiado por tempo indeterminado; — 25 —
Desenvolvimento Ágil de Software – Guia Prático
Inexistência de um caderno/documento formal de trabalho – Quando uma entidade não tem um único documento onde possa expor aquilo que pretende, poderá significar que ainda não se deu a esse trabalho porque aguarda que o mesmo lhe seja entregue de forma gratuita, de preferência com várias propostas de solução. Note-se que qualquer um dos aspetos mencionados, per si, pode não ter qualquer significado, pelo que se deve ser cuidadoso na sua análise e observá-lo no conjunto dos sinais. A validação prévia do Caderno de Encargos é uma atividade fundamental para assegurar a consistência necessária da proposta que a sua organização vai apresentar ao cliente. Evite cair na tentação de envolver apenas um perfil na tentativa de reduzir os custos associados a esta atividade. Afinal, se não investir nesta altura crucial para garantir novas oportunidades, corre sérios riscos de não o poder fazer mais adiante.
RESUMO
Fazer uma reunião de validação do Caderno de Encargos e envolver todos os recursos necessários; Assegurar que o âmbito da solução a implementar é claro e não deixa dúvidas; Estar especialmente atento aos riscos relacionados com a arquitetura e o enquadramento tecnológico; Garantir que o cliente está a par da metodologia que vai ser utilizada. Se não estiver, tem de ser ministrada a formação adequada; Estar atento à autenticidade e legitimidade de cada convite recebido. Evitar investir tempo e dinheiro em “falsos” convites.
2.3 Business Vision e Enquadramento do Negócio Não há dúvidas sobre a necessidade de compreender o negócio de um potencial cliente como ponto de partida para a apresentação de uma proposta sólida e adequada. Tudo começa com a receção do Caderno de Encargos, o qual, com mais ou menos detalhe, descreve aquilo que é a atividade da entidade. A juntar a estes dados estão também os habituais pedidos de esclarecimento que são enviados ao cliente após ter sido feita a validação do Caderno de Encargos. Para mais informações sobre este tema consulte a secção anterior. É um ponto fundamental conhecer a realidade operacional do cliente e em particular da área onde se pretende fornecer uma solução. Toda esta informação é, por norma, compilada num documento que é depois utilizado como referência ao longo de todo o projeto, sendo obviamente parte integrante da proposta de serviços a apresentar. Este — 26 —
3 Fase de Construção 3.1 Introdução Com a Fase de Construção, toda a ideia concebida durante a Fase de Conceção vai finalmente ganhar vida! Através de um processo iterativo e incremental, cada iteração vai resultar na entrega aos stakeholders de um conjunto de casos de uso completos para que possam ser validados e aceites, confirmando que a equipa está no bom caminho. Porque o objetivo de cada iteração consiste sempre em entregar valor real aos stakeholders, a sua estrutura, as atividades desenvolvidas e os artefactos produzidos são sempre os mesmos, pelo que, com o passar das iterações, o rendimento da equipa tem tendência a aumentar. Por outro lado, torna-se também mais fácil representar de forma esquemática como tudo se processa. A Figura 3.1 mostra a estrutura tipo de uma iteração durante a Fase de Construção.
Figura 3.1 – Iteração tipo na Fase de Construção — 93 —
Desenvolvimento Ágil de Software – Guia Prático
A Figura 3.1 apresenta dois ciclos de atividades distintos. O primeiro ciclo diz respeito à iteração propriamente dita, onde são identificadas as suas etapas (e respetivas atividades): 1. Planear a iteração – Esta é a primeira etapa da iteração e ocupa, por norma, todo o primeiro dia. Tem como objetivo principal assegurar que estão reunidas todas as condições necessárias para que os casos de uso planeados para a iteração possam ser desenvolvidos. 2. Executar a iteração – Esta etapa ocupa, praticamente, toda a iteração. As várias atividades desenvolvidas visam assegurar a implementação dos casos de uso que foram preparados durante a etapa anterior (planear a iteração). 3. Avaliar a iteração – Durante esta etapa, que ocupa por norma o último dia da iteração, procura-se efetuar a sua avaliação, quer do ponto de vista do trabalho desenvolvido (casos de uso entregues aos stakeholders), quer do ponto de vista do próprio processo de desenvolvimento (aspetos a melhorar, etc.). Existe um segundo ciclo que diz respeito às atividades diárias que ocorrem durante a etapa 2 (de execução da iteração). Trata-se de tarefas que dizem respeito a toda a equipa e que estão relacionadas com o seu funcionamento diário. As secções seguintes descrevem em detalhe as várias atividades e artefactos envolvidos na Fase de Construção. Por uma questão de facilidade de leitura e compreensão, as atividades são descritas de acordo com a ordem cronológica identificada na Figura 3.1. As atividades ocorrridas na etapa 1 (de planeamento) são detalhadas em primeiro lugar, seguidas depois das atividades realizadas durante a etapa 2 (de execução, onde se incluem as atividades diárias). Por fim, serão apresentadas as atividades relacionadas com a etapa 3 (de avaliação da iteração). Adicionalmente serão ainda referidos alguns artefactos e atividades que ocorrem apenas nas primeiras iterações e que, por esse motivo, não estão representados na Figura 3.1, como é o caso, por exemplo, da elaboração do guia de estilos (consulte a secção 3.9 para obter mais informações).
3.2 Repositório de Trabalho Uma das lacunas mais comuns nos projetos de desenvolvimento de software é a falta de um repositório onde seja claramente visível tudo o que deve fazer parte do sistema a implementar. Este é um aspeto muito importante, uma vez que permite a todos os intervenientes terem uma noção clara do trabalho que está envolvido na conclusão do sistema. O repositório de trabalho é também o ponto de partida para a gestão do trabalho a realizar em cada release planeada, independentemente do tipo de item que esteja envolvido, nomeadamente implementação de um caso de uso, correção de um bug, etc. Dependendo da prioridade atribuída a cada item, o responsável do negócio deverá decidir o que vai ser implementado, deixando no repositório aquilo que não “cabe” na release. — 94 —
4 Fase de Transição 4.1 Introdução A Fase de Transição marca a passagem do novo sistema para a comunidade de utilizadores. Esta fase deve ser clara e objetiva nas suas tarefas, podendo tornar-se mais longa, mediante a dimensão, o grau de complexidade ou o próprio grau de formalismo do projeto. Uma nova release de uma aplicação de gestão de condomínio pode ser bastante simples, requerendo apenas uma iteração para completar a Fase de Transição. Já a substituição de todo o sistema de controlo e gestão de uma central nuclear pode ser bastante complexa, requerendo várias iterações que incluem, por exemplo, funcionalidades adicionais e integrações com outros sistemas. A transição faseada do antigo para o novo sistema é também algo a considerar, a qual pode, por exemplo, obrigar a que durante um determinado período de tempo, os dois sistemas sejam utilizados em paralelo. A Fase de Transição deve ser encarada e planeada exatamente da mesma forma como a Fase de Construção, ou seja, com base em iterações, onde são identificados vários itens de trabalho que fazem parte do repositório. Cada item deve ser dividido em tarefas, as quais serão executadas pelos vários intervenientes alocados. Talvez a única diferença entre a Fase de Construção e a Fase de Transição esteja no facto de nesta última a maior parte das tarefas poder ser estimada já com algum rigor, independentemente de fazerem ou não parte da iteração atual. Isto acontece porque as tarefas a executar na Fase de Transição não variam muito de projeto para projeto no que diz respeito à sua natureza. As vantagens da utilização das metodologias ágeis foram já descritas ao longo deste livro. No entanto, há dois aspetos a realçar pelo facto de serem agora visíveis nesta fase. O primeiro aspeto está relacionado com o processo de aceitação do sistema. Com o decorrer do projeto, as várias reuniões de revisão da iteração, assim como a constante disponibilização do sistema, permitiram aos utilizadores adquirirem o conhecimento necessário, tornando o processo de aceitação da aplicação muito mais simples. O segundo aspeto está relacionado com as necessidades de formação. Tal como será descrito na secção 4.5, há a necessidade de se ministrar formação a vários níveis, nomeadamente a nível funcional. Ora, este tipo de formação assenta sobre o funcionamento da aplicação, o qual foi sendo apreendido de forma natural pelos stakeholders e — 175 —
Desenvolvimento Ágil de Software – Guia Prático
respetivos utilizadores ao longo do projeto. Assim, e porque qualquer tipo de formação sobre a vertente funcional torna-se certamente muito mais simples, esta formação acaba, em vários casos, por ser dispensada. As secções seguintes descrevem as atividades e artefactos mais importantes a ter em conta para que a Fase de Transição corra de forma tranquila e para que a aplicação possa ser disponibilizada e utilizada com sucesso.
4.2 Plano de Comunicação Cada sistema de informação tem na sua génese a satisfação de um conjunto de requisitos para um determinado público alvo. Isto é verdade, independentemente do tipo de sistema em causa. Qualquer que seja o público alvo, é fundamental comunicar quais as perspetivas de disponibilização do sistema, não só quanto ao horizonte temporal mas também quanto ao próprio conteúdo do mesmo. Conforme referido nos capítulos anteriores, aquilo que é o âmbito inicial de uma determinada release pode não ser o mesmo quando da sua conclusão. É importante disponibilizar este tipo de informação com alguma antecedência para que as entidades que vão utilizar o sistema tenham a oportunidade de efetuar eventuais ajustes à estratégia que teriam inicialmente planeado. Uma comunicação imprecisa ou fora de tempo pode ter consequências graves. O exemplo 4.1 mostra o efeito que uma comunicação tardia teve nas várias atividades que uma entidade tinha planeadas e que incluíam a colaboração de terceiros. Por uma questão de privacidade, não foram utilizados os nomes reais das entidades envolvidas.
Exemplo 4.1
COMUNICAÇÃO TARDIA A Euro Suporte é uma entidade que disponibiliza fundos para financiar projetos de investigação. Estes projetos têm de ser avaliados por peritos durante e após a sua conclusão. Compete às entidades que concorrem aos fundos submeter os relatórios intermédios e finais à Euro Suporte. Esta, por seu lado, envia-os à Peritos, Lda. que, através do seu painel de peritos, vai proceder à avaliação de cada projeto com base nos relatórios. A submissão dos relatórios é feita de forma totalmente manual, o que significa um enorme volume de trabalho, trocas de correspondência, etc. Para suprimir este problema, a Euro Suporte propôs-se desenvolver uma aplicação que permite às entidades submeter os seus relatórios online, evitando o recurso aos formulários impressos e enviados por e-mail. (continua)
— 176 —
Fase de Transição (continuação)
Com base nos elementos fornecidos pela Euro Suporte, a aplicação estaria prevista para ser disponibilizada a partir de 1 de novembro, pelo que a Peritos, Lda. reforçou a sua equipa de peritos para essa altura, já que é esperado um número elevado de submissões no arranque da referida aplicação. A pouco mais de uma semana da data inicialmente prevista para o lançamento da aplicação, a Euro Suporte, como parte do seu plano de comunicação, deixa saber que a data de lançamento da aplicação é agora a partir de 1 de dezembro, cerca de um mês depois da data inicialmente prevista. Esta informação deixou a Peritos, Lda. numa situação complicada, pois já havia contratado os peritos para o período de 1 de novembro a 31 de janeiro, sendo agora evidente que tal já não é adequado. A pouco mais de uma semana do início dos contratos, a Peritos, Lda. terá de suportar não só o custo adicional de ter os peritos “parados” durante um mês, mas também a necessidade de estender os contratos por igual período, correndo também o risco de alguns dos peritos já não estarem disponíveis.
Este exemplo reflete claramente a importância de assegurar um plano de comunicação adequado, não só no seu conteúdo e destinatários, mas também nos prazos. Assim, o plano de comunicação deve conter de forma inequívoca a data formal do lançamento da aplicação, assim como uma breve descrição do conteúdo que será disponibilizado. Outro aspeto relevante no plano de comunicação é perceber qual o universo de utilizadores que devem ser abrangidos. Estes podem ser um grupo restrito de utilizadores de um departamento de uma determinada organização, assim como podem ser um número indeterminado de utilizadores através de uma aplicação disponibilizada na Internet. Ambos os grupos devem estar incluídos no plano de comunicação. No entanto, a forma e os meios utilizados serão certamente diferentes. As secções seguintes procuram descrever a forma mais adequada para comunicar com os diferentes grupos.
4.2.1 Comunicação ao Comité do Projeto A reunião de comité do projeto, devido ao seu âmbito, é o local ideal para comunicar e chegar a acordo sobre a data e conteúdo da aplicação a disponibilizar aos utilizadores. Apesar de a proposta a apresentar não dever constituir uma surpresa, é muito importante assegurar que o comité está totalmente em sintonia com aquilo que é pretendido, de maneira a depois poder estender essa informação aos restantes grupos envolvidos. — 177 —
Desenvolvimento Ágil de Software – Guia Prático
A estrutura da comunicação a apresentar deverá ser em tudo similar ao que é feito numa reunião de comité de projeto, nomeadamente a revisão da lista de riscos, os pontos pendentes a resolver, as ações a tomar, etc. Os dois pontos que merecem especial relevo são, naturalmente, os seguintes: Data de lançamento da aplicação – Indicar não só a data proposta, mas também o impacto que a mesma tem. Se necessário, apresentar várias alternativas com as vantagens e desvantagens de cada uma, isto no caso de ser necessário tomar uma decisão quanto à melhor alternativa; Conteúdo da release – Descrever resumidamente as funcionalidades incluídas na release a ser disponibilizada, mencionando, caso se aplique, as que tenham ficado de fora, explicando o porquê e o respetivo impacto. Tal como referido anteriormente, nenhum destes elementos deve constituir uma surpresa para o comité. Poderá, no entanto, acontecer que uma nova data seja proposta, fruto, por exemplo, da necessidade de incluir mais funcionalidades numa release inicial. Poderá igualmente acontecer que não seja possível chegar a um acordo definitivo sobre a data ou o conteúdo da release, pelo que outra reunião de comité de projeto será necessária para formalizar a data e o conteúdo da release a disponibilizar. Este é um ponto fundamental, já que só com estes dados confirmados é que o plano de comunicação deve ser estendido aos restantes grupos intervenientes.
4.2.2 Comunicação ao Grupo de Trabalho O grupo de trabalho num projeto de desenvolvimento de software é, por norma, composto pelo representante do negócio, pelos stakeholders e pelos utilizadores-chave. Este grupo de pessoas é aquele com quem a equipa de Desenvolvimento vai mantendo um contacto bastante frequente, assegurando que todos se encontram constantemente a par do estado do projeto. Esse é, aliás, um dos princípios fundamentais da metodologia descrita neste livro. Assim, o grupo de trabalho deve ser igualmente incluído no plano de comunicação. No entanto, e devido à sua posição privilegiada no projeto, a forma e o timing da comunicação encontram-se bastante simplificados, já que essa mesma informação vai sendo partilhada de forma constante ao longo do projeto. Por esse motivo, a comunicação irá resumir-se à formalização de uma data de lançamento da aplicação, assim como o respetivo conteúdo da release. Nenhum destes aspetos deve constituir uma surpresa para o grupo de trabalho. A forma de comunicação pode resumir-se simplesmente a um e-mail ou, se se preferir, a uma pequena reunião com o grupo. Os pontos a abordar deverão ser os seguintes: Confirmação da data de lançamento da aplicação; Confirmação do conteúdo da release; — 178 —