Mis respuestas sobre Scrum

Planteaba Carlos Junquera Cachero en su blog una serie de dudas sobre Scrum. Esto empezó  siendo un comentario a ese post, pero se alargo lo suficiente como para ser un post con vida propia.

La respuesta a las preguntas es que salvo a una, Scrum no da respuesta absoluta a ninguna de ellas. Es más las metodologías modernas, en general, no dan respuestas absolutas. El desarrollo de software es un problema complejo en el que las repuestas absolutas no existen. La buena noticia es que a veces si que se pueden dar respuestas claras que funcionan en un amplio rango de situaciones.

Antes de nada, comenta Carlos que no es bueno que una empresa se centre en una única metodología. Yo no comparto esta opinión, sobre todo si se trata de una empresa pequeña o mediana. Si bien es cierto que ninguna metodología es de universal aplicación, el problema de las metodologías es que todas, incluso la más simples, exigen un proceso más o menos costoso de implantación. Todas exigen un esfuerzo notable de aprendizaje y adaptación de la metodología. No es muy optimo, en mi opinión, pagar este peaje en múltiples ocasiones. Todas las metodologías, hoy en día, tienden a ser más descriptivas que prescriptivas y como tal constituyen más marcos metodológicos (la mayoría incluso así lo dicen explícitamente) con un amplísimo rango de aplicación. Nos dicen qué debemos hacer pero no el cómo. El cómo es lo que depende de cada empresa, de cada proyecto, de cada equipo incluso. En el ‘cómo’ es además donde se encuentra la dificultad. Descubrir cómo llevar a cabo una metodología es el 90% del coste de la implantación de una metodología e insisto buscar ese cómo no es algo que yo quiera hacer dos veces. Scrum, MSF Agile, RUP o CMMI, por citar algunas de las más populares, son metodologías de amplio espectro, aplicables a una enorme variedad de proyectos. Todas en alguna ocasión han demostrado ser perfectamente útiles. Una funcionará mejor que otra para tal o cual tipo de proyecto. Pero esa diferencia es mínima, no cubre el coste de conocer, implantar, utilizar y ajustar dos metodologías en la gran mayoría de los casos.

El problema es, que ese ‘como’ del que hablo, la manera en que nosotros llevaremos a cabo una metodología, es algo que solo nosotros podemos descubrir. Léase nosotros como nuestra empresa o nuestro equipo, según el rango de aplicación de la metodología. Contar con alguien que ya haya encontrado ese ‘como’ en otras ocasiones para que nos allane el camino puede ser muy útil, incluso marcar la diferencia entre el éxito y el fracaso, porque muchas implantaciones de una metodología nunca llegan al ‘como’ o llegan a un ‘como’ erróneo.

Una vez dicho lo anterior, que solo es mi opinión basada en mi experiencia de haber vivido unas cuantas implantaciones de metodologías, unas exitosas y otras no, voy a comentar las respuestas que yo daría a las preguntas del vecino de blog:

Empezando por la que tiene respuesta clara, ¿debe de existir una demo, un ejecutable, que el Product Owner podría coger y poner en producción?: Si, al final de cada sprint se debe demostrar lo desarrollado durante el mismo y solo se puede presentar funcionalidad ‘hecha’, esto es uno de los pilares de Scrum, y por lo tanto no es opcional. Idealmente ‘hecho’ significa ‘algo que se puede poner en producción’, aunque el significado de hecho se puede establecer según las necesidades y limitaciones de cada proyecto. Eso si, cuando el significado de ‘hecho’, no es el anterior, el nuevo significado debe ser conocido por todos los implicados en el proyecto. No me extiendo más, simplemente os remitio a las reglas de Sprint Review.

Otra pregunta, ¿es mejor crear un único sprint para el análisis y el diseño?: Si te planteas esta pregunta es que deberías volver a leer todo lo que hayas leído sobre Scrum (o sobre cualquier otra metodología iterativa en general y ágil en particular). !No hay fases largas de análisis y diseño! El análisis y diseño, es algo que se hace en línea con el desarrollo, o como mucho de manera más intensa durante el inicio del Sprint. Otro tema es la arquitectura, a menudo se plantea un Sprint 0, que tiene como objetivo poder dedicar un tiempo a trazar y discutir una arquitectura inicial para el sistema, establecer a grandes rasgos los pilares arquitectónicos sobre los que se construirá el software. Ojo que esto no quiere decir que una vez cerrado el Sprint 0 la arquitectura este ‘congelada’. La arquitectura es algo vivo que evoluciona a lo largo de todo el proyecto. Resumiendo: no hacemos desarrollo en cascada, si en algo están de acuerdo todas la metodologías modernas es que el único ciclo de vida que puede funcionar es el iterativo e incremental.

