La influencia de Agile en el uso de prácticas de desarrollo

Este el título del artículo de investigación que estaré presentando en Congreso Bianual de IEEE Argentina. Este artículo, cuya autoría comparto con Diego Fontdevila y Alejandro Oliveros, es parte del resultado de nuestra participación en la iniciativa HELENA Survey. La presentación será esta tarde en el bloque de 15 a 17 hs., la participación es gratuita pero requiere registración aquí.

En forma resumida encontramos que entre las prácticas de desarrollo más utilizadas, las prácticas de gestión/organización son prácticas que fueron introducidas por los métodos ágiles. Al mismo tiempo vemos que las prácticas técnicas más utilizadas son principalmente prácticas previas a los métodos ágiles pero que estos últimos han reconocido e incorporado. En cierto modo podríamos leer esto como lo que la industria tomó de Agile es principalmente técnicas de gestión/organización.

La publicación de este trabajo marca el cierre de una etapa en mi trabajo de investigación. Esta etapa que inició allá por 2016 estuvo enfocada en estudios de índole principalmente exploratoria sobre el uso de métodos ágiles de desarrollo de software. El año próximo continuaré trabajando en otra línea de investigación relacionada a la enseñanza de ingeniería de software (tema que ya vengo trabajando desde 2018) y comenzaré a trabajar en el estudio de prácticas de desarrollos de software.

La motivación de estudiar las prácticas concretas de desarrollo surge a partir de ver que muchos equipos no utilizan un método/enfoque/proceso particular sino que más bien utilizan algún tipo de “enfoque híbrido” que combina prácticas de diferentes enfoques/métodos/procesos. En particular me interesa estudiar experimentalmente dos prácticas: Pair-programming y Test-Driven Development.

Algunas reflexiones sobre Agiles 2020, la conferencia y la comunidad

Hace un par de semanas se llevó a cabo la conferencia Agiles 2020 y en ese contexto participé de una sesión de “historia” junto a algunos otros colegas del grupo organizador del primer Agiles allá por 2008. Agradezco a MaríaT y LinaP por haber tomado la iniciativa de armar la sesión. Mientras escuchaba hablar a algunos colegas en la sesión me fueron surgiendo algunas reflexiones que quiero compartir aquí.

Creo que nadie de aquel grupo de 2008 imaginaba que la conferencia llegaría hasta aquí: 13 ediciones consecutivas en 8 países de la región, 1 edición 100% online y una edición 14 confirmada para celebrarse en 2021 en Panamá (el noveno país anfitrión).

Una cuestión curiosa de esta continuidad es que se da sin que haya una organización formal ni un steering committee. A diferencia de otras comunidades no hay en Agiles un figura legal detrás de la organización. En el caso de Agiles Argentina está la Sociedad Argentina de Informática, pero no todos los países tienen una figura así. Año a año el grupo de organización es distinto pudiendo incluso ocurrir que de un año para el siguiente se renueve todo el equipo de organización. Esto tiene algunas cuestiones positivas y algunas otras no tanto. Entre las no positivas está el hecho de que potencialmente se pierda “conocimiento”, como ha pasado en más de una ocasión (y lo puedo decir con seguridad porque estuve ahí).

Es interesante que en el equipo organizador de este año no participó formalmente ninguno de lo “miembros fundadores” lo cual refuerza esta idea de renovación completa y continuidad. Esto lo digo sin tener una certeza absoluta ya que en la página de la conferencia no encontré ninguna mención al grupo organizador. (si estoy equivocado tal vez algún lector pueda corregirme).

Aquella primera conferencia de 2008, más allá de iniciar la tradición de la conferencia anual, dio origen a una comunidad que inicialmente tomó forma en un lista de correo de Yahoo! y que en algún momento de los últimos años “se mudó” a un grupo de Telegram que hoy en día cuenta con más de 1000 participantes.

