DevOps ¿es un realmente un rol?

Érase una época en que las organizaciones operaban como silos, con un área de desarrollo por un lado y una área de operaciones/infraestructura por otro. Estas dos áreas no sólo hablaban poco entre ellas sino que incluso en algunos casos guardaban cierto rencor entre sí. Programadores y Sysadmins enfrentados mutuamente como Vampiros y Hombres-Lobo, porque obviamente más allá de las diferencias que ellos percibían, para todo el resto de la organización eran más o menos lo mismo: gente rara del área de TI.

La adopción de métodos ágiles en las áreas de desarrollo ayudó que los desarrolladores se acercarán más al negocio y al resto de las áreas de la organización. Agile fue algo así como la sustancia que permite a Blade exponerse la luz solar y vivir más como humano que como Vampiro. Pero en la gran mayoría de los casos la fórmula de Blade no tuvo efecto en los Hombres-Lobo, quienes quedaron aún más aislados del resto de la organización.

En varias organziaciones la cuestión se puso aún más interesante cuando los equipos usando agile pretendieron salir a producción en forma frecuente. Tradicionalmente los pasajes a producción ocurrian cada un par de meses y era entonces cuando la relación entre Programadores y Sysadmins alcanzaba los picos máximos de tensión. Ahora los programadores agile pretendián ir a producción cada 2 semanas y encima contaban con el apoyo (y el entusiasmo) de la gente de negocio. Para los Hombres-Lobo esto era demasiado: ahora los Vampiros tenian el apoyo de Blade y los humanos.

Y como suele ocurrir en todas las guerras, el mayor perjudicado con todo esto era el pueblo (que en este caso era la organización). Fue en este contexto donde surgió el la iniciativa de DevOps como una propuesta para acercar a los programadores y los sysadmins y lograr que cada uno trabajé consciente de la existencia y responsabilidades del otro. Es aquí donde las implementaciones de DevOps divergen en dos estrategias.

Por un lado algunas organzaciones generan un nuevo rol al que denominan DevOp con el objetivo de mediar entre programadores y sysadmins. Si bien creo que inicialmente esta estrategia puede ayudar mejorar la situación, creo que no es más que un remiendo. Estos DevOps cuentan generalmente con habilidades técnicas mixtas, o sea son una especie de Hombre-Lobo-Vampiro y en última instancia son un bicho raro más a los ojos del resto de la organización.

Por otro lado, algunas otras organizaciones ven DevOps como una transformación en la organización mediante la cual programadores y sysadmins dejan de lado su egoísmo para trabajar colaborativamente unos con otros (al mejor estilo Saga Crepúsculo parte 3) de cara a lograr una feliz convivencia con los humanos y el resto de la organización.

Personalmente me inclino por esta segunda estrategia de DevOps aunque reconozco que en ciertos casos la primera estrategia puede resultar beneficiosa siempre y cuando quienes ocupen el rol de DevOps cuenten con habilidades blandas (gestión, facilitación, etc) más allá de las habilidades técnicas.

Nobleza obliga: la analogía con Vampiros y Hombres-Lobo está tomada de un artículo publicado por Jeff Atwood en su blog CodingHorror.com.

La calidad no es inyectable, parte 3

Finalmente hoy sí voy a referirme a los métodos ágiles. Tal como lo contamos en el capítulo 18 de Construcción de Software, una mirada ágil, el enfoque de los métodos ágiles es construir con calidad día a día. Esto no es muy novedoso pues bajado a concreto (y en forma simplificada) lo que hacen los métodos ágiles es tomar algunas de las prácticas existentes en el desarrollo de software y llevarlas un paso más allá:

  • Si las revisiones de código agregan valor, entonces directamente escribamos el código de dos (pair programming)
  • Si el feedback del usuario es valioso, entonces trabajemos más cerca de él (on-site customer) y busquemos su validación en forma periódica (iteration review)
  • Si la integración periódica nos facilita el desarrollo, entonces integremos todo el tiempo (integración continua)
  • Si el testing y la aceptación son actividades importantes para la calidad, no las dejemos para el final, integremoslas al ciclo de desarrollo de forma temprana (Definition of Done, BDD)
  • Si creemos que podemos mejorar en la forma que trabajamos, incorporemos entonces un mecanismo explícito para la mejora continua (retrospectivas)

Y sin duda podríamos seguir enumerando casos de prácticas de desarrollo que los métodos ágiles han potenciado.

Adicionalmente hay algunas otras cuestiones, que personalmente no logro identificar con prácticas pre-existentes pero que sin duda son clave en los métodos ágiles y entre las cuales destaco:

La construcción de software es una actividad intelectual llevada a cabo por personas. Si bien puede parecer una cuestión obvia resulta que curiosamente muchos enfoques de construcción de software precedentes parecen haberla pasado por alto.

Fin.

Libro de experiencias

