Está en la página 1de 17

Contenido

¿Qué es? ........................................................................................................................................................ 3


Introducción. ............................................................................................................................................. 3
Historia ...................................................................................................................................................... 4
Scrum aplicado al desarrollo de software ................................................................................................. 4
Entendiendo SCRUM: Pilares importantes................................................................................................ 4
Transparencia ........................................................................................................................................ 5
Inspección .............................................................................................................................................. 5
Adaptación ............................................................................................................................................ 5
Fundamentos de Scrum ............................................................................................................................ 5
Características ............................................................................................................................................... 5
Características principales ......................................................................................................................... 5
Roles SCRUM ............................................................................................................................................. 6
Roles principales .................................................................................................................................... 6
Roles auxiliares ...................................................................................................................................... 9
Reuniones en Scrum .................................................................................................................................. 9
Daily Scrum ............................................................................................................................................ 9
Scrum de Scrum ................................................................................................................................... 10
Reunión de Planificación del Sprint (Sprint Planning Meeting) ........................................................... 10
Reunión de Revisión del Sprint (Sprint Review Meeting) ..................................................................... 10
Retrospectiva del Sprint (Sprint Retrospective) ................................................................................... 10
Documentos ............................................................................................................................................ 10
Product backlog ................................................................................................................................... 10
Sprint backlog ...................................................................................................................................... 11
Burn down ........................................................................................................................................... 11
Ventajas y desventajas ............................................................................................................................... 11
Ventajas ................................................................................................................................................... 11
Desventajas ............................................................................................................................................. 12
Etapas o fases ............................................................................................................................................. 13
Product Backlog:...................................................................................................................................... 13
Sprint Planning: ....................................................................................................................................... 13
Sprint ....................................................................................................................................................... 13
Sprint Backlog .......................................................................................................................................... 14
Daily sprint meeting ................................................................................................................................ 14
Demo y retrospectiva .............................................................................................................................. 14
Valores SCRUM ........................................................................................................................................... 15
Requisitos para poder utilizar Scrum ......................................................................................................... 15
Ejemplos de uso .......................................................................................................................................... 16
Caso de fracaso (Healthcare.gov) ............................................................................................................ 16
Causas del fracaso ............................................................................................................................... 16
Causas del éxito ................................................................................................................................... 16
Conclusiones ............................................................................................................................................... 17
Metodología SCRUM
¿Qué es?
Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo
es maximizar el retorno de la inversión para su empresa (ROI). Se basa en construir primero la
funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-
gestión e innovación.

También se le conoce como una estructura en la que las personas pueden abordar complejos problemas
adaptativos, siendo a la vez productivas y creativas para entregar productos finales de gran valor. Scrum
también incorpora varios elementos, como que es ligero y fácil de entender. Eso sí, es difícil de dominar.

La estructura está compuesta de Equipos Scrum que llevan a cabo una serie de funciones, tienen diferentes
utensilios y eventos y siguen una serie de reglas. Cada parte de la estructura tiene un propósito, que
trabaja hacia el éxito de Scrum.

Scrum es el nombre con el que se denomina a los marcos de desarrollo ágiles caracterizados 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 auto
organizados, 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 en cascada.

Introducción.
La metodología Scrum es tendencia en la gestión de proyectos. Si trabajas en un sector en el que el nivel
de incertidumbre es alto y tu trabajo ágil, quizás tengas que aplicar Scrum para gestionar tus proyectos.

El sector del desarrollo de software es el principal representante de este tipo de metodología ágil. Se trata
de planificar tus proyectos en pequeños bloques o Sprint, e ir revisando y mejorando el anterior. Y es el
propio término Scrum proviene del mundo del rugby. Te lo contamos a continuación.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que
aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos
complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco
definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita,
cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se
necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación
alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere
trabajar utilizando un proceso especializado en el desarrollo de producto.
Entre las principales características de la metodología Scrum, desataca que es un desarrollo incremental
en lugar de la clásica planificación del desarrollo completo de un producto o servicio. Sus equipos de
trabajo se caracterizan por ser auto-organizados. Y se centra en el producto final, en la calidad del mismo.

Historia
El término Scrum (traducido del inglés como melé) fue acuñado y definido por Ikujiro Nonaka e Hirotaka
Takeuchi en los años 80, cuando las principales empresas de desarrollo tecnológica empezaban a dominar
el mercado y a definir conductas de trabajo. Ambos publicaron en 1986 en la Harvard Business Review
este artículo “El nuevo juego para el desarrollo de productos”. Así abrieron una caja que durante los
próximos años ha evolucionado y se ha extendido por muchos sectores, no sólo el tecnológico.

El avance de las formaciones de las melés en partidos de rugby, inspiró a Nonaka y Takeuchi para bautizar
una nueva forma de trabajar que ya venía dándose en muchas empresas tecnológicas como Honda, Canon
y Fuji-Xerox.

Scrum aplicado al desarrollo de software


Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos
que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el
desarrollo de determinados sistemas de software. Jeff Sutherland aplicó el modelo Scrum al desarrollo de
software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se
integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo
presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software
en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo
de software scrum está considerado como modelo ágil por la Agile Alliance.

La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:

 Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
 Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog),
Incremento.
 Reuniones:
 Planificación del sprint, Revisión diaria, Revisión del sprint.
 Sprint

Entendiendo SCRUM: Pilares importantes.


Para entender Scrum, es importante echar un vistazo a sus fundamentos básicos. Scrum se ha fundado
sobre una teoría empírica de control de procesos, que también se conoce como empirismo. Lo que afirma
esta teoría es que el conocimiento se basa en la toma de decisiones y en la experiencia de los factores
conocidos.

Por tanto, Scrum busca cómo optimizar la predictibilidad y controlar el riesgo utilizando un método
Iterativo e Incremental. Para que esto suceda, hay tres pilares que se deben implementar. Estos son la
Transparencia, la Inspección y la Adaptación.
Transparencia
Hay partes de este proceso que necesitan ser visibles para aquellos responsables de los resultados. Esto
requiere definiciones estándar de todos los aspectos para asegurarse de que hay un entendimiento común
de todas las observaciones. Considera estos ejemplos: –

 Todos los participantes en el proceso deben usar un lenguaje común


 Tanto aquellos que llevan a cabo el trabajo, como los que aceptan el resultado, deben
tener una definición estándar de “Finalizado”.

Inspección
Aquellos que usan Scrum necesitan inspeccionar periódicamente los instrumentos Scrum y el progreso del
Objetivo en el Sprint. Esto asegura que puedan detectar variaciones no deseadas a tiempo. Las
inspecciones deben llevarse a cabo de vez en cuando, de manera que no se interrumpa el trabajo en
progreso.

Adaptación
Después de una inspección, puede revelarse que uno o más aspectos del proceso se ha desviado de los
límites aceptables. Esto significa que el producto final podría no ser aceptable y que es necesario hacer
algún ajuste en el proceso o el material que se está usando. Cuanto antes ocurra, mejor, de manera que
se eviten más desviaciones.

Fundamentos de Scrum

Scrum se basa en:

 El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y


fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita).
 La priorización de los requisitos por valor para el cliente y coste de desarrollo en cada iteración.
 El control empírico del proyecto. Por un lado, al final de cada iteración se demuestra al cliente el resultado
real obtenido, de manera que pueda tomar las decisiones necesarias en función de lo que observa y del
contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las
adaptaciones necesarias.
 La potenciación del equipo, que se compromete a entregar unos requisitos y para ello se le otorga la
autoridad necesaria para organizar su trabajo.
 La sistematización de la colaboración y la comunicación tanto entre el equipo y como con el cliente.
 El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir resultados.

Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar
de equipos altamente productivos.

Características
Características principales
Entre las características principales del SCRUM podemos mencionar:

 Gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación,
retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y
equipo, por último, equipo motivado.
 Se hace uso de equipos auto-dirigidos y auto-organizados.
 Se realiza a diario una reunión de Scrum, que es una reunión de avance diaria que no dura más
de 15 minutos con el objetivo de obtener realimentación sobre las tareas del equipo y los
obstáculos que se presentan.
 Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los
miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas
involucrados en el proyecto.
 Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden
cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que
los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y
planificada.
 Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser
completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de
entregar rápidamente y responder a requisitos emergentes.
 Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco
esfuerzo para comenzarse a utilizar.

Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un
conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas
amarillas "post-it" y pizarras hasta paquetes de software.

Roles SCRUM
Roles principales
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como
punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.

Tres miembros componen el Equipo Scrum básico, y son el Product Owner, el Equipo de Desarrollo y el
Scrum Master. Se espera que estos equipos se auto-organicen y sean multifuncionales. Cuando se auto-
organizan, pueden elegir la mejor manera de finalizar el trabajo y no tener en cuenta la orientación que
puedan dar personas que no sean del equipo.

El Product Owner
Cuando se trata de maximizar el valor del producto y el trabajo del Equipo de Desarrollo, es el Product
Owner el responsable de ello. Esto varía según los Equipos Scrum y las personas del equipo. El Product
Owner tiene la responsabilidad de gestionar el Backlog del Producto. Esta gestión incluye:

 Expresar claramente los elementos del backlog de Producto


 Ordenar los elementos del Backlog de Producto para alcanzar las misiones y los objetivos
 Optimizar el valor del trabajo que realiza el Equipo de Desarrollo
 Asegurar que el Backlog de Producto es visible, transparente y claro.
Esto revela en qué debería trabajar el Equipo Scrum y asegura que el Equipo de Desarrollo comprende
perfectamente los elementos del Backlog de Producto al nivel requerido. Aunque el Product Owner podría
delegar este trabajo en el Equipo de Desarrollo, son responsables del resultado.
El Product Owner es una persona y no un comité. Si existe un comité en funcionamiento, pueden presentar
sus deseos en el backlog de Producto. Aquellos que quieran hacer cualquier ajuste, necesitan consultar al
Product Owner.

Para garantizar que el Product Owner tiene éxito, todas las personas de la organización deben respetar
sus decisiones, que son visibles en el contenido y orden del Backlog de Producto. No hay nadie capaz de
ordenar al Equipo de Desarrollo trabajar con requisitos distintos, y el Equipo de Desarrollo también tiene
sus acciones limitadas bajo las instrucciones de otra persona.

El Equipo de Desarrollo
Es un equipo formado por profesionales que trabajan para entregar un Incremento de producto
“Finalizado” que se pueda lanzar al final de cada Sprint. Solo los miembros de este equipo pueden crear
el Incremento.

La organización asegura que el Equipo de Desarrollo está empoderado para organizar y gestionar su
trabajo. La sinergia que ocurre, como resultado, optimizará la eficiencia y efectividad del Equipo de
Desarrollo. Estos equipos tienen las siguientes características:

 Se auto-organizan. No reciben instrucciones ni consejo de nadie sobre cómo convertir el


Backlog de Producto en Incrementos de funcionalidades potencialmente liberables.
 Son multifuncionales y tienen todas las habilidades necesarias para crear un Incremento de
producto.
 Scrum no otorga ningún título al Equipo de Desarrollo. Todo el mundo es desarrollador, sin
importar el trabajo que desempeñen. Esto se aplica sin excepciones.
 Dentro del Equipo de Desarrollo, el Scrum reconoce que no hay sub-equipos. Esto ocurre
incluso cuando hay muchos dominios que tienen que ser tratados, como el análisis de
negocios o el testeo. Esto se aplica sin excepciones.
 Cada miembro del Equipo de Desarrollo podría tener una habilidad o zona de confort
especial, pero si hablamos de responsabilidades, se considera al equipo como un todo.

El Equipo de Desarrollo se compone de muchas personas, siendo tres el número óptimo. Esto asegura
que se mantienen ágiles y son un lo suficientemente grandes para finalizar todo el trabajo que se debe
hacer en un Sprint.

Si el equipo tiene menos de tres miembros, la interacción puede verse reducida, lo que significa que se
tendrá menor productividad. Además, los Equipos de Desarrollo pequeños pueden ver restringidas sus
capacidades durante el Sprint, significando que podrían no ser capaces de entregar un Incremento
potencialmente liberable.

Los equipos grandes, como aquellos con más de nueve miembros, necesitan mucha más coordinación.
Acaban generando demasiada complejidad como para gestionar un proceso empírico. Al contar al
Equipo de Desarrollo, no se cuenta al Product Owner ni al Scrum Master a no ser que también estén
realizando el trabajo del Backlog del Sprint.
El Scrum Master
El Scrum Master tiene la responsabilidad de asegurar que se ha entendido y aprobado el método Scrum.
Trabajan con el Equipo Scrum, por lo que pueden adherirse a la teoría, prácticas y reglas de Scrum. El
Scrum Master es esencialmente el líder-ayudante del Equipo Scrum.

El Scrum Master ayuda a las personas que no están en el Equipo Scrum a entender cuáles de sus
interacciones con el Equipo Scrum son útiles y cuáles no.

Entendiendo el Servicio del Scrum Master

Hay tres grupos de Servicio del Scrum Master, y estos incluyen:

El Servicio del Scrum Master para el Product Owner

Esto se hace de numerosas maneras, incluyendo:

1. Encontrar técnicas para gestionar de manera efectiva el Backlog de Producto


2. Ayudar al Equipo Scrum a entender la necesidad de tener elementos claros y concisos en el backlog
de Producto
3. Comprensión del planteamiento de producto en un ambiente empírico
4. Asegurar que el Product Owner conoce la mejor manera de organizar el backlog de Producto para
maximizar el valor
5. Comprensión y práctica de la agilidad.
6. Facilitar eventos de Scrum según se requiera

El Servicio del Scrum Master para el Equipo de Desarrollo

Aquí, el Scrum Master ayudará al Equipo de Desarrollo de las siguientes maneras:

1. Actuar de coach en temas de auto-organización y multifuncionalidad


2. Ayudar al Equipo de Desarrollo a crear productos de alto valor
3. Eliminar los Impedimentos del progreso del Equipo de Desarrollo
4. Facilitar eventos de Scrum según se requiera
5. Actuar como coach en ambientes de organización donde el método Scrum no ha sido totalmente
adoptado o entendido

Servicio del Scrum Master para la Organización

Los Scrum Masters pueden ayudar a la organización de varias maneras, como:

1. Liderar al equipo y actuar de coach en la adopción del método Scrum


2. Planear la implementación de Scrum en la organización
3. Ayudar a empleados y partes interesadas a entender el desarrollo de Scrum y el desarrollo
empírico de productos
4. Causar cambios que lleven al incremento de la productividad del Equipo Scrum
5. Trabajar con otros Scrum Masters para aumentar la efectividad de la implantación de Scrum en la
organización
Roles auxiliares
Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no se involucran
frecuentemente en el "proceso Scrum", sin embargo, deben ser tomados en cuenta. Un aspecto
importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del
negocio y otros interesados ("stakeholders"). Es importante que esa gente participe y entregue
retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc.)


Son las personas que hacen posible el proyecto y para quienes el proyecto producirá el beneficio acordado
que justifica su desarrollo. Sólo participan directamente durante las revisiones del "sprint".

Administradores (Managers)
Son los responsables de establecer el entorno para el desarrollo del proyecto.

Reuniones en Scrum
Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup".
El scrum tiene unas guías específicas:

 La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el


equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de
plástico del cuello, etc.)
 Todos son bienvenidos, pero sólo los "cerdos" pueden hablar.

