Muchas veces nos hemos enfrentado al desarrollo de proyectos, en donde la gestion o administracion del mismo es una tarea exhaustiva y requiere mas de un recurso para poder realizarla, pues ahora tenemos una opcion que promueve la gestion de forma agil y proactiva "SCRUM", no entraremos a detalle en los conceptos que son parte de esta nueva metodologia, si quieren ver un pantallaso de SCRUM les recomiendo vean el siguiente link http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx.
El objetivo del presente articulo es realizar un laboratorio, en donde se simule el desarrollo del proyecto con esta prometedora metodologia:
LABORATORIO SCRUM
DEFINICIONES PREVIAS AL LABORATORIO
Definiremos SCRUM como
una metodología ágil para la gestión de
proyectos, que se compone de una serie de iteraciones agiles a las cuales
denominaremos Sprint, mismas que tienen por objetivo obtener entregables del
proyecto. El proceso SCRUM se puede ver en el siguiente grafico.
Dentro de cada
iteración existen tres elementos:
-
Actores: participantes del Sprint, de los cuales mencionaremos a los
siguientes:
o
Product Onwer:
dueño del proyecto, define los requerimientos y prioridades.
o
Scrum
Master: encargado de realizar el seguimiento al proyecto en base a las
actividades que proporciona scrum.
o
Team
Member: miembro del equipo de desarrollo
o
Stakeholder:
cualquier persona que se participe en el desarrollo del producto.
o
Scrum
Project Manager: líder de los equipos SCUM.
-
Actividades: durante la realización de un Sprint definiremos las siguientes
actividades:
o
Sprint
Planning Meeting: reunión en la cual se define requerimientos, entregables y
sus correspondientes priorizaciones; la misma se realiza al inicio de cada
Sprint.
o
Daily
Standup Meeting: reunión diaria que tiene por objetivo engranar y sincronizar los
procesos de desarrollo, a cada Team Member se realiza las siguientes preguntas:
Que hizo ayer? Que se hara hoy? Que
impedimentos tiene?.
o
Revisión
de pares: actividad que tiene por objetivo hacer una revisión rápida de
métricas y estándares.
o
Sprint
Review: presentación del código funcionando (Demo) por equipos SCRUM o Team
Member, tiene por objetivo mostrar que
hemos hecho y no como los hemos hecho.
o
Innovación:
laboratorios que requieran de al menos un día para dar oportunidad de mostrar
innovaciones referente a cualquier tema, tiene por objetivo ser proactivo y dar
espacio al descanso entre cada Sprint.
-
Productos: de cada Sprint fuera de obtener los entregables se debe producir dos
documentos
o
Sprint
Retrospective: documento que indica el estado del Sprint Finalizado; tiene por
objetivo ver que esta bien, que se puede mejorar y que mejoras se puede hacer.
Para esta parte el Scrum Project Manager debe actuar como un puente de
conocimiento que promueva las estrategias de mejora en todos los equipos.
o
Sprint
Burndwon: grafico indicador de avance, permite evaluar los recursos asignados a
las metas determinadas dentro del Sprint.
CICLO DE PROCESO SCUM
Durante el laboratorio
se pretende simular una iteración o Sprint del SCRUM, tal como se indica en el
siguiente grafico:
AGENDA DEL LABORATORIO
Las actividades a
realizar dentro del laboratorio son
a) Sprint Planning Meeting. Duración 2 horas.
b) Daily Standup Meeting. Duración 15 min.
c)
Revisión
de Pares. Duración 1 hora.
d)
Sprint
Review. Duración 30 min.
e)
Sprint
Retrospective. Duración 30 min.
LABORATORIO
Sprint Planning Meeting.
Prerrequisitos:
-
Los Scrum
master debe tener una visión completa del negocio y el alcance del sistema.
-
Tener una
lista de requerimientos ordenada.
-
Tener
definido a las personas que cumplan los roles de: Product Onwer, Scrum Project
Manager, Scrum Master y Team Member.
-
Debe tener
la siguiente plantilla: Plantilla Sprint Plaining
Priorización de requerimientos:
Durante esta parte de
la actividad deben estar presentes: El Scum Project Manager, Scrum Master’s y
el Product Onwer.
1. El Scrum Project Manager debe plantilla Excel
“Plantilla Sprint Planning” definida para el laboratorio, en la hoja
REQUERIMIENTOS liste los requerimientos con un titulo y descripción, modulo (si
correspondiera) y en la columna desarrollador indique la persona quien hara el
seguimiento y desarrollo del mismo.
2. Para llenar la columna prioridad, se debe
entrar en consenso con el Product Onwer.
3. Para llenar la columna de Ref TFS use el id de
registro del requerimiento del TFS.
4. En las horas Aprox. Se debe llenar las horas
que se disponía inicialmente para cubrir el requerimiento.
5. La columna de Observaciones queda libre a
disposición del Scrum Project manager.
6. Una vez registrados todos los requerimientos en
la columna G fila 47 verifica el total de horas que necesita para cubrir los
requerimientos.
7. En la siguiente hoja dentro la plantilla defina
la disponibilidad de horas para cada desarrollador, verifique que el total de
horas en la columna D35 sean suficientes,
compárelas con la hija de requerimientos.
Aproximación Product Backlog:
Para esta parte de la
actividad deben estar presentes los Team Member, Scrum Master y el Product
Onwer.
1.
El Scrum
Project Manager debe plantilla Excel “Plantilla Sprint Planning” ya trabajada
anteriormente, debe consensuar los costos mínimos en tiempo de cada producto
y/o tarea en la lista, en caso de pensar en mas componentes añadirlos a la lista, se debe tomar en cuenta que son
componentes básicos y representan a tareas atómicas o productos elementales y
no complejos.
2.
Se asigna
un set de product backlog o entregables a los requerimientos ya priorizado y/o
seleccionados, se debe llenar solo las primeras 5 columnas.
3.
Para
llenar el tiempo estimado, se presenta un set de barajas a cada participante,
mismas que van del 1 al 8 que representan la cantidad de horas para cubrir el
product backlog correspondiente. Se debe barrer con cada product backlog bajo
la siguiente hermenéutica:
a. De define el producto a realizar y cada team
member debe escoger una carta que indique el tiempo que toma realizar la tarea
y colocarla bajo la mesa; se aclara antes si la misma será en días o en horas.
b. Al mismo tiempo presenta la carta e indica
porque el tiempo escogido.
c. Si la variación del tiempo entre todos es
grande, se vuelve a realizar el ejercicio y/o se plantea la división de tareas.
4.
Una vez
definido el tiempo estimado se debe llenar la columna de prioridad en base a la
necesidad del requerimiento.
5.
Si
existieran dependencias entre módulos estas deben registrarse en la columna de
dependencias.
6.
Finalmente
las columnas de fecha inicio y fecha fin debe llenarse con en base al acuerdo y
dependencia adquiridas. En caso de tener alguna observación se debe registrar
en la columna correspondiente.
Sprint Backlog:
En base a la
estimación anterior, se debe registrar todos los product backlog que lleven al
menos 6 horas dentro como un ítem product backlog dentro del grupo del
requerimiento, el resto será definido con el primer plan de tareas (Sprint
BackLog), estas y las tareas adicionales que sean necesarias para lograr
producir los entregables deben ser registradas en la siguiente plantilla
Project: Plantilla Scrum
Para el uso de la
platilla debe tener instalado MS Project 2007 y el plugin para la conexión al
TFS.
Esta plantilla nos
permitirá hacer el seguimiento diario de las tareas a los equipos. Es
importante mencionar que la generación de las tareas del Sprint backlog tiene
como base el techo de 7 horas para cada una de ellas y deben ser cronogramadas
acorde a la planificación inicial de la aproximación del Producto Backlog.
Daily Standup Meeting.
Prerrequisitos:
-
Haber
definido ya la plantilla Project de la actividad anterior.
-
Los
participantes de esta etapa son Scrum Master y los Team Member
Objetivo: Engranar el
proceso de desarrollo, con reuniones diarias en cada equipo SCRUM.
EJERCICIO DIARIO:
Para realizar este
ejercicio, debe reunir a los team member, y se realiza las siguientes preguntas
a los mismos
-
Que se
hizo ayer?.
-
Que se
hará hoy?.
-
Que
impedimentos tiene para realizar su tarea?.
Esto debe quedar
registrado en el Team Foundation Server, y en el informe diario en la primera
pagina que contiene columnas para estas preguntas además de las dependencias y
las observaciones.
Se adjunta al informe
diario un reporte de Bug y de total de tareas para el SCRUM Project Manager.
Revisión de pares.
Prerrequisitos:
-
Haber
terminado un Sprint.
-
Definir
una lista de productos que se presentara en el Sprint review.
-
Tener la
siguiente plantilla: Plantilla Revision de Pares
Objetivo: Verificar la
calidad interna y externa de los productos generados, esta actividad debe ser
realizada antes de la revisión con el product ownwer para verificar la calidad interna (diseño,
estándares, etc) y externa del producto (lo que el usuario percibe. Ejemplo:
interfaz de usuario).
Para realizar esta
actividad se deben llenar los siguientes cuadros.
CUADRO DE REVISION DE PARES PARA INTERFAZ DE
USUARIO.
|
ACTIVIDADES /
FORMULARIOS
|
FUNCIONALIDAD
|
ESTANDARES DE
CODIGO
|
COBERTURA DE
CODIGO
|
CODIGO
SOBRANTE
|
COMPLEJIDAD
|
|
FORMULARIO 1
|
|
|
|
|
|
|
FORMULARIO 2
|
|
|
|
|
|
|
….
|
|
|
|
|
|
|
FORMULARIO N
|
|
|
|
|
|
Actividades:
FUNCIONALIDAD:
Verificación de navegabilidad y uso del aplicativo. Llenar esta casilla con 10
en caso de tener la funcionalidad completa 1
en el peor caso.
ESTANDARES DE CODIGO:
Verificación de los estándares. Llenar
esta casilla con 10 en caso de tener todos los estándares completos 1 en el
peor caso.
COBERTURA DE CODIGO:
verificar la existencia de métodos que no son usados., Llenar esta casilla con
10 en caso de tener la cobertura completa 1 en el peor caso.
CODIGO SOBRANTE:
Verificar código comentado, duplicidad de métodos, etc. Llenar esta casilla con
10 en caso de no tener la código sobrante 1 en el pero caso.
CODIGO SOBRANTE:
Complejidad ciclo matica. Llenar este valor en base al calculo de code metrics
del VS 2010
CUADRO DE REVISION DE PARES PARA GESTORES Y
SERVICIOS.
|
ACTIVIDADES /
FORMULARIOS
|
UNIT TEST
|
ESTANDARES DE
CODIGO
|
COBERTURA DE
CODIGO
|
CODIGO
SOBRANTE
|
COMPLEJIDAD
|
|
GESTOR / SERV
1
|
|
|
|
|
|
|
GESTOR / SERV
2
|
|
|
|
|
|
|
….
|
|
|
|
|
|
|
GESTOR /
SERV N
|
|
|
|
|
|
UNIT TEST:
Verificación de la existencia y el cumplimiento del assert de Unit Test. Llenar
esta casilla con 10 en caso de tener la funcionalidad completa 1 en el peor caso.
ESTANDARES DE CODIGO:
Verificación de los estándares. Llenar
esta casilla con 10 en caso de tener todos los estándares completos 1 en el
peor caso.
COBERTURA DE CODIGO:
verificar la existencia de métodos que no son usados., Llenar esta casilla con
10 en caso de tener la cobertura completa 1 en el peor caso.
CODIGO SOBRANTE:
Verificar código comentado, duplicidad de métodos, etc. Llenar esta casilla con
10 en caso de no tener la código sobrante 1 en el pero caso.
CODIGO SOBRANTE:
Complejidad ciclo matica. Llenar este valor en base al calculo de code metrics
del VS 2010
Sprint Review.
Prerrequisitos:
-
Haber
terminado un Sprint.
-
Haber
concluido la revisión de pares.
Objetivo: Exponer que hemos hecho y no como los hemos hecho.
DEMO
Cada tem member o
responsables de los entregables debe preparar un demo; para ver codigo
funcionando bajo las siguientes consideraciones:
-
El punto
no es demostrar que el software funciona, pero SI que es útil y valioso
-
Proporcione
información de contexto y escenarios para que las personas se relacionen con
las funciones (juegos de roles funcionan muy bien!)
-
No se
olvide que hay un elemento de espectáculo y entretenimiento. Si la gente
trabaja 2 semanas para llegar a su demo que sea una buena experiencia para
ellos.
-
Nunca se
muestra nada que no este en estado 100% Done
NUESTRA AGENDA REVISIÓN DE SPRINT
1.
Armar los
escenarios óptimos, para el Demo.
2.
El Scrum
Master abre la revisión y reitera el propósito u Objetivo
Mostrar lo que el
equipo ha construido durante el último Sprint
Colaborar con la
audiencia
Recopilar comentarios
3.
El propietario
del producto presenta lo que él quería del Sprint
Describe la meta del
Sprint y por qué la eligio
Explicar por qué es
importante para el proyecto y para la sociedad en su conjunto
Dar a conocer a la
gente el contexto donde nos encontramos en la mayor escala de las cosas
4.
El Scrum
Master presenta el sprint
Cuenta la historia del
Srpint: ¿Cómo te fue? ¿Ha tenido incidentes de soporte de nivel
3? (Nosotros nos encargamos de los de una caja de soporte en tiempo de
trabajo) ¿Había alguien enfermo? Los nuevos miembros del equipo?¿Hay algo
más importante?
Dar un estado del
Sprint y una visión general de qué historias se terminaron y cuáles no
5.
Para cada
historia:
El miembro del equipo
hace una demostración, y muestra la descripción de la historia o Work Item
Asociado adicionalmente describe los límites (deberia poder explicar los
criterios de aceptación)
Demostrar la
característica en un sistema real y en este caso generar el reporte y mostrar
el resultado.
Anotar las preguntas y
escuchar los comentarios mientras usted realiza la demostracion. Recuerde
que debe recoger ideas para nuevas características y casos de usuo para incluir
en la pila de productos.
Repita el paso 4 para
todos los miembros del equipo
6.
Scrum
Master cierra la demo
Resuma y agradezca a
la gente por su asistencia y participación
Comunicar la hora y la
fecha para el próximo fin de Sprint y Revisión.
PROTOCOLO
1.
El equipo expone el objetivo del sprint, la
lista de funcionalidades que se incluían y las que se han desarrollado.
2.
El equipo
hace una introducción general del sprint y demuestra el funcionamiento de
laspartes construidas.
3.
Se abre un
turno de preguntas y sugerencias sobre lo visto. Esta parte genera información
muy valiosa para que el propietario del producto, y el equipo en general,
puedan mejorar el valor de la visión del producto.
4.
El Scrum Manager, de acuerdo con las agendas
del propietario del producto y el equipo cierra la fecha para la reunión de
preparación del siguiente sprint.
INNOVACION
Después de cada Sprint
es necesario, realizar un o dos días de revisión y/o investigación para no
fatigar al equipo, de forma que de espacio al nuevo Planning Meeting.
Actividades de grupo.
ELABORACION DEL SRPINT RETROSPECTIVE.
Prerrequisitos:
-
Haber terminado
un Sprint.
-
Tener la
siguiente plantilla: Plantilla Retrospective
Objetivo: Verificar que esta bien, que se puede
mejorar, como mejorarlo, la estrategia de mejora.
Una vez llenado la
hoja RETROSPECTIVE con las estrategias de mejora, socializar la información en
una reunión con la participación del SCRUM Project Manager, Scrum Master y los
Team Member.