A lo largo de todos estos años la conferencia fue variando en distintos aspectos entre los que a mi parecer se destacan dos: formato y temática. En términos de formato tuvimos conferencia tradicional (con convocatoria de sesiones), con keynotes, sin keynotes, con Open Space, sin Open Space, todo Open Space, etc. Realmente se han probado diversos formatos. En cuanto a temática, me animo a decir que igual que el manifiesto ágil, inicialmente hubo un foco en desarrollo de software que en los últimos años fue inclinándose hacía cuestiones más generales de “agilidad”. Lo mismo pasó con la comunidad, donde hoy en día participa gente que no tiene relación con el desarrollo de software. Un hecho en relación con este cambio es el cambio de nombre de la conferencia: inicialmente la habíamos bautizado como “Conferencia Latinoamericana de Métodos Ágiles, Agiles XX” y en algún momento de los últimos años (no puedo precisar cuando) pasó a ser “Jornadas Latinoamericanas de Agilidad, Agiles XX”.

Personalmente participé de 10 de ediciones y en 3 ocasiones forme parte del grupo organizador. A lo largo de todo este tiempo mi participación y sentido de pertenencia a la comunidad ha ido variando como consecuencia “del match de expectativas”. Personalmente mis inquietudes, gustos e intereses pasan por el desarrollo de software y no me despierta mayor interés hablar de “Agilidad” en otros contextos. Es por ello que en el último tiempo me he sentido más afín con otras comunidades, conferencias y espacios de intercambio. Me consta que algunos otros colegas comparten este pensamiento y ello ha planteando cierto debate sobre si Agiles es un espacio de intercambio para gente del desarrollo de software y más particularmente para gente de perfil más técnico. Algunos colegas como AndresJ cree que sí, yo cada vez tengo más dudas. Sin embargo debo admitir que en este último Agiles me encontré con varias sesiones relacionadas al desarrollo de software que me resultaron muy interesantes.

Para cerrar esta reflexión les comparto una foto de la remera que habíamos hecho para el grupo organizador de Agiles 2008 que aún tengo en mi guardarropa.

Para los interesados en repasar la historia y la evolución de AgilesXX pueden encontrar aquí los distintos artículos al respecto que he escrito a lo largo de todos estos años.

“Good enough” Software Engineering

Por estos días me encuentro leyendo el libro “Software Craftsmanship: The New Imperative” de Pete McBreen. Es un libro que tiene casi 20 años y que a mi entender no ha tenido gran difusión. De hecho yo lo encontré por casualidad. No es mi idea en este artículo resumir el libro sino simplemente detenerme en esta idea de “Good Enough Software Engineering” que es una de las ideas que menciona el autor en la primera parte del libro y que recientemente me resonó mucho a partir de un intercambio de mensajes con mi colega Carlos Peix.

McBreen pone en tela de juicio el “enfoque formal” propuesto por la ingeniería para el desarrollo de software. Argumenta que la ingeniería de software resulta sin duda un enfoque apropiado para ciertos tipos de sistemas que implican el desarrollo conjunto de hardware + software y que ponen en juego la vida humana. En este sentido menciona proyectos militares y aeroespaciales. Sin embargo cree que el enfoque de ingeniería de software no es apropiado para el desarrollo de lo que llama “software comercial”, cuyo desarrollo no requiere del desarrollo de un hardware particular y que no pone en juego vidas humanas, pero que tiene ciertas restricciones de mercado. Dicho de otra forma: los trade-offs que pueden hacerse en cada uno de estos dos tipos de proyectos son distintos y eso da lugar a distintos enfoques. Según MeBreen el desarrollo de software comercial va mejor con un enfoque de “good enough software” que con un enfoque de “Ingeniería”.

Creo que somos varios a los que nos resuenan estos cuestionamientos que hace McBreen. De hecho recuerdo un artículo de David Parnas publicado en IEEE Software: Software Engineering – Missing in Action: A Personal Perspective, en el cual también se cuestiona el enfoque de ingeniería para el desarrollo de software. McBreen insiste en que para muchos contextos (la mayoría según él) hay enfoques más apropiados que el de ingeniería de software. Más aún, cree que hay varios enfoque posibles pero se inclina a hacia un enfoque de “artesanía”.

