Ajedrez - antoniomartel.com

Archivos por Etiqueta: inconvenientes SCRUM

Jornada sobre cómo «Adoptar Scrum y sobrevivir al intento…»

El pasado jueves tuve el placer de dar una pequeña charla en el edificio IncubeGC de la SPEGC al departamento de Desarrollo e Innovación Técnológica de www.aidacanarias.com sobre la adopción de Scrum y los problemas que pueden encontrarse al comenzar a implantarlo.

Espero que les resultara de interés. Solo me queda desearles buena suerte en su implementación. No será fácil pero, con todo el empeño y esfuerzo que han puesto Emilio, Alejandro y sus compañeros, seguro que todo les irá bien.

Les dejo con enlace a la presentación en Prezi que utilicé y con algunas fotos del evento:

Presentación Prezi sobre cómo "Adoptar Scrum y sobrevivir al intento..."

Tiempo para preguntas en la charla sobre Scrum a AIDA Canarias

Ventajas y desventajas de SCRUM (I)

Si estás considerando SCRUM como método de trabajo pero no sabes muy bien de qué va todo esto. Has oído a un montón de gente hablándote de las bondades de este sistema pero ¿cuántas tecnologías y técnicas no han aparecido rápidamente y desaparecido a mayor velocidad aún? Todas prometían ser revolucionarias así que cuando oímos tanto bombo sobre alguna arqueamos una ceja en actitud crítica.

Hace algunas semanas publiqué un prezi en el que explicaba las ventajas y inconvenientes de implantar SCRUM en una organización. Las comentaré ahora en esta entrada, esta vez con palabras en lugar de imágenes, comenzando por sus inconvenientes (trataré de ser parcial, pero no lo prometo)

El equipo puede estar tentado de tomar el camino más corto

Cuando cada dos semanas hay cosas que entregar, en las últimas entregas no se completaron todas las funcionalidades previstas y la velocidad del equipo no predice que vayamos a terminar en plazo tenemos un problema: puede surgir la tentación de resolver las tareas pendientes de cualquier manera y dejar ‘deudas’ técnicas en el trabajo. Aparentemente todo va bien, más funcionalidades hechas, empezamos otras nuevas y el cliente está contento porque se están cumpliendo los plazos.

Pero siempre que se deja un borrón ahí atrás puedo asegurarte que volverás a tropezar con él. Si nuevas cosas han sido construidas sobre este borrón, la ‘deuda’ comenzará a multiplicarse. Antes o después tendrás que parar todo y devolver la deuda comprometida (con intereses de demora) El proyecto no termina de cerrarse cuando parecía que ya quedaba poco por acabar: la gráfica burndown parece tener una asíntota horizontal en 0 (lo siento, deformación profesional/educacional, Cálculo I)

¿Necesitas con mucha antelación fechas exactas de entrega?

Esta es una de las críticas más habituales a SCRUM. En cierta forma es lógico, al inicio del proyecto no puedes predecir cuando lo vas a acabar si estás facilitando que lo que se va a construir cambie y varíe en el tiempo. ¿Se prefiere un producto que se sabe con certeza que va a finalizar en 10 meses pero que está construido sobre las ideas y opiniones que se tenían cuando se comenzó? Quizás se prefiera un producto que podría acabar en el plazo similar pero que hemos podido evolucionar hacia nuestras necesidades reales y que hemos podido usar y probar antes de la entrega final.

¡Stress!

No nos podemos pasar la vida esprintando. Hacemos una entrega y ya nos comprometemos para la siguiente que está solo a un par de semanas vista. Luego otra y otra. Si tenemos que recorrer muchos kilómetros así comenzaremos con un rápido sprint para llegar a la primera meta pero llegaremos caminando a la última, eso con suerte.

¿El equipo es autoorganizado?

Una de los principios de SCRUM es que el equipo debe tomar sus propias decisiones y autogestionarse. Además, se requiere que no haya miembros especializados en tareas concretas como análisis, tests, diseño, documentación, etc. sino que todos los integrantes del equipo sepan hacer de todo y puedan intercambiarse entre sí. ¿Siempre contamos con un equipo así? ¿Qué pasa si no lo tenemos?
Desde luego es un problema pero ¿no lo sería también con cualquier otra forma de trabajo? ¿Hay alguna que permita llevar proyectos a buen puerto con equipos con poca experiencia?
En otra entrada hablaré sobre las ventajas de SCRUM (seguro que no es tan popular)

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

Entregar lo que el cliente necesita

Uno de los principios básicos de SCRUM (y también unos de sus desafíos) consiste en la aceptación de que el cliente puede cambiar de idea sobre lo que necesita. Con SCRUM se intenta dar una respuesta flexible admitiendo que el propio cliente puede no tener completamente definido cuál es el problema y que, a menudo, a medida que avanza el proyecto éste puede darse cuenta de qué es lo que realmente necesita. Por esto, entre otras cosas, SCRUM es denominada como una metodología Ágil.

La lista de requerimientos y funcionalidades creada al principio del proyecto es abierta y puede ser modificada en cualquier momento. Contiene estimaciones aproximadas del esfuerzo que supone el desarrollo de estas funcionalidades y, antes de comenzar cada iteración o sprint, se toma un grupo de estos requerimientos como objetivo para el final del mismo. Dos o tres semanas más tarde, los requisitos serán otros y el nuevo objetivo a alcanzar puede ir en una línea distinta a la definida unos sprints atrás.

Es una nueva forma de trabajar, un tanto difícil de asimilar, tanto para el cliente como para el proveedor. Hay caminos aparentemente más fáciles. Siempre podemos volver a la fórmula tradicional: En primer lugar analizamos el problema durante meses, cuando tenemos claro lo que debe hacerse comenzamos a desarrollar la solución duramente varios meses más. Al finalizar, cruzamos los dedos y entregamos el producto final al cliente.

Después de este punto, quién no ha oído frases como ‘Pero esto no es lo que yo quería, aquí falta …’, ‘No, así no era, no me entendiste bien …’, ‘Sí, está bien, pero voy a llamar al Director que es quién realmente da el visto bueno’ (por supuesto, el Director no ha acudido a ninguna de las reuniones de análisis) Después de los meses de trabajo invertidos y las prisas y el estrés para cumplir las fechas comprometidas, el cliente no ha recibido lo que necesitaba y necesitaríamos trabajar aún más para intentar parchear la solución proporcionada.

La flexibilidad de SCRUM también tiene sus riesgos: ¿Qué sucede si el cliente no termina nunca de añadir nuevas funcionalidades a la pila del producto? ¿y sí el cliente redefine incesántemente cada requisito? Esto será tema para otra entrada del blog.

Suscríbete