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 ESP

Metodologías ágiles de desarrollo - SCRM
by

B. Janeth Morales Méndez

on 4 December 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of SCRUM ESP

SCRUM ROLES SCRUM MASTER Su trabajo es eliminar los obstáculos que
impiden que el equipo alcance el objetivo
del sprint PRODUCT OWNER Representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma
adecuada desde la perspectiva del negocio. EQUIPO Es el que tiene la responsabilidad de entregar el producto USUARIOS Son los destinatarios finales del producto INTERESADOS Son la gente que hace posible el proyecto, para quienes el proyecto producirá el beneficio acordado que lo justifica. MANAGERS Es la gente que establece el ambiente para el desarrollo del producto. ¿QUÉ ES SCRUM? Scrum, que se basa en la teoría del control empírico del procesos, emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar los riesgos. HISTORIA 1986: Hirotaka Takeuchi y Ikujiro Nonaka describieron una aproximación holística en el desarrollo de productos comerciales. 1991: Peter DeGrace y Leslie Stahl acuñan el termino “Scrum” en su libro “A problemas malvados, soluciones virtuosas”. 1995: Ken Schwaber y Jeff
Sutherland presentan articulos describiendo scrum, siendo ésta la primera aparición publica de la metodología. ORGANIZACIÓN DE EQUIPOS Los Equipos Scrum están diseñados para optimizar la flexibilidad y la productividad, para lo cual, son auto-gestionados, multifuncionales, y trabajan en iteraciones. Los Equipos también se auto-organizan. Nadie, ni siquiera el ScrumMaster, dice al Equipo cómo convertir el Product Backlog en incrementos de funcionalidad entregable. Los Equipos también son multifuncionales; los miembros del equipo deben tener todas las habilidades necesarias para crear un incremento de trabajo. El tamaño óptimo para un equipo es de siete personas, más o menos dos.

La composición del Equipo puede cambiar al final de un Sprint. REQUERIMIENTOS En Scrum los requisitos se expresan como elementos del Product Backlog. El Product Backlog es una lista de requisitos funcionales y no funcionales priorizados por su valor para el cliente. Dejando claro que los requisitos que en ella aparecen y el orden de los mismos es cambiante a lo largo de la vida del proyecto. Solo es necesario el nivel de detalle suficiente que nos permita estimar los requisitos y priorizarlos A menudo se utilizan historias de usuario para expresar estos requisitos Los requisitos que aparecen el en Product Backlog deben ser independientes, negociables, evaluables, estimables y no demasiado grandes COMUNICACIÓN EQUIPOS - USUARIO 1. En SCRUM , la comunicación con el cliente se realiza a través del rol de Product Owner ARTEFACTOS Los Artefactos de Scrum incluyen: el Product Backlog, el Burndown de entrega, el Sprint Backlog, y el Sprint Burndown. PLANIFICACIÓN En SCRUM la planificación se realiza para cada iteración o Sprint FORTALEZAS El cliente esta satisfecho ya que recibe lo que necesita y esperaba
El coste en términos de proceso y Management es mínimo.
Permite realizar proyectos en
Rápido desarrollo
Los problemas se identifican por adelantado en las reuniones
Hay visibilidad clara del desarrollo del proceso
Iterativo en su naturaleza
Fácil de manejar los cambios debido a los sprints tan cortos y el feedback constante DEBILIDADES ACTIVIDAD

/

PREGUNTAS Los requisitos para el producto, están listados en el Product Backlog.

El Propietario del Producto es responsable del Product Backlog, de su contenido, disponibilidad y priorización. Product Backlog y Burndown de Entrega El Product Backlog representa todo lo necesario para desarrollar y lanzar un producto exitoso.

El Product Backlog está ordenado por prioridad. El gráfico de Burndown de la Entrega registra la suma del esfuerzo restante estimado del Product Backlog a lo largo del tiempo. Sprint Backlog y Sprint Burndown El Sprint Backlog se compone de las tareas que el Equipo realiza para convertir los elementos del Product Backlog en un incremento "hecho". Los elementos del
Sprint Backlog deben descomponerse.

La descomposición debe ser suficiente para que los cambios en curso puedan ser entendidos en el
Scrum Diario. Sprint Burndown mide los elementos restantes del Sprint Backlog en el transcurso de un Sprint Una meta para el Sprint. Una lista de miembros Una pila de Sprint Una fecha para la Demo del Sprint Un lugar y momento definidos para el Scrum
diario. Para los desarrolladores las ventajas pueden ser motivación y satisfacción de realizar el trabajo de una manera eficiente.
Es fácil entregar un producto de calidad en el tiempo estipulado
Puede trabajar con cualquier tecnología o lenguaje de programación
Hace el proceso del desarrollo de software más centrado y manejable Si no existe una fecha definitiva de finalización del proyecto es posible que se siga solicitando, y añadiendo, nueva funcionalidad.
Si una tarea no está bien definida, los costes de tiempo y dinero estimados del proyecto no serán demasiado exactos.
Si los miembros del equipo no están centrados y convencidos, el proyecto nunca se completara o incluso fallará.
Está bien para proyectos pequeños, de rápido movimiento ya que trabaja bien solo con equipos pequeños. Esta metodología necesita solo miembros de equipo experimentados.
La falta de dirección firme pueden llevar a los proyectos a no completarse o incluso fallar.
La metodología Scrum funciona bien cuando el scrum master confía en el equipo que lleva.
Si algunos de los miembros del equipo se marcha durante el desarrollo puede tener un efecto negativo enorme en el desarrollo del proyecto.
El control de la calidad del proyecto es difícil de implementar y cuantificar 2. El cliente siempre está deseoso de ver los resultados del trabajo. Esto se puede manejar con la entrega de iteraciones, que se producen en un breve periodo de tiempo. Estas entregas hacen que el cliente tenga conocimiento de cuánto va a recibir y en que fechas. Además al ordenar la pila, sabe qué tipo de entrega le espera. 3. El cliente es inestable, cuando un cliente transmite una necesidad, pasadas unas escasas horas, ya la ha modificado en su cabeza. Esta inestabilidad choca directamente con cualquier planificación. En SCRM se aceptan cambios, de manera controlada, en el trascurso iterativo del proyecto, Los cambios mejoran el resultado final del producto, el cliente acaba obteniendo lo que quiere y con las últimas innovaciones.
Full transcript