Minicurso Planificación 1: Planificando las Tareas de un proyecto

Hoy comenzamos un nuevo minicurso sobre Planificación de Proyectos.

En este minicurso no sólo vamos a centrarnos en el ciclo de vida en cascada sino que vamos a tratar tanto la forma clásica (predictiva) como un punto de vista ágil.

En la entrega de hoy del minicurso de Planificación de Proyectos vamos a ver los siguientes contenidos:

• 1. La Planificación de un Proyecto
• 2. Desglosando lo que hay que hacer
• 3. Las Tareas de un Proyecto
• 4. Las Historias de Usuario
• 5. Las Tareas en Kanban

Ya hemos hablado alguna que otra vez sobre los beneficios que te aporta la planificación y para lo que realmente es útil la planificación. Pero sobre este último punto quiero hacer hincapié, ya que no está de más recordarlo de vez en cuanto.

La planificación de un proyecto persigue tres objetivos principales:

• Compromiso. Ambas partes, cliente y proveedor, se comprometen sobre qué será entregado y qué deben entregar.
• Reconocimiento. Cada miembro del equipo ve como su trabajo ayuda, forma parte, de la consecución del objetivo global.
• Avance. Nos permite comprobar como vamos con respecto a lo esperado en un momento determinado, y tomar medidas correctoras si fuera necesario

A la vista de los beneficios que nos permite alcanzar, hacer la planificación, una buena planificación, debe ser algo básico que debemos acometer siempre en nuestro proyecto. De hecho, pese a que se piense lo contrario, en la mayoría de las técnicas de gestión ágil de proyectos se planifica. Por ejemplo, en Scrum se conoce como Sprint Planning a la fase previa al Sprint donde se deciden que historias de usuario formaran parte de dicho sprint.

Y es que tenemos el vicio de pensar que planificar es una tarea compleja y muy costosa y no siempre tiene que ser así, depende de cómo lo hagamos.

Ya comentábamos en el minicurso anterior cual es la definición de proyecto:

Nos tenemos que fijar en la segunda parte: para producir un resultado. Está claro que deberemos cumplir con un presupuesto dado y en un plazo prefijado, pero nuestro objetivo es obtener un resultado.

Ese resultado será alcanzable, será conseguible a través de ciertas acciones, actividades, tareas, etc. desde alto nivel hasta un nivel detallado. Estas tareas serán como los escalones que debemos subir en una escalera hasta alcanzar la planta que nos hemos marcado como objetivo, deberemos completarlos uno a uno.

Luego, antes de poder planificar, debemos saber que es lo que tenemos que planificar, cuales son las tareas en las que podemos apoyarnos para conseguir el resultado esperado (en el plazo y con el presupuesto fijados).

Para identificar todas las tareas podemos apoyarnos en una herramienta como la Estructura de Desglose de Trabajo (EDT) (a veces en español se ve referida como Estructura de Descomposición de Trabajo) o también conocida por su nombre en inglés Work Breakdown Structure (WBS).

Su propio nombre nos describe lo que hace, es una estructura que vamos diseñando conforme vamos desglosando, descomponiendo, subdividiendo los entregables del proyecto en unidades menores. La EDT nos ayuda a representar los entregables que recoge el alcance del proyecto (sus componentes) y una vez detectados, nos permite identificar las tareas necesarias para realizar dichos entregables y componentes.

Como veíamos en la definición previa de proyecto, nuestro proyecto obtendrá un resultado, dicho resultado se compondrá de distintos productos y dichos productos se conseguirán a través de la realización de una serie de tareas.

Y aquí es donde ¡con las tareas del proyecto hemos topado!

Una tarea podríamos definirla como:

Generalmente, una tarea será asignada a una persona dentro del equipo para que la realice, aunque podría ser asignada a más de una persona. Puedes encontrarte proyectos donde se habla de subtareas, todo depende de la granularidad con la cual se identifiquen. Vamos a asumir que una tarea es lo suficientemente pequeña para que la realice una persona o como mucho dos. En otro caso, lo que nos encontraremos será una nomenclatura diferente, pero seguirá aplicando todo lo que tratemos aquí para el caso de una tarea.

Hay una serie de atributos básicos que debe tener cualquier tarea. Entre ellos tenemos por supuesto

• el nombre que defina clara y unívocamente a la tarea
• una descripción que defina perfectamente que debe hacerse.

Parecen obvios pero no lo son.

Muchas veces nos encontramos con tareas que no están definidas correctamente. En otras ocasiones se hace necesario utilizar un ID de la tarea para identificarla unívocamente de forma sencilla y simple por encima del nombre.

Otros atributos también importantes son

