INTRODUCCIÓN
La industria del software es la industria más importante de nuestro tiempo [1], y está muy impactada por el ritmo de vida actual, que cambia cada vez más rápido.
Por ese motivo, requiere de prácticas que permitan producción continua de software, dentro de un ámbito de generación de valor incremental y permanencia de la calidad.
Si no se valida adecuadamente la calidad, pero se sale continuamente a producción, cada versión en lugar de aumentar el valor del activo (que es el software), lo está devaluando (generando deuda técnica).
Se requiere entonces un concepto metodológico de desarrollo que cumpla con la visión completa de la agilidad, como lo muestra Dan Leffinwell [2] en la siguiente gráfica:
“Evita las iteraciones “mini-cascadas”, a través de las iteraciones crossfuncionales.
Este artículo muestra el concepto de “Desarrollo Trenzado” como pilar fundamental de la metodología “Parex”, soportado por la plataforma “Enjisst”. Este concepto se puede aplicar dentro de las iteraciones, o incluso dentro de un flujo continuo Kanban. La aplicación de estos conceptos en diversos proyectos ha demostrado su efectivada para mejorar la calidad en mínimo un 70% y la velocidad de desarrollo en un 50% o más.
II. DESCRIPCIÓN
Para esto es necesario cambiar nuestros paradigmas, y dentro de ello modificar nuestro pensamiento de etapas a disciplinas. En desarrollo, la mayoría de equipos todavía piensa en las fases de requerimientos, desarrollo y pruebas, incluso como si fueran “mini-fases” dentro de la iteración.
Mientras mantengamos este paradigma seguiremos pensando en silos. Para explicar el paradigma tradicional pensemos en una carrera de relevos, que se compone de silos. Los silos son los pasos de la posta entre los atletas, en donde terminas los requerimientos para pasar la posta a desarrollo y luego termina la carrera las personas de pruebas.
Para pensar en agilidad es necesario cambiar de deporte: vamos a pasar del atletismo a un deporte de mayor interacción y agilidad como es el baloncesto.
Es de anotar que llamamos acá agilidad, la capacidad del equipo de responder ante el cambio, y de generar resultados de valor, en un deporte donde no se genera un solo valor (ganar la carrera), sino generar varios resultados de valor (anotar cestas).
En el baloncesto vamos a tomar roles: armador (base), aleros y postes (pivot); que utilizan una jugada llamada trenza. La trenza se caracteriza por:
· Busca rápidamente generar un resultado de valor (trenza)
· Los jugadores poco mantienen en sus manos el balón.
· Se hace interacción continua entre los jugadores.
· Los jugadores buscan recibir el balón en una posición que acerque hacia la cesta.
· Los jugadores corren detrás de los otros, para no afectar el envío del balón.
· Cada rol hace pequeñas carreras (dos pasos) pasando el balón a otro rol y recibirlo más adelante para nuevamente pasarlo pronto a otro rol.
En el “Desarrollo Trenzado” cada rol hace algunas actividades y pasa el balón a otro rol. Se hace de manera continua. A diferencia del baloncesto, el desarrollo trenzado es como si se jugara con dos o máximo tres balones.
Así en el momento inicial, el product owner (o rol de requerimientos) define una historia bien refinada y con apoyo de QA define el paquete de ideas y bocetos de escenarios de pruebas de una historia. Los escenarios de pruebas son base para el desarrollo y así el programador cuenta con los escenarios de base para diseñar el requerimiento, y así mismo la forma de ejecutar desde la perspectiva de sistema su desarrollo. Los desarrollos se van completando por escenarios de prueba. El QA recibe los escenarios (por paquetes) que va validando continuamente en ambiente de certificación según criterio. En esta certificación ejecuta pruebas de regresión, haciendo validación por el producto de software completo (no solo las historias). La certificación continua se puede tomar como el encestar, en este caso varios balones al mismo tiempo.
De forma continua el product owner acompañado con usuarios va validando el comportamiento del sistema, también por escenarios que se vayan entregando.
Este proceso es cíclico y continuo hasta que el paquete de historias haya concluido.
Así, el proceso de desarrollo fluye entre los tres roles principales: PO, QA y desarrollador, como una danza alrededor de los escenarios de prueba que están diseñados para evaluar el impacto de las historias de usuario, pero no para validarlas.
III. CONDICIONES
Una de las condiciones fundamentales en este manejo de escenarios es el pensamiento sistémico del producto de software, orientado a los escenarios completos de uso y validación del software para bajar el riesgo inherente al desarrollo. Se quiere ver reflejado un conjunto de escenarios básicos de uso y validación y todas sus variantes, la nueva forma de interactuar una vez se haya implementado la historia de usuario.
La segunda condición es contar con un mecanismo para automatizar pruebas rápidamente que siga el ritmo de “la jugada”.
Adicionalmente, la automatización en lenguaje de usuario permite que el equipo se pueda comunicar alrededor de las pruebas. Porque si el product owner, desarrollador o usuario tienen conflictos para el entendimiento de las pruebas automatizadas, no es posible llevar el “Desarrollo Trenzado” en la velocidad y fluidez requeridos para que este concepto lleve a la agilidad.
Por último, tener en el equipo el concepto de pruebas ágiles, en donde QA tiene como misiones “criticar el producto” y también “ser soporte al desarrollo”, como se ve en los cuadrantes de pruebas [3].
En esa medida, QA es un rol de colaboración, en donde sus habilidades de criticidad, visión de producto, identificación de riesgos entre otros, se ponen al servicio del equipo para la aplicación de las prácticas tanto de calidad como de agilidad.
IV. CONCLUSIÓN
El desarrollo trenzado que propone “PAREX”, apoyado con la plataforma “Enjisst” para la automatización rápida de pruebas en lenguaje de usuario y por perfiles no especializados, incluye los siguientes conceptos de calidad:
1. Definición de criterios de aceptación de requerimientos, basado en la definición de escenarios de pruebas.
2. Walkthrough con usuarios para la revisión informal de los requerimientos.
3. Shift-left-testing [4] como mecanismo para ejecutar pruebas funcionales y no funcionales en momentos muy tempranos del proceso de desarrollo
Unidos con conceptos de calidad como:
· Crossfuncionalidad que consiste en la habilidad del equipo que combina las ideas desde las diferentes disciplinas
· Roles T dado el aumento de capacidad del equipo de automatizar e interpretar las pruebas
· BDD: [5] y [6] Desarrollo dirigido por pruebas de comportamiento que lleva a la compresión del equipo a través de la definición del comportamiento por escenarios de validación
· ATDD: complementando la anterior definición, incluye la definición de las pruebas de aceptación
· Y la entrega continua de software funcionando
Por los motivos anteriormente expuestos, la combinación PAREX-Enjisst ha demostrado resultados impactantes que hicieron merecedores a los galardones: premio ingenio al caso de éxito de servicio y el premio al ingenio y la innovación.
V. REFERENCIAS
[1] D. Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, Kindle Edition ed., A. S. D. Series, Ed., Pearson Education.
[2] D. Leffingwell, SAFe® 4.0 Reference Guide: Scaled Agile Framework® for Lean Software and Systems Engineering., Edición de Kindle. ed., Pearson Education..
[3] C. Lisa y G. Janet., Agile Testing. A practical guide for testing and agile teams, Edición de Kindle ed., A. S. Series, Ed., Pearson Education..
[4] L. Smith, Shift-left Testing, Dr. Dobb’s Journal, vol. 26, no. 9, pp. 56–ff, 2001.
[5] N. S. A. S. A. &. C. R. Nascimento, «Behavior-Driven Development: An Expert Panel to evaluate benefits and challenges,» de SBES ’20, Natal, Brazil, 2020.
[6] A. Stellman y J. Greene, Learning Agile: Understanding Scrum, XP, Lean, and Kanban, O’Reilly Media, 2014.