Scrum. Espíritu Ágil

Transcripción

1 Scrum Espíritu Ágil

2 Metodología en Cascada Excellence in software development

3 Metodología en Cascada Análisis Diseño Implementación Verificación Mantenimiento

4 Metodología en Cascada > El modelo en cascada es un proceso de desarrollo secuencial, donde el desarrollo de software se concibe como un conjunto de etapas que se ejecutan una tras otra. > La etapa siguiente empieza cuando termina la etapa anterior. > Se le denomina así por las posiciones que ocupan las diferentes fases que componen el proyecto, colocadas una encima de otra, y siguiendo un flujo de ejecución de arriba hacia abajo, como una cascada. > El énfasis es llevar a cabo una planificación detallada del proyecto por adelantado. > La documentación es muy exhaustiva y si se une al equipo un nuevo desarrollador, podrá comprender el proyecto leyendo la documentación. > Por lo general, el cliente no revisa el producto hasta casi el final del proyecto. > Ideal para proyectos estables, donde los requisitos son claros y no van a cambiar a lo largo del proceso de desarrollo.

5 Problemas de la Metodología en Cascada > En muchas ocasiones, los clientes no tienen bien en claro los requisitos antes de ver una primera versión del software en funcionamiento. Entonces, cambiarán parte de ellos y añadirán otros nuevos, lo que supondrá volver a realizar fases ya superadas y provocará un incremento del costo. > No se va mostrando al cliente el producto a medida que se va desarrollando, si no que se ve el resultado una vez ha terminado todo el proceso. Esto provoca inseguridad por parte del cliente que quiere ir viendo los avances. > Además, malinterpretaciones por parte del equipo de desarrollo serían atrapadas muy tarde en el proceso. > Los desarrolladores pueden no tener en cuenta todas las dificultades que se encontrarán cuando estén codificando un software, lo que conlleva a rediseñar la solución para solventar el problema. > Los cambios a los requerimientos surgidos luego de la etapa de diseño son muy difícil de absorber. > Se aplica mejor a proyectos de corto plazo donde los requerimientos son detallados y no cambiarán en el tiempo.

6 Qué es Scrum? Excellence in software development

7 SCRUM - Qué es? > Scrum es un framework (marco de trabajo) para la gestión ágil de proyectos que puede ser aplicado tanto en software como en cualquier otra industria. > Busca siempre una forma de maximizar la ganancia sobre la inversión de trabajo (ROI). > Se define según > Los principios en que SCRUM se fundamenta > Los aspectos que se consideran importantes observar en todo proyecto > Los procesos que SCRUM tiene

8 Principios Excellence in software development

9 SCRUM - Principios >Pautas Básicas que se aplican obligatoriamente en el marco de SCRUM: >Son seis principios: 1. Control de proceso empírico 2. Auto-organización 3. Colaboración 4. Priorización basada en el valor 5. Asignación de un bloque de tiempo 6. Desarrollo Iterativo

10 SCRUM - Principios > Control: Un proyecto debe ser controlado, Scrum propone el control del proyecto en tres pilares. > Transparencia de Información. > Inspección del Proyecto. > Aceptación del Cambio. > Auto Organización: Es asumir la responsabilidad de que el proyecto llegue a un estado de éxito depende de todos lo miembros del equipo.

11 SCRUM - Principios Colaboración: Si se comparte la información y los equipos se organizan por sí mismos, otro valor que decanta en esta filosofía es el la colaboración. Colaboramos con el objetivo de mitigar los riesgos, de anular los impedimentos, de incorporar las solicitudes de cambio, de lograr el objetivo común. Time-Boxing: Scrum plantea que el tiempo es valioso. Propone una cantidad limitada de tiempo para cada proceso y actividad en un proyecto Scrum. Daily Meeting: 15 minutos Sprint : 1 a 6 semanas Retrospective: 4 horas Planning: 8 horas

12 SCRUM - Principios Priorización Basada en Valor: Terminar primero lo que más valor agregado genera al negocio. La priorización se lleva a cabo por el Product Owner sobre las User Stories del Product Backlog.. El Product Owner tiene que interpretar la entradas y las necesidades del proyecto de los stakeholders para crear los Product Backlog Items basados en en tres factores. Valor, Riesgo y Dependencia Desarrollo Iterativo: Busca mejorar el manejo de los cambios y crear productos que satisfagan las necesidades del cliente. No todos los clientes saben que requerimientos quieren. Entregables periódicos, ayudan al cliente a aclarar el nivel de incertidumbre en la definición de sus requerimientos

13 Aspectos Excellence in software development

14 SCRUM -Aspectos Los aspectos son las enfoques desde donde se analiza la gestión de un proyecto. Ellos son: Justificación de negocio: Scrum justifica el proyecto a través del valor que genera y facilita las entregas anticipadas de valor. Value Driven Delivery Organización: Entender los roles y responsabilidades Calidad: La calidad en SCRUM se define como la capacidad del producto o los entregables de cumplir con los criterios de aceptación y de alcanzar el valor de negocio que el cliente espera. Cambio: Es clave entender que SCRUM está diseñado para aceptar el cambio. A veces los stakeholders cambian de opinión sobre los requisitos que quieren, y a veces es difícil definirlos al inicio del proyecto. Riesgo: Los riesgos pueden ser positivos(oportunidades) o negativos(amenazas). Se los evalúa durante todo el proyecto a través de dos factores, probabilidad de ocurrencia e impacto en caso de suceder.

