ASSE 2014, largamos

Hoy tuvimos la primer actividad de ASSE, fue un taller de Arquitectura Emergente de dictado por Diego Fontdevila. El taller duró 4 horas y estuvo dividido en una primera parte teórica y una segunda muy práctica que sorprendió muy positivamente a los asistentes.

Del taller participamos unas 9 personas con perfiles muy variados incluyendo desde alumnos de grado hasta empresarios pasando por docentes, doctores y profesionales de la industria. Esta gran variedad resultó muy enriquecedora para las charlas y actividades del taller.

Más allá de las cuestiones compartidas en el taller, cada asistente se llevó su ejemplar de Construcción de Software: una mirada ágil.

arq_asse

Desarrollador y facilitador, no way

Como ya comenté en un artículo anterior, desde hace un tiempo estoy trabajando en un proyecto Java, una tecnología que no domino plenamente.

El miércoles pasado participé de una retrospectiva de este proyecto que fue facilitada por Alan y que me dejó pensando un buen rato. Ocurre que durante la retrospectiva Alan hizo dos sugerencias puntuales que yo mismo he hecho a otros equipos en reiteradas ocasiones pero que curiosamente esta vez no las sugerí a mi propio equipo.

Todo el viaje de vuelta a casa me lo pasé analizando esta cuestión y finalmente llegué a una conclusión que me convenció: mi falta de pleno dominio de Java me obliga a poner demasiada energía en cuestiones técnicas, lo que me hace perder de vista algunas otras cuestiones.

Luego de pensarlo por un par de días y de consultarlo con algunos amigos me animo a arriesgar:

Para que un desarrollador pueda ocupar el rol de facilitador en su equipo es necesario que tenga un buen dominio de las cuestiones técnicas con las que debe trabajar cotidianamente.

(posiblemente esta afirmación no tenga aplicación universal, pero definitivamente aplica a mi)

Se viene el libro….

Hace un par de días entró en imprenta el libro de ingeniería de software que empecé a escribir hace unos dos años junto a un grupo de colegas de la Fiuba.

La idea era escribir un libro sobre métodos ágiles, luego de un par de charlas refinamos el objetivo y decidimos escribir un libro sobre métodos ágiles que cubriera el proceso completo de desarrollo de software.

Una de las motivaciones para escribir el libro fue que no existen en la actualidad (o al menos no han tenido mayor difusión) libros escritos en castellano sobre métodos ágiles que cubran el proceso de completo de desarrollo de software. Los libros existentes sobre esta temática escritos en castellano están enfocados en algún aspecto particular. Por ejemplo los libros de Martín Alaimo tienen un foco humano/de gestión, mientras que el libro de Carlos Blé está enfocado en TDD. Existe un libro que cubre en gran medida el proceso completo de desarrollo software llamado Scrum y XP desde las trincheras, pero es una traducción de una obra originalmente en inglés.

Al mismo tiempo, la motivación va más allá del idioma. Los métodos ágiles ponen un foco importante en las personas y en ese sentido creemos que la idiosincrasia latinoamericana merece un libro a medida escrito por latinoamericanos.

El libro, más allá de lo que el título pueda sugerir, es un libro de ingeniería de software. De hecho la mayoría de los contenidos son parte de la materia que dictamos con @pablitosuarez en UNQ.

Todos los autores somos docentes y también trabajamos en la industria, por ello creemos que el libro puede resultar muy útil como libro de texto para el dictado de una materia y para profesionales de la industria con intenciones de conocer y experimentar con métodos ágiles.

En los próximos días compartiré algunos detalles y curiosidades del libro, por el momento les dejo una de las imágenes del libro que más me gusta.

15.1

Desarrollo de software sin “métodos ágiles”

Algo que me ha llamado poderosamente la atención en los últimos años es encontrarme con gente que trabaja utilizando métodos ágiles y que sólo conoce de métodos ágiles. Cuando uno les pregunta como trabajaban antes de comenzar a utilizar métodos ágiles, en la mayoría de los casos indican que trabajaban totalmente ad-hoc o que utilizaban un proceso tipo cascada. Esto podría explicar en gran medida porque muchas veces se hace la comparación Agile Vs. Cascada como si no existiera nada más: hay gente no conoce nada más.