Estas reflexiones plantean interesantes dilemas para practicantes y académicos. Como practicantes debemos entonces ante cada nuevo proyecto decidir que enfoque utilizar. Como académicos aparecen algunos cuestionamientos profundos:

  • ¿está bien que las carreras de informática sean ingenierías o deberían ser licenciaturas y de esa forma despegarse de la “carga conceptual/cultural” que la ingeniería impone?
  • ¿es posible/conveniente cubrir dentro de una misma carrera enfoques de ingeniería y de “no ingeniería”?
  • ¿deberíamos tener carreras más específicas en línea con distintos enfoque de desarrollo?

Mi sensación es que en la actualidad muchas carreras, independientemente de su nombre, proponen un enfoque ingenieril pero luego una importante porción de sus egresados terminan trabajando en proyectos que podrían resultar más afines a un enfoque de artesanía.

Un detalle importante aquí es que un enfoque de ingeniería no es más completo ni abarcativo que un enfoque de “no-ingeniería” sino que es divergente. Esta divergencia que yo veo no es necesariamente conceptual sino “operativa” en un punto: las carreras tienen un límite de tiempo, enseñar un enfoque de ingeniería trae de entrada toda una base de conocmiento que reduce el espacio/tiempo para estudiar otras cuestiones. Esto queda muy en evidencia cuando en la actualidad vemos “ingenieros de software” que no buenos desarrolladores. Mi percepción es que muchas de las carreras actuales de “Ingeniería” (más allá de que sean formalmente ingenierías o licenciaturas) no forman buenos desarrolladores.

En fin, creo que este tema da para mucho, continuaré.

Estilos de TDD: London vs. Chicago

Hace un tiempo cobró cierta popularidad entre los practicantes de TDD el debate sobre los denominados estilos o escuelas de TDD: “London” y “Chicago”. Hay varias explicaciones en la web sobre las diferencias de estos estilos ([1][2][3][4]) que podríamos resumir brevemente en dos dimensiones:

  • Flujo
    El estilo Chicago (también denominado “tradicional”) propone un desarrollo de adentro hacia afuera, se comienza por los objetos del dominio y luego se agrega la capa de interface/controllers.
    El estilo London propone un desarrollo de afuera hacia adentro, lidiando de entrada con las cuestiones de interface/controllers y llegando a los objetos de dominio a partir de las necesidades que la interface/controllers nos va demandando.
  • Aserciones:
    En el estilo Chicago los tests hacen asserts sobre el estado de los objetos y los resultados.
    En el estilo London los tests están más enfocado en la interacciones entre los objetos y para ello depende en gran medida del uso de mocks.

Estos dos estilo dieron un salto de popularidad a partir de una serie de videos realizados por Bob Martin y Sandro Mancuso. En estos videos Bob (Chicago) y Sandro (London) muestran y comparan el desarrollo de una aplicación (Rest API) utilizando estos dos estilos.

Al estilo Chicago se lo suele asociar al libro Test-Driven Development by Example de Kent Beck mientras que al estilo London se lo suele asociar con el libro Growing Object-Oriented Software Guided by Tests de Freeman y Pryce. Sin embargo, a mi parecer, comparar los enfoques London y Chicago a partir de estos dos libros me parece errado porque el alcance y foco de las propuestas descriptas en estos libros es distinta. El libro de Beck es un libro que tiene un foco claro en el uso de TDD a nivel del modelo de objetos de dominio. Por su parte, el libro de Freeman tiene un foco es más amplio, apunta al proceso de desarrollo de una aplicación (no solo del modelo de objetos de dominio). Es así que el libro de Freeman contempla también cuestiones como arquitectura hexagonal, walking skeleton e integración continua. Tengamos presente que el libro de Beck es de 2003 mientras que el de Freeman es de 2009. Al mismo tiempo en su perspectiva de desarrollo de una aplicación, el libro de Freeman plantea un doble ciclo de tests donde el ciclo interno es el que coincide con el ciclo de TDD que plantea Beck. Es por esto que no creo que sea Freeman o Beck, sino que los veo como complementarios.