15 SCRUM- Aspectos -Roles 1. Organización a. Roles Centrales: Las personas a quienes se les asignan los roles centrales están plenamente comprometidas con el proyecto y son las responsables del éxito de cada iteración y del proyecto mismo. i. Product Owner: Es la persona responsable de lograr el máximo valor empresarial para el proyecto. Es responsable de la articulación con el cliente y de mantener la justificación de negocio. Representa la voz del cliente. ii. Scrum Master: Facilitador que asegura que el equipo Scrum esté dotado de un ambiente propicio para completar el proyecto con éxito.elimina los impedimentos y es el responsable que las prácticas SCRUM se realicen, iii. Scrum Team: El equipo de personas responsables de la comprensión de los requisitos especificados por el Product Owner y de la creación de los entregables del proyecto. b. Roles No Centrales:Son roles no necesarios para el día a día del proyecto. i. Stakeholders: Es un término colectivo que incluye al cliente, usuarios y patrocinadores que con frecuencia interactúan con el equipo principal de Scrum, e influyen en su desarrollo.

16 SCRUM - Framework - ROLES

17 Procesos Excellence in software development

18 SCRUM - Procesos - Inicio > Inicio > Creación de la declaración de la visión del proyecto: > Se revisa el caso de negocio del proyecto a fin de crear una declaración de la visión del proyecto > Se identifica al Product Owner > Identificación del Scrum Master y Stakeholders > Formación del equipo Scrum > El Product Owner, se encarga de seleccionar al equipo, con ayuda del Scrum Master. > Desarrollo de las User Stories de alto nivel, -Casos de Uso- > Se arman reuniones de Stakeholders para discutir si las User Stories de Alto Nivel son adecuadas. > La declaración de la visión del proyecto sirve como dato de entrada. > Se establece los Criterios de Terminado. > Se priorizan las User Stories de Alto Nivel > Realizar la planificación de lanzamiento > El Scrum Team revisa las User Stories de Alto Nivel ya priorizadas para desarrollar un cronograma de planificación del lanzamiento (cronograma por fases) > Se determina la duración del Sprint

19 SCRUM - Procesos - Inicio -Priorización MoSCoW Esquema de priorización MoSCoW El esquema de priorización MoSCoW obtiene su nombre de la versión en inglés de las frases: Debe tener (Must have), Debería tener (Should have), Podría tener (Could have) y No tendrá (Won t have).

20 SCRUM - Procesos - Planificación > Planificación y Estimación > Creación de User Stories y del Product Backlog > Se crean las User Stories y sus criterios de aceptación. > Son escritas por el Product Owner > Son diseñadas para asegurar que los requisitos del cliente estén representados > Los requisitos deben ser comprendidos por todos los Stakeholders. > Una vez creada, se incorpora al Product Backlog > Aprobación, Estimación, y Asignación de User Stories > El Product Owner valida las User Stories para un sprint > El Scrum Master y el Scrum Team estiman el esfuerzo necesario para desarrollar la funcionalidad descrita en cada User Story > El Scrum Team se compromete a entregar los requisitos al cliente en forma de User Stories, estimadas, aprobadas y asignadas

21 SCRUM - Planificación - Planning Poker > En el Planning Poker a cada miembro del equipo se le asigna una baraja. > Cada carta está enumerada en forma secuencial > Los números representan la complejidad del problema en términos de tiempo o esfuerzo. > El Product Owner elige una User Story del Product Backlog y se la presenta al equipo para que la analize > Cada miembro elige una carta de la baraja que represente su estimación para la User Story. > Si la mayoría, seleccionan la misma carta, o similar, se calcula el promedio. > Si no, entonces se discuten las razones de la selección y se vuelve a estimar.

22 SCRUM -Procesos - Planificación > Planificación y estimación > Creación de Tareas > Las User Stories se dividen en Tasks específicas > Se compilan en una Task List que depende de la User Story > El Scrum Team estima las Tasks > Creación de Sprint Backlog durante la Planning Meeting

23 SCRUM - Procesos - Implementación > Implementación > Creación de entregables: > El equipo scrum trabaja en el PBI para crear los entregables > Se utiliza un Scrum Board para el seguimiento de trabajo > Se mantiene un listado de impedimentos > Llevar a cabo la reunión diaria: > Consiste en una reunión de 15 minutos, se habla qué se hizo, qué se está haciendo, qué impedimentos hay. > Mantenimiento de la Product Backlog > Se actualiza y se mantiene el Product Backlog. Todo el equipo se encarga de esta tarea.

24 SCRUM - Procesos - Demo y Retrospectiva > Demo y Retrospectiva del Sprint > Demo > El Scrum Team muestra su trabajo a los Stakeholders y al Product Owner > El fin de la reunión es la aprobación del Product Owner y aceptación del entregable. > Retrospectiva: Se discute lo que se hizo bien, lo que se hizo mal, y lo que se puede cambiar. Esto genera un documento y sirve de experiencia para los próximos Sprints. > Lanzamiento > Envío de Entregables: Se entregan aquellos ítems que fueron aceptados. Y se firma un acuerdo formal de que el proyecto terminó con éxito. > Retrospectiva del proyecto:se juntan todos los participantes para charlar sobre qué se puede mejorar en futuros proyectos.

25 SCRUM - Framework - PROCESOS

26 Que es?

27 ARGENTINA Clay 2954 Buenos Aires (C1426DLD) tel: BRASIL Cardoso de Melo , Vila Olimpia San Pablo ( ) tel: URUGUAY Roque Graseras 857 Montevideo (11300) tel: USA Sundance Ct. Reston (20194) tel: