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

EXPOSICIÓN SCRUM

Exposición de SCRUM para ingenieria de Software

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of EXPOSICIÓN SCRUM

SCRUM Introducción
Herramientas Roles Reuniones Actividad Como su nombre lo dice, en la metodología SCRUM es la parte funcional de la metodología, de lo que esta compuesto y como esto influyen en la implementación del modelo en un proyecto de desarrollo de software.

Product Backlog. Lista de las funcionalidades que necesita el cliente, priorizada según las prioridades que él determina.
Sprint Backlog: Lista de tareas que se van a realizar en un sprint.
Incremento: Parte del sistema desarrollada en un sprint. Elementos La descripción del sistema define la forma en que se debe abordar un caso: En los proyectos predictivos, los requisitos del sistema suelen especificarse en documentos formales; y el product backlog de los proyectos ágiles toma la forma de lista de historias de usuario.
Los requisitos del sistema formales se especifican por completo al inicio del proyecto, y el product backlog es un documento vivo, que evoluciona durante todo el desarrollo de forma concurrente con el resto de actividades.
Los requisitos del sistema los desarrolla una persona o equipo especializado en ingeniería de requisitos a través del proceso de obtención (elicitación) con el cliente. En Scrum la visión del cliente es conocida por todo el equipo (el cliente forma parte del equipo”) y el product backlog se realiza y evoluciona de forma continua con las aportaciones de todo el equipo. Product Backlog: los requisitos del cliente El product backlog es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo. Representa todo aquello que esperan los
clientes, usuarios, y en general los interesados en el producto. Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el backlog.

Estos son algunos ejemplos de posibles entradas de un backlog:

•Permitir a los usuarios la consulta de las obras publicadas por un determinado autor.
•Reducir el tiempo de instalación del programa.
•Mejorar la escalabilidad del sistema.
•Permitir la consulta de una obra a través de un API web. Permitir la consulta de una obra a través de un API web. Es recomendable que el formato de lista que incluya al menos la siguiente información para cada línea:

Identificador único de la funcionalidad o trabajo.
Descripción de la funcionalidad.
Campo o sistema de priorización.
Estimación.

Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, pueden
resultar aconsejables otros campos:

Observaciones
Criterio de validación
Persona asignada
Nº de Sprint en el que se realiza
Módulo del sistema al que pertenece Formato del product backlog Sprint backlog El sprint backlog es la lista que descompone las funcionalidades del product backlog en las tareas necesarias para construir un incremento: una parte completa y operativa del producto.

Condiciones:

Realizado de forma conjunta por todos los miembros del equipo.
Cubre todas las tareas identificadas por el equipo para conseguir el objetivo del sprint.
Sólo el equipo lo puede modificar durante el sprint.
El tamaño de cada tarea está en un rango de 4 a 16 horas de trabajo.
Es visible para todo el equipo. Idealmente en una pizarra o pared en el mismo espacio físico donde trabaja el equipo.

Sprint backlog Criterios Dependiendo de las características del proyecto tanto oficina y equipo definen el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:

Incluye la información: lista de tareas, persona responsable de cada una, estado en el que se encuentra y tiempo de trabajo que queda para completarla.
Sólo incluye la información estrictamente necesaria.
El medio y modelo elegido es la opción posible que más facilita la consulta y comunicación diaria y directa del equipo.
Sirve de soporte para registrar en cada reunión diaria del sprint, el tiempo que le queda a cada tarea. Formato Sprint backlog El Incremento Incremento es la parte del producto desarrollada en un sprint.

El incremento es la parte de producto producida en un sprint, y tiene como características que está completamente terminada y operativa: en condiciones de ser entregada al cliente final.

Idealmente en el desarrollo ágil:
Cada funcionalidad del product backlog se refiere a funcionalidades entregables, no a trabajos internas del tipo “diseño de la base de datos”
Se produce un “incremento” en cada iteración. Origen Scrum es una metodología ágil para gestionar proyectos de software, que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80 (Ikujiro & Takeuchi, 1986). Aunque surgió como práctica en el desarrollo de productos tecnológicos, resulta válido en los entornos que trabajan con requisitos inestables, y necesitan rapidez y flexibilidad; situaciones habituales en el desarrollo de algunos sistemas de software. Scrum para software En 1993, Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 presentó, junto con Ken Schwaber, las prácticas que empleaba como proceso formal, para gestión del desarrollo de software en OOPSLA 96 (Schwaber & Sutherland, 1996). En 2001 formaron parte de los firmantes del Manifiesto Ágil. Las prácticas diseñadas por Schwaber y Sutherland para gestionar el desarrollo de software están incluidas en la lista de modelos ágiles de Agile Alliance. Caracteristicas Sintesis Flexibilidad Globalidad definicion de roles Metodologia de la exposiciòn Tipos de rol Todas las personas que trabajan empleando Scrum tienen un rol muy definido dentro del proceso. Existen dos niveles de implicación bien diferenciados en Scrum, los que están directamente implicados en el desarrollo del mismo, que se les denomina “Cerdos“, y los que solo están afectados de forma tangencial, a los que se les denomina “Gallinas“. Estos nombres están basados en un chiste. Éste versa sobre un cerdo y una gallina que se encuentran por la calle. La gallina mira al cerdo y dice: “Hey, ¿por qué no abrimos un restaurante?” El cerdo mira a la gallina y le dice: “Buena idea, ¿cómo se llamaría el restaurante?” La gallina piensa un poco y contesta: “¿Por qué no lo llamamos “Huevos con jamón?” “Lo siento pero no”, dice el cerdo, “Yo estaría comprometido pero tú solamente estarías involucrada”. Roles “Cerdo” Propietario del producto PP.
SCRUM Manager SM.
Equipo. Propietario del producto Responsabilidad del producto
Determina las prioridades, una sola persona.
Interlocutor entre el cliente y el equipo.
Representante del cliente, se asegura que el producto que se este creando esta dentro de los objetivos que esta marcando el cliente SCRUM Manager Responsabilidad del funcionamiento
Gestiona y facilita la ejecución del proceso.
Es un miembro del equipo que desarrolla tareas especiales
Reuniones.
Artefactos
Determinar en consenso los objetivos de el sprint
Elimina los obstáculos que impiden que el equipo alcance el objetivo dentro del sprint.
Es el que comunica al propietario del producto el desarrollo del sprint.
Representante del equipo que controla que el proceso de un sprint se lleve de manera adecuada. Equipo Responsabilidad del desarrollo.
Todo el equipo de trabajo debe conocer la metodología SCRUM.
Auténticos responsables del desarrollo.
Debe cumplir todas las habilidades necesarias para generar el desarrollo.
Se auto-gestiona y se auto-organiza.
Recomendación entre 4 y 12 personas. Roles “Gallina” Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta si se busca un resultado óptimo. Hay algunas fases del Scrum en la que pueden aportar valor, como las reuniones de estimación o de retrospectiva. Estos roles pueden ser tantos como estructuras organizativas distintas tenga cada empresa Ejemplos Usuarios o clientes a los que va destinado del producto, Especialistas en Marketing, Intermediarios o Comerciales. VALORES EN EL EQUIPO SCRUM Delegación de atribuciones (empowerment) al equipo para que pueda auto-organizarse y tomar las decisiones sobre el desarrollo.
Respeto entre las personas. Los miembros del equipo deben confiar entre ellos y respetar sus conocimientos y capacidades.
Responsabilidad y auto-disciplina (no disciplina impuesta).
Trabajo centrado en el desarrollo de lo comprometido
Información, transparencia y visibilidad del desarrollo del proyecto En el trabajo con Scrum, el seguimiento y la gestión del proyecto se basa en la información de trabajo de las tres reuniones que forman parte del modelo:
Planificación del sprint
Monitorización del sprint
Revisión del sprint PLANIFICACION DEL SPRINT En esta reunión, tomando como base las prioridades y necesidades de negocio del cliente, se determinan cuáles y cómo van a ser las funcionalidades que se van a incorporar al producto con el próximo sprint. La primera dura de 1 a 4 horas
La segunda parte que puede alargarse incluso hasta el final de la jornada PRECONDICIONES Esta reunión es conducida por el SCRUM MANAGER a la que deben asistir, el propietario del producto del backlog, y el equipo completo MONITORIZACION DEL SPRINT Reunión breve diaria, de no mas de 15 minutos en la que todos los miembros del equipo dicen en que están trabajando, si se han encontrado o prevén encontrarse con algún impedimento y actualizan sobre el backlog las tareas ya terminadas o los tiempos de trabajo que les quedan. PRECONDICIONES Disponibilidad de un lugar físico print backlog actualizado en el soporte que emplee el equipo (pizarra, post-tips, hoja de calculo) Entradas
y salidas FORMATO DE LA REUNION se recomienda realizarla de pie y emplear un formato de backlog o lista de tareas en una pizarra o en la pared, para que todo el equipo pueda verlo, anotar o mover las tareas, junto con el gráfico de avance del sprint.

Uno por uno los miembros del equipo exponen estas tres cuestiones.
¿en que trabajo ayer?
¿en que va a trabajar hoy?
¿Qué problemas prevén que se van
a presentar o impedimentos? REVISION DEL SPRINT Reunión realizada al final de cada sprint en la que con una duración máxima de 4 horas el equipo presenta el producto al propietario el incremento del sprint. OBJETIVOS El propietario del producto obtiene una revisión del progreso del sistema.
Al ver el incremento funcionando, el propietario del producto, y el equipo en general obtienen feedback clave para evolucionar y dar valor al product backlog PRECONDICIONES Se ha concluido el sprint
Asiste todo el equipo de desarrollo, el propietario del producto, el responsable de procesos de la empresa y todas las personas implicadas en el proyecto que lo deseen. FORMATO DE LA REUNION Es una reunión informal. El objetivo es ver el incremento, trabajar en el entorno del cliente. Están prohibidas las presentaciones gráficas y “powerpoints”.
El equipo no puede invertir mas de una hora en preparar la reunión y lo que se muestra es el resultado final: terminado, probado y operando en el entorno del cliente. Cierre
Full transcript