Una introducción a Scrum - Por Jorge Abad

UNA INTRODUCCIÓN A SCRUM

Jorge Hernán Abad Londoñojorge.abad@gmail.com

13/04/2023 2jorge.abad@gmail.com

¿Por que fallan los proyectos?

¿Por qué fallan los suyos?

Estadísticas de Colombia – 2012

PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS

jorge.abad@gmail.com

Causa de Fracasos en los Proyectos

• Cronogramas poco realistas • Personal inadecuado • Cambios en los requerimientos • Trabajo de pobre calidad • Creer en magia

Winning with Software: An Executive Strategy. Watts S. Humphrey

Tipos de proyecto de acuerdo a los requisitos y la tecnología

¿Pregunta?

¿VIAJARÍA USTED EN UN AVIÓN AL QUE USTED LE ESCRIBIÓ EL SOFTWARE

DE NAVEGACIÓN?

Manifiesto ÁgilEstamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientasSoftware funcionando sobre documentación extensivaColaboración con el cliente sobre negociación contractualRespuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,valoramos más los de la izquierda.

http://agilemanifesto.org/iso/es/

Los 12 Principios1. Nuestra mayor prioridad es satisfacer al cliente mediante

la entrega temprana y continua de software con valor.2. Aceptamos que los requisitos cambien, incluso en etapas

tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. 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.

6. 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.

7. El software funcionando es la medida principal de progreso.

Los 12 Principios8. Los procesos Ágiles promueven el desarrollo sostenible. Los

promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10.La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11.Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12.A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Valores• Compromiso• Enfoque y Foco• Apertura y transparencia• Respeto• Coraje

PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS ESPECIALIZACIÓN EN INGENIERÍA DE SOFTWARE – UNIVERSIDAD DE MEDELLÍN

Cambio de Esquema de Negociación

Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series)

Objetivo: Pasar a la otra orilla a

pie sin mojarse (sin usar un

puente, etc, etc.)

Adaptando el plan en vez de adaptarnos al

El espiritu de Scrum. Alan Cyment

13/04/2023 17

Crecimiento orgánico (iterativo e incremental)

Dibujo realizado por Jeff Patton

Una mujer con una pradera atrás

13/04/2023 18

Diferencias entre enfoque iterativo y enfoque orgánico (iterativo e incremental)

Dibujo realizado por Jeff Patton

Cambio de Esquema de Negociación

SCRUM“El Arte de Amar los Lunes”.

Alan Cyment

Estamos perdiendo la carrera de relevos

Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986.

“En enfoque de ‘carrera de relevos’ en el desarrollo de productos ... puede entrar en conflicto con los objetivos de máxima velocidad y flexibilidad. En su lugar, un enfoque holístico o estilo ‘rugby’ - donde un equipo intenta ir a la distancia como una unidad, pasando la pelota hacia adelante y hacia atrás -pueden servir mejor a los actuales requisitos competitivos".

•Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo.

•Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes).

•El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad.

•Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorandolo en otro sprint.

Scrum en 100 palabras

• Scrum es una framework metodológico para la gestión de proyectos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo The New New Product Development Game[Harvard Business Review Ene-Feb 1986] en el que ponen de manifiesto que:o El mercado competitivo de los productos tecnológicos,

además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad.

o Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.

o El mercado exige ciclos de desarrollo más cortos.

Orígenes de Scrum• Jeff Sutherland

o Scrums iniciales en Easel Corp en 1993o IDX 500 personas haciendo Scrum

• Ken Schwabero ADMo Se presenta Scrum en OOPSLA 96 con

Sutherlando Autor de tres libros sobre Scrum

• Mike Beedleo Patrones Scrum en PLOPD4

• Ken Schwaber and Mike Cohno Fundaron conjuntamente la Scrum Alliance en

2002, inicialmente dentro de la Agile Alliance

Scrum ha sido utilizado por:

•Microsoft•Yahoo•Google•Electronic Arts•High Moon Studios•Lockheed Martin•Philips•Siemens•Nokia•Capital One•BBC•Intuit

•Intuit•Nielsen Media•First American Real Estate•BMC Software•Ipswitch•John Deere•Lexis Nexis•Sabre•Salesforce.com•Time Warner•Turner Broadcasting•Oce

