Do desencontro entre universidade e indústria - parte 2 - o mundo real

Continuando o post de ontem, hoje vou falar sobre outra queixa frequente da indústria de software sobre o ensino de computação nas universidades: o fato dos alunos não adquirirem habilidades que são importantes no "mundo real." Veja as queixas do Joel:

Where are students supposed to learn about version control, bug tracking, working on teams, scheduling, estimating, debugging, usability testing, and documentation? Where do they learn to write a program longer than 20 lines?

Dá pra resumir em uma frase: "os alunos não aprendem a desenvolver sistemas de médio/grande porte."

É claro que não. Só há uma forma de aprender a se trabalhar em uma equipe que faz um sistema de grande porte - trabalhando. Trabalhando durante meses e meses a fio. Se envolvendo com requisitos, projeto, repositórios de controle de versões, rastreamento de bugs, deadlines, milestones e tudo mais. Um professor pode até falar a respeito dessas coisas para introduzir o vocabulário, mas não haverá fixação sem a prática.

E por que não fazer isso na sala de aula? Por que não dedicar o último semestre de um curso de quatro anos inteiramente a um grande projeto realizado por todos os alunos em uma grande equipe? Os professores seriam os clientes e gerentes. Creio que com uns oito professores trabalhando juntos, conseguiríamos tocar uma equipe de 40 desenvolvedores inexperientes. Por que não fazer isso? Não parece uma boa idéia?

Primeiro problema: avaliação individual.

O objetivo de uma universidade não é só ensinar. É também entregar atestados chamados "diplomas" que atestam a quem interessar possa que o indivíduo que o carrega tem certas competências. É por isso que até hoje fazemos provas escritas quando todo mundo está careca de saber que essa é uma das piores formas de se avaliar competências - ainda não encontramos forma melhor que funcione quando temos mais de 5 alunos por professor.

Mesmo que cada um dos oito professores use o tempo que lhes sobra depois de gerenciar a equipe (se é que vai sobrar algum) para avaliar os alunos em algum quesito como qualidade do código, uso do repositório, produtividade, adesão à especificação, etc., etc., continua dificílimo avaliar cada aluno individualmente. As tarefas que cada um fará nunca serão homogêneas ou equivalentes, mas os alunos tem de ser avaliados segundo os mesmos critérios.


Segundo problema: qual projeto?

Coloque-se por um instante no lugar de um dos professores que está planejando esse lindo curso de um semestre. Antes do semestre começar, você e seus colegas tem de resolver as seguintes questões:

1. Especificar detalhadamente um sistema que possa ser desenvolvido por 40 pessoas trabalhando 20 horas por semana durante 4 meses. Não erre suas estimativas nem pra mais, pois os alunos não podem ficar ociosos no final do semestre, nem pra menos, pois os alunos devem ser capazes de concluir o projeto para ficarem motivados.
2. Preparar um laboratório com o ambiente de desenvolvimento, instalando e configurando todas ferramentas de controle de versões, acompanhamento de bugs, IDEs de desenvolvimento e tudo mais.
3. Elaborar cronogramas detalhados com entregas bem definidas distribuidas por todo o semestre.
4. Definir os critérios de avaliação e dividir as tarefas de gerência entre os professores participantes.

Lembre-se que no semestre seguinte você terá de fazer tudo de novo, pois não quer que os alunos copiem o trabalho dos alunos dos semestres anteriores.

Terceiro problema: caos

Um projeto de 40 pessoas é caótico, não adianta querer que seja diferente. É preciso lidar com problemas pessoais, atrasos de umas equipes que prejudicam outras, problemas no ambiente de desenvolvimento, conflitos interpessoais e dezenas de outras coisas que acontecem no mundo real. Só que um curso universitário precisa de ordem e previsibilidade, caso contrário nada funciona.

Imagine os professores se reunindo para avaliar os alunos ao final do projeto:

Prof. Feliz: "Ufa! Não saiu nada como planejamos mas foi ótimo porque os alunos entenderam como funciona o mundo real. Mas que nota vamos dar pro Zé? Ele não fez nada."

Prof. Chato: "Ele não fez nada porque o João atrasou a entrega e ele teve de esperar. Não podemos penalizá-lo por isso."

Prof. Feliz: "Então que nota vamos dar pro João por ter atrasado?"

Prof. Chato: "Tem de ser altíssima apesar do atraso, só não atrasou mais porque o João carregou a equipe dele nas costas depois que a Vó da Elaine ficou doente. Ele é o melhor de todos."

Prof. Feliz: "Mas ninguém gosta dele! Ele quer fazer tudo e tolhe os colegas. Temos de levar isso em conta."

Sentiram? São nuances demais para se transformar em uma nota objetiva entre 0 e 100.

Até daria pra se fazer algo desse tipo em uma universidade, não é impossível. Só que nenhuma universidade que eu conheço tem os recursos necessários para se implementar um projeto desses com sucesso, e nenhum professor recebe o suficiente pra passar pela dor de cabeça que isso vai dar.

Tem ainda outro argumento que eu não usei mas que foi usado em um painel de discussões que assisti a muuuitos anos atrás, em que meu prof. José Nagib respondeu da seguinte forma a um comentário de um representante da indústria, semelhante ao comentário do Joel:

"Nós não sabemos ensinar isso que vocês querem. Vocês é quem tem de ensinar."

Acho que é um bom jeito de encerrar o tópico de hoje.

Amanhã falarei sobre a capacitação dos professores.