Trabajos finales de carrera: como plantearlos

Muchas carreras de informática tienen como parte del plan de estudios la realización un trabajo final. En FIUBA se le llama Trabajo Profesional, mientras que en UNQ se le llama Trabajo de Inserción Profesional.
En general este trabajo final (por usar un nombre genérico) consiste en realizar lo que podria ser un trabajo de campo acorde al perfil del futuro egresado. He conocido muchos casos en los que la realización de este trabajo se estira en el tiempo mucho más de lo que debiera. Es por ello que he decido escribir este artículo para compartir algunas recomendaciones.
El trabajo final es un proyecto y como todo proyecto tiene 3 variables:
  • Esfuerzo: cantidad de horas que vas a trabajar
  • Calendario: cuanto tiempo calendario lleva desde el comienzo hasta que se termina
  • Alcance: el tamaño de lo que vas a hacer
En todo proyecto, el cliente fija una variable, el equipo de desarrollo fija otra y finalmente la tercera se va regulando. En ocasiones la gente quiere fijar las 3 variables y las cosas terminan generalmente mal.
Para el caso del trabajo final tenemos:
  • Esfuerzo: ya viene preestablecido por la Universidad, para el caso de UNQ/TPI son entre 100 y 180 horas.
  • Calendario: para el caso de UNQ/TPI, suena razonable un calendario de entre 4 y 6 meses.
  • Alcance: aquí está la clave, si fijas el alcance, diciendo: Quiero hacer un sistema X que tenga las funcionalidades a,b,c,,etc. sonaste, porque no sabes a ciencia cierta cuanto esfuerzo va a requerir y mucho peor si es un tema que no conoces o una tecnologia nueva. Entonces para mi la clave es definir el trabajo final de manera que el alcance sea variable. Esto requiere una atención especial al manejo de prioridades, pues aunque el alcance sea variable, uno debe asegurarse de hacer algo que entregue valor. Esta es una forma de trabajo muy utilizada en los proyectos con métodos ágiles y en general la cuestión camina bastante bien. Yo ya he dirigido trabajos en UBA usando esta estrategia y doy fe que camina.
Hagamos ahora algunas cuentas para bajar a tierra. Supongamos que yo quiero hacer mi trabajo en 6 meses, entonces, tendría:
180 horas de esfuerzo (máximo determinado por el reglamento) / 6 meses = 30 horas al mes
Lo cual si lo paso a semanas, estamos hablando de trabajar 7,5 horas por semana ¿bastante razonable no?
Algunas aclaraciones importantes:
  • Ojo #1: estas horas son horas tipo Pomodoro, nada de telefonito, mensajitos, facebook, etc, etc. Son horas que me siento a laburar y laburo. (quien cursaron Ing. de soft saben a qué me refiero)
  • Ojo #2: no todos los temas permiten definir un proyecto de alcance variable. Cuando el tema es investigar XXX, puede resultar más dificil. Pero si el tema es construir un software que haga ZZZ, entonces es muuuuyyyy factible poder trabajar con alcance variable.
  • Ojo #3: encarar un proyecto de esta forma, puede resultar un poco más demandante, dado que para cumplir con la fecha y esfuerzo planteado, es necesario tener un ritmo de trabajo constante, lo cual también requiere un involucramiento docente constante.
Estos dos mis dos centavos de aporte al tema.

Impresiones del Primer Workshop del Proyecto Uqbar

El proyecto Uqbar es una iniciativa que agrupa a investigadores, profesionales y docentes de diversas instituciones Argentinas relacionadas a la informática. El sábado pasado se realizó el primer Workshop de Uqbar en las instalaciones de la Universidad Nacional de San Martín.

Debido a otros compromisos personales no pude participar del evento completo, pero las sesiones que ví me resultaron muy interesantes.

Yo facilité una sesión titulada «Testing: el gran ausente» en la que expuse mi visión sobre relevancia que se da a este tema tanto en la industria como en la academia. Fue muy gratificante ver que gran parte de la audiencia compartía mi visión.

No usé slides durante me sesión sino que directamente escribí algunas notas en la pizarra. Comparto a continuación algunos links a artículos que escribí que exponen los puntos que traté en la sesión:

Trabajos finales de carrera: mi enfoque de dirección

Como docente universitario en ocasiones me han ofrecido dirigir  o co-dirigir trabajos finales de carrera. El hecho de aceptar o no siempre está sujeto a dos cuestiones: que el tema del trabajo me resulte interesante y que los alumnos se comprometan a trabajar de acuerdo a ciertas normas entre las cuales destaco:

  1. El trabajo debe desarrollarse de forma iterativa e incremental
  2. El desarrollo debe hacerse utilizando integración continua
  3. El producto debe contar con pruebas automatizadas tanto unitarias como funcionales que provean una cobertura superior al 80%
  4. El código debe respetar los estándares de desarrollo de la tecnología utilizada
  5. El código resultante debe ser open source.
  6. A lo largo de todo el proyecto haremos reuniones (presenciales o virtuales) de seguimiento del proyecto

Estas cuestiones tienen que ver con asegurar la calidad del trabajo resultante, una cuestión que a mi parecer es una de las responsabilidades más importantes del director. Sin duda puede que haya otras técnicas/estrategias para asegurar la calidad del trabajo resultante, pero las aquí mencionadas son las que yo personalmente considero más efectivas.

Al mismo tiempo, puede que el tema del trabajo no justifique el uso de las técnicas aquí mencionadas, pero ocurre que justamente, los temas que me suelen interesar son los que sí requieren/justifican las cuestiones aquí mencionadas.

Obviamente que cada trabajo requiere una revisión de esto items, pues puede que en el contexto específico de un trabajo algunos de los ítems mencionados no tenga sentido o que al contrario, sea necesario incluir algunos ítems adicionales.

Testing de software: mi percepción en la industria y la academia

Este es un tema que vengo trabajando desde hace tiempo. Como parte de mi carrera fue muy poco lo que ví al respecto. Vi algo de prueba unitaria en la materia de objetos. Tuve una materia de calidad (Calidad en desarrollo de software) que me resultó muy interesante, pero que estaba más enfocada en cuestiones de proceso, por lo cual fue muy poco lo que vimos de pruebas.

Más allá de eso, mi actividad profesional me llevó a ir metiéndome en el tema. Por un lado, el trabajar con prácticas ágiles de ingeniería me llevó a meterme en temas de automatización de pruebas funcionales/de regresión. Por otro lado, el trabajar como consultor revisando/diagnosticando aplicaciones, me llevo a interiorizarme en cuestiones de pruebas de stress. Luego, inquietudes personales me llevaron a reforzar un poco más la parte teórica. Finalmente, este último año que he estado trabajando en cuestiones de continuous delivery profundicé en cuestiones de automatización de prueba con distintas herramientas.

Más allá de las cuestiones académicas, tengo la percepción que parte de la industria no toma seriamente el testing. He visto muchas empresas que ven a las personas que hacen testing como «ciudadanos de segunda clase». En esos contextos, las personas que hacen testing, son los que menos cobran, los que «menos saben» y los que menos requisitos tienen para acceder al puesto. Esas mismas empresas son las que suelen hacer casi todo su testing en forma manual.

En cierto modo esto plantea el dilema del huevo o la gallina: «La academia no presta atención al testing porque la industria no lo considera relevante o la industria no pone foco en testing avanzado porque la academia no prepara profesionales en testing».

Luego de algunas charlas de intercambio mantenidas durante Agiles 2013 me decidí a hacer algo al respecto de la situación aquí descripta. Por un lado, empecé a trabajar en conjunto con mis colegas de Kleer (más particularmente con JuanG) para dictar una serie de Talleres de Pruebas automatizadas. Por otro lado, en el contexto académico, tengo la intención de dictar una materia de Testing junto con PabloT en UNQ.

Algo de todo esto voy a estar presentando el sábado próximo en el contexto de mi sesión en el Workshop 2013 de Uqbar.

Definición de hecho y entrega limpia

En el contexto de los métodos ágiles suele hacerse mucho énfasis en la definición de hecho (definition of done). Esta definición puede variar dependiendo del contexto.

Personalmente desde que «vi la luz», mi definición de hecho consistió en:

  • El cumplimientos de condiciones de aceptación de la funcionalidad
  • El cumplimiento de las convenciones de codificación
  • El visto bueno por parte del Product Owner

Obviamente en cada nuevo proyecto procuro revalidar esta definición tanto con mi equipo como con el cliente.

Sin embargo, hace unos años empecé a ir por más. Ese «ir por más» tiene que ver con no sólo cumplir la definición de hecho, sino también  con lograr una entrega limpia. La idea es simple aunque puede no resultar fácil de explicar. Para intentar explicarlo voy a describir un contra ejemplo que me tocó vivir recientemente.

Resulta que un cliente necesitaba de una herramienta para resolver determinadas cuestiones de su deber cotidiano, pero debido a ciertas restricciones de agenda no podía involucrarse de lleno en el desarrollo de dicha herramienta. Como yo venía trabajando con él desde hacía un par de meses y conocía en profundidad la problemática a resolver, acordamos que yo ocuparía el rol de product owner. La herramienta fue construida en un par de semanas por un equipo de su organización cumpliendo con todos los «chiches»  (pruebas unitarias, de aceptación, integración continua, alta cobertura, etc, etc).
Luego de 2 semanas de finalizada la construcción de la aplicación, mi cliente se dispuso a ponerla en producción para empezar a utilizarla y entonces….¡chan! El procedimiento de instalación no estaba claro al igual que algunos requerimientos de runtime, lo cual llevó a varias horas de troubleshooting hasta que finalmente la aplicación quedó operativa. Esto es un ejemplo de entrega no-limpia.

Es muy posible que la situación pudiera haberse evitado si la aplicación se hubiera puesto en producción al final de la primera iteración, pero diversas cuestiones llevaron a que eso no fuera posible. Pero si miramos la situación a la luz de la filosofia de entrega limpia, esta entrega no fue limpia. Una entrega limpia habría incluido los pasos detallados para puesta en marcha de la aplicación  y no sólo eso, sino que dichos pasos habrían sido probados para asegurar que fuera correctos.

La entrega limpia tiene que ver con dar ese paso extra que finalmente termina haciendo la diferencia y deleitando al cliente.

Algunas ideas para Agiles 2014

En el open space de Agiles 2013, Alan propuso hacer un Agiles 2014 radicalmente distinto. Entre las particularidades de la propuesta incluyó:

– Que la conferencia sea 100% Open Space
– Que no haya keynotes speakers
– Que haya un único nivel de sponsors

Personalmente me gusta esta propuesta y es en parte por ello que esto escribiendo este artículo.

El punto que más me gusta es el primero, pero el segundo me parece más importante.

Tradicionalmente desde la comunidad siempre hemos hecho un imporante esfuerzo en traer keynotes speakers extranjeros, llegando en un punto a menospreciar a los referentes locales. De hecho en las primeras conferencias no había keynotes speakers locales, lo cual puede en cierto modo justificarse por el hecho de que la comunidad estaba aún en formación. Personalmente creo que esa situación inicial ha cambiado mucho y creo que quedó en evidencia en Agiles 2013 donde el keynote speaker local (Gustavo Quiroz) fue incluso mejor que los keynotes speakers extranjeros.

No es que pretenda no tener keynotes speakers extranjeros, sino que me gustaría que en caso de tenerlos, los mismos sean de primer nivel. A mi entender los keynotes speakers que hemos tenido en los últimos años, aunque muy buenos, dudo mucho que puedan ser keynotes speakers de una conferencia mundial de Agile.

 

Agiles 2013, día #2

La jornada comenzó con el keynote de Janet Gregory quien habló sobre «el cambio». Me resultó bastante abstracto y algunos de los ejemplos que utilizó a mi entender no aplicaban a la realidad de latinoamérica.

A continuación asistí a la mejor sesión del día: Integrating Agile UX into your project. La misma estuvo a cargo de Rafael Petri y trató sobre diversas cuestiones de UX. Creo que me gustó tanto por tratarse de temas que siempre me han interesado pero en los que nunca he profundizado.

Luego seguí con la sesión Continuous Delivery with Mobile. En lo que hace específicamente a mobile la sesión aportó muy poco, pero me resultó muy interesante la forma en que fue explicado CD haciendo una analogía con la producción/consumo de café.

Ya el cierre de la mañana fue con la sesión de Mary Poppendieck, la cual estuvo dedicada al Lean Mindset. La sesión estuvo centrada en la presentación de casos e incluyó varias cuestiones del próximo libro de Mary.

Por la tarde, asistí a la sesión Current Testing Challenges de Janet Gregory, la cual me resultó muy interesante y me dejó varias cosas para pensar (próximamente post aparte sobre algunas cuestiones de testing que me surgieron de esta sesión).

La siguiente sesión fue la de Edson Chávez, un artesano de software que habló sobre su oficio. Si bien yo ya estaba familiarizado con el movimiento de software craftsmanship, la sesión me resultó muy entretenida por el estilo y los ejemplos utilizados por Edson.

