Background Image
ÁGIL

Scrum consciente

January 31, 2024 | 5 Minuto(s) de lectura

De vez en cuando, he pensado en la mejor manera de pagar la deuda técnica en un proyecto de software basado en Scrum. Dos maneras de hacer esto siempre vienen a la mente: el enfoque de la historia técnica y el enfoque mientras estás en ellos.

El enfoque de la historia técnica es bastante sencillo. Documentamos el elemento de la deuda técnica que debe abordarse en una historia de usuario, pero en lugar de llamarlo una historia de usuario, lo llamamos una historia técnica. Esta historia técnica puede priorizarse junto con las historias de usuario.

El enfoque mientras estás ahí dice que si estás trabajando en algún código para una historia de usuario que resulta tener deuda técnica en ella, paga esa deuda técnica durante el curso de la implementación de la característica descrita en la historia de usuario.

A lo largo de los años, he pasado de favorecer el enfoque de la historia técnica a apoyar el enfoque mientras estás en ella. El motivo es que cada historia de usuario debe aportar valor a la parte interesada. La parte interesada mencionada en la frase anterior es, por supuesto, el usuario final representado por un personaje, y el usuario final no ve directamente ningún valor en una historia técnica. Así que pagamos la deuda técnica en nuestro código mientras estamos ahí implementando una historia de usuario.

La mayoría de las empresas tienen la misma visión que la mayoría de los proyectos de software con respecto a las partes interesadas: hay un tipo de parte interesada. Para los proyectos de software, es el usuario final, y para las empresas, es el accionista. ¿Existe realmente un único tipo de parte interesada para los proyectos de software y las empresas? Uno de los principios fundamentales del Capitalismo consciente es que reconociendo que una empresa tiene múltiples tipos de partes interesadas y aportando valor a todas ellas, las empresas pueden lograr un mayor éxito y tener un impacto más positivo en el mundo.

Thumbnail - Conscious Scrum

No voy a ofrecer aquí una tesis sobre el Capitalismo Consciente, pero sí voy a mencionar que la empresa para la que trabajo, Improving, practica el Capitalismo Consciente, y nuestro CEO Curtis Hite forma parte del consejo de administración. Merece la pena enumerar sus creencias fundamentales:

1. Propósito superior. Las empresas deben existir para un propósito más elevado, no sólo para obtener beneficios.

2. 2. Orientación a las partes interesadas. Reconocer que una empresa tiene múltiples tipos de partes interesadas, y necesita crear valor para todas ellas.

3. 3. Liderazgo consciente. Los líderes conscientes comprenden y adoptan el propósito superior de una empresa y se centran en armonizar los intereses de todas las partes interesadas.

4. 4. Cultura consciente. Una empresa necesita desarrollar intencionadamente una cultura que promueva sus valores y su propósito de forma que conecte a su gente y a las partes interesadas.

¿Qué pasaría si aplicáramos los principios del Capitalismo Consciente a un proyecto Scrum? Llamémoslo Scrum Consciente.

Un proyecto de Scrum Consciente tiene un propósito más elevado, alineado con el negocio, que impulsa su existencia y crea entusiasmo entre las personas que trabajan en él. Mi último proyecto en la NASA fue un conjunto de herramientas de planificación de operaciones espaciales cuyo propósito era permitir misiones humanas en el espacio profundo que en última instancia conduciría a la habitación humana permanente de otros mundos. ¿Demasiado grandioso? Tal vez. Pero, ¿me hacía tener ganas de ir a trabajar todos los días? Claro que sí.

¿Ha trabajado alguna vez en un proyecto dirigido por alguien capaz de comunicar su propósito superior de forma que inspirara a la gente y que creara una cultura en la que todos los implicados en el proyecto se sintieran parte importante de algo mucho más grande que ellos mismos? ¿No fue ese su proyecto favorito de todos los tiempos? El mencionado proyecto del conjunto de herramientas de planificación de operaciones espaciales tuvo un líder así, y fue y será siempre mi proyecto favorito.

