Ir al contenido principal

Como implementar Scrum en 10 pasos fáciles. Paso #4: Planeación del Sprint (Tareas)

Siguiendo con la serie "Como implementar Scrum en 10 pasos fáciles" publicada por Kelly Waters y traducida con su permiso en este blog.

El árticulo de hoy sigue hablando de la planificación del Sprint esta vez se concentra en la división de los requisitos en tareas. Encuentra el original en Step 4: Sprint Planning (Tasks)

Planeación del Sprint (Tareas)

Una vez que has completado el paso #3 y has esclarecido los requisitos para todos los ítems de la Pila del Producto que cubrirás en el Sprint, el siguiente paso es planear el Sprint en detalle...


Taller de Planificación del Sprint (parte 2)

La primera parte del Taller de Planificación del Sprint (en el paso anterior de esta serie) estaba enfocado en esclarecer los requisitos para la Pila del producto seleccionada. La segunda parte de la del Taller de Planificación del Sprint está enfocada en dividir los requisitos en tareas y estimar las horas requeridas para completarlas.

Aunque la parte 2 del taller puede estar directamente después de la primera parte, a veces es útil tener un corto espacio de tiempo entre las dos reuniones; tal vez un día. Esto permite tiempo para esclarecer cualquier pendiente derivada de la parte 1 del taller antes de proseguir con el paso siguiente.

Asegurate que la reunión sea atendida por todos los miembros del equipo. Incluyendo todos los roles. Analistas del Negocio si los tienes. Personal de pruebas, si los tienes. Todos los desarrolladores del equipo Scrum para el producto.

El propietario del producto o cualquier cliente, usuario o representante del negocio no necesitan atender esta parte (parte 2) del Taller de Planificación del Sprint, por que es probable que sea mas técnico por naturaleza y es mas sobre el trabajo del equipo elaborando el cómo los ítems de la pila serán desarrollados.

Sin embargo, cualquiera de ellos será bienvenido si quisieran atender la reunión, lo cual puede ayudarles a entender lo que involucra el desarrollo de las características y también puede ayudar por si cualquier clarificación posterior es  requerida mientras las tareas son discutidas y animadas.

Establece el presupuesto del Sprint (Sprint Budget)

Primero que todo, calcular el presupuesto del equipo del Sprint. Esto es el número de horas disponibles que el equipo tiene para trabajar en el Sprint.

Inicia por multiplicar el numero de horas disponibles en la duración del Sprint por el número de personas de tiempo completo en el Sprint. Para personas que están trabajando medio tiempo en Sprint, incluye el número de horas que ellos puedan comprometerse.

Entonces, has cualquier deducción razonale para el tiempo que los miembros del equipo no serán capaces de estar en el Sprint. Deduce vacaciones, cualquier reunión, cualquier tiempo que probablemente será ocupado en otros proyectos, etc. Basado en experiencias pasadas deduce una cantidad razonable de tiempo para soporte, si es apropiado.

Asegurate que todos estos cálculos son transparentes y visibles para todos.

Divide los requisitos en tareas.

Ve por cada ítem de la Pila del Producto seleccionado para el Sprint. Divide los requisitos en tareas.

Las tareas pueden incluir los pasos tradicionales en el ciclo de vida del desarrollo (aunque limitado a la característica en cuestión, no el producto entero). Por ejemplo: diseño, desarrollo, pruebas unitarias, prueba del sistema, UAT(User Acceptance Testing -- pruebas de aceptación de usuario--), documentación, etc.

Recuerda, las metodologías de desarrollo ágil de software no excluyen estos pasos. Las metodologías ágiles solo abogan por hacer estos pasos característica por característica, justo a tiempo, en lugar de grandes fases.

Cada una de estas tareas, especialmente el desarrollo, pueden ser subsecuentemente divididas. Tal vez a un nivel de componentes, detallando cada uno de los elementos individuales de la arquitectura de software que serán requeridos para la entrega del producto.

Incluir todas las tareas necesarias para hacer que el ítem de la pila del producto este 100% completo -ejem. potencialmente entregable - dentro del Sprint. Acordar con equipo la definición de terminado, así todos esten conscientes de lo que tendrá que ser completado e incluido en las estimaciones.

Marca las tareas como resultados, si es posible. Los resultados son mas medibles que las tareas. En lugar de describir que vas a hacer, describe que vas a entregar como resultado.

Estima las tareas en horas

Mantén las tareas pequeñas. Estima todas las tareas en horas. Estima cada una de las tareas como equipo.

Preguntale a todos lo que ellos piensan, para identificar tareas perdidas o para identificar soluciones mas simples.

Idealmente la estimación de las tareas no deberían ser de mas de 1 día. Si una estimación es mucho mas grande que esto, los requisitos deben ser mas divididos para que las tareas sean mas pequeñas. Aunque esto puede ser difícil, se volverá mas fácil en la práctica.

