SCRUM… desarrollos agiles…

Para muchos de los ingenieros de software y arquitectos siempre nos asaltó de una u otra forma la duda de el como plantear un proyecto de ingenieria de software de tal forma de cumplir con los tiempos de manera rápida, pero sin dejar de lado temas como la calidad y el resultado de la solución.  Así como existen variadas metodologías de desarrollo de proyectos (RUP, XP, 4+1, etc), SCRUM es una mas de ellas, creada alrededor del año 1986 por un par de japoneses, lo que busca justamente es el desarrollo de proyectos (principalmente del area de ingeniería de software) enfocados en la gestión del proyecto de software de manera flexible y rápida.

SCRUM es un modelo de referencia que define un conjunto de buena prácticas de la industria del software, se basa en los desarrollos incrementales e iterativos, cuyo ciclo de vida puede bosquejarse de la siguiente manera:

Así como en las otras metodologías de desarrollo, deben de existir roles que administren el proyecto (Jefes de proyecto, Analistas, Programadores, etc), SCRUM define sus propios roles para la metodología:

Rol Product Owner: conoce y marca las propiedades del proyecto o producto.  Es un jefe de proyecto o product manager moderno.

Rol ScrumMaster: es la persona que conoce y asegura el seguimiento de la metodología, guiando las reuniones, y ayudando al equipo a resolver cualquier problema que pueda tener.

Rol ScumTeam: son las personas responsables de implementar las funcionalidades elegidas por el Product Owner.

Rol Usuario o Cliente: son los beneficiarios finales del producto, y son quienes van viendo los progresos de los prototipos mostrados, pueden aportar ideas, sugerencias o necesidades.

Como se puede apreciar en esta metología, el usuario o cliente final juega un rol mas que importante incluso definiendo necesidades o aportando ideas durante el ciclo de desarrollo, algo que no se habia visto en metodologías como RUP u otras.  En definitiva y eso no lo olvidemos nunca, los desarrollos de proyectos de software son para satisfacer los requerimientos funcionales y no funcionales de los interesados en el proyecto (stakeholders), definiendo métricas y evaluando procesos de mejores prácticas para poder cuantificar de mejor manera el proyecto.

¿Que es eso de Requerimientos funcionales (RF) y no funcionales (RNF)?  (Buena pregunta desgraciao….  jajaja)

Voy a tratar de explicarlo con mis palabras: Todo proceso de desarrollo de software (al menos la gran mayoría) pasa antes que todo (ojo con esto VF….  jajajaja) por la definición de los requisitos de software, en el fondo, lo que buscan es poder identificar que es lo que el usuario quiere que hagamos (aunque a veces saben lo que no quieren..   en fin..   hay que ser un poco psicologo al respecto ademas…  jajaja), estos requerimientos la mayoria de las veces son especificos de la aplicacion que se desea desarrollar, estos requisitos especificos del problema o del negocio se denominan REQUERIMIENTOS FUNCIONALES, por ejemplo: “quiero que el sistema muestre un listado con los pagos por fecha de los clientes para un mes en particular”.  Ese es un RF.  Los RNF permiten medir los atributos de calidad, y no son tan específicos del software, sino que apuntan a temas mas generales relacionados con la calidad o eficiencia de la aplicación, por ejemplo:

1. Escalabilidad

2. Tiempos de respuesta

3. Eficiencia en los procesos

4. etc etc etc….

Muchas veces estos vienen de forma implicita en los mismos RF, pero otras veces es necesario hacerselos conocer a los mismos clientes o usuarios finales con la finalidad de que podamos medir dichos atributos en terminos de calidad y complejidad de la aplicación de software.

y volviendo a SCRUM…

Como ya conocemos a los integrantes del equipo y sus funciones, ahora vamos a comenzar a analizar las acciones que se realizan dentro del equipo de desarrollo.

Básicamente las acciones de scrum son:

1. Product Backlog

2. Sprint Backlog

3. Daily Scrum Meeting

Y continuando con la metodología agil SCRUM…

Como mencionabamos anteriormente scrum define muy claramente los actores involucrados y sus funciones dentro del team, pero además estas muy bien identificadas las acciones dentro del team.

El Product Backlog contiene las acciones, tareas, funcionalidades, requerimientos que el cliente desea desarrollar.  El cliente es el responsable de crear y gestionar la lista, aunque la idea en realidad es que el Product Owner pueda definir una planilla base y que el mismo la vaya actualizando en base a los requisitos del cliente.

El Sprint Backlog se obtiene a partir de la gestión aplicada a la planilla generada por el Product Backlog.  Todas las actividades que el PO defina como parte importante de los requisitos, van a formar parte del Sprint Backlog.  Estas tareas por lo general se deben realizar dentro de un periodo entre 2 o 4 semanas (Es lo que recomienda la metodología).  Es decir, hay sprint backlogs de 2 semanas, y hay sprint backlogs de 4 semanas.  Esto debe de ser definido antes de comenzar a desarrollar el sprint backlog, es mas, del product backlog se sacaran la lista de tareas necesarias para poder armar el sprint backlog.  Algo importante que hay que tener en cuenta con los sprint backlog que una vez que comienzan, este NO puede ser modificado, por ende hay que esperar hasta que concluya para poder realizar la modificación correspondiente.

El Daily Scrum Meeting corresponde a una tarea ciclica que se debe realizar todos los días para los cuales hallan sprint backlogs que no se hallan terminado.   Se trata ni mas ni menos de una reunión que no debe durar mas de 30 minutos, en la que se le hacen preguntas especificas a los integrantes del equipo:

1. Que tareas haz realizado desde la última reunión (Dime lo que haz hecho…    pero en bonitas palabras eso si..   a lo JP)

2. Que tareas vas a realizar el dia de hoy (Dime lo que vas a hacer hoy dia loquillo….)

3. Necesito que me digan para cada uno de los sprint desarrollados que problemas, obstaculos o riesgos han impedido el normal desarrollo del trabajo, y que ayuda necesitan para poder resolverlos.  Este trabajo debe ser realizado por el scrum master quien debe dejar resueltos los temas y eliminar todos los obstaculos posibles.

El trabajo de realizar los movimientos de tareas desde el product backlog hacia el sprint backlog debe efectuarse en una reunión denominada Sprint Planning Meeting cuyo objetivo es planificar las tareas que serán traspasadas desde el PB hacia el SB.  Por lo general en esta reunión participan: El Product Owner, el Scrum Master y el Scrum Team.

Como toda reunión lo que busca es obtener un objetivo, el resultado del Sprint Planning Meeting se denomina Sprint Goal, que corresponde a un pequeño documento que describe o explica lo que Sprint intentará alcanzar.  Este documento debe ser revizado en una pequeña reunión de unas 2 horas llamada Sprint Review. En este punto ya debiéramos tener algo mas tangible para mostrarle al cliente.  A esta reunión a parte de los mencionados anteriormente pueden asistir los clientes para analizar los avances en el proyecto.

Cuando finaliza el sprint backlog y el sprint review, pasamos a una nueva etapa donde el equipo reviza los objetivos propuestos inicialmente en el sprint backlog, se aplican los cambios y ajustes necesarios, se marcan los aspectos positivos (para repetirlos..    algo asi como un patron metodológico..   q entrete no…  jejeje) y los aspectos negativos obviamente también son marcados para evitar volver a cometer el mismo error (Como q este sistemita aprende solito..  pero hay que entregarle el conocimiento necesario..   ahora si que se puso weno)..   Demosle una mirada al siguiente diagrama para retroalimentar lo aprendido…

Algunas consideraciones…

Como tal vez muchos se estarán preguntando, los tiempos son muy cortos, y hay que trabajar duro para poder lograr los objetivos propuestos.  Pero esta metodología no solo ha sido aplicada a temas relacionados con los proyectos de software, sino que ha sido probada con éxito en variadas ramas.  La idea obviamente es que cada empresa, proponga sus propios tiempos, no necesariamente debe de ser 2 o 4 semanas, tal vez un poco mas, pero SCRUM lo recomienda de esa forma.  Supongamos que deseamos implantar el modelo en una constructora.  Si definimos como tiempos de sprint backlog 2 semanas, lo mas probable es que las personas a cargo de la construcción no tendrán ningún objetivo cubierto, producto de que el negocio de ellos requiere de una planificación un poco mas larga.  Lo mismo sucedería con un proyecto de software mal planificado.  Si la estimación de tiempo es erronea, los desarrolladores por mas horas extras que trabajen, no podrán cumplir los sprint y el documento que identifica los objetivos contendrá demasiados errores, lo que atrasará definitivamente el proyecto.

Básicamente eso es SCRUM y la forma en que trabaja.  La recomiendo mucho ya que es bastante agil y los resultados son buenísimos.

En un próximo capitulo voy a comentar algo sobre XP que también es una metodología agil de desarrollo de proyectos de software.

Suerte!!!

Anuncios

1 comentario

Archivado bajo Arquitectura de Software

Una respuesta a “SCRUM… desarrollos agiles…

  1. Pingback: XP (Extreme Programming) « Juanjo's Blog

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s