An evening with… ScrumArkho Innova Meetup series

August 2017

• Un espacio para compartir experiencias y conocimiento • Un espacio para hacer relaciones entre personas y

equipos con intereses afines • Un espacio para pasarla bien

Gracias por su asistencia!!!

ARKHO Innova Meetup series

¿Qué es Scrum?

¿Qué es Scrum?

• Es un framework que especifica el proceso de desarrollo dentro las metodologías ágiles

• Utiliza un paradigma incremental

• Replantea la forma tradicional de desarrollo de software, concentrándonos en los resultados mas que en la formalidad.

• El objetivo es la calidad y la productividad

• Se definen nuevos roles que en otras metodologías no existen, pero que ayudan a controlar y llevar a cabo el proceso sin mayores problemas

• Scrum Busca el rápido desarrollo, entrega y corrección (FAIL FAST)

Scrum

Es un framework o una especificación ?

Roles ScrumSCRUM

Scrum Master

• El rol del Scrum Master es llevar al éxito del desarrollo de cada Sprint. Es como un director o un coach del equipo de desarrollo

• Entre sus responsabilidades están:

• Liderazgo

• Facilitar que las tareas se cumplan.

• Elimina los obstáculos que se puedan producir en el proceso

• Ayuda a adoptar y organizar el proceso Scrum

Product Owner

• Es el dueño del producto que se va a desarrollar y dueño del product Backlog

• Entre sus responsabilidades están:

• Conocimiento del dominio de negocio

• Conocimiento del negocio y sus necesidades

• Recopilar las prioridades del negocio para organizar el product backlog

• Intermediario entre el equipo y los Stakeholders

• Debe tener cierto conocimiento técnico

Equipo Scrum

• Encargado de ejecutar los incrementos planificados dentro del Sprint.

• Ellos son dueños del Sprint Backlog

• Responsabilidades del Equipo:

• Tener un objetivo común

• Buscar la mejor de ejecutar el Sprint

• Avisar oportunamente cualquier problema que obstaculice el avance del sprint

• Sprint Backlog

Stakeholders

• Los Stakeholders son otros roles que tienen relación con el proceso pero que no tienen influencia en su funcionamiento

• Stakeholders son personas que tienen conocimiento del dominio y que también se ven beneficiados del producto que se esta desarrollando

• Es responsabilidad del Product Owner la comunicación con ellos

• Producen el Backlog de producto

Proceso y ArtefactosSCRUM

Sprint

Product Backlog• Pila de requerimientos

• Ordenados por prioridad

• Es único en el proyecto no existe otro.

• El dueño del product Backlog es el product Owner

• Tiene todos los derechos sobre el backlog

• El consumo del backlog se hace a través de grupos de requerimientos llamados Sprint

• Los requerimientos se generan a través de User Stories

Sprint Backlog

• Es un subconjunto de requerimientos del Product backlog

• Son los requerimientos que se van a ejecutar para producir un incremento y generar un producto potencialmente funcional

• Este subconjunto se ejecuta dentro de un ciclo llamado Sprint.

Sprint Planning• Se define su duración, la que podría ser de 1 a 4

semanas

• En este punto se definen las historias necesarias desde el backlog para completar una funcionalidad potencialmente entregable.

• Se define que funcionalidad se debe completar en ese periodo de tiempo, y la cual es una pieza potencialmente productiva.

• Otra actividad que se debe lograr es estimar las historias en unidades de complejidad, llamadas story points.

Daily Scrum Meeting

Objetivo: Responder 3 simples preguntas:

• ¿Qué hice ayer?

• ¿Qué tareas voy a hacer hoy?

• ¿Qué problemas tengo para resolverlas?

Resumen

User Stories & ReleasesSCRUM

User Story

• Es una narración de una necesidad o requerimiento desde el punto de vista de un usuario • Una historia de usuario no debe estar redactada desde el punto técnico. Debe ser comprensible por parte

de un usuario común y corriente.

• Una buena historia debería cumplir con: ★ Independiente: Evitar la interdependencia de historias ★ Comprobable: las condiciones de satisfacción deben estar presentes ★ Valorable: Es decir tengan valor para el usuario ★ Estimable: Si no se cumple con esta condición quizá estamos frente a una Epic ★ Verificable: En cada entrega del proyecto

https://www.mountaingoatsoftware.com/agile/user-stories

Redacción de una historia de Usuario

Según la definición de Mike Cohn:

As a < type of user >, I want < some goal > so that < some reason >.

Interpretación:

Como un <Usuario o Rol>, Quiero <Objetivo> de manera que <Justificación>

EJ:

• Como Cliente quiero poder seleccionar los productos en la pagina para poder comprarlos online

• Como Cliente, quiero pagar mi suscripción mensual vía sitio web por medio de transferencia bancaria o tarjeta de crédito.

http://www.pmoinformatica.com/2015/05/historias-de-usuario-ejemplos.html

Historias Épicas (Epics Stories)

• Son historias grandes, que en su narrativa implican varias funcionalidades que pueden ser descritas en 2 o mas User Stories.

• Poseen un nivel de detalle muy general y son difíciles de estimar por que podrían tomar mucho tiempo al equipo • Son difíciles de encontrar por que pueden abarcar varias dimensiones • Por ser historias con nivel general estas se pueden subdividir en varias historias que cumplan con las

características de una buena historia. • EJ:

Como Vicepresidente de mercadeo y ventas, quiero revisar el desempeño histórico de las ventas, para poder identificar las regiones geográficas y productos de mejor desempeño

Esta historia épica se puede subdividir en: • Como VP de Mercadeo, quiero seleccionar el período de tiempo en el cual realizaré la revisión de las ventas. • Como VP de Mercadeo, puedo clasificar la información de ventas por región geográfica y productos.

Tareas

• Una historia de usuario esta compuesta de una o varias tareas.

• Una tarea es la realización de una actividad concreta para satisfacer la necesidad que especifica la historia de usuario.

• Para completar un User Story se deben seguir una secuencia de tareas.

• Las tareas deben ser medibles.

Releases

• Definición: Un Release es una entrega de un producto o incremento funcional totalmente terminado

• Un release puede estar compuesto por uno o varios Sprint

• Tiene una fecha de entrega en la cual el Usuario final Product Owner y Stakeholders dan revisan y aprueban la funcionalidad

• Todos los sprint deben planificarse en función del tiempo comprometido para la entrega del release

Relación

An evening with … ScrumArkho Innova Meetup series

August 2017