metodologías Ágiles - scrum
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 PresentationTRANSCRIPT
-
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