La siguiente pregunta también es típica de alguien que se aproxima por primera vez a Scrum ¿Hay que definir inicialmente las personas que estarán en el proyecto desde el principio hasta el fin, permitiendoles tomar decisiones u opinar en el backlog de un sprint, pese a no pertenecer a dicho sprint? O ¿Una persona solo entra en el Scrum Team en el momento que va a realizar un sprint, y cuando no es mas necesario para la realización de mas sprints sale del equipo?. No olvidemos que el equipo en Scrum es un rol central. Nada es más importante que el equipo en Scrum. Luego parece que la respuesta evidente es que algo tan importante debe establecerse pronto. El equipo es quien llevará a cabo el proyecto, esto no quiere decir que en momentos puntuales (durante el despliegue y la integración por seguir con el ejemplo de Carlos) el equipo pueda contar con la ayuda de terceros. Pero no olvidemos que el equipo en Scrum debe ser multidisciplinar y que por lo tanto, debería contar en su interior con todo el conocimiento necesario para llevar a cabo el proyecto. El pensar que existen roles que solo intervienen en ciertas partes del proyecto es ‘erróneo’ si usamos Scrum. En Scrum, el enfoque es que si se necesita alguien con conocimientos en integración de sistemas, este debe estar presente desde el principio del proyecto: quien mejor que el para diseñar las interfaces que debe exponer la arquitectura, quien mejor que él para diseñar los contratos de datos a intercambiar, quien mejor para implementarlos o guiar a quien los implemente, quien mejor para participar en la fase de despliegue e integración?. Ninguna actividad en el ciclo de vida de un proyecto se realiza en completo aislamiento de otras. En Scrum, un mismo equipo debe ser capaz de llevar a cabo todas las actividades y cuando encuentre impedimientos siempre puede recurrir, puntualmente, a expertos ajenos al equipo.

Espero haber arrojado un poco de luz sobre las interesantes dudas planteadas por Carlos, decir que si puedo dar mi respuestas es porque yo ya las tuve antes.

