¡Descarga Scrum: Metodología Ágil para el Desarrollo de Proyectos de Software y más Apuntes en PDF de Ingeniería solo en Docsity!
Exposición SCRUM
1. ¿Qué es SCRUM? “SCRUM es una metodología ágil utilizada en el desarrollo de proyectos de software y que permite obtener el mejor resultado posible en la gestión de un proyecto” Scrum es el nombre con el que se denomina a los marcos de desarrollo ágiles. Es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo y obtener el mejor resultado posible de proyectos. En Scrum no se realiza una entrega final del proyecto, sino que se van haciendo de forma regular entregas parciales, de forma que esto es lo que más beneficia al receptor del proyecto. Por ello, Scrum está especialmente indicado para entornos complejos, donde los cambios se producen con mucha frecuencia y sobre la marcha y donde la rapidez, la flexibilidad, la adaptabilidad y la competencia juegan un papel fundamental. 2. Características de Scrum. Gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por último, equipo motivado. Se hace uso de equipos autodirigidos y autoorganizados. Se realiza a diario una reunión de Scrum, que es una reunión de avance diaria que no dura más de 15 minutos con el objetivo de obtener realimentación sobre las tareas del equipo y los obstáculos que se presentan. Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles. Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software ; requiere muy poco esfuerzo para comenzarse a utilizar. Así, si se utiliza una pizarra con notas autoadhesivas cualquier miembro del equipo podrá ver tres
columnas: trabajo pendiente ("backlog"), tareas en proceso ("in progress") y hecho ("done"). De un solo vistazo, una persona puede ver en qué están trabajando los demás en un momento determinado.
3. Características de Scrum La metodología se basa en: El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos. Se da prioridad a lo que tiene más valor para el cliente. El equipo se sincroniza diariamente y se realizan las adaptaciones necesarias. Tras cada iteración (un mes o menos entre cada una) se muestra al cliente el resultado real obtenido, para que este tome las decisiones necesarias en relación a lo observado. Se le da la autoridad necesaria al equipo para poder cumplir los requisitos. Fijar tiempos máximos para lograr objetivos. Equipos pequeños (de 5 a 9 personas cada uno). 4. Factores Clave en SCRUM
- Planteamiento: un proyecto gestionado bajo el modelo SCRUM parte de los objetivos que han trazado con anterioridad el cliente y la empresa. Lo primero es fraccionarlo en entregas parciales, de manera que el cliente pueda replantear aspectos a los que en principio no prestó la importancia debida o que simplemente desconocía. Esos aspectos pueden ser sobre costes, estrategias, producción, etc.
- Lista de tareas: el equipo de trabajo elabora la lista de tareas que debe tener en cuenta para cada entrega de resultados. Es muy importante hacer una estimación del esfuerzo requerido para, de esta manera, fijas plazos proporcionados.
- Reuniones: lo ideal es que cada día el equipo dedique 15 minutos para reunirse y ponerse al tanto de la evolución del plan. En estas sesiones, el líder del proyecto (Scrum Master) debe encargarse de que cada miembro cumpla con las labores que le han sido asignadas y de motivarles para que su productividad no descienda. En caso de que detecte alguna incidencia dentro del grupo, es necesario que tome las
Scrum diario También llamado Daily Standup. Cada día durante la iteración, tiene lugar una reunión de estado del proyecto. Su objetivo es que los miembros del equipo se mantengan actualizados unos a otros sobre el trabajo de cada uno desde el ultimo standup, qué problemas han encontrado o preveen encontrar, y qué planean hacer. La reunión tiene una duración fija de entre 5 y 15 minutos. Se recomienda hacerla de pie para recordar que debe ser una reunión breve y centrada en su objetivo, sin divagaciones. Es obligatorio parar todo lo que se está haciendo para concentrarse en la reunión. Si se requiere ampliar un tema, se hará tras el Daily Standup, pero no se interrumpe la dinámica del Standup para elaborar una discusión. Se hace siempre a la misma hora y en el mismo lugar. Si falta alguien, no se pospone la reunión. Revisión de sprint Al final de un sprint, el equipo realiza dos eventos: la revisión del sprint y la retrospectiva del sprint. En la reunión de revisión de sprint se presentan los trabajos completados y su duración no debería ser superior a 4 horas para un Sprint de 1 mes. Retrospectiva del sprint Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.
6. Roles en SCRUM En Scrum tenemos dos categorías de roles: Roles centrales Los roles centrales son aquellos que su participación es indispensable para la realización del proyecto, están comprometidos con el proyecto y son responsables del éxito de cada sprint y del proyecto en general. Estos son:
Product owner Scrum master Equipo Scrum Roles no centrales Los roles no centrales son aquellos cuya participación en el proyecto es importante pero no depende de ellos el éxito o fracaso del proyecto, es importante siempre identificar los individuos de esta categoría y mantenerlos siempre presentes, en cualquier momento su rol puede ser decisivo para el proyecto (por ejemplo, si es un sponsor ). Estos son: Stakeholders o Cliente o Usuarios o Patrocinador (sponsor) Vendedores Scrum Guidance Body En la siguiente gráfica vemos una descripción general y cómo se relacionan los roles centrales del Equipo Scrum. Product Owner El Product Owner se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner ayuda al usuario a escribir las historias de usuario, las prioriza, y las coloca en el Product Backlog. ScrumMaster (o Facilitador) El Scrum es facilitado por un ScrumMaster , cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan. Equipo de desarrollo El equipo tiene la responsabilidad de entregar el producto. Es recomendable un pequeño equipo de 3 a 9 personas con las
proporcionado por el hecho de que pueden estructurarse de manera autónoma. Maximiza el retorno de la inversión (ROI). Creación de software solamente con las prestaciones que contribuyen a un mayor valor de negocio gracias a la priorización por retorno de inversión. Predicciones de tiempos. A través de este marco de trabajo se conoce la velocidad media del equipo por sprint, con lo que es posible estimar de manera fácil cuando se podrá hacer uso de una determinada funcionalidad que todavía está en el Backlog. Reducción de riesgos El hecho de desarrollar, en primer lugar, las funcionalidades de mayor valor y de saber la velocidad a la que el equipo avanza en el proyecto, permite despejar riesgos efectivamente de manera anticipada.
8. Documentos. Product backlog El product backlog se trata como un documento de alto nivel para todo el proyecto. Es el conjunto de todos los requisitos de proyecto, el cual contiene descripciones genéricas de funcionalidades deseables, priorizadas según su retorno sobre la inversión (ROI). Representa el qué va a ser construido en su totalidad. Es abierto y solo puede ser modificado por el product owner. Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal (KEV) y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menor tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto. Sprint backlog El sprint backlog es el subconjunto de requisitos que serán desarrollados durante el siguiente sprint. Al definir el sprint backlog, se describe el cómo el equipo va a implementar los requisitos durante el sprint. Por lo general los requisitos se subdividen en tareas, a las cuales se asignan ciertas horas de trabajo, pero ninguna tarea con una duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca adecuado.
Burn down chart La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.
