Etiqueta: agile

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.

User Stories vs. Casos de uso

Es común que en una primera aproximación tienda a verse las user stories como análogas a los casos de uso del Proceso Unificado, en el sentido que ambos artefactos describen en cierto modo una funcionalidad del sistema. Personalmente creo que esta analogia no es apropiada, ya que mientras un caso de uso es efectivamente una especificación de un requerimiento, la user story podría a lo sumo el título de dicho requerimiento.

Es más, en un punto podríamos decir que las user stories son en su espíritu contrarias a los casos de uso: mientras que los casos de uso pretenden contemplar los detalles del requerimiento para que el programador pueda realizar una implementación completa y correcta del requerimiento, las user stories son intencionalmente vagas pues lo que buscan es promover el diálogo entre quien debe implementar la funcionalidad y quien la ha requerido.

¡Que lindo es ser Product owner en estas condiciones!

Como ya he comentado, he estado trabajando con un par de alumnos de FIUBA en la construcción de un sistema de corrección de trabajos prácticos. A lo largo del proyecto he ocupado diversos roles: director, consultor, tester, etc, pero sin duda el que más tiempo he ocupado y que más he disfrutado es el rol de Product Owner.

Es la primera vez que ocupo este rol y ¡que linda experiencia me ha resultado! Creo que en gran medida esta satisfacción se debe a que el equipo (los alumnos en este caso) han sabido contentarme, no solo construyendo un producto que satisface mis necesidades, sino que también han logrado que el trabajo sea fácil de llevar. ¿De qué estoy hablando? De cosas en un punto simples u obvias pero que no siempre se dan. Puntualmente, han entregado un producto de valor, han sabido adaptarse a los cambios pedidos, me han dado visibilidad completa y contínua del estado y el avance del proyecto y en líneas general han facilitado mucho mi trabajo como product owner.

Agile no funciona con equipos grandes

Simplemente porque no existen equipos grandes. Seamos realista, 50 personas trabajando en un en una sala no son un equipo, son simplemente un amontonamiento de gente. Un equipo es mucho más que un amontonamiento de gente, basta con mirar los equipos deportivos, donde la mayoría no supera los 10 integrantes.

¿Esto implica que no pueden hacerse proyectos grandes? De ninguna manera, si un proyecto por la cuestión que sea require de 50 programadores, entonces simplemente habrá que particionar el proyecto de manera que puede ser desarrollado por 10 equipo de 5 integrantes cada uno.

Inclusión de métodos ágiles en las carreras de informática

En este post quiero tratar un tema que estuve trabajando la semana pasada en los talleres que participé en Medellín.
Según mi visión, a la hora de diseñar una carrera de informática existen distintas alternativas para incluir los métodos ágiles. En una simplificación extrema podriamos hablar de un enfoque conservador y otro innovador.

El enfoque conservador podria consistir simplemente en agregar una materia sobre métodos ágiles (posiblemente hacia el final de la carrera) y mantener el resto del plan sin mayores modificaciones.

Por otro lado, el enfoque innovador sería repensar la carrera completa incluyendo temas de agilismo en diversas materias. De esta forma se podría incluir Scrum en la materia de gestión de proyectos, TDD en las materias de diseño/programación, BDD y User Stories en las materias de análisis/requerimientos y así sucesivamente.

Si bien el enfoque innovador puede parecer más difícil de implementar, la realidad es que no siempre es así. Un claro ejemplo es lo que ocurre en FIUBA. Si bien los planes de estudio actuales no hacen referencia explícita a métodos ágiles, varios profesores han incluido temas de métodos ágiles en sus respectivas materias por iniciativa propia. Claro está, que esto es pura informalidad ya que la inclusión de los temas está sujeta por completo a la iniciativa de cada docente. Pero también es cierto que es una implementación «rápida», ya que no require de todo el trámite burocrático que puede implicar el modificar un plan de estudios. En FIUBA los temas de agilismo se empezaron a dictar hace ya más de 6 años por iniciativa de algunos docentes. Hoy por hoy, más docentes se han sumado a esta iniciativa y los nuevos planes de estudio (que están en proceso de aprobación) ya incluyen formalmente estos temas que en la realidad se vienen dictando hace varios años.