La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.

 Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
 La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:·

 ¿Qué has hecho desde ayer?


 ¿Qué es lo que estás planeando hacer hoy?
 ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del
ScrumMaster recordar estos impedimentos).

Scrum de Scrum
Cada día normalmente después del “Daily Scrum”

 Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose


especialmente en áreas de solapamiento e integración.
 Asiste una persona asignada por cada equipo.

La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas:

 ¿Qué ha hecho tu equipo desde nuestra última reunión?


 ¿Qué hará tu equipo antes que nos volvamos a reunir?
 ¿Hay algo que demora o estorba a tu equipo?
 ¿Estás a punto de poner algo en el camino del otro equipo?

Reunión de Planificación del Sprint (Sprint Planning Meeting)


Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.

 Seleccionar que trabajo se hará


 Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará
hacer el trabajo.
 Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual
Sprint
 Ocho horas como límite

Al final del ciclo Sprint, dos reuniones se llevarán a cabo: la “Reunión de Revisión del Sprint” y la
“Retrospectiva del Sprint”

Reunión de Revisión del Sprint (Sprint Review Meeting)


 Revisar el trabajo que fue completado y no completado
 Presentar el trabajo completado a los interesados (alias “demo”)
 El trabajo incompleto no puede ser demostrado
 Cuatro horas como límite

Retrospectiva del Sprint (Sprint Retrospective)


Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del
equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar
una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.

Documentos
Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas
de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la
inversión (ROI). Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene
estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido.
Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de
las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera
menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.

Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los
requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración
superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. Las tareas en el
sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca
oportuno.

Burn down
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog
del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos
los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea
descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde
el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha
terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se
añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se
modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

Ventajas y desventajas
Ventajas
 Flexibilidad a cambios: Gran capacidad de reacción ante los cambiantes requerimientos
generados por las necesidades del cliente o la evolución del mercado. El marco de trabajo está
diseñado para adecuarse a las nuevas exigencias que implican proyectos complejos.
 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 calidad del software: El trabajo metódico y la necesidad de obtener una versión de
trabajo funcional después de cada iteración, ayuda a la obtención de un software de alta calidad.
 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: 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.
 Reducción de riesgos: El hecho de desarrollar, en primer lugar, las funcionalidades de mayor
valor y de saber la velocidad a la que el equipo avanza en el proyecto, permite despejar riesgos
efectivamente de manera anticipada.
 Entregables en tiempo y forma, puedes ir enviando entregables al cliente mientras vas atacando
los objetivos más sencillos, eso te hace ganar tiempo para atacar los objetivos más complejos.
 El ScrumMaster tiene el conocimiento necesario para lograr el objetivo primario y secundario
por lo cual puede ir controlando el proyecto y delegando roles.
 Cada persona sabe que es lo que tiene que hacer y no es necesario estar reorganizando una y
otra vez los Tracks de cada persona.
 Se involucra desde un principio y se da un rol a todos los stakeholders (personas que van a
participar en el proyecto incluyendo cliente final, QA, Testers, etc.)

Desventajas
 Algunos miembros de tu equipo pueden saltar pasos importantes en el camino rápido para llegar
al “sprint” final.
 El cliente siempre va a esperar los informes con la fecha exacta, y muchas veces los va a pedir
antes, cuando capaz no pudiste avanzar en nada.
 Demasiadas Reuniones para poco avance, a veces es muy cansado y estresante reunirse
demasiadas veces por el mismo tema, algunos van perdiendo el interés en el proyecto.
 Si una persona renuncia o hay algún cambio es complicado remplazar ese rol ya que es la
persona que se lleva el conocimiento específico y afecta a todo el proyecto.
 No es aplicable a grandes escalas o cuando el sector IT es variado.
 Dificultad de aplicación en grandes proyectos.
 Plantea un problema si el desarrollo está restringido por una fecha de entrega y un precio de
