Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

Error nº 14: Objetivos del Sprint inalcanzables

Lo que cabe dentro de un Sprint y lo que no es algo que decide el Equipo de Trabajo. Ellos son quienes mejor pueden calcular hasta dónde pueden llegar en esas semanas que dura el Sprint porque son ellos quienes saben hacer el trabajo. Si se les obliga a aceptar un alcance mínimo para entregar en ese tiempo lo que podríamos estar haciendo es forzarles a que disminuyan la calidad.

En todo proyecto hay siempre tres variables que están ligadas unas a otras. Es el llamado triángulo de hierro. Estas variables son:

  • Alcance: El conjunto de funcionalidades o tareas a realizar.
  • Coste: El presupuesto o el número de personas empleadas para desarrollar esas funcionalidades.
  • Tiempo: Lo que durará el proyecto.

 

Triángulo de Hierro en el desarrollo del software

Esto es, si tienes un alcance muy grande tendrás un proyecto muy grande con un coste alto y que durará bastante tiempo. Si por ejemplo, en un proyecto empleas a pocas personas para el mismo alcance tendrás un proyecto que se alargará en el tiempo. Estas variables están interconectadas por lo que si intentas reducir alguna de estas variables manteniendo fijas las otras será la calidad la que se resienta.

Si en cambio, como dice el título de este apartado, alguien externo al proyecto obliga a aceptar un alcance muy elevado en sólo un Sprint, estaremos ampliando el alcance pero dejando inmutables el coste (número de desarrolladores) y el tiempo. Con esto sólo conseguiremos que no lleguemos a cumplir el objetivo del Sprint o que lo hagamos con unos niveles de calidad inaceptables.

No pasará nada en un principio, todo irá aparentemente bien aparte del estrés para poder cumplir el Sprint, pero si la calidad ha bajado esto se terminará notando. Lo hará más adelante en forma de bugs o incidencias que irán apareciendo o de funcionalidades que no están bien pensadas o resultas y que son usables. Funcionalidades poco prácticas o incómodas de usar por los usuarios y que requieren más clics de los necesarios.

Si tenemos un objetivo del Sprint demasiado ambicioso, que ha sido impuesto desde fuera y que es inasumible corremos el riesgo de emplear el doble de trabajo que si lo hubiésemos repartido mejor entre más Sprints. Veamos por qué:

  • Los programadores tendrán que hacer multitarea para intentar acometer el alto número de tareas que tienen en ese Sprint. Lamentablemente nunca tenemos en cuenta la bajada de productividad que la multitarea supone.
  • Tendremos que dedicar tiempo a la corrección de bugs. No habrá tiempo ni para pensar y todas las tareas se acometerán a toda prisa: No hay tests, no se hacen pruebas, no se revisa la aplicación una vez está todo integrado y no hay tiempo de comprobar que todas las funcionalidades pedidas realmente se han hecho.
  • Debido a esto último, muchos bugs aparecerán más tarde, cuando se hagan las pruebas de aceptación por el cliente o cuando se ponga en uso la aplicación. Puede que algunos aparezcan meses o años después de entregado el código ¿Quién se acuerda ahora de por qué el código se hizo así? ¿Para qué eran esas funcionalidades? Se tardará mucho más tiempo en resolver esos bugs que si se hubiesen corregido en el mismo Sprint cuando se tenía aún fresco en la memoria el trabajo hecho. Se sobresaturó el trabajo en el Sprint y no quedó tiempo para hacer buen código y revisarlo después (o a la vez que se escribe). En el futuro pagaremos más por cada bug detectado, es mejor pagar la deuda técnica ahora que hacerlo luego con muchos más intereses.

Reuniones de demo que no están listas

