Value Stream Management: ¿Qué es Flow Framework?

Gabriel Casarini

Gabriel Casarini

Value Stream Management: ¿Qué es Flow Framework?

Compartir

Share on email
Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

Value Stream Management por Gabriel Cassarini y co-autor Alonso Álvarez

En el artículo anterior analizamos el problema de la transformación digital de Nokia. Comentamos que las optimizaciones y métricas locales, a nivel de los equipos, estaban desconectadas del resto de estrategias y de toda la cadena de entrega de valor. El foco estaba puesto en medir la ejecución de actividades en lugar de tomar distancia y medir el impacto de la transformación en los resultados de negocio. Nuestro objetivo en este artículo es empezar a analizar la propuesta de Flow Framework para interconectar las actividades de desarrollo de software y medir su impacto en las áreas de negocio. Necesitamos tener trazabilidad, gestionar el flujo del trabajo de los equipos y tomar mejores decisiones en base a datos y resultados. Un enfoque sistémico y empírico. 

Umm… dicho así suena un poco abstracto. Vayamos por partes. 

¿Qué es un Value Stream?

El concepto de value stream proviene de los procesos de fabricación industrial y se refiere a todo el flujo o cadena de valor, de principio a fin, desde que llega una solicitud hasta que ponemos el resultado en manos del usuario final. Aquí lo utilizamos para referirnos a toda la secuencia de actividades, personas y herramientas que intervienen en la producción de software. Según SAFe y Flow Framework, la producción de software a gran escala requiere que haya una relación 1-a-1 entre la dedicación de los equipos de desarrollo y los value streams. Es decir, que cada equipo participe en un único value stream. Foco y dedicación. Aplicar esta estrategia en la creación de los equipos aumenta la eficacia, la calidad del trabajo—y también mejora el compromiso, aumenta el conocimiento compartido y la salud de los equipos. 

Cuando hablamos de value streams es especialmente importante incluir a todos los stakeholders y actores. Si excluimos, por ejemplo, a los equipos de soporte o a las áreas de negocio, el resultado no es un value stream, sino segmentos de un flujo. En ese sentido, los equipos ágiles y DevOps son segmentos. Los segmentos son importantes pero nuestro objetivo ahora es tener una visión sistémica, de extremo a extremo de todo el value stream, y ver de qué forma podemos medir cómo discurre la entrega de valor. 

Una taxonomía para los ítems

El primer paso para poder medir es identificar claramente los ítems que viajan por el flujo de valor. Estas unidades de trabajo, que en Flow Framework se denominan Flow Items, de alguna manera representan el valor que se entrega a los clientes y usuarios. Los equipos ágiles utilizan un backlog para gestionar el trabajo y las prioridades. Flow Framework propone la siguiente taxonomía para clasificar los ítems del backlog: 

  • Feature: es un requisito funcional con valor de negocio (historia de usuario, épica). Las features representan necesidades de los usuarios y suelen ser recogidas por Product Ownersstakeholders y las áreas de negocio 
  • Defect: es la corrección de un defecto (bug, errores, incidencias). Los defectos suelen ser reportados por el equipo de calidad, los usuarios o el propio equipo técnico 
  • Debt: se refiere al pago de la deuda técnica del software. Por ejemplo: acometer mejoras en la arquitectura para facilitar el mantenimiento, automatizar tareas, adoptar nuevas herramientas. Estas necesidades suelen ser detectadas por los equipos técnicos—los arquitectos y desarrolladores 
  • Risk: son requerimientos no funcionales como la seguridad, cumplimiento de estándares y normativas (GDPR), privacidad de datos. En muchos casos, estos requerimientos actúan como restricciones sobre el diseño de la solución técnica 

Tener visibilidad y cierto grado de abstracción sobre el flujo de los ítems a través de los procesos y herramientas de la organización nos permitiría identificar cuántos diseñadores, desarrolladores, Product Owners, managers, testers y otros perfiles estuvieron involucrados en crear, desplegar y dar soporte a una feature concreto.