Volviendo a London vs. Chicago, un punto central en la discusión es el uso de mocks. Si solo pensamos TDD para el desarrollo del modelo de objetos de dominio puede que el uso de mocks no resulte útil. Pero si ampliamos el foco de la discusión y consideramos el desarrollo de una aplicación completa incluyendo las cuestiones de “infraestructura” (interfaces, persistencia, etc.), entonces los mocks toman otra relevancia/utilidad.

Continuará…

[1] https://josemyduarte.github.io/2018-12-09-tdd-outside-in/
[2] https://devlead.io/DevTips/LondonVsChicago
[3] https://dev.to/hiboabd/a-beginners-explanation-of-the-chicago-london-approaches-4o5f
[4] https://nvoulgaris.com/comparing-tdd-flavours/


Sobre mi sesión de trunk-based development @ Agiles2020

En lunes pasado presenté mi sesión sobre Trunk-based Development en Agiles 2020. La presentación fue vía Zoom pero como al finalizar el tiempo estipulado aún quedaban algunas cuestiones por hablar, la continuamos por Jitsi. Participaron unas 50 personas y yo personalmente quedé muy conforme con como salió la sesión.

Hay una cuestión que salió durante la charla y que no deja de llamarme la atención al hablar de modelos de branching. Hay gente que cree que tener un repositorio centralizado y un build server es hacer integración continua. Pues no, no lo es, no es suficiente pues la práctica de integración continua implica que adicionalmente todo el código debe ser integrado al menos una vez al día. Cuando digo integrado me refiero a integrar en un mismo branch todo el trabajo en curso. Esto es algo básico que está explícitamente mencionado en el clásico artículo de Fowler sobre Integración Continua como lo muestra la imagen a continuación:

Hacer Feature branches puede o no ser integración continua dependiendo de la duración de esos branches. Si los branches viven a lo sumo 1 día, está ok. En fin, es un tema que me resulta importante y en breve le dedicaré un artículo en profundidad.

Finalmente quiero agradecer a la organización de Agiles 2020 por haberme invitado a presentar y también a los participantes que se sumaron a la sesión. Les comparto aquí las diapositivas utilizadas en mi sesión.

Egreso online de Ingeniería en Computación @ UNTreF

El miércoles pasado asistí a una defensa de trabajo final de carrera en modalidad online. El ponente fue Gonzalo Cozzi, quien presentó su trabajo final para obtener el título de Ingeniero en Computación de la Universidad Nacional de Tres de Febrero. Los jurados evaluadores fueron Carlos Fontela, Diego Fontdevila y Diego Marcet. También estuvo en la defensa el director de la carrera Alejandro Oliveros. Yo participé en la presentación en calidad de director del trabajo presentado.

La presentación de Gonzalo fue muy sólida, ordenada y en tiempo. Los jurados felicitaron a Gonzalo por el trabajo realizado. Yo como director del trabajo también quedé muy satisfecho, tanto con el resultado como con todo el proceso de trabajo.

El trabajo en cuestión consistió en el desarrollo un radiador de información incluyendo una solución integral de software y hardware y soportando distintas arquitecturas de despliegue:

  • SmartTV + Cloud
  • SmartTV + Raspberry Pi
  • TV/Monitor + Raspberry Pi

El software está desarrollo con una arquitectura hexagonal, la cual a partir de un modelo de ports and adapters permite integrar distintas herramientas de una habitual con los proyectos de desarrollo. Out-of-the-box hay soporte de conectores para GitHub, GitLab, Redmine y Travis-CI.

Todo el código del proyecto está disponible en GitHub bajo licencia GPL-V3.

Algunos punto interesantes para destacar de este trabajo:

  • Se buscó proveer una solución integral contemplando software y hardware.
  • El trabajo está publicado con licencia de código abierto.
  • El trabajo está desarrollado de forma tal que permite muy fácilmente incorporar extensiones lo cual puede significar un oportunidad interesante para trabajos finales de otros alumnos (interesados no duden en contactarme).
  • Adicionalmente a la presentación formal de trabajo en la universidad, el mismo también fue presentado en un congreso de ingeniería.

¡Felicitaciones Gonza!

Abajo (los jurados): Carlos, Diego y Diego
Arriba: Nico, Alejandro y Gonzalo

Efectos colaterales de TDD

El uso de TDD (desarrollo guiado por la pruebas) tiene varios efectos colaterales, a mi criterio, la mayoría de ellos positivos. Algunos de ellos son evidentes y ampliamente conocidos, pero algunos otros suelen pasar desapercibidos.

Uno de estos efectos colaterales las pruebas y el código de prueba pasan a ser ciudadanos de primera categoría. Esto es así porque el desarrollo arranca con las pruebas y eso hace que el código de las pruebas sea una herramienta central para pensar nuestro diseño. Antes de escribir una funcionalidad la vamos a estar describiendo en una prueba, eso concretamente implica que en la prueba escribiremos invocaciones a métodos y objetos que aún no hemos creado. Esto no ocurre cuando escribimos las pruebas a posteriori. El hecho de que las pruebas sean un ciudadano de primera categoría implica que el código de prueba debe ser tratado con el mismo cuidado que el código de producción, esto es: debe ser mantenible, cumplir las convenciones y sobre todo ser claro y evitar duplicaciones. Ojo, no es que al escribir las pruebas a posterior no debamos cumplir con esto, pero al hacer TDD estas propiedades del código de prueba toman mayor relevancia porque el código tiene un protagonismo distinto.

Al mismo tiempo, como no escribiremos código de producto sin tener primero una prueba, es común que la cantidad de pruebas sea mayor que si escribimos pruebas a posteriori (no tengo evidencias formales de esto, es más bien una sensación basada en lo que visto tanto con mis alumnos como con mis clientes). Cuantas más pruebas tenemos, más importante es la claridad y mantenibilidad del código de prueba. Curiosamente y un poco a contramano de esto, suele ocurrir que al agregar nuevos casos de prueba sobre una funcionalidad existente, muchas veces comenzamos “copy&pasteando” el código de prueba del caso anterior. Esto en principio genera código duplicado y ahí la importancia de hacer refactoring sobre el código de prueba. Personalmente me pasa que a partir de cierto punto, siento que hago mucho más refactoring sobre el código de prueba que sobre el código de producción. Más aún, cuando la aplicación alcanza cierto tamaño o grado de complejidad los refactorings sobre código de prueba llevan a generar clases/métodos “de soporte” por ejemplo para generar objetos/datos de prueba. En línea con esto me parece que no es casualidad que el libro de Gerard Meszaros tenga como subtítulo “Refactoring Test Code“. También los libros de Tarlinder y Freeman tienen capítulos dedicados al cuidado del código de prueba.

A propósito de este tema, el próximo jueves 12 de noviembre voy a estar dando una charla en la conferencia dotnetconf 2020 en la que compartiré algunas técnicas para mejorar la legibilidad de tests en C#: Enhancing Test Readability with Extension Methods and Fluent Interfaces.

Sobre mi taller de Git en Nerdearla 2020

Ante todo: ¡Zarpado evento Nerdearla 2020!

En este año de pandemia he participado de varias conferencias online pero ninguna estuvo ni cerca de Nerdearla, ni a nivel contenido, ni a nivel producción, ni a nivel interacción (y eso que Nerdearla aún no terminó). Simplemente mis felicitaciones al equipo organizador.

Ahora sí, el taller. En la sala de zoom había unas 40 personas que era el límite establecido, pero en paralelo la sesión fue transmitida por YouTube y por la página de la conferencia. Según me comentó uno de los organizadores llegó a haber más de 250 personas viendo la transmisión.

Al iniciar el taller hice dos preguntas a la audicencia en parte para validar algunas “creencias mias” y en parte para entender mejor a la audiencia. Para esto utilicé la herramienta mentimeter. En primer lugar les pregunte si habían utilizando alguna otra herramienta de versionado más allá de Git. Resultó que aproximadamente la mitad de los que contestaron solo habían trabajado con Git, en un palabra los podríamos calificar como “nativos git”.

Luego pregunté sobre la forma habitual de utilizar Git en el sentido de que qué tipo de herramienta utilizan. Resultó ser que la gran mayoría (~70%) indicó utilizar la terminal. Esto me sorprendió pues pensé que por la forma en que estaba anunciado el taller, me encontraría con mucha menos gente utilizando la consola y mucha más gente utiliza el IDE.

