Mis respuestas sobre Scrum (II)

Me comenta un ex-alumno de uno de mis cursos de Scrum que está involucrado en un proyecto en el que el cliente a pedido que se utilice Scrum como metodología de desarrollo. Sin duda que el cliente exija una metodología determinada es una manera excelente de contar con un sponsor. Sin duda factor clave para hacer más facil la adopción de Scrum o cualquier otra metodología.

A parte de esto, me plantea una serie de dudas que contesto aquí pues creo que son muy interesantes. Esto solo son mis respuestas, no verdades absolutas, que no las hay. No es la primera vez que doy respuestas sobre Scrum y seguro que no será la última. Seguro que los comentarios que aquí hagáis serán de utilidad y de interés para mucha gente.

1) ¿Cuándo establecer la fecha del Sprint Planning Meeting? (o generalizando de otras liturgias…)

No hay reglas claras en Scrum sobre este aspecto. Pero lo que marca todas las fechas es la duración del sprint. El primer Sprint Planning Meeting se lanza generalmente cuando se tiene la primera versión del product backlog construida. Una vez tenemos la duración del sprint determinada (20 días hábiles funciona bien para la mayoría de proyectos), los siguientes hitos importantes, Sprint Restropective y Sprint Planning Meeting, ocurrirán transcurrido ese lapso concreto de tiempo.

Generalmente el Sprint Planning Meeting se realiza justo el día siguiente al Sprint Review y Sprint Restrospective. La mayoría de los equipos Scrum que conozco lo que hacen es realizar el mismo día la revisión del sprint (Sprint Review) y la retrospectiva del sprint (Sprint Retrospective). La recomendación aquí es clara, la retrospectiva siempre se debe hacer con el sprint fresco en la memoria, por lo tanto el mejor momento para realizarla es sin duda justo después del Sprint Review.

Los sprines son periodos muy intensos de trabajo y una práctica que cada vez más a menudo usan los equipos es dejar entre 1 a 3 días entre el final de un sprint (los sprines terminan con la restropectiva) y el siguiente Sprint Planning Meeting que dará comienzo al siguiente sprint.

No hay por tanto muchas variables a determinar, una vez determinada la duración del sprint y el periodo de margen entre sprines las fechas vienen dadas. Esta variables generalmente se determinan por consenso entre todos los implicados pero es el Scrum Master quien tiene en sus manos, como gestor del proceso de desarrollo, la última palabra.

Otro tema es cuando se comunicas las fechas. Una de las salidas que se optienen del Sprint Planning Meeting es el lugar y la fecha del Sprint Review de ese sprint que debe ser comunicado a todos los implicados, esto es algo que si viene establecido por las reglas de Scrum.

2) ¿Cómo cobrar el proyecto? ¿Todavía no tenemos el Product Backlog y por lo tanto no tenemos especificaciones claras, como le podemos hacer una oferta sobre algo que no controlamos?

Nunca vas a tener las especificaciones claras, no te engañes, asúmelo, por eso nacieron las metodologías ágiles. Aunque lograses tenerlas claras, estas pueden cambiar a lo largo del proyecto. Hace poco escribía sobre la gestión de requisitos en Scrum, sería bueno que reviséis ese post.

Esto son realidades por tanto a la hora de hacer la oferta la técnica a utilizar debe ser la misma que se utiliza con cualquier otra metodología: la estimación. Presupuestar la oferta de un proyecto es únicamente un problema de estimación, no de gestión o de ciclo de vida. En Scrum una técnica habitual es construir una primera versión preliminar del Product Backlog, espresado como un conjunto de historias de usuario, con toda la información que el cliente nos pueda facilitar en la fase de oferta, que no siempre es completa. Luego este Product Backlog se estima, generalmente usando puntos de historia, un luego se establece un valor monetario para cada punto de historia. Para establecer ese valor monetario para el punto de historia, se seleccionan algunas historias representativas ya estimadas y se estiman en unidades monetarias. El cociente entre la estimación en puntos de historia y en unidades monetarias de las historias estimadas en ambos nos permite obtener un coeficiente que podremos aplicar para convertir nuestro punto de historia totales a unidades monetarias, de esta manera podremos conocer una estimación en unidades monetarias del coste de desarrollo de nuestro proyecto. Lógicamente, deberemos considerar también los costes de hardware, formación, consultoría. Existen otros muchos enfoques, pero este me gusta particularmente pues además de servir para estimar el coste del proyecto, proporciona avance en la construcción del product backlog. Decir que no es necesario para estimar el coste del proyecto construir un product backlog muy detallado.

