Mes: mayo 2013

Batalla Naval en Algo3

La semana pasada publicamos el trabajo práctico final de Algo3 de este cuatrimestre. El trabajo consiste en la construcción de una aplicación que es una variante del clásico Batalla Naval.

Yo tengo a mi cargo dos grupos, de 3 alumnos cada uno. Ambos equipos estan trabajando en Java.  En la primera charla que tuve con los grupos fui bien claro respecto de la expectativas en la forma de trabajo. Hablé con ambos grupos juntos e hicimos un poco de «community programming» (una especie de pair programming pero de a muchos más) para hacer el setup del proyecto: crear estructura de carpetas, ant, etc, y codeamos la clase casillero haciendo TDD.

Luego les comparti un .zip de lo que hicimos para que lo tomaran como base. Eso les permitió no tener que andar «peleando» con Java y Ant y concentrase en lo importante para nuestra materia: la programación orientada a objetos.

 

Lecturas 2012

ups: este mail me quedó colgado como borrador y me olvidé de publicarlo. Bueno, más vale tarde que nunca.

Comencé el año leyendo Hechicero, el tercer libro de la saga Rio Sagrado de Wilburg Smith. Excelente igual que los dos tomos anteriores.

Luego leí el primer libro de Game of Thrones que lo tenia en mi biblioteca desde mi viaje a Europa. También excelente, con unos giros inesperados.

El siguiente libro fue de un autor argentino llamado Guillermo Martinez, el título del libro: Acerca de Roederer. Me gustó y le dediqué un post en su momento.

Por último terminé la serie de Los Reyes Malditos de Maurice Druon. La comencé a leer hace unos 4 años, lei rápidamente el primer libro y dejé el segundo a la mitad para retomarlos años después y me lei 5 libros seguidos. Resulta que habia comenzado a leer la serie con la expectativa de espaditas, estrategia militar, etc, pero me encontré con intrigas políticas en las corte de Francia. Una vez que acomodé el nuevo panoroma, me resultó entretenido.

En el thread técnico lei bastantes menos libros, pero muchos artículos, blogs y capítulos sueltos de determinados libros entre los que se encuentran:

En otro post les cuento el backlog de lecturas para 2013.

De las grandes bandas a los (no tan) grandes solistas

Esta tarde estaba escuchando en  la radio un reportaje que hacía Juan Di Natale a Palo Pandolfo a propósito de su nuevo disco. Siempre he sentido un cariño especial por Palo, pues fue el líder de Los Visitantes, una de las bandas que más seguí durante mi adolescencia, allá por  la década del ’90. Luego de la disolución de Los Visitantes, Palo formó parte de diversas agrupaciones y hoy en la entrevista conocí la última: Palo y La Hermandad.

Esto me llevó inmediatamente a pensar en otros casos de artistas que también pasaron de bandas «tradicionales» a formaciones del tipo «solista + grupo».  Ejemplos: Indio y Los Fundamentalistas, Ciro y Los Persas, Skay y Los Seguidores de la Diosa Kali, Juanse y Las Fieras Lunáticas, Flavio y La Mandinga, etc, etc.

Y casi sin darme cuenta me encontré pensando en las bandas de convocatoria masiva de los ’90, Los Rendondos, Soda Stereo, La Renga, Los Piojos, Los Cadillacs, etc.  ¡Uau!  Parece como que varias de aquellas grandes bandas han dado lugar a nuevas formaciones caracterizadas por «El solista compositor» y «el grupo de músicos acompañantes». ¿Individualismo?

Sobre mi sesión virtual de Continuous Delivery en ITSMF

La semana pasada participé de un evento virtual organizado por ITSMF. Fue mi primera vez en un evento de esto tipo.

En un primer momento me sentí un poco incómodo, pues sentía que hablaba sólo y yo estoy a acostumbrado a interactuar con la audiencia en todas mis exposiciones. Pero luego de hablar unos minutos, empecé a percibir la interacción de la audiencia en la plataforma, lo cual me tranquilizó.

La sesión se realizó utilizando una plataforma específica para este tipo de eventos: Brightalk. La misma requería subir el material a exponer, en formato PPT/ODP. Luego loguearse en la plataforma como orador y desde ahi manejar la el avance de los slides. Para el audio, el orador debía conectarse vía telefónica. Al mismo tiempo, la plataforma tenia un espacio de chat y la posibilidad de hacer compulsas, dos herramientas muy útiles para interactuar con la audiencia.

Agradezco a la gente de ITSMF y en particular a Juan José (@PinkFloydF) por la invitación.

La sesión está disponible aquí.

Hay gente que miente, gente que roba y gente que no respeta las convenciones

Esta frase me surgió espontáneamente esta tarde mientras daba clase en Algo3. Sonó un poco extrema, a punto tal que motivó algunas risas, pero a esta altura del cuatrimestre los alumnos ya me conocen lo suficiente y saben que para mi no es chiste.

Con el correr de los años me doy cuenta que gradualmente me he vuelto cada vez más radical en algunos temas. Sin duda las diversas lecturas y prácticas de Extreme Programming han tenido algo que ver en esta cuestión.

Personalmente me he ido convenciendo que si una práctica es beneficiosa entonces llevarla al extremo maximiza los beneficios. Y estoy convencido que esto va mucho más allá del desarrollo de software.

Un modelo de madurez de Entrega Contínua