Scrum ha sido utilizado para:

• Software comercial • Desarrollos internos• Desarrollos bajo

Contrato• Proyectos Fixed-price• Aplicaciones Financieras• Aplicaciones

certificadas ISO 9001• Sistemas Embebidos• Sistemas con requisitos

7x24 y 99.999% de disponibilidad

• Joint Strike Fighter

•Desarrollo de video juegos

•Sistemas críticos de soporte vital, aprobados por laFDA

•Software de control satelital

•Sitios Web

•Software para Handheld

•Teléfonos portátiles

•Aplicaciones de Network switching

•Aplicaciones de ISV

•Algunas de las más grandes aplicaciones en uso

CaracterísticasEquipos auto-organizadosEl producto avanza en una serie de “Sprints"

de dos semanas a un mes de duraciónLos requisitos son capturados como

elementos de una lista de “Product Backlog"No hay prácticas de ingeniería prescritasUtiliza normas generativas para crear un

entorno ágil para la entrega de proyectosUno de los “procesos ágiles”

CancelGift wrap

Return

Sprint2-4 semanas

Objetivo del Sprint

Sprint Backlog

Incremento del producto potencialmente entregable

ProductBacklog

24 horas

Poniendo todo junto

Imagen disponible en www.mountaingoatsoftware.com/scrum

Sprints• En Scrum los proyectos avanzan en una

serie de “Sprints”o Análogo a las iteraciones en XP

• La duración típica es 2–4 semanas o a lo sumo un mes calendario

• La duración constante conduce a un mejor ritmo

• El product es diseñado, codificado y testeado durante el Sprint

Desarrollo secuencial vs. superpuesto

Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

En lugar de hacer todo de una cosa a la vez ... ...los equipos Scrum

hacen un poco de todo todo el tiempo

Requisitos Diseño Código Test

No hay cambios en un sprint

Planee la duración del sprint en torno a cuánto tiempo usted puede comprometerse a mantener los cambios fuera del sprint

Cambios

Scrum Framework

•Product owner•ScrumMaster•Team

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Reuniones

•Product backlog•Sprint backlog•Burndown charts

Artefactos

Scrum framework

Reuniones

Artefactos

Product OwnerDefine las funcionalidades del producto

Decide sobre las fechas y contenidos de los releases

Es responsable por la rentabilidad del producto (ROI)

Prioriza funcionalidades de acuerdo al valor del mercado/negocio

Ajusta funcionalidades y prioridades en cada iteración si es necesario

Acepta o rechaza los resultados del trabajo del equipo

Product Owner

El ScrumMaster• Representa a la gestión del proyecto

• Responsable de promover los valores y prácticas de Scrum

• Remueve impedimentos

• Se asegura de que el equipo es completamente funcional y productivo

• Permite la estrecha cooperación en todos los roles y funciones

• Escudo del equipo de interferencias externas

El TeamTípicamente de 5 a 9 personasMulti-funcional:

◦ Programadores, testers, analistas, diseñadores, etc.