Sobre como cobrar, en Scrum un enfoque que surge del sentido común es recibir pagos del cliente después de cada sprint. Puesto que tras cada sprint el cliente recibe un incremento potencialmente entregable de funcionalidad y por tanto un retorno de la inversión asociado es lógico que pague por el ¿no?. El cuánto ya es otro cantar. Aquí hay mucho enfoques, el ideal es cobrar por certificación, tanto me ha costado el desarrollo tanto te cobro, pero esto no siempre es posible, sobre todo con precio cerrado. Cuando vas a precio cerrado lo que se suele hacer es determinar a priori un número determinado de sprints y establecer una cantidad fija por sprint, que resulta de dividir la cantidad presupuestada entre los sprints previstos. Lógicamente todas la cantidades a menudo se ajustan según la velocidad del equipo, por lo tanto volvemos a los de antes todo se trata de un problema de estimación, como en cualquier otra metodología.

3) ¿Cuándo fijar la fecha para generar el product backlog y quien lo debe fijar? Entiendo que serán varios días entre el Product Owner, el Scrum Master y todo el equipo.

Recordar antes de nada que el Product Backlog es algo vivo que se debe mantener y evolucionar a lo largo de todo el proyecto. Efectivamente el Product Backlog se suele construir, idealmente, entre el Product Owner, el Scrum Master y todo el equipo. Pero esto no siempre es así, especialmente en desarrollos de proyecto, no de producto. A menudo cuando se comienza la construcción del Product Backlog, no contamos con el equipo. Especialmente cuando estamos en fase de oferta. Por lo tanto, quien generalmente construye el Product Backlog es el Product Owner, que es el responsable último. Como a menudo durante la fase de oferta tampoco se conoce quien será en última instancia el Producto Owner, e incluso puede que finalmente se trate de alguien del cliente, alguien de la empresa que realiza la oferta actúa como tal, quizás de manera provisional, durante la fase de oferta para construir una primera versión del Product Backlog que luego debe ser refinado.

4) ¿Propongo un Product Owner de parte del cliente, es lo correcto?

Suele ser lo correcto, pero a veces no lo es o no es posible que sea así, aun siendo lo correcto. A menudo es la mejor opción. El Product Owner construye y prioriza el Product Backlog considerando el valor obtenido por el cliente y la estimación de cada elemento del Product Backlog. ¿Quién mejor que alguien del cliente para saber esto?. La única pega es que a veces el cliente no cuenta con alguien capaz de recabar los requisitos y construir el Product Backlog o simplemente no quiere dedicar personal a este cometido. En este caso, no quedará más remedio que poner a un Producto Owner desde la empresa de desarrollo.

Todas las cuestiones aquí planteadas darían para escribir un libro, hay muchísimos aspectos a considerar en cada proyecto que pueden hacer que las respuestas aquí dadas sean más o menos aceptadas, solo he tratado de dar aquí la respuesta que intuyo funciona en el más amplio rango de casuísticas.

Un comentario sobre “Mis respuestas sobre Scrum (II)”

  1. Hola, tengo algunas preguntitas, si pueden ayudarme estaré muy agradecido.

    – Se pueden realizar paralelamente multiples SCRUMs para multiples proyectos de desarrollo distintos?
    – Pueden ser los actores de un SCRUM parte de otros SCRUMs que se estén realizando al mismo tiempo?. Que actores pueden ser parte de múltiples SCRUMs y que actores no?
    – Hay un número minimo posible de personas para un SCRUM? sé que lo recomendable es 8 personas, pero hay un minimo?, por ejemplo en un pequeño proyecto de desarrollo podría haber una persona por cada rol?
    – En el mismo caso de antes puede una persona cumplir mas de un rol en el SCRUM?
    – Debería el Product Owner ser de nivel jerárquico superior a los miembros del equipo? Algun nivel recomendable?
    – Debería ser el Product Owner o el Scrum Master del área informática (informático) necesariamente?
    – Debería ser el Product Owner del área usuaria?.
    – En la empresa donde yo trabajo se desarrollan o corrigen partes o modulos del sistema que utiliza la compañía, estos nacen de un requerimiento del área usuaria, pasan por el área de desarrollo de la Compañía quien evalua el requerimiento y encarga la programación a una empresa de outsourcing. Estoy frente a los posibles actores de un SCRUM?
    – Donde queda la etapa de certificación de un SCRUM? esta es iterativa como todo lo demás? O solo se certifica al final? En el caso de la certificación los actores cambian? Por ejemplo el área usuaria pasa a formar parte del team?
    – Que pasa con las reuniones y organización de éstas en periodos donde la gente sale de vacaciones y no puede estar en toda la secuencia? Se debe detener el proyecto?

    Muchas Gracias de antemano

Deja un comentario

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