Download Agile Teaching Practices- Using TDD and BDD in Software Development Teaching

Agile Teaching Practices: Using TDD and BDD in Software
Development Teaching
Fabio G. Rocha
Layse Santos Souza
Universidade Tiradentes; ITP
Aracaju, SE
[email protected]
Universidade Federal de Sergipe; GPITIC
Aracaju, SE
[email protected]
Thiciane Suely C. Silva
Guillermo Rodríguez
Universidade Tiradentes; GPITIC
Aracaju, SE
[email protected]
ISISTAN (UNICEN-CONICET) Research Institute
Tandil, Argentina
[email protected]
ABSTRACT
1
In this paper, we aimed to analyze the application and contribution of the use of Test-Driven Development (TDD) and BehaviorOriented Development (BDD) in Software Engineering teaching. As
empirical research, we presented an experiment conducted in the
Software Engineering Laboratory (LES) course of a Private University (Tiradentes University) in the Bachelor of Computer Science
and Information Systems courses. This experiment demonstrated
the fundamentals in verifying the learning difficulties of students.
Collected data were subjected not only to quantitative analysis but
also to appropriate statistical analysis. The results showed a reduction in student absences, higher student satisfaction rate and higher
grades in the courses. Furthermore, our approach allowed students
to deliver a product in a short period, representing a possibility of
adoption of BDD due to their successful learning experience.
O ensino de Engenharia de Software tem sido um tema amplamente
debatido, Dawson [1] e Regev et al. [2] afirmam que os projetos
utilizados no ensino se afastam da realidade, formando assim, alunos
com pouco preparo para o mercado de trabalho.
Conforme Lethbridge et al. [3] as empresas tem, por vezes, que
complementar os conhecimentos dos alunos com treinamentos
para prover as habilidades necessárias para o desenvolvimento de
software. De acordo com Yamaguti et al. [4] na atualidade há um
grande desafio no ensino de Engenharia de Software no Brasil, em
razão de uma demanda por profissionais que sejam habilitados e
capacitados ao desenvolvimento de software de forma eficiente.
Ainda conforme Yamaguti et al. [4] abordagens inovadoras devem ser adotadas para permitir a integração de conteúdos por meio
da interdisciplinaridade. Assim, este estudo teve como objetivo
analisar a aplicação e a contribuição do uso do Desenvolvimento
Orientado por Testes (TDD) e Desenvolvimento Orientado por
Comportamento (BDD) no processo de ensino de Engenharia de
Software nos cursos de Bacharelado em Sistemas de Informação e
Ciências da Computação na disciplina de Laboratório de Engenharia
de Software (LES) no quarto período (segundo ano) para uma tarefa
de desenvolvimento de software, a fim de atender às mudanças de
requisitos durante o desenvolvimento do projeto.
Este experimento evidenciou os princípios necessários para a
verificação das dificuldades dos alunos na aprendizagem. Assim, as
abordagens realizadas nas análises foram quantitativa e qualitativa
empregando e relacionando os dados obtidos. Com esse experimento foi perceptível que houve uma redução no número de faltas
dos alunos, maior taxa de satisfação dos alunos e maiores notas no
curso, além da entrega de um produto em um curto espaço de tempo
comprovado através do sucesso da aprendizagem destes alunos com
a adoção do BDD.
Apesar do trabalho ter sido feito de modo colaborativo, as avaliações foram feitas tanto individualmente quanto em grupo, permitindo que o aluno aprendesse todos os aspectos do processo de
desenvolvimento do currículo. As questões de pesquisa adotadas
foram:
CCS CONCEPTS
• Software and its engineering; • Software creation and management; • Software development techniques; • Object oriented development;
KEYWORDS
BDD, TDD, Software Engineering Education, Learning Experience,
Agile Software Developlment
ACM Reference Format:
Fabio G. Rocha, Layse Santos Souza, Thiciane Suely C. Silva, and Guillermo
Rodríguez. 2019. Agile Teaching Practices: Using TDD and BDD in Software
Development Teaching. In XXXIII Brazilian Symposium on Software Engineering (SBES 2019), September 23–27, 2019, Salvador, Brazil. ACM, Bahia,
BA, Brazil, 10 pages. https://doi.org/10.1145/3350768.3351799
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from [email protected].
SBES 2019, September 23–27, 2019, Salvador, Brazil
© 2019 Association for Computing Machinery.
ACM ISBN 978-1-4503-7651-8/19/09. . . $15.00
https://doi.org/10.1145/3350768.3351799
INTRODUÇÃO
(1) O que é preciso ensinar aos alunos para lidar de forma rápida
e eficaz com mudanças de requisitos durante o desenvolvimento do projeto?
SBES 2019, September 23–27, 2019, Salvador, Brazil
Rocha et al.
(2) Como avaliar o desempenho individual ao ensinar um curso
respaldado em projeto baseado no TDD e no BDD?
Para realizar o experimento, 18 alunos dos cursos de Bacharelado em Sistemas de Informação e Ciências da Computação foram
divididos em 3 grupos de 6 alunos. Cada grupo tinha como tarefa o
desenvolvimento de um produto, o qual deveria ser desenvolvido
em um período de oito semanas. A fim de averiguar nosso objetivo,
um grupo não utilizou nenhuma das práticas ágeis, o segundo grupo
utilizou TDD e o terceiro grupo utilizou BDD.
Os resultados apresentam indícios de que o uso do BDD melhora
a capacidade de desenvolvimento de software do discente, bem
como resulta em um melhor aprendizado no processo de software,
e depois de praticá-los de forma efetiva em curto tempo, seguiu-se
em entregas com um menor número de falhas.
O restante do artigo está organizado da seguinte forma: a Seção 2
apresenta a fundamentação teórica sobre as práticas ágeis adotadas
no experimento. A Seção 3 expõe os trabalhos relacionados. A Seção
4 exibe a proposta da disciplina. A Seção 5 apresenta a metodologia
aplicada para a condução do estudo, o planejamento e os resultados
obtidos. A Seção 6 expressa o relato da experiência. A Seção 7
apresenta a discussão sobre os resultados. A Seção 8 manifesta as
lições aprendidas e, por fim, a Seção 9 expõe as considerações finais.
2
PRÁTICAS ÁGEIS
As práticas ágeis, conforme Cohn [5], são essenciais para a entrega
de produtos de forma sistemática e incremental. Assim, equipes
ágeis, vem utilizando, com sucesso, práticas consolidadas como o
Test Driven Development (TDD), refatoração, posse coletiva, integração continua, entrega continua, programação em pares e também
o Behavior Driven Development (BDD) [6].
2.1
TDD
O Desenvolvimento Orientado por Testes (TDD) é uma técnica de
programação que visa entregar um produto de qualidade em um
curto período de tempo. Dessa forma, apresenta como metas agir de
forma preventiva, prevenir possíveis erros e facilitar o entendimento
dos requisitos do sistema [7]. Idealizado por Kent Beck como parte
da Metodologia XP, inicialmente, era descrito como uma prática do
XP necessária para análises e testes que permitiam a refatoração e
a integração contínua.
Conforme Bissi et al. [8] o TDD vem ganhando popularidade
para além do XP, além disso, os autores apontam para um aumento
significativo da qualidade ao se utilizar esta prática no desenvolvimento de software. O TDD é a prática ágil mais utilizada no setor
de desenvolvimento de software, em partes pela simplicidade do
seu ciclo de vida [8], Figura 1, que também traz praticidade para
o desenvolvimento, iniciando pela criação de um teste de unidade
falho, visando garantir que o teste funciona e captura o erro, assim,
o foco é que o desenvolvedor conheça o erro/problema para que
possa implementar uma solução funcional que faça a correção, e
posteriormente, esta solução evolui por meio da refatoração.
Além disso, de acordo com Jazen e Saiedian [9], o TDD é uma
estratégia que requer a escrita de testes automatizados antes do
desenvolvimento do código funcional e suas iterações com a intenção de verificar se estes estão corretos, completos e qual o seu
nível de qualidade. Apesar de surgir como parte do método XP, o
Figure 1: Ciclo do TDD
TDD tem recebido atenção como uma prática independente, sendo
adotado por outros métodos e possuindo diversas ferramentas para
o suporte ao TDD em várias linguagens de programação. Também
foram escritos inúmeros livros que definem seu conceito. Além
disso, pesquisadores e educadores começaram a analisar os efeitos
do TDD na redução de defeitos e melhorias na qualidade dos ambientes acadêmicos e profissionais, e na integração desta estratégia
nos cursos de Bacharelado em Sistemas de Informação, Ciências da
Computação e Engenharia de Software. De acordo com D. North
[10] a utilização do TDD gerou alguns questionamentos, como:
Quais seriam os testes iniciais? O que deve ser testado? Como entender a falha de um teste? Tais questionamentos acabam levando
ao surgimento de dúvidas e, consequentemente, impactando no
desenvolvimento. Para solucionar esse problema North apresenta
o Desenvolvimento Orientado por Comportamento (BDD), que
tem como base o TDD e o Desenvolvimento Orientado a Testes de
Aceitação (ATDD).
2.2
BDD
O BDD foi idealizado por D. North [10] como uma resposta aos
problemas no TDD. Com o BDD é possível extrair as especificações
fornecidas pelo cliente durante o levantamento dos requisitos. Em
vista disso, é possível afirmar que o TDD progrediu para o BDD com
os seguintes questionamentos: Por onde começar? O que testar? O
que não testar? Quando testar? Como nomear os testes? Por que
um teste falha?
O BDD difere de outras abordagens ao descrever um comportamento do sistema na perspectiva de seus stakeholders, em todos
os níveis de granularidade [10], por assegurar que o foco em tal
descrição do comportamento do sistema proporciona uma melhor
comunicação.
A Figura 2 descreve como deve ser o ciclo do BDD. Primeiramente, é indispensável escrever um teste para descrever o comportamento esperado, logo o teste deve falhar porque o código
ainda não existe. Depois é necessário escrever o código para criar
o comportamento esperado descrito pelo teste. E, sucessivamente,
é fundamental reescrever (refatorar) o código para que este tenha
Teaching Agile with TDD and BDD
Figure 2: Ciclo do BDD
maior qualidade uma vez que o teste vai garantir que o comportamento continue de acordo com o esperado.
Smart [11] destaca que o BDD possui benefícios como redução
do desperdício, comunicação, redução de custo, mudança mais fácil e segura, e releases mais rápidas. Moraes [12] desaponta algumas vantagens do BDD, por exemplo, comunicação entre equipes,
visão do todo, compartilhamento de conhecimento e documentação
dinâmica. Portanto, o BDD é uma técnica de especificação que vincula os requisitos funcionais ao código fonte através da conexão
da representação textual dos requisitos aos testes automatizados.
Deste modo, pode-se confirmar que o BDD estende o TDD, Figura
3, visto que o TDD tem como objetivo obter a solução correta que
corresponda exatamente ao problema de negócio nos níveis de
unidade e integração, enquanto o BDD cuida do nível de aceitação,
onde os requisitos residem.
SBES 2019, September 23–27, 2019, Salvador, Brazil
encorajar o bom design e um processo disciplinado na qual ajuda a
evitar erros no momento da programação. O TDD oferece atenção
a qualidade do código e design, além de ter um significativo efeito
sobre quanto do tempo de desenvolvimento é gasto para corrigir defeitos ao invés de, por exemplo, implementar novas funcionalidades
ou melhorar o código base do projeto existente.
George e Williams [14] realizaram um estudo de caso com programadores profissionais no qual afirma que o uso do TDD com ciclo
de vida iterativo e incremental, assistida com detecção de falhas,
o tempo de programação aumentou em 16% quando comparada
com os desenvolvimentos tradicionais, por exemplo, cascata. Os
estudos de caso apresentados nos trabalhos de Nagappan et al. [15]
e Canfora et al. [16] também apresentaram conclusões semelhantes
com os desenvolvedores de empresas como Soluziona Software
Factory, IBM e Microsoft.
O trabalho de Edwards [17] aponta a necessidade de ensinar
habilidades de teste de software para alunos de computação, que,
conforme os autores, são, em geral, despreparados para esta tarefa.
Assim, os autores propuseram o uso do TDD como forma de exigir
que os alunos testem seus códigos, e apontam que os estudantes
produziram códigos com 45% menos defeitos por mil linhas de
códigos ao utilizarem o TDD. O trabalho de Eierman e Iversen
[18] compara o TDD com a programação em par, analisando, pela
percepção dos alunos, qual destas mais contribuiu para o aprendizado de programação, logo os resultados dos autores apontam
que ambas as técnicas são consideradas úteis, mas o TDD é visto
como uma prática importante.
Santos et al. [19] apresentaram TesterDS, um jogo voltado ao
ensino de Estruturas de Dados que utiliza técnicas de TDD e Teste
Estrutural de Software. O jogo tem foco em estudantes de disciplinas
de programação mais avançadas, e tem como objetivo facilitar e
estimular o aprendizado de Estruturas de Dados.
Seroa et al. [20] propuseram um processo de desenvolvimento
de software para implementação de demandas de uma fábrica de
software em ambiente acadêmico. A metodologia proposta tem
como base um modelo iterativo-incremental e inclui métodos tais
como Scrum, XP, RUP, BDD, e entre outros. O processo foi aplicado
como metodologia prática de ensino em um curso de nível técnico
de Engenheira de Software.
Como diferencial, este trabalho apresenta um relato de experiência em uma disciplina dos cursos de Bacharelado em Sistemas de
Informação e Ciências da Computação, no desenvolvimento de um
produto, comparando grupos de alunos que empregaram TDD e
BDD com um grupo que não utilizou práticas ágeis.
4
Figure 3: Integração do BDD e TDD
3
TRABALHOS RELACIONADOS
Segundo Koskela [13] o TDD é uma importante prática de teste que
visa aumentar a produtividade no desenvolvimento de produtos,
pois envolve parcialmente a escrita de testes e é uma técnica para
melhorar a qualidade interna do software, isto é, é uma forma de
PROPOSTA DA DISCIPLINA
A disciplina Laboratórios de Engenharia de Software (LES) foi uma
proposta elaborada durante a modificação dos currículos dos cursos de Bacharelado em computação (Ciências da Computação e
Sistemas de Informação) da Universidade Tiradentes com foco na
integração de conteúdos das disciplinas de modelagem, Engenharia
de Software, e programação de forma prática e aplicada. Esta disciplina está posicionada no quarto período em ambos os cursos e tem
com objetivo seguir a base nos estágios de Piaget [21], considerando
o estágio operacional formal ocorrido a partir dos 11 ou 12 anos
até a vida adulta do indivíduo. Aplicando-se os pressupostos desse
SBES 2019, September 23–27, 2019, Salvador, Brazil
estágio de desenvolvimento humano, na medida em que o aluno
decompõe o problema em etapas, partindo dos problemas gerais,
em uma visão concreta, aos complexos, desenvolve uma visão mais
abstrata, e estabelece o pensamento dedutivo-indutivo necessário
ao desenvolvimento de software ágil.
Ao posicionar os alunos como participantes ativos do processo
de solução de problemas, diante do concreto, das suas experiências
mais próximas, em um processo de interação pessoa-meio, conforme
descrito por Bigge [22], sobre a realidade percebida, o professor e
os colegas ficam, na dinâmica proposta, também envolvidos nessa
interação com vistas ao conhecimento, esse movimento “[...] implica
uma relação sujeito-sujeito-objeto” [22].
Esta atividade ocorreu em sala de aula, esse espaço “[...] pode
assumir para si a perspectiva de interação com o conhecimento e
com os atores do ato educativo, assim, assume também a função de
ser o principal lugar em que se desenvolva a inteligência coletiva”
[23]. O ato de desenvolver software resulta na criação de um objeto
com significância aos alunos, que vê a concretização da aplicação de
seus conhecimentos, além de integrar os conhecimentos adquiridos
ao conhecimento anterior. Para tal criação, os alunos são estimulados a perceber o problema de forma individual, mas sendo levado a
considerar a participação colaborativa dos demais na elaboração
da solução. Desta forma, os alunos passam a ter uma participação
ativa e interativa, a qual é mais positiva que a recepção passiva
sendo incentivada por meio da prontidão e da aprendizagem [22].
Na prática investigada, a participação do professor é especialmente relevante nos momentos da passagem da abordagem teórica
para a explicação detalhada sobre a forma da busca de solução ao
problema proposto. Além disso, é fundamental que o professor esclareça sobre a possibilidade da solução proposta ser revista pelos
alunos, constituindo um ciclo contínuo de melhoria da solução inicial. O processo de ensino e aprendizagem torna-se, assim, contínuo
na própria reconstrução da experiência [24].
Rocha et al.
um período de oito semanas. A cada semana os alunos deveriam
apresentar o progresso de desenvolvimento do produto.
Desta forma, para a avaliação e validação dos resultados individuais dos alunos por grupo através da distribuição das notas de
produto por aluno foram definidas as seguintes hipóteses:
H0: Existe diferença entre a distribuição das notas relacionadas
aos alunos, por grupo.
H1: Não há diferença entre as notas relacionadas aos alunos, por
grupo.
A coleta de dados foi realizada por meio do Github, utilizado
no projeto pelos grupos, mediante as tarefas desenvolvidas pelos
alunos e informações inseridas no Trello através das entregas semanais e avaliações dos alunos. Para aplicar o TDD foi utilizado o
JUnit e para o BDD foi utilizado o JBehave durante o desenvolvimento do projeto. Além dessas ferramentas, também foi utilizado o
Slack para a comunicação entre os membros dos grupos, no entanto
alguns destes grupos utilizaram o Slack para realização das reuniões
diárias.
5.1
5.2
5
METODOLOGIA
Como investigação empírica, a pesquisa constitui um relato de
experiência, tornando-se exploratória, sobre a verificação das dificuldades de aprendizagem dos alunos, e descritiva, quanto à experimentação do uso do TDD e BDD como metodologia para o
ensino.
As análises sobre os resultados foram feitas sob abordagem
qualitativa e quantitativa, associando-se os dados obtidos na atividade pedagógica e os referenciais adotados no estudo. Assim, esta
pesquisa foi estruturada em forma de relato de experiência visando
expressar a aplicação de práticas ágeis, TDD e BDD, como uma
alternativa para o ensino de práticas de Engenharia de Software.
O relato apresentado abrange edições do componente curricular
Laboratório de Engenharia de Software (LES), o qual possui 80
horas aula nos cursos de Bacharelado em Sistemas de Informação
e Ciências da Computação de uma Universidade Tiradentes, no
período de janeiro a abril de 2019.
A turma, composta de 18 alunos, foi dividida em 3 grupos de 6
alunos, um grupo não utilizou práticas ágeis, outro grupo utilizou
TDD e o outro grupo utilizou BDD. Cada grupo tinha como tarefa o
desenvolvimento de um produto, este deveria ser desenvolvido em
Trello
O Trello [25] é uma ferramenta web gratuita de gerenciamento
de projetos em quadros que pode ser ajustada de acordo com as
necessidades do usuário, isto é, moldada de acordo com os objetivos.
Pode ser usado tanto por um só indivíduo quanto em trabalhos
em equipe. Sua interface permite a rápida identificação do que está
sendo feito, quem está fazendo e em qual estado se encontra cada
tarefa.
Apesar de seu foco ser o gerenciamento de projetos, o Trello
também pode ser utilizado para organizar tarefas do trabalho, planos
de estudos, e entre outros. Neste estudo, o Trello foi utilizado para
acompanhar as tarefas desenvolvidas por cada grupo cruzando com
as informações de commit do Github.
Github
O Github [26] é uma ferramenta web de gerenciamento de projetos
e versões de códigos com controle de versão. O Git [27], sistema
por traz do Github, é open source e tem como função o controle de
versão. Com ele é possível criar todo o histórico das alterações no
código do projeto, e facilmente voltar para qualquer ponto caso
pretenda saber como o código estava em determinada data. Ou seja,
o Git ajuda a controlar o fluxo das novas funcionalidades.
Permite que programadores contribuam em projetos privados
e/ou open source. Oferece suporte ao recurso de organização que
é amplamente utilizado por aqueles que querem uma divulgação
maior dos trabalhos e promover uma fácil comunicação através de
recursos que relatam problemas ou mesclam repositórios remotos.
5.3
JUnit
O JUnit [28] é um framework open source que facilita o desenvolvimento e a execução de testes unitários em código Java, orientado a
objeto, exibindo os possíveis erros que estão ocorrendo nos métodos. Este framework é amplamente utilizado na metodologia TDD,
pois permite verificar se cada unidade de código funciona da forma
esperada. Como também, facilita a criação, a execução automática
de testes e a apresentação dos resultados.
Teaching Agile with TDD and BDD
5.4
SBES 2019, September 23–27, 2019, Salvador, Brazil
JBehave
O JBehave [29] é um framework Java de Desenvolvimento Orientado
por Comportamento, isto é, BDD. Sua ideia principal é escrever um
arquivo-texto que será executado linha a linha, relacionado a um
método que é a materialização em código do objetivo de negócio
da respectiva linha textual.
Os usuários podem especificar e executar as histórias que são
compostas por um ou mais cenários, e um cenário é composto de
uma ou mais etapas (Given, When e Then - Dado, Quando e Então).
É utilizado para facilitar a comunicação entre os stakeholders e
verificar o comportamento através da integração contínua. Além
disso, os resultados dos testes podem ser vistos em formatos HTML,
TXT e XML, por exemplo, e permite a integração com as principais
IDEs, como: Eclipse e NetBeans.
5.5
Slack
O Slack [30] é uma ferramenta criada para ajudar empresas na
colaboração das equipes melhorando sua comunicação interna, ou
seja, com o Slack é possível reduzir a necessidade da troca de e-mails
e da participação em diversas reuniões para tomada de decisão.
Transparente com os dados no compartilhamento de projetos e
processos decisórios. Nele é possível criar times para gerenciar a
comunicação, criar canais com os mesmos assuntos de interesse,
trocar mensagens diretamente com uma pessoa ou um grupo, citar
pessoas ou notificar um canal quando necessário e compartilhar
arquivos.
6
RELATO DE EXPERIÊNCIA
Esta seção apresenta os relatos das experiências em ensino realizadas
em uma edição do componente curricular Laboratório de Engenharia
de Software. O público alvo foi composto por 18 alunos entre 18
e 24 anos de idade, tendo entre os 18 alunos um total de 4 alunas,
representando aproximadamente 22.3%.
Estes alunos possuíam conceitos básicos, pois o pré-requisito
para LES é a disciplina de Engenharia de Software (ES) e conclusão
das disciplinas de Introdução à Programação e Programação Orientada a Objetos (POO). Vale ressaltar que esses alunos não possuíam
experiência prática ou avançada em desenvolvimento ágil de software. Além disso, houve o acompanhamento, na forma de coaching
por parte do professor, durante as mudanças de requisito realizados
após a terceira iteração. Logo, observou-se que compreender o problema e conseguir separar os requisitos estáveis dos não estáveis foi
essencial pela prática de BDD que traz a história de usuários e o
cenário como parte da prática, permitindo que os alunos obtivessem
um melhor conhecimento das partes do sistema.
O experimento foi realizado da seguinte forma, Figura 4, na
primeira semana foi realizada uma palestra sobre as técnicas ágeis e
como estas impactam no desenvolvimento de software, discutindo
as ferramentas - Trello, Github, Slack, JUnit e JBehave. Na segunda
semana foi desenvolvido uma prática utilizando as técnicas TDD e
BDD, e as ferramentas que foram discutidas na palestra. Na terceira
semana teve início o desenvolvimento da solução, sendo realizada
uma apresentação, e em seguida, iniciou-se o desenvolvimento que
foi seguido até a décima semana, oito sendo para a parte prática e
duas para parte conceitual.
Figure 4: Ciclo de trabalho dos alunos
Os grupos criaram um projeto no Trello, Figura 5, e adicionaram
o professor para acompanhar a execução das tarefas. Cada grupo
se auto organizou de forma a dispor no time de um Scrum Master
e um Product Owner, o professor atuou como Cliente, ou seja, o
responsável por passar ao Product Owner e ao grupo de alunos
o que é o produto, quais são as funcionalidades desejadas, e por
conseguinte, quem avalia as entregas realizadas pelos grupos. O
professor, além de funcionar como o Cliente, auxilia como Coach
durante as iterações [31] permitindo que os alunos tomassem as
decisões, todavia, auxiliando-os durante o processo.
Figure 5: Quadro Trello utilizado pelos grupos
A atuação do professor como Coach foi apresentada no trabalho de Rodriguez et al. [31] e empregada de forma que os alunos
tivessem alguém para dirimir dúvidas, porém, sem resolver os
problemas. Dessa forma, o professor atuaria como um guia da
SBES 2019, September 23–27, 2019, Salvador, Brazil
Rocha et al.
prática proposta. Com isso, foi observado que os alunos, após a
primeira iteração, sentiram-se confortáveis para procurar o professor em relação as suas dúvidas. Por fim, na entrega final, os
alunos apresentam o produto no repositório Github a um grupo de
professores, para uma avaliação final.
Durante as aulas, os alunos deveriam, em todos os grupos, entregar o que foi planejado na aula anterior, debater sobre o que foi
aprendido e os erros cometidos, e por fim realizar o planejamento
para a entrega da próxima aula, seguindo o ciclo de reuniões Scrum,
com exceção da reunião diária. O domínio do problema escolhido
foi Software para gestão de clínica médica. Para a avaliação
foram realizadas análises individuais e em grupos, empregando os
dados a seguir:
• Commits realizados individualmente;
• Tarefas desenvolvidas individualmente;
• Quantidade de retrabalho individual;
• Entrega produzida pelo grupo;
• Apresentação do produto;
• Resolução dos problemas pelo grupo;
• Avaliação teórica sobre a prática desenvolvida.
Desta forma, cada grupo teve a liberdade de escolher a linguagem
de programação, o Sistema Gerenciador de Banco de Dados (desde
que fosse open source) e como seria a divisão de tarefas entre os
membros do grupo. Foi apenas definido que semanalmente deveria
ser apresentado a entrega e a definição do que seria feito na próxima
iteração para o professor. Após isso, o professor deveria avaliar se
as tarefas atenderam as necessidades, senão, deveria ser inserido
como retrabalho.
Por conseguinte, os grupos se organizaram escolhendo a linguagem de programação e as técnicas ágeis a serem adotadas, conforme Tabela 1.
Table 1: Distribuição dos grupos de trabalho
Técnica ágil
Número de alunos
Sexo masculino
Sexo feminino
Linguagem
IDE
Framework
Grupo 1
Não utilizou
6
6
0
Java
Netbeans
Não utilizou
Grupo 2
TDD
6
4
2
Java
Netbeans
JUnit5
Grupo 3
BDD
6
4
2
Java
Netbeans
JBehave
Desta forma, o primeiro ciclo foi composto de uma reunião de
planejamento, na qual os alunos compreenderam o problema, discutiram e definiram as tarefas. Essa reunião foi de 1h e 30 min seguido
pela etapa de desenvolvimento. As demais iterações começaram
por uma reunião para discutir a entrega e apresentar ao Cliente.
Depois foi realizada uma revisão da iteração, para ver o que eles
aprenderam e como resolveram os problemas, em seguida planejavam a próxima iteração e iniciavam o desenvolvimento. Esta série
de ações foram realizadas em todas as demais iterações, na iteração final os alunos revisaram o que foi produzido, se reuniram
para verificar a entrega final e apresentaram ao Cliente (professor),
fazendo um relato das lições aprendidas. Durante todo o ciclo teve
o acompanhamento do Coach (professor), Figura 6.
Figure 6: Ciclo de iterações
Os grupos, na primeira iteração (semana de trabalho), não obtiveram grandes resultados, visto que, pela falta de experiência
prática, entregaram poucas tarefas e com muitos erros. Os grupos
que optaram por utilizar as técnicas ágeis, durante o primeiro ciclo,
entregaram menos do que o grupo que não utilizou técnicas ágeis,
segundo os alunos o motivo foi à falta de prática com a ferramenta
escolhida, assim, apenas o Grupo 1 obteve bons resultados iniciais,
a Figura 7 apresenta estes resultados.
Figure 7: Entregas por grupo
Teaching Agile with TDD and BDD
Durante a segunda iteração, o Grupo 2 realizou um maior número
de entregas, seguido pelo Grupo 1 e por fim Grupo 3. Neste ponto,
o Grupo 2 relatou que tinha compreendido o framework e a IDE que
auxiliou no processo de uso. O Grupo 3 afirmou que as entregas de
tarefas foram menores, porém entregaram documentações como
as histórias de usuários e os cenários. No ciclo seguinte, o Grupo
3 realizou um maior número de entregas, seguido pelo Grupo 2.
O Grupo 1 teve maior número de retrabalho relativo às tarefas
entregue por falta de integração com as novas tarefas.
A partir da terceira iteração houve mudanças para todos os grupos pela pouca experiência prática dos alunos. Como o projeto era
único e iniciado do zero (software para gestão de clínica médica,
com controle de agenda dos médicos; cadastro de pacientes, médicos
e atendimento; controle dos atendimentos), todos teriam o mesmo
ponto de partida e as mesmas mudanças solicitadas pelo cliente. O
uso de práticas ágeis e o uso do JUnit pelo grupo que adotou o TDD,
e o uso do JBehave + JUnit pelo grupo que adotou o BDD, reduziu
consideravelmente o retrabalho.
Assim, o Grupo 3 passou a realizar um maior número de entregas,
com um menor número de retrabalho, seguido pelo Grupo 2. Conforme os alunos do Grupo 3, o trabalho inicial relacionado a escrever
as histórias de usuários e cenários, obrigou que eles obtivessem um
entendimento prévio sobre as funcionalidades, o que demorou a ser
compreendido no início de como fazer, porém reduzindo o trabalho
nas fases seguintes. O Product Owner do grupo, ficou responsável
por escrever as histórias dos usuários, e relatou ainda ser mais fácil
se comunicar com o time e com o Cliente (professor) por meio das
histórias. O Grupo 2 relatou que a tarefa de criar os testes, apesar de parecer lento, fez com que o grupo conseguisse reduzir o
retrabalho pois tiveram que pensar nas entradas e saídas de cada
funcionalidade, antes de sua construção.
O Grupo 3 relatou que achou inicialmente que a utilização do
BDD atrapalharia, mesmo tendo selecionado, e que durante a primeira
iteração eles acharam que poderia ter perdido muito tempo, mas notaram que durante as iterações o BDD fez com que eles reduzissem
retrabalhos, além disso, os cenários auxiliaram na validação das
funcionalidades, antes mesmo de rodar o teste, pois eles tinham um
caminho para validação, que facilitava o trabalho de desenvolvimento.
Na penúltima iteração, o Grupo 3 tinha concluído as tarefas e
ficou apenas trabalhando em melhorias, o Grupo 2 fez um grupo
de entregas, e na última iteração apenas o Grupo 1 ainda tinha
entregas a serem feitas. Após a execução dos ciclos foram analisados
os resultados através do Trello e Github.
Vale ressaltar que as falhas foram acompanhadas durante as
entregas, e medidas em nível de funcionalidade entregue, sendo
que cada falha foi comunicada de duas formas: a) Como cliente, o
professor dizia o que ele esperava; b) Como consultor, o professor
explicava caminhos para solucionar os problemas. Para mensurar as
falhas pretendemos utilizar uma ferramenta de gestão de defeitos,
por exemplo, Mantis. Na seção a seguir foram representados os
resultados encontrados durante a execução deste trabalho.
7
RESULTADOS E DISCUSSÃO
As práticas adotadas na aula tiveram como objetivo aproximar a
vida acadêmica da vida profissional do estudante, tal ação é essencial
SBES 2019, September 23–27, 2019, Salvador, Brazil
para formação conforme apontado no Relatório Delors [32], assim,
observa-se que as práticas pedagógicas realizam a convergência
entre a teoria e a prática. Neste estudo, o modelo adotado traz o
princípio da autonomia, onde os grupos tiveram que decidir quais
práticas iriam adotar e como elas seriam utilizadas.
Como apontado por Gadelha e Castro [33], ao final da execução
deste trabalho, observou-se que na apresentação teórica do conteúdo, os alunos apresentaram pouco interesse, tanto que o Grupo
1 foi o primeiro a definir que não utilizaria as práticas ágeis durante
o desenvolvimento, os outros dois grupos definiram as práticas
somente durante a aula prática. Também foi tarefa dos alunos a
busca da melhor solução para o problema apresentado.
Ao final da execução das tarefas realizadas pelos grupos, pode-se
verificar que a utilização do BDD mostrou-se eficiente, do ponto de
vista de entrega com menos falhas, o Grupo 3 que adotou o BDD
obteve um maior rendimento, seguido do Grupo 2 que adotou o
TDD e por fim o Grupo 1 que não adotou as práticas ágeis.
Dessa forma, nota-se que as entregas de funcionalidades também são diferentes por grupo, neste caso, não foi contabilizado o
retrabalho. O Grupo 3 iniciou mais lentamente nas entregas, porém
a partir da terceira iteração os alunos mantiveram uma quantidade
alta de entregas, melhorando sua performance. O Grupo 2 iniciou
com melhor tempo nas entregas, porém durante as iterações não
ocorreu grande evolução. O Grupo 1 obteve o melhor resultado
no tempo das entregas iniciais, mas nas iterações seguintes não
manteve a estabilidade devido a grande quantidade de erros, reduzindo assim, a performance geral do grupo, como pode ser visto
anteriormente na Figura 7.
Quando comparado os resultados individuais dos alunos por
Grupo de 0 a 4, é possível notar que a prática do BDD permitiu ao
Grupo 3 manter uma pontuação maior, seguido do Grupo 2, esses
dados podem ser observados na Tabela 2.
No processo de validação quanto à distribuição das notas de produto por aluno, Tabela 2, usa-se a análise de variância com o teste de
Kruskal-Wallis [34], também conhecido como Test H, que compara
três ou mais grupos em amostras independentes analisando a existência de diferenças significativas nas médias entre os valores obtidos. Este foi adotado devido ao fato de que o tamanho da amostra é
pequeno.
Table 2: Distribuição das notas de produto por aluno
Aluno 1
Aluno 2
Aluno 3
Aluno 4
Aluno 5
Aluno 6
Grupo 1
3
2
1.5
1.5
1.5
1.5
Grupo 2
4
4
2.5
2.5
2.5
3
Grupo 3
4
4
4
4
4
3.5
Conforme a observação da Tabela 3 é possível observar que o
resultado do teste H foi de 0.6926 do p-value, df de 5 e qui-quadrado
de 3.0479. Vale ressaltar que para esse teste foram adotados o nível
de significância de 0.05 e o intervalo de confiança de 95%. O chisquared ou qui-quadrado ou X2 é uma medida de divergência entre
a distribuição dos dados e uma distribuição esperada. Nesse relato
SBES 2019, September 23–27, 2019, Salvador, Brazil
de experiência foi escolhido para determinar se o modelo estatístico
ajusta os dados de forma adequada. Os graus de liberdade (df) são
iguais ao número da amostra menos 1, isto é, seis alunos por grupo
avaliados por nota menos um igual a cinco.
Table 3: Resultados do teste Kruskal-Wallis
x2
3.0479
df
5
p-value
0.6926
O p-value é a probabilidade de se obter uma estatística de teste
igual ou mais extrema que aquela observada em uma amostra, sob a
hipótese nula (H0). Um intervalo de confiança é uma amplitude de
valores, derivados de estatísticas de amostras, que têm a probabilidade de conter o valor de um parâmetro populacional desconhecido.
O nível de significância é a probabilidade de se rejeitar incorretamente a hipótese nula (H0) quando ela é verdadeira.
Assim, nesse caso, é possível concluir que se o p-value associado
à sua estatística qui-quadrado for menor do que a seu nível de
significância selecionado, o teste rejeita a hipótese nula de que o
modelo ajusta os dados. Portanto, a H0 - Existe diferença entre
a distribuição das notas relacionadas aos alunos, por grupo
não será rejeitada visto que o p-value foi de 0.6926, isto é, existe uma
probabilidade de 69% de se obter esse resultado por acaso quando o
tratamento não tem nenhum efeito real.
Desta forma, ao se analisar o boxplot, Figura 8, é possível visualizar
as diferenças de notas dos grupos de alunos, nota-se que o Grupo
1, possui um ponto de outlier, ou seja, um aluno teve um maior
destaque comparado aos demais. No Grupo 3, que utilizou o BDD,
nota-se que há pouca discrepância entre as notas dos alunos, além
de estas serem mais altas do que dos demais grupos.
Rocha et al.
Table 4: Commits por grupo de alunos
Aluno 1
Aluno 2
Aluno 3
Aluno 4
Aluno 5
Aluno 6
Grupo 1
20
32
40
22
30
18
Grupo 2
32
8
16
16
8
16
Grupo 3
16
17
8
24
16
8
Todos os grupos tiveram um comportamento colaborativo entre
os membros, porém os Grupos 2 e 3 obtinham melhores feedbacks
durante o desenvolvimento, conforme os próprios alunos, como
resultado da adoção das práticas ágeis. Os conflitos gerados durante
as iterações foram sanados com apoio do Coach (professor), não
prejudicando o andamento geral dos grupos. O Grupo 3 afirmou que
os cenários possibilitaram uma comunicação rápida e eficiente com
os membros do time e com o Cliente (professor), além de facilitar na
apresentação final, pois tinham uma ideia de aceitação do produto.
Assim, foi possível responder as duas questões de pesquisa:
Figure 8: Boxplot comparativo de notas por grupo
Q1: O que é preciso ensinar aos alunos para lidar de forma
rápida e eficaz com mudanças de requisitos durante o desenvolvimento do projeto?
O modelo adotado obteve um bom resultado prático, porém
carece de melhorias no contexto teórico. Apesar dos alunos obterem
as teorias em outras disciplinas, foi relatado pelos alunos que a
ideia da palestra no início auxiliou e foi proposto que poderia
ter mais algumas palestras, porém, os alunos apontaram que tais
palestras seriam melhores aproveitadas se fossem conduzidas por
um profissional de mercado e não pelo próprio professor, falando
a respeito do uso das técnicas na indústria de software. Assim,
passa a ser necessário, conforme relatado, ao menos duas palestras
separadas sobre as técnicas ágeis.
Foi possível notar que, grupos que adoraram as práticas ágeis
tiveram menos problemas em relação as mudanças de requisitos,
conseguindo fazer as adaptações de forma mais ágil. Outro ponto
indicado pelos alunos como positivo foi o fato do professor além
de ser o Cliente, também atuou como Coach durante as iterações, o
que auxiliou na prática ágil durante as tarefas. Além disso, como
relatado pelos alunos, há dificuldades de lidar com as mudanças de
requisitos quando se trabalha em conjunto por causa da falta de
comunicação, sendo melhorado por meio das ferramentas, assim
os grupos adotaram o Slack como forma de manter as informações
relativas as dúvidas que surgiam durante o desenvolvimento, funcionando como uma reunião diária.
Quando analisado os commits dos grupos, o Grupo 1 apesar de
possuir mais commits, parte deles foram retrabalho, ou seja, tarefas
que tiveram de ser refeitas diversas vezes. No Grupo 2, o Aluno
1 optou por efetuar commit por cada funcionalidade e mudança
efetuada, e no Grupo 3 ocorreu um balanceamento na realização
dos commits, onde os Alunos 1 e 5 realizaram a mesma quantidade
de commits e o Aluno 4 realizou a maior quantidade de commits,
esses dados podem ser observados na Tabela 4.
Assim, em resposta a pergunta, é necessário que os alunos compreendam os requisitos e como eles impactam no produto, tal compreensão foi adquirida por meio das práticas ágeis. Também é preciso que os discentes aprendam que a comunicação entre os membros do time é essencial. Assim, o professor, atuando como Coach,
foi essencial para explicar aos times que, apesar deles se encontrarem em sala apenas uma vez por semana, a comunicação deveria
ser continua.
Teaching Agile with TDD and BDD
Q2: Como avaliar o desempenho individual ao ensinar um
curso respaldado em projeto baseado no TDD e no BDD?
O modelo de avaliação utilizado nas entregas do grupo, integrando o Trello com o Github para acompanhar, facilitou tanto
o trabalho do docente como o acompanhamento dos alunos, permitindo que o professor, atuando como Coach, auxiliasse os alunos
que tinham baixa produtividade. O Slack, que não foi utilizado para
avaliação, poderia ser um complemento, permitindo entender as
interações entre os alunos. Porém, o quadro de acompanhamento
de commits do Github, ao ser integrado com o Trello, facilitou o
trabalho de análise de produtividade individual e do grupo. Assim,
pode-se afirmar que a integração destas ferramentas pode ser utilizada como método de avaliação do desempenho individual dos
alunos.
8
LIÇÕES APRENDIDAS
Este trabalho apresentou a experiência de aplicação do TDD e BDD
na prática de ensino de Engenharia de Software, não apenas no
contexto teórico, mas também prático. Os alunos tiveram assim, a
possibilidade de aplicar os conhecimentos nas demais disciplinas
na criação de projeto real. Porém, como lição aprendida, pode-se
afirmar que ao liberar os alunos, que possuem pouca experiência
prática, para escolher técnicas não é a melhor opção, o mais adequado seria que tivesse sido determinado a utilização do BDD pelos
alunos durante a execução dos projetos. Outro ponto a ser observado foi a primeira iteração dos alunos, normalmente se obtém
um baixo rendimento, o que se mostra normal, devido a falta de
experiência dos alunos, assim, isso deve ser contabilizado para a
execução em sala de aula.
Além disso, as divergências nas escolhas das ferramentas e metodologias utilizadas entre os grupos acarretou em diferentes resultados desde o início do projeto até sua conclusão. Isso pode ser
comprovado aos observar os resultados apresentados da Figura 7,
onde inicialmente o Grupo 1 iniciou com maior quantidade de tarefas práticas e o Grupo 3 com a menor quantidade (os alunos tiveram
foco no planejamento), porém ao final do tempo estimado o Grupo
3 finalizou o projeto antes mesmo da última iteração enquanto o
mesmo não ocorreu com o Grupo 1. Dessa forma, pode-se ressaltar
que a etapa de planejamento é de extrema importância para evitar o
retrabalho, entregar dentro do prazo, e principalmente para manter
a qualidade do produto.
Por fim, o desempenho dos alunos está relacionado na compreensão dos problemas, o BDD auxiliou neste processo, mas carece de
uma forma de validar os cenários, pois, devido a falta de experiência
dos alunos, há possibilidade de se criar cenários que não tenham
utilidades reais para o projeto.
9
CONSIDERAÇÕES FINAIS
Neste trabalho foi apresentado um relato de experiência através
da adoção de práticas ágeis na prática de ensino de Engenharia de
Software. O relato cobre a edição de 2019 do componente curricular
Laboratório de Engenharia de Software dos cursos de Bacharelado em Ciências da Computação e Sistemas de Informação de
uma Universidade particular no nordeste brasileiro (Universidade
Tiradentes). Em LES são integrados diversos conteúdos como design de software, desenvolvimento, teste e validação, empregando
SBES 2019, September 23–27, 2019, Salvador, Brazil
metodologias ágeis, demanda apontada como necessária pelo mercado.
Com base nos resultados apresentados no relato, pode-se afirmar
que o BDD tem melhor aderência para a integração dos diversos
conteúdos, além de possibilitar um melhor entendimento sobre o
problema a ser solucionado, proporcionando, assim, benefícios a
aprendizagem dos alunos. Os resultados demonstram que a adoção
de práticas ágeis auxilia o aluno no processo de desenvolvimento,
reduzindo os ruídos relacionados ao entendimento do sistema, bem
como diminuindo o retrabalho em relação às funcionalidades.
Porém, cabe ressaltar que, as práticas ágeis são apenas uma parte
do processo, visto que a adoção de um modelo de entrega continua
e de reuniões também se fez necessário. Ferramentas como Trello e
Github apoiaram os alunos em relação ao que fazer e o professor em
relação à avaliação, tanto individual quanto do grupo, permitindo
uma auditoria das entregas de artefatos. Além disso, a atuação do
professor como Coach facilitou o trabalho dos alunos.
Como trabalhos futuros, pretende-se aplicar técnicas de análise
de cenário para melhorar a qualidade dos trabalhos, utilizar uma
ferramenta de gestão de defeitos, por exemplo Mantis, além de
utilizar palestras com profissionais de mercado durante as fases de
desenvolvimento, visando melhorar o entendimento dos alunos nas
técnicas ágeis.
10
AGRADECIMENTOS
Agradecemos o apoio da Universidade Tiradentes ao conceder bolsas que possibilitaram a execução desta pesquisa e ao Instituto de
Tecnologia e Pesquisa (ITP) pelo apoio.
REFERENCES
[1] Ray Dawson. Twenty dirty tricks to train software engineers. In Proceedings of
the 22nd international conference on Software engineering, pages 209–218. ACM,
2000.
[2] Gil Regev, Donald C Gause, and Alain Wegmann. Experiential learning approach
for requirements engineering education. Requirements engineering, 14(4):269,
2009.
[3] Timothy C Lethbridge, Jorge Diaz-Herrera, J Richard Jr, J Barrie Thompson, et al.
Improving software practice through education: Challenges and future trends.
In Future of Software Engineering (FOSE’07), pages 12–28. IEEE, 2007.
[4] Marcelo H Yamaguti, Flávio M de Oliveira, Cássio AW Trindade, and Alessandra
Dutra. Ages: An interdisciplinary space based on projects for software engineering learning. In Proceedings of the 31st Brazilian Symposium on Software
Engineering, pages 368–373. ACM, 2017.
[5] Mike Cohn. Desenvolvimento de software com Scrum: aplicando métodos ágeis
com sucesso. Bookman, 2000.
[6] Susan Hammond and David Umphress. Test driven development: the state of the
practice. In Proceedings of the 50th Annual Southeast Regional Conference, pages
158–163. ACM, 2012.
[7] Steven Fraser, Dave Astels, Kent Beck, Barry Boehm, John McGregor, James
Newkirk, and Charlie Poole. Discipline and practices of tdd:(test driven development). In Companion of the 18th annual ACM SIGPLAN conference on
Object-oriented programming, systems, languages, and applications, pages 268–270.
ACM, 2003.
[8] Wilson Bissi, Adolfo Gustavo Serra Seca Neto, and Maria Claudia
Figueiredo Pereira Emer. The effects of test driven development on internal
quality, external quality and productivity: A systematic review. Information and
Software Technology, 74:45–54, 2016.
[9] David Janzen and Hossein Saiedian. Does test-driven development really improve
software design quality? Ieee Software, 25(2):77–84, 2008.
[10] Dan North.
Introducing bdd (2006).
Verfügbar unter: http://dannorth.
net/introducingbdd, 2019.
[11] John Ferguson Smart. BDD in Action. Manning Publications, 2014.
[12] Lauriane Corrêa Pereira Moraes et al. Um estudo empírico sobre o uso do bdd e
seu apoio a engenharia de requisitos. 2016.
[13] L Koskela. Test Driven Practical TDD and Acceptance TDD for Java Developers.
Manning, 2007.
SBES 2019, September 23–27, 2019, Salvador, Brazil
[14] Boby George and Laurie Williams. A structured experiment of test-driven development. Information and Software Technology, 46:337–342, 04 2004.
[15] Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, and Laurie
Williams. Realizing quality improvement through test driven development:
Results and experiences of four industrial teams. Empir Software Eng, pages 289
– 302, June 2008.
[16] Gerardo Canfora, Aniello Cimitile, Felix Garcia, Mario Piattini, and Corrado Aaron Visaggio. Evaluating advantages of test driven development: A
controlled experiment with professionals. In Proceedings of the 2006 ACM/IEEE
International Symposium on Empirical Software Engineering, ISESE’06, pages
364–371. ACM, New York, NY, USA, 2006.
[17] Stephen H Edwards. Using test-driven development in the classroom: Providing
students with automatic, concrete feedback on performance. In Proceedings of
the international conference on education and information systems: technologies
and applications EISTA, volume 3. Citeseer, 2003.
[18] Michael A Eierman and Jakob Iversen. Comparing test-driven development and
pair programming to improve the learning of programming languages. Journal
of the Midwest Association for Information Systems| Vol, 2018(1):23, 2018.
[19] Giovanna Lorena Rodrigues dos Santos and Edmilson Campos Neto. Um processo
de desenvolvimento de software para o ensino técnico baseado em uma fábrica
de software escola. In Brazilian Symposium on Computers in Education (Simpósio
Brasileiro de Informática na Educação-SBIE), volume 29, page 1741, 2018.
[20] Iago Seroa, Helder Bertoldo, and Vânia Neves. Testerds: uma maneira fácil
e estimulante para aprender estruturas de dados. In Brazilian Symposium on
Computers in Education (Simpósio Brasileiro de Informática na Educação-SBIE),
volume 29, page 864, 2018.
Rocha et al.
[21] Jean Piaget and David Elkind. Six psychological studies, volume 462. Vintage
Books, 1968.
[22] Morris L Bigge. Learning theories for teachers. Harper & Row, 1982.
[23] Vani Moreira Kenski. Educação e tecnologias. Papirus editora, 2007.
[24] John Dewey. Experience and education: The kappa delta pi lecture series. Touchstone, 1997.
[25] Trello. https://trello.com/, 2019. [Online; accessed 19-may-2019].
[26] Github. https://github.com/, 2019. [Online; accessed 03-april-2019].
[27] Fabio Gomes Rocha, Pablo Marques Menezes, Methanias Colaço Rodrigues Junior,
Rogério Patrício Chagas do Nascimento, and Adicinéia Aparecida de Oliveira.
Integração contínua e controle de versão: Uma revisão sistemática. In 14th
CONTECSI-International Conference on Information Systems and Technology Management, 2017.
[28] Junit. https://junit.org/junit5/, 2019. [Online; accessed 20-april-2019].
[29] JBehave. https://jbehave.org/, 2019. [Online; accessed 15-may-2019].
[30] Slack. https://slack.com/intl/pt-br/, 2019. [Online; accessed 15-april-2019].
[31] Guillermo Rodríguez, Álvaro Soria, and Marcelo Campo. Measuring the impact
of agile coaching on students’ performance. IEEE Transactions on Education,
59(3):202–209, 2016.
[32] Jacques Delors and Zhou Nanzhao. Educação um tesouro a descobrir. 1998.
[33] Bruno Gadelha and Alberto Castro. A reference model for teaching collaborative
mobile systems. In Proceedings of the 31st Brazilian Symposium on Software
Engineering, pages 374–383. ACM, 2017.
[34] Changhee Kim and Won Sug Shin. Does information from the higher education
and rd institutes improve the innovation efficiency of logistic firms? 35(1):70–76,
2019.