O projeto SGT utiliza uma combinação de metodologias ágeis de desenvolvimento. A identificação das necessidades do sistema, atividade tecnicamente chamada de levantamento de requisitos, é realizada através de histórias de usuários. Uma história equivale a uma atividade que realizamos, por exemplo, a avaliação de uma DITCMD ou uma análise de pedido de restituição de ICMS. As histórias são contadas a um profissional que, através de perguntas direcionadas ao grupo de trabalho conhecedor do negócio (legislação, processo como é hoje e expectativas para este processo no futuro), busca obter respostas às necessidades de desenvolvimento do sistema. Estas histórias passam a compor a lista de atividades (backlog) do projeto. No grupo de trabalho que participa do levantamento de requisitos há sempre a figura do chamado “dono do produto” (product owner ou P.O.).

Metodologias ágeis são iterativas: o trabalho a ser realizado é dividido em ciclos sucessivos chamados sprints. Sprint é uma quantidade de tempo fixa, na qual são alocadas as atividades do backlog a serem realizadas neste período de tempo, de acordo com priorização e ordenação. A equipe de desenvolvimento se compromete a executar as atividades previstas para a sprint e, para segurança e efetividade dos trabalhos, uma vez que a sprint é iniciada, sua composição não se altera. Sendo um processo iterativo, conforme se aprofunda o assunto e se compreende melhor as necessidades, as histórias de usuários, estas sim, podem sofrer mudanças (metodologias ágeis encorajam estas mudanças), mas sempre fora da sprint, sendo a atividade modificada novamente inserida no backlog para priorização e entrada em sprint futura. Um modelo do funcionamento de uma sprint é apresentado na Figura 1.

Figura 1 – Modelo de funcionamento de uma sprint.

Fonte: https://gw2d.com.br/metodologia-agil, consultado em 7/6/2018.
 

No SGT, cada sprint de desenvolvimento dura duas semanas. Durante estas duas semanas são realizadas as atividades de desenvolvimento de software e adicionam-se funcionalidades à ferramenta, sempre atendendo as necessidades apresentadas pelas histórias de usuários. Portanto, ao final de cada sprint o sistema SGT conta com novas funções. Estas funções são testadas por uma equipe dedicada exclusivamente à verificação de conformidade do sistema em relação à história de usuário. A sprint de duas semanas diz respeito ao tempo de desenvolvimento do software, e não ao tempo de conclusão e entrega efetiva da funcionalidade descrita na história, uma vez que a equipe de testes pode identificar problemas de funcionamento (os bugs) e encaminhá-los novamente à equipe de desenvolvimento para que esta realize o ajuste fino da função.

Por isso é comum a entrega de sprints não ocorrer a cada duas semanas e haver intervalo entre a sprint de desenvolvimento em andamento, as sprints que se encontram em período de teste/validação e as sprints efetivamente finalizadas e entregues. De acordo com o último relatório de acompanhamento do projeto SGT, referente às atividades realizadas até o dia primeiro de junho, estamos na sprint #6 de desenvolvimento, a sprint #3 encontra-se em teste/validação e as sprints #1 e #2 foram apresentadas já em funcionamento.

Assista o vídeo: Troca de Propriedade de Veículo, para conhecer um pouco deste trabalho. Algumas telas ainda estão em inglês, mas os dados já são nossos conhecidos. Outros vídeos podem ser acessados no Portal SGT, pasta Execução => Apresentação de Sprints.