Hace un tiempo salió publicado un artículo en InfoQ sobre el tema de referencia. Hay algunas cosas del modelo propuesto en el artículo que no me cierran pero más allá de eso creo que hay dos puntos destacados en el planteo:

  1. Explicita las diversas dimensiones de la entrega contínua
  2. Propone un camino razonable para la adopción de la práctica en cada una de las dimensiones

Al mismo tiempo resulta que una empresa con la que estoy trabajando actualmente, ha definido su plan de implementación de Entrega Contínua basado en este modelo. En 6 meses les cuento que tal vamos.

Sesión virtual sobre Continuous Delivery

¿Cuánto tiempo pasa desde que el usuario expresa su necesidad hasta que el software que la satisface llega al ambiente productivo donde puede utilizarlo? ¿Cuánto de ese tiempo se debe a a ejecución de procesos manuales? ¿Cuántos errores introducen esos procesos manuales? Si no tienes las respuestas a estas preguntas, o si las tienen y te gustaria mejorarlas no dejes de asistir a esta ponencia sobre Continuous Delivery.

Este es el resumen de la sesión en la que voy a estar dictando mañana, martes 14 de Mayo. Esto es en el contexto de un evento virtual organizado por  ITSMF . El título de la sesión es: De la idea al ambiente de producción. La intención es presentar la práctica de Continuous Delivery surgida dentro del movimiento ágil.  Voy a comenzar presentando algunas cuestiones «conceptuales» y luego hablaré de algunas experiencias concretas de implementación en las que he participado. Mi intención es mezclar un poco de teoría y poco de mundo real.

Como parte del mismo evento habrá otras dos sesiones:

La primer sesión es las 10 am (hora Argentina) y me sesión en particular es a las 12.

El evento es totalmente gratuito, pueden encontrar más detalles de la presentación y el link para registración aquí.

Satisfacción del cliente más allá del entregable

Hace un tiempo comenté que estaba muy contento con mi experiencia como Producto Owner. Dicha experiencia positiva no se debió solamente a que recibí un producto acorde a mis expectativas, sino que también resultó fundamental la forma en que se desarrollo el proyecto. Yo suelo referirme a esto como «experiencia de cliente» y es lo que muchas veces hace la diferencia entre un proveedor de servicios de software y otro. Esta «experiencia de cliente» tiene que ver con cuán fácil le resulta al cliente trabajar con el proveedor y dado que me es difícil dar una definición concreta comparto algunas cuestiones que para mi son importantes para tener una buena experiencia de cliente:

  • El proveedor me da visibilidad contínua del estado del proyecto y los siguientes pasos
  • Cuando tengo inquietudes el proveedor me responde en tiempos razonables para mi negocio
  • El proveedor siempre está bien predispuesto a incorporar el feedback que le doy
  • El proveedor entiende las necesidades de mi negocio y sabe adaptarse a los cambios que este requiere

Todas estas cosas se cumplieron durante el desarrollo de SEAL y por ello mi experiencia como Product Owner fue muy positiva.

Creo que en parte, el haber cumplido con los puntos mencionados tuvo que ver en gran medida con metodologia de trabajo utilizada. Usamos un proceso tipo Scrum con las siguientes particularidades:

  • Iteraciones semanales
  • Una reunión de Demo/Planning semanal, de 1 hora, en la que primero repasábamos el trabajo realizado en la iteración pasada y luego planificábamos la iteración siguiente.
  • Luego de cada reunión de Demo/Planning el equipo enviaba dos mails:
  • Una retrospectiva cada X cantidad de iteraciones para mejorar dinámica de trabajo
  • Todo el tiempo el producto estaba disponible en un ambiente de prueba donde podía entrar a ver/probar funcionalidades
  • Ante cada situación que pudiera implicar un retraso o un desvio de expectativas el equipo me informaba para que tuviera la chance de repriorizar
  • Usamos una herramienta de gestión para administrar el backlog de proyecto
  • Utilizamos burndown charts para tener una visión del estado actual de la iteración y proyectar evolución

Sinceramente me he sentido muy cómodo trabajando de esta forma y por ello espero volver a trabajar así en futuros proyectos.

SEAL: Se buscan colaboradores

Si bien Aníbal y Martín han hecho un gran trabajo y tienen la intención de continuar colaborando con el desarrollo del producto, hay algunas cuestiones que requieren habilidades especiales o bien un esfuerzo importante.

Varias de estas cuestiones serán parte del alcance de algún futuro trabajo profesional de alumnos de Fiuba (ya hay algunos que han manifestado su interés), pero hay una cuestión en particular que dudo que alumnos «promedio» de Fiuba puedan manejar: la estética. Voy a ser sincero, la UI del sistema apesta, no sólo no es cómoda sino que tampoco es visualmente atractiva. Pero es algo que era de esperar, la formación que nos da Fiuba no trata estas cuestiones. Históricamente las casas de estudio de ingeniería se han ocupado que no falten en el plan de estudios materias de ciencia básica y ciencia aplicada, pero cosas de diseño y usabilidad, bien gracias. En fin, no perdamos el foco. El punto es que nos vendría bien contar con una mano de alguien que se dé maña con cuestiones de UI.

Por otro lado, la aplicación está hecha en Python, pero ni Aníbal, ni Martín, ni yo somos expertos en Python. Por esto nos vendría bien la colaboración de un experto Python para hacer una revisión de la aplicación y ver que hayamos aplicado apropiadamente las prácticas y convenciones del lenguaje.