Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

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

No te dejes engañar por un diagrama de Gantt y la Falacia de la Planificación

¿Cuántos proyectos conoces que hayan acabado dentro del tiempo y presupuesto estimado sin que haya habido que reducir el alcance del proyecto? Muy pocos ¿no? Yo tampoco conozco muchos casos. Esto pasa en casi todos los sectores, no sólo en la industria del software, pero me temo que nuestra industria tiene una tasa de proyectos fracasados más alta que otras industrias. El estudio realizado para el Informe CHAOS 2015 revela que sólo el 29% de los proyectos TI pudo considerarse un éxito.

Nuestras estimaciones de tiempo y coste de un proyecto se salen de toda escala e incumplimos habitualmente nuestros relucientes diagramas de Gantt hechos al inicio del proyecto ¿A qué se debe esto? Bueno, al menos tiene una explicación científica. Se debe a un sesgo cognitivo que tenemos todas las personas no deprimidas y que hace que caigamos, una y otra vez, por exceso de optimismo en la llamada falacia de la planificación.

Este fenómemo, el de la falacia de la planificación, es debido a que los seres humanos tendemos a subestimar cuanto nos va a llevar terminar una tarea. Somos demasiado optimistas y siempre pensamos que vamos a tardar mucho menos de lo que finalmente nos va a llevar terminarla.

Lovallo y Kahneman, los autores de esta teoría, realizaron un estudio en el que preguntaron a 87 estudiantes de una universidad cuánto tiempo creían ellos que necesitarían para terminar su proyecto de fin de carrera. De media estos estudiantes estimaron que tardarían 34 días en finalizarlo el proyecto pero sólo el 30% de ellos fueron capaces de hacerlo en ese tiempo. La media real empleada en terminar sus tesis fue de 55.5 días, un 63% más de lo estimado.

Este exceso de optimismo es provocado en parte por la llamada ceguera de ausencia (absence blindness) que nos dice que por muy bien que planifiquemos nuestro proyecto nos será muy difícil planificar los imprevistos porque son eso, imprevistos, y no los conocemos de antemano. Planificamos todo lo relacionado con las especificaciones del proyecto pero olvidamos calcular los tiempos para las vacaciones, bajas por enfermedad, paternidad, maternidad, reuniones, otras tareas que causan overhead, dependencias de otros proyectos, requisitos que no están bien definidos y un larguísimo etcétera. Como dice Forrest Gump en su película, shit happens (esas cosas pasan).

Todo esto nos lleva además a tener en cuenta la Ley de Hofstadter: “Todo proyecto lleva siempre más tiempo del previsto incluso si se tiene en cuenta la propia Ley de Hofstadter“. Y si esto ocurre y nuestro proyecto se alarga más de lo previsto, probablemente caigamos todavía en más costes de lo que supone terminar más tarde. Como no llegamos a la fecha del fin del proyecto la presión nos llevará a meter a más gente dentro del proyecto para terminaar a tiempo haciendo que tengamos que contabilizar gastos extra directos como el salario de estas nuevas personas pero también indirectos de los cuáles no siempre somos conscientes.

Al incluir más personas olvidamos que necesitarán formación en el proyecto y que cometerán más errores al ser nuevos, errores que habrá que dedicar un tiempo a corregir. Se estima que un nuevo perfil en un proyecto tarda unos tres meses en ser totalmente productivo. Por otro lado, alguien que ya estaba trabajando en el proyecto tendrá que parar lo que estaba haciendo para enseñar a los nuevos. Como ya nos decía Brooks en los 70: “Añadir más gente a un proyecto retrasado, hará que se retrase aún más“.

Pero la presión aún nos hará incurrir en más costes en el proyecto. Las prisas nos harán bajar la calidad del producto que producimos, aparecerán más errores que también necesitarán tiempo para ser corregidos, o nos saltaríamos las pruebas del software con lo que saldrá a producción con bugs que nos harán perder la confianza y credibilidad con nuestro cliente. Y queremos que nos contrate de nuevo ¿no?

¿Qué podemos hacer para evitar esto?

En primer lugar debemos hacer un esfuerzo para tener en cuenta el máximo número posible de imprevistos que puedan surgir calculando así un tiempo extra para esos inconvenientes del día a día y aquellos otros que puedan ser aún más imprevisibles.

Podemos también intentar apoyarnos en las estadísticas de proyectos similares al nuestro. Si comprobamos cuanto tardaron probablemente nos llevemos una sorpresa si lo comparamos con lo que nosotros hemos previsto inicialmente.
Por último, sería bueno apoyarnos también en pruebas empíricas y no en estimaciones predictivas y medir la velocidad del equipo para calcular cuantas tarjetas podemos consumir en cada sprint. Así sabremos calcular un poco mejor qué podremos tener terminado en determinadas fechas. Los equipos de trabajo no son siempre iguales y si nos basamos en la cantidad de puntos o historias de usuario que nuestro equipo ha podido hacer durante los últimos sprints, podremos calcular algo mejor la cantidad de tiempo que nos llevará hacer otras funcionalidades similares en las próximas semanas o meses.
Otros artículos que pueden ser de tu interés:
Referencias:

Cómo ser ágiles en proyectos de mantenimiento

Son habituales en la industria ciertos proyectos, denominados de mantenimiento, en los que el trabajo consiste no en desarrollar nuevas funcionalidades al producto sino en realizar correcciones a bugs o las tareas mínimas para lograr que el sistema esté activo y dando servicio las 24 horas.

