Un afectuoso saludo a todos, pues aqui traigo un tema arto interesante :P, de echo ya tenia algun tiempo queriendo escribir sobre esta metodologia pero por X o por Y no lo habia echo, ahora estoy documentando un proyecto en el que presisamente ocupe SCRUM por lo que aprovechando la documentada del marco teorico, me decidi a escribir por fin este post.
SCRUM
Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80, su objetivo primordial es elevar al máximo la productividad de un equipo. Reduce al máximo la burocracia y actividades no orientadas a producir software que funcione y produce resultados en periodos muy breves de tiempo. Sólo abarca prácticas de gestión sin entrar en las prácticas de desarrollo como puede hacer XP. Más bien delega completamente la responsabilidad de decidir la mejor manera de trabajar para ser lo más productivos posibles.
La forma de trabajar con scrum es por medio de la product backlog y el sprint, la llamada product backlog es una pila (los que no conoscan las pilas imaginen un pastel con muchas capas, el recipiente que lleva al pastel es el contennedor mientras que cada capa de pan o lo que sea es un elemento de la pila) que contiene todas las funcionalidades que deberá tener el sistema, las funcionalidades serán acomodadas en esta de acuerdo a su importancia en el sistema, es decir una funcionalidad primordial se pone en una posición superior a la de una funcionalidad poco trascendente, por otra parte el sprint es un periodo de tiempo calculado, no mayor a 30 días (algunos dicen que hasta 40 dias esta bien, ahora si que va en gustos chato :P) hábiles en el cual se desarrollaran ciertas funcionalidades del sistema que son tomadas de la product backlog, estas funcionalidades formaran una nueva pila a la que se le llama sprint backlog, cada funcionalidad finalizada pasara a una lista de nombre “incremento de funcionalidad”, al termino del sprint se hace una reunión para ver el rendimiento del equipo y los avances realizados hasta el momento, si alguna funcionalidad no fue finalizada o existen cambios indicados por parte del propietario del producto dicha tarea se pondrá en el sprint del siguiente periodo, las tareas que se realicen por cada sprint dependerán enteramente del equipo de desarrollo, sin embargo existen algunas prácticas que son comunes y que deben de realizarse en cada sprint estas se enuncian a continuación:
Sprint Día 1 (Planificación)
En scrum es importante saber identificar cual es el papel de cada uno de los implicados para saber cuáles son sus responsabilidades en el desarrollo del sistema, esta identificación se da casi siempre de manera natural y debe de estar explicita desde el principio del proyecto, sin embargo cuando estos roles no están bien definidos podemos caer en el error de asignar tareas a quien no le corresponde, causando de esta manera un atraso en el proyecto, para evitar esto scrum define de forma sencilla tres tipos de roles con sus respectivas responsabilidades:
Propietario del producto
Representa a todos los interesados en el producto final. Sus áreas de responsabilidad son:
• Financiación del proyecto
• Requisitos del sistema
• Retorno de la inversión del proyecto
• Lanzamiento del proyecto
Equipo
Responsable de transformar la pila del sprint (Backlog) en un incremento de la funcionalidad del software.
Gestor de Scrum (Scrum manager o Scrum Master):
Responsable del proceso Scrum se encarga de organizar y guiar el desarrollo, evitar atrasos y proporcionar información a quien lo requiera ya sea al propietario del producto, a algún miembro del equipo o al equipo en general.
Al comienzo de un proyecto, este se divide en cierto número de funcionalidades, las cuales en un momento dado pueden subdividirse si se requiere, una vez divididas se les asigna a cada una de ellas una prioridad, es decir se eligen cuales son las de carácter necesario, cuales son de tipo urgente y cuáles no son realmente necesarias, hay que tomar en cuenta que alrededor del 45% de las funcionalidades solicitadas por los usuarios rara vez son utilizadas, por lo que inicialmente hay que enfocarnos en las que realmente sean funcionalidades necesarias, después todas estas funcionalidades se guardan en un apartado lógico llamado product backlog lugar del cual iremos sacando teóricamente las tareas que debemos realizar.
En scrum para realizar la división de funcionalidades se hace lo siguiente:
1) Planificación de sprint: En este punto se determina el tiempo de duración del sprint y se establecen las fechas en las cuales se cubrirá dicho tiempo.
2) Se calcula la velocidad inicial del equipo: este es un proceso muy sencillo de implementar, lo primero que se debe de hacer es multiplicar el número de horas de trabajo por el número de días que dura el sprint en caso de ser mas de un desarrollador, se multiplica la cantidad anterior por el numero de desarrolladores, con esto tendremos el total de horas de trabajo, ahora bien scrum es consciente de que las horas de trabajo no son forzosamente de rendimiento, es decir puede que trabajemos 5 horas al día, sin embargo debido a diversas circunstancias (Tiempo para iniciar, descansos, comidas etc.) realmente estamos rindiendo únicamente 3 horas, es por esto que scrum usa un porcentaje llamado factor foco para determinar la velocidad de avance, inicialmente el valor del factor foco será del 70%, por lo que si multiplicamos (número de horas al día) x (número de días del sprint) x [número de desarrolladores] x (factor foco inicial) obtendremos la velocidad inicial del equipo, este valor refleja la cantidad real de horas que disponemos para trabajar en el presente sprint, a medida que vallamos avanzando en el proyecto este valor se ajustara cada sprint pudiendo aumentar, disminuir o quedar con el mismo valor.
3) Exposición de historias: En esta etapa el Scrum Máster, el Dueño del Producto y el equipo se juntan para estimar las historias (es decir tener un panorama general de lo que tiene que hacer el sistema) y decidir cuales podrán realizarse durante el Sprint. Esta primera parte de la reunión de planificación se conoce con el nombre de "Exposición". Es importante destacar que la reunión es llevada adelante por el Scrum Máster, el cual tiene que asegurarse que la reunión no divague en temas que no afectan al Sprint y tiene que poder cerrar la reunión con las historias priorizadas y estimadas. Además, sólo se planifica el Sprint que está iniciando.
4) Creación de historias: El Dueño del Producto presenta las historias de usuario(es algo similar a los casos de uso), las cuales se escriben con títulos que el equipo comprenda en post-it amarillos grandes. Estos post-it se pegan en la mesa para que todos los vean. Cada post-it contiene 4 datos:
• Nombre de la historia
• Importancia
• Estimación
• Validación
o El nombre de la historia es una muy breve frase o título que describe a la historia (por ejemplo, "exportación de saldos", "alta de usuario", "modificación de dirección de facturación", etc.).
o La importancia es un número, mientras más grande el número más importante la historia (y deberá terminarse antes que historias de menor importancia). La importancia la indica el Dueño del Producto.
o La estimación es un parámetro que indica el número de horas de esfuerzo que nos llevara realizar alguna tarea, en principio se deja en blanco, ya que será completada más adelante (pero dentro de la misma reunión).
o La validación será la forma que el Dueño del Producto dará por aceptada la historia en la reunión de Revisión (Demo del Producto).
Así, luego de la exposición del Dueño del Producto, se tendrá cierto número de historias pegadas sobre la mesa, ordenadas por importancia.
El Equipo además puede agregar historias propias, generalmente técnicas, que considera necesarias para la ejecución del proyecto (por ejemplo, la creación de un repositorio de código, creación de un estándar, diseño etc.).
5) Estimación de historias: El Equipo y el Scrum Master son quienes estiman el tiempo que tardaran en realizar las historias. El Dueño del Producto está presente durante la estimación, para responder cualquier duda que pueda surgir, pero no estima ni opina sobre la estimación.
El equipo estima las tareas hasta un número mayor al de su capacidad (que es el valor de velocidad inicial calculado anteriormente). De esta manera, si durante el Sprint llega a terminar antes puede seguir tomando historias, y al estar estimadas luego se pueden tener en cuenta para el Factor de Foco del próximo Sprint.
Teniendo las historias estimadas, el equipo seleccionará por orden de importancia una cantidad de historias cuya estimación no supere al número de horas que hemos calculado para nuestro sprint.
Estas historias seleccionadas serán las que conformarán el Backlog del Sprint, y es el compromiso que asume el Equipo frente al Dueño del Producto. Estas historias se completarán durante el Sprint, y serán las demostradas el último día durante la Revisión del Sprint.
6) Planificación: Después de finiquitada la primera reunión el equipo y el Scrum Master ya sin la presencia del dueño del producto se vuelven a juntar para crear las tareas de las historias, y estimarlas.
En esta reunión el equipo toma cada una de las historias del Backlog del Sprint (las comprometidas) y crea las tareas que necesita resolver para terminar con la historia. Cada tarea no puede tener más de 4 días ideales (de ser mayor, debe ser dividida).
Sprint Día 2 (Inicio del proyecto)
En el segundo día, los desarrolladores eligen las tareas que van a realizar de la pila sprint backlog, tomándolas libremente, por orden de importancia. “Cada desarrollador elige la tarea, nadie se la asigna”.
Al tomar una tarea del Sprint, el desarrollador escribe su nombre en la nota adhesiva, la pasa a la columna de "Asignada" y comienza el trabajo en la misma.
Durante el tiempo que dura el sprint es norma de scrum tener una reunión diaria de no más de 15 minutos, en ella el equipo rápidamente hará un repaso de su situación y del esfuerzo restante para finalizar el Sprint. Cada integrante cuenta cuántos días le falta para finalizar la tarea que tiene asignada: tacha el valor anterior en la estimación de la tarea, y escribe la nueva estimación.
El Scrum Master lidera la reunión, y debe asegurarse que no divague en otros temas, para lograr esto debe de apegarse a cuatro preguntas básicas:
• ¿Qué hiciste ayer?
• ¿Qué vas a hacer hoy?
• ¿Qué ayuda necesitas?
• ¿Existe algún impedimento que te permita finalizar la tarea?
Cabe aclarar que durante el Scrum Diario no se resuelven problemas, tan sólo es un punto de encuentro para que todo el equipo informe su estado al resto y puedan sincronizar sus actividades. En caso de que alguien tenga un conflicto que deba que comentar con el scrum manager deberá quedarse hasta el final de la reunión y exponerlo únicamente al scrum manager y a las personas que pudieran verse directamente afectadas.
Sprint Día 3 (Terminando tareas)
Una vez repartidas las tareas, todos los días durante el Scrum Diario cada integrante dice cuánto le falta para terminar la tarea que tiene asignada. Cuando se finaliza una tarea, la misma se ubica en la columna de "Terminados" y el desarrollador toma otra tarea para seguir.El momento de finalización de una tarea puede o no coincidir con su estimación. Es decir, por ejemplo, una tarea estimada en 4 días puede haber llevado 1 día en resolverla; a sí mismo, una tarea estimada en 1/2 día puede llevar finalmente 3 días, o una tarea de dos días puede llevar 2 días resolverla. La estimación de esfuerzo restante para la tarea se actualiza todos los días durante la reunión de Scrum Diario. Aquí se debe tener en cuenta que solo se debe estimar el tiempo restante para finalizar la tarea, no importa el tiempo que pasó, solo el que falta.
Tarea pendiente esperando ser tomada por un miembro del equipo
Es que las tareas se resuelvan en el orden de importancia de las historias de usuario. De esta manera el equipo se asegura de ir terminando primero las historias más importantes para el Dueño del Producto.
Finalización del Sprint
El último día del Sprint, ocurrirán dos reuniones importantes para el equipo, las cuales ya fueron planificadas por el Scrum Máster desde el inicio del Sprint. Estas reuniones son:
• Reunión de Revisión
• Reunión de Retrospectiva
Reunión de Revisión del Sprint
En la reunión de Revisión (o demostración) el Equipo muestra a los asistentes el trabajo realizado durante el Sprint. Se realiza una demostración "en vivo" del producto, mostrando el funcionamiento de las historias terminadas en el Sprint.
Esta demostración se realiza preferentemente en una de las PC de los desarrolladores, y se muestra el producto real funcionando (no hay diapositivas, ni papeles impresos: se muestra el sistema funcionando realmente) y se comienza contando el Objetivo del Sprint, y cuál era el plan original del mismo con las historias que se desarrollarían. Luego se comenta lo que es lo que se encuentra terminado y se explica que ha pasado con lo no desarrollado a grandes rasgos.
A esta reunión asisten todos los integrantes del equipo, el Scrum Máster, el Dueño del Producto, usuarios y cualquier otro interesado en el sistema.
El Dueño del Producto (y los usuarios), al ver el sistema funcionando, pueden empezar a visualizar la solución, verificar si el producto está llevando el rumbo que ellos pensaron desde el inicio, si sigue siendo útil, y qué cambios se podrían hacer. Todos pueden proponer mejoras, pero sólo el Dueño del Producto decidirá si las mismas formarán parte del sistema final.
Es muy importante tener en cuenta que lo que se muestra al usuario, es en base a la reunión de planificación que se había realizado inicialmente de cómo iba a aceptar la historia y en qué condiciones. Es importante tener esto en claro en la Reunión de Planificación del Sprint.
Esta reunión no debe durar más de 2 horas, en general, con 1 hora es suficiente para que todos puedan ver el producto, debatirlo y proponer cambios para el próximo Sprint.
Reunión de Retrospectiva del Sprint
La retrospectiva del Sprint es una reunión en la cual los Miembros del Equipo discuten el Sprint que acaba de finalizar, y determinan qué podría cambiarse en el próximo Sprint para que sea más productivo y mejor.
La Revisión del Sprint se focaliza en "Qué" construye el equipo, mientras que la Retrospectiva se centra en "Cómo" están construyendo el sistema.
El Scrum Máster lleva la reunión adelante, mostrando la dedicación del equipo dando a conocer los imprevistos e impedimentos que pudieron influir en el trascurso del Sprint.
El equipo divide los temas del Sprint en:
• Bueno
• A mejorar
• Mejora concreta (de aquí se elegirán dos o tres para poner foco en el próximo Sprint)
La dinámica será en que cada miembro exponga su impresión del Sprint y agregue temas a las dos primeras columnas. Cuando los miembros del equipo discuten sobre el Sprint que acaba de finalizar, no solo tratan temas técnicos, sino que tiene que surgir cualquier tipo de mejora.
Con esto se da por terminado el Sprint, y el equipo se prepara para comenzar una nueva reunión de planificación al día siguiente hasta llegar a la finalización eh implementación del producto.
fuentes:
The beast
Scrum
Explicando Scrum a mi abuela
Agile Spain
No hay comentarios:
Publicar un comentario