Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

SCRUM

No description
by

Carolina Valverde

on 27 March 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of SCRUM

Muchas gracias por su atención! Introducción a SCRUM: conceptos básicos y caso de aplicación en BPS ¿Por qué se llama SCRUM? Team Definición Roles Proceso MARCO TEÓRICO ¿Qué es SCRUM? Metodología ágil Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda. Timebox Comunicación Enfoque iterativo e incremental
Auto-organización
Optimiza productividad
Valor para el cliente
Control empírico del proceso: transparencia, inspección y adaptación "Incomodidad" Rápido, no apurado Feedback temprano Procesos visibles, ajustados por inspección Product Owner Scrum Master No es un Gerente de Proyecto "Custodio" del Proceso Líder facilitador basado en coaching y apoyo al equipo "Custodio" del Producto Responsable del valor generado para el producto UN representante del cliente VISIÓN Auto-organización 4 a 9 integrantes Sin "títulos" Product
Backlog Marco de trabajo para desarrollo de sistemas Reglas
Process Backlog Product Backlog Decisiones reflejadas en prioridades sobre requerimientos Responsables de generar un incremento del producto de valor para el PO Requerimientos
del
Producto Funcionalidades, características, tecnologías, mejoras, bugs a solucionar, cambios, ... que definen al producto En constante evolución Nunca completo Tarjetas Descripción
Estimación
Valor del Negocio
ROI
Prioridad BV/PE Puntos de Esfuerzo PO Para adaptarse a necesidades
cambiantes del producto Team
Agree Disciplina Definiciones Sprints
Timebox
Fechas
Reuniones Dashboard Estrategia
+

Táctica ¿Qué tarjetas se realizarán
en este Srpint? Identificación de tareas Prioridades del PO Negociación PO y Team Evacuar dudas sobre tarjetas Compromiso del Team Sprint Backlog Criterios de
Aceptación Para cada tarjeta: qué se espera que haga cuando se complete Forma de validación del PO Estimaciones Planning Poker Sprint
Backlog Subconjunto de reqs que el Team se compromete
a realizar en un Sprint Sin cambios durante el Sprint Solo el Team puede modificar las estimaciones Sprint Execution (2-4 weeks) Iteración Timebox Potentially
Shippable
Product Incremento del producto de valor para el PO Criterio de listo Sprint
Review Sprint
Retrospective Timebox: 5% de la duración total del Sprint Adicional a incrementos anteriores Correctamente testeado Mostrar qué se hizo y qué no PO acepta o rechaza "tarjetas" Team muestra trabajo alcanzado y comenta dificultades encontradas Compromiso del Team para cumplir
con requerimientos del PB Entendido por el PO Daily
Meeting Timebox: 15 minutos ¿Qué se cumplió en ese día? ¿Qué se compromete a cumplir para el próximo día? ¿Qué dificultades surgieron? Comunicación Minimiza cantidad de reuniones e interrupciones al Team
Elimina obstáculos para el desarrollo
Promueve toma de decisiones "rápida"
Mejora conocimiento sobre el proyecto Planificación "just-in-time" Solo se planifica lo que se va a hacer en el próximo Sprint No es una reunión de status Inspección y adaptación Optimiza la probabilidad de que el Team cumpla con el compromiso del Sprint Timebox: 5% de la duración total del Sprint Bugs, cambios, nuevos requerimentos Se agregan en PB "Parking lot" para errores de testeo Input para próximo Sprint Timebox: de 2 a 3 horas Revisión del Proceso Proceso
Herramientas
Relaciones
Personas
Comunicación
Reuniones
Acuerdos
Criterio de listo
... Process Backlog Mejoras/Cambios en el Proceso

Inspección y adaptación

El Team y SM cumplen el rol de PO ¿Cumple con los criterios de aceptación? Es fundamental el aporte del Team Opcional: Puntos de Esfuerzo realizados en el día El Team no debería trabajar en nada que no esté en el SB Cambios en requerimientos:
Re-estimación
Re-valoración
Re-definición de criterios de listo
Re-definición de criterios de aceptación Transmitir la experiencia piloto de aplicación de SCRUM a otros interesados dentro de BPS, tanto a nivel teórico de la metodología así como de los resultados de evaluación de uso Todos silenciamos los celulares
Pedimos participación activa del público
Para participar "pedir la pelota"
Al finalizar la jornada todos completamos la encuesta de satisfacción
Corte con café y galletitas a las 11.15hs Sprint 1: Marco Teórico, presentar principales conceptos de SCRUM
Timebox: 90 minutos, de 9.45 a 11.15hs Sprint 2: Presentar la experiencia de aplicar SCRUM a un proyecto piloto en BPS
Timebox: 90 minutos, de 11.30 a 13.00hs Veamos nuestro Product Backlog ... Que los participantes conozcan la metodología SCRUM.
Que los participantes cuenten con elementos que les ayude a detectar oportunidades de uso de esta metodología que aporten a su labor.
Que se presenten los principales artefactos que sustentan la metodología, y que eventualmente evalúen su aplicación inclusive por fuera de la misma. El primer incremento de nuestro producto será cuando finalicemos el Marco Teórico (Sprint 1) Luego de finalizada la presentación, le preguntaremos a nuestro PO...
¿Cumplimos con los criterios de aceptación definidos?
¿Qué tarjetas se aceptan y cuáles no? ¿Qué puntos de mejora se identifican sobre nuestro proceso? Gabriel, Carlos, Damián, Juan Pablo, Paola y Carolina Estela Gonzalo Cubrir todos los puntos definidos
Entendimiento por parte del público
Consultar si hay dudas, y responderlas SDES-Centro de Servicios de Desarrollo Central
SUGPC-Control y Mejora de los Servicios Historias de Usuario Descripción
Criterios de aceptación
Conversaciones, mails Como <rol> necesito <actividad> con el objetivo de <objetivo buscado> Release
Planning Retrospectiva - Starfish MANTENER Involucrar desde el comienzo del proyecto al PO, lograr su compromiso para llegar a un producto que se adecue a sus necesidades y a la visión.
Que note la importancia de su rol y que es el dueño del producto.
Sprints de duración fija e inamovible ayuda a organizarse de mejor manera para llegar en tiempo y forma con las funcionalidades comprometidas.
Ambiente de trabajo físico separado del ambiente diario donde ocurren más interrupciones, influye favorablemente en el trabajo.
La programación en pares se considera que aumenta la productividad de desarrollo y disminuye el retrabajo
INNOVAR No se cuenta con una herramienta que unifique y centralice el seguimiento y trabajo con SCRUM, lo cual facilitaría la aplicación de la metodología.

Tender a un desarrollo full-stack que incluya testing automatizado (TDD) en el proceso.
Realizar una estimación top-down, partiendo de la macro por funcionalidad, y llegando a estimar cada tarea o subproducto Planificar Sprint con al menos sean 10 días de desarrollo, además de los 3 días de reuniones


Generar una wiki con problemas y soluciones conocidas
Cambio de paradigma en la arquitectura COMENZAR A HACER NO MÁS OTRA OPORTUNIDAD La especificación de las tarjetas debería ser tal, que cualquier integrante que no sea del team sea capaz de comprender los requerimientos.

Refinar el criterio de listo con mayor detalle, debe quedar claro para todos los involucrados, y no debe ser ambiguo.



PO que no define los criterios de aceptación

Reuniones donde no se cumple el timebox, y se desvía de su alcance
Ejemplo, en planning no se debe discutir en detalle sobre las tarjetas, esto se hace durante la ejecución.
Para funcionalidad complejas, incorporar proceso previo al review que permita mostrar el producto con mayor eficacia de nuestra experiencia ¿Cuándo aplica utilizar SCRUM? Existencia de PO que pueda cumplir con el rol, tal como la metodología lo enuncia

Debe conocer la metodología (taller, curso, …) Cuando los requerimientos no cambian a diario por el cliente

No existen otros proyectos críticos para el negocio, de alta prioridad, que no permita cumplir con los plazos y la metodología

Evaluación en Release Planning Equipos conformados por no menos de 4 integrantes, y no más de 9



Que conozcan la metodología (Team y SM)
Con dedicación fija, no menor a media jornada laboral En un equipo de 4 integrantes y 3hs de dedicación diaria, cada Sprint debería durar al menos 10 días de desarrollo, además de los 3 días de reuniones Definir timebox cerrado para cada Sprint, y que se pueda cumplir

Cuando es posible tener un ambiente de trabajo físico separado, o es posible evitar interrupciones en el horario acordado

Creación de ambientes
Liberaciones en testeo y producción
Reuniones
Testeos planificados con PO Tiene que ser posible una planificación con SITO Contar con una herramienta que unifique y centralice el seguimiento y trabajo con SCRUM Team armado y consolidado


Conocerse y haber trabajado juntos previamente Compromiso gerencial

