Estuve en: ALM’09 Sessions

El pasado martes estuve participando como ponente en las ALM’09 Sessions. Un exitazo de evento que reunión a más de 800 profesionales interesados en mejorar la gestión del ciclo de desarrollo de sus aplicaciones. La agenda que propuso Microsoft y la calidad de los ponentes tubo una clara respuesta. Plain Concepts era uno de los patrocinadores del evento y colaboramos con tres charlas. Yo hablé en el track de procesos, mi compañero Jose Luis Soria hablo de ecosistemas heterogéneos de desarrollo y Team System, y mis compañeros Pablo Peláez y Ricardo Acosta, hablaron de como integrar a los diseñadores en el ciclo de vida.

Como no podía ser de otro modo hablé de Scrum, aderezándolo esta vez, con un poco de buenas prácticas y con un tema que cada vez me preocupa más, la gestión de la configuración en equipos ágiles. El motivo es que veo cada vez más aberraciones de arquitectura, complejidad innecesaria y disfunciones en el ciclo de vida que se pueden solucionar con una política de gestión de la configuración. La gestión de la configuración es una de las ramas más desconocidas, más infrautilizadas y peor utilizadas cuando se usa, de la ingeniería del software.

Os dejo la presentación que realice:

Como siempre, lo mejor en este tipo de eventos fue la oportunidad de charlar con compañeros de la comunidad, amigos, clientes y gente interesada en la gestión de sus proyectos y las tecnologías de Microsoft.

¡Un saludo!

Estuve en: Foro de arquitectos sobre VSTS 2010 en Santander

Gracias a la amable invitación de Juan Carlos, MVP y miembro del CIIN fui invitado junto a Ibon Landa y Juan Irigoyen, a participar en un evento en Santander. El evento consistió en una reedición del Foro de Arquitectos (podéis seguir el link si queréis la ppt) en el que había participado en Madrid y Barcelona.

El evento reunión a tres decenas de profesionales del mundo informático cántabro, entre los que quiero resaltar al compañero de Geeks.ms Miguel Sierra, más que nada por que en la comida posterior al evento hubo mucho debate muy interesante sobre CMMI vs. Scrum y la idea de realizar ese debate en forma de evento… ¡algo que seguro que haremos!, estad atentos.

Sodercan TV siguió el evento y publicó una pequeña reseña sobre el evento. Desde luego no se quien eligió los cortes, pero en lo que a mi respecta… no me parece que me quisiese bien ;).

¡Un saludo!

¡Un saludo!

Exprimiedo Scrum: Scrum y el triangulo de la gestión de proyectos: la calidad

Triangulo Escribía hace un tiempo sobre el triangulo de gestión de proyectos y la férrea dictadura que impone sobre la gestión de proyectos. En esencia, uses la metodología que uses para la gestión de proyectos o incluso si no usas ninguna hay cuatro factores sobre los que, como gestor de proyectos, puedes llevar a cabo tu gestión: la calidad, el alcance, el coste y el tiempo. De todos estos factores, el cliente puede controlar como máximo, tres. El cuarto será el que nos permite gestionar. Si el cliente o alguien externo a la gestión del proyecto controla la totalidad de los aspectos ¿que papel nos queda como gestores del proyecto?.

Dado que el dichoso tirano triángulo nos impone su realidad, cabe plantearse una serie de cuestiones sobre el mismo y su relación con Scrum: ¿Cuál es la relación de Scrum con estos factores? ¿Cómo se actúa sobre ellos en Scrum? ¿Cómo condicionan esta metodología? ¿Qué decisiones explicitas han tomado los diseñadores de Scrum sobre ellos? Estas son las preguntas que quiero responder, en la medida de mis conocimientos, con esta serie de post.

Hoy hablaremos de la calidad, desde la perspectiva de Scrum.

La calidad no es opcional, no es un factor sobre el que podamos especular. Ni siquiera lo podemos gestionar explícitamente: cualquier decisión que tomemos puede ser dañina, vaya esta en el sentido de incrementarla como en el sentido de reducirla. Es un aspecto que siempre decide el cliente no quien gestiona el proyecto. Si decidimos recortar calidad para ganar velocidad, por ejemplo, tarde o temprano lo pagaremos si la calidad que logramos no es la que el cliente está dispuesto a aceptar.

