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í.

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.

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.

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:

• ¿Qué me aporta una plataforma ITSM en el uso de AGILE?
• ¿Por qué la agilidad es cada vez más determinante en las empresas?

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í.

• 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:
  • Uno de fin de iteración, con un resumen de lo realizado
  • Uno de inicio de iteración con el compromiso de trabajo para nueva iteración
• 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.

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.

El nombre formal del sistema es SEAL: Sistema de Entregas Automatizadas Libre, un nombre apropiado en el sentido que representa lo que hace el sistema, pero desde el punto de vista comercial no tiene mucha onda (ya estamos trabajando en buscar un mejor nombre).

Como suele suceder en la presentación de los trabajos finales de carrera, la mayor parte de la audiencia son familiares de los alumnos que presentan y por lo tanto es poco lo que entienden de lo que se presenta. Siendo conscientes de esto, Aníbal y Martín prepararon una presentación muy didáctica para explicar su trabajo. Básicamente utilizaron la metáfora de un viaje a la luna para explicar el desafio que para ellos representaba hacer este trabajo de fin de carrera. Personalmente me gusto mucho la presentación, respeto los tiempo, resultó entretenida y expuso de forma adecuada el trabajo realizado.

Ha sido un gusto para mi trabajar con Aníbal y Martín, espero haberles aportado al menos un granito para su formación profesional. Al mismo tiempo les agradezco por haber confiado en mi para guiarlos en el trabajo.

¡Mi felicitaciones a los flamantes ingenieros!

El material utilizado en la presentación está disponible aquí.

Como build server hicimos un primer intento de usar TFS, pues el proyecto ya lo venia utilizando como repositorio de código y herramienta de gestión. Pero luego de dos problemas, desistimos y decidimos apostar a lo seguro: Team City. ¡Ja!, seguro que más de uno pensó que iba a decir Jenkins. No, hace un año aproximadamente analicé ambas herramientas y llegué a la conclusión que para ambientes Microsoft era más apropiado utilizar Team City.

Como herramienta de build usamos MSBuild.

Para realizar los pasajes entre ambientes, dado que nuestra aplicación es web, optamos por la propuesta de Microsoft: MSDeploy.

Continuará…

Como parte de nuestro proceso de despliegue, era necesario que uno de los Jobs ejecutara un merge de svn.

Estuve 2 horas para hacerlo funcionar. Resulta que al correr el job obtenia un error del svn diciendo que no podia conectar al servidor. Entonces entré a probar distintas cosas para encontrar la razón del error. Me conecté al server svn, me dió ok. Revisé el plugin de conexión a svn y googleando encontré que podia haber problemas con mi versión, entonces lo actualicé. Volví a probar, el mismo error. Actualicé la versión de svn, el problema persistia. Empecé a pensar que el problema estaba en servidor svn, pero desde mi máquina conectaba OK. Pensé que habría un problema con el job, entonces cree otro. Al pepe, el error persistía.

Así seguí probando cosas, hasta que finalmente escribí al proveedor del servicio quien me confirmó que el servicio estaba funcionando bien y me preguntó que DNS estaba usando. Me fijé en el server y estabamos usando el DNS de Google, lo cual “me dejó tranquilo”. Pero para mi sorpresa la gente de soporte del servicio svn me indicó que el DNS de Google no es una buena opción y que durante el año anterior habian tenido varios problemas. ¡Ja! ¿¡quien lo iba a imaginar!? Esta es la respuesta textual de la gente de soporte:

I would not recommend using Google’s DNS, it’s been very flakey the past year, so much so we no longer use it internally at all. Here are some other options: UltraDNS, Dynect, OpenDNS, Norton DNS.

Bueno, en sí, no fue todo el día, pero fue mucho más de lo que debería haber sido.

El viernes 26/04 a las 18 horas, los estudiantes Aníbal Alejandro Lovaglio y Matín Mauro Zucchiatti presentarán en el Lab. E del Departamento de Computación su Trabajo Profesional “SEAL (Sistema de Entregas Automatizadas Libre)”, que realizaron con la tutoría del Ing. Carlos Fontela y el Ing. Nicolas Paez como co-tutor.

Resumen:
El presente trabajo se enmarca en la problemática de corrección de trabajos prácticos en las materias de programación. La mayor parte de la producción a evaluar se trata de programas de computadora, y resulta claro que la funcionalidad de los desarrollos constituye el núcleo de la atención dedicada por los docentes a la hora de corregir las entregas. Sin embargo, esta porción del trabajo muchas veces hace perder tiempo valioso que debiera utilizarse para revisar aspectos conceptuales, como el diseño de las soluciones o la separación de incumbencias dentro de los distintos núcleos de abstracción de dicho
diseño. Es decir que muchas veces se invierte tiempo en ver que las entregas funcionen, o cumplan con casos de pruebas, pero lo que realmente importa no es que funcione, sino cómo está construido, y cómo funciona.
Existiendo ahora tantas herramientas que nos permitirían hacer esto de manera automática, es imperativo que se abandone el trabajo artesanal de testing y que se pueda dedicar el tiempo de los docentes en cosas que requieran del criterio de una persona.

Breve descripción de la metodología, indicadores, etc. que llevaron para su gestión
La gestión del proyecto se hizo usando una metodología basada en Scrum, pero adaptada a las condiciones del equipo de trabajo, ya que los tiempos dedicados al proyecto no eran regulares y la interacción entre los miembros del equipo está limitada por las circunstancias laborales de cada uno. De cualquier manera se usó el desarrollo guiado por user stories, y se midió el avance por burndown chart de proyecto.
El desarrollo del proyecto fue pensado en una única fase, con el objetivo del proyecto cumplido a su fin.
Se trabajó con un servidor de integración continua, que después de cada commit, compila, comprueba la sanidad del nuevo código y redespliega la aplicación, poniendo disponible la nueva versión.

Están todos invitados.