Etiquetado: agile

MiriadaX: cursos online gratuitos en castellano

Reciente descubrí MiriadaX, una plataforma al estilo Coursera, pero que agrupa Universidad de España. Cuenta con una gran cantidad de cursos de diversos temas que varian desde Economia y Finanzas hasta Turismo y Salud pasando por Informática e Innovación.

Para hacer una prueba de esta plataforma y aprovechando que ya estoy por terminar el curso de Android decidí anotarme en un curso de agilidad llamado Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI El mismo tiene una duración de 1 mes y una carga estimada de trabajo de 5o horas.

En un mes les cuento que tal el curso y la plataforma.

Continuous Delivery en Olx

Hace aproximadamente un año comencé a trabajar en un proyecto de implementación de continuous delivery en Olx. Mi rol dentro de dicho proyecto era el de facilitador colaborando principalmente con Diego Garber, release manager de Olx y product owner del proyecto.

Cuando digo facilitador lo digo en un sentido muy amplio, ya que mis tareas incluian un poco de gestión, un poco de diseño, capacitación, configuración/troubleshooting de Jenkins y hasta programación en Php. Básicamente ayudaba a que cada involucrado cumpliera con sus tareas, lo cual podía incluso implicar que en ciertas ocasiones me encargara yo mismo de la ejecución de dichas tareas, ya fueran configurar un repositorio GitHub o escribir algo de código.

releases

En estos días estamos cerrando el proyecto y me complace el hecho de que no sólo hemos cumplido con la mayoría de los objetivos inicialmente planteados, sino que aún más importante, hemos agregado valor a la organización permitiendo que el área de tecnología pueda dar respuestas más rápidas a las necesidades del negocio, acortando el ciclo de feedback y potenciando el retorno de la inversión.

En las próximas semanas iré compartiendo algunos datos más de esto, por el momento termino este artículo con un gráfico que muestra la evolución de la cantidad de releases desde que arrancamos el proyecto. En el  mismo se puede apreciar que se pasó de 60 releases mensuales en marzo de 2013 a 180 en enero de 2014.

Sobre la terminologia ágil y sus traducciones

Muchos de los términos del ámbito de la informática tienen su origen en habla inglesa. A lo largo de los años diversos términos han sido traducidos al castellano y en mayor o menor medida las traducciones han sido adoptadas por la comunidad hispano-parlante.

En particular dentro del mundo ágil también nos encontramos con muchos término con origen en lengua inglesa, pero que tal vez por ser de más reciente aparición, aún no tienen traducciones consolidadas en castellano.

La traducción de estos términos fue uno de los desafíos que enfrentamos al escribir el libro sobre desarrollo ágil. Desde un principio decidimos intentar traducir todo lo que fuera posible y razonable. Finalmente la estrategia fue:

  • En el caso de términos con una traducción ampliamente aceptada por la comunidad y a nuestro entender apropiada, hemos utilizado dicha traducción.
  • En el caso de términos con diversas traducciones razonables, optamos por elegir aquellas que a nuestro criterio resultaban más apropiadas.
  • En el caso de términos sin traducciones razonables, optamos por no traducir.

Un caso interesante es el término User Story, muchas veces traducido como Historia de usuario. A nuestro entender dicha traducción no es del todo correcta. El término historia en castellano hace referencia justamente a la historia como sucesión de hechos pasados, lo que en inglés es history. El término inglés story, sería en castellano algo así como cuento. Es por esto que decidimos utilizar directamente el término inglés.

Entre los términos que no tradujimos están: spike, coach, slack y build.

Libro en castellano sobre desarrollo ágil

Hace aproximadamente año y medio me embarqué junto a otros 5 colegas de la UBA en el proyecto de escribir un libro sobre desarrollo ágil.  Si, en total 6 autores lo cual ya de por si sólo significó un gran desafío. La idea no era hacer una compilación de escritos independientes, sino una obra integrada en la que todos los autores fuéramos responsables por la totalidad del libro y no sólo por las partes que escribió cada uno.

La semana pasada finalmente entregamos el manuscrito a la editorial. Aún nos queda un buen camino por recorrer, la parte más trabajosa (al menos para los autores) parece haber quedado atrás.

Entre las cosas que nos quedan por hacer, está la definición del título del libró, una cuestión no menor.

Continuará…

Historia de Ágiles Argentina

Si tuviera que definir un hito punto de inicio de la comunidad ágil de Argentina, sin duda diría que ese hito fue la Conferencia Latinoamericana de Métodos Ágiles, Agiles 2008. Luego de ese evento, comenzamos con las reuniones mensuales de la comunidad ágil de Buenos Aires.

