CURSO SCRUM:
“DESARROLLO ÁGIL DE PROYECTOS”
1.1. Definición e Historia de Scrum
1.1.1
Definición
Es un marco de trabajo ágil iterativo e incremental en donde cada periodo de
tiempo (Sprint) determinado por el equipo, se entrega un incremento funcionando
que brinde valor al cliente.
1.1.2
Historia
La historia de Scrum se puede rastrear desde 1986 en un artículo de la revista
Harvard Business Review, “El nuevo juego para el desarrollo de productos”
realizado por Hirotaka Takeuchi y Ikujiro Nonaka. En el cual describen que
empresas como Honda, Canon y Fuji-Xerox producen nuevos productos a nivel
mundial utilizando un enfoque escalable y basado en equipos integrales autoorganizados para el desarrollo de productos.
Desde 1993 es utilizado Scrum para trabajar con proyectos de desarrollo de
software, en dicho año Jeff Sutherland y su equipo en Easel Corporation crearon el
proceso de Scrum para ser utilizado en los procesos de desarrollo de software. El
12 de febrero de 2001 se reunió con otros críticos de modelos de mejora de
desarrollo de software basados en procesos: Ken Schwaber, Mike Beedle, Kent
Beck entre otros para consolidar la experiencia y ahí surge la definición de Métodos
ágiles y el Manifiesto Ágil, el cual que especifica los valores y principios por los
cuales se rige Scrum.
2
1.2 Principios de Scrum
 Valorar más a los individuos y sus interacciones que a los procesos y las
herramientas:
Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben
adaptarse a nuestros clientes, a los equipos y a las personas; Con cambios tan
rápidos que se dan en todos los ámbitos, es innegable que los procesos y
herramientas en una organización competitiva deban cambiar ágilmente.
Para ello, es vital primeramente que las personas propongan iniciativas de
cambio o se adapten rápidamente al mismo. Por ello contamos con un equipo
altamente proactivo para propiciar la innovación.
 Valorar más el software funcionando que la documentación exhaustiva:
Poder ver anticipadamente cómo se comportan las funcionalidades
esperadas sobre prototipos o sobre las partes ya elaboradas del sistema final
ofrece una retroalimentación muy estimulante y enriquecedora que genera
ideas imposibles de concebir en un primer momento; difícilmente se podrá
conseguir un documento que contenga requisitos detallados antes de
comenzar el proyecto.
Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y
generación de valor que se logra con la comunicación directa entre las
personas y a través de la interacción y con prototipos. Por eso, siempre que
sea posible debe preferirse, reducir al mínimo indispensable el uso de
documentación, que genera trabajo que no aporta un valor directo al
producto. Se requiere únicamente la documentación necesaria para entregar
valor.
 Valorar más la colaboración con el cliente que la negociación contractual:
Las prácticas ágiles están especialmente indicadas para productos difíciles de
definir con detalle en el principio, o que si se definieran así tendrían al final
menos valor que si se van enriqueciendo con retroalimentación continua
durante el desarrollo. También para los casos en los que los requisitos van a
ser muy inestables por la velocidad del entorno de negocio.
Para el desarrollo ágil el valor del resultado no es consecuencia de haber
controlado una ejecución conforme a procesos, sino de haber sido
implementado directamente sobre el producto. Un contrato no aporta valor
al producto. Es una formalidad que establece líneas divisorias entre
responsabilidades.
En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y
colabora en el grupo de trabajo.
3
 Valorar más la respuesta ante el cambio que seguir un plan:
Para un modelo de desarrollo que surge de entornos que tienen como factor
inherente el cambio y la evolución rápida y continua, resulta mucho más
valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de
planes preestablecidos. Los principales valores de la gestión ágil son la
anticipación y la adaptación; diferentes a los de la gestión de proyectos
ortodoxa: planificación y control para evitar desviaciones sobre el plan.
1.3Valores de Scrum





Compromiso de hacer el máximo esfuerzo posible y ser completamente
transparentes en el progreso de un Sprint.
Enfoque en los objetivos.
Apertura al cambio y a los retos.
Respeto.
Empuje para hacer lo correcto.
4
1.4 . Beneficios de Scrum
•
Flexibilidad a cambios:
Gran capacidad de reacción ante los cambiantes requerimientos
generados por las necesidades del negocio, el cliente o la evolución del
mercado.
•
Reducción del Time to Market:
El cliente puede empezar a utilizar las características más importantes
del proyecto antes de que esté completamente terminado.
•
Mayor productividad:
Se logra, entre otras razones, debido a la eliminación de la burocracia y la
motivación del equipo proporcionado por el hecho de que pueden
estructurarse de manera autónoma.
•
Maximiza el retorno de la inversión (ROI):
Creación de software solamente con las prestaciones que contribuyen a
un mayor valor de negocio gracias a la priorización por retorno de
inversión.
•
Predicciones de tiempos:
5
A través de este marco de trabajo se conoce la velocidad media del
equipo por sprint, con lo que es posible estimar de manera fácil cuando
se podrá hacer uso de una determinada funcionalidad que todavía está
en el Backlog.
1.5. Roles y Responsabilidades
1.5.1
Product Owner
El Product Owner es un actor clave en el desarrollo de un proyecto. Una de sus
responsabilidades es tener una visión de lo que desea construir, y transmitir esa
visión a todo el equipo.
Esto es clave para iniciar con éxito cualquier proyecto ágil de desarrollo de
software. El Product Owner hace esto (en parte) a través del Product Backlog que
es una lista priorizada de características del producto.
El rol del Product Owner lo debe asumir una persona del lado del negocio con
ciertas habilidades y características, incluyendo disponibilidad, la comprensión del
negocio y habilidades de comunicación:



