Proyectos finales y gestion de tiempo

From The Joel on Software Translation Project

Jump to: navigation, search

Por Joel Spolsky
Lunes 26 de octubre de 2009
Artículo original: Capstone projects and time management
Traducido originalmente por: User:aminm


Me asombra lo fácil que es navegar por la carrera de ciencias de la computación de una universidad de primera sin ni siquiera aprender las herramientas básicas de desarrollo de software, sin haber trabajado en equipo, y sin haber cursado una materia para el cual no recibes un cero por colaborar. Muchos departamentos de CC (ciencias de la computación) están atrapadas en los años 80, enseñando con el mismo plan de estudios que hoy ya está completamente divorciado de la realidad del desarrollo de software moderno.

¿Dónde es que los alumnos deben aprender sobre control de versiones, gestión de defectos, trabajo en equipo, estimación de tiempo, depuración de errores, testeo de facilidad de uso, y documentación? ¿Dónde aprenden a escribir un programa más largo que 20 líneas?

Muchas universidades han logrado auto-convencerse que si el plan de estudios es más irrelevante al mundo real, entonces la universidad es más élite. Es la forma que funciona con artes liberales. Dejemos que los institutos técnicos o vocacionales, las universidades nuevas, y facultades con menor cantidad de fondos y muchos "puntos en el compás (ej: Universidad del Norte del Sureste de Florida) que produzcan programadores. Las universidades más élites del mundo quieren enseñar álgebra lineal y teorías de cómputo y programación Haskell, y los departamentos de CC luchadoras tratando de elevar su estándar lo hacen eliminando cualquier cosa práctica de su plan de estudios a favor de más teoría.

Ahora, no me mal entiendan, esto no es necesariamente algo malo. Por lo menos están reemplazando a Java por Scheme, tal vez únicamente porque "eso es lo que hace MIT". (¡Muy tarde!) Y están enseñando a los estudiantes a pensar de cierta forma. Y dado cuánto el profesor CC promedio sabe sobre ingeniería de software en el mundo real, creería que preferería que alumnos aprendan eso durante una pasantía en Fog Creek.

Greg Wilson, un profesor adjunto de la Universidad de Toronto, dió una charla en la conferencia StackOverflow DevDay en Toronto, que fue entretenida, informativa, y en general un gran éxito. Estuvimos conversando, y el me contó sobre su última innovación, UCOSP, que significa "Todos los Nombres Buenos ya han sido Utilizados".

Es un consorcio de 15 universidades, principalmente en Canadá, que organizan proyectos finales en conjunto para alumnos de último año. Están organizando equipos de media docena de alumnos de distintas universidades para colaborar en un proyecto open source, y reciben créditos y una calificación. Tan pronto escuché del programa me ofrecí para auspiciar a un equipo para hacer una contribución a Mercurial. Auspiciar un equipo consiste de ofrecer pagar el viaje de todos los alumnos a Toronto para que ser organicen, y proveer un programador para ser un mentor del equipo.

Ojeando el blog de UCOSP, me acorde de por qué proyectos de alumnos, por más meritorios que sean, frecuentemente no son capaces de generar algo útil. "Uno de los objetivos de esta materia es darte una oportunidad de descubrir qué tal es fijar tus propias metas y luego lograrlas," escribe Greg. "El resultado neto es bastante claro en este momento: en muchos casos, los estudiantes hacen menos en una semana para este curso que lo que harían en un curso más estructurado que tenga exactamente el mismo contenido".

Alumnos universitarios en su último año tienen aproximadamente 16 años de experiencia en hacer proyectos cortos y dejando todo para el último minuto. Hasta que seas un alumno de último año en la universidad, es muy improbable que alguna vez te hayas topado con una consigna que no pueda hacerse quedándote despierto toda la noche.

La asignatura típica de CC espera que los alumnos escriban la parte "interesante" del código (en el sentido académico de la palabra). El otro 90% del trabajo que se necesita para llevar el código al nivel de "código útil y del mundo real" nunca se espera de alumnos, porque no es "interesante" arreglar defectos y lidiar con condiciones del mundo real, y porque la mayoría de profesores de CC nunca han trabajado en el mundo real y no tienen casi ninguna idea de lo que se necesita para crear software que pueda sobrevivir un encuentro con usuarios.

La gestión de tiempo es generalmente la culpable. En un grupo de cuatro alumnos, si uno o dos de los alumnos son suficientemente emprendedores para intentar empezar su proyecto temprano en el semestre, los otros alumnos probablemente arrastrarán el proyecto al atraso porque tienen proyectos más urgentes de otras clases que tienen que terminarse mañana. Los alumnos emprendedores entonces tendrán que elegir entre empezar primero y hacer más de lo que les corresponde del trabajo, o esperar con el resto hasta que la noche anterior, y adivina cuál de las opciones gana.

Los alumnos tienen exactamente cero experiencia con cronogramas grupales de largo plazo. Por tanto, casi siempre hacen trabajo de baja calidad cuando se les da un proyecto de largo plazo y se les dice que manejen su tiempo ellos mismos.

Si algo productivo se logra de estos proyectos, tendrás que tener fechas tope semanales, y tendrás que reconocer que TODO el trabajo para ese proyecto se hará la noche antes del fecha tope semanal. Parece ser una parte permanente de la condición humana que plazos largos sin hitos de tiempo corto rara vez se cumplen.

Esta tal vez sea una buena oportunidad para usar Scrum. Una vez por semana, el equipo se reúne, en persona o virtualmente, y revisa el trabajo de la semana anterior. Entonces deciden que prestaciones y tareas se van a hacer durante la próxima semana. FogBugz funcionaría bien para hacer el seguimiento para esto: si estas realizando un proyecto final y necesitas acceso a FogBugz, por favor déjanos saberlo y estaremos felices de configurarlo para ti gratis. También podemos configurarte un acceso beta a kiln, nuestra versión hosted de Mercurial, que incluye una prestación para hacer revisiones de código.

He estado culpando a alumnos aquí por su falta de disciplina en lograr proyectos de un semestre entero durante el curso del semestre en vez de dejar todo para el último minuto, pero por su puesto, el problema es endémico entre personas que no son alumnos también. Me he demorado un tiempo en darme cuenta, pero por fin entendí que fechas tope de largo plazo (o no tener ninguna fecha tope) simplemente no funciona con programadores profesionales tampoco: necesitas un cronograma de entregas regulares y frecuentes para ser productivo a largo plazo. La única razón que el mundo real hace esto correctamente donde los equipos de solo alumnos fracasan es porque en el mundo real hay supervisores, que pueden fijar fechas tope, y un grupo de solo alumnos no puede lograr lo mismo.

Personal tools