Artefactos de SCRUM en BPS MANTENER CAMBIAR Dashboard Mejora comunicación (team con SM, y con stakeholders)
Quién está haciendo qué Daily Meeting ¿En qué estamos?
¿Cómo seguimos? Reuniones planificadas, timebox fijo Planning, Review, Retrospectiva Liberaciones al PO frecuentes y que agregan valor
Resultados tangibles en corto plazo
Ajustes en requerimientos antes de fin de proyecto Sprints de diferente duración Timebox cerrado, establecido al comienzo
Dependiendo de las funcionalidades comprometidas Timebox fijo y específico para puestas en testeo y producción
Propuesta: 2 días al final de cada Sprint
Incluir Sprint pre-producción Sprint 0 Incluir Diseño Macro del release
No perder visión general
Aplicar técnicas y herramientas de Gestión de Proyectos
Sitios de Proyecto
Cronograma (PWA)
Involucrar Referentes de Tecnología Propuesta de uso Proyectos de corta duración por tensión de Team en cada Sprint
VISIÓN Product
Backlog Requerimientos
del
Producto Team
Agree Definiciones Sprints
Timebox
Fechas
Reuniones Nuestro Dashboard Sprint
Planning PO asigna BV a cada tarjeta
Team estima esfuerzo
Se calcula ROI=BV/PE Criterios de
Aceptación Difícil lograr que el PO los definiera Planning Poker Estimación de esfuerzo Sprint
Backlog Sprint Execution (2-4 weeks) Potentially
Shippable
Product Nuestro Producto Criterio de listo Sprint
Review Sprint
Retrospective Timebox: 90 minutos Mostrar qué se hizo y qué no Recordar al PO el contenido del Sprint backlog Daily
Meeting Timebox: 10 minutos Timebox: 60 minutos Cómo presentamos el producto Parte del Team Agree Timebox: 150 minutos Starfish y Process Backlog Sistema de Gestión de Convocatoria y Designaciones de personas seleccionadas, capaz de integrarse con la BDC, recibir datos de otros procesos de selección, que publique en el sitio web y emita comunicaciones masivas a otros involucrados en el proceso, asegurando robustez, calidad de datos en tiempo real y transparencia Comenzar a trabajar en el proyecto todos los días puntualmente a las 14hs
Se auto-gestionará cubrir las licencias de otros team members
Salir a almorzar a más tardar a las 13hs
Daily de 16:45 a 17:00hs Timebox: 3 Sprints de 2 semanas, 3hs por día, 4 desarrolladores
7 días de desarrollo
3 días de reuniones Modelos y Diagramas
Testeo unitario
Testeo de integración
Release
Planning Proceso aplicado ROLES Team Product Owner Scrum Master Damián, Juan Pablo, Carlos, Gabriel Paola, Carolina (backup) Gerente Registro de Personal
Zelmar Piazza Compromiso del PO Sprint 0 Timebox determinado Visión Comprometida Documentación comprometida
Especificación de requerimientos funcionales y no funcionales
Solución funcional, modelo de dominio
Arquitectura: modelo de componentes y deploy
MER
Casos de prueba
Infraestructura, ambiente de desarrollo
Escenario de construcción, herramientas a utilizar
Esquema de seguridad
Arquitectura general TEAM Coordinar la generación del Product Backlog (para release)
Común acuerdo Team y PO
Basado en visión comprometida
Valor de negocio (BV) para PO SM 1) ARMAR las NECESIDADES de una CONVOCATORIA (sin considerar puntajes repetidos)
Alta, Baja y Modificación de los datos de la convocatoria. Por ejemplo: fecha de inicio, fecha de fin, cupos por localidades (titulares y suplentes) e identificación de la misma.

Todos los datos son obligatorios.
Validaciones: fecha de fin > fecha de inicio
Todos los datos (salvo el identificador) se pueden editar al modificar una convocatoria, incluso hasta después de publicada.
Cuando se elimina una convocatoria, se debe mantener el log (histórico) de cuándo se eliminó y quién lo hizo. Mejora capacidad de estimación La prioridad está dada por el ROI, pero hay que considerar las dependencias Team decide a qué se compromete Auto-organización ANATOMÍA DE LA REUNIÓN Desarrollo vertical Análisis - Diseño - Desarrollo
Refactory Concentración Tensión Dashboard actualizado Interacción con PO Todo el team Mejora comunicación del Team Criterios de aceptación Guían la revisión Validación en base a criterios Pasaje a testeo Testeo funcional durante Sprint siguiente Parking lot para bugs bloqueantes Pair Programming Mejora productividad
Cubrimiento de licencias Contexto Metodologías acordes a la realidad
Herramientas flexibles ¿CÓMO SURGE ESTA INICIATIVA? Distintos dominios de negocio en BPS
Dinamismo y heterogeneidad en las necesidades de automatización
Las metodologías ágiles se presentan como una opción muy interesante para complementar sobre las metodologías tradicionales (ej: RUP) ¿Cuál es nuestra realidad? ¿Qué necesitamos? Entonces ... Capacitación Dinámica del backlog Rol SM Como facilitador
Participación de stakeholders que no eran el PO GUIÓN NO es desarrollo neto EXPERIENCIA PILOTO EN BPS Sprint
Planning 1.¿Cuáles son los tres roles que participan en esta metodología? Para cada caso, indicar al menos una de sus principales funciones. Artefactos de la metodología: Oportunidad de aplicación en BPS 2.¿Qué ventajas y desventajas brinda SCRUM con respecto a una metodología tradicional (ej. RUP)? Metodología SCRUM – Conceptos
3.¿En qué situaciones del trabajo diario aplicaría el concepto de “timebox”? 1.Si para un nuevo proyecto Ud. cuenta con un equipo de desarrollo de 3 integrantes full-time, ¿aplicaría SCRUM? 2.Si para un nuevo proyecto se identifica un referente funcional con conocimiento del negocio, y con disponibilidad para el proyecto, ¿aplicaría SCRUM? 1.¿Para qué situaciones del trabajo diario utilizaría una “Daily meeting”? 2.¿En qué situaciones (además de una Retrospectiva) podría ser útil utilizar la herramienta “starfish”? Debe tener la jerarquía necesaria para tomar decisiones
Debe estar comprometido e involucrado con el proyecto Sprints
Full transcript