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

Breve descripción de SCRUM.
by

Shadia Nazrala Sabugo

on 9 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of SCRUM

SCRUM
"Estamos descubriendo formas
mejores de desarrollar
software".

Manifiesto por el Desarrollo Ágil de Software (Manifesto Agile)
Valores
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
Principios
Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
¿Qué es SCRUM?
Es un marco de trabajo o framework dentro del cual las personas pueden afrontar problemas complejos, a la vez que entregan productos del máximo valor posible de forma productiva y creativa.

Scrum
no es un proceso
o una técnica para construir productos. Es utilizado normalmente en la gestión y desarrollo de software en el ámbito ágil.
¿En qué consiste SCRUM?
SCRUM consiste en componentes, cada uno con un propósito específico y esencial para lograr el éxito.
Estos componentes son:
Roles:
Eventos:
Product Owner
Scrum Master
Development Team
Increment
Product Backlog
Product Backlog Item
Sprint Backlog
Task
Burndown Chart
Sprint Planing
Daily Scrum
Sprint Review
Sprint Restrospective
Backlog Grooming
ROLES
Product Owner
Artefactos:
Development Team
Es el encargado de gestionar el Product
Backlog, de darle valor/priorizarlo y ver
que el equipo de desarrollo trabaje de forma
adecuada según la perspectiva del negocio.

Debe estar interiorizado en producto
y saber exactamente que es lo que
desean los Stakeholders (clientes).
Única persona responsable de maximizar el retorno de la inversión (ROI) del esfuerzo de desarrollo.
Responsable de la visión del producto
Constantemente re-prioriza el Backlog del Producto, ajustando las expectativas a largo plazo, como los planes de liberaciones.
Es el árbitro final de las preguntas sobre requerimiento.
Acepta o rechaza cada incremento del producto.
Decide si se debe liberar.
Decide si se debe continuar con el desarrollo.
Considera los intereses de los Stakeholders.
Puede contribuir como miembro del equipo.
Tiene un papel de liderazgo.
Características

Sólo los miembros del Equipo de Desarrollo participan en la creación del Incremento.

