Documentos de Académico
Documentos de Profesional
Documentos de Cultura
En la actualidad, los proyectos se desarrollan en contextos muy versátiles. Son más complejos que
antes, frente a unas exigencias del cliente y del mercado mucho más variables, y con una incertidumbre
elevada. Por eso, la aplicación del método Scrum se ha extendido como la pólvora en numerosos
sectores, fuera del mundo del desarrollo de software.
El desarrollo de producto tiene un ciclo de vida en la metodología Scrum. Estas son fases en las que
se divide un proceso Scrum:
• ¿Qué y quién? El producto que queremos conseguir una vez terminemos el Sprint, y los roles de
equipo con sus tareas asignadas.
• ¿Dónde y cuándo? El plazo y el contenido del Sprint.
• ¿Por qué y cómo? Las distintas herramientas para aplicar esta metodología ágil.
Cada Sprint puede tener una serie de eventos o etapas. Los más comunes son:
1. Reunión para la planificación del Sprint. En ella, se divide el tiempo de duración del Sprint, así
como el objetivo y entregable del mismo. Además, el equipo de desarrollo deberá saber cómo
realizarlo. Muy parecido a lo que llamamos reunión de Kick off y que puedes descubrir en este
curso gratis y online de gestión de proyectos.
2. Scrum diario. Se basa en poner en común y sincronizar actividades para elaborar el plan del día.
3. Trabajo de desarrollo durante el Sprint. Nos aseguramos que los objetivos se están cumpliendo,
que no se producen cambios que alteran el objetivo del Sprint y se mantiene un feedback
constante con el cliente o dueño del proyecto.
4. Revisión del Sprint. Reunión con el cliente o dueño del proyecto, en la que se estudia y revisa el
Product Backlog del Sprint. Se definen los aspectos a cambiar, en caso necesario, de mayor
valor o probables para planificarlo en el siguiente Sprint.
5. Retrospectiva del proyecto. Oportunidad del equipo de desarrollo para mejorar su proceso de
trabajo y aplicar los cambios en los siguientes Sprints.
Roles de Scrum
La metodología Scrum tiene unos roles y responsabilidades principales, asignados a sus procesos de
desarrollo. Estos son:
• Project Owner. Se asegura de que el proyecto se esté desarrollando acorde con la estrategia del
negocio. Escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
• Master Scrum o Facilitador. Elimina los obstáculos que impiden que el equipo cumpla con su
objetivo.
• Development team Member. Los encargados de crear el producto para que pueda estar listo
con los requerimientos necesarios. Se recomienda que sea un equipo multidisciplinar, de no más
de 10 personas. Sin embargo, empresas como Google disponen de unos 15.000 desarrolladores
trabajando en una rama del código. Y con una metodología Scrum. La automatización en el
testeo explica sobre por qué este gran volumen en el 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
—a pesar de que éste último está sufriendo una transformación importante a través del BIM y sus
líneas bases. Puedes saber más sobre las metodologías a usar según tu tipo de proyecto en la primera
lección del curso online y gratis de gestión de proyectos.
Incluso, en los propios proyectos tecnológicos ha habido algún que otro fracaso. Precisamente, Jeff
Sutherland, cocreador de Scrum y Asesor Senior y Coach de OpenView, explica las razones del fracaso
de Healthcare y del éxito de Spotify en esta entrevista que resumimos aquí.
Causas de fracaso de Healthcare.gov, proyecto del gobierno norteamericano para mostrar
transparencia en los seguros sanitarios.
• 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
Qué es SCRUM
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas
prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. 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.
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.
El proceso
En Scrum un proyecto se ejecuta en ciclos temporales cortos y de duración
fija (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos
son de 3 y hasta 4 semanas, límite máximo de feedback de producto real y
reflexión). Cada iteración tiene que proporcionar un resultado completo, un
incremento de producto final que sea susceptible de ser entregado con el mínimo
esfuerzo al cliente cuando lo solicite.
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa
como plan del proyecto. En esta lista el cliente (Product Owner) prioriza los
objetivos balanceando el valor que le aportan respecto a su coste (que el
equipo estima considerando la Definición de Hecho) y quedan repartidos en
iteraciones y entregas.
Las actividades que se llevan a cabo en Scrum son las siguientes (los tiempos
indicados son para iteraciones de 2 semanas):
Planificación de la iteración
El primer día de la iteración se realiza la reunión de planificación de la iteración.
Tiene dos partes:
1. Selección de requisitos (2 horas). El cliente presenta al equipo la lista de
requisitos priorizada del producto o proyecto. El equipo pregunta al cliente
las dudas que surgen y selecciona los requisitos más prioritarios que prevé
que podrá completar en la iteración, de manera que puedan ser entregados
si el cliente lo solicita.
2. Planificación de la iteración (2 horas). El equipo elabora la lista de tareas de
la iteración necesarias para desarrollar los requisitos seleccionados. La
estimación de esfuerzo se hace de manera conjunta y los miembros del
equipo se autoasignan las tareas, se autoorganizan para trabajar incluso en
parejas (o grupos mayores) con el fin de compartir conocimiento (creando
un equipo más resiliente) o para resolver juntos objetivos especialmente
complejos.
Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos), normalmente
delante de un tablero físico o pizarra (Scrum Taskboard). El equipo inspecciona el trabajo
que el resto está realizando (dependencias entre tareas, progreso hacia el
objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder
hacer las adaptaciones necesarias que permitan cumplir con la previsión de
objetivos a mostrar al final de la iteración. En la reunión cada miembro del equipo
responde a tres preguntas:
• ¿Qué he hecho desde la última reunión de sincronización para ayudar al
equipo a cumplir su objetivo?
• ¿Qué voy a hacer a partir de este momento para ayudar al equipo a cumplir
su objetivo?
• ¿Qué impedimentos tengo o voy a tener que nos impidan conseguir nuestro
objetivo?
Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para
prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican los objetivos del
proyecto (10%-15% del tiempo de la iteración) con el objetivo de maximizar la utilidad de lo que
se desarrolla y el retorno de inversión.
Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene
dos partes:
1. Revisión (demostración) (1,5 horas). El equipo presenta al cliente los requisitos
completados en la iteración, en forma de incremento de producto preparado
para ser entregado con el mínimo esfuerzo. En función de los resultados
mostrados y de los cambios que haya habido en el contexto del proyecto, el
cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la
primera iteración, replanificando el proyecto.
2. Retrospectiva (1,5 horas). El equipo analiza cómo ha sido su manera de
trabajar y cuáles son los problemas que podrían impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El
Facilitador se encargará de eliminar o escalar los obstáculos identificados
que estén más allá del ámbito de acción del equipo.
Ver en detalle las diferentes actividades, responsabilidades y herramientas en cómo funciona Scrum.
Compártelo:
• Object 1
• Object 2
• Object 3
• Object 4
• Correo electrónico
•
Object 5
Categorías
• calidad (6)
• como_empezar / transformación Agile (21)
• contratos_agiles (4)
• ejecución (2)
• ejemplos (11)
• entrevistas (4)
• escuela_secundaria (2)
• fundamentos (14)
• ingeniería (2)
• inspección_adaptación (6)
• métricas (5)
• personas / motivación / liderazgo (9)
• planificación_iteración (4)
• planificación_proyecto (13)
• recursos_externos (3)
• simulaciones y juegos (2)
• Sin categoría (28)
Entradas recientes
• Master en Agile – MMA 2019
• Cómo desescalar una organización – Un caso real
• Refactorización organizativa Agile – Parte 2
• Refactorización organizativa Agile – Parte 1
• Auto-organización – Fundamentos y relación con la motivación intrínseca
Comentarios recientes
Xavier Albaladejo en Métricas de iteración (Scrum s…
Suscríbete al RSS
• Registrarse
• Acceder
• de las entradas
• de los comentarios
• WordPress.com
Colaboraciones
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.
¿Cuándo se utiliza?
Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve
crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los
objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el
inicio de cada nueva iteración sin ningún problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma
parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus
capacidades.
Beneficios
• Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le
aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el
Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product
Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al
equipo.
• Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada
para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.
• Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más
importantes del proyecto antes de que esté finalizado por completo.
• Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión
funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.
• Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la
burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para
organizarse.
• Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de
inversión.
• Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo
por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar
fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el
Backlog.
• Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer
lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar
riesgos eficazmente de manera anticipada.
Si desea conocer más acerca de Scrum, consulte aquí cómo es el proceso y roles que intervienen.
En este artículo, resumo Qué Es la Metodología Scrum. Aquí encontrarás todo lo que necesitas saber
sobre el método Scrum
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. Los inspectores cualificados se aseguran de que todas las inspecciones se hacen de manera
correcta y son beneficiosas.
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.
Equipo Scrum
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.
Como equipos multifuncionales, tienen todas las competencias para para realizar el trabajo, sin
depender de otras personas fuera del equipo. El objetivo del equipo es optimizar la flexibilidad, la
creatividad y la productividad.
Los Equipos Scrum entregan productos de manera iterativa e incremental, aprovechando el feedeback
que les llega. Las entregas incrementales de productos “Finalizados” asegura que siempre está
disponible una versión funcional del producto. Si quieres conseguir un equipo óptimo, echa un vistazo
a estos dos artículos: “Cómo Conseguir un Gran Equipo Ágil” y “Cómo Llevar a Cabo una Reunión
Inicial de 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. Si te encuentras en la situación de
que eres el Scrum Master de dos equipos, echa un vistazo a: “Las Dos Preguntas más Importantes sobre
Liderar 2 Equipos como Scrum Master”.
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 Sprint
El corazón del método Scrum es el Sprint. Se puede definir como un periodo de tiempo de un mes o
menos en el que se crea un producto liberable, utilizable y “Finalizado”. Normalmente tienen una
duración consistente durante un periodo de desarrollo. Los sprints deberían tener duraciones constantes
durante todo el desarrollo. Un nuevo Sprint comienza solo cuando el anterior ha finalizado.
Los Sprints contienen y consisten de la Planificación del Sprint, los Scrums Diarios, la Revisión del
Sprint, la Retrospectiva del Sprint y el Trabajo de Desarrollo.
Cuando el Sprint está en curso, no debería haber ninguna alteración que pudiera afectar al objetivo del
mismo, los objetivos cualitativos no descienden, y el enfoque podría ser aclarado y renegociado entre el
Product Owner y el Equipo de Desarrollo.
Es seguro considerar cada Sprint como un proyecto de un mes en el que se ha de conseguir algo. Por
esta razón, en el Sprint se define claramente qué se va a construir, diseñar, un plan para la producción,
el trabajo y el producto final. Si el Sprint durara más de un mes, la definición de lo que se va a crear
cambiaría, y el riesgo podría subir junto a la complejidad general. Los Sprints son importantes ya que
aseguran que el trabajo es predecible y puede ser inspeccionado y adaptado mientras se trabaja por el
objetivo del Sprint. Limitan el riesgo, particularmente si nos fijamos en el coste.
Es posible cancelar un Sprint antes de que finalice. Sin embargo, la única persona que puede hacer esto
es el Product Owner. La decisión puede estar influenciada por otros, incluyendo las partes interesadas,
el Equipo de Desarrollo o el Scrum Master. Una cancelación puede hacerse efectiva cuando el Objetivo
del Sprint se vuelve obsoleto.
La obsolescencia puede estar causada por el azar en la dirección, las condiciones del mercado o las
condiciones de la tecnología. Si el Sprint deja de tener sentido, debería ser cancelado. Sin embargo,
verás que raramente se cancela un Sprint, ya que tienen una duración bastante corta.
Hay una serie de pasos que hay que cumplir al cancelar un Sprint. Se revisan primero los elementos
completados y “Finalizados” del Backlog de Producto. Si algo del trabajo del Sprint puede liberarse,
será aceptado por el Product Owner. Esos elementos que son incompetentes en el backlog de Producto
se reestiman y devuelven al Backlog de Producto. Ya que este tipo de trabajo se puede depreciar
rápidamente, se debe revalorar frecuentemente.
Las cancelaciones desaniman, ya que consumen recursos. Esto se debe a que todas las personas
envueltas en el Sprint tienen que reagruparse y realizar otro proceso de planificación del Sprint, para
comenzar uno nuevo. Causan malestar en el equipo y se trata de evitarlas.
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. Los inspectores cualificados se aseguran de que todas las inspecciones se hacen de manera
correcta y son beneficiosas.
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.
Equipo Scrum
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.
Como equipos multifuncionales, tienen todas las competencias para para realizar el trabajo, sin
depender de otras personas fuera del equipo. El objetivo del equipo es optimizar la flexibilidad, la
creatividad y la productividad.
Los Equipos Scrum entregan productos de manera iterativa e incremental, aprovechando el feedeback
que les llega. Las entregas incrementales de productos “Finalizados” asegura que siempre está
disponible una versión funcional del producto. Si quieres conseguir un equipo óptimo, echa un vistazo
a estos dos artículos: “Cómo Conseguir un Gran Equipo Ágil” y “Cómo Llevar a Cabo una Reunión
Inicial de 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. Si te encuentras en la situación de
que eres el Scrum Master de dos equipos, echa un vistazo a: “Las Dos Preguntas más Importantes sobre
Liderar 2 Equipos como Scrum Master”.
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.
Valores de 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
Entendiendo el Sprint
El corazón del método Scrum es el Sprint. Se puede definir como un periodo de tiempo de un mes o
menos en el que se crea un producto liberable, utilizable y “Finalizado”. Normalmente tienen una
duración consistente durante un periodo de desarrollo. Los sprints deberían tener duraciones constantes
durante todo el desarrollo. Un nuevo Sprint comienza solo cuando el anterior ha finalizado.
Los Sprints contienen y consisten de la Planificación del Sprint, los Scrums Diarios, la Revisión del
Sprint, la Retrospectiva del Sprint y el Trabajo de Desarrollo.
Cuando el Sprint está en curso, no debería haber ninguna alteración que pudiera afectar al objetivo del
mismo, los objetivos cualitativos no descienden, y el enfoque podría ser aclarado y renegociado entre el
Product Owner y el Equipo de Desarrollo.
Es seguro considerar cada Sprint como un proyecto de un mes en el que se ha de conseguir algo. Por
esta razón, en el Sprint se define claramente qué se va a construir, diseñar, un plan para la producción,
el trabajo y el producto final. Si el Sprint durara más de un mes, la definición de lo que se va a crear
cambiaría, y el riesgo podría subir junto a la complejidad general. Los Sprints son importantes ya que
aseguran que el trabajo es predecible y puede ser inspeccionado y adaptado mientras se trabaja por el
objetivo del Sprint. Limitan el riesgo, particularmente si nos fijamos en el coste.
Es posible cancelar un Sprint antes de que finalice. Sin embargo, la única persona que puede hacer esto
es el Product Owner. La decisión puede estar influenciada por otros, incluyendo las partes interesadas,
el Equipo de Desarrollo o el Scrum Master. Una cancelación puede hacerse efectiva cuando el Objetivo
del Sprint se vuelve obsoleto.
La obsolescencia puede estar causada por el azar en la dirección, las condiciones del mercado o las
condiciones de la tecnología. Si el Sprint deja de tener sentido, debería ser cancelado. Sin embargo,
verás que raramente se cancela un Sprint, ya que tienen una duración bastante corta.
Hay una serie de pasos que hay que cumplir al cancelar un Sprint. Se revisan primero los elementos
completados y “Finalizados” del Backlog de Producto. Si algo del trabajo del Sprint puede liberarse,
será aceptado por el Product Owner. Esos elementos que son incompetentes en el backlog de Producto
se reestiman y devuelven al Backlog de Producto. Ya que este tipo de trabajo se puede depreciar
rápidamente, se debe revalorar frecuentemente.
Las cancelaciones desaniman, ya que consumen recursos. Esto se debe a que todas las personas
envueltas en el Sprint tienen que reagruparse y realizar otro proceso de planificación del Sprint, para
comenzar uno nuevo. Causan malestar en el equipo y se trata de evitarlas.
Planificación del Sprint
Cualquier trabajo que va a hacerse en el Sprint se planea en la Planificación del Sprint. La planificación
une al Equipo Scrum y se crea mediante un trabajo colaborativo. La planificación del Sprint tiene una
duración concreta de ocho horas como máximo para un Sprint de un mes; aquí puedes encontrar
sugerencias sobre cómo llevar a cabo una efectiva planificación del sprint.
Cuando el Sprint dura menos, también el evento tiene a ser más corto. Depende del Scrum Master
asegurar que el evento tiene lugar y que los asistentes entienden la razón del mismo. El Scrum Master
enseñará al equipo a mantenerse en la duración establecida.
En la Planificación se responden las preguntas sobre qué se puede liberar en el Incremento del siguiente
Sprint, y cómo se conseguirá realizar el trabajo que se va a liberar.
Scrum Diario
Cada día, el Equipo de Desarrollo deja 15 minutos para sincronizar sus actividades y desarrollar un
plan para las siguientes 24 horas. Esto se conoce como el Scrum Diario. Incluye una inspección del
trabajo que se ha hecho desde el anterior Scrum Diario y posteriormente se enfatiza sobre el trabajo que
ha de realizarse antes del siguiente.
Es esencial que la hora y el lugar del Scrum Diario sean siempre iguales, ya que esto evitará cualquier
complejidad. En la reunión, el Equipo de Desarrollo se centrará en:
• Qué se hizo el día anterior que ayudó a alcanzar el Objetivo del Sprint
• Qué se ha hecho hoy para ayudar a alcanzar el Objetivo del Sprint
• Qué impedimentos pueden poner trabas a la consecución del Objetivo del Sprint
•
Esto significa que el Scrum Diario es como una manera de chequear el grado de consecución del
Objetivo del Sprint. Asegura que el trabajo se basa en el Backlog del Sprint y facilita la tarea de
alcanzar el objetivo. Se desafía al Equipo de Desarrollo durante el Scrum Diario a trabajar
conjuntamente como un equipo auto-organizado a través de discusiones detalladas, en las cuales puede
que tengan que adaptar o repetir el trabajo del resto del Sprint.
Es el Scrum Master quien asegura que esta reunión se realiza a diario, aunque está dirigida por el
Equipo de Desarrollo. Los Scrum Masters aseguran que el equipo no se sobresale de los 15 minutos, y
hacen cumplir las reglas de participación.
Los beneficios del Scrum Diario son numerosos, incluyendo la mejora en la comunicación, la no
necesidad de otras reuniones, la identificación de trabas al desarrollo, la rápida toma de decisiones y el
aumento del conocimiento general del Equipo de Desarrollo. Hace un tiempo escribí un artículo sobre
“Cómo llevar a cabo un Scrum Diario efectivo”, al que puedes echar un vistazo.
El Scrum Master usará esta reunión para animar al Equipo Scrum a mejorar en las prácticas y procesos
del desarrollo. Esto asegurará que el siguiente Sprint sea más efectivo y disfrutable. Se implementan
los planes para elevar la calidad del producto, estableciendo una definición apropiada de producto
“Finalizado”.
Una vez que se ha completado la Retrospectiva del Sprint, el Equipo Scrum habrá identificado qué se
puede mejorar en el siguiente Sprint. Se adoptarán estas mejoras y serán inspeccionadas por el propio
Equipo Scrum. La Retrospectiva del Sprint es una oportunidad formal de centrarse en la inspección y la
adaptación.
Si te interesa este tema, puedes echar un vistazo a mi otro artículo: “La Guía Sobre Las Retrospectivas
Ágiles Que Te Convertirá En Un Magnífico Facilitador”. Mi amigo Marc Loeffler escribió este
artículo: “Las cinco preguntas más comunes sobre las Retrospectivas Ágiles”. Y, por supuesto, si
buscas nuevas ideas para tu Retrospectiva del Sprint, echa un vistazo a: “Ideas sobre las Retrospectivas
Ágiles”.
Elementos de Scrum
Representan el trabajo o valor para proporcionar transparencia, así como oportunidades para la
inspección y la adaptación. Se definen como específicamente diseñadas para maximizar la
transparencia sobre la información clave, de manera que todos tienen el mismo conocimiento del
elemento en cuestión.
El Backlog de Producto
Esto se refiere a una lista ordenada de todas las cosas que se requieren para desarrollar un producto.
Contiene todos los requisitos para cualquier corrección que se tenga que hacer a un producto; el
responsable de ello es el Product Owner.
Es un trabajo en progreso (WIP), y no llega a tener nunca una versión final. Establece los requisitos y
evoluciona a la vez que el producto. Sufre cambios basándose en qué es más conveniente, útil y
competitivo para el producto y existirá mientras que exista el producto.
Contiene una lista de todas las funciones, requisitos, características, mejoras y arreglos, que constituyen
los cambios que tienen que realizarse al producto en la siguiente release. Los elementos del Backlog
del Producto tienen una descripción, orden, estimación y valor.
Cuanto más se use el producto, y obtenga valor, más feedback puede esperarse del mercado. Esto
resultará en el crecimiento del Backlog del Producto, al mismo tiempo que los requisitos evolucionan.
También puede sufrir cambios basados en los requisitos de negocio, condiciones del mercado y la
tecnología.
Donde hay muchos Equipos Scrum, puede que necesiten trabajar juntos en un producto. En Este caso,
solo un Backlog de Producto será utilizado para describir el producto. Para refinar el Backlog del
producto, los detalles, las estimaciones y el orden de los elementos podría ser modificado.
Esto lo realizan mediante la colaboración el Product Owner y el Equipo de Desarrollo. Mientras se
refina, también se revisan los elementos que se quedan dentro. Es el Equipo Scrum quien decide cómo
se realizará el perfeccionamiento, de manera que no se coja más del 10% de la capacidad del Equipo de
Desarrollo. El Product Owner tiene la capacidad de actualizar los elementos del Backlog del Producto
en cualquier momento.
Hay elementos del Backlog del Producto ordenados más arriba y otros más abajo, siendo los que están
más arriba los más aclarados y detallados. Son los que están arriba los elementos que pueden ser
“Finalizados” por el Equipo de Desarrollo, y pueden ser considerados como “Listos” para la selección
en la Planificación del Sprint.
El Equipo de Desarrollo es responsable de todas las estimaciones, ya que son los que van a realizar el
trabajo.
Incremento
Se puede resumir todo el trabajo que resta del Backlog del Sprint en cualquier momento. El Incremento
es la suma de esto y del valor de cualquier otro Incremento de Sprints previos. El incremento final al
terminar el Sprint debería estar “Finalizando”, que significa que está en una condición utilizable y
cumple con la definición establecida por el Equipo Scrum. La condición utilizable es indispensable, sea
cual sea la decisión del Product Owner de lanzarlo o no.
Transparencia en los Elementos
Para que el método Scrum sea como es, la transparencia es esencial. Es la base de las decisiones que se
toman para optimizar el valor y el control del riesgo. El grado de cumplimiento de la transparencia
determina si las decisiones son correctas o no. Si los elementos no son completamente transparentes,
entonces las decisiones tienen defectos y su valor disminuye. Además, el riesgo aumentará.
El Scrum Master debe trabajar con todas las partes participantes, incluyendo el Product Owner y el
Equipo de Desarrollo, para asegurar que los elementos son totalmente transparentes. En el caso de que
no exista una fuerte transparencia, hay prácticas para salir adelante.
El Scrum Master debe a ayudar a todos a aplicar las prácticas más apropiadas para conseguir una buena
transparencia. Un Scrum Master puede detectar una transparencia incompleta mediante la inspección
de los elementos, el razonamiento sobre los patrones y la observación cuidadosa de toda la información
disponible.
Desde aquí, se pueden detectar las diferencias entre los resultados reales y los esperados. El Scrum
Master ha de trabajar con el Equipo Scrum y la organización para aumentar la transparencia de los
elementos. Esto se consigue mediante el aprendizaje, el convencimiento y los cambios, y requiere un
largo camino.
Definición de “Finalizado”
El término “Finalizado” ha aparecido bastantes veces en este texto. Cuando se dice que un elemento del
backlog del Producto o un Incremento está “Finalizado”, es muy importante que todas las partes
involucradas entiendan el significado.
Está directamente relacionado con completar el trabajo y asegura que existe transparencia. Para el
Equipo Scrum, “Finalizado” significa que el trabajo está completado en el Incremento del producto.
Hace un tiempo, escribí un ejemplo de una “Checklist de la Definición de Finalizado”. Es esta la
definición que servirá como guía para el Equipo de Desarrollo en el número de elementos del Backlog
del Producto que deberían seleccionarse durante la Planificación del Sprint. La razón de existencia de
cada Sprint es entregar Incrementos de funcionalidades potencialmente liberables que cumplan con la
definición de “Finalizado” del Equipo Scrum.
Con cada Sprint, el Equipo de Desarrollo debería entregar un Incremento de funcionalidades del
producto. Es utilizable y un Product Owner podría decidir lanzarlo inmediatamente. En el evento en el
cual la definición de “Finalizado” para un Incremento es parte de las costumbres o estándares de la
organización de desarrollo, entonces todos los Equipos Scrum deben seguirla.
En el evento en el cual la definición de “Finalizado” no es un estándar de la organización de desarrollo,
entonces se pide al Equipo de Desarrollo del Equipo Scrum traer una definición de “Finalizado” que
vaya en la línea del producto. Allí donde hay muchos Equipos Scrum trabajando en el lanzamiento del
producto, los Equipos de Desarrollo de todos ellos deben definir mutuamente el término “Finalizado”.
Cada Incremento es acumulable a los Incrementos anteriores y se prueba minuciosamente. Esto asegura
que todos trabajan conjuntamente.
A la vez que los Equipos Scrum maduran, sus definiciones de “Finalizado” se expanden para incluir
más criterios. Aquí presento algunas sugerencias para empezar con este acercamiento. Todos los
sistemas y productos necesitan una definición de “Finalizado”, que es el estándar que se aplica al
trabajo realizado en ellos.
Creo que esto resume todo acerca de “Qué Es La Metodología Scrum”. Puedes comentar debajo lo que
te apetezca.
Eduardo Martínez
¿Sabes qué es la metodología Scrum? La gestión de procesos y equipos es una de las partes más
complicadas para cualquier empresa. No se trata solo de recursos. La optimización del tiempo,
coordinación del equipo, definición de protocolos y la asignación de tareas es un asunto de peso, que
requiere de conocimiento, buen criterio y mucho tiempo para su implementación.
Índice de contenido:
• ¿Qué perfiles intervienen en la metodología Scrum?
• ¿Cómo funciona la metodología Scrum?
• ¿Cómo son las reuniones con la metodología Scrum?
• ¿Qué ganamos con la metodología Scrum?
¿A qué lleva la falta de planificación? Sobrecostes, retrasos en la entrega de proyectos, conflicto con
los clientes u otros departamentos. ¿Y el uso de procesos anticuados? La diferencia de criterios entre
los propios integrantes a la hora de realizar su trabajo, la falta de unificación de herramientas o la
disgregación de procesos de trabajo lleva a malgastar tiempo, dinero y, en último término, a la
desmotivación del equipo.
¿Lleva tiempo esta planificación e implementación de nuevas técnicas? Sí. ¿Compensan? Si
analizamos los costes indirectos de una mala gestión, no hay duda de que la respuesta es sí.
Como respuesta a esta problemática surgen las metodologías ágiles. Nuevos sistemas de gestión que
apuestan por una gestión dinamizada y muy coordinada de los procesos para llevar a un nivel óptimo el
uso que demos a nuestros recursos.
¿En qué consiste exactamente? La metodología Scrum permite abordar proyectos complejos
desarrollados en entornos dinámicos y cambiantes de un modo flexible. Está basada en entregas
parciales y regulares del producto final en base al valor que ofrecen a los clientes.
Es una opción de gestión ideal para acometer proyectos desarrollados en entornos complejos que
exigen rapidez en los resultados y en los que la flexibilidad es un requisito imprescindible. Scrum
ofrece agilidad y el, resultado, siempre, valor.
Para que puedas tener una visión más global de Scrum y su implantación, aquí encontrarás un resumen
original de Jeff Shuterland (Creador de SCRUM) de lo que necesitas para poner en marcha un proyecto
Scrum.
Si no te apetece leer mucho puedes ver un video de nuestro curso sobre gestión de proyectos mediante
Scrum.
Es un descripción rápida de todo el proceso, pero te va a venir de maravilla para poder empezar con el
«cómo se hace en scrum». ¡Menos rollos y mas madera!
6. Planificación de sprints.
Ésta es la primera reunión Scrum. El equipo, el Scrum Master y el responsable de producto se sientan a
planificar el sprint.
Los sprints siempre duran una cantidad determinada de tiempo, que es menos de un mes.
Habitualmente, casi todo el mundo hace sprints de una o dos semanas. El equipo mira el principio de la
lista de objetivos pendientes y hace una previsión de cuánto pueden tener terminado en este sprint. Si el
equipo ya ha hecho algún sprint, deberían tener en cuenta los puntos que hicieron en el último. Ese
número se conoce como la velocidad del equipo. El Scrum Master y el equipo deberían estar siempre
intentando aumentar esa cifra en cada sprint. También es el momento para que el equipo y el
responsable de producto se aseguren de que todo el mundo entiende exactamente cómo estos ítems van
a lograr crear la visión. Además, en esta reunión todos deben ponerse de acuerdo en la meta, lo que
todos quieren lograr en ese sprint.
Uno de los pilares del Scrum es que una vez que el equipo se ha comprometido con lo que creen que
pueden terminar en un sprint, no hay vuelta atrás. No se puede cambiar y no se le puede añadir nada. El
equipo tiene que ser capaz de trabajar de forma autónoma durante todo el sprint, para terminar lo
que previeron que podían hacer.
Pues ahí es nada, cientos de horas de reflexión concentradas en 11 puntos. Espero que sea de tu ayuda y
puedas implementar con éxito el SCRUM.
La metodología Scrum es un marco simple que facilita la colaboración en equipo en proyectos
complejos. Se trata de un enfoque de trabajo muy sencillo, aunque su implementación en la práctica no
suele serlo tanto.
Scrum enfatiza el trabajo en equipo, haciendo hincapié en la rendición de cuentas y la necesidad de
abordar las tareas en base a iteraciones.
La claridad de los objetivos es crucial para avanzar hacia una versión cada vez mejor y más
completa de los entregables. Scrum es parte del desarrollo de software ágil aunque, a día de hoy, se
trata de un método que muchas compañías de diferentes sectores han incluido como parte de su
estrategias
Scrum es reconocida por ser la metodología ágil más prestigiosa internacionalmente en el sector
empresarial. De ella sabemos la rápida aceptación que ha tenido desde su creación, en el año 1992,
cuando el teórico norteamericano Jeff Sutherland sentó las bases para su posterior desarrollo.
Durante muchos años Scrum ha liderado el denominado grupo agile, es decir, una categoría en la que
se agrupan las metodologías que surgieron en las últimas dos décadas como respuesta a los modelos
tradicionales de gestión.
También sabemos de sus excelentes resultados en distintas áreas empresariales, sobre todo cuando se
trata de gestionar proyectos demasiado complejos o que requieran la ejecución de actividades
simultáneas.
Contents [hide]
• 1 ¿Qué es Scrum?
• 2 ¿Cómo aplicar la metodología Scrum para proyectos?
• 3 Implementación de la metodología Scrum
• 4 Scrum: ventajas y desventajas del modelo
• 4.1 1) Usos y ventajas:
• 4.2 2) Limitaciones:
¿Qué es Scrum?
El marco de trabajo que propone Scrum es un método ágil en base al cual se proporcionan
descripciones completas y detalladas de cómo hacer que todo salga adelante dentro de un
proyecto. Se trata de decisiones consensuadas en las que participa todo el equipo, puesto que sus
integrantes son los que, por su experiencia y formación, mejor pueden conocer las diferentes formas de
resolver cualquier problema que se pueda presentar.
Scrum está relacionado con un equipo autoorganizado y multifuncional, donde destacan figuras
como el ScrumMaster, que es quien ayuda al equipo a lograr trabajar al máximo rendimiento, y el
propietario del producto, que es quien representa el negocio, los clientes o usuarios, y guía al equipo
hacia la construcción del producto correcto.
1) Usos y ventajas:
Scrum es una propuesta de gestión basada en la división del trabajo en iteraciones, es decir, fases con
objetivos y tareas específicas. Esto hace que necesariamente aporte beneficios en aspectos como los
siguientes:
• Gestión de las expectativas de los clientes. Los clientes pueden participar en cada una de las
iteraciones y proponer soluciones. De hecho, el proceso en su conjunto está pensado para un
tipo de evaluación conjunta.
• Resultados anticipados. Cada iteración arroja una serie de resultados. No es necesario, por
tanto, que el cliente espere hasta el final para ver el producto.
• Flexibilidad y adaptación a los contextos. Se adapta a cualquier contexto, área o sector de la
gestión. No es una técnica exclusiva de ninguna disciplina.
• Gestión sistemática de riesgos. Del mismo modo, los riesgos que pueden afectar a un proyecto
son gestionados en el mismo momento de su aparición. La intervención de los equipos de
trabajo es inmediata.
2) Limitaciones:
Pero ojo, antes de que te decidas por esta metodología de gestión, viene bien que mires las siguientes
limitaciones en cuanto a su implementación:
• Funciona sobre todo con equipos reducidos. Las empresas grandes, por ejemplo, deben estar
sectorizadas o divididas en grupos con objetivos concretos. De lo contrario, el efecto de la
técnica se perderá.
• Requiere una exhaustiva definición de las tareas y sus plazos. Cuando estos dos aspectos no
se definen adecuadamente, Scrum se desvanece. Recuerda que la división del trabajo en
iteraciones (y de éstas en tareas específicas) son la esencia de esta metodología.
• Exige una alta cualificación o formación. No es una modalidad de gestión propia de grupos
junior o que apenas estén en proceso de formación. Gran parte del éxito de Scrum radica en la
experiencia que aportan los profesionales de los equipos, quienes por lo general acumulan años
de experiencia.
¿Cuáles son las ventajas y desventajas de
agile/scrum?
3 respuestas
Bueno esta Metodologías Ágil para proyectos tienen muchas ventajas y desventajas, primero que nada
no solo es para el desarrollo de software, sino también es aplicable a distintos proyectos de tecnología y
por que no, en otras áreas, ahora cito las principales conocidas y luego te doy un plus especial de mi
experiencia:
Ventajas:
• Entregables en tiempo y forma, puedes ir enviando entregables al cliente mientras vas atacando
los objetivos mas sencillos, eso te hace ganar tiempo para atacar los objetivos mas 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 cansador 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 especifico y afecta a todo el proyecto.
• No es aplicable a grandes escalas o cuando el sector IT es variado.
Mi opinión personal y experiencia: Las metodologías son aplicables solo en cierta medida, es bueno
seguir las buenas practicas y tratar de planificar el mejor escenario, o ir combinándolas con otras
mas evolucionadas como es la Metodología RUP Agile, pero por más mejorada que este, siempre vas a
tener Stoppers y Semaforos Amarillos y Rojos, y es que no hay una receta del éxito especifica de un
proyecto, por que hay variables no controlables, sino mas 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 lo que me ha dado resultados.
ratare de ser breve, Scrum tiene muchas ventajas y también desventajas
Ventajas
• Mejora la comunicación entre los integrantes del equipo de desarrollo y el resto de la compañia:
Esto es debido a promocion de pocas reuniones pero efectivas (time boxing)
• Evita el Context Change: El equipo de desarrollo toma la decision en que va a trabajar durante
el Sprint sin interrupciones por parte de factores externos.
• Promueve la agilidad: Si un requerimiento esta ambiguo o muy grande, éste se rechaza ya que
no cumple con la definicion de listo (Definition of Ready) . En su lugar se entrega lo que es
posible durante un Sprint y el cliente puede familiarizarse.
• Reduce el Riesgo: Se entrega el resultado del sprint y el Product Owner puede rapidamente ver
el resultado, si éste no es suficiente se puede tomar alguna acción (Fail Fast)
Desventajas
• Desarrolladores que se esconden: Debido a que es el equipo de desarrollo el responsable, puede
darse que desarrolladores con poca experiencia o mala actitud (funciona en mi PC, no es mi
problema), se escondan detras y no aporten nada al proyecto.
• Poca importancia a las técnicas ágiles: Scrum no dice nada acerca de tecnicas agiles como por
ejemplo: Unit Testing, CI, Code Review, Funtional Testing, etc. Entonces el equipo tiende a no
trabajar en actividades no directamente relacionadas - ya que estos esfuerzos no tienen
visibilidad con la administración -
Mi opinión personal es que antes de una iniciativa Scrum en la compañia deberá previamente trabajarse
en actividades de integración de equipos. Promover un ambiente para Geeks.
Obviamente en unas industria como la banca, seguros y gobierno donde dar la impresión de mantener
las cosas bajo control es mas importante que la calidad del producto final, no es buena idea utilizar
Scrum ya que las personas tienden a simplemente decir que hacen Scrum solo para complacer a la
administración y a la larga les quita tiempo valioso. En un Startup por otro lado, yo utilizaria KanBan
ya que es menos estricto que Scrum
Ventajas
• Reduce la aparición de riesgos: Al ser dividido e entregables, los errores y los cambios se hacen
en diferentes etapas del proyecto.
• El producto se lanza al mercado con mayor rapidez: Quizás no el producto completo, pero si las
características más importantes.
• Máxima productividad: Roles definidos acorta los tiempos al máximo.
Desventajas
• Puntualidad: Como en todas las metodologias de proyectos agiles, el ofrecer puntualidad es un
arma de doble filo.
• Susceptibilidad a la ausencia de un miembro: Si cualquier persona de cualquier equipo falta o
falla, todo el trabajo se atrasa.
• Limitado por tamaño: Es recomendado aplicarlo solo en equipos pequeños y medianos y con
proyectos de tamaño moderado.
En definitiva, la metodologia Scrum debe ser conocida por todos los equipos de desarrollo de software
que quiere tener éxito en proyectos con entregas a corto plazo.