Ajedrez - antoniomartel.com

Archivos por Etiqueta: Ágil

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.

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.

El Dueño del Producto

El Dueño del Producto (Product Owner) es el responsable de gestionar la Lista o Pila del Producto (Product Backlog) con la lista de funcionalidades que deberá tener el producto. La gestión de esa Pila del Producto implica que es también el responsable de que el producto final tenga el mayor valor posible y para ello deberá obtener el máximo valor del trabajo del Equipo de Desarrollo.

Para gestionar esa Pila del Producto deberá:

  • Expresar claramente los elementos de la Lista para que queden claros para todos y que esa Lista muestre  en qué estará trabajando el equipo en los próximos Sprints.
  • Asegurarse de que el Equipo de desarrollo entiende los elementos de la Lista con el detalle suficiente. El Dueño del Producto conoce bien su producto y lo que se quiere conseguir con él, por tanto es el responsable de que cada funcionalidad a implementar está bien detallada y explicada para el Equipo de Desarrollo.
  • Ordenar los elementos de la Lista de Producto para obtener los objetivos que tiene el producto lo antes posible, priorizando para ello los de más valor para el producto en el mercado o en su organización.
  • Optimizar el valor del trabajo del Equipo de Desarrollo. Para ello deberá hacer que mediante la Pila del Producto debidamente ordenada y priorizada el Equipo de Desarrollo trabaje en las funcionalidades de más valor en cada momento, evitando trabajo redundante o inútil en tareas de poco valor añadido.

Es además la única persona responsable de gestionar esa Lista de Producto. Eso implica que puede estar representando a varias personas o a un comité de Interesados (Stakeholders) en el producto en la empresa cliente que nos contrata o de la propia empresa que desarrolla el producto pero es sólo el Dueño del Producto el único responsable de expresar, detallar, optimizar y priorizar la Pila del Producto. Los Interesados en el producto pueden querer cambiar la Lista, añadir nuevas funcionalidades o darles otra prioridad pero deberán hablar primero con el Dueño del Producto para expresarle sus deseos y sólo él podrá cambiarla.

El rol del Dueño del Producto es un rol fundamental en todo proyecto (se llame como se llame según la metodología) por lo que toda la organización que contrata el desarrollo del producto debe respetar sus decisiones. Él es quién decide qué va a hacerse con el producto y que funcionalidades tendrá por lo que tiene un peso muy grande en que el producto final sea un éxito o no.

No se permite acceder al Equipo de Desarrollo para pedirle que realice funcionalidades distintas a las indicadas en la Lista de Producto. El Equipo de Desarrollo deberá actuar siempre en función de lo que diga el Product Owner y no cualquier otro Interesado en el producto.

Dudas sobre Scrum

Un lector de este blog me preguntaba hace ya algún tiempo algunas dudas que le surgían en el uso de Scrum en sus proyectos. Algunas de ellas pueden ser bastante comunes a otros equipos de Scrum o que yo mismo he tenido cuando intentaba aplicar Scrum. Aquí les pongo algunas de estas respuestas (sería la solución que yo aplicaría en los tipos de aplicaciones que conozco pero puede que no sea el mismo tipo de proyecto/equipo/producto/etc.).

¿Qué pasa cuando una historia de usuario requiere análisis que debe ser desarrollado en el propio sprint?¿el resto del equipo que no analiza se pone con otras historias de usuario del Sprint Backlog?
La historia de usuario es ya parte del análisis y debería estar bien definida y concretada cuando se va a comenzar un sprint. Es cierto que en ocasiones, cuando el equipo de trabajo comienza a realizar la tarea puede encontrarse con dudas o puntos que no tienen claro. Debería bastar con una llamada al Cliente o una breve reunión para resolverlo.
Es un punto complejo éste. Es cierto que es habitual que el desarrollo pisa al análisis y llegue la hora de desarrollar funcionalidades que aún no están bien analizadas. Para esto es bueno mantener reuniones frecuentes con el cliente para ir avanzando y concretando tareas previstas para más adelante de forma que a la hora de planificar el sprint éstas funcionalidades estén listas para comenzar. Si aún así el desarrollo sigue encontrando tareas que aún no están bien descritas quizás deba dedicarse una parte mayor del equipo a analizar y concretar estas tareas en lugar de a desarrollar.
¿Qué ocurre con un equipo que mezcla seniors y juniors con grandes diferencias salariales?¿van a empujar todos con la misma intensidad? 
Bueno, en principio, se supone que la diferencia salarial corresponde a su nivel de experiencia y saber hacer en su trabajo por lo que los junior cobran menos. Conocen aún poco sobre la tecnología o el producto y que, a medida que van aprendiendo y adquiriendo experiencia esta diferencia se acorta o desaparece.
Si algún miembro del equipo entiende que no cobra a razón de lo que está aportando es cierto que puede perder el ánimo o las ganas de trabajar. Aquí entramos en un asunto de recursos humanos en lugar de Scrum pero yo le aconsejaría que comente con sus responsables el trabajo que ha realizado y lo que ha podido aportar y vea con ellos si tienen la misma percepción sobre esto y consideran que en algún momento puede hacerse una revisión de su salario.
¿Qué ocurre cuando el Team auto-gestionado tiene que tomar una decisión técnica?¿vale igual el voto de un senior que el de un junior?
Yo no pondría valor a los votos del equipo de trabajo. A veces la mejor idea puede venir del que lleva menos tiempo en el trabajo, aunque lo habitual sea que los senior sean los que más aporten en la discusión que llevará a la decisión técnica que finalmente se tome.
Algo que he utilizado a veces es escribir en una pizarra las ventajas e inconvenientes de cada solución. A veces, nada más terminar de escribir esos pros y contras todos nos damos cuenta de cuál es la solución que más conviene ahora. Otras veces esto no está tan claro y hay que apostar por una aunque no haya consenso.