Recuerdo que la primer reunión estuvo dedicada a debatir sobre lo discutido en el panel de cierre de Agiles 2008 en el que habían participado los Poppendieck y Tobias Mayer entre otros. También recuerdo que no pude asistí a ese encuentro :-(.

Ya en 2009, empezamos con eventos en formato Open Space. El primero fue el Agile Open Buenos Aires 2009. Para mi el evento fue un éxito total, si les interesa pueden leer algunos posts que escribí en aquel momento. Luego de este evento realizamos lo que denominamos el “Agile Open Tour” que consistió en hacer eventos Agile Open en distintas ciudades del interior del país. Entre las ciudades que visitó el tour en todos estos años se encuentran: Buenos Aires, Córdoba, Tandil, Bahía Blanca, Tucumán, Rosario, Paraná, La Plata y Mar del Plata. En varios casos estos eventos fueron el punto de partida para la conformación de comunidades locales.

Hasta el 2010, la comunidad éramos básicamente un grupo de entusiastas autoorganizados con ganas de compartir inquietudes, experiencias, conocimientos y aprendizajes. Esto estaba muy bien, pero no contábamos con ningún tipo de estructura organizacional lo cual resultaba un inconveniente en ciertas situaciones . Un ejemplo de estas situaciones fue cuando organizamos la conferencia Agiles 2008. Algunos de los sponsors de la conferencia pagaban en especias haciéndose cargo de algún gasto del evento. Pero otros aportaban directamente dinero y esperaban una factura de parte de la organización, ¡oops!.  Este fue el principal motivo que nos llevó a pensar en la necesidad de contar con una estructura organizacional. Básicamente teníamos dos opciones: armar una asociación civil o bien sumarnos a alguna asociación ya existente como ser IEEE o SADIO. Finalmente fue SADIO.

SADIO es la Sociedad Argentina de Informática, una institución que desde 1960 realiza diversas actividades relacionadas a la difusión de la informática. Posiblemente la actividad más importante sean las Jornadas Argentinas de Informática e Investigación Operativa que año a año reunen a investigadores y profesionales de la informática. SADIO prevé en su estatuto la existencia de grupos de interés denominados divisiones. Lo que nosotros hicimos fue crear la División Ágiles Argentina. Para ello, unos 15 participantes de la comunidad ágil nos asociamos a SADIO y completamos las formalidades para dar origen a la división.

Como comunidad, el ser parte de SADIO nos brinda una estructura organizacional que nos facilita la organización de actividades, como fue el caso de Ágiles 2011, Ágiles 2012 y el Scrum Gathering de Buenos Aires en 2012. Como individuos, el estar asociados a SADIO, brinda descuentos para la participación en eventos/cursos/actividades así como también el acceso a una serie de recursos de la institución.

Desde que somos parte de SADIO hemos participado activamente de las Jornadas Argentinas de Informática, dando cursos de agilismo en el contexto del Simposio de Ingeniería de Software (ASSE).  Adicionalmente, en 2013 algunos miembros de ágiles argentina han dictado cursos en SADIO, una actividad que esperamos se repita durante 2014.

La comunidad no tiene un espacio físico, pero si un espacio virtual que está dado por una página y una lista correo, cuya dirección se encuentra en la página.

ao_tandil_2011Agile Open Tandil 2011

Sobre el tamaño de los proyectos y los equipos en agile

Este es un tema que suele prestarse a debate cuando se habla de métodos ágiles. En diversas ocasiones he escuchado afirmaciones tales como:

Los métodos ágiles no sirven para proyectos grandes.

o

En mi equipo no podemos aplicar métodos ágiles porque somos 50 personas.

Quiero dedicar algunas líneas para desmistificar estas cuestiones.

Respecto del tamaño de los proyectos, en primer lugar debemos dejar en claro qué define el tamaño de un proyecto: ¿mucho presupuesto? ¿mucho alcance? ¿mucha gente?. Podríamos decir que el tamaño de un proyecto está dado por su alcance. Naturalmente la cantidad de personas involucradas y el presupuesto del proyecto suelen ser proporcionales al alcance del mismo.

Aclarado qué entendemos por tamaño, podemos entonces preguntarnos ¿existe alguna limitación de tamaño para aplicar métodos ágiles? La respuesta es no. Entonces ¿puedo hacer proyectos de cualquier tamaño usando métodos ágiles? Tampoco.

La cuestión pasa una vez más por el desarrollo iterativo incremental y los ciclos de feedback. En este sentido la propuesta del agilismo es particionar un proyecto grande en varios proyectos pequeños, trabajando en forma iterativa con versiones incrementales que incorporen el feedback en forma temprana.

¿Y que hay del tamaño de los equipos? La respuesta a esto se deriva del párrafo anterior, si trabajamos en proyectos chicos tendremos entonces equipos chicos. Suele  decirse que el tamaño de un equipo debe ser tal que lo puedas alimentar con dos pizzas.

Sobre herramientas de gestión: Pizarra vs. Software

Ayer tuve una interesante charla sobre este tema. Uno de los participantes se inclinaba fervientemente por el uso de herramientas físicas: pizarra y post-its. Yo en cambio me inclino más hacia el uso de herramientas de  software, tal vez sea porque no soy muy amigo del papel o tal vez sea que tengo algunos motivos más profundos y menos subjetivos como ser:

  • El uso de pizarra y post-its tiene como positivo que es un irradiador natural de información y con un simple vistazo uno puede ver el estado. Sin embargo, esto ya no es algo exclusivo de las pizarras. Hoy en día existen diversas herramientas de software que “emulan” una estética/experiencia similar a los post-its y que combinadas con un monitor grande dedicado (o directamente un televisor) permiten disfrutar de este beneficio de la irradiación de información. Personalmente he trabajado con herramientas de software como Trello, Mingle y Pivotal, con muy buenos resultados.
  • El uso de post-its hace más compleja la obtención de métricas, ya sea porque las mismas deben calcularse a mano o bien porque la información que está en post-its debe replicarse en alguna herramienta software para el cálculo de las métricas.
  • Si tu organización requiere algún tipo de trazabilidad o un historial de items es muy posible que ya estés obligado a usar una herramienta de software.
  • Finalmente está la cuestión de la distribución del equipo, hoy en día es cada vez más común tener gente distribuida físicamente, lo cual dificulta el uso de herramientas físicas. Ojo, no digo que no puedan usarse, sino que su uso en un contexto así puede llegar a requerir de trabajo adicional.

Claro que si tu equipo no está distribuido y no usas métricas en tu proyecto puede que resulte más práctico usar una pizarra.
Más allá de esto, debo reconocer que hay cierta “mística” o “ritual” en el uso de post-its, que en ciertos contextos puede resultar motivador para los equipos.

Cierre de cuatrimestre en Algo3 (2013-2)

Comienzo compartiendo algunos hechos generales que personalmente me resultan de interés:

  • Consolidamos el uso de campus virtual
  • Consolidamos el uso del sistema de corrección de TPs
  • Gran parte de los grupos pudo trabajar exitosamente con servidor de integración continua
  • Curiosamente el  curso de los jueves por la tarde tuvo record de alumnos

Ya hablando en particular del curso de los jueves por la tarde, surgieron los siguientes temas en la retrospectiva:

  • (+) Los videos explicativos
  • (+) El uso de dos lenguajes
  • (+) El uso del sistema de corrección/gestión de TPs
  • (+) El TP final
  • (-) Poco tiempo para resolver los parciales => cuestión recurrente a pesar que Carlos a intentado mejoras ya lo hablaremos en equipo
  • (-) Poca explicación sobre cómo crear elementos visuales con Java => Vamos a proveer una guía/ejemplo/video para facilitar este tema
  • (-) Que el corrector automático no corra todo el tiempo => Este un tema de infraestructura que esperamos tener resulto para el cuatrimestre próximo.

Ya en el plano personal, la experiencia con mis grupos me resulto excelente. Tuve 3 grupos que trabajaron acorde a mis expectativas, haciendo test-driven development e integración continua y cumpliendo con las fechas estipuladas. Creo que por primera vez todos los grupos a mi cargo cumplieron con la fechas estipuladas.

algo3-2013-2

Project Bootstrap, cómo inicio mis proyectos

Al comienzo de todo proyecto de desarrollo hay ciertas cosas que debemos tener en claro y algunas decisiones que debemos tomar respecto de las herramientas de soporte que utilizaremos. Estas cuestiones constituyen lo que suelo denominar como bootstrap del proyecto. Hace un tiempo grabé este screencast para mis alumnos de UNQ sobre este tema. Para quienes prefieran leer a escuchar, resumo brevemente lo que mencionado en el screencast.

Todo proyecto surge a partir de una visión. La visión es definida por el cliente y es básicamente el justificativo del proyecto. El cliente decide llevar adelante el proyecto para resolver un problema o para aprovechar una oportunidad. Es fundamental que todos los involucrados del proyecto conozcan la visión, por ello siempre suelo ponerla por escrito y compartirla con todos los involucrados.

Al desarrollar proyectos es común hablar de “el cliente”, un término que me resulta inapropiado, pues lo considero ambiguo. Personalmente prefiero utilizar términos más específicos. Desde mi perspectiva todo proyecto tiene un sponsor, que es aquel que brinda el apoyo político para que el proyecto se lleve adelante. En forma simplificada podemos decir que el sponsor es quien está pagando por el proyecto. Por otro lado tenemos al experto de negocio, que es quien conoce en detalle la problemática a resolver. En ocasiones puede que el sponsor sea también el experto de negocio, pero no siempre es así.

Ya en el terreno de las herramientas, hay algunas cosas básicas como:

  • un repositorio de código: git, mercurial, subversion o el que más te guste
  • una herramientas de gestión: Jira, Redmine, Trello, una hoja de cálculo o simplemente un tablero de post-its
  • un servidor de integración continua: Jenkins, TeamCity, Travis o el que gustes

Adicionalmente me parece importante contar con:

  • Un ambiente de prueba/demo: este es un ambiente “neutro”, fuera de la máquina del programador, donde se instala la aplicación en cuestión de forma frecuente. Este ambiente es usado para las revisiones de iteración. De cara a mitigar riesgos, debería ser lo más similar posible al ambiente productivo
  • Projectpedia: es básicamente una wiki que concentra información del proyecto. Con información del proyecto me refiero a cosas bastante variadas que van desde información de contacto de los involucrados, hasta la visión del proyecto y la información de acceso a los distintos ambientes, etc, etc

¿y tu? ¿usas algo más?

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”