Personalmente me quedé muy conformé con el taller y hubo varios de los participantes que me manifestaron los mismo. Agradezco a todos los que participaron y también a Aixa por haberme asistido en la logística del taller.

Comparto algunos recursos:

Colaboración Universidad Pública y Estado: un potencial círculo virtuoso

El estado invierte en la universidad pública. Por su parte la universidad educa a los ciudadanos, hace investigación y genera conocimiento que ayuda a mejorar la sociedad. Esta mejora se traduce (indirectamente) en una mejora del estado y así se cierra un circulo virtuoso.

En el área de informática/computación/sistemas creo que se da una situación en la que este circulo virtuoso no resulta tan virtuoso, o al menos no todo lo virtuoso que podría resultar.

Más allá de mi trabajo en la universidad, llevo casi 20 años trabajando en la industria del software, he sido empleado de distintas empresas privadas y en los últimos años he trabajado de manera independiente. Nunca fui empleado de un organismo estatal (más allá de mi trabajo en la universidad) pero como empleado de una empresa privada he trabajado en proyectos de consultoría y capacitación para organismos estatales. Proyectos que perfectamente podría haber realizado una universidad. Al mismo tiempo tengo muchos colegas en situaciones análogas. Esto me ha disparado una pregunta recurrente: ¿porque está una empresa privada haciendo este proyecto y no una universidad pública?

Es aquí donde veo que el círculo virtuoso Estado-Universidad no es todo lo virtuoso que podría ser. Si los organismos estatales contrataran a universidades públicas, estas podrían tener más presupuesto, una cuestión siempre escasa en las universidades Argentinas. Al tener más presupuesto podrían hacer más investigación, o mejorar diversos aspectos de su operatoria y en un última instancia aportar más valor a la sociedad.

Intentando dar respuesta a la pregunta planteada comparto aquí algunas posibles respuestas que se cruzaron por mi cabeza:

  • La universidad no tiene el conocimiento para dar servicios a terceros. No lo creo. Si efectivamente fuera así, entonces tendríamos un problema muy grave. Pero sinceramente no lo creo. Muchos docentes universitarios del área de informática trabajan en la industria y enseñan en la universidad justamente lo que ponen en práctica en la industria (es mi propio caso y el de todo mi equipo docente).
  • La función de la universidad no es dar servicios a terceros. Falso, la universidad (al menos en Argentina) tiene 3 funciones: docencia, investigación y extensión. El prestar servicios a terceros es una actividad de transferencia que puede enmarcarse perfectamente dentro de actividades de investigación y/o extensión.
  • Las personas de la universidad que podrían brindar servicios a terceros prefieren hacerlo en forma privada que por medio de la universidad. Este sí puede ser un tema. Las diferencias salariales en el área de informática entre la universidad y lo que paga el sector privado pueden ser muy relevantes. Sin embargo, según he estado averiguando, hay alternativas que podrían habilitar que los docentes que trabajen en brindar servicios a terceros puedan recibir una remuneración equiparable a lo que podrían ganar desde el sector privado.

Ojo, con esto no estoy diciendo que la universidad tenga que convertirse en una software factory o en un proveedor de servicios de manpower vendiendo “programador por kilo”. Sino que los tipos de trabajos en los que imagino a la universidad, son trabajos de capacitación, consultoría o proyectos de desarrollo con un alto componente investigación/innovación.

Me consta que en algunos casos de algunas universidades y algunos organismos, esta colaboración fluye exitosamente, pero no es el caso común.

Creo que revertir esta situación requiere de un acuerdo de las 3 partes: las universidades, los organismo estatales y los docentes/profesionales.

Estoy bastante convencido de esta idea del círculo virtuoso de colaboración Estado-Universidad y es por ello que ya estoy gestionando para participar de un proyecto de colaboración entre la universidad y un organismo estatal durante el año próximo. Continuará…

#HistoriaDeTrinchera: Planning de una User Story

