Ajedrez - antoniomartel.com

Archivos por Etiqueta: ventajas 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

5 lecciones aprendidas en la gestión de proyectos

Siempre que acabo un proyecto procuro hacer balance de lo que fue mal o de lo que fue bien en él, de lo que intenté y no funcionó o de lo que debo anotarme para no volver a hacer. Incluso cuando el balance final lo he considerado negativo, puede que el proyecto haya merecido la pena si en el siguiente proyecto no vuelvo a cometer los mismos errores.

De algunos de esos balances he extraído aquí cinco de las lecciones más importantes que he aprendido. Algunos son errores de principiante, otros los debería haber resuelto la simple lógica pero no me resultaron tan evidentes cuando estaba en ello. Ahí van:

La agilidad funciona

Es difícil de cuantificar pero desde que comencé a usar Scrum en mis proyectos, el número de horas invertidas por funcionalidad bajó y en mi opinión lo hizo bastante. Simplemente haciendo el seguimiento diario durante 15 minutos, mantener la gráfica del estado del proyecto que nos indica si vamos bien o no y las entregas cada dos semanas nos permitieron obtener el 80% de las ventajas de Scrum. Además, a los clientes parecía aportarles cierta tranquilidad que de forma consistente cada dos semanas se entregara y mostrara lo que se había acordado dos semanas antes. En los meses de julio y agosto, cuando no eran posibles las reuniones, el envío semanal de un simple documento de dos páginas con el porcentaje de realización de cada funcionalidad y dos párrafos explicando el porqué de esos porcentajes, ayudó a recuperar credibilidad en un proyecto difícil (especialmente cuando en septiembre se pudo comprobar que los porcentajes eran reales)

Todo no es positivo en Scrum

Se requiere de bastante más dedicación del Scrum Master de la que tendría si solo jugase el papel de jefe de proyecto. En esos 15 minutos de seguimiento diario te van a contar un montón de dificultades que se necesitan resolver para seguir avanzando. Intentar resolverlas te va a llevar el resto de la mañana.

Por otro lado, tener una entrega cada 2 semanas puede ser agotador. No se puede estar esprintando durante meses. Al cabo de seis meses se termina trotando (y eso con suerte) Es necesario tener esto en cuenta desde la primera planificación.

Por último, y no por ello menos importante, Scrum no es magia. Uses la metodología que uses necesitarás un equipo formado en el trabajo a realizar, dispuesto a arrimar el hombro y con ganas de aportar. Equipos así no crecen en los árboles. Si cuentas con uno, la misión del jefe de proyecto será estorbar lo menos posible.

Incorporar más trabajadores al equipo no consiguirá más que ralentizarlo

Bueno, esto ya se decía desde hace un montón de años en el libro The Mythical Man-Month. Aún así es necesario recalcarlo, no hay excepciones a la regla. No importa lo ajustado que sean los plazos: nueve personas no pueden crear un bebé en 1 mes.

¿Quién es el dueño de todo esto?

Da igual cómo lo llamemos: identificar a los interesados, designar el product owner o hacer partícipes a los stakeholders. Al final necesitaremos saber quién va a validarlo en realidad. Y no me refiero a quién va a firmar la factura. Necesitarás conocer también a quién va a usar el producto. El proyecto sólo será un éxito si después de entregarlo funciona y es útil.

En algún proyecto el director de área nos facilitó toda la documentación, validó las entregas parciales, testeó toda la aplicación y nos felicitó por el trabajo realizado. Lamentablemente, cuando su secretaria acudió a la sesión de formación una semana antes de la puesta en producción nos dijo: ‘Esto no me sirve: esa ya no es la plantilla correcta y necesito recoger datos diferentes de los que ahí pone’. Esto significó una semana de horas extra y esfuerzo adicional además del riesgo de poner en producción un producto que podría ser inestable.

Producto Mínimo Viable

Si ya tienes algo que puede ser útil al usuario, entrégalo, ponlo en producción, sácalo a la venta. No esperes a tener todas y cada una de las funcionalidades terminadas. Si recuerdas el principio de Pareto con sólo el 20% de ellas conseguirás completar el 80% de los usos que tendrá tu producto.

Cuando esté en producción comenzarás a obtener las impresiones de los usuarios. Ellos sabrán con mayor exactitud qué es lo que de verdad necesitan y tú sabrás qué has hecho mal y cómo puedes mejorarlo. Si apuestas por una única entrega final sólo cuentas con una única bala para acertar en la diana (haber hecho esto nos habría ahorrado un montón de problemas con el producto mencionado en el punto anterior)