• el responsable, es decir quién es el encargado de realizar la tarea, quién es el encargado de completarla. Cada tarea debe tener un único responsable alquien que sea quien responda por ella en el futuro. Esto no significa que en su ejecución no puedan intervenir más personas (de hecho si tenemos una RACI podemos ver que pueden colaborar muchas personas).
• la duración de la misma o cuanto esfuerzo estimamos que costará realizarla.

En la duración parémonos un poco.

Es una tema bastante peliagudo y que suscita mucha polémica. Sobre todo en desarrollo de software, siempre se está discutiendo sobre si se puede estimar la duración de una tarea o no.

Las tareas deben poder estimarse siempre.

Si no lo podemos hacer, significa que no la conocemos lo suficientemente bien, nos faltan datos, no dominamos el entorno del problema o no conocemos la tecnología y/o el negocio. En algún caso podría darse que el objeto de nuestro proyecto fuera avanzar en una tecnología o en un negocio sobre el que no conocemos nada o muy poco, pero salvo en esos casos en el resto debemos poder dar una estimación.

Otro matiz es que una estimación sea válida siempre sin importar que las circunstancias cambien. Una estimación sobre el esfuerzo y/o duración de una tarea está realizada sobre unos supuestos y unos datos. Si dichos supuestos o datos sufren variación, entonces nuestra estimación deberá cambiarse para poder recoger los cambios sufridos. Una estimación se debe volver a retomar y ajustar cuando las circunstancias así lo recomienden:

Cuando hablamos de esfuerzo real consumido para la realización de una tarea ya tenemos otro atributo más.

Algunos atributos que no debemos olvidar son, por ejemplo:

• la precedencia o dependencia de otras tareas. Algunas tareas por su naturaleza para ser comenzadas deben esperar a que se completen otras tareas previamente. Esta información debemos recogerla para poder establecer una planificación correcta. En esta acción puede ser de gran utilidad contar con una herramienta que nos facilite realizar dicha tarea y que nos pueda mostrar de forma gráfica dicha precedencia.
• la prioridad de la tarea. Dependiendo del caso, varias tareas podrán realizarse a la vez, pero algunas por su naturaleza o por el interés de los stakeholders será necesario realizarlas antes que otras, de ahí que la prioridad sea una atributo necesario para que todo el mundo conozca dicha situación.
• el estado. Para saber si se ha iniciado, si está pendiente, si está completa, si le sucede algo, …
• el porcentaje completada. Para saber cuanto nos queda por hacer.

Las historias de usuario son, por así decirlo, los requisitos de usuario que vamos a desarrollar. Los atributos más generales que se le asocian a las historias de usuario son:

• Perfil. Quién está realizando la historia que se describe
• Qué quiero. Qué es lo que quiero que realice el sistema
• Para qué lo quiero. Cual es el valor de negocio que alcanzo con ello

Las historias de usuario se utilizan para que el Producto Owner describa que es lo que quiere y el equipo del proyecto, siguiendo la prioridad indicada por el Product Owner, seleccione las historias que podrá realizar en el próximo sprint (siguiendo scrum por supuesto).

Aquí tenemos que explicar algunos conceptos.

El Sprint es la iteración en la cual el equipo del proyecto va a entregar producto. Para ello, debe comprometerse a entregar una serie determinada de historias de usuario. El Product Owner (que podríamos simplificar como el cliente) aclara todas las cuestiones del equipo para ayudarles a definir el conjunto de historias que entregaran.

Sí, sí hay tareas. Cada historia de usuario para ser realizada puede necesitar que se completen una o más tareas. Estas tareas son identificadas por el equipo internamente, asignadas entre ellos y realizadas en el sprint. Forman parte del sprint backlog o pila del sprint.

Ya hablaremos de Kanban con mayor profundidad en la última entrega de esta serie, pero adelantemos algo sobre como trata Kanban las tareas. En Kanban la entrega de trabajo es a través de tareas completas no a través de producto instalado, es decir dividimos un panel en distintas columnas en función de su estado. Cuando una tarea de un estado avanzado se completa “tira” de otra de estado menos avanzado para que ocupe su lugar.

En este escenario las tareas tienen implícito su estado por la posición que ocupan y su planificación no es necesaria ya que las tareas se van completando conforme se van completando. No es un juego de palabras me explico. El Kanban proviene del Lean Manufacturing utilizado por Toyota y describe una cadena de montaje. Una tarea avanzará si hay una posición libre para ella, en caso contrario, deberá esperar a que la haya. Digamos que la planificación pasiva permite optimizar los recursos cuando el proceso está bien definido.

Espero que te haya gustado esta primera entrega del minicurso sobre Planificación de Proyectos.

En la siguiente trataremos más temas interesantes, suscríbete para no perdértela.