Usando Metodos Ageis para Ensinar Metodos Ageis

Avelino Ferreira Gomes Filho1, Carlos Felippe Cardoso de Resende1, Rodrigo de Toledo1

1Programa de Pos-graduacao em Informatica – Universidade Federal do Rio de Janeiro (UFRJ).Caixa Postal 15.064 – 91.501-970 – Rio de Janeiro – RJ – Brasil

avelino.filho@ppgi.ufrj.br, carlos.resende@ppgi.ufrj.br, rtoledo@ufrj.br

Abstract. In the Agile Methods Discipline offered to undergraduate students ofthe Federal University of Rio de Janeiro (UFRJ), the teachers decided that thetraditional model of education would not be the most suitable way of teachinga subject that breaks so many paradigms. This paper presents the four yearsexperience of the teachers applying agile concepts in the Agile Methods disci-pline. Our goal is to report how they use these concepts to create a stimulatingand effective learning environment.

Resumo. No Curso de Metodos Ageis oferecido aos alunos de graduacao daUniversidade Federal do Rio de Janeiro (UFRJ), os professores decidiram queo modelo tradicional de educacao nao seria o mais adequado para o ensinode um assunto que quebra tantos paradigmas. Este artigo apresenta os quatroanos de experiencia dos professores aplicando conceitos ageis na disciplina deMetodos Ageis para os alunos de graduacao do curso de Informatica. Nossoobjetivo e demonstrar como o uso desses conceitos ajudou a criar um ambientede aprendizagem estimulante e eficaz.

1. Introducao

Compartilhar, construir conhecimento e tornar alunos agentes ativos do ensino nao e umatarefa facil de ser realizada. Utilizar praticas comuns, em que o professor transmite seuconhecimento para a turma que passivamente assiste as aulas e no final do perıodo eavaliada por uma prova, pode nao ser o meio mais estimulante para engajar os alunos noaprendizado.

Na disciplina de Metodos Ageis do curso de Graduacao em Informatica da Univer-sidade Federal do Rio de Janeiro (UFRJ), os professores decidiram que o modelo tradici-onal de ensino nao seria o mais adequado para um tema que representa quebras de variosparadigmas. Eles decidiram aplicar valores e princıpios ageis como auto-organizacao,foco nas pessoas, transparencia, disciplina, respeito, curtos ciclos de feedback nao so noconteudo da materia, como tambem na forma como a disciplina e realizada.

Este artigo apresenta como os conceitos, princıpios e valores que governam osMetodos Ageis de Desenvolvimento de Software sao aplicados ao contexto de educacao eaprendizado dessa disciplina na UFRJ. Na secao 2 descrevemos os trabalhos relacionadoscom os temas aqui abordados. A secao 3 apresenta como os conceitos ageis sao aplicadosem sala de aula. A secao 4 relata os resultados alcancados ate o momento pela aplicacaodo metodo desenvolvido pelos professores da disciplina. Por fim, na secao 5 apresentamosa conclusao do trabalho.

2. Trabalhos RelacionadosMetodos Ageis nao deve ser entendido como um modelo unico de desenvolvimento desoftware. Na verdade, o termo serve como um guarda-chuva para um extenso conjuntode metodologias, praticas, frameworks e tecnicas compatıveis com os valores e princıpiosdescritos no Manifesto Agil [Beck et al. 2001] [Abbas et al. 2008].

Uma das metodologias mais populares e bastante utilizada pelo mercado dedesenvolvimento de software [de O. Melo et al. 2013] e o Extreme Programming (XP)[Beck 2000]. Diversos artigos sobre a aplicacao, funcionamento e evolucao dessa me-todologia no contexto de educacao foram escritos. Entretanto, duas experiencias saode grande relevancia para a disciplina descrita nesse artigo. A primeira, na Univer-sidade de Sao Paulo (USP), foi a criacao do Laboratorio de Programacao Extrema, ocurso academico mais antigo e ainda em funcionamento sobre Metodos Ageis no Bra-sil [Corbucci et al. 2011]. A segunda experiencia foi a criacao do curso de ExtremeProgramming na propria Universidade Federal do Rio de Janeiro (UFRJ) pelo profes-sor Vinıcius Teles que assim como o laboratorio da USP privilegiava a construcao doconhecimento atraves da aplicacao da teoria em problemas reais e construıa o conhe-cimento dos alunos atraves de uma abordagem experimentativa, reflexiva e colabora-tiva [Teles and de Oliveira 2003]. Ambas experiencias foram fundamentais, pois desdeo princıpio basearam a construcao do conhecimento na pratica e reflexao dos alunosem detrimento do modelo tradicional de aulas expositivas e prova no final do perıodo[Goldman et al. 2004] [da Silva 2007] [Santos et al. 2012].