1.5.2
El Product Owner necesita estar disponible para su equipo.
Es quien toma las decisiones de las características que el producto
tendrá y aprobará las entregas realizadas por el equipo de desarrollo
en cada Sprint
El rol del Product Owner requiere trabajar de forma muy cercana con
las principales partes interesadas (en la organización y más allá de
ella), así él o ella será capaz de comunicar diferentes mensajes a
diferentes personas acerca del proyecto en todo momento.
Equipo Scrum
El Equipo Scrum se conforma por un Scrum Master (líder del equipo), un Business
Analyst, Desarrolladores, Líder técnico, Diseñador UX / UI y Testers altamente
especializado en sus rol y responsabilidades, los cuales trabajan colaborativamente
para entregar los incrementos de proyectos solicitados (Sprints) y altamente
comprometidos con nuestros clientes.
Características de un equipo Scrum:
 Los miembros del equipo siguen las mejores prácticas, principios y valores de
desarrollo ágil.
 El equipo de Scrum en su totalidad es responsable de la entrega.
 El Equipo Scrum está altamente capacitado para desempeñar sus funciones.
6




Funciona de la forma más autónoma posible.
El Equipo Scrum es auto-organizado y auto-motivado.
Las habilidades dentro del equipo Scrum son equilibradas.
Las personas dentro del Scrum Team trabajan a tiempo completo al proyecto.
7
1.6 . Ceremonias Scrum
Ceremonia
Objetivo
Participantes
Duración
Cuando
sucede
1. Sprint Drafting
El Product Owner presenta
al equipo el producto
Backlog
Equipo
desarrollo y
Product
Owner
de 1 a 3
horas
2 semanas
antes del
inicio del
Sprint
2. Sprint White Boarding
Revisar las épicas con el
Diseñador UX / UI los
nuevos prototipos
correspondientes o en su
caso cambios en el diseño
del producto.
Equipo
desarrollo y
Product
Owner
De 30
minutos a
2 horas
Seguido del
Sprint
Drafting
3. Designs Review
Obtener la aprobación del
diseño UX/UI presentado al
Product Owner respecto a
las épicas del Sprint.
Equipo
desarrollo y
Product
Owner
De 30 min
a 2 horas
Seguido del
Sprint White
Boarding
4. Sprint Refinement
Refinar las US para obtener
el pre-estimado a bajo nivel
y la identificación de las
subtareas.
Equipo
desarrollo y
Product
Owner
De 30
minutos a
1 hora
3 o 4 días
antes del
inicio del
Sprint
5. Sprint Planning
Determinar el inicio y fin del Equipo
Sprint y su alcance de
desarrollo
acuerdo a la capacidad del
Scrum Team, cada miembro
del equipo cuál elige las
tareas a realizar de acuerdo
a la capacidad de trabajo, si
el esfuerzo a invertir supera
De 30
minutos a
1 hora
Posterior al
Sprint
Refinement
8
Marca el
inicio de un
Sprint
dicha capacidad las US que
excedan quedaran excluidas
del alcance del Sprint.
6. Daily Stand Up
Meeting
Coordination
Es una reunión de
planeación diaria para que
el equipo se coordine para
trabajar.
Equipo de
Desarrollo
15
minutos
Diariamente
7. Sprint Completion
Status Review
Revisar la completitud del
Sprint.
Equipo de
Desarrollo
30
minutos
2 días antes
del Sprint
Review
8. Sprint Review
(Demo)
Realizar la demostración de
la funcionalidad del Sprint al
Product Owner para
obtener la aprobación del
Sprint.
Equipo de
Desarrollo y
Product
Owner
30
minutos
El último día
del Sprint
9. Sprint
Retrospective
Realizar la retrospectiva
sobre el Sprint.
Equipo de
Desarrollo
30
minutos
Después de
del Sprint
Review
1.7¿Por qué usamos Scrum?
Los modelos de negocio se están transformando. La tecnología no sólo inventa nuevos
modelos, sino que está dando la vuelta literalmente a sectores muy tradicionales como
los son los medios de pago.
En este escenario, uno de los mayores retos en NetPay es ser capaces de adaptarnos al
cambio. Scrum, viene a satisfacer nuestra necesidad de adaptación.
Las metodologías predictivas difícilmente funcionan en entornos de incertidumbre
como los que solemos encontrar en el software. La famosa matriz de Ralph Stacey
plantea dos ejes: acuerdo respecto a los requerimientos en las coordenadas, y el grado
de la incertidumbre respecto a la tecnología.
9
El giro de agregador bancario es altamente complejo por las múltiples variables que
intervienen.
10