Un proyecto de Scrum Consciente reconoce múltiples tipos de partes interesadas. ¿Qué tipos de partes interesadas tiene un proyecto de software? Puede haber muchos, tales como:

  • Los usuarios finales

  • El gerente que está pagando por el proyecto

  • Desarrolladores de software

  • El equipo de control de calidad

  • El Scrum Master y el Product Owner

  • Ventas y marketing

  • Proveedores de bibliotecas de software, marcos de trabajo y herramientas utilizadas en el proyecto.

Se trata de siete partes interesadas que me vienen a la cabeza, y probablemente se te ocurran más. Un proyecto tiene que proporcionar valor para todos ellos.

¿Qué nos dice Conscious Scrum sobre cómo gestionar la deuda técnica? Aunque el enfoque mientras estás allí tiene valor para pequeñas cantidades de deuda técnica que se puede pagar en una hora o dos, el enfoque de la historia técnica es la mejor manera de pagar la deuda técnica significativa. Documentar la deuda técnica de este modo facilita las conversaciones con todas las partes interesadas en el proyecto para priorizarla adecuadamente.

Image 2 - Conscious Scrum

Para ello, no es necesario entrar en discusiones técnicas; basta con sopesar el coste de saldar la deuda técnica y el coste de no hacerlo. ¿Cómo aportan valor las historias técnicas a los distintos tipos de partes interesadas en el proyecto? Ahorran dinero al gestor que paga el proyecto. Hasta el noventa por ciento de los gastos del proyecto se producen durante la fase de mantenimiento (después de la puesta en producción inicial). Gastar un poco más de dinero ahora para pagar la deuda técnica reportará dividendos más adelante.

Los usuarios finales siguen recibiendo un flujo de nuevas funcionalidades porque el pago regular de la deuda técnica mantiene el código base en mejor forma y lo suficientemente flexible como para soportar nuevos requisitos, incluidas funcionalidades que aún no se nos ocurren.

Los desarrolladores de software tienen una base de código mejor con la que trabajar, lo que facilita la incorporación de nuevas funciones. Trabajar con una buena base de código todos los días aumenta la satisfacción en el trabajo y hace que sea más fácil retener a los desarrolladores con talento y atraer a nuevos desarrolladores para que se unan al equipo en el futuro.

El equipo de control de calidad se enfrenta a menos presión para aumentar su rendimiento de pruebas con el fin de obtener historias de usuario liberadas antes del final del sprint, porque el código defectuoso resultante de la deuda técnica puede tener dificultades para pasar sus pruebas y puede necesitar ser corregido hasta el último minuto.

El Scrum Master y el Product Owner obtienen más visibilidad sobre el trabajo que se está realizando, lo que les permite calcular valores de velocidad más significativos y tener una mejor idea del estado real del proyecto.

El equipo de ventas y marketing también ve valor en las historias técnicas porque un flujo constante de nuevas características entregadas mantiene su ventaja competitiva, y se traduce en un mejor producto para vender y publicitar.

Scrum consciente nos lleva a reconocer y generar valor para múltiples tipos de partes interesadas en un proyecto de software, y las historias técnicas son una parte de eso. También nos anima a encontrar un propósito más elevado para nuestro trabajo, lo que nos da un mayor sentido de logro y realización.

¿Quieres saber más sobre Scrum? Póngase en contacto con nosotros o echa un vistazo a los numerosos cursos que ofrecemos sobre el tema cada mes¡!

Ágil

Reflexiones más recientes

Explore las entradas de nuestro blog e inspírese con los líderes de opinión de todas nuestras empresas.
Asset - Respecting and Rewriting Our Legacy
DESARROLLO DE SOFTWARE

Respetar y reescribir nuestro legado

Retos y estrategias para actualizar los sistemas de software heredados en las empresas.