Resumen sobre Marco de trabajo SCRUM

Exposición sobre Scrum
Convocatoria Competencias Específicas y Transversales
Ingeniero Antonio E. Martínez Bernier
2015

Agenda
1. Presentación del expositor
2. Convocatoria Competencias Específicas y Transversales
3. Proceso ante el ICETEX
4. Marcos de trabajo ofertados
5. Experiencia personal
6. Marco de trabajo SCRUM

Presentación del Expositor
 Antonio Enrique Martínez Bernier
 Ingeniero de Sistemas – Universidad del Norte (1998)
 Especialista en Gerencia de Sistemas de Información – Universidad del Norte (2000)
 Especialista en Redes de Computadores – Universidad del Norte (2003)
 Magíster en Gobierno de Tecnologías de la Información – Universidad del Norte (2012)
 Auditor interno ISO 27001:2005
 Auditor interno ISO 9001:2008
 Certificaciones:
 Scrum Master CSM
 ITIL Foundations V3
 Certified Sonicwall Security Administrador (CSSA)

Convocatoria Competencias Específicas y
Transversales
 Beneficio otorgado a raíz de la intervención del Plan Vive Digital y la
iniciativa FITI – Fortalecimiento de la Industria TI – de la Dirección de
Políticas y Desarrollo de TI del Ministerio de Tecnologías de Información y
Comunicaciones MINTIC.
 Objetivos:
 Fomentar la formación de capital humano especializado en el uso de las TI.
 Fortalecimiento de la industria.
 Desarrollo de la competividad, investigación, innovación y proyección
internacional del sector de las TI.

Proceso ante el ICETEX
 El beneficio es otorgado a través de un crédito con el ICETEX.
 Este crédito es condonable luego de cumplir los siguientes requisitos:
Requisito Descripción
1 Cumplir con el mínimo de asistencia requerido en el curso
seleccionado y culminarlo satisfactoriamente.
2 Lograr la certificación correspondiente.
3 Cátedra de no menos de 2 horas orientada a la sensibilización sobre
la necesidad de contar con mayor talento humano para el sector TI.
Inducción sobre las temáticas del curso escogido.
4 Testimonio en video (youtube) contando la experiencia adquirida
en el curso.

Marcos de trabajo ofertados
La Biblioteca de Infraestructura de Tecnologías de Información, frecuentemente
abreviada ITIL (del inglés Information Technology Infrastructure Library), es un
conjunto de conceptos y buenas prácticas para la gestión de servicios de
tecnologías de la información, el desarrollo de tecnologías de la información y las
operaciones relacionadas con la misma en general. ITIL da descripciones detalladas
de un extenso conjunto de procedimientos de gestión ideados para ayudar a las
organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos
procedimientos son independientes del proveedor y han sido desarrollados para
servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI.
Tomado de:
http://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

Scrum es parte fundamental de la herramienta Sprint del modelo de
desarrollo ágil caracterizado por:
Adoptar una estrategia de desarrollo incremental, en lugar de la
planificación y ejecución completa del producto.
Basar la calidad del resultado más en el conocimiento tácito de las personas
en equipos autoorganizados, que en la calidad de los procesos empleados.
Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una
tras otra en un ciclo secuencial o de cascada.
Tomado de:
http://es.wikipedia.org/wiki/Scrum

El Project Management Institute creó en 1984 la
certificación PMP® y desde entonces esta ha sido la
certificación internacional sobre gerencia de proyectos
más reconocida y respetada a nivel mundial. Los
profesionales certificados PMP® pueden demostrar
experiencia, educación y competencias necesarias para
liderar y dirigir proyectos.
Tomado de:
http://www.pmicolombia.org/preguntas-frecuentes/

La Guía sobre Los fundamentos del conocimiento del
Análisis de Negocio es un estandar Reconocido
mundialmente para la practica del Analisis de
Negocio. La Guía BABOK® describe las areas de
conocimiento del Analisis de Negocio, sus actividades,
tareas asociadas y las habilidades necesarias para ser
eficaz en su realizacion.
Tomado de:
http://www.iiba.org/babok-guide/spanish-
translation.aspx

Experiencia Personal
• Curso Scrum Master, dictado por SEONTI a través del ingeniero Julián Guevara.
• Fechas: 30 y 31 de marzo de 2015 en el Hotel Country International de Barranquilla.