9 comentarios sobre “Mis respuestas sobre Scrum”

  1. Muchas gracias Rodrigo.

    La verdad es que había cosas que no sabía muy bien donde encajarlas, y me has proporcionado una grandisima ayuda, primero con tu repositorio sobre scrum, y ahora contestandome a esto.

    ¡¡No dudes que seguire lanzando preguntas sobre Scrum!!

    Muchas gracias de nuevo!

    Un saludo. Carlos.

  2. Aupa Carlos!!!

    Si tu lanzas las preguntas, en la medida de lo posible, yo te daré al menos ‘mis’ respuestas!!!

    Un saludo y suerte con Scrum!!!

  3. Hola:

    Estoy pensando en usar Scrum en el trabajo, sin embargo se me plantean un par de dudas.

    Se supone que el Sprint backlog una vez establecido no se toca. Supongo que en las fases finales del Sprint puede haber gente desocupada: no quedan tareas sin iniciar y quizás los que tienen las últimas puedan tardar todavía un par de días. ¿Qué se hace con esa gente?

    Una duda similar se me presenta con las parejas de XP. Para cambiar parejas … ¿hay que esperar que dos parejas terminen sus historias de usuario simultáneamente? ¿o se cambian las parejas con las historias a medio terminar?

    Volviendo a Scrum, ¿Qué pasa si las estimaciones iniciales no estaban todo lo bien que debían y se acaba (o se ve que se va a acabar) demasiado pronto o demasiado tarde?. Entiendo que si se acaba muy pronto, mejor, se empieza otro Sprint antes. Pero, si se va a acabar más tarde … ¿símplemente se retrasa la fecha de finalización del Sprint?

    Se bueno.

  4. Aupa chuidiang!!!

    Interesantes preguntas las tuyas:

    Nunca se debe terminar un sprint antes de lo planeado y mucho menos alargarlo. Si empiezas a alargar sprints, todos se van a alargar, y Scrum pierde su razón de ser.

    No es cierto que es Sprint backlog no se toca. Se puede y se debe tocar en dos situaciones: cuando el sprint se ha infraestimado (hemos metido más tareas de las que podemos abordar) o cuando el sprint se ha sobrestimado (hemos metido menos de lo que podemos hacer). En el primer caso es importante sacar product backlog items de sprint para evitar poner esfuerzo en cuestiones que no vamos a poder completar y demostrar en el Sprint Review. En el segundo caso es importante añadir carga al sprint para evitar que haya gente que no este ‘produciendo’. Siempre se debe contar con el ‘commitment’ del equipo a la hora de añadir más elementos al sprint.s Estas situaciones se suele detectar hacia mitad del sprint con solo ver el burndown chart del sprint.

    Al final el sprint siempre hay cosas que hacer, a lo mejor no directamente relacionadas con el sprint backlog, pero siempre es posible que la gente que ya ha terminado sus tareas haga cosas como: ayudar a la gente que aun tiene tareas que hacer, mejorar partes del código que son problematicas, mejorar las construcciones automatizadas, mejorar la covertura de los test, preparar el Sprint Review, documentar partes del código no sufientemente documentadas, realizar o escribir pruebas de aceptación… anda que no hay siempre cosas que hacer…

    Espero haberte ayudado con tus dudas…

    Un saludo!!!

  5. hola!

    Primeramente quiero felicitarte x estos blogs!
    Y como veo que eres una persona muy adentrada en esto, quisiera ver si me puedes dar tu opinión a cerca de un proyecto que estoy trabajando para mi tesis de maestria, la cual pretendo aplicar en la empresa donde laboro…

    Quiero hacer un metamodelo para la mejora del proceso de gestión,desarollo y testing; pretendo combinar varias metodologías para sacar lo mejor de cada una y así tener una herramienta fuerte…

    Las metodologías que escogí es Scrum para la parte de gestión, Rup para el desarrollo, pues me lleva de la mano para que pueda tener los estandares de cmmi que es lo óptimo para el proyecto.

    Ahora bien, se que scrum trabaja con una metodología de agile, x lo tanto, no se cuan adaptable la pueda hacer con rup, crees que esto sea posible???
    O me recomiendas que siga la metodologia de agile y que el rup unicamente lo empiece a combinar en la parte de testing?
    O que otra metodología crees que me serviría?

    Gracias.
    Espero tu opinión
    Saludos!!

  6. Hola LIS!!!

    Lo que está haciendo esta bien como tesis y como manera de aprender sobre metodologías, pero lo último que necesita el mundo es una metodología más 😉

    Dicho esto, creo que Scrum con lo que mejor combina es con XP, otra metodología ágil. Tratar de combinar una metodología ágil, con otra que no lo es como RUP es un juego cuando menos dificil. Piensa que un tema clave en toda metodología son los principios que la rigen, y que estos son muy diferentes entre las metodologías ágiles y la metodologías clásicas.

    A parte de RUP, creo que deberías mirar MSF Agile, en concreto la parte de testing es bastante compatible con Scrum.

  7. Aupa Rodri,
    Tiempo ha! Te diré que tus blogs me arrancan bastantes sonrisas. Al meollo. En relación con la opción de hacer un Sprint 0 para definir una arquitectura base (tech story), me surgen dudas y me gustaría saber qué se te pasa por la cabeza con respecto a ellas. En el Planning Meeting de ese Sprint 0, no se si estimar unicamente la definición de la arquitectura o simplemente tratarla como una historia más, es decir que participe todo el equipo, estimar «todo» como cualquier otro Planning Meeting, y simplemente priorizar y limitar el objetivo del sprint a definir la arquitectura y poco más. Tambien se me hace un poco difícil definir el equipo necesario sin tener clara la arquitectura, en fin, supongo que la respuesta es: «DEPENDE», pero bueno si pudieras arrojar algo de luz a estas viejas neuronas 😉 Un saludote majo!!!

  8. Hola, veo grandes posibilidades a scrum y me encanta su concepión, sin embargo tengo una duda que no sé muy bien cómo resolver.

    Scrum parece muy bien definido cuando el proyecto a abordar está claro y es hora de ponerse a trabajar, pero cuando previamente al desarrollo hay que realizar una estimación de costes, esfuerzo y tiempo para dar una valoración a un cliente para su aceptación no veo cómo scrum puede ayudar.

    En otras metodologías (por ejemplo RUP) se estima que sin terminar la fase inicial, con aproximadamente el 20% de los requisitos iniciales (de alto nivel) debe ser suficiente para establecer una arquitectura previa (aunque no definitiva) del producto. La descomposición de esta arquitectura en componentes, capas, etc. te da las pistas para conocer cuantos integrantes debe de haber en el equipo, cuál va a ser su dedicación y en qué fases van a aparecer, así como los perfiles necesarios, como consecuencia a esto tienes un alcance temporal.

    Si multiplicas el coste_hora_perfil*alcance_temporal te da un precio aproximado del coste del proyecto y es aproximado porque sólo contamos con el 20% inicial de los requisitos (posiblemente sacados en la primera entrevista con el cliente), pero ese coste es más que suficiente para plantearle algo al cliente así como la arquitectura que se le va a hacer. Me consta que otras metodologías tienen procesos similares.

    No me queda claro que propone scrum en este sentido.

    Un saludo.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *