Scrum y la realidad del software en Chile

Slides:



Advertisements
Presentaciones similares
SISTEMAS II CICLO DE VIDA.
Advertisements

¿De qué vamos a hablar hoy? Estrategia ágil vs. estrategia tradicional Scrum: ciclo de proyecto, roles Planificación ágil Seguimiento de un proyecto.
Scrum Juan Palacio Bañeres.
Administrado y desarrollado utilizando Scrum
Proyecto Call Center Taller de desarrollo de proyectos II
Scrum Master: Gabriel Bongianino
Sprint Review Sprint Review 17/09/2012 Release N° 1 End of Sprint N° 3 Scrum Master: Denise Giusto Team: Romina Paganessi, Gabriel Bongianino, Hugo Damian.
CICLO DE VIDA DEL DESARROLLO DE SOFTWARE
Desarrollo de software innovador con métodos ágiles
Área 1 Metodología de implantación de un nuevo modelo horario laboral Área 1: Diagnóstico de situación de partida 1.2. Plantilla completa de análisis.
SISTEMAS II CICLO DE VIDA.
SYSMOTORFLOW PRESENTACIÓN DEL PROCESO Proyecto de Ingeniería de Software 2010.
Taller de Desarrollo de Proyectos II (75.47) Presentación Inicial ERNESTO GIMENO PABLO BESADA SANTIAGO PETERSEN PATRICIO FAGALDE
Metodología de Trabajo Aperio: SCRUM Aperio Inducción
Agile Game Design Alejandro Luna. Sabarasa Inc. 10 y 11 de Diciembre – Hotel Panamericano - Buenos Aires.
METODOLOGÍA PARA IMPLANTAR UN SISTEMA INTEGRADO DE INFORMACIÓN
PPQA.
Proceso de Originación de Crédito: Banco de los Alpes
Proyecto de Ingeniería de Software 2008
Aseguramiento Calidad
Reunión de los requerimientos de la red
Evaluación de Productos
Introducción a la gestión
Formulación de Proyectos de Titulación
MINISTERIO DE ECONOMÍA Y FINANZAS DIRECCION NACIONAL DE CONTABILIDAD
Objetivo. Dado que ya tenemos la planificación temporal del proyecto, que responde a: ¿Qué se hará?, ¿Quién lo hará?, y ¿Cuándo lo hará? ¿Qué recursos.
Un conjunto de herramientas para integrar la sostenibilidad en las empresas navarras.
SEMINARIO NAIC/ASSAL/SVS REGULACIÓN & SUPERVISIÓN DE CONDUCTA DE MERCADO © 2014 National Association of Insurance Commissioners Conducta de Mercado Normas.
Capítulo 3 Etapas de un Proyecto de simulación
PROCESO O REUNIONES EN SCRUM BENEFICIOS DE UTILIZAR SCRUM
Determinar a que se le va a hacer Benchmarking
ITERASOFT. OBJETIVOS DEL GRUPO Producir un sistema Manejador de Itinerarios de alta calidad y confiabilidad Realizar un proyecto bien administrado y productivo.
Luis Fernando Hevia Rodríguez
Ciclos de vida ágiles.  Es una metodología ágil que plantea: ◦ Iteraciones cortas ◦ Entregables periódicos ◦ Colaboración con el cliente full time ◦
PROCESO DE DESARROLLO. Introducción Mediante esta presentación se pretende describir el proceso de desarrollo del TALLER I.
TEAM SOFTWARE PROCESS CICLO 3.  Análisis del Proyecto  Producto  Resultados por Rol  Resultado del Proceso.
Requerimientos /Metas:
Fundamentos de la Gerencia de Proyectos
Scrum Images goes here …y prácticas ágiles para desarrollo de software.
Entornos de Desarrollo
EDUAR 2.0 Sistema de Explotación de Información Educativa 10/05/2011.
Eugenia Parodi Eugenia Parodi Lazaro Ruiz Lazaro Ruiz Juan Achucarro Juan Achucarro Sebastian Castellanos Sebastian Castellanos.
Proceso de Gestión de Proyectos
¿Cómo nos ayuda GeneXus a mejorar la calidad en el proceso de desarrollo de Software? Ing. Rosario Estévez Ing. Rafael Mon
EL APORTE DE LA INGENIERIA DE SOFTWARE A LAS ORGANIZACIONES
Ximena Romano – Doris Correa
Un conjunto de herramientas para integrar la sostenibilidad en las empresas navarras.
Estudio de Viabilidad del Sistema (EVS)
Ingeniería de Software
UNIVERSITARIO: DAVID MAMANI EL ALTO – LA PAZ – BOLIVIA 2009 CARRERA: ING. DE SISTEMAS MATERIA: INGENIERIA DE SOFTWARE.
Un conjunto de herramientas para integrar la sostenibilidad en las empresas navarras.
Gestión Ágil de Proyectos Colaborador: Anónimo
Scrum Una Alternativa Ágil para el desarrollo de Software
Conceptos sobre GESTIÓN DE PROYECTOS
Introducción al proceso de verificación y validación.
Especialidad en Administración de Proyectos
DESARROLLO E INTEGRACIÓN DE APLICACIONES MÓVILES Manual de Usuario JIRA – Servicios 20/11/2013.
Proyecto: Lanzamiento QUICK ORDER. Objetivo General  Desarrollar el sistema de información de acuerdo a los requerimientos establecidos por el cliente,
Implementando PSP / TSP
“ NO HAY NADA MÁS DIFÍCIL DE CONSEGUIR, MÁS ARRIESGADO DE MANTENER NI MÁS INSEGURO DE TENER ÉXITO, QUE ESTAR A LA CABEZA EN LA INTRODUCCIÓN DE UN.
Taller de desarrollo de proyectos II Presentación Inicial.
Scrum Ciclo Profesor: Ing. José Díaz
Fundamentos de Computación
Metodologías de Programación II UNAJ - Instituto de Ingeniería y Agronomía - Ingeniería en Informática 1 3 Clase Clase 6 Scrum (Parte 2)
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
Ingeniería de Software Facultad de Ingeniería Septiembre 2010 Fernando Alsuyet Ariel Illio Matias Baldini.
Modelo de procesos de software
Es una metodología ágil diseñada para el desarrollo de software, basada en la calidad y el monitoreo constante del proyecto. Consiste esencialmente en.
Sistemas de calidad en el desarrollo de software.
Gerenciamiento de Proyectos. Planeamiento Estratégico  Introducción  Necesidad e Idea  Objetivos y Estructura Inicial  La importancia del Gerenciamiento.
Transcripción de la presentación:

Scrum y la realidad del software en Chile Myrleny Mancilla Morales Alejandro Núñez Guardia Santiago, 23 de marzo de 2017

Agenda Aplicación Scrum en el mercado local, yendo desde la cartas gantt hacia los gráficos de burndown. A esta altura todos hemos escuchado de Scrum Pasando del día a día a otro distinto Plazos impuestos Reunión diara una vez a la semana De Jefe de Proyecto a Scrum Master Cómo hacer Scrum sin apoyo Más allá del desarrollo, aplicando SCRUM a otros contextos. Scrum para otros proyectos Scrum para Testing Casos de éxito y facilitadores de la internalización del método.

A esta altura todos debieran haber escuchado de Scrum: Al menos una vez, ¡está en el título de esta presentación! Encuesta Ágil: Quienes son Certified Scrum Masters? Quiénes usan Scrum en sus empresas? Quienes no lo hacen pero están considerando hacerlo? Quienes no quieren usarlo?

Repasando Scrum

Ciclo de trabajo: Explicación Al inicio del proyecto se establece su factibilidad, visión, valor de negocio Después se listan los requerimientos creando el “Product Backlog” Al principio de cada iteración se seleccionan aquellos requerimientos que agregan mayor valor El equipo los analiza y define tareas para desarrollar cada uno de ellos, esas tareas conforman el Sprint y se registran en el Sprint Backlog (durante la reunión de Planificación) Al final de cada Sprint hay nueva funcionalidad para probar, la cual es presentada para revisión por parte de los usuarios y clientes Diariamente se revisa el estado de las tareas para detectar y remover obstáculos

Elementos de SCRUM Product Backlog Sprint Roles Valores Planificación Revisión Sprint Backlog SCRUM Retrospectiva (Reflexión) Roles Product Owner Scrum Master Team Valores Foco, apertura, coraje y respeto

Del día a día a otro distinto Para la gran mayoría, la adopción de Scrum para el trabajo diario no es algo que vaya a ocurrir de la noche a la mañana Para un área típica de desarrollo, hacer el cambio es relativamente simple Convencer al resto de la organización es el reto ¿Pero a qué están acostumbrados?

Cosas que Cambiarán al usar Scrum Cómo se ven afectadas las prácticas de gestión de proyectos más difundidas en Chile

De la Carta Gantt al Gráfico de Burndown Tal vez el cambio más visible de la incorporación de Scrum, sea en la presentación del avance del proyecto. Examinemos el enfoque tradicional y de Scrum respecto de la planificación: Proyecto de Ejemplo : Administrador de Bibliotecas Fecha de Puesta en Producción 10/08/2008 Miembros del equipo: 4 personas Módulos a Desarrollar: Adquisición de Libros Catálogo Reportes Administrador de Préstamos Administrador de Multas Baja y sustitución de ejemplares

Desglose de los módulos en actividades y tareas En la Gantt Desglose de los módulos en actividades y tareas Se fija el alcance, y se trata de ajustar a las restricciones de tiempo. Alcance Tiempos Costos Fijas Tradicional Ágil Variables Tiempos Costos Alcance

Revisamos el detalle del primer Sprint En Scrum Se estiman, priorizan y distribuyen los módulos solicitados en bloques temporales fijos (sprints). 2 Fecha de Fin 3 1 6 4 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Adquisición de Libros Catálogo Reportes Administrador de Préstamos Administrador de Multas Baja y sustitución de ejemplares Desde esa estimación podemos ver si el alcance puede ser cumplido en los plazos Revisamos el detalle del primer Sprint

Planificación del Sprint Identificación y estimación de actividades del Sprint El máximo de horas a agregar al Sprint es Horas en el Sprint x Personas en el equipo Todo exceso sobre ese número no se ve con posibilidades de éxito. Actividad Estimación Generar Pantalla Ppal 4h Conectar a la BD 2h Listar préstamos activos 8h Ingreso de Ejemplares 7h

La diferencia: Priorización del Backlog de Producto. Plazos impuestos Los muchachos de ventas / producción / gerencia seguirán imponiendo fechas de entrega del producto terminado sin haberte preguntado si es posible. La diferencia: Priorización del Backlog de Producto. Poner metas realistas, y cumplirlas dentro del sprint…. Si fallas, en el siguiente sprint tienes que ser cuidadoso. Revisar optimismo de las estimaciones Considerar complejidad de la solución de Software Prever un porcentaje del tiempo para resolver “urgencias” Tener considerado Testing / Documentación / Análisis Tranquilos(as): Todos fallamos en el primer Sprint Lo importante es definir todo lo que programaremos para llegar a la fecha comprometida. El equipo debe participar en la estimación que decide la meta de cada Sprint, y debe participar con mayor razón en la estimación de las tareas que se ejecutarán en el próximo Sprint. Deben considerarse esfuerzos reales / dedicaciones reales para no sobreestimar las capacidades del equipo. No todo el tiempo estaremos codificando, el ser Agile no significa que no documentaremos, analizaremos o diseñaremos la solución. El primer Sprint es para medirnos, y establecer el ritmo con el que continuaremos trabajando