Marco de trabajo SCRUM
Fundamentos de Scrum
Roles en Scrum
Actividades y Artefactos
Historias de usuario
Estimación
Planeación de la Entrega
Planeación del Sprint
Ejecución del Sprint
Revisión del Sprint
Retrospectiva
TEMARIO

FUNDAMENTOS DE SCRUM
SCRUM es un marco de trabajo (Framework) para el desarrollo Ágil de productos
software (proyectos). Se basa en unos principios, prácticas y valores ágiles, no es una
metodología completa como tal. No tiene demasiados artefactos o etapas cerradas.
Principio básico: entrega temprana al cliente de software (entre 2 semanas y 2 meses)
con valor para su satisfacción. No se alienta la resistencia al cambio, como es la tónica
habitual en los proyectos, sino que pretende aprovechar para aumentar la ventaja
competitiva del cliente y su satisfacción. Por otra parte, se pretende obtener un ritmo
constante de desarrollo.
Las entregas son iterativas e incrementales, aportando nuevas funcionalidades en cada
iteración o sprint.

Se fomenta el trabajo en equipos auto-organizados, la comunicación cara a cara y la
colaboración entre los profesionales que saben del tema. No hay roles pre-establecidos
ni jerarquías (..yo jefe de proyecto ordeno y mando y tu programador haces lo que te
diga..). Se perfecciona y se busca la mejora continuamente.
Se prohíbe la ocultación de detalles de implementación al cliente, ya que se le tiene
informado y presente en las reuniones.
El equipo construye aquello que el Product owner indica. El Scrum Master es un
garante de la ejecución del método y un facilitador, en ningún caso es un Project
Manager al uso, cuya función consiste en re-enviar mensajes con copia a, actualizar
excel copia y pega de otro proyecto o manejar Gantts.

Objetivo principal: mejorar la satisfacción del cliente, la velocidad y calidad de
desarrollo a través del trabajo en equipo y la transparencia. Los requerimientos o
alcance se cambian durante toda la vida del proyecto.
Manifiesto Agil:
“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
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la
izquierda”

ROLES: PRODUCT OWNER
Product Owner o dueño del producto. Es una sola persona. Dice que es lo siguiente
más importante que se debe hacer. Será responsable de garantizar el máximo retorno
posible del proyecto. Su tarea consiste en identificar las necesidades que debe cubrir
el producto, priorizando las historias más importantes en primer lugar (se asesora por
el equipo también) para que se aborden en los sprints por orden de prioridad y se
encarga de actualizar continuamente la pila de producto con requisitos: nuevas
historias, redefinir, re-priorizar y reordenar la pila. Mantiene el gráfico de burndown.
Lo deseable es que sea alguien con suficiente autoridad para respaldar el proyecto y
dar apoyo, y no alguien que actúa obligado por las circunstancias o como encargo
marrón de otro superior.

ROLES: EQUIPO DESARROLLADOR
Formado por profesionales multifuncionales que cubran todos los roles entre varios.
Es autónomo y autoorganizado, no por programadores que solo programan, tester
que solo realizan pruebas, etc.. Son los que mandan en el desarrollo.
Ellos deciden a lo que se comprometen y como lo hacen, así como de realizar las
estimaciones de las historias. El equipo diseña, construye, prueba y vela por la calidad
interna del producto, ayudando al Product Owner a comprender tareas y
requerimientos técnicos.
Mejor que sean equipos estables, que no cambien mucho. Las rotaciones en los
equipos acaban lastrando el rendimiento.

ROLES: SCRUM MASTER
Scrum Master es una sola persona que ayuda al equipo y al Product Owner a finalizar con éxito,
garantizando el máximo de productividad al evitar incidentes, resolver cuellos de botella por
recursos no concedidos, permisos, accesos, …burocracía en definitiva o simplemente correos no
contestados, así como ejercer de guardián del método Scrum. Debe ser un profesional
experimentado a nivel técnico pero con dotes de líder colega y un toque de entrenador de rugby
o coaching de equipos. Este rol lo puede abordar un miembro del equipo o ser una persona a
tiempo completo si el proyecto es mediano o grande.
IMPORTANTE: No dice a nadie lo que tiene que hacer o asigna tareas. No es un manager o líder
técnico del equipo, sino alguien que ayuda, protege y guía en la aplicación del Scrum. Vigila que
todo el mundo entienda su papel y aplique el método. Debe ser una persona enérgica y pro-
activa, además de poseer también ciertas habilidades sociales.