Hace un tiempo que vengo dando vueltas a la idea de escribir un libro de experiencias de desarrollo de software. Seria una especie de compendio de casos de estudio cada uno de ellos escrito en primera persona. No es una idea novedosa, de hecho el año pasado gente de una univesidad de Colombia intentó hacer algo similar, pero hasta donde supe no prosperó.

La semana pasada mientras compraba mi pasaje para el Agile Open Camp tuve una idea para para concretar este libro: proponer una sesión en el open space para escribirlo. La idea seria aprovechar que estaremos 3 dias y dedicar un tiempo fijo cada día de cara a llegar el final de evento con una primera versión del libro. Puede parecer complejo pero en realidad no lo es, básicamente quienes tengan un caso para compartir, deberan sentarse y escribirlo, sin dar muchas vueltas la idea tener el caso contado aunque sea a grandes rasgos, luego se le podremos iterear para agregar detalles y correcciones. El último dia del evento tomamos todos los casos y generamos el libro utilizando la plataforma LeanPub. A partir de ahí, el manuscrito queda en un repositorio Git para que podemos ir puliendo los capítulos, ajutando estilo, agregando imágenes, etc, etc.

Al mismo tiempo, yo como promotor de la idea tomaré la responsabilidad de revisar y unificar estilos (acepto colaboración también para estos temas).

Más aún, podría ser interesante llevar al evento con algunos casos ya escritos y aprovechar alguna sesión del open space para trabajar en cuestiones de revisión y unificación de estilo. ¿Que tal si escribes tu caso durante el viaje? (salvo los patagónicos, el resto de los asistentes tendrá al menos 2 horas de viaje, tiempo más que suficiente para volcar la idea en un mail).

Imagino todos los casos siguiendo una misma estructura:

  • Título
  • Tags
  • Contexto
  • Desafío
  • Solución
  • Conclusión

Para tener una idea más concreta de mi idea de caso, pueden ver este que escribí el año pasado.

Para mi es clave es llegar el final del evento con una primera versión del libro, pues ya he participado en proyectos de escritura/traducción con varios involucrados y resulta verdaderamente complejo lograr compromiso y dedicación cuando uno tiene otras responsabilidades.

Bien, la invitación está hecha,  espero que contar con el apoyo suficiente para terminar el evento con la primera versión del libro.

 

El evento del Año: AOC 2015

aoc2015

Definitivamente este evento está en el top 3 de los eventos que más expectativas me han generado.

Mi gran expectativa no es por el contenido, pues dada la propia dinámica del evento el contenido surgirá de los asistentes y será sin duda excelente. Lo que realmente me genera gran expectativa es el “formato inmersivo”: hay una invitación explícita a compartir plenamente 3 días realizando diversos tipos de actividades, sesiones de debate, caminatas, almuerzos, meriendas, cenas, visitas turísticas, actividades deportivas, etc, etc.

Y como si con una experiencia así no fuera ya suficiente, debemos sumarle el hecho de que el evento se llevará a cabo es uno de los paisajes naturales más hermosos de Argentina.

Me imagino…

….charlas después de la cena alrededor de una fogata.

…rondas de mate al aire libre con un cerro nevado de fondo.

… actividades recreativas a la orilla del lago.

…asado, chocolates y cerveza!!!!

La cita es 17, 18 y 19 de Abril en San Carlos de Bariloche, info completa en http://www.agileopencamp.com.ar/ ¿Te lo vas a perder?

 

 

 

#ConstrucciónDeSoftware, entrevista en DevAcademy

Mañana (miércoles 5 de Octubre), a las 22 hs. (Argentina) estaré participando del ciclo DevHangouts organizado por la gente de DevAcademy.

La excusa es hablar un poco del libro: las motivaciones que nos llevaron a escribirlo, el proceso de escritura y obviamente el contenido. Al final del hangout sortearemos un libro.

Los interesados pueden sumarte al hangout via este link: http://devacademy.la/devhangout

Agiles 2014, #NoSeréFeliz pero tengo trabajo

#NoSeréFeliz pero tengo trabajo, fue el título del keynote de Martín Alaimo el tercer día de Agiles2014. Posiblemente haya sido el mejor keynote que vi en las 6 ediciones de ÁgilesXX que participé (no estuve en 2010). Ya de entrada el título resultaba interesante. Más allá del contenido del keynote, destaco algunos elementos que a mi entender fueron claves para que el keynote sea realmente excelente:

  • Manejo de recursos: en primer lugar Martín manejó muy bien los tiempos y respetó lo que estaba agendado. También hizo un uso discreto pero muy apropiado de las diapositivas: diseño minimalista, pocos colores, poco texto, algunas imágenes, nada de transiciones. Esto hacía que audiencia no se distraiga con las diapositivas en cambio prestara atención a lo que Martín decía. También hizo uso de las luces, en un momento se apagaron todas las luces del auditorio lo cual sirvió para generar una atmósfera muy especial y en sintonía con lo .que se estaba hablando.
  • Vivencia: Martín comenzó contando una vivencia personal, lo cual generó una conexión con la audiencia.
  • Participación: a pesar de ser un keynote, Martín hizo participar a la audiencia en varias ocasiones. En un momento nos dió algunas consignas a realizar desde nuestro lugar y luego invitó a algunos voluntarios a subir al escenario.
  • Llamado a la acción: finalmente el keynote cerró con un llamado a la acción, una estupenda idea para el cierre pero que curiosamente pocas veces he visto.

