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

Edgardo Martinez

on 27 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of SCRUM

Metodologías de Desarrollo de Software
Roles en Scrum
Reuniones en Scrum
KANBAN
Visualizar el trabajo y flujo de Trabajo
SCRUM
Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software.

Sprint
Período en el cual se lleva a cabo el trabajo.
Duración de los sprints constante y definida por el equipo.
Al final de cada sprint, el equipo deberá presentar los avances logrados, y el resultado obtenido es un producto potencialmente entregable al cliente.
Se recomienda no agregar objetivos al sprint o sprint backlog a menos que la falta de estos objetivos amenace al éxito del proyecto.
Características
Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.
Durante cada sprint, un período entre una y cuatro semanas, el equipo crea un incremento de software potencialmente entregable (utilizable).
Product Backlog, es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar.
Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning.

Roles Principales
Product Owner
asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio

ScrumMaster
elimina los obstáculos que impiden que el equipo alcance el objetivo del sprint

Equipo de desarrollo
tiene la responsabilidad de entregar el producto

Roles Auxiliares
Stakeholders
gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción

Administradores
establece el ambiente para el desarrollo del producto
Daily Scrum o Stand-up meeting
cada día de un sprint, se realiza la reunión sobre el estado de un proyecto

Scrum de Scrum
Cada día normalmente después del “Daily Scrum”

Reunión de Planificación del Sprint
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”

Reunión de Revisión del Sprint
Retrospectiva del Sprint
Documentos
Product backlog
Contiene descripciones genéricas de todos los requisitos, funcionalidades deseables, etc. Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido.

Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint.


Burn down chart
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.

Visualizar el trabajo y las
fases del ciclo de producción o flujo
de trabajo
Determinar el límite de “trabajo en curso” (o Work In Progress)
Medir el tiempo en completar una
tarea (lo que se conoce como
“lead time”).
El trabajo se divide en partes,
cada una de esas partes se escribe
en un post-it y se pega en una pizarra
La pizarra tiene tantas columnas como estados por los que puede pasar la tarea (ejemplo, en espera de ser desarrollada,
en análisis, en diseño, etc.).



MURO KANBAN
Determinar el límite de
"Trabajo en Curso"
En Kanban se debe definir cuantas tareas como máximo puede realizarse en cada
fase del ciclo de trabajo (ejemplo, como máximo 4 tareas en desarrollo, como
máximo 1 en pruebas, etc.), a ese número
de tareas se le llama límite del “work in progress”.
Medir el tiempo en completar una tarea.
El “lead time” cuenta desde que se hace una petición hasta que se hace la entrega.
El “cycle time” mide desde que el trabajo sobre una tarea comienza hasta que termina.
Si con el “lead time” se mide lo que ven los clientes, lo que esperan, y con el “cycle time” se mide más el rendimiento del proceso.
Comparación
entre Scrum y Kanban

Ambos son métodos ligeros menos restrictivos que los métodos tradicionales y muy adaptables.
Estas herramientas no son excluyentes y se pueden mezclar entre sí y con otras herramientas como algunas de las ideas de XP.
Mientras que Scrum prescribe los roles de dueño del producto, equipo y Scrum Master, Kanban no establece ningún rol. Pero existe libertad para añadir los roles que se consideren necesarios.
Scrum está basado en iteraciones de tiempo fijo que determinan la cadencia del proyecto. En una iteración se combinan las actividades de planificación, mejora del proceso y entrega. En Kanban no existen iteraciones, por lo que estas actividades se pueden realizar siguiendo cualquier estrategia.
Kanban limita el número de elementos al mismo tiempo en un estado del flujo de trabajo. En Scrum, el límite es el número de elementos en la pila del producto.
Ambos son empíricos en el sentido de que se espera que experimentes con el proceso y lo adaptes a tu entorno. A este proceso de mejora se le denomina “kaizen” en terminología Lean, y se trata de buscar una realimentación sobre el proceso que de información sobre cómo mejorarlo.
Scrum no permite modificar la pila del sprint durante el mismo, permitiendo al equipo mantenerse enfocado durante un periodo de tiempo suficiente. Kanban, en cambio, permite cambiar los elementos en la entrada del flujo de trabajo siempre que se respete el límte del WIP establecido.
En Scrum, cuando finaliza un sprint, el tablero se limpia y todos los elementos son eliminados. En Kanban, el tablero no se limpia, los elementos simplemente van avanzando a través de las columnas.
En Scrum, el tablero pertenece a un equipo, y un equipo tiene todo el conocimiento necesario para llevar a cabo una iteración. En Kanban el tablero está relacionado con un flujo de trabajo y puede pertenecer a varios equipos de distintas funcionalidades.
En Scrum, si un problema es demasiado grande para caber en un sprint, éste se descompone. En Kanban, aunque es interesante tener elementos pequeños que minimicen el tiempo de entrega, no es obligatorio que estos se ajusten a un intervalo de tiempo específico.
En Scrum, la pila de producto podría completarse con elementos de varios proyectos. Esto mismo, se puede hacer también en Kanban.
Ambos son sistemas de optimización “pull”, basados en procesos de optimización continuos y que priorizan la respuesta al cambio frente al seguimiento de un plan, entre otras características.
Diferencias menos relevantes entre Scrum y Kanban son que Scrum prescribe una pila de producto priorizada, establece reuniones diarias y utiliza gráficos burndown. En Kanban se utilizan diagramas de flujo acumulativo que representan como el WIP afecta al plazo de entrega.
En Scrum los equipos estiman el tamaño relativo de cada elemento al que se comprometen, y sumando el tamaño de cada elemento se obtiene la velocidad. En Kanban no es necesario estimar, pero algunos equipos lo hacen para poder garantizar el tiempo de entrega promedio.
Full transcript