ARTEFACTOS
Existen tres artefactos, el Product Backlog, el Sprint Backlog y el Burndown Chart.
Product Backlog: es una "caja" con todos los requisitos del producto. éstos
requisitos pueden ir cambiando y ésta "caja" se puede implementar de muchas
formas, dependerá del tipo de proyecto, producto o servicio que se quiera
entregar. El responsable de la gestión de ésta "caja" es el jefe de producto, es
quien modificará requisitos o los priorizará cuando crea necesario y quien
"encolará" requisitos para la creación en cada Sprint del Sprint Backlog.

ACTIVIDADES
Todo en SCRUM esta dividido en periodos de tiempo, esto nos ayuda a mantener el
rumbo del proyecto y a entregar en las fechas previstas ya que cada reunión tiene
unas pautas y unos límites de tiempo preestablecidos. Están prohibidas esas
reuniones interminables, improductivas y tremendamente costosas.
Sprint es el período en el que estamos trabajando. Se establece una duración fija de
entre de 2 y 4 semanas al principio del proyecto que se debe mantener para
posibilitar la gestión del cambio evolutiva.

ACTIVIDADES
Hay 5 tipos de reuniones dentro de un Sprint.
• Sprint Planning: al comienzo del Sprint tenemos la reunión de planificación que no
debería durar más de una jornada de trabajo. En esta reunión se estiman en
puntos suficientes tareas como para que el equipo alcance, al menos, su límite de
trabajo. (8 horas máximo)
• Sprint Commitment Meeting: es una reunión de compromiso. En ésta reunión, con
la estimación ya hecha, se llega a un compromiso entre el equipo y el Jefe de
producto sobre las tareas que se realizarán durante el Sprint. (4 horas máximo)

ACTIVIDADES
• Sprint Review: al final del Sprint se realiza una revisión de lo que se ha hecho
durante el Sprint. Se evalúa lo que se ha hecho y cómo se ha hecho y de ésta
reunión podrían salir nuevas tareas o requisitos para el siguiente Sprint. (4 horas
máximo)
• Sprint Retrospective: una vez hecha la revisión se realiza ésta reunión de
retrospectiva en la que se busca la autocrítica, individual y colectiva, enfocada a la
mejora de la eficiencia y la calidad. (3 horas máximo)
• Daily Meeting: todos los días tenemos el Daily Meeting, una reunión en el que cada
miembro del equipo nos cuenta que hizo la jornada anterior, lo que piensa hacer en
ésta y nos expone sus bloqueos si los tiene. (15 minutos máximo)

ARTEFACTOS
Sprint Backlog: es un subconjunto del Product
Backlog con los requisitos más prioritarios. Durante
la reunión de planificación, el Sprint Planning, el
grupo de trabajo subdivide éstos requisitos en tareas
que se estiman en puntos. Una vez comenzado el
Sprint el Sprint Backlog no cambia. Es el grupo de
trabajo, acorde a sus posibilidades, quien a lo largo
del Sprint van pasando dichas tareas desde un
estado "pendiente", es decir, están en el backlog, a
un estado "Done!", es decir, finalizadas.

ARTEFACTOS
Burndown Chart: es un gráfico que indica la
cantidad de trabajo que queda en el Sprint. En el
eje Y tenemos la cantidad de trabajo pendiente y
en el eje X los días que quedan para la
finalización del Sprint de tal forma que el gráfico
siempre es un polígono o una curva descendente
que ha de tender a cero, de ahí el nombre. Éste
gráfico es actualizado a diario por el
ScrumMaster después del Daily Meeting tras
haber escuchado a todos los integrantes del
grupo decir qué consiguieron acabar durante la
jornada anterior.

HISTORIAS DE USUARIO
Descripción de una funcionalidad que debe incorporar un sistema de software, y
cuya implementación aporta valor al cliente.
La estructura de una historia de usuario está formada por:
• Nombre breve y descriptivo.
• Descripción de la funcionalidad en forma de diálogo o monólogo del usuario
describiendo la funcionalidad que desea realizar.
• Criterio de validación y verificación que determinará para considerar terminado y
aceptable por el cliente el desarrollo de la funcionalidad descrita.
• Y adicionalmente por la información que resulte necesaria por el modelo de
implementación: Prioridad, Riesgo, Tamaño, etc.

