Oscar Luis Sánchez Jara
I am an enthusiastic software developer, I like working with PHP, Ruby, Golang, I have knowledge in Ethical Haking and I love playing drums rock \uu/
Planificación de proyectos
Desarrollo Ágil de software
/dev-lusaja
/dev_lusaja
Agenda
- Definición de la meta.
- Estimación de historias (Puntos).
- Disponibilidad de recursos.
- Estimación de tareas.
- Factor de dedicación.
- Definición de fechas.
- Burndown Chart.
Definición de la meta
En la metodología ágil un proyecto se elabora por etapas (Sprint) cada una de estas etapas debe aportar valor funcional al desarrollo del proyecto.
Durante el Sprint Planning debemos elegir los Items del Product BackLog que se van a trabajar.
Product Backlog
Definición de la meta
Vale recalcar que cada equipo de desarrollo debe definir el tiempo que dura su Sprint.
Scrum recomienda que la duración del Sprint vaya desde 1 a 4 semanas como máximo.
Estimación de historias
Cuando ya hemos definido el alcance de nuestro Sprint el siguiente paso es tomar cada requerimiento (User Story) y asignarle una puntuación que va a ir de acuerdo a la madurez del equipo.
Puntos de Historia
Para definir la complejidad de una User Story utilizaremos el método "puntos de historia".
Este método nos permitirá saber que tan compleja es una historia.
Se recomienda que el equipo tenga 2 puntos de referencia: 1 historia sencilla y 1 historia compleja.
Puntos de Historia
Historia sencilla:
Esta historia tendrá una dificultad mínima, la cual utilizaremos como punto de partida para compararla con las historias que hemos definido (User Story).
Una vez realizada la comparación le asignaremos una complejidad a nuestra historia.
Puntos de Historia
Historia compleja:
Esta historia tendrá una dificultad máxima, la cual utilizaremos como punto de referencia final. Esto quiere decir que, si una historia sobrepasa esta dificultad debemos de dividirla.
Puntos de Historia
Tengamos en cuenta que los puntos de historia definen la dificultad de la User Story dentro del equipo de desarrollo.
Estos puntos de historia nos ayudaran a calcular el tiempo (horas/días) que nos llevara desarrollarla.
Serie Fibonacci para los puntos de historia
Ejemplos de User Story
Disponibilidad de recursos
Durante este paso, debemos de realizar un cuadro donde tengamos la cantidad de desarrolladores que trabajaran durante el Sprint y la cantidad de horas diarias.
Esto con la finalidad de saber cuantas horas de trabajo podemos cubrir con nuestro equipo.
Disponibilidad de recursos
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | Total | ||
|---|---|---|---|---|---|---|---|---|---|
| T1 | 8 | 8 | 8 | 8 | 8 | 8 | 8 | 56hrs | BackEnd |
| T2 | 8 | 8 | 6 | 6 | 6 | 8 | 8 | 50hrs | FrontEnd |
| T3 | 6 | 6 | 6 | 6 | 8 | 8 | 8 | 48hrs | Q.A |
| 154hrs |
En el cuadro podemos observar la cantidad de horas que trabajara cada desarrollador durante el Sprint de 7 días. Obteniendo un total de 154hrs de disponibilidad.
Estimación de tareas
El siguiente paso es realizar la identificación de las tareas que se deben de realizar para satisfacer la User Story.
Durante este proceso a cada tarea se le asigna un tiempo de desarrollo estimado en horas.
El equipo debe dividir la historia en tareas que se puedan realizar por separado, con la finalidad de que estas tareas sean divididas entre el equipo.
| BackEnd | FrontEnd | Q.A | |
|---|---|---|---|
| Task 1 | 10 hrs | 10 hrs | 8 hrs |
| Task 2 | 5 hrs | 5 hrs | 8 hrs |
| Task 3 | 12 hrs | 5 hrs | 2 hrs |
| Task 4 | 8 hrs | 6 hrs | 6 hrs |
| Task 5 | 5 hrs | 6 hrs | 6 hrs |
| Task 6 | 4 hrs | 5 hrs | 5 hrs |
| Task 7 | 9 hrs | 9 hrs | 6 hrs |
| Task 8 | 2 hrs | 3 hrs | 6 hrs |
| Total horas | 55 hrs | 49 hrs | 47 hrs |
Estimación de tareas
Estimación de tareas
La sumatoria de las tareas por cada rol nos da un total de 151 hrs.
Esta cantidad de horas es la que necesitamos cubrir con el equipo de desarrollo para satisfacer la User Story.
En este punto entra el factor de dedicación.
Factor de dedicación
El factor de dedicación es el tiempo que el equipo emplea durante la jornada en realizar actividades que sumen al proyecto.
Este dato es un valor variable, que dependerá de la madurez del equipo y sera ajustado en cada Sprint
| BackEnd | FrontEnd | Q.A | |
|---|---|---|---|
| HDR | 56 hrs | 50 hrs | 48 hrs |
| FD | 0.8 | 0.8 | 0.8 |
| HRE | 44 hrs | 40 hrs | 38 hrs |
| HNT | 55 hrs | 49 hrs | 47 hrs |
Utilizando un factor de dedicación del 80%
HDR = Total de horas disponibles por recursos.
FD = Factor de dedicación.
HRE = Horas reales empleadas por recurso.
HNT = Horas necesarias para desarrollar las tareas.
Factor de dedicación
Operando con el factor de dedicación obtenemos que el tiempo real que el equipo trabajara es de 122hrs.
Con lo cual nos podemos dar cuenta que no es suficiente para realizar todas las tareas estimadas para la User Story.
Cuando se presente este caso debemos de re-definir el alcance de la User Story.
Definición de fechas
En este punto debemos asignarle a cada User Story una fecha limite de entrega por parte del equipo de desarrollo.
Esto nos ayudara a definir un deadline que tendrá el equipo para culminar la funcionalidad y validar su funcionamiento.
Burndown Chart
Un gráfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la que se está completando los objetivos/requisitos. Permite extrapolar si el Equipo podrá completar el trabajo en el tiempo estimado.
Este gráfico nos permitirá saber al final del Sprint si el factor de dedicación que estamos utilizando es el correcto.
Estimación de proyectos
By Oscar Luis Sánchez Jara
Estimación de proyectos
Desarrollo ágil de software
