ARTIGO ORIGINAL
AZEVEDO, Livyson Saymon Leão [1], NASCIMENTO, Erica de Lima do [2]
AZEVEDO, Livyson Saymon Leão. NASCIMENTO, Erica de Lima do. Unindo metodologia ágil e tecnologia de tablets em função do gerenciamento de informações escolares. Revista Científica Multidisciplinar Núcleo do Conhecimento. Ano 04, Ed. 08, Vol. 02, pp. 107-118. Agosto de 2019. ISSN: 2448-0959, Link de acesso: https://www.nucleodoconhecimento.com.br/tecnologia/informacoes-escolares
RESUMO
Este artigo se constitui a partir da descrição do desenvolvimento do projeto que teve como produto final o e-live Class. O projeto foi desenvolvido sob duas plataformas – mobile e web – utilizando a metodologia ágil do Scrum. O software que permite agilidade e confiabilidade da disponibilização de informações que, atualmente, se encontram em “diários de classe”. Nas salas de aula permite um registro mais rápido e sem retrabalho de dados gerenciados pelos professores através de tablets android e também, possibilita maior controle pelos alunos e pelas instituições das informações escolares através de um portal web.
Palavras-Chave: scrum, tablets, diário de classe.
INTRODUÇÃO
Com a tecnologia móvel mais ativa no cotidiano das pessoas, surgem necessidades especiais para preencher a demanda por processos mais automatizados e ágeis com a vantagem da mobilidade oferecida por celulares e tablets.
A e-live Software surge neste contexto, lançando o e-live Class, um sistema direcionado às instituições acadêmicas que propõe automatizar e controlar a função realizada pelo diário de classe, conhecido por muitos como “caderneta escolar”.
O retrabalho das informações fornecidas pelo diário de classe, quando os professores preenchiam as informações em papel para só após serem lançadas manualmente por outro operador ou até mesmo pelo professor no sistema da instituição é dirimido com o sistema e-live Class.
Desenhado para atuar em Tablets PC, a versão mobile do sistema registra a assiduidade dos alunos, ocorrências de sala de aula, súmula de aula, plano de aula, dentre outras funcionalidades. Estas informações são disponibilizadas imediatamente online, podendo ser visualizadas pelos alunos e pela própria instituição no site web na internet. O sistema web permite aos alunos a justificativa de suas faltas através do envio de documentos, consulta dos seus conceitos ou notas de avaliações e ainda receberão um e-mail caso suas faltas estejam próximas ao limite. O limite é definido de acordo com as parametrizações do sistema como ajuste de limite de faltas ou informar se o seu modelo de avaliação é por nota ou conceito registrados no sistema através do perfil institucional. Dentre as atividades acima também é possível à instituição efetuar as avaliações das ocorrências geradas pelos professores e providenciar suas soluções, efetuar o cadastro de cursos, disciplinas e turmas.
Essas transformações ecoam com maior força no comportamento das novas gerações (principalmente entre crianças e jovens que nasceram a partir dos anos 90 e que convivem naturalmente com computadores e redes) e suas relações com a educação. Como diz Don Tapscott, há um “generational lap” na atualidade que coloca a hierarquia do saber de pernas para o ar. As crianças são, pela primeira vez, autoridades especialistas em algo central. (KENSKI, 2007, p. 49).
O e-live Class também foi criado em cima do conceito TI Verde — produção de tecnologia conscientemente sustentável —, reduzindo as impressões dos diários de classe, as cópias das justificativas de falta em papel, economizando energia e celulose.
A sociedade está rodeada de necessidades, as quais nem sempre são atendidas de forma satisfatória. Tal insatisfação desperta um desejo de buscar formas para resolver os problemas através da tecnologia.
De acordo com Ferreira(2011), na sociedade atual, é fundamental o uso da ciência e da tecnologia, chegando a ser difícil existir um espaço em que as mesmas não se façam presentes. Conforme Sadi e Borges (2011), o uso das tecnologias em sala de aula traz um avanço significativo, não apenas para os professores e alunos, mas para todos aqueles que serão beneficiados com o desenvolvimento destes.
A informação é um produto precioso e para poder obter, em tempo real, ou instantaneamente, a informação que poderá fazer a diferença em um processo decisório, podem ser utilizados diversos caminhos, e, às vezes, nem sempre os melhores. Muitas dessas decisões, obtidas dentro do tempo e do espaço certo, podem mudar a vida de muitas pessoas. (JANZ, 2007, p. 6).
O tablet pode ser usado como uma ferramenta de gestão educacional, podendo trazer maior agilidade nos registros e disponibilidade de informações.
METODOLOGIA
Para o desenvolvimento do projeto formou-se a empresa start-up e-live. Esta foi composta por sete integrantes, todos estudantes em fase final do curso de Análise e Desenvolvimento de Sistemas, número máximo delimitado pelos clientes. Os papéis dentro da equipe variaram durante a duração do projeto e estas variações foram previstas e gerenciadas através do plano de projeto e plano de processo. Outra limitação inegociável recebida pelos stackholders foi o tempo disponível de quatro meses. Este período englobou as fases de planejamento, implantação e entrega do produto.
O produto final do projeto é o e-live Class, o qual é composto de um sistema web, desenvolvido através da linguagem de programação PHP e o sistema mobile, programado na linguagem para android, desenvolvido utilizando, em sua maior parte, a linguagem Java, e em menor escala, XML para as interfaces.
Algumas ferramentas foram utilizadas para auxiliar o controle de mudanças, a comunicação entre a equipe, o controle de versões, a implementação do código mobile e web, e um serviço de hospedagem do site e do servidor para centralizar e gerenciar dados. A ferramenta de controle, inicialmente, foi definida pela planilha em Excel que apresentava os dados referentes à mudança, no entanto, posteriormente alterou-se para a utilização do Mantis.
A comunicação foi realizada através de e-mails trocados entre a equipe. Cada integrante teve criado um e-mail associada à conta da e-live e a partir desse e-mail eram enviados algumas informações que eram consideradas relevantes. Como a equipe se encontrava, em média, cinco vezes a cada intervalo de sete dias, este uso não era intenso, mas necessário em alguns pontos.
O versionamento de código e de documentos foi realizado a partir do uso da ferramenta SVN. Todo time possuía dados de acesso ao SVN, sendo gerenciado apenas o tipo de acesso. Os stakeholders ligados diretamente a e-live, que chamaremos de equipe interna, possuíam acesso a alterações do conteúdo do repositório; já os stakeholders que faziam parte do time, mas não eram ligados à e-live, nomeado de equipe externa, o que inclui product owner, cliente e patrocinador, possuíam restrição no acesso podendo apenas visualizar as informações.
Para a implementação não foi estabelecido uma IDE — do inglês Integrated Development Environment ou Ambiente de Desenvolvimento Integrado —, única para todo o time. Cada integrante desenvolveu na IDE que possuía maior experiência. Dessa forma foram utilizadas as seguintes IDEs: Eclipse com plugin android, Netbeans com plugin JQuery, Dreamweaver e o Zend.
A metodologia de desenvolvimento foi definida pela equipe. O projeto desenvolvido sob as boas práticas de uma metodologia ágil: o Scrum. O ciclo de vida segue o fluxo definido na figura 1. As sprints foram desenvolvidas sob o time box de dez dias para executar as tarefas definidas.
Figura 1 – Ciclo de vida do processo
Com o apoio de todas as ferramentas acima, baseado no sprint backlog — como é chamada a lista de tarefas no Scrum — com as estórias quebradas em tarefas e estas estimadas em horas, a implementação foi iniciada pela equipe. Após a implementação foram realizados os testes de sistema de cada estória e apresentado ao cliente no review — reunião onde o time mostra o que foi alcançado durante o sprint. Os teste de aceitação escritos pela equipe foram disponibilizados no repositório. O cliente aceitou as estórias.
RESULTADOS
A partir da definição do período de quatro meses, este foi divido em duas semanas de concepção e planejamento do software e em seis sprints. Cada ciclo de sprint incluiu as fases de planning – onde a equipe faz a divisão de cada estória em tarefas e a estimativa das horas para duração de cada uma; fase de implementação; fase de testes; e review – apresentação do produto gerado aos clientes. Além destas ainda podemos observar a realização de daily scrum — reunião onde todos os membros diariamente dão o report das atividades em que estão trabalhando — e sprint retrospective — cerimônia realizada para levantar pontos positivos e pontos de melhorias no processo.
Durante a fase de planejamento, na fase de concepção, o time desenvolveu alguns artefatos que auxiliaram a construir a ideia do produto, como, por exemplo, o plano de projeto e plano de processo. Ainda no planejamento, na fase de definição do escopo e estimativas com o cliente, foi definido o release backlog — um subconjunto do backlog do produto que deve ser entregue na próxima versão — e estimado através da técnica do planning poker – técnica proposta pelo scrum para estimar, através do time, a complexidade das estórias através de cartas. Após a priorização do cliente das estórias, foi definido as sprints iniciais.
Na primeira sprint buscou-se minimizar um impacto inicial relacionado à curva de aprendizado da programação mobile implementando mais estórias do sistema web. Durante essa sprint aconteceu também a modelagem do banco de dados. As estórias foram realizadas, mas foram entregues posteriormente ao final da sprint e estas tarefas acabaram impactando na segunda sprint, já que foram estendidas.
Durante a segunda sprint observou-se a necessidade de alterações no banco, o que impactou no andamento do projeto já que o WebService geralmente sofria impactos consideráveis com as mudanças no banco. Neste momento o sistema web estava sendo desenvolvido apenas por um integrante já que havia apenas uma estória. Apesar do atraso inicial, o time conseguiu desenvolver as estórias planejadas e observou-se a necessidade de aumentar a equipe mobile, implicando maior potencial de agilidade posterior. Iniciou-se então a programação em pares para tentar minimizar o impacto da curva de aprendizado.
Nesta sprint, o projeto sofreu mais um impacto. Inicialmente havia sido programada a sprint com time box de quinze dias, no entanto, os clientes reduziram o tempo de cada iteração para dez dias.
Na terceira sprint foram desenvolvidas duas estórias web e uma mobile. Com apenas uma estória mobile houve um maior tempo para o aprendizado dos novos colaboradores. O desenvolvimento web foi em maior quantidade e ainda permanecia apenas um integrante com esta incumbência. Percebeu-se a necessidade de integração de uma pessoa para colaborar definido a integração para a quarta sprint.
Neste momento priorizou-se a unificação de conhecimento do grupo. Nesse intuito realizou-se uma pequena apresentação do sistema mobile. Observou-se, após esta atividade, que a equipe tornou-se mais unida e implicada nas suas tarefas com o sentimento de que todas as etapas do projeto, mesmo que não fossem explicitamente direcionadas a pessoa, dependiam de todos.
Na quarta sprint, apesar de ter um story points menor do que a sprint anterior, havia maior número de estórias a serem implementadas. A equipe apresentou uma maior integração e conseguiu alcançar a entrega de todas as estórias para o cliente, dentro do time box de dez dias.
Na quinta sprint, a equipe apresentou uma redução na agilidade do trabalho, ao contrário do planejado. Apesar da curva de aprendizado ter seu impacto reduzido nesta etapa, as estórias só tiveram seu desenvolvimento realmente iniciado após quatro dias de start da sprint. Assim o escopo da entrega não foi testado dentro da sprint, impactando na entrega, não sendo realizada sem bugs. Neste ponto o grupo percebeu a necessidade de inserir mais três estórias no release backlog. Após o aceite do cliente na mudança de escopo e re-estimado o story points e business value, uma foi inserida nesta quinta sprint e as outras duas foram adiadas para sexta.
Na sexta sprint o cansaço da equipe começou a ser evidenciado através de desentendimentos. Nesta última fase houve uma maior quantidade de estórias a ser desenvolvidas. Apesar deste fator, a equipe buscou realizar a implementação com agilidade, mas vários erros e pontos de melhoria foram citados pelos clientes na entrega. Isso gerou mais uma semana de trabalho e testes de sistema para concluir o produto.
Ao longo dos meses de projeto, apesar de existir reuniões de duas a três vezes por semana, da utilização do burndown — gráfico por onde a equipe monitora seu progresso em relação a um plano — e dos encontros quase diariamente, a ferramenta de e-mails ainda foi bastante utilizada. Observa-se, através da figura 2, que a intensidade de comunicação via correio eletrônico variou pouco durante os três primeiros meses. Reduziu-se a troca através deste canal de diálogo apenas na conclusão do projeto, já que o escopo estava quase todo completo, sendo necessário apenas para melhorias e correção de bugs, que eram comunicados via Mantis.
Figura 2 – Gráfico da relação quantidade de e-mails x meses
Durante o período de projeto, modificou-se, completamente, a forma de gerenciar as mudanças. Inicialmente foi definido o controle através de planilhas em Excel com as informações da mudança e esta era enviada para a equipe via e-mail. No entanto, observou-se, por volta da quarta sprint, que esta metodologia não estava sendo gerenciável. Não havia controle necessário de resoluções das mudanças e rastreabilidade. Portanto viabilizou-se uma ferramenta de gerenciamento que possibilitasse uma maior funcionalidade do controle de mudanças: o Mantis.
Através da figura 3 observa-se que, após essa mudança, houve maior número de solicitações de mudança, visto que o processo de solicitação se tornou mais ágil, e maiores registros de resolução.
Figura 3 – Tabela de solicitadas x resolvidas relacionada Mantis e Formulário
A partir do Burndown (figura 4) observou-se que, dentro do período total do projeto, três sprints não foram cumpridas. Na primeira sprint o time ultrapassou o time box definido para a sprint na fase inicial de projeto, devido à falha de comunicação com os clientes em relação ao tempo de duração da iteração. Na quinta e sexta sprint tiveram produtos entregues apresentando alguns erros e necessidades de melhorias, já que não conseguiu-se cumprir a fase de testes com a fase de implementação ultrapassando o tempo previsto. As melhorias e correção de bugs foram realizadas no período de uma semana, negociada com o cliente, posterior à sexta sprint.
Figura 4 – Brundown semana x esforço
Apesar do time box de algumas iterações terem sido fora do estipulado, obteve-se todas as estórias, sem bugs, entregues ao final da décima terceira semana (uma semana adicional foi cedida pelo cliente para implementação das melhorias e correção de erros do sistema. Pode-se observar, na figura 5, a porcentagem de business values entregues em relação ao escopo geral do projeto ao final de cada sprint.
Figura 5 – Relação de story points entregues por sprint em relação ao total
Ao final do projeto foram entregues 3.260 pontos de valor de negócio ao cliente em relação ao inicial de 3.120.
CONSIDERAÇÕES FINAIS
Durante o desenvolvimento do projeto e-live Class foram assumidos desafios de buscar modernização de um dos setores da educação. Dentro desta lógica foi presenciado a mobilidade chegar a vários pontos, dentre eles as instituições de ensino.
Tal inovação é apresentada às instituições com a proposta pedagógica gerada a partir deste projeto de que é possível melhorar o trabalho dos docentes com o diário de classe. Entretanto, é necessário, mudar uma cultura de longos anos para trazer a tecnologia para dentro das salas de aula. Precisa-se mostrar às direções das instituições que não se pode usar essa tecnologia apenas como marketing, como forma de atrair maior número de alunos, e os professores, mas como ferramenta para atribuir qualidade no gerenciamento das informações, confiabilidade dos dados e acessibilidade. Para ter sucesso na implementação deste software deve haver uma preocupação com treinamento e motivação aos principais responsáveis pelo uso desses instrumentos em sala de aula, os professores.
O fato do não conhecimento inicial de operar um Tablet PC, pode provocar uma resistência, contudo, isso não quer dizer que não exista interesse e vontade de serem incluídos nessa dinâmica, mesmo que o interesse seja provocado pela imagem que os meios de comunicação estão transmitindo, com o objetivo de criar um “movimento em direção à tecnologia”.
O e-live Class é promissor e a e-live acredita que a ideia deste “movimento” precisa ser bem difundida a fim de apresentar o sucesso deste projeto. A partir desta espera-se superar barreiras e continuar a trabalhar para que este setor seja ágil, organizado e correto, eliminando as falhas que o fluxo das informações do diário de classe possui.
REFERÊNCIAS
ANTONACCI, Maria Antonieta (Coord.) Trabalho, cultura, educação: Escola Nova e Cinema Educativo nos anos 1920/1930. 1993. Disponível em: <http://revistas.pucsp.br/index.php/revph/article/viewFile/12111/8773>. Acesso em: 1 jun. 2018.
FERREIRA, José Heleno. Integração: educação, tecnologia e sociedade. Disponível em: <http://www2.funedi.edu.br/revista/revista-eletronica3/artigo6-3.htm>. Acesso em: 24 mai. 2011.
GRUPO DOS GESTORES DE TI. Consumerização – uso de dispositivos pessoais no local do trabalho requer atenção da TI: 2010. Disponível em: <http://www.ggti.org.br/visao/noticias/noticias_detalhe.php?id=20> Acesso em: Jun. 2018.
JANZ, Karla. (2007). Gestão da informação na administração escolar e seu benefício para a educação. Disponível em: <http://www.scribd.com/doc/248285/GESTAO-DA-INFORMACAO-NA-ADMINISTRACAO-ESCOLAR-E-SEU-BENEFICIO-PARA-A-EDUCACAO>. Acesso em: 07 jun. 2018.
KENSKI, Vani Moreira. Educação e Tecnologias: o novo ritmo da informação. Campinas: Papirus, 2007.
LAURIA, André.; LIMA, Erica.; Araújo, Rodrigo. Contribuições da Informatização na Sustentabilidade. In: Disciplina de Metodologia científica, 2010, Recife. Quinto período do curso de análise e desenvolvimento de sistemas UNIBRATEC, 2010.
MIRANDA, Marília Gouveia. Trabalho, educação e construtivismo: a redefinição da inteligência em tempos de mudanças tecnológicas. Educação & Sociedade, Campinas, v. 51, p. 275-330, 1995.
SADI, Andréia & BORGES, Priscilla. (2011). MINISTÉRIO DA EDUCAÇÃO ESTUDA USO DE TABLETS NAS ESCOLAS PÚBLICAS. In: iG Brasília. Disponível em: <http://ultimosegundo.ig.com.br/educacao/ministerio+da+educacao+estuda+uso+de+tablets+nas+escolas+publicas/n1300061216782.html>. Acesso em: 08 jun. 2011.
[1] Graduado em Análise e Desenvolvimento de Sistemas; Pós-graduado em Gestão da Qualidade; Pós-graduando em Gestão de Projetos.
[2] Graduada em Análise e Desenvolvimento de Sistemas; Pós-graduada em Gerenciamento de Projeto de TI.
Enviado: Agosto, 2018.
Aprovado: Agosto, 2019.
