O momento da seleção da metodologia de desenvolvimento de software é de extrema importância em qualquer projeto na área da informática, pois este momento irá definir a cadência com que este é desenvolvido e com que frequência é apresentado o trabalho desenvolvido ao cliente.
Tendo em conta que existem variadas metodologias com diferentes diretrizes que se adequam a determinados tipos de projeto, foi necessário ponderar alguns fatores, de forma a efetuar uma escolha. Um dos fatores considerados foi a dimensão do projeto, ou seja, o número de pessoas que iriam participar no desenvolvimento da plataforma digital, para além da possibilidade de existir ou não, uma grande quantidade de documentação associada ao mesmo.
Desta forma e tendo em conta de que se trata de um projeto de média dimensão que não necessita de uma quantidade enorme de documentação, a solução que mais se adequava era a utilização de uma metodologia ágil de desenvolvimento de software, tendo como base o agile manifesto (Manifesto for Agile Software Development, 2019), em que é dado mais valor a indivíduos e interações do que processos e ferramentas, ao funcionamento do software, do que à documentação detalhada, a colaboração com o cliente, do que negociação de um contrato, e ainda responder à mudança, do que seguir um plano.
As metodologias ágeis de desenvolvimento de software apresentam algumas vantagens e benefícios em relação às metodologias tradicionais, nomeadamente no tipo de projeto que se pretendia desenvolver. Tendo em conta que se pretendia efetuar demonstrações sistemáticas ao cliente, de forma a obter feedback e a garantir que toda a equipa de desenvolvimento do projeto estava de acordo, este tipo de metodologias parecia ser o que mais se adequava à situação. Para além disso, este tipo de metodologias não obriga a que todos os requisitos do projeto sejam definidos no início do mesmo, permitindo aos desenvolvedores e outros participantes no projeto alterarem ou acrescentarem funcionalidades a meio do mesmo caso se verifique necessário por algum motivo. Desta
forma, existe mais espaço de manobra para possíveis alterações em fases intermédias do desenvolvimento do projeto.
Apesar de existirem várias metodologias ágeis que poderiam ser utilizadas no processo de desenvolvimento deste projeto, a selecionada assemelha-se, maioritariamente, à framework Scrum. Na Figura 8 é possível observar a forma como foi adaptada a framework Scrum no âmbito deste projeto.
Figura 8 - Metodologia Scrum, adaptado de (Using Agile Scrum for Web Development | Neon Rain Interactive, 2019)
Como se pode verificar na Figura 8, existem vários papéis a ser desempenhados nesta metodologia, mais concretamente:
• O Product Owner, que, neste caso, foi desempenhado pelas Professoras Maria dos Anjos Dixe e Ana Querido, tendo como função liderar o projeto em todos os aspetos, estabelecer o elo de ligação entre o cliente e os membros da equipa e definir os requisitos funcionais a implementar no projeto;
• Os Scrum Masters, que têm como objetivo coordenar a equipa de desenvolvimento do projeto, assegurando que esta cumpre as regras e as práticas definidas na framework Scrum, de forma potencializar o seu trabalho, sendo que esta posição foi assumida pelos Professores Ricardo Martinho e Rui Rijo; • A equipa de desenvolvimento, que foi constituída por dois elementos, o autor da
presente dissertação e desenvolvedor da aplicação web (Nuno Gomes) e o desenvolver da aplicação móvel (João Caroço);
• Os clientes/stakeholders, que foram desempenhados pela equipa de investigação “Help2Care” da ESSLei.
Inicialmente, os clientes/stakeholders e os Product Owners definiam os requisitos funcionais principais a integrar no projeto Help2Care numa lista ordenada pela sua prioridade (Product Backlog). A partir desse momento, o desenvolvimento do projeto era realizado com base em iterações, sendo estas denominadas por sprints no contexto da framework Scrum. Estas iterações consistem num ciclo de desenvolvimento, no qual são definidos e validados novos requisitos ou modificados requisitos já definidos anteriormente. No caso do projeto Help2Care, estabeleceu-se um intervalo de tempo de uma semana, após a qual a equipa se reunia para validar o trabalho desenvolvido e definir novos objetivos a cumprir na sprint seguinte.
Antes de cada sprint, foi efetuada uma reunião entre a equipa (Sprint Planning Meeting) para determinar quais as funcionalidades (User Stories) a serem desenvolvidas na sprint seguinte (Sprint Backlog), tendo em conta a prioridade definida anteriormente no Product Backlog. Após o Sprint Backlog estar definido, era dado início à sprint de desenvolvimento, no qual a equipa de desenvolvimento efetuava o seu trabalho. No final de cada iteração ou sprint, foram realizadas reuniões entre os desenvolvedores, os coordenadores do projeto (Scrum Masters) e os Product Owners (sempre que possível) nas quais eram demonstradas as funcionalidades desenvolvidas nesse sprint (Sprint Demo), de forma a que estes possam observar e validar o trabalho desenvolvido. Sendo assim, este era o momento (Sprint Review) em que se identificavam eventuais problemas e erros, definindo-se em seguida as respetivas soluções a implementar.
Estas reuniões foram fundamentais para obter feedback valioso do cliente e sugestões sobre aspetos a melhorar ou a acrescentar ao projeto, transmitido através dos Product Owners, que foi levado em conta para melhorar o trabalho desenvolvido. Para além disso, estes momentos
foram utilizados para oferecer uma pequena “formação” aos representantes do cliente, uma vez que estes desempenham ou desempenharam funções de profissional de saúde, fazendo assim parte do público alvo da plataforma a ser desenvolvida. Mais se acrescenta que nestas reuniões, os representantes do cliente acediam à plataforma web através do seu computador, de forma a testarem as funcionalidades desenvolvidas até ao momento e experimentarem a plataforma em si, acompanhados pela equipa do projeto para que esta apoiasse os representantes do cliente, caso estes apresentassem alguma dúvida relativamente às funcionalidades demonstradas nesse momento.