Alem de entender a aplicacao do XP em ambiente academico, e importantetambem conhecer a aplicacao do framework Scrum [Sutherland and Schwaber 2011], umdos mais utilizados pelo mercado [Version One 2013] [de O. Melo et al. 2013], nessemesmo contexto. Dois trabalhos relevantes nessa area foram desenvolvidos pela Uni-versidade Federal de Santa Catarina (UFSC) [von Wangenheim et al. 2013] e pela Uni-versidade do Minho em Portugal [Fernandes and Sousa 2010], por contar e avaliar o fun-cionamento de abordagens praticas, experimentais e ludicas para fazer com que os alunosentrem em contato com o framework. O uso desse tipo de estudo e importante, por relatare descrever a criacao de um ambiente divertido, pratico, colaborativo, capaz de auxiliar oaluno a construir conhecimento de Metodos Ageis.

Outro metodo que e muito explorado na disciplina da UFRJ com o objetivo decriar uma cultura empreendedora extremamente focada no produto com suas funcionali-dades essenciais e o Lean Kanban [Anderson 2010]. Tal metodo foi estudado em contextode aprendizado por Anderson e outros [Anderson et al. 2011] que descrevem tambemcomo a abordagem pratica, experimental e reflexiva auxilia os praticantes de Lean Kan-ban a construir o conhecimento e aprimorar seus processos de construcao de software. Aproxima secao descreve como esses trabalhos influenciaram o desenvolvimento da disci-plina de Metodos Ageis na UFRJ.

3. A Disciplina de Metodos AgeisA disciplina de Metodos Ageis comecou a ser ministrada para alunos da graduacao doDepartamento de Ciencia da Computacao da Universidade Federal do Rio de Janeiro(UFRJ) pelo professor Vinıcius Teles em 2002. Na epoca o curso tinha foco em ExtremeProgramming (XP), metodologia a qual o professor Vinıcius Teles foi um dos pioneiros

no Brasil [Teles 2007]. A disciplina foi oferecida e ministrada ate 2006. Apos um hiatode cinco anos, em 2011, a disciplina passou a ser ministrada pelo professor Rodrigo deToledo em conjunto com o professor Carlos Felippe Cardoso de Resende que ampliaramo foco de XP para Metodos Ageis de Desenvolvimento de Software. Trata-se de umadisciplina eletiva, que tem carga horaria de 60 horas e equivale a quatro creditos (quatrohoras semanais durante um semestre). O unico pre-requisito para que o aluno nela se ma-tricule e ter cursado a materia de quinto perıodo Fundamentos de Engenharia de Software.Nessa secao serao descritas algumas das praticas baseadas nos Metodos Ageis utilizadasna disciplina.

Esta secao apresenta como os valores, princıpios e praticas ageis foram utilizadosno desenvolvimento da disciplina. Serao apresentados o modelo de selecao de alunos, ometodo de ensino, a forma como a melhoria contınua e realizada e os criterios de avaliacaodos alunos.

3.1. Selecao de Alunos

Em um perıodo, apenas vinte alunos participam da materia por restricao dos propriosprofessores. Porem, todos os anos, a quantidade de interessados em cursa-la e mais que odobro do numero de vagas. Os professores decidiram entao aplicar os princıpios e valoresdos Metodos Ageis como auto-organizacao, transparencia e respeito ao proximo ja naselecao dos alunos [Beck et al. 2001] [Teles 2005] [Sutherland and Schwaber 2011] .

Inicialmente eles se reunem com todos os interessados e juntos decidem oscriterios que utilizarao para selecao. Estes devem ser simples, relevantes e acordadoscom todos os participantes do processo, por exemplo: demonstrar capacidade de traba-lhar em grupo, ter conhecimento sobre linguagens de programacao, poder compareceras aulas pontualmente, nao estar cursando materias que reconhecidamente tomam muitotempo de estudo do aluno, entre outros.

Uma vez que os criterios tenham sido definidos, os dez alunos mais antigos docurso e interessados na materia sao selecionados para desempenhar o papel de entrevis-tador. Os dez alunos formam cinco duplas e cada dupla deve entrevistar e selecionaros demais alunos interessados para cursar a disciplina do perıodo, sempre observando oscriterios decididos por todos. Para que os alunos comecem praticando a auto-organizacao,os professores nao interferem na selecao de alunos. Eles estao disponıveis para ajudar osentrevistadores em caso de duvidas. Para demonstrar respeito ao proximo e transparencia,no final da selecao, todos os alunos entrevistados recebem presencialmente feedback in-formando os motivos que levaram a sua aprovacao ou reprovacao na selecao.

3.2. Ensino Baseado em Problemas Reais

As aulas tem como objetivo fazer com que os alunos adquiram conhecimento sobreMetodos Ageis atraves da experiencia pratica e reflexao das suas acoes. Esse modelo euma implementacao do Aprendizado Baseado em Problemas [Wood 2003] e que por suavez tem como bases as teorias de aprendizagem Experimental [Keen and Mahanty 2006],Transformativa [Mezirow 2000] e de Aprendizagem Social [Armitage et al. 2008].