Es frecuente que el equipo, metido en las prisas por entregar lo comprometido en el Sprint, olvidé que al final del mismo tiene que demostrar lo que ha hecho y que esas demos tienen un coste de preparación. Normalmente es necesario:

  • Montar el entorno de demo donde se va a enseñar la aplicación
  • Asegurarse de que funciona en el equipo donde se va a enseñar
  • Tener preparado un usuario y unos registros pre-insertados para que se vean en la demo
  • Guionizar las pruebas que se van a enseñar y ensayar brevemente la demo para asegurarse de que todo irá sobre ruedas.

Cuando estamos en los primeros sprints y aún no estamos muy acostumbrados a hacer las demos, no sabemos bien dónde está el entorno de demo ni estamos acostumbrados a mostrar la aplicación es frecuente que todo falle: El usuario que escogimos no loguea, no tiene todos los permisos para entrar en las áreas de la aplicación que vamos a mostrar hoy y es necesario que alguien salga de la reunión para darle esos permisos. Necesitamos estar creando registros para poder probar delante del Dueño del Producto y los Interesados alguna de las funcionalidades.

Por esta razón, unos dos días antes de la reunión de demo suelo hacer una reunión que he dado en llamar de pre-demo. En ella, de forma informal y breve, los desarrolladores hacen una mini-demo de las funcionalidades que les ha tocado hacer y que se les ha pedido que preparen primero. En esta pre-demo suelen surgir muchas incidencias y dudas para las que todavía quedan dos días a resolver antes de entregarlas al cliente. Para entonces ya estarán más rodadas cuando se vayan a mostrar de forma algo más oficial.

Curso de Scrum: preparación certificado Professional Scrum Master PSM I

Acabo de lanzar un nuevo curso de Scrum para la preparación del certificado Professional Scrum Master (PSM I) de Scrum.org. El curso es online y, además de enseñarte el Scrum que necesitas para aprobar el certificado, incluye ayudas y consejos a la preparación, numerosos tests y preguntas de práctica y libros y plantillas de regalo.

Diploma Certificación Professional Scrum Master PSM I

Tendrás también, entre otras cosas, un capítulo dedicado a los recursos que puedes encontrar en Internet para que puedas documentarte, practicar los exámenes y aprender más sobre estas certificaciones. Además podrás encontrar abundante información sobre los distintos tipos de examen de certificación para Scrum Master: Una Comparativa entre las certificaciones de Scrum Master más populares en el mercado, explicando las ventajas e inconvenientes de cada una de ellas:

  • Professional Scrum Master, PSM I de Scrum.org
  • Certified Scrum Master, CSM de Scrum Alliance
  • Agile Certified Practitioner, PMI-ACP de PMI
  • Certificado o acreditación Scrum Manager, de Scrum Manager

Si te interesa, échale un vistazo a la página del curso online. Ahí tienes una preview de algunos de los capítulos del curso. Está a la venta ahora por tan sólo 79€ el curso completo.

Curso de Scrum: Preparación para el certificado Professional Scrum Master (PSM I).

Interrupciones urgentes que no nos dejan avanzar en el proyecto

A veces tenemos que manejar un montón de interrupciones para resolver problemas de mantenimiento, corrección de errores o soporte que hacen que no lleguemos al objetivo del Sprint porque nos llega una cantidad grande de tareas que no estaban planificadas al inicio del Sprint.

Lo primero que tendremos que hacer es verificar si esas interrupciones urgentes son en realidad tan urgentes como nos las pintan o nos hemos dejado llevar por el alarmismo de haber encontrado un error en producción.

Lo segundo que debemos hacer es ver cuál es la razón principal por la que tenemos tantas interrupciones y de forma tan constante ¿Se deben a la mala calidad del software? ¿Quizás debido a las constantes interrupciones? Quizás debamos dedicar algunos sprints a resolver la deuda técnica que hemos ido dejando atrás o a dar más estabilidad a las partes del software que más problemas están dando.

También hay otras cosas que podemos hacer:

Tener sprints cortos