entrega cerrados por contrato.
 Supone que el equipo está muy formado y motivado.

 Funciona bien solo en equipos pequeños.


 Esta metodología necesita sólo los miembros del equipo con experiencia. Si el equipo está
formado por personas que son novatos, el proyecto no se puede completar en el tiempo.
 Si algunos de los miembros del equipo dejan el desarrollo del proyecto, puede tener un enorme
efecto inverso en el proyecto
 Es necesario que el equipo de trabajo sea auto organizado
 Depende en gran medida de la interacción del cliente, por lo que, si el cliente no está claro, el
equipo se puede conducir en la dirección equivocada.

Etapas o fases

El desarrollo se realiza de forma iterativa e incremental. Cada iteración, denominada Sprint, tiene una
duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software
con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya
construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de
negocio.

Product Backlog:
Conjunto de requisitos denominados historias descritos en un lenguaje no técnico y priorizados por valor
de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los
requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.

Sprint Planning:
Reunión durante la cual el Product Owner presenta las historias del backlog por orden de prioridad. El
equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en
una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.

Este plan se crea con la colaboración de todo el Equipo Scrum.


La reunión de planificación de un Sprint es un evento de tiempo variable. Para un Sprint de un mes tiene
ocho horas de duración. Para Sprints más cortos, el evento es proporcionalmente más corto. Por ejemplo,
para un Sprint de dos semanas, las reuniones de planificación de Sprint son de cuatro horas de duración.
En esta reunión se define la funcionalidad en el incremento planeado y cómo el Equipo de Desarrollo
creará este incremento y la salida de este trabajo es definir el Objetivo del Sprint.
La reunión de planificación de Sprint tradicionalmente consta de dos partes, cada una de la mitad de
tiempo de duración de la Reunión de Planificación respondiendo a las siguientes dos preguntas:

 ¿Qué va a ser entregado en el incremento resultante del próximo Sprint?


 ¿Cómo se va a realizar el trabajo seleccionado?

A destacar que el objetivo del Sprint puede ser un hito en el objetivo más amplio de la hoja de ruta
(roadmap) del producto.

Sprint
Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product
Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo.

Cuando el sprint está en curso, debemos asegurar que:


 No se realizan cambios que afectan al objetivo del Sprint;
 No disminuyen los objetivos de calidad, y
 El Alcance podrá aclararse y re-negociarse entre el propietario del producto y el Equipo de
Desarrollo a medida que se va aprendiendo.

Cuando un Sprint es demasiado largo, la definición de lo que se está construyendo puede cambiar, puede
aumentar la complejidad y puede aumentar el riesgo. Los Sprints permiten previsibilidad al garantizar la
inspección y la adaptación de los avances hacia una meta de por lo menos cada mes de calendario.

Sprint Backlog
Lista de las tareas necesarias para llevar a cabo las historias del sprint.

Daily sprint meeting


Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza para trabajar de forma
coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos.

El equipo de desarrollo utiliza el Scrum Diario para evaluar el progreso hacia la meta del Sprint y evaluar
la tendencia del progreso en finalizar el trabajo en el Sprint Backlog. Cada día, el equipo de desarrollo debe
ser capaz de explicar al dueño del producto y al Scrum Master como van a trabajar juntos como un equipo
auto-organizado para lograr el objetivo y crear el incremento previsto en el resto del Sprint.

Demo y retrospectiva
Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas
mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se
hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos. El propósito de la
retrospectiva de Sprint es:

 Revisar cómo fue el último Sprint en lo que respecta a las personas, relaciones, procesos y
herramientas;
 Identificar y ordenar los temas principales que salieron bien y las potenciales mejoras, y
 Crear un plan para la implementación de mejoras con respecto a cómo el Equipo Scrum hace su
trabajo.
Valores SCRUM
Hay muchos valores que el Equipo Scrum debe encarnar. Estos son el coraje, el compromiso, la
sinceridad, el respeto Estos valores son básicos para erigir los pilares del método Scrum y conseguir
confianza con todas las personas envueltas en él.

