SCRUM cuantas menos métricas mejor

Scrum cuantas menos métricas mejor, ha sido posible gracias a Scrum Manager y a Juan Palacio por compartir sus ideas y conocimientos en este post y en sus disponibilidad para debatir y contrastar opiniones, gracias.

Si medimos como se hace con un proceso para determinar su «capacidad”, ya vamos mal porque precisamente es un marco de trabajo cuyo origen es una respuesta de antítesis a los procesos.

Lo de medir el proceso para mejorarlo va bien para los procesos, pero no presupondría que para todo

Si errar es humano y rectificar de sabios, Tom DeMarco es de los segundos. Su obra es una de las principales contribuciones en el desarrollo de la Ingeniería del Software.

Tom de Marco autor del principio que muchos toman como incuestionable «no puedes gestionar lo que no puedes medir», se desdijo afirmando que en determinados proyectos es mejor no aplicarlo”

Sus trabajos sobre métricas para la gestión de proyectos de software, referente de temarios como PMBoK: Controlling Software Projects: Management, Measurement and Estimation, publicado en 1982 y que hizo famoso su principio «no puedes controlar lo que no puedes medir». Con motivo del 40 cumpleaños de la Ingeniería del Software , el número de julio/agosto de IEE SOFTWARE publilca un artículo de Tom DeMarco del que prefiero citar literalmente:

Las métricas que inicialmente expuse en mi libro Controlling Software Projects: Management, Measurement and Estimation, han definido la forma en la que muchos ingenieros construian el software y planificaban el trabajo. Con un ánimo de estado reflexivo, ahora me pregunto: ¿Fué correcto el asesoramiento en métricas? ¿Sigue siendo pertinente? y ¿creo todavía que las métricas son una necesidad para el éxito de cualquier desarrollo de software?. Mis respuestas son no, no y no.

El artículo hace un paralelismo con el tipo de control de un padre sobre su hijo y me recuerda el principio de «control sutil» identificado por Nonaka y Takeuchi en el concepto original de Scrum.

«Al aplicar el principio ‘no se puede controlar lo que no se puede medir’ a la educación en la adolescencia, la mayoría de las cosas realmente importantes, honor, dignidad, disciplina, personalidad, valores, ética, ingenio, lealtad, humor, bondad… no son medibles.

Tienes que formar a tu hijo lo mejor que puedas sin tener feedback de métricas. Es difícil, porque ser padre es difícil. Tienes unas ciertas métricas del tipo de las notas del colegio, e intuyes que la nota de matemáticas es más importante que la de español y que la nota de comportamiento quizá diga más del profesor que del alumno».

Véase Espiral del conocimiento 

El patrón dialéctico

Al cuestionar el conocimiento, se inicia su evolución que sigue un patrón dialéctico de: tesis, antítesis y síntesis.

De manera esquemática el patrón dialéctico puede definirse como el ritmo de avance que contrapone una antítesis a una concepción previa, entendida como tesis. La antítesis muestra los problemas y contradicciones de la tesis, y de la confrontación surge un tercer momento llamado síntesis, una resolución o una nueva comprensión del problema.

De esta forma la estrategia de abordar con ingeniería de procesos los retos de los proyectos de software, supuso la primera la tesis para dar respuesta a la “crisis del software”, y sus problemas y contradicciones han sido puestos de manifiesto por su antítesis: la agilidad. En 1968, en la primera conferencia sobre desarrollo de software celebrada por la organización OTAN, se analizaron los problemas de la programación del software, y en ella se acuñó el término “crisis del software” para referirse a ellos. La conclusión de la conferencia (Bauer, Bolliet, & Helms, 1969) fue la necesidad de crear una disciplina científica que, como ocurría en otras áreas, permitiera aplicar un enfoque sistemático disciplinado y cuantificable al desarrollo, operación y mantenimiento de los sistemas del software, es decir, la aplicación de la ingeniería de procesos al software. Fue el nacimiento de la Ingeniería del Software. La primera estrategia de la Ingeniería del software (tesis) se ha basado en dos pilares:

Cuestionar lo conocido hace girar la espiral del conocimiento y leer estas afirmaciones de Tom DeMarco reconforta y da gusto ver que hay personas que con honestidad cuestionan depuran y mejoran de forma continua.

También se puede pensar «vaya pena con Tom DeMarco. Con las buenas ideas que tenía, y al final se ha echado a perder». 

Pero, Scrum es un framework basado en el manifiesto ágil,

Primer principio

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Segundo principio

Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Queda claro que siguiendo estos principios la entrega temprana de valor e incluir la innovación como ventaja competitiva, entregando valor frecuentemente de forma iterativa tras feedback continuo de todos los individuos que intervienen en el desarrollo, deja claro que no podemos utilizar métricas al uso o tradicionales.

Usamos para ello la antítesis a los procesos en el desarrollo, lo de medir el proceso para mejorarlo va bien para los procesos, pero no presupondría que para todo incluyendo la fase de desarrollo o productiva.

Si tomamos los artefactos de Scrum, podemos usar 3 herramientas clave para la gestión:

1. Product Backlog Más Info