El Equipo de Desarrollo consta de profesionales que desempeñan el trabajo de entregar un Incremento de producto “Hecho”, potencialmente utilizable, al final de cada Sprint.
Los Equipos de Desarrollo se estructuran y reciben poder por parte de la organización para organizar y gestionar su propio trabajo, esto da como resultado una optimización en la eficiencia y efectividad general
del Equipo de Desarrollo.
Scrum Master
Multifuncional (incluye miembros con habilidades de testing y a menudo otros no llamados tradicionalmente desarrolladores: analistas de negocio, expertos de dominio, etc.).
Auto-organizado/auto-gestionado, sin roles asignados externamente.
Negocia los compromisos con el Product Owner, de un Sprint a la vez.
Tiene autonomía con respecto a la forma de lograr sus compromisos.
Intensamente colaborativo.
Tiene mayor probabilidad de éxito al encontrarse establecido en un mismo lugar, sobre todo para los primeros Sprints.
Tiene más éxito si el involucramiento con el equipo es a largo plazo y full-time. Scrum promueve evitar el traslado de personas o dividirlas entre otros equipos.
7 ± 2 miembros.
Tiene un papel de liderazgo.
Características
Ayuda, a las personas externas al Equipo, a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no, modificando estas interacciones para maximizar el valor creado por el Equipo Scrum.
El Scrum Master es el responsable de asegurar que Scrum es entendido y llevado a cabo, asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum.
Es un líder servil, al servicio del Equipo Scrum.
Se recomienda que el Scrum Master no sea parte del Equipo de Desarrollo, ya que vendría a representar un moderador entre es Equipo
y el Product Owner.
Facilita el proceso de Scrum.
Ayuda a resolver los impedimentos.
Crea un ambiente propicio para la auto-organización del equipo.
Captura datos empíricos para ajustar las previsiones.
Protege al equipo de interferencias externas y distracciones para mantener el flujo del equipo.
Aplica los timeboxes (el tiempo máximo para conseguir un objetivo, tomar una decisión o realizar una tarea).
Mantiene visibles los artefactos Scrum.
Promueve la mejora de las prácticas de ingeniería.
No tiene autoridad en la gestión del equipo (cualquier persona que tenga autoridad sobre el equipo no es, por definición, su ScrumMaster).
Tiene un papel de liderazgo.
Características
Liderar y entrenar a la organización en su adopción de Scrum.
Planificar implementaciones de Scrum en la organización.
Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto.
Causar cambios que incrementen la productividad del Equipo Scrum.
Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.
El Scrum Master y la Organización
El Scrum Master da servicio a la organización de varias formas, incluyendo:
ARTEFACTOS
Lista ordenada de funcionalidad deseada.
Visible para todos los stakeholders.
Cualquier stakeholder (incluido el equipo) puede agregar ítems.
Constantemente re-priorizado por el Product Owner.
Los Ítems superiores son más granulares que los inferiores.
Mantenido durante la reunión de Refinamiento del Backlog.
Product Backlog
Especifica el qué más que el cómo de una característica centrada en
el cliente.
A menudo escrita en forma de Historia de Usuario.
Tiene una definición de “terminado” abarcadora de todo el producto
para evitar la deuda técnica.
Puede tener criterios de aceptación específicos del ítem.
El esfuerzo es calculado por el equipo, de preferencia en unidades
relativas (por ejemplo, puntos de la historia).
El esfuerzo es de aproximadamente 2-3 personas 2-3 días, o menos
para equipos más avanzados.
Product Backlog Item
Consiste en PBIs comprometidos negociados entre el equipo y el Product Owner durante la Reunión de Planificación del Sprint.
El alcance comprometido es fijo durante la ejecución del Sprint.
Las tareas iniciales son identificadas por el equipo durante la reunión de planificación del Sprint.
Referenciado durante la Daily Scrum Meeting
Visible para el equipo.
El equipo descubrirá las tareas adicionales necesarias para cumplir con el compromiso de alcance fijo durante la ejecución de Sprint.
Sprint Backlog
Task
Tarea que especifica cómo alcanzar el qué del PBI.
Requiere aproximadamente un día de trabajo.
El esfuerzo restante se re-estima a diario, por lo general en horas.
Durante la ejecución de Sprint, una persona de contacto puede ofrecerse para ser el principal responsable de una tarea.
Propiedad de todo el equipo, se espera colaboración.
Pila del Sprint
Dueño del Producto
Equipo de Desarrollo
Pila de Productos
Elemento de la Pila de Productos
Tarea
Visualiza el flujo de trabajo
: al separar el trabajo en items, escribir cada item en una tarjeta de la pizarra Kanban y utilizar columnas que ilustran el estado de la tarjeta.
Limita el trabajo en progreso
: es recomendable asignar explicitamente cuantos items podemos tener en cada estado, un estado es una columna de la pizarra de Kanban.
Mide el tiempo de iniciación de un item
: con el objetivo de optimizar ese tiempo.
Kanban
Es un método para gestionar el trabajo con énfasis en la entrega justo a tiempo mientras sin sobrecargar a los miembros del equipo. En pocas palabras:
Kanban Board
Pizarra Kanban
Increment
Incremento/Hecho
Los miembros del Equipo deben tener un entendimiento compartido de lo que significa que el trabajo esté completado, para asegurar la transparencia.
El Equipo de Desarrollo sabrá cuántos elementos del Sprint Backlog pueden seleccionar durante una reunión de Planificación de Sprint, el propósito de cada Sprint es entregar Incrementos de funcionalidad potencialmente utilizable.
Los Equipos de Desarrollo entregan un Incremento de funcionalidad de producto en cada Sprint. Este
Incremento es utilizable
, de modo que el Product Owner podría elegir liberarlo inmediatamente.
Cada Incremento es aditivo a todos los Incrementos anteriores y es exhaustivamente probado, asegurando que todos los Incrementos funcionan en conjunto.
Burndown Chart
Indica el total de horas restantes de las tareas del equipo dentro de un Sprint.
Re-estimado a diario, por lo tanto puede subir antes de bajar.
Diseñado para facilitar la auto-organización del equipo.
Algunas variaciones, como agrupar por persona de contacto o agregando tendencias, tiende a reducir su efectividad para fomentar la colaboración.
Parecía una buena idea en los primeros días de Scrum, pero en la práctica ha sido a menudo mal utilizada como un informe de gestión, invitando a la intervención. El Scrum Master debe descontinuar el uso de esta tabla si se convierte en un impedimento para la autoorganización del equipo.
EVENTOS
Flujo de los Eventos o Reuniones en SCRUM
Al comienzo de cada Sprint, el Product Owner y el equipo tienen
una Reunión de Planificación del Sprint donde negocian qué ítems
del Product Backlog intentarán convertir en producto funcionando
durante el Sprint.
Sprint Planning
Planificación del Sprint
El Product Owner es el responsable de declarar cuáles son los ítems más importantes para el negocio. El equipo es responsable de seleccionar la cantidad de trabajo que cree que podrán realizar sin acumular deuda técnica. El equipo "toma" el trabajo desde el Product Backlog hacia el Sprint Backlog.
Hacia el final de la Reunión de Planificación del Sprint, el equipo desglosa los ítems seleccionados en una lista inicial de tareas del Sprint (Sprint Tasks) y hace un compromiso final para realizar el trabajo.
El tiempo máximo asignado (también conocido como timebox) para la planificación de un Sprint de 30 días, es de ocho horas, reducido proporcionalmente en caso de un Sprint más corto.
Resultado del Sprint Planning
Daily Scrum
Reunión Diaria
Cada día, a la misma hora y en el mismo lugar
, los miembros del equipo de desarrollo pasan
15 minutos
reportándose entre sí. Cada miembro del equipo resume lo que hizo el día anterior, lo que hará hoy, y qué impedimentos está enfrentando.
Mantenerse de pie
en el Daily Scrum ayudará a que sea breve. Los temas que requieren atención adicional pueden ser discutidos por los interesados después de que cada miembro del equipo haya reportado.
Durante la ejecución del Sprint es común descubrir
tareas adicionales
necesarias para alcanzar las metas del Sprint.
Sprint Review
Revisión del Sprint
Después de la ejecución del Sprint, el equipo mantiene una reunión de revisión del Sprint para
mostrar un incremento
del producto al Product Owner y a todos los demás interesados.
La reunión debe ofrecer una demostración en vivo, no un informe.
Después de la demostración, el Product Owner revisa los compromisos contraídos en la Reunión de Planificación del Sprint y declara qué ítems considera terminados.
El ScrumMaster ayuda al Product Owner y a los stakeholders a convertir su feedback en los nuevos Ítems del Product Backlog o Product Backlog Items (PBIs) para su priorización por el Product Owner.
Es la oportunidad de revisar y adaptar el producto a medida que emerge, y de forma iterativa refinar la comprensión de cada uno de los requisitos
Sprint Retrospective
Retrospectiva del Sprint
Cada Sprint finaliza con una retrospectiva.
En esta reunión, el equipo
reflexiona
sobre su propio proceso.
Inspeccionan
su comportamiento en cuanto a personas, relaciones, procesos y herramientas.
Una retrospectiva en profundidad requiere de un ambiente de
seguridad
psicológica que no se encuentra en la mayoría de las organizaciones. Sin seguridad, la discusión retrospectiva o bien evitará los problemas incómodos, o se deteriorará en la culpa y la hostilidad.
El ScrumMaster debe utilizar una variedad de técnicas para facilitar retrospectivas, incluyendo la redacción en silencio, líneas de tiempo, e histogramas de satisfacción.
Se debe
identificar
y ordenar los elementos más importantes que fueron bien, y posibles mejoras, así también crear un plan para implementar las mejoras para la forma en la que el Equipo Scrum desempeña su trabajo
Backlog Grooming
Refinamiento de la Pila de Productos
La mayoría de los PBIs inicialmente deben refinarse, ya que son grandes y poco comprendidos. Los equipos han encontrado útil tomar un tiempo de la ejecución de cada Sprint para preparar el Product Backlog para la próxima Sprint Planning.
En la reunión de refinamiento del Backlog, el equipo estima la cantidad de esfuerzo que se debe invertir para completar los Ítems del Backlog del Producto y proporciona información técnica para ayudar al Product Owner a priorizarlos.
Es común escribir los PBIs en forma de Historias de Usuario4. En este enfoque, los PBIs de gran tamaño son llamados Epics.
La agilidad requiere aprender a dividir las Historias de Usuario que representan características más pequeñas del producto.
Practicas De Programación Recomendadas
Para acompañar este framework ágil se recomienda tomar en cuenta el uso de prácticas como ser
TDD
(Test-Driven Development) que involucra el escribir las pruebas primero y el uso de la
Refactorización
. Realizar
integración continua
para evitar fallos lo antes posible y se posible (o necesario) el uso del
Pair Programming
(programación en pares) para obtener mas disciplina, mejor código, flujo de trabajo constante entre otras ventajas que ofrece esta técnica.
Herramientas
No existe una herramienta que represente este framework en su totalidad, pero si existen herramientas que ayudan a gestionar los artefactos del Scrum (product backlog, sprint backlog, etc.) .
Algunas de estas herramientas son:
On Time
Team Foundation Server (con scrum template)
Clarize
Kanbanpad
IceScrum
ScrumDo
Trello
Kunagi
Gracias
Bibliografía
http://agilemanifesto.org/
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide%202011%20-%20ES.pdf
http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm

Páginas:
Videos:
Aprende SCRUM en menos de 10 Min : Walter Colchado.
Tutoriales de Scrum: "Manifiesto Ágil - Valores : Ruta N.
Kleer - Principios Ágiles : Pablo Tortorella.
Kleer - Scrum : Martin Alaimo.
Prácticas y Herramientas Recomendadas
Full transcript