Autor: NicoPaez

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.

Largamos el TP Final de Algo3

Este cuatrimestre el TP fue ideado por GabiD con aportes de DiegoM y PabloM. Consiste en un juego por turnos en el que el usuario debe mover su vehículo por una ciudad llena de obstáculos de distinto tipo, intentando minimizar la cantidad de turnos utilizados y maximizando el puntaje acumulado.

Yo tengo a mi cargo 3 grupos los cuales vienen trabajando muy bien. Para facilitar las cuestiones tecnológicas y permitir que los alumnos se concentren en OO, les dimos un proyecto base de ant y un par de videos que explican cómo dar los primeros pasos con Java, Ant y Subversión. Adicionalmente me encargué de configurar un servidor de integración continua. Para esto último estamos usando el servicio gratuito que muy gentilmente nos brinda la CloudBees. Como de costumbre hemos hecho mucho énfasis en que desarrollen sus trabajos haciendo TDD y según muestran los reportes de cobertura parece que lo estan haciendo.

algo3-g1-2013-2

Relato de un desarrollo ágil en la industria petrolera

Resumen

Este artículo describe un proyecto en el que participé hace un par de años cuyo objetivo era la informatización del proceso de gestión de licitaciones de una empresa del rubro petrolero. El mismo fue realizado por un equipo de 4 personas en un plazo de 5 meses, trabajando con prácticas ágiles de gestión en el marco de un contrato de alcance variable.

Contexto del proyecto

Trabajaba yo en aquel momento en un empresa de desarrollo de soluciones informáticas y nos había contactado una empresa del rubro petrolero para informatizar su proceso de la gestión de licitaciones. Hasta aquel momento esta empresa tenía un proceso de licitaciones totalmente manual lo cual implicaba:

  • Gran volumen de información en papel
  • Alto costo de gestión
  • Licitaciones más largas de lo deseable

El objetivo del proyecto era resolver estas cuestiones a partir de la informatización de proceso y adicionalmente lograr:

  • Una mayor transparencia del proceso de licitaciones
  • Mayor visibilidad del proceso
  • Tener métricas del proceso que permitan detectar posible puntos de mejora

Un detalle técnico relevante era que la solución debía ser implementada sobre una plataforma de gestión de contenidos (CMS) que el cliente ya estaba utilizando.

El acuerdo

La venta del proyecto fue llevada a cabo por el gerente del área de desarrollo con mi asistencia, que en aquel momento era líder técnico. Ambos hicimos un primer relevamiento a partir del cual, mi equipo de técnicos y yo hicimos una estimación de esfuerzo. Luego junto con el gerente del área del área de desarrollo, hicimos un plan tentativo de versiones (release plan ) tomando como base la estimación realizada por el equipo, los riesgos detectados y las fechas deseables que había manifestado el cliente.

Es importante destacar que antes de la presentación formal de la propuesta tuvimos una reunión con el cliente en la que hicimos una presentación informal de la misma, para explicar nuestra forma de trabajo y así asegurarnos que la propuesta escrita fuera bien interpretada. La propuesta tenía algunas particularidades interesantes:

  • Indicaba explícitamente que tendríamos reuniones semanales para validar el trabajo realizado y así tener feedback temprano y constante. Esto nos permitiría asegurarnos de estar construyendo el producto que el cliente necesitaba
  • Establecía un alcance variable, lo cual estaba justificado por la incertidumbre que había respecto de cómo se informatizarían ciertas cuestiones del proceso de licitación. Si bien la empresa ya tenía un proceso de licitaciones que venía utilizando, el mismo era manual y su informatización implicaba ciertos cambios en dicho proceso.Algunos de esos cambios era bien claro cómo debían ser, pero había otros que no y que requerían algo de experimentación.
    Al mismo tiempo la empresa de desarrollo se comprometia a entregar un sistema informático de soporte a la gestión de licitaciones. No se establecía el alcance completo de ese sistema pero estaba claro que ciertas funcionalidades debían ser cubiertas por el sistema.
  • El acuerdo tenía un alcance un año, donde los primeros 5 meses estaban destinados a generar la versión inicial de sistema con un equipo a tiempo completo. Los restantes 7 meses se preveía un esquema de soporte y mantenimiento evolutivo con un compromiso de unas 80 horas mensuales.

Inicio de proyecto

Aproximadamente 2 semanas después de haber presentado la propuesta, el cliente confirmó que haría el proyecto con nosotros. Para mi satisfacción el equipo encargado de la ejecución estaba conformado por los mismo técnicos que habíamos realizado la estimación inicial. De esta forma, por parte de la empresa desarrollo los involucrados éramos:

  • Danilo: gerente de desarrollo y responsable comercial del proyecto
  • Ramiro: era el responsable de sistemas del cliente.
  • Nicolás (yo): líder técnico del equipo de desarrollo y facilitador del proyecto
  • Camilo y Roberto: dos técnicos del equipo de desarrollo