Balancear la distribución

Es importante que los equipos trabajen sobre una distribución equilibrada de los diferentes tipos de ítems. La distribución puede ir variando con el tiempo para maximizar el valor de negocio—principal responsabilidad de los Product Owners. Si llegan demasiadas incidencias, algunas features tendrán que ser quitadas de las prioridades del backlog. Si la presión por entregar nueva funcionalidad a la par que corregir errores no se estabiliza, al cabo de varios trimestres la deuda técnica interferirá con la capacidad de avanzar en el desarrollo. De la misma forma, si los riesgos no son explícitamente priorizados en el backlog, nunca serán implementados.  

Es necesario que esta información, que es de naturaleza técnica, pueda ser comunicada a las áreas de negocio. La siguiente imagen muestra lo que ocurre cuando el equipo invierte todo su esfuerzo en desarrollar nuevas funcionalidades (features) y descuida la calidad y la corrección de defectos. Con el tiempo, la deuda llega a ser tan grande que es imposible continuar desarrollando nuevas funcionalidades y el equipo se ve obligado a parar completamente para pagar la deuda. Si no reducimos esta deuda de forma regular, el software se vuelve prohibitivamente caro y difícil de mantener y actualizar. 

En muchas organizaciones, las áreas de negocio no ven este problema y continúan empujando a los equipos a implementar nuevas features a costa de aumentar la deuda técnica. En las grandes tecnológicas suele haber más conciencia de este problema porque los directivos, en general, suelen tener experiencia en el desarrollo de software. Necesitamos herramientas para que los líderes y perfiles menos técnicos vean claramente este problema. Los Product Owners no solo deben optimizar la entrega de valor a corto plazo; también deben tener en cuenta el impacto de una mala distribución de las prioridades de los ítems del backlog. ¿Qué hubiera pasado si la dirección de Nokia hubiera podido visualizar el impacto de la deuda técnica?  

En el próximo artículo analizaremos en detalle las métricas que propone Flow Framework para medir el trabajo que fluye por un value stream de desarrollo de software. 

Forma parte de la comunidad #AlwaysLearning

Sobre el autor

Gabriel Casarini

Gabriel Casarini

Gabriel Casarini, Netmind Lead Expert, SAFe Program Consultant y Software Architect, siente pasión por desarrollar y liderar equipos. Se dedica a racionalizar equipos y organizaciones, impartir experiencia, motivar y enseñar qué es la agilidad y cómo hacer que los equipos de desarrollo sean altamente productivos. Su experiencia profesional se basa en la creencia de que la mejora continua y la adaptación son las únicas formas de optimizar verdaderamente los procesos de desarrollo, aumentar la calidad y ofrecer un mayor valor al cliente. Gabriel es un ferviente defensor y practicante de marcos ágiles, TDD y Lean Startup. También aporta una amplia experiencia técnica con la plataforma JEE y la integración de componentes, herramientas y marcos de código abierto. La combinación única de pasión y experiencia de Gabriel contribuye a su capacidad como formador, mentor, consultor y Scrum Master ágil para ayudar a los equipos a adoptar una visión integral y un enfoque de gestión ágil que supere el desafío en cuestión. Conecta con Gabriel en LinkedIn y consulta su blog personal , donde comparte su visión sobre el software y temas de ingeniería!
Insights relacionados

SOLICITAR FORMACIÓN A MEDIDA

Por favor, proporciona la siguiente información para ayudarnos a personalizar la solución.

CONTÁCTANOS

Netmind España
Barcelona +34 933 041 720
Madrid +34 914 427 703

Nos puedes encontrar de:
Lunes – Viernes, 9:00-18:00 (GMT+1)

¡Te ayudamos!
[email protected]

¿Dudas sobre servicios/formaciones?
[email protected]

Solicitar Información