Recurrentemente hablo con gente que me comenta de sus dificultades para completar el trabajo planificado en la iteración. En muchos de esos casos mi sensación es que el equipo incluye funcionalidades en su iteración sin tener suficientemente en claro su implicancia. Creo que muchos se han ido del extremo de especificar cada detalle de la funcionalidad en un documento tipo especificación de casos de uso, a directamente pasar al otro extremo y escribir un título y nada más. Es por esto que quiero compartir en este artículo el ejercicio que intentamos hacer en mi proyecto actual a la hora de armar nuestro backlog de iteración determinando las funcionalidades que trabajaremos.

Una de las particularidades de nuestro proyecto es que como parte del equipo tenemos una especialista en diseño de experiencia usuario (digo particularidad pero me parece que esto es cada vez más común). A su vez esa especialista es en simultáneo parte de otro equipo que trabaja en forma transversal en el diseño de la experiencia de varios productos de la organización. Es así que las funcionalidades (que usualmente llamamos user stories) se piensan desde un momento muy temprano teniendo presente la experiencia que se quiere ofrecer al usuario. De esta forma, cuando hablamos sobre una funcionalidad en una reunión de planificación generalmente ya contamos con un diseño de pantalla (o tal vez varias) que acompañan la conversación.

De la conversación sobre la user story buscamos esclarecer los siguientes puntos para poder agregarla al backlog de la iteración:

  • El escenario principal de uso y alguno de los escenarios alternativos más importantes. De ser posible, y si la complejidad lo amerita, ahi mismo expresamos estos escenarios en sintaxis Gherkin.
  • Las tareas necesarias para completar la story como ser: codear la pantalla, codear un nuevo servicio, codear componente para conectar con otro sistema, generar los datos de prueba, automatizar la prueba end-2-end, etc, etc
  • La dependencias de otras aplicaciones/apis y estados de las mismas (esa API que debemos consumir ¿ya está disponible en producción? ¿la está consumiendo algún otro equipo?)
  • La necesidad (o no) de hacer que la funcionalidad sea “apagable” o “segmentable”. Hay funcionalidades que son simples y de baja criticidad que apenas las terminamos pueden ser liberadas al público en general, pero hay otras que, ya sea por su complejidad o criticidad, se prefiere liberarlas gradualmente a distintos grupos de usuarios. En términos técnicos pretendemos identificar si la funcionalidad debe ser “toogleable”.

A medida que vamos viendo cada una estas cuestiones vamos tomando conciencia del tamaño y la complejidad de la funcionalidad y puede que en base a ello decidamos partir la funcionalidad en varios cortes (lo que comúnmente se conoce como slicing).

En algunos casos parte de estas cuestiones se hablan en una reunión de refinamiento que ocure previamente a la planning. A su vez dicha reunión nos permite identificar potenciales blockers para el desarrollo de alguna funcionalidad pedida. En algunos casos también ocurre que la funcionalidad pedida depende de funcionalidades provistas por alguna API desarrollada por otro equipo y que no se encuentra disponible aún o tal vez no provee todo lo que necesitamos. En estos casos en lugar agregar la funcionalidad en cuestión a nuestra iteración, agregamos una tarea de gestión para darle seguimiento a al desarrollo de esa API e incluso hacer algún prueba de concepto como para ir familiarizándonos.

Dos datos adicionales de contexto:

  • En las reuniones de refinamiento no participa necesariamente todo el equipo. Seguro están los especialistas de negocio, la especialista en UX, el facilitador y algunos devs. En general esta reunión dura 1 hora.
  • Las reuniones de planificación tiene 2 partes: una estratégica donde participa todo el equipo y una táctica donde solo participan los técnicos (devs & testers). Entre ambas se van entre 2 y 3 horas.

A partir de lo anterior resulta que para planificar una iteración de 2 semanas este el equipo requiere en total de unas 4 horas de trabajo conjunto.

Algunas de estas cuestiones puede que no coincidan exactamente con lo que recomiendan algunos libros y posiblemente a algunos lectores puede que le resulten impracticables en su propio contexto y lo entiendo. No es mi intención convencer a nadie de trabajar de esta de esta forma, simplemente pretendo compartir lo que a nosotros nos viene funcionando y nos permite entregar software todas las semanas.