Reflexiones sobre metodologías de Desarrollo y el cumplimiento de los puntos de Historia

Hablar de Desarrollo de Software es sinónimo de evolución, una evolución a pasos agigantados que se nutre de la necesidad constante de entregar productos de software funcionales con calidad lo más pronto posible, reduciendo los tiempos de implementación y costos asociados. Es por ello, que desde la comunidad del software surgen variedad de soluciones para cumplir con la entrega pactada. Hablamos de lenguajes de programación que se especializan en tareas determinadas ya sea para frontend o para backend, otros más completos que son buenos en ambos frentes; otros son más útiles y versátiles para tareas de inteligencia artificial. En fin, con ellos evolucionan frameworks y paralelamente tecnologías que nos facilitan la vida y que nos dicen: “ocúpate de lo tuyo, que yo hago el resto por ti” como lo son la computación en la nube, contenedores, aplicaciones para despliegue y entrega continua, entre otras.

Adicionalmente, alrededor de todos los componentes técnicos mencionados anteriormente y aquellos que faltaron (gestores de dependencias, versionamiento de código, etc.) también evolucionan las metodologías y prácticas de referencia para llevar a cabo el ciclo de desarrollo de software y será en estas últimas que nos enfocaremos para analizarlas y ver cómo pueden convivir entre ellas generando valor.

Ahora bien, antes de entrar en materia fijemos unos puntos de referencia y conceptos para el desarrollo del presente contenido:

1. Veamos el ciclo de vida del desarrollo de software lo más abstracto posible y agnóstico a una metodología en particular, el cual inicia con una necesidad que requiere de una propuesta de solución, una implementación, pruebas, instalación, uso y mantenimiento. Adicionalmente, no lo vean como algo secuencial después de la identificación de la necesidad. De lo contrario, acabarán diciendo que acabo de definir un ciclo de vida en cascada, véanlo como algo más dinámico y con interacciones entre sí.

2. Una metodología se enfoca en el proceso y no en el resultado (aunque sí esperamos un buen resultado) es decir, el hecho de usar la metodología “A” porque es muy acogida y les ha dado resultado a otros, esto por sí solo no garantiza el éxito cuando la usamos nosotros.

3. Práctica es algo que hacemos de forma repetitiva aplicando técnicas y conocimientos adquiridos. Así que les dejo la primera inquietud: ¿TDD es una metodología o una práctica?

4. Según el estándar IEEE 830-1998, una buena especificación de requerimientos debe tener ciertas características:

• Corrección: La ERS (Especificación de requisitos del Sistema) es correcta sí y sólo si todo requisito que figura aquí (y que será implementado en el sistema) refleja alguna necesidad real. La corrección de la ERS implica que el sistema implementado será el sistema deseado.

• No ambiguos: Cada requisito tiene una sola interpretación. Para eliminar la ambigüedad inherente a los requisitos expresados en lenguaje natural, se deberán utilizar gráficos o notaciones formales. En el caso de utilizar términos que, habitualmente, poseen más de una interpretación, se definirán con precisión en el glosario.

• Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir todas las posibles respuestas del sistema a los datos de entrada, tanto válidos como no válidos.

• Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos contradictorios no es implementable.

• Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por importancia (esenciales, condicionales u opcionales) o por estabilidad (cambios que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear excesivos recursos en implementar requisitos no esenciales.

• Verificables: La ERS es verificable si y sólo si todos sus requisitos son verificables. Un requisito es verificable (testeable) si existe un proceso finito y no costoso para demostrar que el sistema cumple con el requisito. Un requisito ambiguo no es, en general, verificable. Expresiones como a veces, bien, adecuado, etc. introducen ambigüedad en los requisitos. Requisitos como “en caso de accidente la nube tóxica no se extenderá más allá de 25 Km” no es verificable por el alto costo que conlleva.

• Modificables: La ERS es modificable si y sólo si se encuentra estructurada de forma que los cambios a los requisitos pueden realizarse de forma fácil, completa y consistente. La utilización de herramientas automáticas de gestión de requisitos (por ejemplo, RequisitePro o Doors) facilitan enormemente esta tarea.

• Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la referencia de cada requisito a los componentes del diseño y de la implementación. La trazabilidad hacia atrás indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia delante de un requisito R indica qué componentes del sistema son los que realizan el requisito R.

5. Los requisitos se clasifican en:

a. Requisitos de usuario: recuerden lo primero del ciclo de vida propuesto. Estas son las necesidades verbales expresadas por el usuario.

b. Requisitos del sistema.

c. Requisitos funcionales: son servicios que debe proporcionar el sistema.

d. Requisitos no funcionales.

Entre las metodologías y prácticas definidas para el desarrollo de software surgen gran variedad de ellas. Respecto a las metodologías, en términos generales creo que estaremos de acuerdo en decir que hoy en día hablamos de “rígidas” y ágiles. Si pensáramos en una metodología de las que denominamos “rígidas”, yo pienso en RUP y en la cantidad de documentación que debía levantarse, pero, también pienso ¿Será que el rígido fui yo que no supe tomar solo lo que realmente necesitaba?. Si pensáramos en una metodología ágil lo primero que pienso es en Scrum, bueno les mentí, pensé primero en XP (la primera que conocí) y luego me pregunté, ¿Si la metodología es ágil, entonces el lento soy yo?, ¿Por qué no siempre cumplo con los puntos de historia?, ¿Será que estoy confundiendo velocidad con agilidad?, ¿Por qué las pruebas E2E automatizadas no se terminan dentro del mismo sprint?, o será aún más compleja la situación y es que sin importar la metodología usada ¿aún seguimos teniendo dificultades para identificar las necesidades de nuestros clientes?. Porque una cosa muy diferente es que una metodología sea más adaptable al cambio comparada con otras y otra cosa muy distinta es que teniendo las herramientas para identificar la necesidad del cliente nos sigamos equivocando. No quiero que piensen que esto último es una constante, solo que pueden pasar algunas veces.

Así que algo que comparto completamente con las metodologías ágiles como Scrum en que se centran en las personas y no en el proceso, porque somos realmente nosotros los ejecutores de la metodología (aunque si somos estrictos en las definiciones, una metodología ágil es un proceso diseñado para enfocarse en las personas y no en sí mismo, en fin, saltemos esta discusión) y de nuestros actos y decisiones depende el éxito de una metodología u otra.

Lo que no tiene discusión es que en la realidad actual el desarrollo de software está marcado por la capacidad de adaptación al cambio y en ella radica la diferencia en el nivel de competitividad de nuestros clientes ante sus competidores. Por ello, debemos rodearnos de marcos ágiles como Scrum y de metodologías y técnicas que se complementen para apoyar en conseguir los objetivos propuestos. Así que en esa búsqueda nos podemos encontrar con TDD, UTDD, BDD, ATDD, STDD, SBE y DDD. Sin embargo, podemos terminar confundidos por la variedad de significados que tiene la letra “D” en cada sigla. En mi caso, ya tengo suficiente curiosidad para saber qué tiene de especial la “D” en el nombre Monkey D. Luffy para sumar más letras “D” a mi lista. Por el momento les digo, si ven una “D” en metodologías orientadas al agilismo, por lo general habrá que automatizar.

Aclaro, que no entraré en detalle en las definiciones de cada una de las técnicas y metodologías mencionadas anteriormente porque cada una de ella es un mundo con una historia para contar y me centraré solo en puntos particulares y relevantes que nos permitan identificar cómo pueden convivir, generarnos valor y responder a la pregunta:

¿Por qué no siempre cumplimos con los puntos de historia?

Lo primero es remitirnos a la etapa uno de nuestro ciclo de desarrollo pactado: la necesidad, la cual es representada en forma de requisitos y de la calidad de estos dependen los resultados obtenidos al final de la implementación.

Así que sí no cumplimos existen diferentes causales asociadas al requerimiento inicial llámese caso de uso o historia de usuario:

• La historia era ambigua y construí lo que no era. Aunque siendo más específicos, lo que realmente fue ambiguo es la conversación previa para elaborarla y la HU es solo la tarjeta que nos recuerda la definición que hicimos del requerimiento.

• Era demasiado grande para hacerla en un sprint.

• Presentaba dependencias que no se alcanzaron a resolver durante el sprint.

• Testeable sí, pero la implementación tomó todo el sprint.

• Entre otras situaciones particulares a cada proyecto y equipo según su nivel de madurez.

Y si tenemos los causales anteriores en nuestros equipos, la respuesta a la pregunta: ¿aún seguimos teniendo dificultades para identificar las necesidades de nuestros clientes?... Es sí…, aún tenemos dificultades y la principal causa de esto es la forma en la que nos comunicamos.

Ahora bien, para cumplir con lo puntos de historia debo usar correctamente el instrumento escrito, el cual, debe ser: Independiente, Negociable, Valiosa, Estimable, Pequeña y Testeable (INVEST por su acrónimo en inglés) y así vemos que no importa la metodología, encontramos lineamientos que nos guían para definir correctamente un requerimiento.

En las metodologías ágiles hay un cambio significativo en cómo llegamos a definirlos. Nos encontramos en un escenario de responsabilidades compartidas. Si bien es cierto que el Product Owner es la voz del negocio y la expresa en historias de usuario, cada uno de nosotros desde el rol en que estemos, podemos aportar en el refinamiento de ellas.

Por lo anterior, el camino a seguir para cumplir con los puntos de historia comprometidos tiene como punto de partida una correcta identificación de la necesidad y para ello conozcamos cómo las “D” sientan la base para lograrlo.

ATDD sería una buena opción dado que su enfoque en criterios de aceptación basados en ejemplos resulta de gran utilidad para dar claridad sobre lo que se espera de la implementación de una historia con el aporte de cada rol del equipo. Al definir los criterios con ejemplos no solo se limita el alcance de lo que se debe implementar, sino que también se eliminan ambigüedades y se van estableciendo los escenarios de prueba a partir de ellos. Ahora te podrás preguntar: ¿Me estás diciendo que además de trabajar bajo Scrum ahora debo añadir sesiones adicionales para hacer sesiones de ATDD? La respuesta es no… Aprovecha el espacio de refinamiento para resolver tus dudas sobre las historias y pide que te den un ejemplo, si debes construir una interfaz gráfica toma un lápiz, un marcador, Paint o lo que tengas a tu alcance y pregunta: ¿así como esta imagen es que te imaginas la pantalla? y no que al final del sprint te digan que esa no es la pantalla esperada y debas construirla de nuevo y agregar un sprint de atraso. No digas que es un tema que debe resolver un equipo de experiencia de usuario y no tú. Tener este equipo sería ideal pero no siempre lo vamos a tener en todos los proyectos y si no están, debemos explorar nuestras habilidades para diseñar.

También puede pasar a escena BDD y ser otra opción para mitigar las causales mencionadas con anterioridad. BDD nos dice que tomemos el comportamiento del sistema como referencia, convirtamos cada comportamiento en una historia de usuario con ejemplos concretos representados con escenarios de un usuario en el sistema. Les suena familiar ¿ejemplos concretos? Finalmente, no son más que criterios de aceptación con ejemplos, lo mismo que se especifica en ATDD. Así que ¿ATDD y BDD son lo mismo? Podríamos entrar en la discusión y quizás unos piensen que son lo mismo y otros que no. Lo que sucede en realidad es que si seguimos adecuadamente BDD, deberías estar haciendo ATDD y TDD. Así que la pregunta no es ¿Son lo mismo? sino, ¿Estoy aplicando BDD de forma correcta?

Algo que no tiene discusión es que BDD y ATDD hacen énfasis en tener criterios de aceptación basados en ejemplos para eliminar ambigüedades, limitar el alcance y comprender lo que el cliente finalmente espera. Así que su objetivo es ayudarnos a mejorar la comunicación entre los miembros de nuestro equipo de trabajo y usarlas correctamente contribuye al momento de ser más acertados a la hora de estimar puntos de historia y cumplir con ellos.

En las metodologías “rígidas” sufríamos por el teléfono roto entre el negocio, el analista de requisitos, el tester y el desarrollador y a eso súmele la carga documental. Respecto a las ágiles, no hay excusa porque todos hacemos parte de las definiciones de las historias y si decidimos aceptar una sin la claridad suficiente, no es cuestión de metodologías sino de responsabilidad colectiva sobre las decisiones que tomamos.

Es claro que un factor determinante en la definición de un requerimiento (historia de usuario, caso de uso) es el lenguaje utilizado para comunicarnos. ATDD nos sugiere usar criterios de aceptación con ejemplos con el fin de lograr una mejor comunicación y entendimiento entre las partes, BDD también lo hace y agrega un lenguaje común con su “Given-When-Then”. Entonces, más que entrar en discusiones sobre comparaciones entre ellas, es ver más BDD como un paso más adelante de esa constante evolución del ecosistema del desarrollo de software y que contiene ATDD como lo mencione anteriormente, aportando la inclusión de un lenguaje común para las partes interesadas agregando también un patrón para la definición de una historia de usuario “As a – I want – So that”.

Siguiendo con las letras “D” salta a escena TDD, la cual es una práctica propia del desarrollador y podrás preguntarte ¿puedo usar TDD con ATDD/BDD? Claro que sí, porque cuando se trata de metodologías y prácticas lo primero que debes preguntarte es ¿cuál es su alcance y en qué momento me generan valor al usarlas? No importa qué metodología uses para definir los requerimientos, siempre podrás diseñar código a partir de las pruebas y si quieres usar “Given-When-Then” como estructura base para nombrar tus pruebas unitarias también puedes hacerlo. De esta forma, como efecto secundario de TDD estas agregando calidad a tu desarrollo, construyendo lo que se requiere y realizando un aporte significativo para cumplir con los puntos de historia.

Otro conjunto de letras es DDD (Diseño Guiado por el Dominio) y ¿Ahora qué? ¿Cuándo lo uso? Sin entrar en detalles sobre el concepto, con él se busca centrarse en el dominio del negocio y encontrar una mejor comunicación entre el negocio y tecnología con el fin alcanzar un entendimiento macro sin importar el rol que tengas dentro del proyecto. Así que puedes ver DDD en etapas de estructuración del proyecto y complementarlo con BDD y cualquier otra que genere valor. Tengamos en cuenta que las metodologías no son una camisa de fuerza que se deba seguir al pie de la letra, puedes tomar de forma consciente lo que te genere valor y combinarlo con otras. En mi caso, el rígido fuí yo en su momento, quería hacer todo al pie de la letra y el día a día te aterriza en que el mundo ideal no existe y que cada proyecto trae sus propios retos y necesidades particulares.

Entonces, hasta el momento he dicho que si queremos cumplir con nuestros puntos de historia debemos usar la familia de las “D” en el momento que corresponda a cada una de ellas, pero ¿usarlas será suficiente? La respuesta es no, depende del compromiso de cada uno de nosotros para convertirnos en un equipo ágil comenzando con pequeñas acciones para lograrlo y desde el camino que he recorrido comparto algunas que me han funcionado:

1. Entender que la calidad de un producto de software no es responsabilidad de un equipo de certificación, es responsabilidad de todos los que de una u otra forma somos dolientes del proyecto.

2. Evaluar el estado actual de nuestro equipo y ver cuales son las habilidades que se tienen y también las falencias para abordarlas. La metodología no te hace ágil, es la decisión de superarte cada día lo que va madurando el equipo.

3. Si un compañero requiere que lo apoyes con algo que sabes, saca el rato y comparte tu conocimiento, quizás lo que necesite esté en google pero le costará encontrarlo, tú lo puedes orientar. Así vas aportando a mejorar la velocidad del equipo.

4. Transmite los beneficios de la metodología que hayas elegido en términos del negocio como la reducción de tiempos de entrega y la calidad del producto obtenido a partir de la mejora en la comunicación y claridad sobre sus necesidades.

5. Pedir ejemplos sobre una funcionalidad genera espacios que favorecen la comprensión de la misma, no todo es tan obvio como parece y se facilita la identificación de escenarios que no se habían visualizado.

6. Las pruebas hacen parte del criterio de DONE, así que considera el tiempo para probar dentro del sprint. Si solo la implementación toma todo el sprint es porque quizás faltó limitar el alcance de la historia.

7. Las metodologías son puntos de referencia, los resultados dependen de quienes las ejecuten.

8. Un buen diagrama de actividades nunca sobrará, es una herramienta muy útil para entender el flujo que tiene determinada funcionalidad, hay quienes entendemos mejor desde una imagen que desde una narración verbal o escrita.

Así que, si queremos mejorar el porcentaje de cumplimiento de puntos de historia y la velocidad con la que hacemos entregas, ya sabemos que las metodologías están ahí y han demostrado ser útiles para mejorar el proceso de desarrollo de software.

En el caso particular de la velocidad, no es algo que se mejoré de la noche a la mañana, pues es en la medida que maduramos como equipo donde se verán las mejoras significativas, porque no se trata de la velocidad con la que escribimos líneas de código sino de la agilidad con la cual identificamos una necesidad y presentamos la propuesta de solución correcta. Por ello, insisto en invitarlos a asumir un compromiso con la calidad del producto y del proceso, somos los ejecutores los responsables de obtener resultados a partir de una metodología, elegir la adecuada dependerá del contexto en nos encontremos y más aún influyente es ¿Cuál se adapta mejor al proyecto que vas a iniciar?

Finalmente, lo que buscamos es entregar productos de software con calidad y a tiempo que satisfaga la necesidad del cliente, por tanto, para lograrlo debemos nutrimos no solo de conocimientos técnicos, también lo debemos hacer con nuestras habilidades interpretativas y sociales en pro de mejorar nuestra capacidad de comunicarnos.

¡Gracias por leer!