SCRUM, vale…ahora hagamos el proyecto.

Muchos gestores tiene dudas a la hora de tomar la decisión de si SCRUM es la solución correcta en su organización ya que surgen varios temores resultantes de una forma de pensamiento tradicional de la gestión de proyectos donde se realiza una planificación de todos los aspectos al inicio del proyecto, a un modelo que realiza un cambio de timón brusco, en donde esa planificación emerge a medida que reducimos el grado de incertidumbre, por consiguiente planificamos y ajustamos a medida que vamos conociendo más. Ese temor  muchas veces es producto del desconocimiento de cómo aspectos tales como: el alcance, el presupuesto, cronogramas, asignación de recursos, riesgos, plan de calidad y comunicaciones se desarrollan en un modelo empírico como SCRUM, y lo que usualmente desemboca en modificaciones al modelo conocidas como ScrumBut.

En este post voy a intentar aclarar estos aspectos.

Alcance, presupuesto y cronograma.

Usualmente, el Jefe de Proyecto necesita pronosticar el presupuesto, el cronograma, el plan de capacidad del personal, el plan de gestión de riesgos, el plan de calidad y el plan de comunicación basado en el alcance del proyecto.

En SCRUM el Product Owner, administra el alcance del software a construir en términos de Product Backlog así como el costo beneficio de las características del producto a ser construidas (hay una línea base en relación a costo beneficio de la funcionalidad que en el modelo waterfall es compleja de establecer). En SCRUM el coste del trabajo no fluctúa ya se tiene un equipo constante. El Product Owner  tiene en sus responsabilidades la de reunir las funcionalidades de tal manera que se obtiene el máximo valor del  trabajo del equipo, el cual se debería mantener estable. El Product Owner  constantemente mantiene actualizado el tiempo estimado para finalizar las funcionalidades no construidas o incompletas. Esta actividad es de suma importancia para poder pronosticar el cronograma y las fechas de terminación.

Los plazos y el presupuesto se revisan a una frecuencia determinada en las Sprint Review.

La carga de trabajo, en el primer Sprint es asignada por la organización posiblemente vía su oficina de proyectos. Ésta asignación de gente debe tener en cuenta además de los perfiles la estabilidad del equipo a lo largo de los Sprint, su capacidad para llevar a cabo todo el trabajo en cada Sprint y sus habilidades intrínsecas para poder balancear su responsabilidad de auto gestión.

Los Stakeholders proveen feedback frecuentemente  de cómo el mercado o el uso potencial del producto podría haber cambiado y cuáles son las cosas más valiosas que se deberían hacer a continuación. También revisan las fechas de liberación, el presupuesto, las capacidades potenciales y requisitos del mercado a ser consideradas en la próxima versión lo cual permite adaptar la planificación y de ser requerido el alcance.

Finalmente las Daily Meeting permiten una actualización diaria del Plan de trabajo.

Plan de Calidad:

El Scrum Team en su conjunto es responsable de la calidad del Incremento (software generado en la iteración). La calidad funcional requerida se especifica en las pruebas. La calidad técnica requerida se hace transparente por  la "DoD".  SCRUM establece las siguientes reglas a la hora de construir el incremento: Durante un Sprint, las metas de calidad no disminuyen. Durante cada Retrospectiva el Scrum Team identifica y planea formas de aumentar la calidad del producto adaptando la DoD tanto como sea necesario. Cuando el equipo madura, se espera que su DoD se amplíe para incluir criterios más estrictos para una mayor calidad.

Plan de Riesgo:

SCRUM es fundamentalmente un marco de reducción de riesgos, reduciendo el riesgo, la incertidumbre de por ejemplo; los grandes compromisos (como lo vimos en un post anterior), la acumulación de residuos, las debilidades ocultas del equipo de desarrollo, etc., limitándose el horizonte de planificación a períodos de tiempo cortos. Las iteraciones de no más de un mes permiten la previsibilidad al asegurar la inspección y la adaptación del desarrollo hacia el objetivo. Los Sprints también limitan el riesgo a un mes calendario de costo. Cualquier otro riesgo que surja, tal como el trabajo subestimado, se comunica inmediatamente a través de impedimentos y se actúa de inmediato.

Plan de comunicación:

Scrum define límites claros para la comunicación a fin de aumentar la transparencia y centrarse en trabajo que aportan valor. El Product Owner es el único punto de comunicación para las partes interesadas, incluidos los clientes, los usuarios y áreas de negocio. El Scrum Master gestiona la comunicación en la periferia del equipo. Dentro del Scrum Team, la comunicación es continua. Ésta comunicación efectiva se logra mediante la transparencia de la información a través de los artefactos SCRUM (Product Backlog, Sprint Backlog e Incremento) los cuales proporcionan información necesaria sobre el plan de desarrollo del producto, el estado de los trabajos,  configuración actual del producto, etc.  

Los eventos SCRUM en especial el Daily Scrums mejora la comunicación, elimina otras reuniones, identifica los impedimentos para el desarrollo, promueve la toma de decisiones rápidas, y mejora el nivel de conocimiento del Equipo de Desarrollo.

Nota: Este post también puede servir para aquellos que necesitan trazar los requisitos de un modelo como CMMI en un entorno de desarrollo SCRUM.