Reunión de Avance Seguiremos teniendo que asistir a las clásicas reuniones de avance semanal, y los niveles jerárquicos superiores seguirán conformándose con un porcentaje como indicador de avance. Al interior del Equipo tendremos reunión diaria en donde se planifican las actividades a realizar durante el próximo día del proyecto. En esta ocasión el Scrum master recibe problemas y devuelve soluciones. Realizar la reunión diaria de pié, en círculo y en menos de 15 minutos, puede ser todo un espectáculo para el resto de la organización. Aprovechen el marketing gratuito que eso genera para educar sobre Scrum. Tener constancia y disciplina para llevar la reunión diaria de Scrum nos permitirá tener estimaciones frescas de cada tarea, saber que problemas han surgido y que temas se han solucionado. El Scrum Master tendrá que hacer esfuerzos especiales por mantener el foco de las reuniones, aprovechando al máximo el tiempo y guiando al resto del equipo a hacerlo. En caso de tener espectadores, mantenerlos interesados pero imposibilitados de intervenir en la reunión diaria. La presencia de espectadores junto al equipo es una invitación a recibir requerimientos que no estaban planificados.

Jefe de Proyecto o Scrum Master Si eres Jefe de Proyectos querrás ser Scrum Master, al resto de la organización le dará igual, mientras sigas recopilando requerimientos como antes… Ser Scrum Master no es dirigir al equipo hacia donde tú crees que deben ir, es apoyar al equipo a avanzar hacia donde ellos decidieron ir: Removiendo obstáculos que dificulten el avance del proyecto Consiguiendo recursos críticos Manteniendo actualizadas las estimaciones Ayudando a mantener al equipo enfocado Bloqueando interrupciones o tareas no planificadas en el Sprint Backlog Dirigiendo las actividades propias del método Educando activamente a la organización El Scrum Master debe tener la fuerza para proteger y defender a su equipo. Pero debe ser flexible y apoyar las decisiones tomadas en forma colectiva. El Scrum Master no es el jefe del equipo, está al servicio del equipo. Todo el trabajo de preparación de informes, gráficos y reuniones que se alejan del aspecto técnio deben ser absorbidas por el Scrum Master

Que tan de acuerdo está la organización con la implantación de Scrum? En muchas organizaciones es el equipo de desarrollo quién “decide” comenzar a trabajar con un método Ágil. Pero respetando también protocolos anteriores Hay que trabajar para demostrar que el método funciona Tener entregables funcionales al final de cada Sprint es la mejor demostración del avance real del proyecto Revisar formalmente la aplicación repasando cada compromiso adquirido al inicio del Sprint Mostrar avance diario en base a estimaciones actualizadas de cada tarea Tener un historial de fracasos con proyectos anteriores puede ser muy positivo, porque tenemos un excelente punto de comparación respecto de lo que estamos haciendo ahora. Para el día a día, pueden involucrar al Product Owner invitandolo a revisar el estado diario del proyecto, aprovechando su visita para aclarar dudas o recibir consejo sobre detalles no funcionales. Al finalizar el Sprint la demostración debe ser en vivo, no sirve una presentación, debe ser usada por el Product Owner, repasando en voz alta cada uno de los compromisos iniciales del Sprint.

Aplicando Scrum más allá del desarrollo

Scrum para Mantenciones Uno de los ajustes más dificiles a la hora de implantar Scrum es el de establecer un Sprint Backlog realista. Siendo el principal problema a considerar el flujo de solicitudes de mantención Mantenciones Lentas: El menos complicado de los panoramas, si entre la solicitud de mantención y el release requerido hay al menos un Sprint, entonces la mantención puede entrar perfectamente en el esquema. Asignandole la prioridad necesaria para que entre al siguiente Sprint Backlog. Mantenciones Rápidas: Caen aquí todas las “emergencias”. Si las emergencias son la regla, considerar un tiempo reservado para estas actividades, como si fuese una tarea más que siempre entra en el Sprint Backlog. Si la emergencia pone en riesgo el cumplimiento del Backlog comprometido, tratar de negociar elementos a “Intercambiar” entre el backlog y la emergencia. Usar Scrum para mantenciones presenta un desafío mayor, ya que tenemos menos oportunidades (iteraciones) para poder depurar la aplicación. Las mantenciones lentas pueden programarse de modo de ir encolando las peticiones de soporte, priorizando desde esa lista para conformar el Sprint Backlog. Las mantenciones rápidas dificultan el uso de Scrum en su forma estandar, y podría requerir la reducción radical de la duración de cada Sprint (llegando a 2 o 3 días por Sprint). Aún así, la gran mayoría de las actividades de gestión de proyecto aplican perfectamente.

