Scrum: Velocidad vs Calidad
Un título tal vez algo sensacionalista y poco acertado, pero hace unos días me entró la duda de como afrontar este dilema.
En primer lugar, el concepto de terminado que tiene el equipo tiene que estar claro para cumplir el concepto de calidad, por ejemplo:
- Código documentado
- Documentación técnica
- Refactorización de la tarea (si es necesario).
La velocidad de un equipo puede ser constante si el criterio de terminado está definido y se aplica en todas las historias, pero... ¿cuándo tenemos que dejar de refactorizar y/o optimizar?
No se trata de que en cada tarea de historia optimicemos al máximo el código ya que puede que en la demostración se pidan cambios, pero si intentar tener un criterio para no extenderse. Esto puede ser un problema si eres demasiado perfeccionista o estás desarrollando pensando en el futuro. Es bueno preveer el futuro, pero si nos centramos en la funcionalidad inmediata es más sencillo el ir cumpliendo objetivos.
Si en el desarrollo nos centramos en cumplir funcionalidad podemos ir avanzando en el proyecto a una velocidad mayor, pero si en el criterio de "Refactorización" o de "Homogeneización" de código del equipo no se cumple estaríamos generando deuda técnica para futuras iteraciones.
Creo que lo más difícil pensando en la parte técnica, es el llegar a decir "Hasta aquí..." en cuanto a dejar el código como nos gustaría que estuviese. Los técnicos solemos pecar a menudo en intentar a veces hacer naves espaciales para poder cruzar de acera... (Yo el primero) todos nos gusta tener la sensación de "Esto ha quedado dpm!" por eso el ponerse el tope de no ir más allá de donde realmente tenemos que ir, ya que todo es mejorable hasta el infinito y más allá... 
Obviamente, cuando nos planteamos una iteración centrándonos en mejorar nuestro criterio de calidad la velocidad es más lenta (he descubierto el mundo xD) pero tal vez no en todos los proyectos se pueda tener la calidad que pueda ofrecer el equipo.
Nuestro amigo Ángel Medinilla siempre afirma que la calidad no es negociable, ¿pero hasta que punto?
A la hora de vender un proyecto la empresa podría ofertar productos/proyectos en diferentes calidades? si... penalizando la calidad, pero también podemos comprar diferentes calidades de un coche por ejemplo las gamas de un mismo modelo. El abanico que podría estar ofertando la empresa podría ser diferente, pero también entraría en conflicto con la posible deuda técnica que podría generar el penalizar la calidad de un servicio no siendo rentable entonces para la empresa.
Calidad, calidad de que funciona siempre! pero el resto de la calidad que no se ve podría ser la que podría variar?
Ser ágil, no significa ser rápido.
Haz de Scrum parte de tu vida
Tal vez un título muy generalista pero antes de contar el porqué comenzaré por el principio
La Historia
Tras unos años en el mundo del desarrollo de software, acostumbrado a proyectos gestionados en cascada y con roles con responsabilidad determinada, en un proyecto con un proveedor de outsourcing comienzo a oír la palabra "Scrum". Nos encontrábamos embarcados en un proyecto "bicicleta", se habían recortado funcionalidades para poder entrar en costes, pero el lado comercial era un coladero de funcionalidades con poca comunicación con la parte técnica. La parte técnica era la que estaba involucrada en el proyecto junto con el proveedor. La toma de decisiones con el cliente llegaban a la parte técnica del proyecto con "Es que hay que hacer esto porque se lo hemos dicho al cliente..."
Aunque el acceso a los jefes de proyecto y de área era muy lineal, al final a la hora de exigir responsabilidades cada uno se mantenía en su escalón aunque aguantábamos la carga general conjuntamente. Estábamos obcecados en tener un control excesivo del proyecto, notábamos falta de control y comunicación. El intentar cerrar el acuerdo con el cliente a base de contratos, el recurrir a la oferta y al contrato con el cliente para defender batallas internas de responsabilidades de la perdida que estaba generando el proyecto se estaba convirtiendo en algo frecuente y con ello la sensación de entrar a la oficina con la coraza puesta dispuesto a luchar con el que se ponga por delante.
Al final el proyecto salió, a base de horas, esfuerzos personales y negociaciones con el cliente. Aunque no era el responsable de números, estaba claro que ese proyecto fue una perdida para la empresa.
Os puedo asegurar que tuve muchos dolores de cabeza y roces con compañeros a nivel profesional a causa de este proyecto. Cuando pasa el tiempo te lo tomas a "broma" aquellos días en los que te quedas trabajando 12 o 13h porque "Hay que entregarlo mañana...", "Es para ayer...", "Tiene que estar hecho..." y el trabajo de un día de 13h se echaba a perder. A nadie le gusta invertir su tiempo en algo que luego se tira, aunque a final de mes tengamos la nómina asegurada. Esto causa desmotivación y por lo tanto bajo rendimiento.
Pero algo bueno salió de este proyecto. Scrum llegó a mis oídos y a los de mi jefe de proyecto. Comenzamos a valorar la opción de intentar aplicar Scrum en el equipo y a conocer un poco la metodología. El proveedor de servicios lo utilizaba y a él le funcionaba con sus clientes, ¿por qué no tendría que funcionar con nosotros?
En el siguiente proyecto intentamos aplicarlo. Nos creamos nuestro product backlog a base de funcionalidades y a crear sprints de desarrollo. Funcionaba! el desarrollo comenzaba a ser más visible y el dueño de producto priorizaba las funcionalidades e iba viendo su resultado.
A día de hoy
Bien esto paso hace ya casi un año, ahora en mi nueva etapa profesional he tenido la suerte de toparme con una empresa que cree fielmente en esta metodología.
Hoy ha finalizado un curso de Scrum Master impartido por Angel Medinilla en donde me he sentido identificado en muchos de los ejemplos que ha ido exponiendo a lo largo del curso. Es difícil encontrarse con un comunicador de este calibre, una persona que a parte de transmitir su experiencia, inculcarnos la manera de trabajar de manera ágil también hace ameno el aprendizaje. Sinceramente, la sensación tras finalizar el curso ha sido de: "Vamos a comenzar a utilizar esto al 100%, ya!!... " Con motivación!!
Al identificarme en muchos de los casos de "error" en el desarrollo de software no puedes evitar el que te venga a la mente todos aquellos proyectos en los que "sufriste el parto" y aún así recordar que en ese momento pensabas que lo estabas haciendo de la manera correcta. Ahora simplemente lamento haber conocido esta metodología "tan tarde" pero a tiempo!! que es lo importante y con la suerte de que no tengo que "Luchar" para incorporar esta metodología de trabajo dentro de la empresa, si no que la empresa apuesta por esta metodología al 100%.
Está claro que en la parte técnica es fácil que pueda cuajar esta metodología, pero no es sólo trabajo de los "pica teclas". Introducir esta metodología en una empresa con una estructura piramidal firme y acostumbrada a desarrollar proyectos de manera convencional seguro que es una tarea difícil. Tiene que ser un esfuerzo conjunto por todos los roles que forman parte de la corporación, ya que sin esta convicción el equipo de desarrollo nunca será ágil y la lucha "Técnico vs Comercial" se mantendrá por la eternidad...
Desde mi incorporación hemos utilizado esta metodología y fui adquiriendo conocimientos que no tenía de Scrum, pero el curso ha sido una manera de reflexionar y reforzar esos conocimientos que me estaban transmitiendo mis compañeros de trabajo.
Desarrollar utilizando Scrum es divertido, tengo que reconocer que tengo una fiebre extrema por los gráficos burn down que me presenta Jira pero he aprendido a hacerlos a mano y como interpretarlos con un simple vistazo. No sólo nos han explicado como funciona Scrum, si no la combinación con otras metodologías como Extreme Programing y Kanban.
Conclusión
Hoy estoy tan convencido del uso de Scrum que me estoy planteando la opción de utilizar Scrum para la gestión de mi agenda personal Scrum-Alone
Referencias de interés
Scrum Definición de Scrum en Wikipedia
Programación Extrema (XP) Definición de Programación Extrema en Wikipedia
Kanban Definición de Kanban en Wikipedia
http://www.presionblogosferica.com/ Blog de Angel Medinilla
http://www.agile-spain.com/ Comunidad sobre métodos ágiles.
http://groups.google.es/group/agile-spain Lista de correo de la comunidad de Agile Spain