Por lo general, siempre leemos artículos sobre agilidad desde la experiencia de un Scrum Master o un Agile Coach, hoy lo vamos a ver desde la visión de un Arquitecto de Software que forma parte del equipo de Desarrollo.
Cada día que pasa, la agilidad sigue y sigue tomando más fuerza en el mundo. Las empresas grandes, medianas y pequeñas desean realizar diferentes actividades para obtener diferentes resultados mediante la agilidad.
Estas empresas están entendiendo que la agilidad aumenta la productividad por lo tanto están invirtiendo en capacitar a su personal en temas ágiles, en algunas metodologías ágiles como Scrum, Kanban, XP, entre otras. Sin embargo, la agilidad no solo implica capacitar, sino que se debe entender que es un cambio de mentalidad (mindset) más que algo que podemos aplicar para solucionar un problema.
Entonces, ¿qué involucra un cambio de mentalidad?
Significa olvidar todo lo que hemos aprendido hasta el momento, es decir, aplicar el comando ctrl+shift+supr a tu cerebro de tal manera que estés predispuesto a aprender nuevas cosas de muchas formas (como el término polimorfismo que significa implementar algo de muchas formas). Este cambio de mentalidad está asociado al aprendizaje de nuevas formas de trabajo, uso de herramientas, metodologías, dinámicas, etc.
Uno de los principales puntos a tener en cuenta al momento de aplicar agilidad es no cuestionar nada sino aceptar los conceptos y términos, (así como cuando descargas un software libre y aceptas los términos y condiciones) y si tenemos alguna duda, entonces, realizar las preguntas necesarias para absolver esta duda. Al comienzo es difícil comprender y aplicar agilidad, no solo es ponerlo en práctica y ya está, sino que es un proceso de aprendizaje diario por lo que es importante ir poco a poco y siempre realizar retrospectivas sobre lo aprendido, con la finalidad de saber qué es lo que está tomando mucho tiempo en aprender, en qué fallamos y qué cosas se pueden mejorar o hacer mejor.
Luego de ver las consideraciones necesarias para poder aplicar agilidad, veremos cómo es la óptica del arquitecto de software. Le sirve al arquitecto de software aplicar realidad o solo es humo.
En un post anterior de Arquitectura de software (puedes verlo aquí), revisamos los conceptos de patrones de arquitectura, atributos de calidad y que son importantes para definir una correcta arquitectura de software.
Recordemos que la arquitectura de software es el punto medio entre los requerimientos de negocio y la parte técnica. Entonces allí nos salta una pregunta muy sencilla: ¿Cómo hacemos esto en entornos con mucha incertidumbre?
Así como los requerimientos de negocio no están totalmente definidos y se van definiendo en el camino entonces la arquitectura de software pasa por lo mismo el mismo escenario.
Cuando trabajamos con agilidad, se tiene que definir el producto mínimo viable (MVP), esto normalmente lo define el equipo de UI/UX, el Product Owner y el negocio; y ¿cuáles son las labores del equipo de desarrollo como arquitecto, backend, frontend y calidad?
El equipo de desarrollo empieza trabajando en un trabajo previo. Algunos llaman a esto sprint 0, donde consideran todas las historias técnicas, aspectos, tareas y cosas que se necesitan como base para construir el producto que no necesariamente agregan valor al negocio, pero es indispensable tenerlo para empezar a construir funcionalidad para el negocio. SIn embargo, este término no es considerado dentro de Scrum, podríamos decirle simplemente pre-work. Son también conocidos como requerimientos no funcionales de inicio del proyecto.
En la imagen anterior se muestra que mientras el Product owner, UI/UX se reúnen con el negocio para definir el MVP y las funcionalidades que se van a incluir para el producto, el equipo de desarrollo liderado por el arquitecto empieza a trabajar en el «sprint 0» con algunas tareas como son definición de arquitectura, construcción de arquitectura base, construcción de ambientes, crear jobs automatizados, entre otras cosas.
En este trabajo previo, no se sabe con certeza qué funcionalidades se tendrá por lo tanto todas las historias serán técnicas e investigaciones de poder incluir algunas nuevas cosas como para aplicar seguridad a la aplicación, integración con otros sistemas, despliegues automatizados, como aprovisionar servicios en la nube, etc.
Luego que ya el MVP está definido, el equipo de desarrollo ya tiene una visión mucha más clara de lo que se requerirá para el proyecto, el arquitecto es aquel que traduce los requerimientos de negocio del MVP en parte técnica y a partir de la arquitectura base se empezará a definir módulos o paquetes para separar funcionalidades que la aplicación va tener. ¿Por qué se realiza esta tarea? Es necesario realizar esta tarea para poder construir código que sea escalable en el tiempo es decir que controlemos de manera efectiva la deuda técnica.
Deuda Técnica
La Deuda Técnica es el costo que asume el equipo y el negocio por escribir el código usando malas prácticas de programación. Estas malas prácticas se traducen en escribir código ilegible, utilizar nombres de variables incoherentes y difíciles de entender, redundar en el código, etc. En un equipo de trabajo siempre habrá nuevos integrantes y personas que abandonen en el equipo, entonces por lo tanto la deuda técnica tiene que ser lo menor posible para evitar retrabajos y los famosos refactorings.
Refactoring
Refactoring es el proceso que se realiza al código cuando se requiere mejorarlo y a la vez reducir su deuda técnica con la finalidad de seguir añadiendo más funcionalidad y no se incremente la deuda técnica.
La tarea de separar en módulos o paquetes la funcionalidad solo es el principio, pues se tiene que utilizar herramientas que validen la calidad de tu código frecuentemente antes de que termine cada sprint y así poder pasar código de calidad y disminuir nuestra deuda técnica. Las herramientas que se utilizan son sonar, PMD, checkstyle, Findbugs, SonarGraph y codeCity. Si deseas conocer más sobre calidad de código con sonar puedes revisar el tutorial de calidad de código creado aquí.
La tarea de separar en módulos o paquetes la funcionalidad solo es el principio, pues se tiene que utilizar herramientas que validen la calidad de tu código frecuentemente antes de que termine cada sprint y así poder pasar código de calidad y disminuir nuestra deuda técnica. Las herramientas que se utilizan son sonar, PMD, checkstyle, Findbugs, SonarGraph y codeCity. Si deseas conocer más sobre calidad de código con sonar puedes revisar el tutorial de calidad de código creado aquí.
Además, para asegurar que hemos escrito buen código, cada parte del código debería estar acompañado de una prueba unitaria para validar que lo que se ha escrito realmente haga la tarea para lo cual fue creado. Pueden leer los tipos de pruebas aquí.
Finalmente sabemos con certeza que la agilidad permite atacar inconvenientes o impedimentos de una forma mucho más rápida con los daily scrum, es allí donde el arquitecto debe adelantarse a estos inconvenientes teniendo en mente lo que va involucrar las historias de usuario de por lo menos de aquí a dos o tres sprints en adelante y así poder tener tiempo para mapear dependencias, restricciones, accesos de otros equipos, etc. y que estos no se conviertan en un cuello de botella a la hora de construir funcionalidad.
Conclusiones
- La agilidad es efectiva cuando tenemos entornos con mucha incertidumbre y es importante involucrar al arquitecto de software para que lidere el equipo de desarrollo a construir el sprint 0 y estar preparados para luego construir la funcionalidad sin ningún problema.
- El sprint 0 se definen historias técnicas, investigaciones y todos aquellos temas que nos ayuden a tener lo necesario para empezar a construir la funcionalidad que requiere el negocio.
- El arquitecto se encarga de transformar los requerimientos de negocio en parte técnica y es de suma importancia su labor para poder actuar en ambos lados, explicando al equipo de desarrollo que es lo que requiere el negocio en aspecto técnicos y explicar al PO y al negocio que es lo que necesita el equipo de desarrollo para cumplir las historias y si tienen impedimentos para avanzar.
- El arquitecto de software basándose en metodologías ágiles, se encarga de validar la calidad de código en cada siempre con la finalidad de evitar deuda técnica que se traducen en malas prácticas de creación de código.
- Cuellos de botella, impedimentos e inconvenientes siempre van a existir, si son técnicos, es labor del arquitecto de prever estas situaciones y si ya sucedieron, tener planes necesarios para resolver los mismos.
Si tienes preguntas cómo: ¿Qué es agilidad y por qué todos están hablando de eso? ¿Por qué yo (jefe/líder/analista/ejecutivo…) debo saber de agilidad? ¿Quienes hacen agilidad?… y sobre todo, si buscas respuestas a estas y otras preguntas, te esperamos en Agile Fundamentals, dale clic aquí y entérate de todos los detalles.
¡Nos vemos dentro!
Saludos.
Johana Chuquino
Johana Chuquino
Muchas gracias por compartir, me encanto el articulo.
Genial Theresa.