Los miembros deben ser full-time◦ Puede haber excepciones (Ej.: Infraestructura, SCM,

Los equipos son auto-organizativos

◦ Idealmente, no existen títulos pero a veces se utilizan de acuerdo a la organización

Solo puede haber cambio de miembros entre los sprints

Interacción entre los roles

Fuente: El espiritu de Scrum. Alan Cyment

RolesScrum Framework

Artefactos

Reuniones

Sprint Planning meeting

Priorización

• Analizar y evaluar el Product Backlog

• Seleccionar el objetivo del Sprint

Planificación

• Decidir como alcanzar el objetivo del Sprint (diseño)

• Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog (user stories / features)

• Estimar Sprint Backlog en horas

Objetivo del Sprint

SprintBacklogSprintBacklog

Condiciones del Negocio

Capacidad del Equipo

Product BacklogProduct Backlog

TecnologíaTecnología

Producto ActualProducto Actual

Planificación del Sprint

• El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar

• Se crea el Sprint Backlogo Se identifican tareas y cada una es estimada (1-16 horas)o Realizado colaborativamente, no solo por el ScrumMaster

• El diseño de Alto Nivel es considerado

YO COMO planificador de vacaciones, QUIERO ver fotos de los hoteles. PARA poder mostrar diferentes sitios a mis clientes

Codificar la capa intermedia (8 hs)Codificar la interfaz de usuario (4)Escribir los test fixtures (4)Codificar la clase foo (6)Actualizar test de performance (4)

Daily Scrum

• Parámetroso Diaria

o Dura 15 minutos

o Parados

• No para la solución de problemaso Todo el mundo está invitado

o Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar

o Ayuda a evitar otras reuniones innecesarias

Todos responden 3 preguntas

• No es dar un status report al Scrum Master

• Se trata de compromisos delante de pares

¿Qué hiciste ayer?¿Qué hiciste ayer?11

¿Qué vas a hacer hoy?¿Qué vas a hacer hoy?22

¿Hay obstáculos en tu camino? ¿Hay obstáculos en tu camino?

Sprint reviewEl equipo presenta lo realizado durante

el sprint Normalmente adopta la forma de una

demo de las nuevas características o la arquitectura subyacente

Informal◦ Regla de 2 hs preparación

◦ No usar diapositivas

Todo el equipo participaSe invita a todo el mundo

Sprint retrospective• Periódicamente, se echa un vistazo a lo

que funciona y lo que no • Normalmente 1 hora• Se realiza luego de cada sprint• Todo el equipo participa

o ScrumMaster

o Product owner

o Equipo

o Posiblemente clientes y otros

Start / Stop / Continue• Todo el equipo se reúne y discute lo que les

gustaría :

Comenzar a hacerComenzar a hacer

Dejar de hacerDejar de hacer

Continuar haciendoContinuar haciendo

Esto es sólo una de las muchas maneras de hacer una retrospectiva.

Retrospective• Por lo general se evalua

FelicidadFelicidad

ProductividadProductividad

CalidadCalidad

Esto es sólo una de las muchas maneras de hacer una retrospectiva.

RolesScrum framework

Reuniones

Artefactos

Product Backlog• Los requisitos

• Una lista de todos los trabajos deseados en el proyecto

• Idealmente cada tema tiene valor para el usuarios o el cliente

• Priorizada por el Product Owner

• Repriorizada al comienzo de cada Sprint

• Se aplica PARETO (el 20% de las historias de usuario cumplen con el 80% de las necesidades del P.O.

Este es el product backlogEste es el product backlog

Product Backlog

• Existen técnicas de priorización como:o Visual Story

Mapping, o Minimal Market

Feature, o Impact Mapping

Ejemplo de Product Backlog

Backlog item Estimación

Permitir que un invitado a hacer una reserva. 3

Como invitado, quiero cancelar una reserva. 5

Como invitado, quiero cambiar las fechas de una reserva. 3

Como un empleado de hotel, puedo ejecutar informes de los ingresos por habitación disponible

Mejorar el manejo de excepciones 8

... 30

... 50

Ejemplo de Product Backlog

El objetivo del Sprint• Una breve declaración de cual será el foco del

trabajo durante el sprint

Aplicación con B.Datos

Servicios Financieros

Ciencias Biológicas

Funciones de apoyo técnico necesarios para estudios de genética de poblaciones.

Soportar más indicadores técnicos que la empresa ABC en tiempo real y streaming de datos.

Hacer que la aplicación se ejecute en SQL Server, además de Oracle.

Gestión del Sprint Backlog

Los individuos eligen las tareas El trabajo nunca es asignado

La estimación del trabajo restante es actualizada diariamente

Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog

El trabajo para el Sprint emerge

Si el trabajo no está claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo y subdividirla luego.

Actualizar el trabajo restante a medida de que más se conoce

Ejemplo de Sprint Backlog

TareasTareasCodificar UI

Codificar negocio

Testear negocio

Escribir ayuda online

Escribir la clase foo

Agregar error logging

Ejemplo de Sprint Backlog

Seguimiento• Es recomendable, que el propietario del

producto emplee una hoja de cálculo, alguna herramienta similar, o el soporte de una intranet, para guardar en formato digital la pila del producto.

• Pero no es aconsejable emplearla como base para trabajar sobre ella en la reunión proyectándola sobre la pantalla de la sala.

• Es mucho mejor trabajar y manipular elementos físicos; y usar una pizarra y fichas removibles (adhesivas, con chinchetas o magnéticas).

Tablero de mando - Kanban

Recordemos

Un Sprint Burndown Chart

Tue Wed Thu Fri

TareasTareasCodificar UI

Codificar Negocio

Testear Negocio

Escribir ayuda online

MM MM JJ VV4

Escalabilidad• Normalmente los equipos son de 7 ± 2

personaso La escalabilidad proviene de equipos de equipos

• Factores a tener cuentao Tipo de aplicación

o Tamaño del equipo

o Dispersión del equipo

o Duración del proyecto

• Scrum se ha utilizado en múltiples proyectos de más de 500 personas

Expansión a través de Scrum de scrums

Scrum de scrums de scrums

Scrum of Scrums / Meta-Scrum

13/04/2023 73

Scrum estar acompañado de

buenas prácticas de ingeniería.

Versionone.com

13/04/2023 75

Scrum = reglas + espíritu + buenas prácticas

¿En resumen en qué consiste scrum?

La magia no existe• Ken Schwaber: “En Scrum, un grupo en el que

se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”

• Dan visibilidad y transparencia desde el principio, aunque no resuelven todos los problemas.

• No ser extremista, usar lo que te funcione• Se recomienda primero usar todo, luego hacer

modificaciones. Cuidado con “Scrum but…”

Donde seguir?• www.mountaingoatsoftware.com/scrum

• www.scrumalliance.org

• www.controlchaos.com

• www.scrum.org

• scrumdevelopment@yahoogroups.com

Una lista de lecturas sobre Scrum• Agile and Iterative Development: A Manager’s Guide by

Craig Larman

• Agile Estimating and Planning by Mike Cohn

• Agile Project Management with Scrum by Ken Schwaber

• Agile Retrospectives by Esther Derby and Diana Larsen

• Agile Software Development Ecosystems by Jim Highsmith

• Agile Software Development with Scrum by Ken Schwaber and Mike Beedle

• Scrum and The Enterprise by Ken Schwaber

• User Stories Applied for Agile Software Development by Mike Cohn

• Artículos semanales en www.scrumalliance.org

ANEXOSIntroducción a Agile

El juego de la Estimación

Historias de Usuario

Introducción a Agile

El Manifesto Ágil – una declaración de valores

Procesos y herramientasProcesos y herramientas

Individuos e interaccionesIndividuos e interacciones

Seguimiento de un planSeguimiento de un plan

Responder ante el cambioResponder ante el cambio

Fuente: www.agilemanifesto.org

Documentación exhaustivaDocumentación exhaustiva

Software que funcionaSoftware que funciona

Negociación de contratos Negociación de contratos

Colaboración con el clienteColaboración con el cliente

Algunos principios y valores ágiles

• La prioridad mayor es la satisfacción del cliente haciendo entregas continuas de software valioso para él

• Los cambios son bienvenidos siempre• La medida principal de progreso es el software

funcionando• El gestor es un facilitador no un controlador• Equipos auto-organizados y multidisciplinares• Inspeccionar y adaptar• Mejora continua• Respeto, claridad y comunicación• Ritmo sostenible• La arquitectura y diseño emergen

Ágil no es hacer lo que se quiera

• … ni tampoco programación heroica

La magia no existe• Ken Schwaber: “En Scrum, un grupo en el que

se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”

• Dan visibilidad y transparencia desde el principio, aunque no resuelven todos los problemas.

• No ser extremista, usar lo que te funcione• Se recomienda primero usar todo, luego hacer

modificaciones. Cuidado con “Scrum but…”

El juego de la estimación

Poker Game• Planificación de póquer es una variación del

método Delphi. • Es simple, se burla y los resultados de estim• Planificación de póquer se utiliza para estimar

el esfuerzo o el tamaño relativo de las tareas en el desarrollo de software de manera fiable.

• Los miembros del equipo del proyecto se reúnen y en unas pocas rondas mediante el Poker Game llegan a un consenso sobre el tamaño de cada tema o tarea.

La baraja de Cartas• Cada juevo de cartas incluye

los números 0, (0,5), 1, 2, 3, 5, 8, 13, 20, 40, 100, y, a veces, un café tarjeta.

• Cada miembro del equipo necesita una baraja de cartas

La reunión de planificación (1)

• Al comienzo de la planificación de póquer, cada estimador se le da un mazo de cartas.

• Para cada Historia de Usuario o tema que se va a estimar, un moderador lee la descripción.

• El moderador suele ser el propietario del producto o una analista. Sin embargo, el moderador puede ser cualquier persona, ya que no hay privilegio especial asociado con el papel.

• El Dueño del producto (Product Owner) responde todas las preguntas que tienen los estimadores.

• Después de todas las preguntas cada estimador selecciona una carta de forma secreta e individual.

• Las tarjetas no se muestran hasta que todos hayan hecho su estimación. Luego todos muestran al mismo tiempo la carta elegida

• El grupo puede discutir la historia y sus estimaciones durante unos minutos más. Principalmente se indaga a las personas que están lejanas de la media que explique su posición.

• Tras el debate se hace otra ronda de estimacion en privado.

• Valores altos de tiempo implican o Baja granularidado Alta complejidado se recomienda en lo posible dividir en tareas más pequeñas.

• Si sale (?) Implica que no se tiene idea de que se esta hablando

• Si sale la taza de café, indica que la persona esta casada.

Resultados• En muchos casos, las estimaciones convergen en

la segunda ronda. En caso contrario se debe repetir el proceso.

• El objetivo es converger a una única estimación.

Historia de usuarios

Fuente Wikipedia

Historias de Usuario• Una historia de usuario es una representación de

un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario. Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requerimientos (acompañadas de las discusiones con los usuarios y las pruebas de validación). Cada historia de usuario debe ser limitada, esta debería poderse escribir sobre una nota adhesiva pequeña. Dentro de la metodología XP las historias de usuario deben ser escritas por los clientes.

Historias de Usuario• Las historias de usuario son una forma rápida de

administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rápidamente a los requerimientos cambiantes.

Características• Independientes unas de otras: De ser necesario, combinar las historias

dependientes o buscar otra forma de dividir las historias de manera que resulten independientes.

• Negociables: La historia en si misma no lo suficientemente explícita como para considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación.

• Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos más que para el desarrollador.

• Estimables: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Esto permite estimar el tiempo total del proyecto.

• Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones sobre la planificación de un desarrollo iterativo. Generalmente se recomienda la consolidación de historias muy cortas en una sola historia.

• Verificables: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables. Cuando sea posible, la verificación debe automatizarse, de manera que pueda ser verificada en cada entrega del proyecto.

Características• Si bien el estilo puede ser libre, la historia de

usuario debe responder a tres preguntas: ¿Quién se beneficia?, ¿qué se quiere? y ¿cuál es el beneficio? Por ello, algunos autores[1] recomiendan redactar las historias de usuario según el formato:

• Como (rol) quiero (algo) para poder (beneficio).

• Adicionalmente se debe plasmar los CRITERIOS DE ACEPTACIÓN.

Beneficios• Al ser muy corta esta representa requisitos del

modelo de negocio que pueden implementarse rápidamente (días o semanas)

• Necesitan poco mantenimiento• Mantienen una relación cercana con el cliente• Permite dividir los proyectos en pequeñas

entregas• Permite estimar fácilmente el esfuerzo de

desarrollo• Es ideal para proyectos con requerimientos

volátiles o no muy claros

Limitaciones• Sin pruebas de validación pueden quedar abiertas a distintas

interpretaciones haciendo difícil utilizarlas como base para un contrato

• Se requiere un contacto permanente con el cliente durante el proyecto lo cual puede ser difícil o costoso

• Podría resultar difícil escalar a proyectos grandes• Requiere desarrolladores muy competentes • Sin pruebas de validación pueden quedar abiertas a distintas

interpretaciones haciendo difícil utilizarlas como base para un contrato

• Se requiere un contacto permanente con el cliente durante el proyecto lo cual puede ser difícil o costoso

• Podría resultar difícil escalar a proyectos grandes• Requiere desarrolladores muy competentes

Un enfoque BDD (Behavior Driven Development)

• Title (one line describing the story)• • Narrative:• As a [role]• I want [feature]• So that [benefit]• • Acceptance Criteria: (presented as Scenarios)• • Scenario 1: Title• Given [context]• And [some more context]...• When [event]• Then [outcome]• And [another outcome]...• • Scenario 2: ...

Fuente: http://dannorth.net/whats-in-a-story/

EjemploBDD

• Scenario 1: Account has sufficient funds• Given the account balance is \$100• And the card is valid• And the machine contains enough

money• When the Account Holder requests \$20• Then the ATM should dispense \$20• And the account balance should be \$80• And the card should be returned

• Scenario 2: Account has insufficient funds• Given the account balance is \$10• And the card is valid• And the machine contains enough money• When the Account Holder requests \$20• Then the ATM should not dispense any money• And the ATM should say there are insufficient funds• And the account balance should be \$20• And the card should be returned

Story: Account Holder withdraws cash As an Account HolderI want to withdraw cash from an ATMSo that I can get money when the bank is closed

• Scenario 3: Card has been disabled• Given the card is disabled• When the Account Holder requests \$20• Then the ATM should retain the card• And the ATM should say the card has been retained

Fuente: http://dannorth.net/whats-in-a-story/

Aviso de Copyright• Usted es libre de:

o Compartir- copiar, distribuir y trasmitir el trabajo

o Modificar- adaptar el trabajo

• Bajo las siguientes condicioneso Atribución. Ud. debe atribuir el trabajo en la manera

especificada por el autor o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo).

• Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor.

• Para más información ver http://creativecommons.org/licenses/by/3.0/

Información de Contacto

Presentado por: Mike Cohnmike@mountaingoatsoftware.comwww.mountaingoatsoftware.com(720) 890-6110 (office)

Puede eliminar este (o

cualquier diapositiva), pero

debe dar crédito de la fuente

en algún lugar de su

presentación. Utilizar el

logotipo y el nombre de la

empresa (como en la parte

inferior izquierda, por ejemplo)

o incluir una diapositiva en

algún lugar diciendo que parte

(o todo) de su presentación son

de esta fuente. Gracias.

Tomado de:• Una introducción a Scrum - Ernesto Grafeuille. • Enriquecido y Modificado por: Jorge H. Abad L. –

jorge.abad@gmail.como Blogs:

• http://lecciones-aprendidas.blogspot.com/• http://ing-sw.blogspot.com/

Una introducción a Scrum - Por Jorge Abad

Software

Transcript of Una introducción a Scrum - Por Jorge Abad

Metodología Scrum

Scrum Básico

Metodología scrum

Presentación SCRUM

Curso Scrum con certificación Scrum Manager® curso Scrum...Curso Scrum con certificación Scrum Manager® • Curso basado en ejercicios prácticos y LEGO® • Examen de certificación

PADRON D N I APELLIDO PATERNO APELLIDO …aplicaciones007.jne.gob.pe/srop/Documentos/pafil/1257/1257.pdf · 2. 80399748 abad abad salome s ... 30. 44128151 abad ledesma jorge luis

Scrum, Resumen

Scrum método

Agile Scrum

Gente que hace Scrum sin saber que existe Scrum (Scrum Gathering Bs As 2012)

Scrum de Scrum

Curso Scrum con certificación Scrum Manager® - fidetia.es curso Scrum... · Curso Scrum con certificación Scrum Manager® Temario. Marco Scrum estándar Introducción. Descripción

TRAMO 1 APELLIDOS y NOMBRE AYUDA TRANSPORTE D.N.I. … · 2019. 9. 25. · abad sanchez, jorge abad sanchez, jose luis abad sanseroni, maria isabel abad segura, maria carmen abad

Un resumen sobre contratos ágiles. Por Jorge Abad y Leonardo Agudelo - Agile Contracts

Tesis Jorge Carlos Abad

INFORMACIÓN BÁSICA DE SCRUM - goodagile.com · Certified Scrum Training Worldwide | INFORMACIÓN BÁSICA DE SCRUM (THE SCRUM PRIMER) Por Pete Deemer Gabrielle Benefield Craig Larman

Capacitación scrum

Scrum Agiles2014

Viviendo Scrum

Gerencia deProyectos Ágiles con Scrum Certi cación Scrum ... SCRUM.pdf · Gerencia deProyectos Ágiles con Scrum Certi cación Scrum Master Project Management & Business Consulting