Por parte de la empresa cliente los involucrados eran:

  • Felipe: sponsor, era el directivo de la empresa cliente que estaba pagando por el proyecto
  • Gabriel: era el responsable del  área de compras y en el contexto del proyecto ocupaba el rol experto de negocio y  product owner
  • Manuel y Matías: eran dos empleados del área de compras y como tales eran los futuros usuarios del sistema

La primer iteración fué particular pues duró sólo 1 semana y la dedicamos a algunas típicas del inicio de proyecto como ser configuración de ambientes y capacitación de los expertos de negocio sobre la dinámica de trabajo.

Para la gestión del proyecto utilizamos la herramienta Trac, que era la herramienta estándar utilizada por nuestra empresa de desarrollo en aquel momento. Dicha herramienta brindaba:

  • Gestión de tickets y plan de versiones
  • Wiki
  • Acceso web
  • Almacenamiento de documentos
  • Integración con sistema de gestión de código Subversion
  • Envío de notificaciones ante determinados cambios en los artefactos del proyecto

Dinámica de trabajo

El equipo de desarrollo trabajaba en sus oficinas, las cuales se encontraban a 1o minutos de a pié de las oficinas del cliente. En líneas generales la dinámica de trabajo estaba dada por :

  • Iteraciones time-boxed de 2 semanas de duración
  • Reuniones presenciales de planificación al comienzo de cada iteración
  • Reuniones presenciales de revisión y demostración al final de cada iteración

Dado que la informatización del proceso requería repensar algunos pasos del proceso de licitación, era común durante las iteraciones, hacer algunas reuniones adicionales a para ir analizando/definiendo las «nuevos pasos» del proceso de licitación.

Durante las reuniones de planificación se definían las funcionalidades a implementar en la iteración actual y establecían los criterios de aceptación de las mismas. Dichos criterios eran luego refinados y bajados a detalle por los especialistas de negocio en un plazo máximo de 3 días luego de la reunión de planificación. De esta forma el equipo de desarrollo podía contar con los criterios de aceptación antes de finalizar el desarrollo de las stories.

Apenas finalizada una funcionalidad, la misma era validada con un experto del negocio de forma de tal llegar al final de la iteración con la mayor parte de las funcionalidades con cierto grado de validación. La reunión de revisión al fin de la iteración no solía era un momento tenso, pues el cliente ya sabía lo que sea se iba a encontrar. Si una funcionalidad había sido completa, el cliente ya la habia visto y había dado algo de feedback. Al mismo tiempo, si alguna funcionalidad no había sido completada, el cliente también lo sabía previamente, pues el equipo comunicaba este cualquier tipo de desvío apenas lo detectaba.

Había un detalle importante respecto de la forma en que el equipo planificaba las iteraciones. Las reuniones de planificación se hacían los lunes de la primera semana de la iteración, preferentemente por la mañana. Las reuniones de revisión de hacían los viernes de la segunda semana de la iteración. Sin embargo, el equipo planificaba de cara a completar el desarrollo el miércoles de la segunda semana de la iteración, lo cual dejaba un día y medio para hacer prueba de regresión y realizar ajustes correspondientes al feedback temprano obtenido de los expertos de negocio.

Tanto la definición del proceso, como las user stories y sus correspondientes criterios de aceptación, eran escritos en la wiki del proyecto, en muchos casos por los mismos especialistas de negocio y luego eran revisados por algún miembro del equipo de desarrollo. También se pretendía que los expertos del negocio se encargaran de ejecutar las pruebas de aceptación, aunque esto no siempre se lograba.

La fase de desarrollo se completó con algunas variaciones respecto de lo planificado pero sin problemas graves. Una vez que el sistema estuvo productivo, se pasó a mantenimiento tal como estaba previsto.

Consideraciones finales

No todos los clientes están dispuestos a trabajar de la forma aquí descrita ni tampoco todos los proyectos lo requieren. Tal vez el proyecto se podría haber realizado utilizando otra dinámica de trabajo, pero en su momento creímos que esa era la forma apropiada de llevar ese proyecto. Hoy en día sigo pensando lo mismo.

Entre los puntos que considero fueron claves para el éxito del proyecto no puedo dejar de mencionar:

  • El alto grado de involucramiento de los expertos de negocio
  • Comunicación constante
  • Confianza del cliente en el equipo y vice versa
  • Compromiso y transparencia

El gráfico de Burndown

Este gráfico es muy utilizado en la gestión ágil de proyectos y muchas veces se lo suele hacer en forma manual en el tablero del proyecto.

En el eje horizontal se representa la dimensión tiempo y en el eje vertical se representa trabajo remanente. La unidades utilizadas para cada una de estas dimensiones pueden variar dependiendo de lo que se pretenda mostrar.

El uso más frecuente para este gráfico es durante el desarrollo de una iteración. En tales casos, en el eje vertical se representan los story points remanentes y en el eje horizontal los días de la iteración.