No inıcio do perıodo, os professores pedem para que os alunos pensem em proble-mas que eles percebem no dia a dia e que eles poderiam resolver atraves de um software.

As unicas restricoes sao: a) deve ser um problema real; b) pode ser resolvido por soft-ware; c) deve ser util para a comunidade. O tema e de livre escolha: transporte, servicos,estagios, alimentacao, confraternizacoes e etc. Tres problemas sao selecionados pelosalunos por votacao. A cada aula eles servem para “puxar” os conceitos de Metodos Ageisconforme sera descrito na subsecao 3.3. O problema selecionado desencadeara o traba-lho em grupo e no final do Sabadagil o software e disponibilizado para usuarios reais. OSabadagil e o evento que tem como objetivo fazer com que os alunos construam em umdia as funcionalidades consideradas por eles e pelos professores como essenciais para re-solver o problema. Nesse dia eles utilizam diversos metodos aprendidos durante as aulas.Esse evento sera melhor descrito na subsecao 3.5

As aulas sao dividas em temas e cada tema e uma etapa para a solucao do pro-blema imaginado. Comeca desde a concepcao ate a disponibilizacao para o publico, emum ciclo similar ao de Lean-Startup [Ries 2011] apresentado na Figura 1 e explicada aseguir. Nesse ciclo, conforme ja escrito, inicialmente, os alunos pensam em um problemae nas hipoteses que podem resolver o problema, depois definem os possıveis stakeholdersque serao afetados pela solucao. Dentro desse grupo de stakeholders, ha um subgrupo depossıveis usuarios que podem ser outros alunos, professores, funcionarios ou uma comu-nidade especıfica. Os alunos podem conversar com essas pessoas para obter informacoesrelevantes sobre o problema. Nao ha a figura do cliente que ira patrocinar a solucao. Essespossıveis usuarios nao participam da validacao inicial do produto. Essa validacao iniciale feita por pessoas externas convidadas para o Sabadagil.

Criadas as hipoteses e definidos possıveis stakeholders, os alunos devem pensarsobre o negocio em que eles estao prestes a entrar. Eles devem tentar avaliar se o problemae um problema de fato, se ha usuarios potenciais para o produto e na viabilidade domesmo. Nesse momento sao utilizadas tecnicas de Metodos Ageis como o ValidationBoard [The Startup Machine 2014] e jogos de inovacao [Hohmann 2006] com o intuitode verificar se a ideia que eles tiveram e ou nao e viavel e se tem potencial de aceitacao.

Caso os alunos concluam que a ideia e viavel e tem potencial deaceitacao, eles passam a desempenhar o papel de Product Owner (P.O.)[Sutherland and Schwaber 2011]. Inicialmente os alunos pensam quais seriam asPersonas que utilizariam o software. Essas personas sao os possıveis perfis de usuarioque utilizarao o sistema [Cohn 2004]. Definidas as Personas, os alunos comecam adescrever as funcionalidades que mais agregam valor para os possıveis usuarios. Cada

Figura 1. Ciclo de Lean Startup que serve como base para a disciplina deMetodos Ageis.

funcionalidade e escrita no formato de User Story [Cohn 2004] que a apresenta de formabastante sucinta e do ponto de vista do negocio, sem jargoes tecnicos. O P.O. tambemdeve valorar cada User Story indicando o quanto a transformacao desta em software iragerar de ganho para o negocio. Todas as User Stories sao colocadas em um artefatochamado Product Backlog. Cada User Story ganha um vınculo com: a Persona quesera diretamente atingida quando ela for disponibilizada no software, o esforco estimadopelo grupo para realizar a implementacao. Uma dinamica para a construcao do ProductBacklog e a Prune the Product Tree [Hohmann 2006], como na Figura 2.

A construcao do Software indicada na Figura 2 pelo processo Scrum ocorre du-rante as secoes de Coding Dojo (Subsecao 3.3) e no Sabadagil (Subsecao 3.5). Durante oSabadagil, a construcao do produto e validada pelos alunos dos outros grupos, professorese profissionais externos convidados pelos professores. No final do Sabadagil, os alunoscolocam o produto em producao, disponibilizando o software na internet ou em algumaplataforma de distribuicao como a Apple Store ou Google Play.

3.3. Ensino PuxadoGrande parte do conteudo da materia e “puxada” pela pratica e experiencia que os alunosadquirem ao resolver problemas reais. Espera-se que esse modelo auxilie os alunos a com-preender melhor os temas que estao sendo apresentados pelos professores, promova a re-flexao constante e colaborativa sobre o resultado das acoes por eles tomadas e consequen-temente aprimore continuamente o aprendizado de todos os envolvidos [Bolton 1999][Wood 2003].

