Autor: NicoPaez

Comienzo de nuevo proyecto, llamémosle T

En estos días estoy por comenzar un nuevo proyecto, llamémosle T. Se trata de un trabajo de inserción profesional que voy a co-dirigir con Fidel. El trabajo será desarrollado por dos alumnos de la carrera y el objetivo es construir un sistema de gestión para la sala de guardia de un hospital. El proyecto surgió a partir de una necesidad detectada por Luis, un médico, jefe de guardia de un hospital del conurbano.

Como suelo recomendar para todos los trabajo finales de carrera, la idea es gestionar el proyecto como de alcance variable, lo cual requiere una trabajo muy cercano con el product owner para asegurar una correcta priorización de funcionalidades y un rápido feedback a medida que estas se van completando.

Continuará…

 

 

Resultados del Taller de lntegración Continua

El jueves pasado hicimos en Kleer el taller de integración contínua. No tuvo tanta práctica como yo esperaba, pues hubo muchas consultas, pero creo que estuvo muy bien. Cubrimos todos los puntos del programa y atendimos a todas consultas de los asistentes.

Algunas variantes a considerar para futuras ediciones:

  • Enfocar el taller sólamente en Jenkins
  • Enfocar el taller en una única tecnología (Java , .Net, etc)
  • Hacer el taller de día completo o de dos medios días para poder hacer más práctica

Les dejo algunos frases de las encuestas de la evaluación completadas por los asistentes:

  • “Excelente las explicaciones y conocimientos expuestos”
  • “Muy bueno, si bien conocía algunas de las herramientas, vi un poco más en detalle todo el potencial de uso que tienen”
  • “Nada para agregar, el taller fue genial..”
  • “Excelente Didáctica y cobertura del tema”

Impresiones de la RubyConfAR 2013

La semana pasada participé por primera vez de la RubyConf. Los comentarios que recibí de algunos colegas sobre las ediciones anteriores me entusiasmaron mucho y por ello decidí anotarme.

Para quienes nunca han asistido comienzo describiendo el formato de la conferencia. La conferencia en sí son 2 días a los que se le suma un preludio denominado «Ruby Fun Day» en el que se dictan charlas/talleres introductorios a Ruby. Lamentablemente no pude asistir al fun day, pero de todas formas no creo que me hubiera aportado mucho, ya que tengo bastante experiencia trabajando con Ruby. Adicionalmente también suele haber alguna actividad social fuera del horario de la conferencia.

La conferencia en sí es un track único con sesiones de 30 minutos organizadas en bloques, donde cada bloque es: sesión 1 + sesión 2 + coffee break. Al mismo tiempo las sesiones suelen ser en forma de exposición, a diferencia de los eventos de agile, donde hay sesiones tipo workshop o tipo debate. Creo que justamente por estar acostumbrado a las conferencias agile, este formato me resultó  un poco pesado.

Respecto de las sesiones, me llamó la atención que más de una se enfocó en otros lenguajes (recuerdo una sesión sobre Go y otra sobre Erlang). Entre las sesiones que me resultaron más interesantes estuvieron:

  • La de @abecciu de Restorando sobre cómo resolvieron ciertas cuestiones de recolección de datos
  • La @runixo sobre IPython Notebook
  • La de @cristianrasch sobre Rack
  • La de @xymbol sobre Ruby & Unix
  • La de @kurko sobre orientación a objetos

Más allá de esto, hubo otras dos sesiones que más que interesantes yo las calificaría como muy entretenidas, en gran parte por el carisma de sus oradores. Esas sesiones fueron las de @ajlopez sobre su implementación de Ruby con C# y la de @janogonzalez sobre la bipolaridad de los programadores.

Cliente no es un buen término

Es común al trabajar en proyectos hablar de «el cliente» como un rol. Yo mismo lo hago todo el tiempo, pero no me parece apropiado y tengo algunos argumentos al respecto.

Desde el punto de vista humano me parece muy frió: «el cliente y el proveedor», siento que genera un división muy fuerte y que en cierto modo denota un conflicto de intereses. Personalmente me  gusta ver a mis clientes como socios, pues al fin y al cabo ambos sabemos que para lograr un proyecto realmente exitoso tenemos que lograr una situación ganar-ganar.

Desde el punto de vista técnico el término cliente me resulta ambiguo. ¿quien es el cliente? ¿es quien paga por el proyecto? ¿o es quien conoce los detalles de la problemática a resolver?  Para evitar este tipo de ambigüedades es que prefiero utilizar otros términos más específicos, sobre todo al comienzo de los proyecto para dejar bien en claro las responsabilidades de cada involucrado.