Scrum para Testing Testing Formal Testing Exploratorio La priorización del Product Backlog de testing debe sincronizarse con las entregas por parte de desarrollo (sea cual sea la metodología que usen) Dependiendo del proyecto y basándonos en la estimación de rendimiento por caso de prueba. Podemos asignar tareas de Definición / Ejecución de agrupaciones funcionales de casos de prueba. Estas agrupaciones serán nuestras Actividades. Con la reunión diaria se actualizarán las estimaciones de la definición / ejecución de casos de prueba. La reunión de finalización del Sprint debiera hacer repaso de los casos de prueba más relevantes. Testing Exploratorio En el caso de que sólo se realice test exploratorio, calcular tareas basadas en cantidad de entradas / salidas / campos / ventanas. Formalizar proceso de Testing. La vida será mas fácil! Al aplicar Scrum para Testing, dadas las características más predecibles del Testing el consejo es agrupar casos de pruebas para su definición o ejecución en base a sus características funcionales. Considerar varios ciclos de prueba dependiendo de las métricas anteriores. Para el Testing Exploratorio tomar estimaciones en base a las características de la aplicación a testear. Convencer al equipo y a la organización de los beneficios de la aplicación formal del testing.

Casos de éxito y facilitadores

Caso de Éxito: GamingCompany.com Cliente local dedicado al desarrollo de videojuegos, compuesto por dos equipos claramente diferenciados: Ingenieros y Diseñadores Adopción rápida del método. Scrum Master es a la vez parte del equipo Mejoraron estimación , entregas comprometidas y manejo de los cambios de requerimientos Casi 2 años utilizando el método Totalmente institucionalizado

BigBank.mx Scrum aplicado para Testing Equipo de testing muy extenso, realizando Scrums de Scrums para soportar volumen de participantes El gráfico de burndown se utilizó como monitor de avance de las pruebas de todo del proyecto. Integrantes del equipo (80+ personas) no tenían experiencia con metodologías ágiles. Fueron entrenadas en sus actividades particulares, disminuyendo costos y tiempo de inicio del proyecto

Facilitadores para la adopción de Scrum Alta productividad / Alta técnica Localización común de los participantes Sencillez del seguimiento y su reporte Historial de retrasos en proyectos anteriores Clientes finales que quieran ver “prototipos” Proyectos elaborados por Fases Proyectos de más de 6 meses Equipos compactos de entre 5 y 12 personas Scrum Master con espíritu de servicio. No de mando Hacer de la demostración a fin de cada sprint un evento importante Product Owner entrenado en el método

Visite nuestros WEBSITES: www.pragmaconsultores.com - Información Detallada de Servicios - Nuestra Experiencia: Clientes y Proyectos - Nuestro Compromiso y Nuestra Metodología de Trabajo www.qafactory.com - Fábrica de Aseguramiento de la Calidad - Beneficios y Detalle del Servicio Contáctenos: Chile Luis T. Ojeda 0191 • Of. 701, Providencia, Santiago Tel (+56-2) 334-3361 practia@practia.cl Argentina San Martín 575 • 2º (C1004AAK) Buenos Aires Tel (+54-11) 4327-1999 pragma@pragma.com.ar España López de Hoyos 35 • 1º (28002) Madrid Tel (+ 34) 91-745-9912 practia@practia.es