La entrada original de este artículo es: Get your backlog in order
Ordena tu "Pila del Producto"
¿Así que quieres implementar Scrum?
¿Y te gusta la idea de hacerlo fácilmente?
Entonces escucha. Este es el paso 1 en mi serie: ¿Cómo implementar Scrum en 10 pasos fáciles.
Este no es solo el primer paso. Es el paso más importante.
A menos que puedas llevar a cabo este paso, no sigas. No lo saltes. Te prometo que te arrepentirás si lo haces. Incluso si no continuas, es probable que este paso te beneficie, a tu equipo y a tu organización.
Así que aquí está.
Primero, ¿dónde deberíamos empezar?
Alineación con el negocio
Primero, antes de nada, debes alinear tu equipo de desarrollo con el negocio.
Si eres parte de una unidad de negocio, eso puede ser natural y directo. Si estas en una organización central de desarrollo sirviendo a múltiples unidades de negocio, desarrollando múltiples productos, entonces puede ser más difícil. Inicialmente, asegúrate que tienes al menos una persona dedicada a un producto, aplicación o rango de productos donde empezarás a implementar Scrum.
Inicia con BAU
Segundo, aunque puedes usar Scrum en proyectos para buen efecto, te sugiero iniciar con BAU (business-as-usual [negocios usuales]) en lugar de grandes proyectos. Esto mantendrá las cosas simples mientras tú y tu equipo se acostumbran a las bases.
Así que has decidido un producto donde empezar a usar Scrum. Tienes al menos una persona que estará dedicada a ese producto (o rango de productos). Para mantener las cosas simples al principio, has seleccionado un producto que es parte del ciclo BAU de corrección de errores y mejoras.
Encuentra un Propietario de Producto dispuesto
El siguiente paso clave es nominar un propietario de producto. Debes encontrar un propietario de producto. Una persona será responsable por priorizar el trabajo en el producto. Una persona que sabe que es lo requerido del producto. Una persona que es un buen comunicador y es capaz de transmitir requisitos. Una persona que está comprometida con el éxito del producto, tal que esté dispuesto y sea capaz de dedicar una cantidad razonable de tiempo a su desarrollo.
Si, por cualquier razón, esto es un problema para ti, NO SIGAS.
Si no puedes completar este paso, el desarrollo de tu producto puede estar cargado de problemas. Implementes o no, Scrum. A menos que puedas lograr los pasos de arriba, es muy posible que enfrentes una lluvia de peticiones, sin vista clara de prioridades, una falta de claridad sobre los requisitos, mucho ruido y quejas, y ser empujado de un lado al otro. ¿Las consecuencias? No entregaras y/o fallarás en cumplir las expectativas. Todo será miserable. Y de alguna forma será tu culpa. Desafortunadamente, todo esto es una situación demasiado común para equipos de desarrollo en todas partes. Esto debe ser solucionado antes de proceder. Este es un factor crítico para el éxito de tu equipo.
Actúa como ScrumMaster
Así que ahora estas organizado y alineado. Tienes un producto, aplicación o rango de productos. Tienes al menos una persona dedicada al producto (Equipo Scrum). Tienes un propietario del producto. Y tú, por virtud del hecho que estes leyendo esta información sobre la implementación de Scrum, asumiré que eres probablemente el ScrumMaster.
Como ScrumMaster, eres responsable de apoyar al Equipo Scrum, entrenando y orientándolos a través de este proceso y quitando cualquier impedimento que bloquee su progreso.
Crea la Pila del Producto (Product Backlog)
Ahora debes crear la Pila del producto
Probablemente necesites crear o facilitar la creación de la Pila del Producto. Estrictamente hablando debería ser propiedad del Propietario del Producto. Pero puedes poner las cosas en marcha.
La Pila del Producto, en su forma más simple, es una lista de cosas que las personas quieren que se hagan en el producto, ordenadas por prioridad.
Cualquiera puede agregar cualquier cosa a la Pila del Producto. Cualquiera. El proceso Scrum y los principios ágiles de desarrollo, son generalmente colaborativos e inclusivos. No hay más necesidad de decir no.
Pero... muy importantemente - solo el Propietario del Producto puede priorizar la Pila del Producto.
La pila del producto puede contener cualquier cosa. Cualquier cosa relacionada al producto. Errores. Mejoras, Proyectos completos. Problemas. Riesgos. Lo que sea.
Habiendo dicho eso, los ítems en la Pila del Producto deberían ser idealmente expresado en términos del negocio que sean de algún valor para el usuario (o cliente, o negocio). No como tareas técnicas.
Los requisitos funcionales deberían ser expresados como características. Requisitos no funcionales pueden ser puestos en la Pila también, por ejemplo "el producto necesita ser más rápido", "necesitamos asegurar que el producto sea seguro", "necesitamos salir de la antigua plataforma". Estas pueden no ser características, como tales, pero están completamente justificadas como ítems en la Pila del Producto.
Prioriza la Pila.
Los Propietarios del Producto priorizan la Pila del Producto. Ellos no categorizan las prioridades en 1, 2, 3 o algo así. La prioridad es determinada simplemente por el orden de la lista. El Propietario del Producto pone la Pila del Producto en orden de prioridad.
Las cosas en el fondo de la lista pueden estar muy lejos de ser hechas o podrían no llegar a hacerse. Las cosas en la parte inferior antes del fondo, son probablemente confusas y mal definidas. No gastes el tiempo definiendo cosas que puede que nunca tomes, o tardes algún tiempo en llegar hasta ellas. Si algo es una mala idea, el Propietario del Producto debe explicar a quien lo solicitó por qué se retira de la Pila. Sin embargo, si algo no es tan mala idea, aunque probablemente no se llegue a hacer, solo ponlo en su correcto bajo lugar en la Pila y explica a quien lo pidió donde se ajusta a las prioridades.
En realidad esto es como hacer fila. O estar de pie en una línea. Estamos acostumbrados a eso. La gente en general lo acepta. Una vez que la autoridad del Propietario del Producto ha sido comunicada y cuenta con el apoyo de la administración, la gente ocupará su lugar en la cola.
Muy a menudo en equipos de desarrollo, no hay una clara visibilidad de la fila. Las personas no saben qué tan larga es la fila. Y no saben cuántos están primero que ellos. Esto generalmente lleva a impaciencia y quejas, porque es la única forma de pasar e ir adelante en la fila.
La visibilidad de la Pila del Producto puede resolver este problema.
Además...
Los pasos de arriba pueden tener un profundo y poderoso efecto...
Priorización es ahora un problema del negocio. El equilibrio entre la adición de costo y hacer más, o esperar pacientemente en la cola, ahora es una decisión comercial. Una creciente conversación entre el costo versus el beneficio. No es mas un problema de entrega. Es una elección. Gritar más fuerte no es más el sistema para la priorización. Así que no hay ningún punto para los gritos.
Y piensa en los problemas técnicos o riesgos que causan que pierdas el sueño pero nunca te dan el tiempo para solucionarlos. Ponlo en la Pila. El Propietario del Producto puede decidir que otras, más visibles características deberían tomar prioridad. Pero si el riesgo te muerde, se trata de una decisión de negocios enfrentar el riesgo. La propiedad del riesgo es exitosamente transferida.
Las cosas en la parte superior de la Pila del Producto se pueden hacer en el futuro previsible. Por lo tanto son probablemente mejor entendidas. Y necesitan estar lo suficientemente bien definidas como para que el equipo pueda trabajar en ellas. Estas características (o ítems de la Pila) deberían estar definidas individualmente, de manera que puedan permanecer solas como discretas piezas de trabajo entregables. No como partes de una gran red de interdependencias. Y tampoco partes de un gran documento de especificación. Definidas, sí. Pero definidas en pequeñas, piezas individuales. La clara definición de ítems de la Pila solo necesitan permanecer un paso adelante del equipo. No más allá.
Así que ahí lo tienes. Ahora tienes un equipo Scrum. Un ScrumMaster. Un Propietario del Producto. Una Pila del Producto. Has alineado tu equipo con el negocio. Has creado una clara propiedad del producto. Has priorizado el trabajo de tu equipo. Y tienes un sistema, un mecanismo, un sistema de fila para priorización de forma permanente.
Si no haces más, estarás mejor solo por tomar este paso. Pero, hasta que puedas tomar este paso, no sigas.
Kelly
Serie completa:
#1: Ordena tu pila del producto
#2: Cómo estimar tu pila del producto
#3: Planeación del Sprint (Requisitos)
#4: Planeación del Sprint (Tareas)
#5: Crear un espacio de trabajo colaborativo
#6: Sprint
#7: Ponte de pie y a contar
#8: Mide el progreso con un gráfico
#9: Termina cuando dijiste que lo harías
#10: Revisa, Reflexiona, Repite
Serie completa:
#1: Ordena tu pila del producto
#2: Cómo estimar tu pila del producto
#3: Planeación del Sprint (Requisitos)
#4: Planeación del Sprint (Tareas)
#5: Crear un espacio de trabajo colaborativo
#6: Sprint
#7: Ponte de pie y a contar
#8: Mide el progreso con un gráfico
#9: Termina cuando dijiste que lo harías
#10: Revisa, Reflexiona, Repite
Buen aporte.
ResponderEliminarEn el punto 9... "dijistes"
ResponderEliminarEs debatible si se puede considerar un error, pero "dijiste" suena un poquito mejor. Así que gracias.
ResponderEliminarBuen aporte
ResponderEliminarUna pregunta, la pila de producto debe estar completa antes de comenzar el primer sprint? O se puede ir agregando mas historias a medida que se descubran algunas que no fueron consideradas al principio.. Gracias
ResponderEliminarAntes de comenzar el Sprint debes elegir una meta de X historias. Una vez que empiezas el Sprint, no se deben agregar mas historias (a las seleccionadas) a menos que termines antes con todas las que ya tenías. El resto de historias, fuera del alcance del Sprint, pueden variar en cualquier forma: se pueden agregar mas a la pila del producto, se pueden quitar, pueden cambiar la prioridad, etc.
ResponderEliminarMuchas gracias por tu respuesta! :)
EliminarSeguro que si +Ernesto
ResponderEliminarExcelente aporte, me ha quedado bastante claro la metodología scrum con tu post, excelente redacción.
ResponderEliminar