En el siguiente gráfico se muestra el burndown correspondiente  al día 12 de una iteración donde el trabajo remanente es de 12 story points (línea bordó). También puede apreciarse en color gris una línea punteada que representa una proyección basada en el ritmo actual de trabajo del equipo. Finalmente la línea de color naranja muestra el ritmo de trabajo que debería tener el equipo para llegar a completar el trabajo remanente al final de la iteración.

burndown

El gráfico de burndown también puede utilizarse para tener una visión de la evolución del proyecto a más alto nivel que la iteración actual. En este caso se representan iteraciones en el eje horizontal y los story points correspondientes a las user stories aún no completadas en el vertical.

burndown-iteraciones

 

Nota: el primer gráfico aquí mostrado corresponde a un proyecto en el que participé hace ya algunos años cuando solía trabajar con iteraciones de 3 semanas. En la actualidad prefiero trabajar con iteraciones más cortas, generalmente de 1 semana.

Eventos comunitarios en la última parte del año

La semana pasada se llevó a cabo en la ciudad de Rosario la Smalltalks 2013, lamentablemente no pude asistir y digo lamentablemente porque según me han comentado estuvo excelente.

Por otro lado este viernes 8 hay un evento de lujo en el contexto de la comunidad ágil de Buenos Aires: un open space con la participación de Alistar Cockburn y Mary y Tom Poppendieck. El evento se llevará a cabo a partir de las 14.30 hs en el Centro Metropolitano de Diseño. La entrada es gratuita pero requiere registración.

El sábado 16 de Noviembre se llevará a cabo el  primer  workshop de proyecto Uqbar para la discusión de ideas innovadoras en programación e ingeniería de software. Me resultó muy interesante y por eso la semana pasada envié una propuesta de sesión sobre la que aún no he recibido respuesta.

Finalmente, los días 27 y 28 de noviembre se llevará a cabo en el centro cultural Konex la RubyConf Argentina. Si bien el evento no es gratuito, sin duda vale la pena asistir si uno trabaja con Ruby.

QA no es testing

Una confusión que muy frecuentemente encuentro es el uso del término QA para referirse a cuestiones de prueba. Voy a intentar aclarar un poco esta confusión.

Existen diversas definiciones de calidad. Una de ellas es la que define calidad como ausencia de defectos. Esto nos lleva a definir qué entendemos por defecto. En términos generales podríamos decir que un defecto es una no conformidad con los requerimientos/especificaciones.

El testing es una actividad enfocada en la detección de defectos. El testing por si sólo no asegura la calidad de un producto. Decir que al testear se mejora la calidad de un producto, sería equivalente a decir que por pesarse se baja de peso. El testing brinda información sobre los defectos de un producto, del mismo modo que una balanza brinda información sobre el peso. Luego en base a esa información uno puede tomar acciones correctivas, como hacer dieta en el caso de sobrepeso, o corregir los defectos en caso que estos sean de una severidad no aceptable. En términos más formales el testing es denominado Quality Control (QC).

Ahora bien, testear para detectar defectos y luego corregirlos, es un enfoque de calidad en cierto modo reactivo. Esto nos lleva a la pregunta: ¿podremos hacer algo más proactivamente para asegurar la calidad de nuestros productos?

Si aceptamos que la calidad del producto está influenciada por el proceso de construcción del mismo, entonces podríamos tomar un enfoque de calidad más proactivo, definiendo tareas en nuestro proceso de cara a asegurar la calidad. Esto es precisamente lo que se denomina aseguramiento de calidad o simplemente QA (Quality Assurance).

Entonces, siendo explícito: el aseguramiento de calidad (QA) tiene que ver con procesos, no con testing. Claro que existe cierta relación entre estas dos actividades, pero también es cierto que cada una de estas actividades requiere de distintas habilidades.

Resumiendo:

QA = Quality Assurance = Aseguramiento de calidad -> Procesos
QC = Quality Control = Control de calidad -> Testing

Taller de Integración Continua

La integración continua es una de las prácticas de ingeniería que más rápidamente permite comenzar a ver sus beneficios. A pesar de esto hay muchos equipos que no la utilizan, en parte porque sus miembros la desconocen. Al mismo tiempo, dar los primeros pasos con esta práctica requiere de un poco de experimentación de cara tomar algunas decisiones como: qué pasos i

ncluir en el proceso de integración qué herramientas utilizar, cómo configurarlas, etc.

Reiteradas consultas sobre estos temas nos llevaron a organizar este taller de integración continua. El mismo tendrá lugar los primeros días de diciembre en la oficinas de Kleer.

Les comparto el temario tentativo:

  • Fundamentos de la integración continua
  • Automatización del proceso de build
  • El rol de servidor de integración
  • Cómo elegir un servidor de integración
  • Instalación & Configuración básica del servidor de integración
  • Servicios de integración en la nube
  • Métricas y notificaciones

En los próximos días estaré compartiendo más detalles.

taller_ci

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.