Ir al contenido principal

Como implementar SCRUM en 10 pasos fáciles - Paso #1: Ordena tu "Pila del Producto"

Esta es la continuación de la serie: Como implementar SCRUM en 10 pasos fáciles. Creación de Kelly Waters y traducida con la autorización correspondiente por su servidor.


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.

Comentarios

  1. Es debatible si se puede considerar un error, pero "dijiste" suena un poquito mejor. Así que gracias.

    ResponderEliminar
  2. Una 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

    ResponderEliminar
  3. Antes 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.

    ResponderEliminar
  4. Excelente aporte, me ha quedado bastante claro la metodología scrum con tu post, excelente redacción.

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Enumerar filas en una consulta con MySQL

Supongamos que tenemos tablas con la estructura siguiente: documentos (iddocumento, nombre_documento, url_original, idtipo_documento, idproyecto) proyectos (idproyecto, nombre_proyecto, longitud, unidad_medida) tipo_documentos (idtipo_documento, descripcion_tipo_documento) Tenemos necesidad de hacer una consulta como la siguiente: "Enumerar todos los documentos en la base de datos agrupados por proyecto" Parece fácil, excepto por el término "enumerar", aquí tienes un truquito para que logres enumerar tus consultas: SELECT (@rownum:=@rownum+1) AS rownum, nombre_documento, descripcion_tipo_documento, nombre_proyecto FROM (SELECT @rownum:=0) r, documentos AS d INNER JOIN proyectos AS p ON d.idproyecto = p.idproyecto INNER JOIN tipo_documentos AS td ON d.idtipo_documento = td.idtipo_documento Pero que tal si te piden que enumeres los proyectos con sus correspondientes documentos?. Teniendo lo anterior es un poco mas sencillo SELECT IF(@fila=proyectos.idproyecto,

Tips y enlaces de la semana

json_encode y problemas con acentos. Según la documentación de la función json_encode , esta solo funciona con caracteres codificados en utf-8, así que si trabajamos con caracteres con otra codificación podemos convertirlos con la función utf8_encode. Asi: json_encode(utf8_encode($dato)); Si lo que queremos es pasar un arreglo a json, debemos pasar cada item del arreglo a utf8 y para esto usaremos la función array_map, quedando de la siguiente manera: json_encode(array_map("utf8_encode",$arreglo)); Esta función está disponible desde la versión 5.2 de PHP, asi que si usas una versión anterior intentalo con la versión de json_encode y json_decode para PHP4 Este archivo se usa de la siguiente forma: // create a new instance of Services_JSON require_once('JSON.php'); $json = new Services_JSON(); // convert a complex value to JSON notation $value = array(1, 2, ‘foo’); $output = $json->encode($value); print($output); // accept incoming POST data $input =

"Abrir carpeta contenedora" en Firefox y KDE 4.3.x lanza Cervisia

Este es un bug conocido desde hace algún tiempo, pero hay un truco que puede solucionarlo: Edita cervisia.desktop y kfmclient-dir.desktop localizado en /usr/share/applications/kde4 y agrega una linea con "OnlyShowIn=KDE;". Despues de actualizar "update-mime-cache" firefox usará dolphin. Mas información: https://bugzilla.mozilla.org/show_bug.cgi?id=266600 Actualización: El proceso al fin y al cabo le falta un paso mas. Cuando volvi a probar abrir un archivo desde la opción de "Abrir carpeta contenedora", me pidió que asociara el archivo a un programa, así que nada mas me tocó buscar donde se encuentra dolphin(/usr/bin/) y marcar la opción recordar asociación Actualización: En OpenSUSE 11.2 el problema fue solucionado.