O processo de aplicacao do ensino puxado e dividido em quatro etapas. Inicial-mente, os professores apresentam sucintamente o tema para os alunos. O tema e acom-panhado de um problema real que devera ser resolvido na aula. Em seguida os alunostentam resolver o problema aplicando e desenvolvendo aquele conhecimento sucinto pas-sado pelos professores. Apos essa etapa, os alunos e professores refletem e discutemsobre o que foi realizado, as solucoes aplicadas e as duvidas que surgiram. De possedessas informacoes, os professores entao apresentam todo o conhecimento teorico sobreo tema.

Um exemplo desse ensino puxado acontece na aula cujo tema e Validacao deIdeias. Como descrito na subsecao 3.2, os alunos, no inıcio do perıodo devem pensarem um problema real que os afete e sua solucao atraves de um software. Nessa aulaespecıfica, os professores questionam como os alunos fariam para avaliar se o software

Figura 2. Alunos fazendo uso da tecnica de Prune the Product Tree para aconstrucao do backlog.

que eles imaginam tem potencial para resolver o problema e ser utilizado por usuariosreais sem implementar uma linha de codigo e gastando muito pouco tempo. Os professo-res apresentam sucitamente o Validation Board [The Startup Machine 2014] e como elefunciona. Os alunos utilizam o Validation Board e chegam as suas solucoes e questio-namentos. Apos a experiencia pratica e reflexao em conjunto, os professores apresentamtoda a teoria sobre a origem desse quadro desde o Business Model Canvas, conceitossobre Pivotagem [Ries 2011] e metricas de software.

Outra forma que os professores encontraram para aplicar o ensino puxadofoi atraves de secoes de programacao projetada, conhecidas como Coding Dojo[Delgado et al. 2012]. Elas tem como objetivo criar um ambiente colaborativo de aprendi-zado contınuo. Funcionam atraves de ciclos curtıssimos em que os alunos sao convidadosa resolver um problema e em conjunto tentam chegar a uma solucao. Ao longo do perıodoos professores aproveitam essas secoes para puxar a teoria sobre Test-driven Development[Beck 2003], Integracao Contınua, Injecao de Dependencia, Teste em Banco de Dados,etc.

3.4. Melhoria Contınua da DisciplinaUma das grandes preocupacoes dos professores e aprimorar continuamente o curso, naoso de um perıodo como tambem para as turmas vindouras. Eles utilizam feedback cons-tante dos proprios alunos em secoes que acontecem no final da aula. Para tal, os professo-res e alunos fazem a reuniao de licoes aprendidas no dia. Essas licoes devem responder aduas questoes para auxiliar o ensino puxado: O que aprendemos hoje? O que gostarıamosde ter aprendido? E tambem duas questoes para a melhoria contınua baseadas no Scrum[Sutherland and Schwaber 2011]: O que foi bom e devemos continuar fazendo? O quepodemos melhorar? Com isso os professores tambem conseguem uma maior participacaodos alunos na disciplina, pois esses sentem-se responsaveis pelo caminho que eles mes-mos escolhem.

Um exemplo dessas licoes aprendidas dado pela turma de 2014 na aula cujo temafoi Produtos Enxutos. O que aprendemos: “Pivotagem; eXtreme eXperience; primeirofalar do problema e depois falar da solucao; nao existem requisitos, mas hipoteses; Mi-nimum Viable Product”. O que aprendemos nao aprendemos e gostarıamos de ter apren-dido: “Formula do Alisson Vale sobre reducao do tempo entre a hipotese e o feedbackdos usuarios; Quadro de Validacao de Ideias; Business Model Canvas”. O que foi bom:“Horario da aula; quebrar paradigmas; aula focada”. O que podemos melhorar: “projetoresta com problema, horario de chegada dos alunos”. Essa retrospectiva e sempre anotadaem um bloco de notas virtual e compartilhado (http://dontpad.com/ufrjagil).

3.5. SabadagilO aprendizado academico e muito importante, porem os futuros profissionais estarao su-jeitos a diversas outras experiencias quando chegarem ao ambiente corporativo. Pressaopor prazos, mudancas de escopo, negociacao constante, etc. Pensando nisso, os profes-sores desenvolveram o Sabadagil. Um evento em que os alunos em um unico dia e emiteracoes muito curtas implementam as funcionalidades essenciais do software que elesvem trabalhando durante o curso. A expectativa e que este evento proporcione apren-dizado acelerado dos alunos. Assim como as secoes de Coding Dojo descritas no item3.3, objetivo principal do evento nao e a criacao do software, mas sim a experiencia e a

reflexao que os alunos fazem ao aplicar o conhecimento adquirido ate o momento em umcontexto bem proximo ao que eles vivenciarao no mercado de trabalho.

O Sabadagil e um evento que ocorre uma vez no final de cada perıodo, sempre aossabados, daı o seu nome. O nıvel de comparecimento de alunos e muito alto. Nas quatroedicoes realizadas apenas um aluno faltou.

O evento conta tambem com profissionais que possuem reconhecida com-petencia no uso de Metodos Ageis no seu trabalho. Sao pessoas externas a univer-sidade convidadas para desempenhar os papeis de Product Owner e Scrum Master[Sutherland and Schwaber 2011]. O Product Owner foi descrito na subsecao 3.2, ja osegundo papel e o responsavel por proteger o time de interferencias, impedimentos, alemde assegurar que o processo, incluindo as reunioes de apresentacao e retrospectivas, fun-cione corretamente. Tambem sao convidados outros profissionais com grande experienciaem Metodos Ageis para desempenhar o papel de Agile Coach [Adkins 2010]. Esses temcomo principal objetivo servirem de tutores para os Product Owners e Scrum Masters nasrealizacoes de suas acoes. Essa aproximacao de pessoas do mercado com os alunos dagraduacao e feita para que compartilhem suas experiencias.

Seguindo a proposta do Lean-startup apresentada na Figura 1, o Sa-badagil implementa o processo simples do framework Scrum (To do, Doing eDone)[Sutherland and Schwaber 2011] para controlar a execucao das User Stories. Cadagrupo tem uma sala disponıvel, com tomadas para notebooks, quadro branco, lanches equalquer material que o grupo ou os profissionais externos tenham trazido. Os profissio-nais sao divididos e alocados conforme interesse e concordancia do grupo.

Uma vez que o ambiente esteja preparado, a primeira coisa que o grupo faz eapresentar a visao do produto no formato de Elevator Test [Moore 2002], as Personas e asUser Stories para os participantes externos que desempenham os papeis de Product Ow-ner e Scrum Master. Apos a explicacao, os participantes externos podem fazer perguntase ponderacoes sobre o que lhes foi apresentado. Quando todas as duvidas forem resolvi-das, o desenvolvimento do produto comeca segundo a priorizacao das User Stories. Asiteracoes acontecem no formato de Sprint com 1h30 de duracao. No final de cada Sprinto grupo deve apresentar o software para o Product Owner que podera aceitar ou reprovaro resultado da iteracao, alem disso o Product Owner pode fazer qualquer mudanca quejulgar necessario nas User Stories (inclusao, alteracao e exclusao). Sao realizadas qua-tro iteracoes durante o dia e no final, espera-se que o grupo tenha implementado o quefoi definido como Minimum Viable Product (MVP) que sao as User Stories essenciaispara validar se a ideia que eles tiveram no inıcio do perıodo e ou nao viavel, se despertao interesse de usuarios reais e se consegue resolver o problema inicialmente imaginado.A escolha do MVP faz parte da nota do aluno, no geral sao apenas as quatro ou cincoUser Stories com o maior valor agregado para os possıveis usuarios. O resultado do diae apresentado para toda a turma e caso seja aprovado pelo Product Owner do grupo, elee disponibilizado na internet para receber feedback dos usuarios reais. Durante o evento,os times fazem uso de visibilidade e polıticas explıcitas do processo, praticas advindas doKanban, ao explicitar as varias etapas e suas tarefas atraves de post-its no quadro do time.

Caso a implementacao do MVP fique incompleta, ou caso o grupo deseje ir alemdas funcionalidades essenciais, ele podera continuar com o desenvolvimento como ati-

vidade extra-classe. Em alguns perıodos, apos disponibilizar o produto na internet, eesperado que os alunos consigam usuarios reais com o objetivo de colher feedback depessoas que ate entao desconheciam os produtos. Tambem e desejavel que os alunos co-lham metricas de utilizacao e possam adaptar o software ao uso real. As metricas podemser usadas para obter feedback sobre o uso (quantidade e frequencia de uso das funci-onalidades, cliques na aplicacao, buscas realizadas na aplicacao), sobre a receptividade(quantidade de visitantes e visitas, opt-in e opt-out tempo de retencao, quantidade dedownloads (Aplicacoes Moveis)), sobre o negocio (palavras que se buscadas no Google eacham o produto, origem das visitas), sobre aspectos tecnicos (velocidade do acesso), etc.

3.6. MinutagemComo pode ser visto nas subsecoes 3.3 e 3.2, os professores procuram dividir cada aulaem partes pratica, teorica e de reflexao, sempre respeitando o conceito de Time-Box[Sutherland and Schwaber 2011] em que cada etapa da aula respeita uma quantidade fixade tempo que nao deve ser ultrapassada. Portanto, o sucesso da disciplina depende dapresenca e pontualidade de todos os alunos. Nao faltar e chegar no horario e essencialpara que eles, individualmente e coletivamente, tenham um bom aproveitamento da dis-ciplina.

Para estimular os alunos a serem pontuais, os professores definiram que um per-centual da nota deles seria dado pelo tempo que eles permanecem em sala de aula. Tra-dicionalmente isso seria feito atraves da lista de chamada dos alunos realizada no inıcioda aula, porem esse tipo de controle e contrario a filosofia Agil e foi descartado pelosprofessores. Entao, com o intuito de promover a disciplina do aluno, alem do respeitonao so ao grupo, como tambem aos alunos que nao conseguiram ser aprovados na selecaodescrita na subsecao 3.1, foi desenvolvida a Minutagem. Ela e implementada atraves deuma planilha disponibilizada no Google Drive onde o proprio aluno informa a hora queele chegou na aula. O intuito e gerar um ambiente confortavel, de confianca mutua, quemotive os alunos a participar ativamente das aulas alem de trabalhar aspectos culturais daagilidade como responsabilidade, confianca na equipe e respeito ao proximo.

No dia da aula, os professores abrem a planilha de minutagem as 07:45, quinzeminutos antes do horario de inıcio. Ela permanece aberta para edicao ate o final de cadaaula. Durante todo esse tempo, cada aluno deve acessar a planilha e informar o horario

Figura 3. Percentual de presenca da turma em minutos no dia-a-dia, comparadocom a presenca de um dos professores. A amostra zerada reflete um dia que oprofessor esteve ausente.

que ele chegou. Em algumas aulas, o grafico de minutagem coletivo e exposto (Figura3) com o objetivo de fazer com que os alunos percebam o quanto eles estao aproveitandoo tempo de aula, alem de estimular o compromisso com o horario e evitar a perda depraticas e conteudos importantes.

3.7. Criterios de Avaliacao

Essa disciplina nao tem prova e os professores procuraram criar criterios de avaliacaocompatıveis com os valores e princıpios ageis. O peso que cada criterio varia de perıodopara perıodo, pois sao decididos pelos alunos em conjunto com os professores no final doperıodo.

O primeiro criterio, como ja visto na subsecao 3.6, e a Minutagem. O segundocriterio e a nota pre-Sabadagil. Essa e nota e atribuıda para cada grupo e e dada pelosprofessores em funcao do quao bem os alunos escolhem as User Stories que irao comporo MVP. Todos os projetos comecam com nota dez mas perdem um ponto para cada UserStory que o professor remover do MVP por acreditar nao e essencial para avaliar a ideia. Aterceira nota e dada tambem para cada grupo e representa o quanto os alunos conseguiramaplicar os conceitos dos Metodos Ageis no Sabadagil para a construcao do MVP. A quartanota e dada para evolucao da aplicacao dos Metodos apos a disponibilizacao do produtoem producao (funcionamento, coleta de metricas, adaptacoes, etc).

Os professores aplicam a melhoria contınua em todos os momentos da disciplina eao longo dos varios anos que ela e realizada, portanto os criterios de avaliacao dos alunostambem sao aprimorados continuamente. Ate 2012, os professores davam uma nota departicipacao para os alunos. A partir de 2013, baseado na experiencia do Laboratoriode XP da USP [Goldman et al. 2004] e buscando desenvolver aspectos culturais comoresponsabilidade, etica e auto-conhecimento, a nota de participacao foi descontinuada eforam criadas a nota de Auto-Avaliacao que o aluno concede para ele mesmo avaliandoo quanto ele acha que seu conhecimento sobre Metodos Ageis evoluiu desde o inıciodo perıodo ate o final, e a Avaliacao 360o que o aluno recebe em funcao do quanto oscompanheiros de grupo acreditam que ele ajudou o conjunto a se desenvolver.

4. ResultadoDurante esses quatro anos foram formadas cinco turmas e quinze grupos. Todos os gru-pos conseguiram desenvolver o MVP dos seus softwares. Como exemplos de produtogerado, podem ser citados: a) Em 2012, um dos grupos desenvolveu o aplicativo movelNice Gesture que tinha como objetivo iniciar aplicativos por gestos na Lock Screen doscelulares. b) o Guia Fundao, desenvolvido por um dos grupos de 2013, tem o objetivo deauxiliar as pessoas que frequentam o enorme Campus da UFRJ a encontrar servicos comofarmacias, bancos, fotocopias, salas, etc. Ele esta disponıvel na Google Play. c) Em 2014,o aplicativo Caronas foi desenvolvido com o principal objetivo de fazer com que pessoasoferecam e recebam caronas dos seus amigos e/ou dos amigos dos amigos do Facebook.

Para buscar evidencias se esse modelo e de fato capaz de gerar aprendizado parao aluno e melhoria contınua para a disciplina, foi desenvolvida uma dinamica em que osalunos avaliam itens de aprendizado (praticas ageis abordadas em aula) que tiveram du-rante o perıodo. Essa dinamica ocorre no final do Sabadagil e funciona da seguinte forma.Individualmente, os alunos listam todos os itens de aprendizado que eles lembram ter tido

durante o perıodo. Depois eles devem colocar o item de aprendizado em um quadro deauto-avaliacao que tem escalas de gradacao de aprendizado que vao de Bom (compre-endo e sou capaz de aplicar), passando por Medio (compreendo, porem preciso de maisinformacao para aplicar a pratica) e terminando em Ruim (pouco compreendido). Comisso e possıvel verificar quais temas os alunos estao com maior dificuldade de compre-ensao e quais aqueles nao sao sequer lembrados pelos alunos. Na dinamica dos alunosda turma de 2014, os dezenove alunos identificaram 92 itens de aprendizado, sendo que51 eles avaliaram como tendo adquirido um bom conhecimento a respeito, 30 com co-nhecimento Medio sobre o item e 11 como uma compreensao Ruim do item. Olhandoo conjunto de informacoes e possıvel perceber que todos os temas abordados em sala deaula foram lembrados por pelo menos um aluno. Tambem e percebido que, em geral, ositens menos lembrados pelos alunos sao aqueles que tambem sao colocados na escala deauto-avaliacao mais proximos a marca Ruim indicando que foram pouco compreendidos.

