Scrum es un marco de trabajo orientado al proceso de entrega de software en iteraciones cortas. Pequeños esfuerzos, pequeños cambios, pequeñas desviaciones, todo esto permite corregir el rumbo del proyecto en el menor tiempo posible. Si bien, es una herramienta excelente, como tal no puede ser aplicada en todos los escenarios. Es importante detectar cuando Scrum puede hundir un proyecto en lugar de sacarlo a flote. A continuación te explico:
Señales del peligro para Scrum.
Durante el diseño de tu solución o el levantamiento de tu proyecto puedes identificar ciertas situaciones que pueden indicarte que Scrum no es la mejor metodología a seguir para entregar el producto correcto. ¿Has vivido alguna de las siguientes situaciones?, te las menciono:
- No se sabe el porcentaje de desviación de conocimiento.
- Las fechas de entrega no son negociables, ni pueden o deben de moverse.
- No se puede negociar la inclusión o no inclusión de características.
- No hay dueño de producto o interesados, alguien del equipo de desarrollo debe de tomar este rol.
- Todo cambio de alcance se trata como bug.
- No hay un sistema de control de calidad por parte del equipo de desarrollo.
Si te has identificado con al menos dos de los puntos anteriores, es posible que usar Scrum no reporte beneficios a la productividad del equipo. Debes de saber cuál es el objetivo de esta metodología.
¿Qué busca Scrum?.
Scrum busca entregar el producto correcto al cliente, desgraciadamente no se cubre el entregar un buen producto. Comúnmente se asume que el mero hecho de emplear esta metodología garantiza la calidad, lo cual es un error. Scrum también busca reducir la desviación de conocimiento producida en el levantamiento del requerimiento. Idealmente, un requerimiento posee la especificación de como funciona o debe de funcionar un proyecto. En la realidad no siempre es posible producir una especificación que cubra el cien por ciento el sistema, esto produce una diferencia entre lo que sabes y lo que deberías saber. Hablamos de actividades y horas de desarrollo extra. Scrum ayuda a amortizar estas actividades extra agregándolas en cada Sprint, no asocies esta metodología con cero desviación, eso no existe.
El conocimiento lo es todo, debes de saber que no sabes.
El porcentaje de lo que sabes y lo que no, define el número de horas totales que vas a estimar en tu proyecto. Un proyecto con 30 % de desviación dice que vas a tardar 1.3 veces el tiempo que estimas. Si un cliente no puede estimar que no sabe, o te dice que ya todo está definido, debes tener cuidado, no existe un proyecto con margen de error cero. Si no se sabe el número, tendrás que trabajar de más.
Las fechas deben de ser adaptables o las características.
Es común que recibas un proyecto que ya tiene fecha de salida a producción, pero no tiene especificación. Esto es una invitación a no llegar a la fecha pactada, pero admitámoslo es parte de la profesión, difícilmente esto va a cambiar. Como equipo tenemos un número de horas finitas y, por lo tanto, una cantidad de trabajo limitada. Para poder lidiar con esto puedes negociar fechas de entrega o la inclusión de características. No todas las funcionalidades de un sistema son críticas, algunas de estas pueden ser postergadas o recortadas. El dueño del producto debe ser consiente de este hecho y saber priorizar para sacar el mejor producto posible con los recursos disponibles y el equipo debe de saber exponer estos hechos y entregar un producto suficientemente bueno. En caso de que no se puedan llegar a acuerdos, vas a tener problemas.
Los interesados o dueños del producto son indispensables.
El compromiso es fundamental en Scrum, la parte que va a recibir el producto debe estar interesada en recibir algo suficientemente bueno. Ellos o ellas van a dar el visto bueno, validar que funciona o no funciona, si es posible agregar mejoras al requerimiento inicial o desechar cosas que no aportan valor. Claro, todo desde su perspectiva de usuarios u operadores del sistema. El apartado técnico va a correr a cargo del equipo. Si no existe una figura fuerte que defienda el producto, lo que va a suceder es que el equipo de desarrollo va a proponer soluciones que pueden o no funcionar al usuario final, con el riesgo de tener que tirar cosas a la basura. Es frustrante construir sistemas que llegan al usuario final y no logran solucionar las problemáticas, ya que la visión del equipo no era la misma que la del usuario final, aunque sea pequeña. Representa desperdicio de horas de trabajo.
No todo cambio es un bug.
Los usuarios o interesados del producto pueden confundir un cambio con un error. Por ejemplo: si el sistema anterior tenía un botón de exportar a Excel, este no fue especificado en el requerimiento inicial. Durante la revisión por parte de los interesados del producto no fue reportado este faltante. Ahora, en el despliegue de la solución, el primer ticket que recibes es un bug de un usuario que reporta esta falta como un error. No es un bug, ya que no es una funcionalidad que tiene un comportamiento esperado, tampoco es omisión por parte del equipo. Puede considerarse un cambio de alcance o un trabajo adicional, como sea. No debe considerarse como soporte. Si los interesados no quieren asumir la responsabilidad de los cambios va a haber problemas.
La calidad siempre es responsabilidad del equipo.
El equipo de desarrollo jamás debe de justificar cambios de características o alcance, soporte o corrección de errores como pretexto para la caída de calidad. Se trabaja en la calidad desde el día cero, no importa la situación. Scrum no va a asegurar la calidad, el equipo sí. La inclusión de pruebas automatizadas, automatización de despliegues, documentación o mejora continua deben estar implícitas en todas tus actividades, sin excusa. Nuestros usuarios siempre van a esperar un mínimo de calidad. Si el equipo no está comprometido con la calidad de la solución, va a convertir la entrega de cada sprint en una serie de happy paths que tienen como único objetivo pasar la revisión de los interesados del producto.
Conclusiones.
No existen balas de plata en esta profesión, cada solución ofrece ventajas y desventajas que deben de ser evaluadas al momento del análisis. Ten en cuenta, usar Scrum no te va a hacer un programador Agile, en cambio, usar la mejor herramienta disponible para resolver un problema, sí que lo hará.
Autor imagen: garycycles8
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