El Product Backlog es un inventario que contiene cualquier tipo de trabajo que haya que hacer en el producto: requerimientos, casos de uso, tareas y dependencias. Es la principal fuente de información sobre el producto en Scrum, una lista, en cualquier formato, que contiene todos los requerimientos que necesitamos implementar en el producto. Esta lista es el resultado del trabajo del Product Owner con el cliente, los distintos stakeholders, sponsors, comités, etc, y refleja el estado real del trabajo pendiente de implementar en el producto, así como el ya realizado.

El Product Backlog debe ser gestionado en exclusiva por el Product Owner, siendo su principal función la de priorizar aquellos elementos que tienen más valor en cada etapa y detallarlos para que el equipo de desarrollo sea capaz de valorarlos y ejecutarlos.

Al comenzar a utilizar Scrum, no es necesario una lista completa y exhaustiva de todos los requerimientos. Es recomendable empezar con los dos o tres requerimientos más urgentes arriba e ir añadiendo elementos conforme vamos descubriendo más necesidades de nuestro producto.

Un Product Backlog contiene distintos elementos:

Funcionalidades

• Bugs
• Historias de usuario: una forma de expresar elementos de un Product Backlog. Para obtener el máximo valor de una historia de usuarios es necesario expresarlas desde el punto de vista del usuario.
• Tareas técnicas
• Trabajo de investigación

1.  Sprint Backlog Más Info

¿A qué denominamos Sprint Backlog? Se trata de una lista de elementos en los que trabajar durante la etapa de Sprint. Estos elementos normalmente se componen de tareas técnicas más pequeñas que permiten conseguir un incremento de software terminado.

Todo el trabajo que el Development Team haya seleccionado para hacer durante el siguiente Sprint pasa al Sprint Backlog. Este artefacto es un elemento para visualizar el trabajo a realizar durante cada Sprint y está gestionado por el equipo de desarrollo. Su propósito es mantener la transparencia dentro del desarrollo, actualizándolo durante toda la iteración especialmente a través de los daily Scrums.

El Sprint Backlog permite visualizar, durante cada Sprint, aquellos elementos que aún no han empezado a desarrollarse, aquellos que sí y quiénes están trabajando en los mismos, así como aquellos que están esperando a desplegarse o están completamente terminados.

Este artefacto permite entender cuál es la evolución del trabajo durante el Sprint, así como hacer un análisis de riesgos. Dado que cada Sprint tiene una meta específica (p.e. permitir que los usuarios se registren en la app móvil) y hay elementos seleccionados del Product Backlog que tienen más o menos valor, el Sprint Backlog permite analizar hasta donde se ha cumplido el objetivo y que se podría eliminar. De esta forma, maximizamos el retorno de la inversión en desarrollo.

1.  Incremento Más Info

Si Scrum tuviera que ser reducido a una sola cosa, sería a entregar una pieza de software terminado en cada Sprint. Un Incremento es el resultado del Sprint, es la suma de todas las tareas, casos de uso, historias de usuario y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de software, aportando un valor de negocio al producto que se está desarrollando.

Construir software de manera ágil se basa en hacerlo de manera iterativa e incremental. Mediante las iteraciones, nos aseguramos que todo el ciclo de vida del software (planificación, diseño, desarrollo, testeo y entrega) ocurre en 4 semanas o menos. Por supuesto, no podemos construir toda la funcionalidad que queremos en solo cuatro semanas y tenemos que buscar la manera de ir entregando los componentes necesarios justo a tiempo.

Otros artefactos

El marco de trabajo Scrum destaca los 4 elementos expuestos previamente como imprescindibles. Sin embargo, hay otros que, a pesar de no formar parte del core, son necesario para asegurar la calidad de la metodología Scrum.

• Definition of Done (DoD): La DoD es un documento que define qué se considera hecho en un equipo Scrum. La idea es establecer una serie de criterios comunes para especificar cuando un ítem está completamente terminado y que aplique a todos los ítems que forman parte del incremento. Más Info
• Definition of Ready (DoR): El DoR es un documento que define cuándo un requerimiento (historia de usuario o similar) se considera listo para que el equipo de desarrollo pueda entenderlo, valorarlo e incluirlo en un Sprint Planning con idea de acometerlo en un Sprint. Más info
• Burndown Chart: El Burndown Chart es un gráfico de trabajo pendiente a lo largo del tiempo que muestra la velocidad a la que se están completando los objetivos, requisitos, o historias de usuarios. Permite extrapolar si el equipo podrá completar el trabajo en el tiempo estimado. Más Info
• Burnup Char:  El gráfico de producto o gráfico “burn up” es una herramienta de planificación propia del propietario de producto, que presenta visualmente la evolución previsible del producto. Proyecta en el tiempo la construcción del producto, en base a la velocidad del equipo. La proyección se realiza sobre un diagrama cartesiano que representa en el eje de ordenadas el esfuerzo estimado para construir las diferentes historias de la pila del producto, y en el de las abscisas el tiempo medido en sprints. Más Info

 Eventos:

• Restrospectiva: Reunión en la que el equipo analiza la forma de trabajo para su mejora continua. Las reuniones retrospectivas son por tanto un una “meta-práctica” ágil. Más Info

 😉➡️ Para más información en terminología Más Info