O percentual de aprovacao de alunos e bastante elevado. Em cinco turmas, apenasum aluno foi reprovado. Alem disso, durante todo o perıodo e construıdo um ambientede confianca e colaboracao em que os alunos sao sempre convidados a expor suas ideias,no final do perıodo os professores perguntam para todos o que eles acharam da disciplina.Com isso eles conseguem obter a avaliacao diretamente daqueles que sao os maioresinteressados na materia. Em 2011, um aluno escreveu:“Eu gostei do ’aulao’ de Sabado,escolha democratica dos temas, boa divisao entre aulas teoricas e praticas, Dojos, PlanilhaA-HA moments. Eu nao gostei do horario das aulas, nao ter tido pelo menos mais umaaula no sabado perto da metade do desenvolvimento dos trabalhos e nem pre-avaliacao nomeio do curso para estimular o desenvolvimento grupos...”. No mesmo ano, outro alunodisse: ”Gostei das aulas teoricas misturadas com pratica e dos Dojos. Nao gostei quedepois da metade do curso tivemos poucas aulas teoricas”. Um aluno de 2012 escreveuque “...gostaria de mais dinamicas e que o horario da aula fosse alterado”. Em todos osanos, muitos alunos mencionam que gostaria de mais um Sabadagil durante o semestre.Em 2014, um dos relatos que mais chama a atencao foi um aluno que escreve “Foi amelhor materia que tive no curso todo”.

5. Conclusao

Neste artigo descrevemos a experiencia utilizada pelos professores de Metodos Ageisdo Departamento de Ciencias da Computacao da UFRJ. Como eles utilizam valores eprincıpios dos Metodos Ageis durante diversas etapas da disciplina. Mostramos comoesses princıpios e valores podem ser instanciados em outros contextos alem do desenvol-vimento de software e que eles ajudam a construir um ambiente de aprendizado eficaz,empolgante e estimulante para todos os envolvidos.

Durante os quatro ultimos esse retorno dos alunos tem sido bastante positivo eas ponderacoes que eles fazem servem de insumo para melhorar ainda mais as proximasturmas. Conversando com os ex-alunos, percebemos que esse modelo de ensino alem deser muito bem avaliado por eles, tem sido bastante proveitoso na vida profissional. Algunsdeles utilizam Metodos Ageis formalmente em suas atividades e desses ha ainda aquelesque apresentam seus trabalhos em eventos como Agile In Rio e Scrum Gathering.

Futuramente, procuraremos detalhar as diversas praticas descritas na secao 3.Tambem colheremos informacoes mais detalhadas das proximas turmas para relatar a

evolucao da disciplina.

6. AgradecimentoAgradecemos Alfredo Goldman e Viviane Santos pela imensa ajuda e atencao que nosderam durante o programa de Shepherding do WBMA de 2014.

Referencias[Abbas et al. 2008] Abbas, N., Gravell, A. M., and Wills, G. B. (2008). Historical roots of

agile methods: where did “agile thinking” come from? In Agile Processes in SoftwareEngineering and Extreme Programming, pages 94–103. Springer.

[Adkins 2010] Adkins, L. (2010). Coaching Agile Teams: A Companion for ScrumMasters,Agile Coaches, and Project Managers in Transition. Addison-Wesley Signature Series(Cohn). Pearson Education.

[Anderson 2010] Anderson, D. (2010). Kanban. Blue Hole Press.

[Anderson et al. 2011] Anderson, D., Concas, G., Lunesu, M. I., and Marchesi, M. (2011).Studying lean-kanban approach using software process simulation. In Agile Processesin Software Engineering and Extreme Programming, pages 12–26. Springer.