HISTORIAS DE USUARIO

ESTIMACIÓN
A continuación vamos a exponer como realizar este proceso de estimación centrándonos en
tres aspectos: la unidad de medida a utilizar, las limitaciones que ésta tiene y como realizar el
proceso de estimación con el equipo.
La unidad de medida: Puntos de Historia
Definimos un Punto de Historia de la siguiente manera:
1 punto de historia
=
1 jornada de trabajo de un miembro del equipo en dedicación exclusiva
Es decir, si una historia tiene 3 puntos significa que si un miembro del equipo (solo uno) se
dedica a trabajar para realizar la historia sin tener que dedicar tiempo a ninguna otra cuestión
(ni reuniones, ni llamadas, ni "marrones" varios), necesitará 3 jornadas de trabajo.
Hasta aquí todo correcto, pero ...

ESTIMACIÓN
La primera limitación es que estimar con Puntos de Historia es, por definición, impreciso:
se basa en la premisa de que no hay interrupciones y no contempla la paralelización o
colaboración en el trabajo. Sin embargo, el hecho de que olvidarnos de estos aspectos a la
hora de estimar elimina las variables más complejas o indeterminadas y simplifica
notablemente el proceso de estimación por parte de los miembros del equipo.
Solución: después de la estimación, cuando se procede a definir el Sprint Backlog,
utilizaremos el "Cálculo de la Velocidad" del equipo definido por Scrum para hacer los
ajustes que mitiguen esta inexactitud.

ESTIMACIÓN
Cuanto mayor es el tamaño de una
historia, más difícil es determinar el
número exacto de jornadas necesarias
para completarla.
Solución: restringimos los valores a
utilizar para estimar las historias a un
conjunto de valores que se adapten a esta
circunstancia. En este sentido hemos
adaptado al modelo de Planning Poker en
el que el conjunto de valores definido es
el siguiente:

ESTIMACIÓN
La estimación se realiza generalmente
durante el Planning. En este proceso, el
Scrum Master repasa cada una de las
historias priorizadas en el Product Backlog,
confirma con el equipo que todo el mundo
entiende los objetivos de la misma y lanza el
proceso de estimación.
Cada miembro del equipo determina los
puntos de historia que él considera
oportunos.

CONCEPTO DE TIMEBOX
Scrum trata al tiempo como uno de los obstáculos más importantes en la gestión de un proyecto. Para
hacer frente a la restricción del tiempo, Scrum introduce un concepto llamado Time-boxing que propone la
fijación de una cierta cantidad de tiempo para cada proceso y actividad en un proyecto Scrum. Esto
garantiza que los miembros del Scrum Team no ocupen demasiado o muy poco tiempo por un trabajo
determinado, y que no desperdicien su tiempo y energía en un trabajo para el cual tienen poca claridad.
Algunas de las ventajas de Time-boxing son los siguientes:
 Proceso de desarrollo eficiente
 Menos gastos generales
 Alta velocidad para los equipos
Time-boxing es una práctica crítica en Scrum y debe aplicarse con cuidado. Un Time-boxing arbitrario
puede llevar a la desmotivación del equipo y puede tener como consecuencia la creación de un entorno
aprensivo, por lo que Time-boxing debe ser utilizado de manera apropiada

PLANEACIÓN DEL SPRINT
La planificación de las tareas a realizar en la iteración se divide en dos partes:
Primera parte de la reunión. Se realiza en un timebox de cómo máximo 4 horas* :
El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto,
pone nombre a la meta de la iteración (de manera que ayude a tomar decisiones durante
su ejecución) y propone los requisitos más prioritarios a desarrollar en ella.
El equipo examina la lista, pregunta al cliente las dudas que le surgen, añade más
condiciones de satisfacción y selecciona los objetivos/requisitos más prioritarios que se
compromete a completar en la iteración, de manera que puedan ser entregados si el
cliente lo solicita.

PLANEACIÓN DEL SPRINT
Segunda parte de la reunión. Se realiza en un timebox de cómo máximo 4 horas* . El
equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor
resultado posible con el mínimo esfuerzo. Esta actividad la realiza el equipo dado que
ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien
mejor conoce cómo realizarlo.
Define las tareas necesarias para poder completar cada objetivo/requisito, creando la
lista de tareas de la iteración (Sprint Backlog) basándose en la definición de
completado.
Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.
Cada miembro del equipo se autoasigna a las tareas que puede realizar.