Mantener las tareas lo suficientemente pequeñas para que la estimación sea menor que un día tiene algunos beneficios específicos.

Primero, dividir las tareas en pequeñas partes significa que son mas fáciles de estimar. La exactitud de tu estimación se mejorará como resultado. Segundo, las tareas de menos de 1 día son mas medibles en la reunión diaria. Las Tareas de un día o están hechas o no lo están.

Compromiso con la pila del Sprint.

Suma todas las estimaciones de las tareas para la Pila del Producto seleccionada. Si superan significativamente el presupuesto del equipo, reduce el número de items de la pila del producto selecionada para el Sprint. Recuerda que la Pila del Producto estaba en orden de prioridad, así que si es posible debería ser un ítem de la parte de abajo en la pila que sería removido del Sprint.

La lista restante de tareas estimadas - aquellas tareas necesitadas para completar el producto dentro del Sprint - es tu pila del Sprint.

El equipo debe comprometerse a entregar la Pila del Sprint.

Identificar las tareas estiradas

Algunas veces los equipos subestiman o sobreestiman. Extrañas cosas han pasado.

En mi experiencia esto es muy común cuando los equipos son nuevos para Scrum. Pienso que esto pasa porque ellos no están familiarizados con el proceso y están potencialmente fuera de su zona de comfort inicialmente. Ellos pueden no tener mucha experiencia sobre la estimación en el pasado. Y pueden no haberse comprometido con sus propios resultados antes. Esto puede a veces resultar en una aproximación demasiado precavida en las estimaciones.

Siempre incluye algún alcance adicional en tu Pila del Sprint, mas allá de lo que piensas que puede ser logrado. Esto es importante para tener algo listo en caso de que el equipo concluya antes, ya que la duración del Sprint debería idealmente ser fija.

Claramente identifica estos items cono tareas estiradas. El propietario del producto no debería esperar que estas tareas sean alcanzadas. Nadie debería ser molestado si las tareas estiradas no son alcanzadas. Y si puedes completar cualquier tarea estirada, esto debería ser causa de celebración!.

Siguiente...

Así que tienes tu pila en orden, has estimado tu pila, esclarecido los requisitos y planeado tu Sprint. Ahora estás listo para el paso #5 - Crear un espacio de trabajo colaborativo.

Kelly


Serie completa:
#4: Planeación del Sprint (Tareas)

Comentarios

  1. Project management focuses on controlling the introduction of the desired change. This involves(As per Knowledge after attending the PMP Training ):
     Understanding the needs of stakeholders.
     Planning what needs to be done, when, by whom, and to what standards.
     Building and motivating the team.
     Coordinating the work of different people.
     Monitoring work being done.
     Managing any changes to the plan.
     Delivering successful results.

    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, ...

jQuery DataTables y CodeIgniter

Ajax Source Datatables permite configurar fácilmente el origen de datos de la tabla, para que esta sea generada dinámicamente desde el servidor, así que con CodeIgniter tendríamos el siguiente código public function page(){ $data['pedidos'] = $this->pedidos_model->get_pedidos($this->input->post('iDisplayStart')); define('AJAX_REQUEST', 1);//truco para que en nginx no muestre el debug $TOTAL = $this->pedidos_model->total(); echo json_encode(array('aaData'=>$data['pedidos'], 'iTotalRecords'=>$TOTAL, 'iTotalDisplayRecords'=>$TOTAL, 'sEcho'=>$this->input->post('sEcho'))); } Este método producirá algo parecido a esto: {"iTotalRecords":83099,"iTotalDisplayRecords":83099,"sEcho":"2", "aaData":[{"Id":"85514","num":"86109...

Expresiones Regulares y pruebas en javascript

¿Qué es una expresión regular? Una expresión regular es una cadena que contiene una combinación de caracteres normales y metacaracteres o metasecuencias especiales. Los caracteres normales coinciden por ellos mismos. Los metacaracteres y metasecuencias son caracteres o secuencias de caracteres que representan ideas como cantidad, posiciones o tipos de caracteres. Regular Expression Pocket Reference 2nd Ed - Tony Stubblebine - O'Reilly ¿Para qué son útiles las expresiones regulares? Las expresiones son especialmente útiles para validar información, por ejemplo en formularios de ingreso de datos. Por ejemplo para validar que se ingresó un número de teléfono, puedes usar la siguiente expresión regular. /^([\+][0-9]{1,3}[ \.\-])?([\(]{1}[0-9]{2,6}[\)])?([0-9 \.\-\/]{3,20})?$/ Parecieran símbolos al azar, pero nada mas lejos de la realidad. Te muestro una tabla básica con los elementos usados para crear expresiones regulares. Carácter Texto buscado ^ ...