A metodologia Scrum solo consiste num processo iterativo e incremental, que une as boas práticas definidas pelo Personal Software Process (PSP) e pelo Scrum, para promover o bom funcionamento do desenvolvimento de um projeto. Esta metodologia foi aplicada apenas no âmbito do desenvolvimento de software, não incluindo a escrita deste documento e toda a pesquisa necessária para tal.
Este projeto via possibilitar aos seus utilizadores, o acesso ao ERP, através de um Web service e, eventualmente através de uma app ou um website dedicado, que consumam o serviço. No entanto, o valor deste projeto reside também no facto da conversão do código do ERP (desenvolvido durante 25 anos, por múltiplas equipas, com cerca de 4.5 milhões de linhas de código atualmente) é feita automaticamente, poupando uma enorme quantidade de recursos na sua criação e manutenção. Já que o ERP está constantemente em desenvolvimento, o Web service teria obrigatoriamente de acompanhar, adicionando um nível de complexidade na coordenação das equipas de desenvolvimento do ERP e do Web service.
Scrum solo passa por um momento inicial de definição de requisitos, seguido de sprints onde o programa é desenvolvido, seguido do deployment do programa para o cliente. Durante o processo de desenvolvimento é necessário também existir atividades de gestão de projeto. Os dois capítulos anteriores (Web API e Gerador de código) são o resultado deste longo processo.
Durante a definição de requisitos, foram feitas diversas reuniões com o cliente e orientador, de modo a obter um entendimento dos requisitos necessários do produto. Este processo resultou num documento denominado de scope (anexo 1), que contém a definição do âmbito do problema e do perfil do cliente; e, um documento denominado product backlog (anexo 2), dotado de 32 atividades que, caso concluídas, darão origem ao produto final, que irá ser entregue ao cliente.
A Web API tem a particularidade de não ter uma interface de utilizador tradicional. Em vez disso, a sua interface é feita através de URL’s (ver [1]). Ou seja, o protótipo de software é constituído por este padrão genérico para a interface, que será depois utilizado durante a geração de código.
“{Domínio}/api/{classe}/{método}/{parâmetros}” (1)
O repositório do processo está dividido em duas partes. Os artefactos gerados relativos à utilização do Scrum solo foram arquivados numa pasta na cloud, utilizando os serviços da Google Drive. Já o código
41 desenvolvido, foi guardado na rede local da PrimaveraBSS, e foi gerido através da ferramenta TFS (Team Foundation Server).
Foi definido que os sprints seriam constituídos por cinco dias úteis de desenvolvimento, no entanto, um sprint não representa necessariamente uma semana, devido ao interrompimento do desenvolvimento por razões externas, tais como a escrita de artigos científicos ou do presente documento.
O desenvolvimento do projeto começou a 18 de dezembro, no entanto já existiam protótipos funcionais para a geração de código e da Web API. Esta facto economizou algum tempo inicial de pesquisa e adicionou um nível de segurança ao projeto. Existe um total de 10 sprints desde o início do projeto até à conclusão do mesmo (figura 27).
Entende-se que, segundo o trabalho Pagotto et al. (2016), após um sprint é suposto ser gerado um plano de desenvolvimento. Neste caso, a Web API já respeita toda as regras de negócio impostas pelo ERP. Este facto provém da utilização exclusiva da camada de negócio do ERP na Web API, ou seja, todas as regras de negócio serão respeitadas, tal como no ERP, tornando-se dispensável a elaboração do artefacto.
Outro artefacto importante para a organização do projeto são as atas, no entanto, no decorrer deste projeto, não foram elaboradas devido ao clima de proximidade entre o developer e o orientador. Este clima contribuiu para a existência de uma quantidade substancial de reuniões informais, permitindo que o orientador estivesse sempre a par do desenvolvimento do projeto.
42 Quanto ao produto, foram guardadas regularmente versões novas no TFS, permitindo o acesso ao código a pessoas autorizadas, e ter acesso aos registos de todas as mudanças feitas. O sprint backlog (anexo 3) tem como objetivo identificar quais as tarefas do product backlog executadas num determinado sprint, a sua data de começo e o tempo despendido na sua conclusão. Embora seja importante para o futuro ter este artefacto bem documentado e legível para outras pessoas que não o developer, não há necessidade da existência de ferramentas complexas para a sua gestão, uma simples folha de papel ou um documento Word é suficiente. No caso representado na figura 28, é possível visualizar as tarefas do sprint (assinaladas com uma seta) no topo da página e pequenas tarefas apontadas (assinaladas com um hífen), tipicamente pequenos bugs a ser corrigidos.
A data de término do desenvolvimento do projeto coincide com a data de entrega deste documento. Este facto impede a execução da atividade de deployment e a elaboração de testes automáticos que permitam testar as funcionalidades da Web API.
Em projetos desta grandeza, existem riscos adicionados associados ao trabalho, não existentes em projetos de desenvolvimento de software tradicionais. Os riscos identificados passam pela limitação de acesso ao código original do ERP e a sua complexidade; entropia entre o ERP e Web service (a utilização certos mecanismos para o uso de assemblies pelo ERP, causou bastantes problemas devido à incompatibilidade desses mecanismos com a Web, resultando na necessidade da alteração do código original do ERP, por exemplo); existiram também problemas em trabalhar com a versão do ERP que estava em desenvolvimento, por vezes foram encontrados bugs, resultando em tempo despendido à
43 procura da origem do problema; finalmente, a necessidade da mudança de máquina, também se mostrou um contratempo, devido à dimensão do projeto e da configuração de diversos componentes de suporte ao desenvolvimento.
A metodologia do Scrum solo, embora tenha uma tarefa de gestão de projeto, não responde bem a estes casos de forte componente de integração. É proposto que seja criada uma tarefa de mitigação de risco, equivalente a uma percentagem baixa do tempo despendido por sprint, que pode ser preenchida por uma tarefa de desenvolvimento caso haja disponibilidade. Esta tarefa de mitigação poderá, por exemplo, ser adicionada no final de todos os sprints, valendo 2-4h.
44