Scrum

Notas del editor

• #2: Scrum es una metodología para el desarrollo ágil de software. El desarrollo ágil de software procura: mejorar la habilidad para responder rápidamente a los requerimientos del cliente disminuir los periodos de espera para ver algo funcional reducir el stress de los participantes al mismo tiempo que se incrementa su productividad
• #3: En las métodologías tradicionales, se parte de la premisa que todo el problema está bien definido antes de empezar el desarrollo: Las reglas del negocio, las interfaces, los recursos, etc que se requieran no cambiarán. En la práctica, ocurren frecuentes ajustes, precisiones y correcciones, principalmente en las interfaces, pero también en los recursos y las reglas de negocio. En las metodologías tradicionales, cada cambio deja desactualizada la documentación inicial. El proyecto presenta una resistencia al cambio porque esto puede convertirse en recursos no presupuestados. Y cada vez que se procesa un cambio, no hay garantía de que eso no se vuelva a repetir. De hecho, en la práctica puede ocurrir muchas veces. Las metodologías agiles, en particular Scrum, encaran el problema de un modo pragmático. Si la evidencia empírica muestra que los requerimientos siempre cambian, ¿no sería mejor encarar el viaje del proyecto dividiéndolo en tramos cuyo planeamiento, ejecución y corrección de rumbo fueran más manejables?; si habrán ajustes frecuentes en el rumbo, ¿por que gastar recursos en mantener un mapa detallado de todo el viaje cada día?, es suficiente mantener un mapa detallado sólo del tramo que se está recorriendo, y un esbozo de la ruta general. La experiencia muestra que es recomendable un tramo de entre 2 y 4 semanas. Al inicio se hace el mapa detallado del tramo que se hará, y las tareas requeridas, y el equipo actúa como un solo hombre para llevarlas a cabo. Mientras el equipo trabaja, el encargado del viaje va manteniendo el esbozo, quizas incorporando nuevas cosas que ver, o incluso algún cambio en la ruta. Eso no distrae al equipo hasta que termine el tramo. De esa manera se pueden incorporar los cambios sin interferencias, un tramo a la vez, hasta que se completa el viaje. Las entregas frecuentes permiten que el cliente no tenga que esperar mucho hasta ver reflejadas las funcionalidades que requiere, o los cambios que ha planteado. Son también una fuente de retroalimentación, que permite estimar mejor qué funcionalidades es realmente posible cubrir en el tiempo deseado, para ajustar la cantidad de recursos o el tiempo necesarios.
• #9: En Scrum existem 3 roles principales: Product Owner Scrum Master Scrum Team
• #10:      El Product Owner, o Propietario del Producto, representa al cliente y conoce la lógica del negocio del producto; lo que el producto debe hacer desde el punto de vista de los usuarios.      Produce y administra la Lista de Pendientes del Producto, recogiendo y procesa los requerimientos, comentarios y sugerencias del cliente y los usuarios.     Al inicio de cada sprint, prepara una versión fechada que contiene los pendientes de más alta prioridad y que sirve de base para que, junto con el Lider Scrum y el Equipo Scrum, se obtenga la Lista de Tareas del Sprint.
• #11: El Scrum Master, o Lider Scrum , se encarga de proveer al Equipo Scrum del ambiente y las facilidades que requiere para hacer el desarrollo. Da soporte al equipo y ayuda a resolver las dificultades que se presentan.
• #12:      El Scrum Team, o Equipo Scrum , se encarga de desarrollar las tareas de la Lista de Tareas del Sprint.     Aunque es natural que haya especialistas en cierto campo dentro del equipo, no hay jererquías, y la atención de las tareas se decide entre todos.     La propiedad del código es colectiva; cualquier miembro del equipo puede modificar cualquier parte del código, sobrentendiéndose que trabajan coordinadamente.     La responsabilidad es compartida; todo el equipo es responsable de las tareas del sprint.
• #13: Estos roles producen ciertos documentos.
• #15: El Product Backlog, o Lista de Pendientes del Producto, es producida y administrada por el Propietario del Producto.     Enumera las funcionalidades deseadas. Esta lista está en continua evolución.     El tiempo deseado para la implementación de alguna funcionalidad se expresa en días o semanas. No requiere ser muy preciso.     Tampoco requiere ser completo, pues sólo se puede atender un número limitado de funcionalidades en cada sprint.
• #16: El Sprint Backlog, o lista de Tareas del Sprint , es producido por la Reunión de Planificación del Sprint y administrado por el equipo de desarrollo.     Detalla las tareas requeridas para implementar un conjunto de funcionalidades tomadas de una versión fechada de una lista de Pendientes del Producto.     La duración de las tareas se expresa en horas.     Cada tarea puede durar un máximo de 16 horas. Si alguna requiriera más tiempo, es señal de que hay que subdividirla en otras tareas de menor duración.
• #18: La atención de las Tareas del Sprint y su posterior presentación, determina un ciclo llamado Sprint, dentro del cual hay un ciclo diario llamado Scrum.
• #19:     Un script es un ciclo en el cual el equipo de desarrollo realiza las tareas anotadas en la Lista de Tareas del Sprint.     Dura entre 2 a 4 semanas, que es el tiempo recomendado en la práctica.     Como cada sprint tiene asociado un conjunto de reuniones al inicio y al final, si el sprint durara muy poco, el tiempo usado para reuniones y presentaciones en lugar de para desarrollar sería significativo.         Y como al final de cada sprint se hacen ajustes en el rumbo, si éste durara mucho, las desviaciones podrían ser mayores que si el sprint fuera mas corto.     El nombre ha sido tomado del juego rugby, donde un sprint es una carrera hacia un punto que acerca al equipo un poco más hacia la meta.
• #20:      Un día de trabajo en el sprint.     El nombre ha sido tomado también del juego de rugby, donde en un scrum el equipo colabora hombro a hombro para realizar un sprint.
• #22: Las reuniones son para producir los documentos que se necesitan para trabajar en el script, para presentar los avances y para mejorar la experiencia de desarrollo.
• #23: Descripción Reunión de Planificación del Sprint Cuándo Antes de iniciar el sprint y después de la Reunión Retrospectiva del spring anterior. Lugar Ambiente de trabajo del Scrum Team Participan Propietario del Producto Lider del Scrum Equipo Scrum Duración Hasta 8 horas Requiere Lista de Pendientes del Producto Produce Lista de Tareas del Sprint Fecha de la Reunión de Revisión del Sprint
• #24: Descripción Reunión diaria del Equipo Scrum Cuándo Misma hora cada día. Puede ser al final del día. Lugar Mismo lugar cada día. El ambiente de trabajo del Scrum Team. Participan Lider del Scrum Equipo Scrum Pueden asistir personas de fuera, pero no tienen voz. Duración Entre 15 y 20 minutos Produce Informe oral de avances e inconvenientes. Cada miembro del equipo responde a 3 preguntas: ¿Qué hice desde el anterior scrum? ¿Qué haré para el siguiente scrum? ¿Que dificultades tengo?
• #25: Descripción Reunión de Revisión del Sprint Cuándo En la fecha definida por la Reunión de Planificación del Sprint Lugar Puede ser en el ambiente de trabajo del Scrum Team Participan Propietario del Producto Lider del Scrum Equipo Scrum Pueden asistir otros representantes del cliente, el cliente, usuarios, etc. Idealmente la participación se hace a través del Propietario del Producto y el Lider del Scrum. Duración Hasta 4 horas Produce Informe de qué funcionalidades se han implementado en el sprint y cuáles no. Demostración de las funcionalidades completadas en el sprint. No se muestra lo que no está completo.
• #26: Descripción Reunión Retrospectiva del Sprint . Se vuelve el paso inicial para el siguiente sprint. Cuándo Al final del sprint Lugar El ambiente de trabajo del Scrum Team Participan Lider del Scrum Equipo Scrum Duración Hasta 3 horas Produce Se responden 2 preguntas: ¿Qué estuvo bien en el sprint? ¿Qué se podría mejorar en el siguiente sprint?
• #29: Propuesta de nombres traducidos al español.
• #30: Flujo de trabajo en Scrum.
• #52: En el sprint podemos distinguir un ciclo de avance.
• #53: El ciclo de aprendizaje, que sirve para mejorar la experiencia del equipo de desarrollo.
• #54: El día a día del Scrum.