[Armitage et al. 2008] Armitage, D., Marschke, M., and Plummer, R. (2008). Adaptive co-management and the paradox of learning. Global Environmental Change, 18(1):86 –98.

[Beck 2000] Beck, K. (2000). Extreme Programming Explained: Embrace Change. AnAlan R. Apt Book Series. Addison-Wesley.

[Beck 2003] Beck, K. (2003). Test-driven Development: By Example. Kent Beck signaturebook. Addison-Wesley.

[Beck et al. 2001] Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham,W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B.,Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. (2001). Mani-festo for agile software development. http://www.agilemanifesto.org/.

[Bolton 1999] Bolton, M. K. (1999). The role of coaching in student teams: A “just-in-time”approach to learning. Journal of Management Education, 23(3):233–250.

[Cohn 2004] Cohn, M. (2004). User Stories Applied: For Agile Software Development.Addison-Wesley signature series. Addison-Wesley.

[Corbucci et al. 2011] Corbucci, H., Goldman, A., Katayama, E., Kon, F., Melo, C., andSantos, V. (2011). Genesis and evolution of the agile movement in brazil – perspectivefrom academia and industry. In Software Engineering (SBES), 2011 25th BrazilianSymposium on, pages 98–107.

[da Silva 2007] da Silva, A. F. (2007). Reflexoes sobre o ensino de metodologias ageis naacademia, na industria e no governo. PhD thesis, Universidadede Sao Paulo (USP).

[de O. Melo et al. 2013] de O. Melo, C., Santos, V., Katayama, E., Corbucci, H., Priklad-nicki, R., Goldman, A., and Kon, F. (2013). The evolution of agile software develop-ment in brazil. Journal of the Brazilian Computer Society, 19(4):523–552.

[Delgado et al. 2012] Delgado, C. A. D. M., de Toledo, R., and Braganholo, V. (2012). Usode dojos no ensino superior de computacao. In Anais do WEI XX Workshop sobreEducacao em Computacao.

[Fernandes and Sousa 2010] Fernandes, J. and Sousa, S. (2010). Playscrum - a card gameto learn the scrum agile method. In Games and Virtual Worlds for Serious Applications(VS-GAMES), 2010 Second International Conference on, pages 52–59.

[Goldman et al. 2004] Goldman, A., Kon, F., Silva, P. J. S., and Yoder, J. W. (2004). BeingExtreme in the Classroom: experiences Teaching XP. Journal of the Brazilian Com-puter Society, 10:5 – 21.

[Hohmann 2006] Hohmann, L. (2006). Innovation Games: Creating Breakthrough Pro-ducts Through Collaborative Play. Pearson Education.

[Keen and Mahanty 2006] Keen, M. and Mahanty, S. (2006). Learning in sustainable na-tural resource management: Challenges and opportunities in the pacific. Society andNatural Resources, 19(6):497–513.

[Mezirow 2000] Mezirow, J. (2000). Learning to think like an adult. Learning as transfor-mation: Critical perspectives on a theory in progress, pages 3–33.

[Moore 2002] Moore, G. (2002). Crossing the Chasm: Marketing and Selling DisruptiveProducts to Mainstream Customers. Collins Business Essentials. HarperCollins.

[Ries 2011] Ries, E. (2011). The Lean Startup: How Today’s Entrepreneurs Use ContinuousInnovation to Create Radically Successful Businesses. Crown Publishing Group.

[Santos et al. 2012] Santos, V. A., Goldman, A., and Santos, C. D. (2012). Uncoveringsteady advances for an extreme programming course. CLEI Electronic Journal, 15(1).

[Sutherland and Schwaber 2011] Sutherland, J. and Schwaber, K. (2011). The DefinitiveGuide to Scrum: The Rules of the Game.

[Teles 2007] Teles, V. (2007). Improve it: Agile software development.

[Teles and de Oliveira 2003] Teles, V. M. and de Oliveira, C. E. T. (2003). Reviewing thecurriculum of software engineering undergraduate courses to incorporate communica-tion and interpersonal skills teaching. In Software Engineering Education and Trai-ning, 2003.(CSEE&T 2003). Proceedings. 16th Conference on, pages 158–165. IEEE.

[Teles 2005] Teles, V. M. a. (2005). Um estudo de caso da adocao das praticas e valoresdo eXtreme Programming. PhD thesis, Universidade Federal do Rio de Janeiro.

[The Startup Machine 2014] The Startup Machine (2014). Validation board.

[Version One 2013] Version One (2013). 8th Annual State of Agile Survey. Technical re-port, Version One, Alpharetta, GA, USA.

[von Wangenheim et al. 2013] von Wangenheim, C. G., Savi, R., and Borgatto, A. F. (2013).Scrumia - an educational game for teaching scrum. Journal of Systems and Software,86(10):2675 – 2687.

[Wood 2003] Wood, D. F. (2003). Problem based learning. British Medical Journal,326(7384):328–330.