Documentos de Académico
Documentos de Profesional
Documentos de Cultura
09/08/2014
jorge.abad@gmail.com 2
Estadísticas de Colombia – 2012
09/08/2014
jorge.abad@gmail.com 6
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?
http://agilemanifesto.org/iso/es/
http://agilemanifesto.org/iso/es/
jorge.abad@gmail.com
Los 12 Principios
8. 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.
http://agilemanifesto.org/iso/es/
jorge.abad@gmail.com
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 09/08/2014
jorge.abad@gmail.com 12
SOFTWARE – UNIVERSIDAD DE
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.)
09/08/2014
jorge.abad@gmail.com 14
Lacey, Mitch. The Scrum Field Guide: Practical
Advice for Your First Year (Agile Software
Development Series)
jorge.abad@gmail.com
Adaptando el plan en vez
de adaptarnos al plan
El espiritu de Scrum.
Alan Cyment
09/08/2014
jorge.abad@gmail.com 16
Crecimiento orgánico
(iterativo e incremental)
Una mujer
con una
Dibujo realizado por Jeff Patton
pradera
atrás
09/08/2014 17
Diferencias entre enfoque iterativo y
enfoque orgánico (iterativo e
incremental)
09/08/2014 18
Cambio de Esquema de Negociación
Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your
First Year (Agile Software Development Series)
SCRUM
“El Arte de Amar los Lunes”.
Alan Cyment
Estamos perdiendo la carrera
de relevos
“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".
Hirotaka Takeuchi and Ikujiro Nonaka,
“The New New Product Development
Game”, Harvard Business Review, January
1986.
jorge.abad@gmail.com
Scrum en 100 palabras
• 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.
jorge.abad@gmail.com
SCRUM
• 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.
jorge.abad@gmail.com
Orígenes de Scrum
• Jeff Sutherland
o Scrums iniciales en Easel Corp en 1993
o IDX 500 personas haciendo Scrum
• Ken Schwaber
o ADM
o Se presenta Scrum en OOPSLA 96 con
Sutherland
o Autor de tres libros sobre Scrum
• Mike Beedle
o Patrones Scrum en PLOPD4
• Ken Schwaber and Mike Cohn
o Fundaron conjuntamente la Scrum Alliance en
2002, inicialmente dentro de la Agile Alliance
jorge.abad@gmail.com
Scrum ha sido utilizado por:
•Microsoft •Intuit
•Yahoo •Nielsen Media
•Google •First American Real Estate
•Electronic Arts •BMC Software
•High Moon Studios •Ipswitch
•Lockheed Martin •John Deere
•Philips •Lexis Nexis
•Siemens •Sabre
•Nokia •Salesforce.com
•Capital One •Time Warner
•BBC •Turner Broadcasting
•Intuit •Oce
jorge.abad@gmail.com
Scrum ha sido
• Software comercial
utilizado para:
• Desarrollo de video juegos
• Desarrollos internos • Sistemas críticos de soporte
• Desarrollos bajo Contrato
vital, aprobados por laFDA
• Proyectos Fixed-price • Software de control satelital
• Aplicaciones Financieras • Sitios Web
• Aplicaciones certificadas • Software para Handheld
ISO 9001 • Teléfonos portátiles
• Sistemas Embebidos
• Aplicaciones de Network
• Sistemas con requisitos switching
7x24 y 99.999% de
disponibilidad • Aplicaciones de ISV
• Joint Strike Fighter • Algunas de las más grandes
aplicaciones en uso
jorge.abad@gmail.com
Características
Equipos auto-organizados
El producto avanza en una serie de
“Sprints" de dos semanas a un mes de
duración
Los requisitos son capturados como
elementos de una lista de “Product
Backlog"
No hay prácticas de ingeniería prescritas
Utiliza normas generativas para crear un
entorno ágil para la entrega de proyectos
Uno de los “procesos ágiles”
jorge.abad@gmail.com
Scrum
24 horas
Sprint
2-4 semanas
Objetivo del Sprint
Sprint
Incremento del producto
Return Backlog
potencialmente entregable
Gift wrap
Cancel
Product
Backlog
jorge.abad@gmail.com
Poniendo todo junto
Imagen disponible en
www.mountaingoatsoftware.com/scrum
jorge.abad@gmail.com
Sprints
• En Scrum los proyectos avanzan en una
serie de “Sprints”
o Análogo a las iteraciones en XP
jorge.abad@gmail.com
Desarrollo secuencial vs.
superpuesto
Requisitos Diseño Código Test
jorge.abad@gmail.com
Scrum Framework
Roles
•Product owner
•ScrumMaster
•Team Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts jorge.abad@gmail.com
Scrum framework
Roles
•Product owner
•ScrumMaster
•Team Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
jorge.abad@gmail.com
jorge.abad@gmail.com
jorge.abad@gmail.com
Product Owner
Define 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
jorge.abad@gmail.com
Product Owner
El espiritu de Scrum.
Alan Cyment
jorge.abad@gmail.com
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
jorge.abad@gmail.com
El Team
Típicamente de 5 a 9 personas
Multi-funcional:
◦ Programadores, testers, analistas, diseñadores, etc.
jorge.abad@gmail.com
Interacción entre los roles
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
jorge.abad@gmail.com
Capacidad
Sprint Planning meeting
del Equipo
Priorización
• Analizar y evaluar el Product
Objetivo
Product
Backlog
del
Backlog Sprint
• Seleccionar el objetivo del Sprint
Condicione
s del Planificación
Negocio
• Decidir como alcanzar el
objetivo del Sprint (diseño)
Producto
• Crear el Sprint Backlog (tareas) Sprint
Actual
en base a los temas del Product Backlog
Backlog (user stories / features)
• Estimar Sprint Backlog en horas
Tecnología
jorge.abad@gmail.com
Planificación del Sprint
• El equipo selecciona los temas a partir del Product
Backlog que pueden comprometerse a completar
• Se crea el Sprint Backlog
o 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 Codificar la capa intermedia (8
de vacaciones, QUIERO hs)
ver fotos de los Codificar la interfaz de usuario
hoteles. PARA poder (4)
mostrar diferentes Escribir los test fixtures (4)
sitios a mis clientes Codificar la clase foo (6)
Actualizar test de performance (4)
jorge.abad@gmail.com
Daily Scrum
• Parámetros
o Diaria
o Dura 15 minutos
o Parados
jorge.abad@gmail.com
Todos responden 3
preguntas 1
¿Qué hiciste ayer?
2
¿Qué vas a hacer hoy?
3
¿Hay obstáculos en tu camino?
• No es dar un status report al Scrum Master
• Se trata de compromisos delante de pares
jorge.abad@gmail.com
Sprint review
El 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
jorge.abad@gmail.com
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
jorge.abad@gmail.com
Start / Stop / Continue
• Todo el equipo se reúne y discute lo que les
gustaría :
Comenzar a hacer
Dejar de hacer
Esto es sólo una
de las muchas
maneras de Continuar haciendo
hacer una
retrospectiva.
jorge.abad@gmail.com
Retrospective
• Por lo general se evalua
Felicidad
Productividad
Esto es sólo una
de las muchas
maneras de Calidad
hacer una
retrospectiva.
jorge.abad@gmail.com
Roles
Scrum framework
•Product owner
•ScrumMaster
•Team Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
jorge.abad@gmail.com
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
backlog
jorge.abad@gmail.com
Product
Backlog
• Existen técnicas de
priorización como:
o Visual Story Mapping,
o Minimal Market
Feature,
o Impact Mapping
Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your
First Year (Agile Software Development Series) 09/08/2014
jorge.abad@gmail.com 53
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
3
una reserva.
Como un empleado de hotel, puedo ejecutar
informes de los ingresos por habitación 8
disponible
Mejorar el manejo de excepciones 8
... 30
... 50
jorge.abad@gmail.com
Ejemplo de Product
Backlog
jorge.abad@gmail.com
El objetivo del Sprint
• Una breve declaración de cual será el foco del
trabajo durante el sprint
Ciencias Biológicas
Funciones de apoyo técnico
Aplicación con B.Datos
necesarios para estudios de
genética de poblaciones.
Hacer que la aplicación se
ejecute en SQL Server, además
de Oracle. Servicios Financieros
jorge.abad@gmail.com
Ejemplo de Sprint Backlog
Tareas L M M J V
Codificar UI 8 4 8
Codificar negocio 16 12 10 4
Testear negocio 8 16 16 11 8
Escribir ayuda online 12
Escribir la clase foo 8 8 8 8 8
Agregar error logging 8 4
jorge.abad@gmail.com
Ejemplo de Sprint
Backlog
jorge.abad@gmail.com
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).
jorge.abad@gmail.com
Tablero de mando - Kanban
Recordemos
Un Sprint Burndown Chart
Hours
jorge.abad@gmail.com
Tareas L M M J V
Codificar UI 8 4 8
Codificar Negocio 16 12 10 7
Testear Negocio 8 16 16 11 8
Escribir ayuda online 12
50
40
30
20
Hours
10
0
Mon Tue Wed Thu Fri
jorge.abad@gmail.com
Escalabilidad
• Normalmente los equipos son de 7 ± 2
personas
o La escalabilidad proviene de equipos de equipos
jorge.abad@gmail.com
Expansión a través de
Scrum de scrums
jorge.abad@gmail.com
Scrum de scrums de scrums
jorge.abad@gmail.com
Scrum of Scrums / Meta-
Scrum
Scrum
jorge.abad@gmail.com
Scrum estar acompañado
de buenas prácticas de
ingeniería.
09/08/2014 73
Versionone.com
¿En resumen en qué
consiste scrum?
El espiritu de Scrum.
Alan Cyment
09/08/2014 75
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…”
jorge.abad@gmail.com
Donde seguir?
• www.mountaingoatsoftware.com/scrum
• www.scrumalliance.org
• www.controlchaos.com
• www.scrum.org
• scrumdevelopment@yahoogroups.com
jorge.abad@gmail.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
jorge.abad@gmail.com
ANEXOS
Introducción a Agile
El juego de la Estimación
Historias de Usuario
Introducción a Agile
jorge.abad@gmail.com
El Manifesto Ágil – una
declaración de valores
Individuos e Procesos y
sobre
interacciones herramientas
Software que Documentación
sobre
funciona exhaustiva
Colaboración Negociación de
sobre
con el cliente contratos
Responder Seguimiento
sobre
ante el cambio de un plan
Fuente: www.agilemanifesto.org
jorge.abad@gmail.com
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
jorge.abad@gmail.com
Ágil no es hacer lo que se
quiera
• … ni tampoco programación heroica
jorge.abad@gmail.com
jorge.abad@gmail.com
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…”
jorge.abad@gmail.com
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.
jorge.abad@gmail.com
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
jorge.abad@gmail.com
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.
jorge.abad@gmail.com
La reunión de
planificación (2)
• 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.
jorge.abad@gmail.com
La reunión de
planificación (3)
• Valores altos de tiempo implican
o Baja granularidad
o Alta complejidad
o se recomienda en lo posible dividir en tareas más pequeñas.
jorge.abad@gmail.com
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.
jorge.abad@gmail.com
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.
jorge.abad@gmail.com
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.
jorge.abad@gmail.com
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.
jorge.abad@gmail.com
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:
jorge.abad@gmail.com
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
jorge.abad@gmail.com
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
jorge.abad@gmail.com
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/
09/08/2014
jorge.abad@gmail.com 104
Ejemplo Story: Account Holder withdraws cash
As an Account Holder
09/08/2014
jorge.abad@gmail.com 105
Aviso de Copyright
• Usted es libre de:
o Compartir- copiar, distribuir y trasmitir el trabajo
o Modificar- adaptar el trabajo
jorge.abad@gmail.com
Información de Contacto
Presentado por: Mike Cohn
mike@mountaingoatsoftware.com
www.mountaingoatsoftware.com
(720) 890-6110 (office)
jorge.abad@gmail.com
Tomado de:
• Una introducción a Scrum - Ernesto Grafeuille.
• Enriquecido y Modificado por: Jorge H. Abad L. –
jorge.abad@gmail.com
o Blogs:
• http://lecciones-aprendidas.blogspot.com/
• http://ing-sw.blogspot.com/
jorge.abad@gmail.com