Mientras escribo estas líneas, reflexiono, recorro mi memoria y llego a la conclusión de que este keynote está en el top 3 de las mejores sesión que presencie en mi vida.

¡Gracias Martín!

martin_at_agiles2014

#ConstrucciónDeSoftware, disponible en Amazon

La semana pasada cumplimos un nuevo hito con el libro, llegamos a Amazon. El libro puede encontrarse fácilmente buscando por “construccion de software” o directamente siguiendo este link.

Cabe aclarar que por el momento sólo es posible comprar la versión física del libro, la versión digital para Kindle aún no está disponible, estamos trabajando para ella pero va a llevar un tiempo más.

libroenamazon

Galería

Galeria fotos de Agiles 2014

Galería completa aquí.

Fer di Bartolo en su sesión Transformation Priority Premise

Fer di Bartolo en su sesión Transformation Priority Premise

Hernán y Jorge de 10 Pines en el almuerzo

Hernán y Jorge de 10 Pines en el almuerzo

Dos tipos duros, Diego Garber de OLX y Carlos Peix de Kleer

Dos tipos duros, Diego Garber de OLX y Carlos Peix de Kleer

Juan, Diego y Gerardo, de Uruguay

Juan, Diego y Gerardo, de Uruguay

Con Diego Fontdevila y Mauro Cesar luego de la sesión de "Buen desarrollo sin agilidad"

Con Diego Fontdevila y Mauro Cesar luego de la sesión de “Buen desarrollo sin agilidad”

DSC04723

Carlos Hurtado y Jugel Correa contando su caso en Sura

Sesión de LeanUX facilitada por Olga Cardenas

Sesión de LeanUX facilitada por Olga Cardenas

En la presentación del libro Diego Fontdevila y Juan Gabardini

En la presentación del libro Diego Fontdevila y Juan Gabardini

Agiles 2014, DONE

Ayer finalizó Ágiles 2014. Fueron 3 días muy intensos. No tengo números oficiales, pero sin duda hubo un record de asistencia, se rumoreaba por los pasillos que había alrededor de 700 asistentes. Según pude confirmar hubo asistentes de 10 países: Colombia, Argentina, Perú, Ecuador, Chile, Uruguay, El Salvador, USA, Bolivia y Brasil.

Manteniendo la tradición de años anteriores, el evento estuvo organizado en 2 dias de conferencias tradicionales y un dia de Open Space. En este sentido fue el open space más grande del que participé. Los facilitadores del mismo fueron Luis Mulato y Carlos Hurtado. Dejando de lado los keynotes, creo que en promedio las mejores sesiones estuvieron en el open space.

Si bien hubo sesiones muy buenas, como el keynote de Martin Alaimo y la sesión de LeanUX de Olga Cárdenas, creo que hubo unas cuantas que fueron muy pobres. Definitivamente este es un tema a mejorar en el futuro.

Un condimento adicional de esta edición de Agiles fue la presentación de dos libros: Por un Scrum Popular, traducción con anotaciones de Alan Cyment del libro Tobias Meyer y Construcción de software, mi libro ;-).

Inicialmente la idea de realizar el evento en un hotel de alta categoría me generó cierto ruido pero debo admitir que la “experiencia de asistente” fue excelente y en mi caso particular se vio potenciada por el hecho de alojarme en el mismo hotel.

Agradezco al equipo organizador por regalarnos este gran evento y darle continuidad a este espacio que inauguramos allá por 2008.

El próximo año el evento se realizará el Montevideo, allí nos veremos Ágiles 2015 Uruguay.

openspaceagiles2014

Marketplace del Open space

 

Agiles 2014, mi presentación sobre automatización de pruebas

Esta mañana di mi sesión sobre pruebas automatizadas. La sala estaba repleta de gente a punto tal que había gente sentada en el piso. Estimo había cerca de unas 80 personas.

Dado que yo ya sabía que no tendría tiempo suficiente para compartir todo el contenido que tenía preparado, compartí esto en con la audiencia y los invité a priorizar los temas a tratar: teoría de automatización y demostraciones de herramientas. Finalmente acordamos comenzar por los temas teóricos y dejar las demos para una sesión del open space de mañana.

Más de la mitad de los asistentes eran de perfil técnico (programadores y testers) y sólo una pequeña parte (unos 10) tenían pruebas automatizadas.

El material utilizado está disponible para descarga aquí.

sesion_agiles_2014