Pero existe algo más, de hecho existen muchas cosas más que son utilizadas con éxito en diversos contextos. Entre esas cosas uno podria citar el Proceso Unificado y el PSP por nombrar algunas. Al mismo tiempo hay una serie de prácticas muy asociadas a agile, pero que datan de mucho antes como ser versionamiento de código y la automatización de pruebas.

En relación a esta cuestión, con @dfontde, hemos enviado una propuesta de sesión a Agiles 2014 titulada “Hay buen desarrollo sin agilidad“.

Real-world TDD

El viernes pasado me tocó trabajar en una funcionalidad relativamente simple. Dada una aplicación de gestión de proyectos que tiene la capacidad de recibir mails (chiliproject) me pidieron que le agregue la capacidad de rutear los mails de entrada a uno u otro proyecto dependiendo de cierto algoritmo. Cuando estaba por empezar a desarrollarla pensé: “este es un excelente ejemplo para mostrar el uso de TDD en un contexto real”. Entonces abrí mi software de grabación y me puse trabajar. El resultado es este video que muestra cómo resolví parte del problema usando TDD. Espero lo disfruten.

Automatización de pruebas: principios, prácticas y herramientas

Finalmente, me hice un rato y mandé mi propuesta de sesión sobre este tema a Agiles 2014. Para quienes gusten darme feedback, pueden ver la propuesta completa en el sistema de call for papers de la conferencia.

Una cuestión que no está mencionada en la propuesta es qué fue lo que me llevó a proponer una sesión sobre este tema.

Como programador y sobre todo desde que me metí en el mundo Smalltalk, las pruebas unitarias automatizadas se volvieron un artefacto imprescindible en mi trabajo. Al ser Smalltalk un lenguaje de tipado dinámico no contaba con la (falsa) seguridad que proveen los compiladores en los lenguajes de tipado estático. Por esto me sentía obligado a escribir pruebas unitarias automatizadas para tener cierto nivel de seguridad de que no estaba rompiendo mi proyecto. Tiempo más tarde cuando comencé a trabajar en la implementación de la práctica de continuous delivery tomé conciencia de que con automatizar las pruebas unitarias y de componentes no era suficiente. Fue en ese momento que comencé a meterme gradualmente en las cuestiones de automatización de pruebas de aceptación de usuario. En ese sentido trabajé con Juan Gabardini en preparar un curso de automatización de pruebas y tiempo después comencé a trabajar con Pablo Tobia (alto tester) en el armado de una materia de testing que finalmente materializamos en el curso que dictamos en FIUBA. Al mismo tiempo para ganar más experiencia de campo logré meterme a trabajar como Software Engineer in Test en un proyecto de automatización de pruebas de un sistema de facturación. Todo esto me ayudó a ganar experiencia e incorporar muchísimo conocimiento sobre esta temática.

Como de costumbre, si la sesión es aceptada en Ágiles 2014, intentaré hacer una prueba previa en uno de los encuentros de la comunidad ágile@BsAs, mm, en realidad creo que la prueba lo voy a hacer igual más allá de que sesión sea aceptada en Agiles 2014 o no.

My Agile Assessment

Continuando con la cuestión del post anterior, quiero compartir en este post como suelo manejar el tema ante la consulta: ¿Como puedo medir mi nivel de agilidad?.  La respuesta viene en partes. La primera parte es lo que plantee en el artículo anterior. Luego de eso y asumiendo que llegamos a la conclusión de que lo que buscamos es agregar valor a la organización/negocio y que pretendemos hacerlo siguiendo el marco de referencia agile, podemos pasar entonces a la segunda parte [1].

Yo creo que la adopción de agile es básicamente la adopción ciertos mindsets y prácticas asociadas. Los mindset no son fáciles de incorporar pues son en un punto una cuestión cultural y como tal requieren de cambios profundos en algunos casos y de cierto tiempo de maduración. Por eso es que recomiendo familiarizarse con los mindsets, entenderlos y al mismo tiempo enfocarse en el uso de ciertas prácticas que facilitarán/guiarán la incorporación de los mindsets. Por su parte las prácticas son acciones concretas factibles de ser medidas, mejoradas e incorporadas gradualmente. Para entender proceso de adopción de prácticas suelo utilizar el siguiente cuadro [2]:

practicas_agiles