Los miembros del Equipo Scrum aprenden y exploran estos valores al trabajar en eventos y roles de
Scrum. Para que el método Scrum tenga éxito, es necesario que los miembros del equipo sean
competentes en estas cinco características.

Así lo hacen:

 Tienen el coraje para hacer lo que es correcto y abordar los problemas graves
 Se comprometen a alcanzar los objetivos del equipo
 Los inversores y el equipo acuerdan hablar abiertamente sobre el trabajo y las dificultades
que tiene el mismo
 Se respetan los unos a los otros y confían en que son independientes y capaces
 Se centran en el trabajo del Sprint y los objetivos del equipo

Requisitos para poder utilizar Scrum


Los siguientes puntos son de especial importancia para la implantación de una gestión ágil de proyectos
como Scrum:

 Cultura de empresa basada en trabajo en equipo, delegación, creatividad y mejora continua.


 Compromiso del cliente en la dirección de los resultados del proyecto, gestión del ROI y
disponibilidad para poder colaborar.
 Compromiso de la Dirección de la organización para resolver problemas endémicos y
realizar cambios organizativos, formando equipos auto gestionados y multidisciplinares y
fomentando una cultura de gestión basada en la colaboración y en la facilitación llevada a
cabo por líderes al servicio del equipo.
 Compromiso conjunto y colaboración de los miembros del equipo.
 Relación entre proveedor y cliente basada en ganar-ganar, colaboración y transparencia.
 Facilidad para realizar cambios en el proyecto.
 Tamaño de cada equipo entre 5 y 9 personas (con técnicas específicas de planificación y
coordinación cuando varios equipos trabajan en el mismo proyecto).
 Equipo trabajando en un mismo espacio común para maximizar la comunicación.
 Dedicación del equipo a tiempo completo.
 Estabilidad de los miembros del equipo

Ejemplos de uso
La metodología Scrum se puede aplicar a muchos sectores, sin embargo, aún no se puede adaptar
adecuadamente a otros como los procesos de fabricación de productos o el mundo de la construcción.

Caso de fracaso (Healthcare.gov)


Proyecto del gobierno norteamericano para mostrar transparencia en los seguros sanitarios.

Causas del fracaso


 No haber lanzado el proyecto fase a fase
 No testeo ni aprendizaje
 Falta de liderazgo en un proyecto con más de 20 consultoras implicadas
 Falta de coordinación entre el Front-End y el Back-End
 El testeo final se produjo en un periodo demasiado corto

Caso de éxito (Spotify)


Es una aplicación multiplataforma empleada para la reproducción de música vía streaming.

Causas del éxito


 Contrato externo de un especialista en metodologías ágiles. Gran importancia al rol del Scrum
Master.
 Fundamental el trabajo del Product Owner, para saber entender las necesidades reales del cliente
y trasladarlas a tiempo al equipo.
 Buena coordinación central de la compañía.
 Rápidos, baratos y mejores frente a sus competidores Google y Apple.
 Los pequeños equipos Scrum son hábiles para implementar el software al final de cada sprint, sin
romper a otros equipos.
 Cada equipo tiene una parte del software exclusivo suyo. Entre todos forman tribus o Tribe,
añadiendo distintos Squad o escuadrones.

Conclusiones
Las metodologías son aplicables solo en cierta medida, es bueno seguir las buenas prácticas y tratar de
planificar el mejor escenario, o ir combinándolas con otras más evolucionadas como es la Metodología
RUP Agile, pero por más mejorada que este, siempre vas a tener Stoppers y Semáforos Amarillos y Rojos,
y es que no hay una receta del éxito especifica de un proyecto, porque hay variables no controlables, sino
más bien lo veo como una herramienta que nos sirve para ir mejorando el proceso del proyecto, aplicar
metodologías(Ágiles, Espirales, Prototipadas, etc.) en pequeños grupos controlables es lo ideal y por lo
que hemos visto ha dado resultados.

También podría gustarte