El riesgo, ocurre a menudo, es sobrereaccionar. Para asegurarnos de que cumplimos las expectativas ponemos más calidad de la necesaria en el proyecto. El problema es que la calidad adicional tiene un coste, pero sin embargo, no es percibida por el cliente. Suelo poner siempre el mismo ejemplo, que explica muy bien este asunto, solo es un ejemplo, que nadie se quede con los valores absolutos. A mi me gusta el vino, el buen vino, estoy dispuesto a pagar por un vino de cierta calidad. Si alguien me quiere regalar vino, que no se gaste más de 25 euros, ni menos de 10. Por debajo de 10 euros, es probable que el regalo no cumpla su cometido de agradarme, por encima de 25, estará tirando el dinero, ¡mi paladar no es capaz de distinguir un vino de 25 euros, de uno de 35!. A partir de 25 euros todos los vinos me parecen excelentes. Descubrir el nivel de calidad que satisface al cliente al menor coste, es nuestra principal labor a la hora de gestionar la calidad.

El otro aspecto clave la gestión de la calidad es mantenerla a lo largo del proyecto. Es sumamente difícil medir el nivel de calidad de una manera objetiva, precisamente, por que es algo que depende de los usuarios, de los clientes y de su percepción subjetiva. Pero siempre tenemos una idea más o menos intuitiva o analítica (será más analítica si tenemos métricas claras, un proceso de aseguramiento y validación y sobre todo si tenemos testers) sbore cual es nuestro nivel de calidad que nuestro cliente requiere. Y sobre todo de cuan lejos estamos del nivel de calidad que nuestro cliente esta dispuesto a aceptar: ¿se beberá nuestro cliente un Don Simón o un Castillo de Vulpi (dignísimos vinos en brick para calimotxo, pero capaces de corroer una copa de cristal) sin negarse a pagar la cuenta?. Supongamos que no, ¿cómo podemos descubrir que nuestro cliente no se conformará con nuestro Don Simón, sino que quiere mínimo un rioja joven un poco decente y en botella?. Y sobre todo, una vez que lo descubrimos, que sabemos el nivel mínimo de calidad que satisface a nuestro cliente, ¿cómo aseguramos que no estamos elaborando Don Simón?. Por que estaremos de acuerdo en que si estamos elaborando Don Simón es muy muy difícil que al final, hagamos lo que hagamos, logremos que nos salga un Vega Sicilia (¡hay clientes muy exigentes!). Debemos evitar a toda costa darnos cuenta al final de que no hemos alcanzado el nivel de calidad que nuestro cliente requiere, es un riesgo que no podemos asumir.

El único enfoque que funciona, es, sin duda el mantener de manera constante, durante toda la vida del proyecto, un nivel de calidad que sea aceptable al cliente. Si no averiguamos el nivel de calidad que el cliente esta dispuesto a aceptar y no lo mantenemos a lo largo del ciclo del vida del proyecto, a final, cuando los recursos y el tiempo que nos queden sean más bien justos, tendremos que, aunque la funcionalidad este completa, el proyecto se alargará para alcanzar el nivel de calidad necesario.

Las claves son claras: descubrir el nivel mínimo de calidad que el cliente esta dispuesto a aceptar y mantenerse alrededor del mismo durante todo el proyecto. La pregunta es ¿qué mecanismos establece Scrum para que esto ocurra?: El sprint review y los incrementos de funcionalidad potencialmente entregables.

El sprint review, actúa como regulador de la calidad. Por un lado nos va a permitir detectar, mediante el feedback que los asistentes aporten, si estamos lejos o no del nivel de calidad requerido. Además, que el equipo presente las nuevas funcionalidades, es un catalizador clave de la calidad: asegurando una calidad mínima (da mucha vergüenza que te ‘casque’ una demo) y asegurando que el equipo percibe cual es el nivel de calidad mínimo aceptable.

Los incrementos de funcionalidad potencialmente entregables son otro aspecto clave de Scrum. Si algo es ‘potencialmente entregable’, como debe ser el resultado de todo sprint en Scrum, debe cumplir las expectativas de calidad de nuestro clientes (o de su proxy, el Product Owner). Si algo no cumple las expectativas del cliente, no está completado y no se sigue avanzando. Esta es la única manera de asegurar que el equipo no toma atajos sacrificando funcionalidad o no cae en el preciosismo, añadiendo calidad que el cliente no está dispuesto a apreciar y mucho menos a pagar.

Un error habitual es recortar el sprint review o saltárselo, de tal manera que el equipo nunca llega a descubrir cual es el nivel de calidad mínimo aceptable por el cliente o no se asegura que no estamos lejos de este.

En la próxima entrega, Scrum y el triangulo de la gestión de proyectos: El alcance.