La división entre prácticas higiénicas y de orden superior está en cierta medida inspirada en la teoría de Maslow. En este sentido es preciso primero incorporar las prácticas higiénicas para luego poder sí avanzar sobre las prácticas de orden superior. La división entre prácticas técnicas y de gestión es bastante obvia pero no hay un orden preestablecido en cuanto su adopción, o sea, existe cierta independencia entre las prácticas técnicas y las de gestión. Ejemplo: uno podría incorporar TDD (práctica técnica) independientemente del uso de retrospectivas (práctica de gestión). Por otro lado resulta imposible la implementación de continuous delivery (práctica de orden superior) sin tener integración contínua (práctica higiénica).

Volviendo al punto inicial, si pretendemos identificar el nivel de adopción ágil, un camino posible sería identificar qué prácticas tiene establecidas el equipo/organización y en base a ello identificar un nivel “de madurez” para cada uno de los cuadrantes [3]. Una posible clasificación de niveles podría consistir en:

  • Pendiente: no se utilizan las prácticas
  • Básico: se utilizan algunas prácticas pero no todas las elegidas
  • Establecido: se hace uso consistente de las prácticas elegidas

 

practicas_madurz

Una vez identificado el nivel actual, debiera de definirse un plan de acción considerando los objetivos perseguidos por la organización, pero esto ya este tema de otro artículo.

 

 

 

 

 

 

[1] Si bien el mindset agile puede aplicarse a distintos contextos, yo me voy a limitar a la construcción de software pues ese es mi campo de trabajo.

[2] La confección de este cuadro puede ser un tema de debate en si mismo. Por ello las prácticas mencionadas en este cuadros son simplemente a modo esquemático, pues faltan muchas prácticas e incluso algunas de las presentes, es debatible si están ubicadas en el cuadrante correcto.

[3] ¡Ojo! no todas las prácticas son requeridas en todos los casos. Esa es una cuestión para analizar en cada caso particular. Es por esto que yo no mediría el nivel de madurez considerando el total de las prácticas sino sólo aquellas que sean relevantes para la organización.

 

Agile Assessment

En más de una ocasión me he encontrado con gente y organizaciones intentando determinar su nivel “de agilidad”.

Cada vez que oigo hablar de esto me asaltan inicialmente una serie de preguntas como ser:

  • ¿Que entiende esta persona por “nivel de agilidad”? o más básico aún ¿qué entiende por agilidad?
  • ¿Cual es el objetivo que se persigue al querer medir el nivel de agilidad?
  • ¿Es realmente la agilidad un fin como para medirlo o es en realidad un medio?

Entiendo que lo que suele denominarse agilidad es un filosofía, un marco de referencia, un sistema compuesto por un conjunto de principios, valores y prácticas estructuradas para alcanzar un fin. Me abstraigo por un momento de la agilidad en particular para reflexionar en forma más general.

Con el fin de alcanzar un objetivo X tomo un marco de referencia Z que me propone un enfoque determinado para llegar a X. Si asumimos como válido que cuánto “más fiel” me mantenga yo al marco de referencia Z  mayor serán mis probabilidades de alcanzar X, entonces tiene sentido comparar mi estado respecto de la propuesta de Z para así poder alinearme con Z y aumentar mi probabilidades de alcanzar el objetivo X.

Llevando esta tesis al caso particular de la agilidad tenemos que la agilidad es un marco de referencia para la entrega de valor a un determinado negocio/organización. En este sentido yo podria medir mi nivel de agilidad para identificar posibles acciones que me acerquen más al marco de referencia y así aumentar el valor que entrego a mi negocio/organización.

Si uno quisiera determinar su nivel de agilidad podria en primera instancia comparar sus principios y forma de trabajo con lo propuesto en el manifiesto ágil. Esto podría resultar un poco abstracto o incluso complejo para alguien poco familiarizado con la agilidad. De ahí la pregunta que dió origen a este artículo ¿existe un assessment para determinar el nivel de agilidad? Hasta donde conozco no existe UN assessment, pero si me consta que hay varias empresas de consultoría que ofrecen entre sus servicios un assessment de tal tipo. Un ejemplo es el ofrecido por Thoughtworks, que pude hacerse gratuitamente en forma online y que a partir de 20 preguntas organizadas en 5 dimensiones, ofrece un reporte con un conjunto de recomendaciones, seguido posiblemente del contacto de un representante de ventas.

