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.
22 abril, 2010 - 23:56
Algunas grandes verdades amigo Mario (as usual!).
Un apunte que “me ha venido”: TIEMPO invertido NO implica necesariamente CALIDAD.
Aunque la “inteligencia”, como en eso de la valentía en no-sé-qué-ejercitos, se nos supone, cuántas veces no te has encontrado tirando líneas por quintales, buscando *la calidad* pero acabas más liado que la pata de un romano, sin haber conseguido la tan deseada calidad, habiendo perdido el tiempo y el control “de la bestia”
Tenemos demasiada facilidad para “procastrinar”? – YAGNI dixit -
23 abril, 2010 - 08:25
@rgmadariaga es cierto que el TIEMPO invertido NO implica necesariamente CALIDAD.
Lo primero que hay que tener es definido cual es el criterio de calidad en el equipo. Según el criterio de calidad está claro que afectará en la velocidad del equipo.
Intentando no llegar a liarse haciendo naves espaciales (que a veces pecamos en ello) para realizar funcionalidades inmediatas.
Cuando intento hablar de criterio de calidad, es en el orden del código y en la documentación generada, claro está tiene que funcionar. Otra cosa es que se pueda debatir como se ha implementado la funcionalidad a nivel de código.
El error de llegar a “ostiarse” haciendo naves espaciales está en intentar crear más de lo que necesita la funcionalidad. Si te centras en la funcionalidad y refactorizas no tendría que haber problema.
Otra cosa es el no tener claro cómo vas a hacer algo y entonces buscando calidad en funcionalidad te creas un monstruo que cuando quieres dejar fino algo te mueres… Creo que a todos nos ha pasado alguna vez
A veces puede resultar difícil decir “hasta aquí” a veces tenemos que contar con el beneplácito del “cherif” para saber hasta donde podemos llegar, porque nos podemos “pajear” hasta el infinito y más allá!