Pero a veces la carga de trabajo es tan alta, o la organización del equipo no es todo lo eficiente que debería ser, que no hay tiempo para corregir estos problemas de raíz y en lugar de corregir el código que produce los bugs ponemos parches que dan una patada hacia adelante a los problemas. Tampoco tenemos tiempo para refactorizar el código y aumentarle su calidad de forma que el número de errores tan alto que se come todo el tiempo de desarrollo. El problema llega a ser tan preocupante que, incluso cuando nuestro contrato incluye tareas de mantenimiento evolutivo, la corrección de bugs nos consume todo el tiempo disponible evitando que añadamos más valor a nuestro producto.

Si intentamos usar Scrum para poner orden en esto probablemente no nos vaya a funcionar porque semana tras semana nuevas tareas de corrección de bugs nos asaltan de forma urgente en nuestra planificación del sprint impidiendo que lleguemos nunca a cumplirlo. Retomar el trabajo días después hace que tardemos aún más debido a los cambios de contexto y porque nos vemos asaltados de nuevo por más bugs urgentes. Las planificaciones de los sprints no serán nada fiables, el análisis hecho para las nuevas funcionalidades caducará o habrá que revisarlo y ningún sprint se cumple.

Yo utilizaría Kanban en lugar de Scrum en una primera fase de estos proyectos. El uso de Kanban conlleva un menor cambio cultural en el equipo de trabajo y en los clientes y una menor sobrecarga de reuniones pero sobre todo permite una mayor agilidad para dar entrada a tareas urgentes en medio de la carga de trabajo de la semana.

En este Kanban utilizaría tres códigos de tarjetas de colores: Rojo para las tareas de corrección de bugs, amarillo para las tareas que corrigen deficiencias técnicas y code smells en nuestro código y que están haciendo que el código sea difícilmente mantenible o están produciendo bugs de forma continuada. Por último utilizaría el color verde para las tarjetas que implican el desarrollo de nuevas funcionalidades.

Tampoco separaría el equipo en dos partes, uno para corregir bugs y otro para desarrollar nuevas funcionalidades. Hacer eso está reconocido como una mala práctica debido a que los equipos dedicados a los nuevos desarrollos no aprenden lo que pasa cuando se introducen errores y por otro lado se castiga a los equipos de mantenimiento a que sólo arreglan desaguisados y con prisas y tampoco crean nada nuevo que aporte valor y reconocimiento al equipo.

En un principio nuestro Kanban estará lleno de tarjetas de color rojo pero si logramos introducir nuevas tarjetas de color amarillo y subirles la prioridad a aquellas que solucionan un número alto de bugs, en un periodo prudente de tiempo deberíamos conseguir bajar el número de bugs que se están produciendo obteniendo tiempo así para añadir al Kanban más tarjetas amarillas o incluso verdes.

Con el paso del tiempo, nuestro tablero Kanban deberá mostrar un reportorio más amplio de colores en el que finalmente, con suerte, predominará el color verde. Para esto sirven los tableros visuales Kanban, para dar visibilidad a lo que está sucediendo en nuestros proyectos.

Es en este momento, en el que el equipo realiza sobre todo tareas de mantenimiento evolutivo, cuando podríamos volver a pensar en utilizar Scrum para nuestro proyecto bajando un poco el factor de dedicación para solventar aquellas tareas urgentes que nos llegan ahora con menor asiduidad.

Error nº 9: Apretar demasiado en el objetivo del sprint

Es el equipo el que decide qué funcionalidades caben en un Sprint y cuáles no. Los miembros del Equipo de Desarrollo son los que mejor saben cómo se hace el trabajo y los que por tanto mejor pueden calcular si en el sprint caben seis u ocho historias de usuario o lo hacen a 10.
Si viene presión de fuera para que metan más cosas en el Sprint y que se comprometan a entregar más trabajo cuando realmente no lo ven factible, esto sólo puede hacer que se acumule el resentimiento o la desconfianza o que se fomente la baja calidad del trabajo para poder entregar a tiempo. Se sabe que cuanto más ridículos son los plazos de entrega más tiempo y dinero se malgastan en intentar conseguirlos.
Cuando se planea la cantidad de trabajo que podemos hacer, se planea un tiempo para las pruebas que necesitamos hacer y asegurarnos de que el trabajo es fiable. Se planifica también una cantidad de tiempo razonable para pensar y estructurar el desarrollo. Si falta tiempo para hacer estas cosas, la calidad del trabajo se resentirá y, más adelante, en próximos sprints o después de finalizado el proyecto, pagaremos esta deuda que hemos dejado atrás con intereses de demora convertidos en bugs que nos asaltarán en los momentos más inoportunos y que reducirán el nivel de satisfacción de nuestros usuarios.
Otra cosa es que el Equipo de Trabajo se sienta retado a conseguir más cosas dentro del Sprint y que se sientan con ánimo de conseguir mucho en poco tiempo. Si conseguimos un ambiente así, en el que los desarrolladores se comprometen por sí sólos al máximo alcanzable por ellos, habremos conseguido un gran objetivo y tendremos un gran equipo.
SI QUIERES CONTRATAR MIS SERVICIOS PUEDES ENCONTRARME EN:

Tel: +34 690317539
Skype: antoniomartel
admin@antoniomartel.com

Haz clic en la imagen para obtener tu copia del libro gratis

Conéctate

facebook twitter google linkedin rss youtube