Con esta solución mantendremos las tareas ya programadas en la planificación del Sprint. Al tener sprints de una o dos semanas de duración podremos incluir la tarea no planificada como prioritaria en la lista de cosas a hacer en el siguiente Sprint. Si el Sprint tiene una semana de duración tardaremos una media aproximada tres días laborales en comenzar a acometer la tarea urgente.

Esto funcionaría en un mundo ideal pero no todas las tareas pueden esperar varios días para ser solucionadas. El servicio entero podría depender de ella.

Factor de dedicación bajo

Si sabemos que con frecuencia nos llegarán tareas inesperadas que debemos resolver con mucha rapidez podemos bajar el factor de dedicación durante el Sprint para dar ‘hueco’ a la resolución de estos problemas.


Sabiendo que en cada Sprint el equipo tiene capacidad para resolver 10 puntos de historias programadas podríamos comprometernos a entregar solo 7 para que el equipo tenga tiempo de resolver las incidencias urgentes. De este modo no fallaremos un Sprint tras otro en entregar lo prometido.

En mi opinión esta solución puede ser útil en ciertos proyectos pero puede crear otro problema. Me explico: Habitualmente el factor de dedicación es del 75%, si lo bajamos para poder dedicar un 30% del tiempo del equipo a las tareas urgentes deberíamos aplicar un factor de dedicación del 40-50%. Sobre este 40% aplicamos Scrum pero ¿Cómo se está gestionando el resto del tiempo del equipo? ¿Qué sabemos sobre esa pila de tareas que estamos resolviendo Sprint tras Sprint?

Evitemos crear equipos sólo para dar soporte

Eso sería un anti-patrón a evitar en todo tipo de proyectos. Si creamos equipos que se dedican sólo a resolver bugs o errores encontrados en producción dejaremos al resto de equipos con las manos libres para centrarse en su trabajo sin interrupciones para llegar al final del Sprint pero esto puede hacer que cada vez aumente más el número de errores encontrados.


Los equipos necesitan hacerse responsables del trabajo que entregan y si no ven lo que se causa entregando código defectuoso porque otro equipo especializado se encarga de ello, estaremos fomentando que aparezcan más y más errores. Si ellos mismos tienen que corregir sus propios errores, terminarán dándose cuenta de lo importante que es la calidad para evitar desaguisados y de lo que tienen que hacer para construir software más robusto que evite tanto error.

Dependemos demasiado de héroes: otro error habitual en la gestión de proyectos

Cuando dependemos demasiado de uno o dos programadores estrella dentro de nuestro equipo, de los que necesitamos que no fallen nunca, que hagan muchas horas extra porque no llegamos o que, cuando están de vacaciones, los echamos demasiado en falta, estamos ante un gran problema.

Scrum nos puede ayudar a conseguir grandes equipos de trabajo, equipos de alto rendimiento que pueden conseguir entregar mucho trabajo y de calidad. Si lo que tenemos es un equipo formado por un desarrollador estrella del que dependemos absolutamente y el resto del equipo sólo resuelve tareas de menor nivel, no tenemos exactamente un Equipo de Trabajo, tenemos un cirujano y tres o cuatro auxiliares.

Debemos evitar esto facilitando que más miembros del Equipo de Trabajo conozcan las partes de la arquitectura que sólo el programador o programadora estrella conocen, que otras personas realicen también las partes del trabajo que sólo le tocaban a él para que el conocimiento (y el esfuerzo) quede más distribuido.

Por bueno que sea, un Equipo de Trabajo completo siempre podrá producir más que sólo nuestro héroe y además no lo agotaremos a base de horas extra y llamadas durante las vacaciones. Poco a poco el resto del Equipo de Trabajo debe ir acostumbrándose a asignarse a sí mismo las tareas que típicamente sólo hacía el programador estrella e irá ganando en experiencia y en confianza en sí mismo hasta alcanzar un nivel óptimo.
Dependemos demasiado de héroes
Dependemos demasiado de héroes

Suscríbete