Cómo hacer pruebas automáticas sin xUnit

Hace un tiempo en un webcast de la comunidad ágil de Venezuela mencioné la importancia de que todo programador sea responsable de escribir las pruebas unitarias de su código, lo cual es absolutamente independiente del lenguaje de programación utilizado ya que para hacer pruebas no es necesario contar con ninguna herramienta particular. Ante esta afirmación una persona de la audiencia consulto ¿afirmas que es posible escribir pruebas unitarias sin usar un framework de pruebas unitarias? La respuesta es si. Veamos un ejemplo.

Básicamente una prueba unitaria consta de 3 pasos conocidos como las 3A.

  • Arrange: es la preparación de todo lo necesario para realizar la prueba
  • Act: es la ejecutación de la prueba
  • Assert: es verificación de que el resultado obtenido es acorde a lo esperado

De estos tres pasos el único que depende del framework de pruebas unitarias es el assert. Generalmente el framework de pruebas unitarias provee uno o varios métodos del tipo assertXXXX que verifican el valor de verdad de una expresión y en base a ello arrojan un resultado.
Esta funcionalidad del assert de framework de pruebas unitarias bien podría ser reemplazada por una función similar a la siguiente

public void verificar(boolean expresion){
  if(!expresion)
    throw new RuntimeException();
}

Vemos cómo podríamos utilizar esta función para hacer un prueba de la clase ArrayList.

public void deberiaCrearseVacio(){
  // arrange & act
  ArrayList array = new ArrayList();
  // assert
  verificar(array.size()==0);
}

Para aquellos interesados en profundizar, aquí les dejo un ejemplo completo en Java que muestra como codificar y ejecutar las pruebas.

Agilizando Medellín

Por estos dias me encuentro en Medellín dictando un par de talleres sobre adopción de métodos ágiles en la academia. Esta actividad es una iniciativa de Ruta N, un organismo creado conjuntamente por la alcaldía de Medellín y otras organizaciones (tanto del sector público como privado) para promover el desarrollo de negocios innovadores basados en tecnología.

Esta iniciativa tiene como objetivo promover/facilitar la inclusión de los métodos ágiles en los planes de estudio de las carreras de informática. De la iniciativa estan participando 6 universidades entre las que se encuentran la Universidad Nacional de Colombia, la Universidad de Medellín y el Politécnico Colombiano.

Continuará…

Actividad con la comunidad Venezolana

Este miércoles voy a estar participando como facilitador de un webcast sobre métodos ágiles organizado en conjunto por la comunidad ágil de Venezuela, Kleer y Evolución ágil. La actividad es gratuita pero require registración previa.

Como lo sugiere el título, el temario es bastante abierto y justamente por ello hemos habilitado un espacio para que los interesado voten temas y posteen sus inquietudes de antemano.

Artesania de Software, el movimiento

Es muy posible que los siguidores de este espacio conozcan algo sobre métodos agiles. En la misma línea que lo métodos ágiles pero yendo un poco más lejos, hace unos años apareció otro movimiento llamado Software Craftsmanship.

Este movimiento pone el acento en ciertas cuestiones de índole más técnica y entre sus referentes cuenta con Uncle Bob, Micah Martin y Paul Pagel (estos últimos dos tuvimos el gusto de tenerlos en la Conferencia Latinoamericana de Métodos Agiles). El punto de entrada a este movimiento es su manifiesto y a mi parecer este video de Uncle Bob.

A modo de resumen les recomiendo este comic que esquematiza bastante bien las distintas visiones del desarrollo de software según el enfoque tradicional, el enfoque ágil y el enfoque craftsmanship.