Engenharia de Software 5. Métodos ágeis de desenvolvimento de software Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt
Desenvolver e entregar software o mais rapidamente possível é hoje em dia um dos principais requisitos Os modelos de negócio evoluem de forma bastante rápida e os sistemas de informação que os suportam têm que acompanhar essa evolução Rapid software development Neste tipo de abordagens de desenvolvimento de software as fases de especificação, design e implementação são intercaladas Os interfaces gráficos são geralmente criados utilizando um IDE com toolsets gráficos. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 2
Um dos principais motivos que levou ao surgimento deste tipo de abordagens teve que ver com a enorme carga e burocracia existente nas metodologias dos anos 80-90. Estas novas metodologias Centram-se mais no código do que no design; São iterativas; Permitem entregar ao cliente algo a funcionar num curto espaço de tempo e ir evoluindo à que medida que novos requisitos vão sendo identificados/ implementados. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 3
Um dos principais objectivos destas abordagens é de reduzir a sobrecarga, nomeadamente através da redução da documentação. Esta redução permite responder muito mais rapidamente à chegadas de novos requisitos e a mudanças dos já existentes sem necessitar de refazer muito do que já foi feito. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 4
Os princípios dos métodos ágeis: Envolvimento dos clientes; Entregas incrementais; Não devem impor processos muito formais aos membros da equipa; Acomodar as mudanças; Manter a simplicidade. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 5
Aplicabilidade de métodos ágeis Embora possam trazer vantagens para muitos tipos de projectos, na verdade, estes métodos não poderão ser aplicados em todos os projectos. Assim sendo, podem ser utilizados para: Desenvolvimento de produtos de pequena/média dimensão destinados à venda massificada; Sistemas desenvolvidos por medida para organizações em que haja um claro empenho e disponibilidade para se envolver no processo de desenvolvimento e onde não haja muitas regras e regulamentos externos que possam afectar o desenvolvimento; (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 6
Aplicabilidade de métodos ágeis Não deverão ser utilizados em projectos grandes, principalmente devido à grande relação de proximidade que tem que existir entre os elementos da equipa e que não é fácil conseguir em equipas grandes. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 7
Principais problemas Pode ser difícil manter o envolvimento dos clientes durante todo o processo; Nem todos os membros da equipa poderão estar familiarizados com este tipo de abordagens e tudo o que isso envolve; Poderá ser difícil definir prioridades sobre o que fazer em seguida quando há muita gente envolvida; Manter simplicidade pode exigir trabalho extra; (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 8
Manutenção de software A maior parte das organizações gasta mais tempo/dinheiro na manutenção do software do que propriamente no desenvolvimento inicial É pois necessário ter este aspecto em atenção se se pretender optar por uma metodologia deste tipo. Uma questão fundamental a ter em conta diz respeito à manutenção/ou não da equipa original de desenvolvimento. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 9
Desenvolvimento plan-driven vs. Ágil No primeiro caso todo o processo de engenharia de software é baseado à volta de várias fases distintas, estando o output de cada uma das fases definido à partida. No caso das metodologias ágeis, todas as fases são intercaladas e os outputs vão sendo definidos à medida que o desenvolvimento vai avançando. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 10
Desenvolvimento plan-driven vs. Ágil (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 11
Extreme Programming É eventualmente a mais conhecida e utilizada metodologia ágil de desenvolvimento de software. É na prática uma abordagem iterativa muito simplificada. Podem surgir novas versões do software todos os dias, ou até várias vezes por dia; São entregues aos clientes novas versões de 2 em 2 semanas; Todas as versão têm que ser testadas completamente antes de serem entregues aos clientes e só serão entregues se passarem em todos os testes efectuados. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 12
Extreme Programming O envolvimento do cliente deverá ser quase em fulltime; Podem ser utilizados processos como pair/group programming; Ciclo: (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 13
Princípios de Extreme Programming Planeamento incremental; Pequenas releases; Design simples; Utilizar frameworks de testes unitários; Refactoring constante do código; Todos os membros da equipa fazem um pouco de tudo; Integração contínua das novas features; Grande (total!) envolvimento do cliente (ou de um representante deste). (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 14
Extreme Programming - Requisitos Em extreme programming o cliente, ou um representante dele deverá fazer parte da equipa de desenvolvimento e é o responsável por todas as decisões relacionadas com os requisitos Os requisitos são expressos na forma de cenários ou histórias de utilizador (user stories). Estes cenários ou user stories são escritos em cartões e a equipa de desenvolvimento divide-os em tarefas de implementação. Estas tarefas constituem os requisitos e a base de todo o planeamento e estimação de custos (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 15
Extreme Programming - Requisitos Cabe ao cliente escolher quais os cartões a serem incluídos na próxima release de acordo com as suas prioridades. Cenário Tarefas (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 16
Extreme Programming - Mudança Em vez de preparar o software para futuras alterações que poderão ou não existir, em extreme programming aposta-se no constante refactoring (alterações/melhoramento) do código; Refactoring A equipa de desenvolvimento identifica possíveis melhoramentos que possam ser feitos e implementa-os assim que possível; De modo a que tudo funcione perfeitamente, o código deverá ser claro e bem estruturado; Por vezes existem no entanto algumas alterações que não são simples de fazer e podem envolver trabalho adicional, nomeadamente ao nível de documentação (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 17
Extreme Programming - Mudança Refactoring Exemplos Alteração da estrutura de classes para remover duplicação de código Limpar o código e os nomes das classes de modo a ficar mais perceptível o seu objectivo Substituir código através da utilização de componentes externos (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 18
Extreme Programming - Testes Os testes constituem um dos pilares principais da extreme programming Todas as alterações têm que ser correctamente testadas antes de serem incluídas numa nova release. Os testes deverão ser feitos a partir dos cenários. Os clientes devem envolver-se também na construção das especificações de testes e na própria realização dos testes. Recorre-se frequentemente a ferramentas que permitam fazer testes automaticamente (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 19
Extreme Programming - Testes Os testes deverão ser escritos mesmo antes de implementar. Os testes são programas escritos numa determinada linguagem e podem ser utilizados exactamente da mesma forma tantas vezes quanto necessário Exemplo: JUnit De modo a garantir que alterações feitas não originaram erros no código já feito, todos os testes deverão ser sempre corridos, mesmo os que já tinham sido feitos anteriormente com sucesso. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 20
Extreme Programming - Testes Os clientes participam no processo de testes através da definição de testes de aceitação das user stories. No entanto, uma vez que os clientes poderão não ter toda a disponibilidade desejável, poderão efectivamente não participar em todo o processo. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 21
Extreme Programming - Testes Principais dificuldades Os programadores preferem programar e não escrever testes, pelo que poderão fazer os testes de forma algo incompleta e que não incluam todas as possíveis situações e excepções. Poderá ser difícil escrever testes para algumas situações, nomeadamente no que diz respeito a questões de interacção com o utilizador. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 22
Extreme Programming Pair Programming Os pares deverão ser criados dinamicamente, de modo a garantir que todos os programadores conhecem todas as diferentes partes da aplicação (mesmo que superficialmente). É bastante benéfico e importante em equipas cujos elementos mudem constantemente. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 23
Extreme Programming Pair Programming Neste tipo de abordagem, os programadores poderão trabalhar em pares em frente ao computador. Isto permite que mais do que uma pessoa consiga ter conhecimentos profundos sobre os código desenvolvido. Funciona na prática como uma forma informal de revisão. Pode conduzir a refactoring e todo o projecto pode beneficiar. Alguns estudos apontam que o desempenho pode ser igual ou superior a ter 2 programadores isoladamente. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 24
Mais informações: http://www.codeproject.com/kb/aspnet/agilepart1.as px http://www.extremeprogramming.org/ http://xprogramming.com/index.php http://www.versionone.com/ http://www.agilewrap.com/ (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 25