EJECUCIÓN DEL SPRINT
En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de un mes natural y hasta de
dos semanas). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto que
sea potencialmente entregable, de manera que cuando el cliente (Product Owner) lo solicite sólo sea necesario
un esfuerzo mínimo para que el producto este disponible para ser utilizado. Para ello, durante la iteración el
equipo colabora estrechamente y se llevan a cabo las siguientes dinámicas:
• Cada día el equipo realiza una reunión de sincronización, donde cada miembro inspecciona el trabajo de los
otros para poder hacer las adaptaciones necesarias, comunica cuales son los impedimentos con que se
encuentra, actualiza el estado de la lista de tareas de la iteración (Sprint Backlog) y los gráficos de trabajo
pendiente (Burndown charts).
• El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se
merme su productividad.
 Elimina los obstáculos que el equipo no puede resolver por sí mismo.
 Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

EJECUCIÓN DEL SPRINT (DAILY MEETING)
El objetivo de esta reunión es facilitar la transferencia de información y la colaboración
entre los miembros del equipo para aumentar su productividad, al poner de manifiesto
puntos en que se pueden ayudar unos a otros.
Cada miembro del equipo debe responder las siguientes preguntas en un timebox de
cómo máximo 15 minutos:
¿Qué he hecho desde la última reunión de sincronización? ¿Pude hacer todo lo que
tenía planeado? ¿Cuál fue el problema?
¿Qué voy a hacer a partir de este momento?
¿Qué impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteración
y en el proyecto?

REVISIÓN DEL SPRINT
Descripción:
Reunión realizada al final del sprint para comprobar el incremento. . No debe durar más de 4 horas, en
el caso de revisar sprints largos. Para sprints de una o dos semanas, con una o dos horas de duración
debería ser suficiente.
Objetivos:
• El propietario del producto comprueba el progreso del sistema. Esta reunión marca, a intervalos
regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto.
• El propietario del producto identifica las funcionalidades que se pueden considerar “hechas” y las
que no.
• Al ver y probar el incremento, el propietario del producto, y el equipo en general obtienen
feedback relevante para revisar la pila del producto.
Otros ingenieros y programadores de la empresa también pueden asistir para conocer cómo trabaja la
tecnología empleada.

REVISIÓN DEL SPRINT
Precondiciones:
Se ha concluido el sprint.
Asiste todo el equipo de desarrollo, el propietario del producto, el Scrum Master y todas
las personas implicadas en el proyecto que lo deseen.
Entradas:
Incremento terminado.
Resultados:
Feedback para el propietario del producto: hito de seguimiento de la construcción del
sistema, e información para mejorar el valor de la visión del producto.
Convocatoria de la reunión del siguiente sprint.

RETROSPECTIVA DEL SPRINT
Con el objetivo de mejorar de manera continua su productividad y la calidad del
producto que está desarrollando, el equipo analiza cómo ha sido su manera de trabajar
durante la iteración, por qué está consiguiendo o no los objetivos a que se comprometió
al inicio de la iteración y por qué el incremento de producto que acaba de demostrar al
cliente era lo que él esperaba o no:
• Qué cosas han funcionado bien.
• Cuales hay que mejorar.
• Qué cosas quiere probar hacer en la siguiente iteración.
• Qué ha aprendido.
• Cuales son los problemas que podrían impedirle progresar adecuadamente. El
Facilitador se encargará de ir eliminando los obstáculos identificados que el propio
equipo no pueda resolver por sí mismo.

RETROSPECTIVA DEL SPRINT
Notar que esta reunión se realiza después de la reunión de demostración al cliente de
los objetivos conseguidos en la iteración, para poder incorporar su feedback y
cumplimiento de expectativas como parte de los temas a tratar en la reunión de
retrospectiva
Se realiza en un timebox de cómo máximo 3 horas (si la iteración es mensual).

RESUMEN

RESUMEN: BENEFICIOS

RESUMEN: CICLO DE DEMMING

Resumen sobre Marco de trabajo SCRUM

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (14)

Similar a Resumen sobre Marco de trabajo SCRUM

Similar a Resumen sobre Marco de trabajo SCRUM (20)

Último

Último (11)

Resumen sobre Marco de trabajo SCRUM