Personalmente cuando alguien me pregunta cómo determinar su nivel de agilidad, mi respuesta…..

….la compartiré en otro artículo ;-)

Actualización: segunda parte

Agile no es para todo ni todos (Open Space UY 2014)

Continuando con el relato de este evento, la segunda sesión en la que participé me resultó especialmente interesante. No recuerdo el nombre de la persona que la propuso, pero la idea era analizar algunas situaciones debatiendo cómo enfrentarlas desde los métodos ágiles. Las tres situaciones planteadas fueron:

  1. Cliente ausente
  2. Cambio de prioridades constantemente en un proyecto Scrum
  3. Miembro de equipo mala onda/desmotivado y riesgo de contagio al resto del equipo

(si bien mi descripción es sólo de una línea, en la sesión se dió un poco más de detalle sobre cada una)
Una vez planteadas las situaciones empezamos a hacer una especie de brainstorming sobre posibles estrategias para afrontarlas. Para ponerle un poquito de picante a la sesión, pedí la palabra y sin pelos en la lengua dí “mi dictamen”:

Cliente ausente => no uses métodos ágiles

Agile no es para todo,  Agile no es una bala de plata y tampoco se puede aplicar siempre, hay casos en los que no se puede o no conviene usar agile. Puede que suene muy fuerte pero la experiencia me ha demostrado que para aplicar agile deben darse ciertas condiciones de las cuales tal vez la más importante sea el involucramiento del cliente. Si tu cliente está ausente, seguramente sea mejor utilizar un proceso más tradicional, con especificaciones detalladas, entrevistas formales de relevamiento y documentos firmados. O incluso tal vez sea mejor no hacer el proyecto (si es que esta opción está disponible). Si, suena extremo pero es como suelo manejarme y estoy contento.

Cambio de prioridades contastemente => Kanban

Si trabajas con Scrum y no logras “congelar” los requerimientos del Sprint backlog podrías en primer lugar intentar trabajar con iteraciones más cortas. Si eso no es posible o no funciona, entonces tal vez no debas usar Scrum sino hay más del estilo Kanban.

Miembro de equipo mala onda/desmotivado => agile no es para todos

No tengo una solución para esto, supongo que habría que consultar a un coach “humano”, yo estoy más del lado técnico. Lo que sí tengo en claro es que Agile no es para todo el mundo. Me gusta hacer la analogía entre Agile y la forma de juego del Barcelona. Si tienes un equipo con las características del Barcelona, puedes intentar jugar como el Barcelona y posiblemente obtengas buenos resultados, pero si no tienes un equipo así, tal vez debas buscar otra forma de juego. Con agile pasa lo mismo, si tienes un equipo autoorganizado, motivado y un proyecto agile-friendly, seguramente puedas aplicar agile y obtener buenos resultados, pero si tu equipo no es capaz de autoorganizarse y tu gente no está motivada, entonces tal vez sea mejor probar con otro cosa. Claro, si hablas con un “consultor agile”, difícilmente te diga esto. Al contrario, el “consultor agile” muy probablemente te proponga intentar transformar tu equipo. ¿Es posible tal transformación? Supongo que sí. ¿es fácil? Me parece que no. Pero de algo estoy convencido: si tal transformación es posible, es con el acompañamiento de un coach/consultor ágil.

Open Space UY 2014

Ayer estuve participando de un Open Space organizado por la comunidad ágil de Uruguay. El mismo se llevó a cabo en las instalaciones de la Universidad Católica de Uruguay.

La logística fue impecable, las instalaciones de la universidad resultaron muy adecuadas y el evento contó con varios sponsors lo que permitió contar con almuerzo y coffe breaks a pesar de tratarse de un evento gratuito.

Luego de unas palabras iniciales de Ariel (@scrumjedi), la facilitación del marketplace estuvo a cargo de @pablolis y el facilitación del cierre estuvo a cargo Martín Mari.

No tengo el número exacto de sesiones, pero había 4 slots horarios y unas cinco salas, por lo que estimo que debe haber habido unas 20 sesiones.

Gracias AgileUY, fue un gran evento y lo disfruté muchísimo.

PD: en los próximos días voy estar posteando sobre las sesiones en las que participé.