Estas son mis lecciones aprendidas. Espero que a alguien le sirva de ayuda como lo hizo para mí.

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Libro Gestión práctica de proyectos con Scrum

Ventajas y desventajas de SCRUM (II)

No quisiera convertirme en uno de esos evangelistas de lo Ágil que pregonan por doquier lo bueno y moderno que es ser Ágil. He puesto en práctica alguna de estas técnicas y he obtenido buenos resultados con ellas, así que en este post les voy a contar la parte positiva de una metodología como SCRUM (post obligado después de hablar sobre las desventajas de SCRUM en una entrada de mayo)

Me voy a centrar en las ventajas de una de sus características fundamentales: Las Entregas Periódicas. Nuestro cliente recibe cada poco tiempo una entrega de lo que estamos haciendo. Esto le va a permitir:

Que comience a usar ya su producto 

El cliente puede decidir poner en marcha el producto aún cuando no están todas las características construidas. Cuando se haya desarrollado el 20% de las nuevas funcionalidades, que son las que serán usadas el 80% del tiempo, el producto puede comenzar a andar.

Con el feedback de los usuarios podríamos darnos cuenta de que hay nuevas funcionalidades que son mucho más importantes que el 80% de las tareas que aún teníamos por hacer en la pila del producto. Alguien puede decirnos «pero si el borrador del nuevo decreto ya no exige la entrega de la autorización firmada» o «en realidad lo que necesitamos es un botón para poder cancelar el trámite» (dos experiencias reales)

Que pueda decidir hacia dónde vamos

Los negocios cambian, las necesidades varían, nuevas normativas aparecen. Lo que era muy importante cuando se firmó el contrato podría no serlo meses después. El cliente puede decidir los nuevos objetivos, qué hacer en el nuevo Sprint y en qué debemos trabajar para la próxima entrega.

Divide y vencerás

Las tareas titánicas requieren de esfuerzos del mismo orden. Si debemos entregar solo una parte de esa tarea cada dos semanas la carga se nos hará más llevadera. Tareas más pequeñas y abordables harán que nos parezca menos difícil el trabajo y que con cada entrega tengamos la sensación de estar dando un nuevo paso hacia la meta final.

Menos sorpresas

Viendo crecer el producto poco a poco todos vamos a tener una idea de qué estamos haciendo con él y si nos va a ser útil o no. Además, con relativa exactitud sabremos a qué ritmo se están entregando cosas y cuánto tardaríamos en tenerlo acabado. ¿Es necesario tomar medidas para corregir el rumbo? Lo sabríamos en semanas.

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

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

Cómo ayuda SCRUM a construir catedrales

Revisitando el post de Raúl Hernández González con el título ‘Aprendiendo a construir catedrales‘ también he comenzado a darle vueltas a esa conocida historia. En ella, a dos obreros que se encuentran picando piedra para la construcción de una catedral, se les pregunta qué es lo que hacen. Mientras uno responde sobre lo penoso e interminable que es construir el muro en el que está trabajando, el otro responde simplemente que él está construyendo una catedral.

Me he preguntado si se puede ser Ágil cuando uno construye algo tan grande. Creo que la respuesta es que sí. Por lo menos a mí se me ocurren algunas ventajas a ser Ágil cuando se está inmerso en un proyecto del tamaño de una catedral:

Con un framework como SCRUM siempre tendrás presente el objetivo final y las características que se quiere que tenga. En la pila del producto tendrás una lista de requisitos como la construcción de la planta, levantar la bóveda, decorar puertas o ventanales y otras muchas cosas que darán forma a la catedral final.

Pero una vez definido el objetivo hay que ponerse a picar piedra. Al comienzo de cada iteración, el equipo elegirá qué tareas puede acometer de entre la lista de cosas por construir (siempre priorizadas por nuestro cliente). Se definirá un objetivo más pequeño para el Sprint actual por lo que tendremos una nueva meta, mucho más cercana, que no permitirá que desesperemos por lo lejos que está la meta final. Es el momento de coger martillo y cincel.

Al separar las tareas a realizar en pequeños grupos y tratar de resolverlos en periodos fijos de tiempo (timeboxed) cada uno con su propia meta, tiene las ventajas de la estrategia del ‘Divide y vencerás’. Planeas tu objetivo más inmediato y lo que vas a hacer para resolverlo sin abrumarte con todo el trabajo que aún queda por delante. Una gráfica burn-down ayudará también a ver que el trabajo restante va disminuyendo y que, por lento que nos pueda parecer, avanzamos hacia nuestro producto final, la catedral.

Queda claro el marco de trabajo, ahora, manos a la obra …

Suscríbete