Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Sprint cero: ¿que necesitamos?

0 comments
Sprint cero: ¿que necesitamos?

Iniciando un proyecto Ágil.

Esta es la charla que entre Juanma y yo mismo facilitamos para el OpenSpace.

Nos basamos en un supuesto de un equipo que comienza a trabajar en el desarrollo de un producto para un nuevo cliente desde cero e iniciamos la dinámica con el siguiente esquema:

– Individualmente , cada uno escribía en post-it aquellas cosas que considera imprescindibles tener o saber para que el equipo pueda comenzar a trabajar en el proyecto entregando valor de manera temprana.

– Tras un tiempo fijo, exponemos las ideas en el tablón.

– Comentamos en grupo y resumimos.

Antes de empezar yo expongo porqué niego la mayor : esto es,  que para mi no existe un Sprint Cero. El marco Scrum , no prescribe ninguna diferenciación de los Sprints. Un Sprint, es un Sprint, o timebox en el cual el equipo ha seleccionado la lista de tareas del Backlog en la que va a trabajar durante la iteración bien sean estas tareas técnicas, de funcionalidad de negocio, bugs, riesgos, etc.

Asi pues, mi postura es la siguiente : antes de iniciar cualquier Sprint, hay que hacer una serie de tareas de conceptualización, y lanzamiento o chartering en donde se define al alto nivel el producto/proyecto. De esta primera actividad se origina un Backlog del cual el equipo en su primer Sprint Planning escojerá aquellas tareas que sean necesarias en prioridad para ponerse a funcionar.Como llegar a esta conceptualización : hay muchas técnicas que podemos emplear : Inception Deck, Story Map, Personas, ….

Estas tareas de conceptualización, en el marco de la relación cliente -proveedor puede tener diferentes consideraciones :

Si tenemos la certeza de que vamos a empezar ese proyecto con el cliente, ya que hay un acuerdo previo , los costes derivados de realizar dicha conceptualización deberán ser incluidos en el contrato como actividad de pre-lanzamiento de proyecto. ¿ Lo llamamos Sprint cero?. Bajo este concepto , puedo llegar a entenderlo.

Si estamos en periodo de selección de proveedor y nos queremos posicionar porque este proyecto nos interesa, tendremos que arriesgar y hacer de este Sprint cero una cuestión estratégica y por tanto invertir en conceptualizar para demostrar que estamos capacitados para entender lo que el cliente quiere y por lo que está dispuesto a pagar. En este caso tendremos que asumir el riesgo de que finalmente el proyecto no nos sea adjudicado.

Acordaros del inicio del Post: empezé diciendo que se trata de un supuesto en el que un equipo empieza a trabajar para un nuevo cliente construyendo un producto. Eso implica pues, que es muy posible que el entorno de trabajo (ecosistema ), la arquitectura , la infraestructura y otras cuestiones muy de tecnología sean imprescindibles y estarán en el Backlog en la prioridad más alta. Sin ello, por muy ágiles que seamos, el producto no puede ser desarrollado, por lo cual estas serán tareas del primer Sprint. Indudablemente, un Sprint está enfocado a maximizar el valor para negocio y el modelo ágil se basa en la entrega de valor al cliente desde momentos tempramos, luego no solo de tareas técnicas se tiene que nutrir ese primer Sprint. Tenemos que seleccionar aquellas características y funcionalidades definidas por el Negocio como más importantes y seleccionar alguna de ellas para empezar a trabajar en la aportación de valor real. El resto de tareas del Sprint, son “desperdicio” , (Lean Project Management) pues al no aportar valor de negocio, no podemos considerarlas como incremento de producto.

Si como empresa proveedora estamos ya en la tesitura de plantearnos montar entorno, tener infraestructura , etc, es que el contrato está ya acordado entre las partes y aunque evidentemente se repercutan como costes las tareas de “montaje” inicial para poder empezar a entregar valor de negocio,  es algo que el Negocio lo considerará como algo que el proveedor debe tener si o si previsto en su plan de trabajo.

Si acaso, hay un concepto de Sprint cero , que es cierto que en algunos ambientes si se habla de ello,  en mi opinión, (como he mencionado un poco más arriba) , ese Sprint cero se tiene que dedicar a cuestiones muy distintas: Visión, Plan de alto nivel, Definición Backlog inicial y definición de Roadmap y MVP ( producto minimo viable).

Si se trata de una nueva tecnología el equipo deberá plantear al principio un Spike ( prueba de concepto ) para verificar sus asunciones y validar que el producto bajo dicha tecnología será viable. Pero una vez más, esto serán  tareas del Primer Sprint.

Quizás, se deba ser flexible en este primer Sprint en cuanto al TimeBox del mismo y acordar con nuestro cliente que el Sprint de arranque tendrá una duración excepcional debido a la necesidad de montar dicho entorno y demostrar la viabilidad tecnológica, pero sin ningún lugar a dudas, y si queremos demostrar confianza al cliente de que hemos entendido el trabajo a realizar y conocemos las prioridades de valor de negocio, esa prueba de concepto debe incluir elementos del Backlog que demuestren también funcionalidad de cara al cliente .Asi pués la demo o Sprint Review en este caso tendrá dos finalidades: por un lado demostrar la viabilidad de la solución técnica y por otro demostrar que el Backbone ( funcionalidades imprescindibles segun la técnica deStory Map ) para poder apalancar sobre ellas el resto de historias de usuario es entendido, está bien enfocado y va por el buen camino.

En todo caso, el objetivo de este post es reflejar aquellas cosas que los asistentes a la charla escribieron en sus post-it como cosas necesarias para ese Sprint inicial. Muchas de ellas están esbozadas entre las lineas del artículo, pero en honor a los participantes de la charla, os hago simplemente el inventario de las cuestiones que se consideraron necesarias tener para ese llamado Sprint cero, de arranque o como lo llamemos finalmente.

  • VISION DEL PRODUCTO : coincidimos todos en ello como una de las cosas más importantes. Visión de lo que hay que hacer y además que esté compartida.Saber qué es y que no es el producto.
  • EQUIPO : formado, motivado y con actitud.
  • LISTA DE FUNCIONALIDADES A ALTO NIVEL : épicas.
  • PLAN DE TRABAJO INICIAL : plan de releases y Road Map.Tiempo aproximado para que el producto tenga sentido.
  • DEFINIDA LA RELEASE 1.
  • PRIORIDADES DEL CLIENTE.
  • INTERVINIENTES Y CONTACTOS: quien tiene algo que hacer y qué.
  • FASES DE ACEPTACION : proceso para conseguirlo, acuerdos de trabajo. Definición de hecho.(Done)
  • EXPECTATIVAS DE CALIDAD.
  • DETECCION DE DEPENDENCIAS.
  • RESTRICCIONES O LIMITACIONES. (De seguridad, de rendimiento ,de disponibilidad…)
  • TAMAÑO OBJETIVO DE LA BASE DE CLIENTES ESPERADA.
  • PRIMERA VERSION DEL BACKLOG PRIORIZADO: según valor de negocio.
  • BACKLOG DE RIESGOS DEL PROYECTO: se pueden intercalar con el Backlog tradicional, para dar respuesta temprana a cualquier riesgo.
  • METRICAS QUE SE SEGUIRAN EN EL PROYECTO. Ojo con lo que se mide. Que no cueste mucho esfuerzo. Seguir tendencias, no datos.
  • ENTORNO TECNOLOGICO DISPONIBLE.
  • SPIKE DE ARQUITECTURA.
Y a currar , que se nos hace tarde.

Leave a Reply

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


*