Metodologías Ágiles - Scrum

download Metodologías Ágiles - Scrum

If you can't read please download the document

description

Metodologías Ágiles - Scrum. Julian Caruso Andrea Gauna Emilio Watemberg. Gestión Clásica de proyectos. La gestión de proyectos predictiva o clásica es una disciplina formal de gestión, basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles . - PowerPoint PPT Presentation

Transcript of Metodologías Ágiles - Scrum

  • Metodologas giles - ScrumJulian CarusoAndrea GaunaEmilio Watemberg

    Julian Caruso Andrea Gauna Emilio Watemberg

    Gestin Clsica de proyectosLa gestin de proyectos predictiva o clsica es una disciplina formal de gestin, basada en la planificacin, ejecucin y seguimiento a travs de procesos sistemticos y repetibles.

    Criterios de xito: obtener el producto definido, en el tiempo previsto y con el coste estimado.

    Asume que el proyecto se desarrolla en un entorno estable y predecible.

    El objetivo de su esfuerzo es mantener el cronograma, el presupuesto y los recursos.

    Divide el desarrollo en fases a las que considera ciclo de vida, con una secuencia de tipo: concepto, requisitos, diseo, planificacin, desarrollo, cierre.

    Divisin del trabajo en equipos de especialistas.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Manifiesto gilAunque hay valor en los elementos en la derecha, valoramos ms los elementos en la izquierda.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Objetivos de la gestin gil1. ValorInnovacin Flexibilidad 2. Reduccin del tiempo de salida al mercado Solapamiento de las fases de desarrollo. Entrega temprana de las primeras partes del producto, que corresponden con las de mayor urgencia para el cliente.3. Agilidad Capacidad para producir partes completas del producto en periodos breves de tiempo 4. Flexibilidad Capacidad para adaptar la forma y el curso del desarrollo a las caractersticas del proyecto, y a la evolucin de los requisitos. 5. Resultados confiablesLa gestin gil no tiene un carcter predictivo o de anticipacin. No conoce de antemano el detalle del producto que va a desarrollar, y por eso su objetivo no es fiabilidad en el cumplimiento de los planes, sino en el valor del resultado.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Gestin Clsica vs. gil

    Julian Caruso Andrea Gauna Emilio Watemberg

    Metodologas giles

    ADT - Agile Database Techniques AM - Agile Modeling ASD - Adaptive Software Development AUP - Agile Unified Process Crystal FDD - Feature Driven Development DSDM - Dynamic Systems Development Method Lean Software Development Scrum TDD - Test-Driven Design XBreed XP - Extreme Programming

    Scrum

    Julian Caruso Andrea Gauna Emilio Watemberg

    Donde Usar ScrumProyecto simpleScrumProyecto complejo

    Julian Caruso Andrea Gauna Emilio Watemberg

    ScrumScrum, basado en la teora de control emprico de procesos, emplea un acercamiento iterativo e incremental para optimizar la predictibilidad y el control de riesgos. El control de procesos emprico se basa en 3 pilares:

    TransparenciaAsegura que todos los aspectos que afectan los resultados de un proceso deben ser visibles a todos los involucrados. InspeccinLos diferentes aspectos del proceso deben ser inspeccionados frecuentemente de manera de poder detectar variaciones inaceptables. AdaptacinSi el inspector determina que alguno de los aspectos analizados esta fuera de los limites aceptables, y esto resultara en un producto inaceptable, debe ajustar el proceso o el material siendo procesado. Este ajuste debe ser realizado rpidamente para evitar que aumente la desviacin.

    Scrum provee 3 puntos de inspeccin y adaptacin clave durante las iteraciones (Sprint). El scrum diario, planeacin de Sprint y retrospectiva del sprint.

    Julian Caruso Andrea Gauna Emilio Watemberg

    El flujo

    Julian Caruso Andrea Gauna Emilio Watemberg

    Componentes de Scrum

    El Equipo

    Reuniones

    Artefactos

    ReglasRoles

    Julian Caruso Andrea Gauna Emilio Watemberg

    RolesLos equipos se componen de 3 roles principales

    El ScrumMaster (SM)Responsable de que el proceso sea comprendido y ejecutado correctamente

    El Dueo del Producto (PO - Product Owner) Responsable de maximizar el valor del trabajo realizado por el equipo.

    El Equipo Realizan el trabajo. El equipo consiste en desarrolladores con todas las habilidades necesarias para convertir los requerimientos del PO en un producto entregable para el final de la Sprint.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Roles Scrum Master

    Facilitador y lder del equipo

    Remueve impedimentos del equipo

    Promueve valores, principios y prcticas scrum

    Solo uno por equipo

    Trabaja junto con el equipo

    Responsable del producto

    El SM puede ser un miembro del equipo de desarrollo, aunque no se recomienda por los requerimientos full-time de ambos roles. El SM NUNCA debera ser el PO.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Roles Product Owner

    Representante del cliente y stakeholders (involucradosointeresados)Tiene autoridad para cambiar y/o definir el productoAcepta o rechaza el resultado del sprintSolo uno por equipoTrabaja junto con el equipoPropietario de la lista de requerimientosPrioriza los requerimientosResponsable de la rentabilidad del producto

    El PO puede ser un miembro del equipo de desarrollo, aunque esto no se recomienda ya que esta responsabilidad adicional reducira su capacidad de trabajar con los stakeholders. El PO NUNCA debera ser el SM.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Roles Equipo de desarrolloPocos integrantes (7 +/- 2)

    Multifuncional e interdisciplinario

    Roles difusos

    Trabajan a tiempo completo en un sprint

    Auto-organizado y auto-disciplinado

    Definen y estiman tareas de cada requerimiento

    Propietario de la lista de tareas

    Comprometido y descentralizado

    Julian Caruso Andrea Gauna Emilio Watemberg

    Componentes de Scrum

    Roles

    Time-Boxes

    Artefactos

    ReglasReuniones

    Julian Caruso Andrea Gauna Emilio Watemberg

    Reuniones Sprint PlanningLista de requerimientos priorizadosEl equipo determina los requerimientos del sprintEl equipo define y estima las tareas de cada requerimientoPrimera actividad de un sprintLa duracin depende de la duracin del sprint (mx 8 hs)Se genera el sprint backlog y el objetivo del sprint

    Julian Caruso Andrea Gauna Emilio Watemberg

    Reuniones Sprint ReviewDuracin mx: 2 a 4 hs

    Demo del producto

    Finalidad: presentar al product owner las nuevas funcionalidades

    Participan todos: Scrum master, Product owner y Equipo

    Las funcionalidades no implementadas no se presentan

    Se genera feedback del producto

    Julian Caruso Andrea Gauna Emilio Watemberg

    Reuniones Sprint Retrospective

    Reflexin sobre sprint se responde a:Qu fue lo bueno y malo del sprint? Qu cosas se pueden mejorar?

    Siempre al finalizar el sprint

    Participan todos: Scrum master, Product Owner y Team

    Se genera feedback

    Duracin mxima: 1 hora

    Julian Caruso Andrea Gauna Emilio Watemberg

    Reuniones Daily Scrum MeetingDuracin: 15 minutos

    Scrum master es el responsable

    Scrum master y equipo

    Tres preguntas: Qu hice desde la ltima reunin diaria? Qu voy a hacer hasta la prxima reunin? Qu dificultades tengo para realizar mi labor?

    No se resuelven problemas, solo se identifican

    Misma hora y lugar (recomendado)

    Primera actividad del da (recomendado)

    Julian Caruso Andrea Gauna Emilio Watemberg

    Componentes de Scrum

    Roles

    Reuniones

    Artefactos

    ReglasArtefactos

    Julian Caruso Andrea Gauna Emilio Watemberg

    Artefactos Elementos bsicosUna lista con las funcionalidades de la aplicacin ordenadas de mayor a menor importancia. Esta lista se llama "Product Backlog". No hace falta que esta lista contenga todas las funcionalidades inicialmente.

    De la lista anterior, se toman las primeras funcionalidades, se descomponen en tareas y son anotadas en una lista que se llama "Sprint Backlog". Estas tareas sern realizadas en el siguiente mes.

    La Burn Down Chat es una grfica mostrada pblicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una lnea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta lnea sea descendente (en casos en que todo va bien en el sentido de que los requisitos estn bien definidos desde el principio y no varan nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay ms requisitos pendientes de ser completados en el Backlog). Si durante el proceso se aaden 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.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Artefactos - BacklogsProduct BacklogEs un documento de alto nivel para todo el proyecto. Contiene descripciones genricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas segn su valor para el negocio (business value). Es el qu va a ser construido. Es abierto y cualquiera puede modificarlo.El Product Owner es responsable de mantener este documento(contenido, disponibilidad, priorizacin).Nunca esta completo, evoluciona junto con el producto y su ambiente.Las tareas con prioridad mas alta contienen mas informacin, este nivel de detalle disminuye a medida que descendemos por el informe.Sprint Backlog Es un documento detallado donde se describe el cmo el equipo va a implementar los requisitos durante el siguiente sprint. Se desarrolla principalmente en la Sprint Planning. Aunque se puede modificar durante el Sprint(perodo de la iteracin).Las tareas se dividen en horas con ninguna tarea de duracin superior a 16 horas. Si una tarea es mayor de 16 horas, deber ser rota en mayor detalle.A medida que se trabaja en una tarea, el tiempo estimado para finalizarla se actualiza. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.El Sprint Backlog debe ser un radiador de informacin, altamente visible y actualizado , de ser posible, en tiempo real.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Artefactos Burn-Down ChartsProduct Burn Down

    Registra la suma de trabajo restante en el Product Backlog.La unidad de medicin puede ser cualquiera que haya sido acordada por el equipo. En caso de que se requiera agregar o quitar trabajo al Backlog durante el desarrollo se puede mover el piso del grfico para mantener la referencia. Estos cambios deben ser religiosamente documentados. La tendencia puede ser irregular durante las primeras iteraciones. Esta irregularidad disminuye si los miembros del equipo han trabajado juntos antes, conocen el producto ,dominio y la tecnologa a utilizar en el mismo.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Artefactos Burn-Down Charts (2)Sprint Backlog Burndown

    Es un grafico del trabajo restante a lo largo del tiempo restante del Sprint.Se crea sumando cada da el trabajo restante de todos los tems del Sprint Backlog.No se considera el trabajo invertido en una tarea. El trabajo restante y las fechas son las nicas variables de inters. Siempre que sea posible el grafico debe estar a la vista del equipo.

    Julian Caruso Andrea Gauna Emilio Watemberg

    Componentes de Scrum

    Roles

    Reuniones

    Artefactos

    ReglasReglas

    Julian Caruso Andrea Gauna Emilio Watemberg

    Reglas Una vez que se pasan las tareas ms prioritarias del "Product Backlog" al "Sprint Backlog", estas no se pueden cambiar, esto quiere decir, que el trabajo de un mes queda fijado. Esta es la regla ms importante de todas.

    Al final del mes, este periodo se le llama "Sprint", se tiene que tener un ejecutable con las funcionalidades del "Sprint Backlog". Es importante acordar y mantener un criterio de completo a lo largo del desarrollo.

    Este criterio denominado Done, es a lo que el equipo se compromete cuando decide hacer una tarea.Anlisis/ DiseoRefractoringProgramacinI18NDocumentacinTesting funcional (Unit , UAT , Regresin)Testing no funcional (Performance, Estabilidad , seguridad , integracin )

    Julian Caruso Andrea Gauna Emilio Watemberg

    ResumenScrum es un proceso gil que nos permite centrarnos en ofrecer el ms alto valor de negocio en el menor tiempo.Nos permite rpidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes).

    El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de ms alta prioridad.

    Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorndolo en otro sprint.

    Julian Caruso Andrea Gauna Emilio Watemberg

    ReferenciasScrum Alliance http://www.scrumalliance.org/

    Agile Alliancehttp://www.agilealliance.org/

    Comunidad Latinoamericana de metodologas gileshttp://www.agiles.org/

    Recursoshttp://www.agile-software-development.comhttp://www.scrumalliance.org/resources/598http://jeffsutherland.com/scrum/

    Julian Caruso Andrea Gauna Emilio Watemberg