En primer lugar todo proyecto tiene un sponsor que es quien está pagando por el proyecto y que también suele representar la parte política del proyecto frente al resto de la organización.

Por otro lado tenemos al experto de negocio que es quien tiene el conocimiento de la problemática a resolver.

Finalmente tenemos al usuario que es quien utilizará la solución de software provista.

Puede que estos tres roles terminen ocupados por la misma persona o no, eso suele depender del contexto del proyecto. En mi experiencia, en organizaciones grandes es muy común que estos roles sean ocupados por distintas personas. Tomando como ejemplo el caso de la petrolera que compartí hace un tiempo, el gerente general ocupaba el rol de sponsor, el responsable de compras era el experto de negocio y los analistas del área de compras eran los usuarios.

La universidad me mintió

Durante toda la carrera me hicieron trabajar sobre «proyectos nuevos» en el sentido que siempre puse la primera línea de código. Al mismo tiempo, los proyectos terminaban cuando aprobaba la materia y el código nunca más era tocado por nadie más, más allá de mi y mis compañeros de grupo.

Estas situaciones llevadas al «mundo real» resultan ser ficticias, rara vez escribimos código para que nunca más sea tocado. Y al mismo tiempo muchas veces nos toca trabajar sobre código ya existen que ha sido desarrollado por alguien más, a quien tal vez nunca conozcamos y que podria incluso vivir al otro lado del globo.

Lo triste es que esto es moneda común en los ámbitos académicos. Son contados los casos en los que los alumnos tienen que trabajar sobre código existente. Ojo, no me refiero a trabajar con librerías, algo que sí es común, sino a trabajar sobre código fuente de un aplicación desarrollada por alguien más. También resulta poco común que el código escrito por un grupo de alumnos, tenga «vida» más allá de la aprobación del trabajo.

Pasando en limpio:

  • En la academia los alumnos trabajan sobre proyectos/productos empezando de cero.
    Pero en la industria muchas veces nos toca trabajar sobre proyectos/producto ya existentes.
  • En la academia los alumnos trabajan sobre productos durante un período «corto» de tiempo y una vez completado el alcance originalmente acordado no vuelven a tocarlo.
    Pero en la industria los productos evolucionan y luego de su versión inicial son modificados cientos/miles de veces a lo largo de su vida útil.

Con este planteo lo que quiero decir es que es necesario que la academia tome conciencia de esta situación y haga algo al respecto. Conozco algunas iniciativas que ya están trabajando en esta línea, pero eso será parte de otro artículo.

Continuará…

Screencast sobre despliegue automático en .NET

El jueves pasado participé de un Meet up organizado por Microsoft Argentina en el cual presenté la estrategia de despliegue automático que estoy usando en uno de mis proyectos actuales.Como la sesión no fue grabada, grabé este screencast.

Para aquellos interesados en profundizar en este tema, les recomiendo que se sumen al taller de integración continua que voy a dictar a comienzos de diciembre.

cd_en_net

La satisfacción de la inquietud

La semana pasada en el contexto del trabajo final de Algo3 dimos la clase de MVC de cara a que los alumnos puedan empezar a trabajar en la parte de vista y controlador.  A los poco días recibí un mail de un alumno de uno de mis grupos con la siguiente consulta:

Queríamos consultarle si hay alguna forma apropiada de hacer testing para la parte de vista del proyecto, ya que desde que nos pusimos a trabajar con la misma la cobertura de código del proyecto bajó notablemente.

Sinceramente la consulta me sorprendió para bien y me causó una gran satisfacción ver que un alumno tenga este tipo de inquietudes ya desde los primeros años de la carrera.

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:

Despliegue automático con Jenkins, MSBuild y MSDeploy

El próximo jueves a partir de las 18.30 participaré de un Meetup organizado por Microsoft Argentina. Entre los oradores cuentan ArielS y quien escribe.

En mi sesión compartiré la estrategia de despliegue automatizado que estoy usando en uno de mis proyectos actuales. Se trata de sistema relativamente grande, con componentes en distintas tecnologías. Yo estoy trabajando particularmente con los componentes .net que son: dos aplicaciones web corriendo en una granja de 8 servidores, un par de bases de datos SqlServer corriendo en cluster y un conjunto de servicios windows corriendo en otras dos servides aparte. Todo el despliegue está automatizado con Jenkins, MSBuild y MSDeploy. Si la sesión se graba, luego compartiré el link, sino grabaré un video para explicarlo de forma resumida.

El Meetup es gratuito pero requiere registración. Pueden registrarse y ver más detalles aquí.