Cuidado si la opción por la que se apuesta es siempre la de ‘hay que hacerlo así ahora porque no tenemos tiempo‘. Es verdad que a veces es la solución que se debe tomar ante una urgencia. Explícale bien al equipo de trabajo el por qué de esta decisión en estos momentos pero explícale también al Cliente que ahí ha quedado un asunto por resolver que deberá ser programado para un próximo sprint si no queremos que esa deuda técnica nos acumule más errores pronto. Si no hacemos esto, con los años, el proyecto se nos puede convertir en uno de esos proyectos en los que todo el equipo de trabajo está resolviendo bugs y no nos queda tiempo para desarrollar nuevas funcionalidades.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

 

Las cosas se hacen bien pero no demasiado bien

Esa es una frase que escuche en una ocasión a un médico cuando la enfermera le preguntaba si debía usar un tipo u otro de catéter. Lo que quería decir el médico era que no había necesidad de usar el catéter más caro, complejo o difícil de poner si con el más sencillo lográbamos lo mismo.

Es una regla útil para aplicarla en nuestros proyectos de trabajo o personales. Nos pasa cuando vamos a entregar una propuesta o un presupuesto, cuando simplemente debemos enviar un email o un informe o cuando tenemos que entregar una nueva versión de nuestro producto.

A veces lo hacemos por un perfeccionismo excesivo que nos hace pensar que nuestro producto debe tener las mejores características del mercado en todas y cada una de las funcionalidades. Cuando acabemos habremos terminado orgullosos de él pero, qué coste tiene el producto si tiene el Wifi más avanzado, el Bluetooth de mejor rendimiento y el mayor número de puertos USB ¿te lo comprarán a ese precio?

Y cuando por fin hayas decidido poner el producto en el mercado después de tantos meses de trabajo puestos en él ¿se seguirá usando el Bluetooth? ¿el número de puertos USB seguirá siendo una decisión relevante en la compra? Probablemente no.

Quizás era mejor haber planificado una fecha de lanzamiento, el próximo Black Monday por ejemplo, y calcular qué opciones nos da tiempo de construir para entonces. Seguro que en el mercado habrá productos más completos pero ¿serán tan económicos como el tuyo? ¿son tan fáciles de usar o pesan tan poco como tu producto? ¿tus competidores estarán teniendo tanto margen comercial como tendrías tú?

Cuando Google lanzó su Google Docs en la nube, los periodistas especializados fueron corriendo a preguntar a Microsoft por esta nueva amenaza a su MS Word. Google Docs era gratis y podía usarse desde cualquier ordenador sin instalación o licencia alguna. Steve Ballmer contestó de manera un tanto despectiva que Google Docs nunca a sustituir su clásica suite Office. En la nueva aplicación de Google ni siquiera era posible imprimir los documentos que escribías.

La respuesta de Google fue rápida. Al día siguiente Google Docs tenía implementado un botón Imprimir en su barra de herramientas ¿Cómo pudo haber hecho esto Google tan rápido? Sencillo, Google Docs no tiene funcionalidades complejas. Sólo hay 5 ó 6 funcionalidades en un único menú. Son justo las funcionalidades que necesitan el 90% de los documentos que escribimos.

No había mucho que desarrollar tampoco había mucho que probar. Debieron usar una librería de exportación a PDF estándar que recoge las características básicas y listo. No hay complicadas opciones de numeración, viñetas, estilos, fuentes o formatos. Sería una librería muy probada para esas pocas opciones por lo que no había mucho donde fallar.

En tu trabajo diario te puede pasar lo mismo. Puedes estar días y días buscando una diferencia de 1 céntimo entre el Debe y el Haber, pero mientras, el informe de pérdidas y ganancias está sin hacer.

Puedes hacer un versión de tu software para iPad, para tablets, para smartphones, para Chrome, Firefox Internet Explorer y Safari. Mientras tanto alguien está ganando dinero ya con su app para el iPhone pero sobre todo sabrá ya a estas alturas si merece la pena sacar una versión para Android o si estará tirando su tiempo y su dinero si lo hace.

Evita la procastinación, el miedo a fallar o a las críticas si tu producto no es el mejor de todos los que hay en el mercado o no se vende bien. Si eso pasa, bueno, por lo menos no invertiste demasiado en ello. Ve a por el siguiente o trata de mejorarlo en una siguiente versión (Kaizen lo llamaría yo). Ahora ya sabes qué es lo que no funciona y podrás probar de nuevo.

Suscríbete