Ya en el último tramo del día asistí a la sesión de Jorge Gamba sobre BDD. Estuvo bien, pero personalmente no me aportó nada nuevo.

La última sesión de mi día fue la de Angel Nuñez Salazar, quien habló sobre deuda técnica y presentó un modelo interesante para cuantificar su impacto económico. La sesión me gustó y me pareció muy innovadora pues nunca había visto nada de ese tipo.

El día terminó con una «sesión extraordinaria» en la que se debatieron temas de la comunidad, puntualmente se habló sobre el mecanismo de toma de decisiones de la comunidad, otro tema que también merece un post aparte.

Agiles 2013, día #1

El día comenzó con el keynote de Jurgen Appelo. Me gustó mucho, el mismo se tituló «Champs Frog». Podríamos decir que trató sobre un modelo para facilitar el cambio organizacional.

Luego asistí a una sesión titulada «Team of Leaders», la misma trató sobre liderazgo en equipos ágiles y básicamente fue un relato de la experiencia de los oradores. Estuvo bien, pero personalmente no me sumó nada nuevo.

La siguiente sesión que asistí fue de índole técnica y trató sobre testing de aplicaciones Andriod. Me resultó muy interesante y me llevé varias cuestiones para reveer. El orador fue bien claro y concreto.

Ya cerrando la mañana asistí a una sesión que prometía mucho «Diviértete en forma segura con Javascript», pero quedó sólo en la promesa, pues a las 10 minutos me retiré porque detecté que eran todos temas que ya conocía por demás.

Luego de compartir el almuerzo con Andy y Sole Pinter, asistí a la sesión de Jurgen Appelo, pero llegué bastante tarde ya que almuerzo se alargó más de lo debido, ¡ups!

La segunda sesión de la tarde fue de la JuanG que habló sobre planificación de la prueba. Como desde hace un tiempo, Juan no usó slides, sino un poster para facilitar la sesión, la estrategia presentada me resultó interesante.

Ya sobre las 5 de la tarde, estuve en la sesión de Gustavo Quiróz que presentó una técnica para retrospectivas enfocadas en propósitos. Estuvo bien.

Finalmente terminé el día con mi sesión sobre Continuous Delivery, pero eso será tema de otro post.

agiles_2013_dia_1

Checklist de viaje

Hace ya un tiempo que me armé un checklist de viaje con la lista de cuestiones/tareas que  a mi entender uno debiera verificar antes de todo viaje.

Bolso de mano

  • Documentación
    • Pasaporte (en caso de viaje al exterior)
    • Visa (en caso que el pais destino lo requiera)
    • Ticket de viaje impreso
  • Libro / revista para leer
  • Lapicera
  • Block de notas
  • Cámara de fotos
  • Cargador de la cámara de fotos
  • Algo de plata en moneda internacional (si vamos al exterior)
  • Kit de mate
    • Termo
    • Yerba
    • Mate
    • Bombilla
    • Repasador
    • Cuchara

Valija

  • Ropa
    • Ropa interior
    • Pantalón y remeras varias
    • Short de baño
    • Abrigo impermeable
    • Calzado
  • Kit de aseo
    • Cepillo de dientes
    • Pasta dental
    • Afeitadora
    • Crema de afeitar
    • Loción para después de afeitar
    • Desodorante
    • Peine
    • Talco
    • Alicate
  • Mini kit de costura
    • Aguja
    • Hilo de coser
  • Medicación
    • Toda medicación que tomes en forma crónica
    • Ibuprofeno
    • Refrianex
    • Reliverán
    • Protector solar

Espero les resulte útil.

La parte más dura de la vuelta a C# y Java

La semana pasada volví a C# y Java. Por un lado venia trabajando en un proyecto en Groovy y por ciertas cuestiones de contexto me ví obligado a hacer algunas cosas en Java. Por otro lado empecé un nuevo proyecto en C#.

En ambos casos hubo dos cuestiones que me «dolieron mucho».

  1. Los entornos de desarrollo: acostumbrado a trabajar con Ruby y Smalltalk, usando Sublime Text, Pharo y vi, me resultó durísimo tener que volver a usar Visual Studio y Eclipse.
  2. La falta de un entorno interactivo donde poder jugar con mis objetos, lo que seria irb en Ruby  o el workspace Smalltalk.

Continuará….