UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO

METODOLOGÍAS KANBAN Y SCRUM

PARA EL DESARROLLO DE PROCESOS
ÁGILES
TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE
DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN I

Elaborado por: Licelia Rojas Claros

Tutor: Ing. Edson Ariel Terceros Torrico

Cochabamba – Bolivia
2018

1
 ÍNDICE DE CONTENIDO

RESUMEN .................................................................................................................................... 5
INTRODUCCIÓN .......................................................................................................................... 6
1 GENERALIDADES .................................................................................................................... 7
1.1 ANTECEDENTES GENERALES........................................................................................ 7
1.1.1 EL MANIFIESTO ÁGIL ................................................................................................. 7
1.1.2 LOS 12 PRINCIPIOS DEL MANIFIESTO ÁGIL .......................................................... 8
1.2 ANTECEDENTES ESPECÍFICOS ..................................................................................... 9
2 METODOLOGÍA ........................................................................................................................ 9
3 CYNEFIN ................................................................................................................................. 10
3.1 DOMINIO SIMPLE ............................................................................................................ 10
3.2 DOMINIO COMPLICADO ................................................................................................. 11
3.3 DOMINIO COMPLEJO ..................................................................................................... 11
3.4 DOMINIO CAÓTICO ......................................................................................................... 12
3.5 DOMINIO DESORDENADO ............................................................................................. 12
4 METODOLOGÍA KANBAN ...................................................................................................... 12
4.1 INTRODUCCIÓN .............................................................................................................. 13
4.2 QUE ES KANBAN ............................................................................................................. 13
4.3 PRINCIPIOS DE LA METODOLOGÍA KANBAN.............................................................. 13
4.3.1 CALIDAD GARANTIZADA ......................................................................................... 13
4.3.2 REDUCCIÓN DEL DESPERDICIO ........................................................................... 14
4.3.3 MEJORA CONTINUA................................................................................................. 14
4.3.4 FLEXIBILIDAD ............................................................................................................ 14
4.4 PRINCIPALES PASOS EN KANBAN ............................................................................... 14
4.4.1 DEFINIR EL FLUJO DE TRABAJO DE LOS PROYECTOS ..................................... 14
4.4.2 VISUALIZAR LAS FASES DEL CICLO DE PRODUCCIÓN ..................................... 15
4.4.3 LÍMITES DE TRABAJO EN PROGRESO ................................................................. 16
4.4.4 CONTROL DEL FLUJO ............................................................................................. 16
4.5 TABLEROS KANBAN ....................................................................................................... 17
4.5.1 ELEMENTOS DEL TABLERO KANBAN ................................................................... 18
4.5.2 TABLERO DIGITAL KANBAN.................................................................................... 19
4.5.3 TABLERO FÍSICO KANBAN...................................................................................... 20
4.6 TARJETAS KANBAN ........................................................................................................ 21
5 METODOLOGÍA SCRUM ........................................................................................................ 22
5.1 INTRODUCCIÓN .............................................................................................................. 22
5.2 SCRUM ............................................................................................................................. 23
5.3 PILARES DE SCRUM ....................................................................................................... 23
5.4 CARACTERÍSTICAS DE SCRUM .................................................................................... 24
5.5 ROLES DE SCRUM .......................................................................................................... 24
5.5.1 PRODUCT OWNER ................................................................................................... 25
5.5.2 SCRUM MASTER ...................................................................................................... 26

2
 5.5.3 DEVELOPMENT TEAM ............................................................................................. 27
5.6 ACTIVIDADES Y ARTEFACTOS ..................................................................................... 28
5.6.1 ACTIVIDADES DE SCRUM ....................................................................................... 29
a) SPRINT ........................................................................................................................... 30
b) SPRINT PLANNING ........................................................................................................ 30
b.1) ESTIMACIÓN DEL SPRINT ........................................................................................ 32
c) DAILY SCRUM ................................................................................................................ 32
d) SPRINT REVIEW ............................................................................................................ 33
e) SPRINT RETROSPECTIVE ........................................................................................... 34
5.6.2 ARTEFACTOS DE SCRUM ....................................................................................... 35
a) PRODUCT BACKLOG .................................................................................................... 35
a.1) HISTORIAS DE USUARIO .......................................................................................... 37
b) SPRINT BACKLOG ......................................................................................................... 38
c) INCREMENTO ................................................................................................................ 40
6 METODOLOGÍA SCRUMBAN ................................................................................................ 40
6.1 SCRUMBAN ...................................................................................................................... 40
6.2 PRACTICAS DEL MÉTODO KANBAN SOBRE SCRUM ................................................ 41
6.3 TABLEROS SCRUMBAN ................................................................................................. 43
6.4 BENEFICIOS DE SCRUMBAN ........................................................................................ 44
7 KANBAN VS SCRUM .............................................................................................................. 44
7.1 INTRODUCCIÓN .............................................................................................................. 45
7.2 DIFERENCIAS .................................................................................................................. 46
7.3 SEMEJANZAS .................................................................................................................. 47
7.4 APLICACIÓN PRÁCTICA ................................................................................................. 48
8 CONCLUSIONES .................................................................................................................... 48
9 RECOMENDACIÓN ................................................................................................................ 49
10 BIBLIOGRAFÍA ...................................................................................................................... 50

3
 ÍNDICE DE ILUSTRACIONES Y TABLAS

Ilustración 1: Manifiesto por el Desarrollo Ágil de Software. .................................................... 8

Ilustración 2: Cynefin, la complejidad que nos rodea. ............................................................. 10
Ilustración 3: Flujo de trabajo de Kanban ................................................................................. 15
Ilustración 4: Tablero Kanban y sus Elementos. ...................................................................... 19
Ilustración 5: Tablero digital Kanban. ....................................................................................... 20
Ilustración 6: Tablero físico Kanban. ........................................................................................ 21
Ilustración 7: Roles de Scrum................................................................................................... 25
Ilustración 8: Product Owner. ................................................................................................... 26
Ilustración 9: Scrum Master. ..................................................................................................... 27
Ilustración 10: Development Team........................................................................................... 28
Ilustración 11: Actividades y Artefactos de Scrum. .................................................................. 29
Ilustración 12: Sprint Planning. ................................................................................................. 31
Ilustración 13: Daily Scrum. ...................................................................................................... 33
Ilustración 14: Sprint Review. ................................................................................................... 33
Ilustración 15: Sprint Retrospective.......................................................................................... 34
Ilustración 16: Product Backlog. ............................................................................................... 35
Ilustración 17: Ejemplo de Product Backlog inicial. ................................................................. 36
Ilustración 18: Ejemplo de Product Backlog final. .................................................................... 36
Ilustración 19: Ejemplo de Sprint Backlog................................................................................ 39
Ilustración 20: Tablero Scrumban. ........................................................................................... 44
Ilustración 21: Scrum vs Kanban. ............................................................................................. 45

Tabla 1: Diferencias de Scrum y Kanban. ..................................................................... 46

4
 METODOLOGÍAS KANBAN Y SCRUM
PARA EL DESARROLLO DE PROCESOS ÁGILES

RESUMEN

En esta ocasión se hablará de las metodologías Kanban y Scrum para el desarrollo de

procesos ágiles. Esto en el sentido de cómo llevan a cabo la gestión durante el
desarrollo de un proyecto, también haremos notar la importancia que tiene la unión de
estas dos metodologías para un óptimo progreso en el desarrollo de proyectos, que se
llegó a denominar Scrumban, y por ultimo veremos las diferencias y similitudes que
existen entre las metodologías Kanban y Scrum.

Palabras clave: Scrum, Kanban, Scrumban, Metodologías, Agiles.

5
INTRODUCCIÓN

A la hora de desarrollar un proyecto uno de los primeros pasos que se debe hacer, es
seleccionar el método de desarrollo de software efectivo, esto parece algo complicado
teniendo en cuenta que hay muchos modelos de desarrollo de software desde las
metodología tradicionales o estáticos como por ejemplo el Proceso Unificado Racional
(Rational Unified Procces) o RUP, Microsoft Solution Framework o MSF, Cascada,
Espiral, etc., hasta las metodologías ágiles como Programación Extrema (Extreme
Programming) o XP, Scrum, Crystal Clear, Kanban, etc.
Según (The Blokehead, 2016, págs. 7-8)

En esta ocasión solamente se hablará de dos metodologías ágiles muy efectivas para
el desarrollo de proyectos que son Kanban y Scrum. Sobre Kanban se analizará sus
principios y los pasos que se lleva a cabo y sobre todo de los tableros Kanban y sus
tarjetas. Sobre Scrum se analizará al equipo de trabajo y los roles que deben realizar,
además de sus elementos y sus artefactos.

Teniendo en claro como es el comportamiento de estas metodologías durante el

periodo de desarrollo de procesos se podrá ver que es muy beneficioso trabajar con
estos métodos.
No se tomará en cuenta la parte de su aplicación sobre un proyecto de ninguno de los
dos métodos, al menos que sean imágenes de ejemplo.

Este documento contribuirá a que las personas tengan un conocimiento general de las
metodologías ágiles Kanban y Scrum, para el proceso de desarrollo de software.

6
1 GENERALIDADES

1.1 ANTECEDENTES GENERALES

El software es un producto empírico, por lo que es un error adoptar procesos

prescriptivos rígidos en proyectos de software, las metodologías ágiles reconocen la
metodología empírica del software y están preparadas para acoger los cambios
frecuentes, ofrecen rapidez para realizar los cambios idóneos a partir de la
retroalimentación (feedback) de los usuarios y se presentan como metodologías leves,
enfocadas al software funcional en vez del formalismo y de la documentación extensa.
Según (Fuentes, pág. 8)

1.1.1 EL MANIFIESTO ÁGIL

El manifiesto ágil surge por la urgencia de salir de las prácticas tradicionales y

monótonas. Donde Kent Beck y 16 personas más se reunieron para discutir sobre el
desarrollo de software. Estos profesionales con una dilatada experiencia llevaban ya
alrededor de una década utilizando técnicas que le fueron posicionando como líderes
de la industria del desarrollo de software. Conocían perfectamente las desventajas del
clásico modelo en cascada donde lo primero que se hace es un análisis, luego se
diseña, después se implementa y por último en algunos casos se escriben algunos test
automáticos donde se martiriza a un grupo de personas para que ejecuten
manualmente el software, una y otra vez hasta la saciedad.

El manifiesto ágil se compone de cuatro principios.

• Individuos e iteraciones sobre procesos y herramientas.

• Software que funciona sobre documentación exhaustiva.
• Colaboración con el cliente sobre negociación de contratos.
• Responder ante el cambio sobre el seguimiento de un plan.
7
 Ilustración 1: Manifiesto por el Desarrollo Ágil de Software.
Fuente: (agilemanifesto, 2001)

1.1.2 LOS 12 PRINCIPIOS DEL MANIFIESTO ÁGIL

1. Satisfacer al cliente mediante la entrega temprana y continua de software con

valor.
2. Aceptar los cambios de requisitos, incluso en etapas tardías del desarrollo. Los
procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.
3. Se entrega software funcional frecuentemente, entre dos semanas y dos meses,
con preferencia al tiempo más corto.
4. Los responsables de negocio y los desarrolladores trabajan juntos de forma
cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el
entorno y el apoyo que necesitan y confiarles la ejecución del trabajo.
8
 6. El método más efectivo eficiente de comunicar información al equipo de
desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
9. La atención continua de la excelencia técnica y buen diseño mejora la agilidad.
10. La simplicidad o el arte de maximizar la cantidad de trabajo no realizado es
esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados.
12. A intervalos regulares el quipo reflexiona sobre cómo ser más efectivo para
ajustar y perfeccionar su comportamiento en consecuencia.
Según (Gallego, pág. 31)

1.2 ANTECEDENTES ESPECÍFICOS

El manifiesto ágil dio paso a nuevas herramientas de gestión, especialmente en el

desarrollo de proyectos de software. En esta ocasión se hablará de las metodologías
Kanban y Scrum que son las más conocidas y utilizadas actualmente. También se
hablará de la metodología Scrumban.

2 METODOLOGÍA

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

• Método Bibliográfico, debido a que se realizara la lectura y compilación

de libros relacionados al tema de estudio.
• Método Analítico, debido a que se procederá a revisar y analizar
ordenadamente documentos relacionados al tema de estudio, para la
redacción del presente trabajo.

9
3 CYNEFIN

Cynefin compara las características de cinco dominios de complejidad diferentes:

• Simple.
• Complicado.
• Complejo.
• Caótico.
• Desordenado en el centro.

Ilustración 2: Cynefin, la complejidad que nos rodea.

Fuente: (Alaimo, 2013)

3.1 DOMINIO SIMPLE

Se opera con problemáticas simples, es muy fácil identificar las causas y sus efectos,
por lo general, la respuesta correcta es clara, conocida por todos e indiscutible. En este
dominio existen las mejores prácticas, soluciones conocidas para problemas
10
conocidos. Los procesos más eficientes en este dominio son aquellos que especifican
una serie lógica de pasos y ejecutan de manera respectiva, una u otra vez.
Ejemplos de este dominio son la construcción en serie de un mismo producto, la
instalación en muchos clientes de un mismo sistema. Si bien Scrum puede funcionar
en este contexto, los procesos compuestos por pasos bien definidos son mucho más
eficientes. Según (Alaimo, 2013, pág. 17)

3.2 DOMINIO COMPLICADO

En este dominio encontramos problemas complejos, buenas prácticas y perfiles

expertos, hay múltiples soluciones correctas para una misma problemática, pero se
requiere del involucramiento de expertos para poder identificarlas.
Un ejemplo típico de este escenario es la solución de un problema de performance en
un software o base de datos, la sincronización de semáforos, en un cruce de tres
avenidas, la búsqueda de eficiencia en la distribución logística de mercaderías, etc.
Si bien Scrum podría emplearse, no necesariamente sea la forma más eficiente de
resolver estas situaciones, donde funcionaria mejor un conjunto de expertos en la
materia que revelen la situación. Según (Alaimo, 2013, pág. 18)

3.3 DOMINIO COMPLEJO

Cuando nos enfrentamos a problemas complejos, los resultados se vuelven más

impredecibles, no exiten ni mejores ni buenas prácticas catalogadas para las
situaciones frente a las cuales nos podemos encontrar, simplemente, no sabemos con
anticipación si una determinada solución va a funcionar, solo podemos examinar los
resultados y adaptarnos. Este es el dominio de las prácticas emergentes. Las
soluciones encontradas rara vez son replicables, con los mismos resultados, a otros
problemas similares. Para poder operar en la complejidad necesitamos generar
contextos donde haya lugar para la experimentación y donde el fallo sea de bajo
impacto. Se requieren niveles altos de creatividad, innovación, interacción y
comunicación. El desarrollo de nuevos productos o la incorporación de nuevas
características en productos existentes es un contexto complejo en el que Scrum se
11
utiliza mucho para actuar, inpeccionar y adaptar las practicas emergentes de un equipo
de trabajo. Según (Alaimo, 2013, pág. 19)
3.4 DOMINIO CAÓTICO

Los problemas caóticos requieren una respuesta inmediata, estamos en crisis y

necesitamos actuar de inmediato para restablecer cierto orden. Imaginemos que el
sistema de despacho de vuelos en un aeropuerto de alto tráfico deja de funcionar. Este
no sería un escenario para utilizar Scrum, aquí debemos actuar de inmediato, alguien
debe tomar el control y mover la situación fuera del caos. Por ejemplo, solucionar el
problema inmediatamente (sin importar la forma técnica), para luego, fuera del caos,
evaluar y aplicar una solución más robusta, de ser necesario. Este es el dominio de la
inprovisación. Según (Alaimo, 2013, pág. 19)

3.5 DOMINIO DESORDENADO

Nos movemos en el espacio desordenado cuando no sabemos en qué dominio

estamos. Se la clasifica como una zona peligrosa, ya que no podemos medir las
situaciones ni determinar la forma de actuar. Es muy típico en estas situaciones que las
personas interpreten las situaciones y actúen en base a preferencias personales. El
gran peligro del dominio desordenado es actuar de manera diferente a la que se
necesita para resolver ciertos problemas.

Por ejemplo, mucha gente en el ámbito del desarrollo de software está acostumbrada
al desarrollo secuencial, por fases, detalladamente planificado utilizando las mejores
prácticas de la industria, y este enfoque, que corresponde al dominio Simple, muchas
veces se aplica en el dominio complejo. Si nos encontráramos en el espacio
desordenado, todo lo que hagamos debe estar enfocado netamente a salirnos de ese
espacio hacia uno mejor identificado, para luego actuar de la manera en que dicho
dominio lo requiera. Según (Alaimo, 2013, pág. 20)

4 METODOLOGÍA KANBAN

12
Ahora se hará un enfoque en la metodología ágil Kanban para la gestión de desarrollo
de sistemas de software.
4.1 INTRODUCCIÓN

En el año 2007 David Anderson presenta el método “Kanban” para el desarrollo de

software. Dicho método se enfoca en la entrega justo a tiempo (Just In Time) o JIT
también se enfoca en no sobrecargar a los desarrolladores de software.
según (Ruedas)

Kanban es una palabra japonesa donde KAN quiere decir “visual” y BAN quiere decir
“tarjeta”, entonces esto significa “tarjetas visuales”. Las ventajas de Kanban es que, es
fácil de utilizar, actualizar, visualizar las tareas y que el equipo de trabajo lo puede
asumir con facilidad.

4.2 QUE ES KANBAN

Kanban es un marco de trabajo muy popular a la hora de implementar un desarrollo de

software ágil. Requiere una comunicación en tiempo real sobre la capacidad y una
transparencia de trabajo total. Los elementos de trabajo se presentan visualmente en
un tablero Kanban, lo que permite a los miembros del equipo ver el estado de cada uno
en cualquier momento. Según (Atlassian, s.f.)

4.3 PRINCIPIOS DE LA METODOLOGÍA KANBAN

Kanban se basa en una serie de principios que la diferencian del resto de las
metodologías ágiles y son las siguientes:

4.3.1 CALIDAD GARANTIZADA

Todas las tareas deben ser realizadas sin margen de error a la primera, en la
metodología Kanban es más importante la calidad de las tareas y no así la rapidez en
la entrega. Esto se basa en el hecho que cuesta más arreglarlo después, que hacerlo
13
bien a la primera.

4.3.2 REDUCCIÓN DEL DESPERDICIO

La metodología Kanban se basa solamente en hacerlo lo justo y necesario, pero hacerlo

bien. Esto significa a la reducción de todo aquello que es superficial y/o secundario.

4.3.3 MEJORA CONTINUA

Kanban no es simplemente un método de gestión, también es un sistema de mejora de

desarrollo de proyectos, según los objetivos a alcanzar.

4.3.4 FLEXIBILIDAD

La tarea siguiente a realizar se decide del Backlog (tareas pendientes acumuladas),

donde se priorizan las tareas según las necesidades del momento.

4.4 PRINCIPALES PASOS EN KANBAN

Para la aplicación de la metodología Kanban se genera un tablero de tareas que permite

mejorar el flujo de trabajo y alcanzar un ritmo sostenible. Para implantar esta
metodología, debemos tener en claro los siguientes pasos.

4.4.1 DEFINIR EL FLUJO DE TRABAJO DE LOS PROYECTOS

Se debe crear un tablero propio, que deberá ser visible y accesible por todos los
miembros del equipo. Cada una de las columnas corresponderá a un estado concreto
del flujo de tareas, que nos servirá para saber en qué situación se encuentra cada
proyecto. El tablero debe tener tantas columnas como estados por los que pasa una
tarea, desde que se inicia hasta que finaliza.

14
A diferencia de Scrum, una de las peculiaridades del tablero es que este es continuo,
esto significa que no se compone de tarjetas que se van desplazando hasta que la
actividad queda realizada por completo. En este caso, a medida que se avanza, las
nuevas tareas (mejoras, incidencias o nuevas funcionalidades) se acumulan en la
sección inicial, de manera que en las reuniones periódicas con el cliente se priorizan
y se colocan dentro de la sección que se estima oportuna. Dicho tablero puede
ser específico para un proyecto en concreto o bien genérico. Según (Gilibet, 2013)

Ilustración 3: Flujo de trabajo de Kanban

Fuente: (Matter, s.f.)

4.4.2 VISUALIZAR LAS FASES DEL CICLO DE PRODUCCIÓN

Al igual que Scrum, Kanban se basa en el principio de desarrollo incremental,

dividiendo el trabajo en distintas partes. Esto significa que no hablamos de la tarea
en sí, sino que se divide en distintos pasos para agilizar el proceso de producción.

15
Normalmente cada una de esas partes se escribe en un publicado (post-it) y se pega
en el tablero, en la fase que corresponda, dichos publicados contienen la información
básica para que el equipo sepa rápidamente la carga total de trabajo que supone,
normalmente descripción de la tarea con la estimación de horas. Además, se pueden
emplear fotos para asignar responsables, así como también usar tarjetas con
distintas formas y colores para poner observaciones o indicar bloqueos (cuando una
tarea no puede hacerse porqué depende de otra).
Al final, el objetivo de la visualización es clarificar al máximo el trabajo a realizar, las
tareas asignadas a cada equipo de trabajo, así como también las prioridades y la
meta asignada. Según (Gilibet, 2013)

4.4.3 LÍMITES DE TRABAJO EN PROGRESO

Se prioriza el trabajo que está en curso en vez de empezar nuevas tareas.

Precisamente, una de las principales aportaciones de Kanban es que el trabajo en
curso debe estar limitado y, por tanto, existe un número máximo de tareas a realizar
en cada fase. En realidad, se trata de definir el máximo número de tareas que
podemos tener en cada una de las fases.

• Fase de Planificación.
• Fase de Desarrollo.
• Fase de Pruebas.

Aquí lo importante es que las tareas que se abran se cierren antes de empezar con
la siguiente.

4.4.4 CONTROL DEL FLUJO

A diferencia de Scrum, la metodología Kanban no se aplica a un único proyecto, sino

que mezcla tareas y proyectos. Se trata de mantener a los trabajadores con un flujo
de trabajo (Workflow) constante, las tareas más importantes en cola para ser
desarrolladas y un seguimiento pasivo para no tener que interrumpir al trabajador en
16
cada momento. Asimismo, dicha metodología de trabajo permite hacer
un seguimiento del trabajo realizado, almacenando la información que proporcionan
las tarjetas.
Muchos insisten en destacar las ventajas de Kanban respecto a otras metodologías
ágiles, como puede ser Scrum. La posibilidad de poder realizar entregas en cualquier
momento, cambiar prioridades al vuelo y la visualización perfecta del flujo, son
algunos de los puntos que remarcan como elementos diferenciales y de valor.
Según (Gilibet, 2013)

4.5 TABLEROS KANBAN

Un tablero Kanban es una herramienta de gestión de proyectos lo cual puede ser físicos
o digital, diseñada para ayudar a visualizar el trabajo, limitar el trabajo en curso y
maximizar el flujo de trabajo.

El trabajo de todos los equipos de Kanban gira en torno a un tablero Kanban, una
herramienta que se usa para visualizar las tareas y optimizar el flujo de trabajo entre
los miembros del equipo.

Aunque los tableros físicos gozan de popularidad entre algunos equipos, los tableros
virtuales constituyen una función esencial de cualquier herramienta de desarrollo de
software ágil para garantizar la trazabilidad, la colaboración sencilla y la accesibilidad
desde varias ubicaciones.

Independientemente de que, si el tablero del equipo es físico o digital, su función es

garantizar que el trabajo del equipo se visualice, que su flujo de trabajo (workflow) se
unifique y que se identifiquen y resuelvan inmediatamente todos los factores que lo
bloqueen y de los que dependan. El tablero Kanban básico tiene un flujo de trabajo
(workflow) de tres pasos: Por hacer, En curso y Hecho. Sin embargo, dependiendo del
tamaño, la estructura y los objetivos del equipo, el flujo de trabajo (workflow) se puede
asignar para cumplir el proceso único de cualquier equipo determinado.

17
La metodología Kanban se basa en una transparencia total del trabajo y una
comunicación en tiempo real de la capacidad. Por lo tanto, el tablero Kanban debería
considerarse la única fuente fiable sobre el trabajo del equipo. Según (Atlassian, s.f.)
4.5.1 ELEMENTOS DEL TABLERO KANBAN

Los tableros Kanban se pueden dividir en cinco componentes.

• Señales visuales (Visual signals) Son tarjetas visuales y/o notas adhesivas,
donde todo el equipo escribe sus proyectos y elementos de trabajo. Para los
equipos ágiles cada tarjeta podría encapsular una historia de usuario, una vez
en el tablero estas señales visuales ayudan a los compañeros de equipo y a las
partes interesadas a entender en que está trabajando el equipo.

• Columnas (Columns) Cada columna representa una actividad específica que

juntos componen un flujo de trabajo hasta su culminación, los flujos de trabajo
pueden ser simples, tareas pendientes, tareas en curso, completar algunas
tareas o tareas más complejas.

• Límites de trabajo en proceso (Work-in-progress limits) Son el número máximo

de tarjetas que puedan estar en una columna en cualquier momento dado, no
pueden ser más de tres tarjetas. Estos límites de trabajo en proceso son críticos
para exponer cuellos de botella en el flujo de trabajo y maximizar el flujo. Los
límites de trabajo en proceso le dan una señal de advertencia temprana de que
se comprometió a trabajar demasiado.

• Un punto de compromiso (A commitment point) Aquí es donde el cliente y

compañeros de equipo ponen ideas para proyectos que el equipo puede recoger
cuando estén listos, el punto de compromiso es el momento en que el equipo
recoge una idea y comienza el trabajo en el proyecto.

• Punto de entrega (Delivery point) Para la mayoría de los equipos Kanban, el

punto de entrega es cuando el producto o servicio está en manos del cliente. El
18
 objetivo del equipo es llevar las cartas desde el punto de compromiso al punto
de entrega lo más rápido posible. Según (Atlassian, s.f.)

Ilustración 4: Tablero Kanban y sus Elementos.

Fuente: (Atlassian, s.f.)

4.5.2 TABLERO DIGITAL KANBAN

Estos tableros digitales permiten a los equipos trabajar remotamente. Uno de los
tableros digitales es Trello, es sencilla la configuración para crear listas digitales que
representan las etapas de su proceso Kanban en una vista de tablero a la que todo el
equipo pueda acceder y administrar. Por ejemplo, puede crear listas para atrasos, más
adelante, en curso y hecho. Cada tarea está organizada como una tarjeta que se mueve
a través de las listas a medida que se ponen en cola, se trabaja y completado. La
ventaja de los tableros digitales Kanban es la velocidad para configurarla, la facilidad
de compartir con otros miembros del equipo y la capacidad de seguir asincrónicamente
un número infinito de conversaciones y comentarios a medida que avanza el proyecto,
no importa dónde o cuando los miembros del equipo se registren en el tablero Kanban,
verán el estado más actualizado del proyecto.

19
 Ilustración 5: Tablero digital Kanban.
Fuente: (Atlassian, s.f.)

4.5.3 TABLERO FÍSICO KANBAN

Los tableros físicos más simples son los que se dividen en columnas verticales, los
equipos marcan una pizarra y colocan notas adhesivas, estas notas se mueven a través
del flujo de trabajo y demuestran el proceso. Sin embargo, los tableros físicos no son
ideales para equipos remotos.

20
 Ilustración 6: Tablero físico Kanban.
Fuente: (Atlassian, s.f.)

4.6 TARJETAS KANBAN

El objetivo principal de representar el trabajo con una tarjeta en el tablero de Kanban

es que los miembros del equipo realicen el seguimiento del proceso del trabajo
mediante el flujo de trabajo (workflow) de una manera muy visual.

Las tarjetas Kanban presentan información vital sobre ese elemento de trabajo concreto
y proporcionan una visibilidad completa a todo el equipo sobre quien está a cargo de
ese elemento de trabajo concreto una breve descripción del trabajo que se está
haciendo, la duración estimada que llevara esa unidad de trabajo. Las tarjetas de los
tableros Kanban virtual a menudo presentan capturas de pantalla y otros datos técnicos
de valor para el destinario de la asignación, al permitir que los miembros del equipo
vean el estado de cada elemento de trabajo en cualquier momento determinado, así
como todos los detalles relacionados, se garantiza un aumento de dedicación, un
seguimiento completo y una identificación rápida de los factores que lo bloquean y de
los que dependen. Según (Atlassian, s.f.)

21
5 METODOLOGÍA SCRUM

Scrum se basa en un siclo de vida iterativo e incremental que persigue el objetivo de

optimizar la previsibilidad y controlar el riesgo. En Scrum cada iteración se denomina
“Sprint” y tiene una duración de 2-4 semanas, durante este periodo se realizan los
trabajos seleccionados y al finalizar cada Sprint se obtiene como resultado un producto
de software que provee alguna funcionalidad al cliente.

5.1 INTRODUCCIÓN

En el año 1986 Takeuchi y Nonaka publicaron el artículo “The New Product

development Game” en Harvard Business Review. El cual dará a conocer una nueva
forma de gestionar proyectos en la que la agilidad, flexibilidad y la incertidumbre son
los elementos principales.

Observando a empresas como Honda, HP, Canon, Toyota, donde realizaban sus
productos en menos tiempo, de buena calidad y con menos coste. Además que se
dieron cuenta que el producto no seguía unas fases en la que había un equipo
especializado en cada una de ellas, si no que se partía de unos requisitos muy
generales y el producto lo realizaba un equipo multidisciplinar que trabajaba desde el
comienzo del proyecto hasta el final.

Se comparó esta forma de trabajo en equipo, con la colaboración que hacen los
jugadores de Rubby y la utilización de una formación denominada Scrum.

Scrum aparece como una práctica destinada a los productos tecnológicos y será en
1993 cuando realmente Jeff Sutherland aplique un modelo de desarrollo de software
en Ease/Comparation. Según (Gallego, pág. 32)

Scrum es una metodología simple, flexible y adaptable a todo tipo de desarrollo de

software.

22
5.2 SCRUM

Scrum es un marco de trabajo ágil y estructurado que permite que talentosos equipos
de desarrollo de software en colaboración con sus clientes puedan desarrollar
productos innovadores y complejos en un ambiente de confianza y en base a unas
pocas reglas simples. Este marco de trabajo plantea una simplificación respecto a las
metodologías tradicionales que prosperaron en los años 90.

Para definir cuáles son las funcionalidades que se producirán en el proyecto, se definen
los requerimientos del cliente o usuario que se denominan historias de usuario (User
Stories). Las priorizaciones se realizan evaluando las historias de usuario según el valor
que le proveen al negocio del cliente y el riesgo inherente de cada una. Las historias
de mayor valor y mayores riesgos se desarrollan en los primeros Sprint.
Según (Lledó, 2014, pág. 165)

5.3 PILARES DE SCRUM

Los pilares de Scrum son la transparencia, la inspección y la adaptación.

• Transparencia: Aspectos significativos del proceso deben estar visibles a los

responsables de los resultados. Definir el estándar común para que los
observadores compartan un mismo entendimiento de lo que está siendo visto.

• Inspección: Los objetivos de Scrum deben ser inspeccionados y el progreso del

evaluado para detectar variaciones.

• Adaptación: Supone que si un inspector determina que uno o más aspectos de

un proceso se desviaron fuera de los límites aceptables y que por ello el producto
resultado será inaceptable el proceso o material en producción debe ser
ajustado. Según (Martínez, pág. 56)

23
5.4 CARACTERÍSTICAS DE SCRUM

• La metodología Scrum es flexible, iterativo e incremental.

• Enfoque ágil para el desarrollo de sistemas y servicios software innovadores.
• Basado en modelos de proceso iterativos y los valores del manifiesto ágil.
• Equipo multidisciplinar, motivado y auto-organizado.
• Requisitos en forma de lista priorizada de características y capacidades del
producto.
• Entrega iterativa del producto en ciclos cortos y fijos, primero las características
más importantes.
• Planificación adaptiva.
• Retroalimentación (Feedback) de producto y proceso en cada iteración.
• Cada entrega contiene un conjunto de características completas que pueden
ponerse en producción. Según (Yelmo, 2014)

5.5 ROLES DE SCRUM

Un proyecto de desarrollo se puede llevar a cabo mediante uno o más equipos Scrum.
Un equipo Scrum está formado por personas que juegan tres tipos de roles que son:
Product Owner, Scrum Master y Development Team Member. Un equipo Scrum se
auto-organiza no necesita jefes.

A continuación, se hablará de los papeles que juegan cada miembro de un equipo

Scrum.

24
 Ilustración 7: Roles de Scrum.
Fuente: (Rubin)

5.5.1 PRODUCT OWNER

El Dueño del Producto (Product Owner) es la persona que representa los intereses del
usuario cliente y vela porque el producto desarrollado cumpla con las necesidades del
mismo. El Product Owner define las funcionalidades y características del producto para
el negocio y prioriza las funcionalidades en base al valor que provee al negocio cada
una. Además, es el responsable de aceptar o rechazar los resultados del trabajo.
Según (Lledó, 2014, pág. 167)

El Product Owner es algo así como un intermediario, quien realiza todas las acciones
necesarias para asegurar que el cliente obtenga lo que desea, pero garantizando al
mismo tiempo que los miembros del equipo y los grupos de interés sepan lo que tienen
que hacer. El dueño del producto (Product Owner) recibe información de ambas partes
y selecciona cuidadosamente los elementos que harán parte de la lista de prioridades
del desarrollo del producto. Según (Dimes, 2015)

25
Las principales tareas del Product Owner son:

• Responsable de la visión de producto y la gestión económica de su desarrollo.

• Nexo de conexión entre el equipo de desarrollo y la parte interesada
(Stakeholders).
• Decide qué características y funcionalidades ha de tener el sistema en desarrollo
y el orden en que deben ser implementadas (pila de características del sistema
pendientes de implementación o Product backlog) y las valida.
• Participa activamente en el equipo Scrum. Según (Yelmo, 2014)

Ilustración 8: Product Owner.

Fuente: (Rubin)

5.5.2 SCRUM MASTER

El rol del Maestro Scrum (Scrum Master) es probablemente el más importante en el

proceso de desarrollo de software. El Scrum Master se asegura de que cada persona
esté haciendo su trabajo adecuadamente y que nadie este retrasado, además tiene que
estar vigilante en la detección de posibles obstáculos que puedan surgir. Su trabajo no
consiste en dar órdenes sino en guiar al equipo en la correcta aplicación de los
conceptos Scrum, esto es especialmente para aquellas compañías que aún se están
ajustando al concepto ágil.

Scrum permite anticipar fácilmente problemas potenciales y es responsabilidad del

Scrum Master asegurarse de que el equipo tome las medidas pertinentes para
26
resolverlos antes de que estos se salgan de las manos. Muchas veces el Product Owner
podría presionar al equipo a realizar múltiples tareas generando un retraso en la
entrega del producto, es ahí cuando el Scrum Master entra a negociar y rechazar
algunos cambios para evitar el fracaso del proyecto.

Las principales tareas del Scrum Master son:

• Ayuda a los miembros del equipo a aplicar los principios, valores y prácticas de
Scrum.
• Ayuda a la organización en la adopción del proceso Scrum.
• Lidera el equipo de desarrollo, no dirige ni gestiona.
• Es el responsable del proceso Scrum y está al servicio de los miembros del
equipo de desarrollo para facilitar su aplicación. Según (Yelmo, 2014)

Ilustración 9: Scrum Master.

Fuente: (Rubin)

5.5.3 DEVELOPMENT TEAM

El rol del Equipo de Desarrollo (Development Team) son los responsables de

seleccionar las actividades que puedan manejar y ejecutar de la manera más eficiente
posible. Los Development Team son generalmente desarrolladores, diseñadores de
interfaces de usuario, administrador de base de datos, personal de pruebas y
depuración, etc. Según (Dimes, 2015)

27
Las principales tareas del Development Team son:

• Responsables del diseño, implementación y verificación del sistema en

desarrollo.
• El equipo se auto-organiza para llevar a cabo los objetivos fijados por el Product
Owner.
• En conjunto, deben de tener todos los conocimientos y capacidades para
producir software funcional de buena calidad.
• Tamaño típico del equipo para un proyecto mediano es de 5-9 personas, para
proyectos grandes se puede usar jerarquías de equipo. Según (Yelmo, 2014)

Ilustración 10: Development Team.

Fuente: (Rubin)

5.6 ACTIVIDADES Y ARTEFACTOS

El ciclo del Sprint de la metodología Scrum, está formado por actividades y artefactos,
dentro de las actividades se realiza distintas reuniones, en el artefacto se forman las
prioridades de los requerimientos y se estiman los esfuerzos.

28
 Ilustración 11: Actividades y Artefactos de Scrum.
Fuente: (Rubin)

5.6.1 ACTIVIDADES DE SCRUM

Las actividades o reuniones son una de las características más importante y

destacadas de Scrum, donde se incentiva la comunicación permanente y directa de
todos los que participan, estas reuniones se realizan durante el ciclo de vida del
proyecto y se fundamentan en las siguientes razones.

• Solventa la escasa documentación que se maneja.

• Permite delimitar los hitos de desarrollo del proyecto.
• Mantiene la comunicación permanente entre el Development Team, el Scrum
Master y el Product Owner.
• Permiten registrar las herramientas y elementos propios de Scrum.
Según (Jaldín, 2018)

29
Las actividades o reuniones que se realizan en el ciclo de vida del proyecto son:

• Sprint (Reunión Inicial).

• Sprint Planning (Planificación del Sprint).
• Daily Scrum (Reunión Diaria Scrum).
• Sprint Review (Revisión del Sprint).
• Sprint Retrospective (Retrospectiva del Sprint).

a) SPRINT

Es la única reunión que se realiza antes del inicio del proyecto, previo a esta reunión
es recomendable que el Product Owner prepare su lista de requerimientos. En esta
reunión deben estar presentes el Product Owner, el Scrum Master y el Development
Team para conocer las necesidades o requerimientos del Product Owner. Además, en
esta reunión se determinan los requisitos iniciales y la visión del producto desde el
punto de vista del cliente y el resultado de esta reunión se consolida en el Product
Backlog que es una lista de requerimientos funcionales del cliente.
Según (Jaldín, 2018)

b) SPRINT PLANNING

Esta reunión se realiza al inicio de cada iteración o Sprint, donde participan el Product
Owner, el Scrum Master y el Development Team. Aquí se determinan los objetivos que
deberán cumplir, y las tareas que se realizarán para cada requerimiento definido en el
Product Backlog. El resultado se consolida en el Sprint Backlog. Según (Jaldín, 2018)
Pasos a seguir para un buen resultado en el Sprint:

• El product Owner presenta al equipo los requisitos a través de las Historia de

Usuario.
• El Development Team hace las consultas necesarias al Product Owner o a los
usuarios, para aclarar dudas y complementar las historias de usuario.

30
 • El Scrum Master y el Development Team también hacen sugerencias para
incorporar funcionalidades.

Una vez definidos los requerimientos del Sprint, el Developmnet Team junto con el
Scrum Master elaboran las listas de tareas de cada requerimiento, para cada
requerimiento puede haber tareas relacionadas, se hace una estimación conjunta del
esfuerzo necesario para realizar cada tarea, los miembros del equipo se auto-asignan
las tareas que van a realizar, La estimación de esfuerzo de cada tarea oscila entre 4-
16 horas de trabajo. Si una tarea se estima en más de 16 horas, esta deberá ser
particionada en otras tareas más específicas.

En cada reunión las preguntas claves que se tienen que hacer son:

• Qué es lo que se hizo desde la última reunión.

• Qué es lo que se va hacer hasta la siguiente reunión.
• Cómo se va a llevar a cabo.

Ilustración 12: Sprint Planning.

Fuente: (Rubin)

31
b.1) ESTIMACIÓN DEL SPRINT

Las estimaciones del esfuerzo son realizadas por los desarrolladores al momento de
planificar el Sprint. Las estimaciones se basan en las experiencias previa en desarrollos
con las mismas características, también existen técnicas para establecer las
estimaciones.

Nombraremos las técnicas más usadas:

• Estimación de Poker.
• Diagrama de Burndown.
• Estimacion basada en la experiencia.
• Estimacion por puntos de función.

c) DAILY SCRUM

Son reuniones diarias durante un Sprint, donde se realiza un seguimiento de

sincronización, revisión y de adaptación a las actividades realizadas el día anterior y
planificar las actividades que se realizan en el día presente. Esto se hace a la misma
hora de corta duración a lo mucho unos 15 minutos y se debe estar de pie, se
recomienda que sea la primera actividad del día, aquí no se ponen soluciones a los
problemas estos se coordinan para hacer atendidos en otro momento. Los que están
presentes en estas reuniones son Scrum Master y el Development Team.

Las preguntas que se hacen en estas reuniones son:

• Qué he hecho desde la última reunión.

• Qué tengo planeado hacer hasta la próxima reunión.
• Qué impedimentos he encontrado para realizar mi trabajo según lo previsto.
Según (Yelmo, 2014) y (Jaldín, 2018)

32
 Ilustración 13: Daily Scrum.
Fuente: (Rubin)

d) SPRINT REVIEW

Estas reuniones se realizan al final de cada Sprint o Iteración, donde están presentes
el Product Owner, el Scrum Master, los Stakeholders, clientes y terceros interesados.
Lo que se presenta en esta reunión es una demo del proyecto, el tiempo de
presentación como máximo es de 4 horas. El Product Owner identifica el cumplimiento
de objetivos respecto del Product Backlog, El Development Team obtiene una
retroalimentación (feedback) por parte del cliente sobre el incremento presentado. La
demo presentada debe ser lo más real posible usando información histórica del cliente.
Según (Yelmo, 2014)

Ilustración 14: Sprint Review.

Fuente: (Rubin)
33
e) SPRINT RETROSPECTIVE

Reunión final de cada siclo de desarrollo destinada a revisar la forma en que se

desarrolló el ultimo Sprint en lo que respecta a las personas, relaciones, procesos y
herramientas, además permite mejorar la forma de trabajo, se considera cada vez más
un componente del marco técnico de Scrum. Esta reunión es de carácter técnico para
analizar cómo se está construyendo el proyecto, desde una perspectiva netamente
técnica. Si el Development Team está teniendo dificultades de trabajo de equipo, de
relaciones interpersonales o comunicación, es en esta reunión en la que se deben tratar
y solucionar. Aquí participan los Development Team, el Scrum Master y el Product
Owner, tiene una duración de 4 horas.

Todos los miembros responden a dos preguntas:

• Qué cosas se hicieron bien en el último sprint.

• Qué cosas se podrían mejorar. Según (Yelmo, 2014) y (Jaldín, 2018)

Ilustración 15: Sprint Retrospective.

Fuente: (Rubin)
34
5.6.2 ARTEFACTOS DE SCRUM

Los tres elementos fundamentales de Scrum son:

a) PRODUCT BACKLOG

El Product Backlog es el inventario de funcionalidades o lista de requerimientos que el

Product Owner desea obtener como resultado del proyecto, priorizando de acuerdo con
el valor que cada funcionalidad le provee al negocio. Contiene todos los requisitos del
proyecto definidos por el Product Owner, según las necesidades del cliente o usuario,
al inicio del proyecto en formato de Historias de Usuario.
Durante la planificación el equipo Scrum estimara el esfuerzo de desarrollo de cada
Historia de Usuario ya sea en horas o en unidades de medida llamadas “Puntos de
Historia” que indica el tamaño relativo de las mismas.
El Product Backlog o “Lista de necesidades del cliente” es un documento en constante
evolución al que se le pueden agregar y quitar funcionalidades como consecuencia de
los cambios que surjan en las necesidades del negocio y se le revisan las prioridades
al inicio de cada Sprint. Pueden participar todos los que están involucrados en el
proyecto, todos pueden contribuir y aportar sugerencias, pero el responsable del
Product Backlog es el Product Owner. Según (Lledó, 2014, pág. 171)

Ilustración 16: Product Backlog.

Fuente: (Rubin)
35
Un ejemplo de experiencia en la elaboración del Product Backlog acerca de un “sistema
de atención de servicios mecánicos”, durante las clases de Diplomado. Módulo I.

Ilustración 17: Ejemplo de Product Backlog inicial.

Fuente: (Jaldín, 2018)

Ilustración 18: Ejemplo de Product Backlog final.

Fuente: (Jaldín, 2018)
36
a.1) HISTORIAS DE USUARIO

Son las descripciones de las funcionalidades que va a tener el software.

Estas Historias de Usuario serán el resultado de la colaboración entre el Product Owner
y el Development Team, donde irán evolucionando durante el proceso de desarrollo del
proyecto.

Características de una Historia de Usuario “INVEST”:

• Independientes (I). Las Historias de Usuario deben ser independientes de forma

que no se superpongan en funcionalidades y que puedan planificarse en
cualquier orden.

• Negociable (N). Una buena Historia de Usuario es negociable. No es un contrato

explícito, por el contrario, los alcances de las Historias podrían ser variables:
pueden incrementarse o eliminarse con el correr del desarrollo y en función del
feedback del usuario y/o la performance del Equipo.

• Valorable (V). Una Historia de Usuario debe ser valorable por el Product Owner.
Los desarrolladores pueden tener actividades técnicas como parte del Backlog
pero para que puedan ser consideradas una Historia de Usuario deben ser
enmarcadas de forma tal que el Product Owner las considere importantes caso
contrario, no deberían formar parte del Backlog.

• Estimable (E). Las Historias de Usuario deben ser estimables. Existen tres
razones por las cuales una Historia de Usuario no podría estimarse.

❖ La Historia de Usuario es demasiado grande.

❖ Falta de conocimiento funcional.
❖ Falta de conocimiento técnico.

37
 • Pequeña (Small). Las Historias de Usuario deben ser lo suficientemente
pequeñas de forma tal que permita ser estimada por el equipo de desarrollo.
Algunos equipos fijan el tamaño de una Historia de Usuario como no más de dos
semanas de una persona, si bien no es una medida explícita tener entre 4 y 6
Historias de Usuario por Sprint es una buena señal de tamaño.

• Verificable (Testable). Se espera que el Product Owner no solo pueda describir

la funcionalidad que necesita, sino que también logre verificarla. Algunos
equipos acostumbran solicitar los criterios de aceptación antes de desarrollar la
Historia de Usuario. Si el Product Owner no sabe cómo verificar una Historia de
Usuario o no puede enumerar los criterios de aceptación, esto podría ser una
señal de que la Historia en cuestión no está siendo lo suficientemente clara.
Según (Alaimo, 2013, págs. 86-89)

Una Historia de Usuario está compuesta por tres elementos “3Cs”:

• Tarjeta (Card). Es una breve descripción escrita que sirve como recordatorio.
• Conversación (Conversation). Es una conversación que sirve para asegurarse
que se ha entendido todo y concretar el objetivo.
• Confirmación (Confirmation). Pruebas funcionales para fijar detalles que sean
relevantes e indicar cuál va a ser el límite.

b) SPRINT BACKLOG

Es la lista de tareas que elabora el equipo durante la planificación de un Sprint, se

asignan las tareas a cada persona y el tiempo que queda para terminarlas. De esta
manera el proyecto se descompone en unidades más pequeñas y se pueden
determinar o ver en que tareas no se está avanzando e intentar eliminar el problema.

Es una lista ordenada por prioridades para el cliente, puede depender entre una tarea
y otra, por lo tanto, se tendrá que diferenciar de alguna manera.
Todas las tareas deben de tener un coste semejante que será entre 4-16 horas.
38
Generalmente las tareas a completar se suelen gestionar mediante el Scrum
Taskboard, a cada objetivo se le asigna las tareas para llevarlo a cabo, se usan tarjetas
(post-its) que se van moviendo de una columna a otra para cambiar el estado. En el
Sprint Backlog participan el Scrum Master y el Development Team.
Según (Gallego, págs. 40-41)

Un ejemplo de experiencia en la elaboración del Sprint Backlog acerca de un “sistema

de atención de servicios mecánicos”, durante las clases de Diplomado. Módulo I.
UMSS.

Ilustración 19: Ejemplo de Sprint Backlog.

Fuente: (Jaldín, 2018)

39
c) INCREMENTO

Representa los requisitos que se han completado en una iteración y que son
perfectamente operativos. Según los resultados que se obtengan el cliente puede ir
haciendo los cambios necesarios y replanteando el proyecto.

6 METODOLOGÍA SCRUMBAN

Se hará un enfoque sobre la metodología Scrumban que nace de la combinación, de

las mejores prácticas de Scrum y Kanban, permitiendo a los equipos a mejorar
constantemente sus procesos.

6.1 SCRUMBAN

Scrumban evoluciono a partir de una instancia de Scrum complementado con prácticas

básicas de Kanban. Estas prácticas son: visualización, límites del trabajo en progreso,
gestión del flujo de trabajo, mantenimiento y políticas explícitas.

Scrumban tiene como características:

• Reduce el tiempo dedicado a planificación y estimación, promoviendo el flujo

constante de trabajo.
• Desova una cultura de mejora continua, haciendo hincapié en la entrega
continua sin sobrecargar al equipo de desarrollo.
• Alienta la filosofía de “pensar en grande, actuar en pequeño, fallar rápido,
aprender rápidamente”.

Hablando en términos claros:

• Elimina un ciclo constante iterativo.

• La necesidad de un Sprint Backlog.

40
 • Incita un pull por demanda del sistema, en lugar de que un “push a la fuerza”
del sistema.
• Promueve el flujo constante de trabajo.

Scrumban es más apropiado cuando se trata de mantenimiento de proyectos, trabajo

dirigido por eventos (apoyo, endurecimiento), gestión de proyectos problemáticos
(proyectos con historia de usuarios inesperadas y virus), desarrollo de nuevos
productos (trabajo anterior al desarrollo del Sprint o posterior al desarrollo del Sprint) o
mejora continua de la gestión.

6.2 PRACTICAS DEL MÉTODO KANBAN SOBRE SCRUM

• Visualiza el flujo de trabajo. Aquí el énfasis es el Backlog (que podrían estar

definidos como historias de usuario), desde que se priorizan los requerimientos
hasta que se convierten en un incremento del producto. En Scrum la
visualización de los requerimientos y cómo las tareas fluyen durante la ejecución
del Sprint no es suficiente para visualizar todo el flujo de valor.
Se requiere que se visualice el flujo de trabajo antes de entrar al Sprint y
mantener esta visualización explícita a través del cambio de estado del
trabajo. Con Scrumban se trata de visualizar el flujo y no tareas, visualizar tareas
podría ser opcional dentro del proceso y si ya se hace se puede mantener.

• Limita el trabajo en progreso. Quiere decir que evita iniciar más trabajo para
terminar lo que ya lleva en progreso implementando un sistema “Pull” en parte o
todo el Workflow donde se “jala” o “tira” del trabajo solo si hay capacidad
disponible. En base a un sistema “Pull” es posible detenerse para pensar en la
demanda e identificar cuellos de botella logrando un mejor entendimiento de qué
es lo que sucede con el flujo de trabajo.
En Scrum el equipo es quien limita la cantidad de trabajo a hacer durante el
Sprint en base a un pronóstico y su capacidad durante la reunión del Sprint
Planning. Sin embargo, durante la ejecución, no existe nada que prevenga que
el equipo comience a trabajar en una, dos, tres o todas las historias del Backlog
41
 del Sprint al mismo tiempo. El Sprint es un contenedor (Container) y se deja al
equipo a que se auto-organice para cumplir de la mejor forma su trabajo.
Limitar la cantidad de historias en progreso en un mecanismo para asegurar que
no se termine el Sprint con pocas historias que hayan alcanzado la definición de
terminado o en un peor escenario tener una gran cantidad de historias
parcialmente completadas poniendo en peligro el objetivo del Sprint.

• Gestiona el flujo. El hecho de que exista un límite de trabajo en

progreso estimula a que el equipo piense y lleve a cabo las conversaciones
adecuadas para avanzar el trabajo de la mejor forma resolviendo los
impedimentos en el flujo.
El equipo tiene la opción de romper los limites, ignorar el problema y seguir o
afrontar el problema auto-organizándose alrededor de la entrega continua de
valor, ya en este punto es posible gestionar el flujo desde otra perspectiva y una
métrica empezará a tener sentido: el Tiempo de Ciclo (Cycle Time) que corre
desde que un ítem se inició hasta que se transformó en un incremento del
producto. El uso de Tiempo de Ciclo como métrica podría en algún momento
reemplazar a los puntos de historia.

• Políticas Explícitas. La “definición de terminado” en Scrum es el acuerdo o

políticas que establecen las condiciones para el equipo considere un
requerimiento del Backlog como terminado. Ahora que se tiene el flujo de trabajo
visible es posible hacer explícitas las políticas que gobiernan este flujo y el
cambio de estado del trabajo. Cuando las políticas son explicitas es más fácil
mejorarlas. Un entendimiento explícito de cómo el trabajo fluye y cambia de
estado facilita a que el equipo se auto-organice alrededor del flujo y los
problemas que emerjan para proveer sugerencias de mejora.
Con políticas explícitas en cada fase estamos simplemente llevando la definición
de terminado a un nivel mas avanzado. Nada impide de acuerdo a las reglas de
Scrum que la definición de terminado sea mas explícita.

42
 • Circuitos de Retroalimentación. Implementar circuitos de retroalimentación
(feedback loops) o ciclos de retro-alimentación significa seguir una serie de
prácticas que permitirán obtener información aprender, validar experimentos y
adaptarse rápidamente.
Aquí nos referimos no solo a prácticas que probablemente ya se lleven a cabo
tales como reuniones diarias y retrospectivas sino adicionar reuniones de
revisión de operaciones para analizar métricas cuantificables más avanzadas.
Métricas tales como diagramas de flujo acumulativos y diagramas de control
relacionadas a la medición de la cantidad de trabajo en progreso, tiempo de ciclo
y tasas de entrega (cantidad de historias de usuario entregadas por día o por
semana).

• Mejora Colaborativamente. Cuando el equipo lleva a cabo conversaciones

sobre teorías del trabajo, principios, flujo de valor, riesgos y es consciente de
comportamientos que generan desperdicio es más probable que se logre un
entendimiento compartido del problema y se sugieran acciones de mejora que
podrían ser adoptadas en consenso.

6.3 TABLEROS SCRUMBAN

El tablero Scrumban proporción una excelente visión de flujo de trabajo de un proceso,

donde informa el número de cosas en la que el equipo está trabajando actualmente,
así como el número de tareas ya finalizadas. Aumenta la rendición de cuentas, la
responsabilidad, la comunicación y los resultados de rendimiento del equipo.

Herramientas Kanban (Kanban tool) proporciona potenciadores que te ayudan a

personalizar tus tableros para poder comunicarte, compartir, colocar en tiempo real, en
cualquier momento y en cualquier lugar las tareas, los documentos, las notas y los
comentarios.

43
 Ilustración 20: Tablero Scrumban.
Fuente: (Kanbantool)

6.4 BENEFICIOS DE SCRUMBAN

Scrumban puede ayudar al equipo de desarrollo a eliminar el elevado estrés a mejorar

la eficiencia y también puede mejorar la satisfacción general del cliente. Además, lo
importante de Scrumban es la entrega de productos de alta calidad, la mejora continua,
la minimización de pérdidas y la reducción de tiempo de producción.

7 KANBAN VS SCRUM

Ahora, se hablará de las diferencias y semejanzas que existen entre las metodologías
ágiles Kanban y Scrum.

44
7.1 INTRODUCCIÓN

La metodologia Kanban es un concepto de organización de trabajo parecido al Scrum,

aunque más flexible. Esta metodología acepta la posibilidad de replantearse las
prioridades del trabajo a medida que las necesidades del momento cambian. El equipo
ayuda a que el flujo de trabajo sea mucho mejor, y se evita el estancamiento en unos
patrones predefinidos. Es más, en este caso es posible decidir rechazar los
planteamientos iniciales de la organización del proyecto, si los miembros del equipo
perciben que no funciona adecuadamente.

La metodología Scrum busca establecer un marco de trabajo adaptable a las tareas

que deben ser realizadas en un período de entre 1 y 4 semanas de trabajo
intensivo. Una vez acabado y lanzado el producto, se empieza otro ciclo igual. ¿Qué
ventajas ofrece trabajar así? Esencialmente, rapidez y flexibilidad a la hora de combinar
los procesos de trabajo. De todos modos, también se tiene en cuenta que un calendario
tan marcado y estricto puede condicionar a algunos equipos, que sentirán su actividad
restringida por las estrictas pautas marcadas al principio de cada ciclo de trabajo
intensivo. Según (ITM Platform, 2015)

Ilustración 21: Scrum vs Kanban.

Fuente: (Software, s.f.)

45
7.2 DIFERENCIAS

Kanban concibe el trabajo en base a items individuales, que puedan agregarse o

eliminarse de cada fase del proyecto, según las necesidades de cada momento,
presisamente por esto y para evitar desfases entre los miembros del equipo, requiere
una monitorización del todo el proceso.

El flujo de trabajo de Scrum se sentra en intervalos de trabajo, en donde las tareas

deben progresar de manera constante.

Las diferencias son en primera instancia por sus proposito y en sugundo por sus reglas.

SCRUM KANBAN
Es un marco de trabajo creado por Es un Sistema creado por Taiichi Ohn,
Jeff Sutherland y Ken Awchaber, para optimizar el flujo de trabajo en una
para maximizar el valor entregado cadena de distribución.
en el desarrollo y el mantenimiento
de productos complejos en
situaciones de alta incertidumbre.
SCRUM es mucho más prescriptivo que KANBAN
Prescribe unos roles concreto. Se puede definir roles o no.
Prescribe equipos Los equipos pueden ser
multifuncionales. multifuncionales o especializados.
Prescribe reuniones concretas de No exiten reuniones prefijadas.
tiempo fijo.
Prescribe la estimacion y la No fija la estimacion ni la velocidad.
velocidad.
Prescribe iteraciones de tiempo No indica el trabajo de iteracion.
fijo(Sprint).
Limita el trabajo en curso por Limita el trabajo en proceso (WIP) por
iteracion. el estado de trabajo en el flujo.

46
Se resiste a cambios de alcance Admite cambios siempre que haya
durante la iteración. capacidad disponible para abordarlos.
Limpia su tablero en cada Su tablero es persistente.
iteracion, usa un tablero diferente
en cada iteracion.
Las funcionalidades se dividen en No tiene limitaciones en el tamaño de
partes que puedan completarse en las divisiones.
un Sprint.
Prioriza la pila del Product La priorización es opcional.
Backlog.
Establece reuniones diarias No se establece reuniones.
centradas en las personas.
Usa diagramas Burndown. No prescribe diagramas de
seguimiento concretos.
El tablero pertenece a un unico Varios equipos o personas puede
equipo. compartir el mismo tablero.
Tabla 1: Diferencias de Scrum y Kanban.
Fuente: (Ramos, 2017)

En concecuencia, el esquema organizativo Scrum puede encajar mucho mejor en

proyectos de equipos que se mantienen constantes a lo largo de toda su ejecución,
Mientras que Kanban encajara mucho mejor en un proceso de alto nivel de trabajo,
llevando a cabo por un equipo maduro y capaz de evolucionar según las necesidades
del momento. Según (ITM Platform, 2015)

7.3 SEMEJANZAS

• Son modelos Lean y Agile. Foco en el objetivo, obtimización de medios, entrega

frecuente de valor y mejora continua.
• Son herramientas de proceso que gestionan el flujo de valor. Maximizan el valor
entregado, visualizan el proceso en curso, dividen el trabajo y limitan el trabajo
en proceso (Work In Progress “WIP”).
47
 • Son practicas empiricas orientadas a la eficacia y eficiencia del proceso.
• Facilitan la transparencia del proceso mediante tableros visuales.
• Permiten la deteccion temprana de impedimentos. No los resuelven, pero los
hacen emerger más pronto.
• Trabajan con equipos auto-organizados en torno a la entrega de valor, no en
torno a la asignación de tareas.
• Emplean sistemas de planificación “pull”. Según (Ramos, 2017)

7.4 APLICACIÓN PRÁCTICA

KANBAN da buenos resultados en:

Detectar y eliminar cuello de botella en la ejecución de procesos.

Ejecutar proyectos de mantenimiento, en especial en ANS (Acuerdos de Nivel de
Servicio), donde el tiempo de respuesta en los procesos y las operaciones criticas es
vital.

SCRUM es altamente eficiente en:

Adquirir compromiso del equipo con la entrega de valor constante y continua.

Ejecutar proyectos de desarrollo que manejen plazos de entrega corto y en los que se
puedan hacer planteamientos iterativos e incrementales partiendo de un mínimo
producto viable.

8 CONCLUSIONES

• A la hora de decidir qué tipo de metodologia debemos de emplear para el

proceso de desarrollo de software, tenemos que tener en claro que es lo que va
hacer el software. Kanban está más inclinada a proyectos de gestión, mientras
Scrum va más inclinado a proyectos de constante cambio. Sin embargo, ambas
metodologías son muy aceptables para cualquier proyecto de desarrollo de
software hoy en día.
48
 • La forma de trabajo de la metodologia Kanban es sobre un tablero y el uso de
tarjetas, donde los elementos de trabajo son presentados, es buena práctica
para que el equipo no tenga sobrecarga de trabajo. Como se menciona
anteriormente esta metodologia es más usada para gestionar, ya sea en un
proceso de desarrollo de software o en empresas de producción.

• Scrum tiene un entorno de trabajo en equipo sin jefes lo cual es muy positivo. Se
enfoca en realizar reuniones donde el equipo analiza el trabajo hecho y lo que
se va hacer sin distracciones en otros asuntos. Parece muy bueno por su siclo
de vida iterativo e incremental. Scrum es recomendable para proyectos de
software que tienen constante cambio en los requerimientos propuestos por el
cliente.

• La metodología Scrumban es la unión de las ambas metodologías que son

Kanban y Scrum. Donde Scrum se complementa con las mejores prácticas de
Kanban, como ser el uso de tableros, la entrega justo a tiempo, flujo de trabajo,
no sobre cargar el trabajo al equipo, etc. Scrumban es más usada en el entorno
de mantenimiento de proyectos, gestión de proyecto, etc.

9 RECOMENDACIÓN

Ninguna metodología es mejor o peor que otra, entonces para su óptimo uso de una
metodología en concreto se debe tener en claro que tipo de proyecto se va a desarrollar.

49
10 BIBLIOGRAFÍA

agilemanifesto. (2001). Retrieved Septiembre 3, 2018, from agilemanifesto.org

Alaimo, D. M. (2013). Proyectos Ágiles con Scrum. Keer. Retrieved Noviembre 13, 2018, from
www.martinalaimo.com

Atlassian. (n.d.). ATLASSIAN Agile Coach. Retrieved Septiembre 12, 2018, from ATLASSIAN Agile Coach:
https://es.atlassian.com/agile/kanban

Dimes, T. (2015). Conceptos Básicos de Scrum: Desarrollo de software Ágile y manejo de proyectos
Ágile. Babelcube Books y Babelcube. Retrieved Septiembre 20, 2018, from
https://books.google.com.bo

Fuentes, J. R. (n.d.). Desarrollo de Software Ágil. Retrieved Septiembre 5, 2018, from

https://books.google.com.bo

Gallego, M. T. (n.d.). Gestion de Proyectos Informáticos. Metodologia Scrum. Retrieved Septiembre 8,

2018, from
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.
pdf

Gilibet, L. (2013, Julio 31). Que es la metodología Kanban y cómo utilizarla. Retrieved Septiembre 15,
2018, from Que es la metodología Kanban y cómo utilizarla:
https://www.iebschool.com/blog/metodologia-kanban-agile-scrum/

ITM Platform. (2015, diciembre 14). Las diferencias entra Kanban y Scrum. Retrieved Septiembre 25,
2018, from http://www.itmplatform.com/es/blog/las-diferencias-entre-kanban-y-scrum/

Jaldín, R. (2018, Abril). El Modelo Scrum. Apuntes de clases de Diplomado "Expertos en Desarrollo de
Aplicaciones Empresariales". Cochabamba, Bolivia. Retrieved Septiempre 23, 2018

Kanbantool. (n.d.). Scrumban. Retrieved Septiembre 22, 2018, from Lo mejor de Kanban y Scrum:
https://kanbantool.com/es/scrumban-scrum-y-kanban

Ladas, C. (2008). SCRUMBAN. United States of America.

Lledó, P. (2014). Gestion Lean y Ágil de Proyectos. Estados Unidos: Trafford. Retrieved Septiembre 17,
2018, from https://books.google.com.bo

Martínez, R. N. (n.d.). El Proceso de Desarrollo de Software. Retrieved Nobiembre 16, 2018

Matter, R. (n.d.). www.rocketmatter.com. Retrieved Noviembre 15, 2018, from

www.rocketmatter.com

Ramos, C. V. (2017, octubre 2). Semejanzas y diferencias entre Kanban y Scrum. Retrieved Septiembre
27, 2018, from Semejanzas y diferencias entre Kanban y Scrum:
https://cristinaramosvega.com/semejanzas-diferencias-kanban-scrum/

Rubin, K. S. (n.d.). Essential Scrum. Retrieved Septiembre 15, 2018, from A Practical Guide to the Most
Popular Agile Process:
http://ptgmedia.pearsoncmg.com/images/9780137043293/samplepages/0137043295.pdf
50
Ruedas, J. G. (n.d.). Dirección y Gestión de proyectos de Tecnologías de la Información en la Empresa.
Madrid: Fundación Confemetal. Retrieved Septiembre 9, 92018, from
https://books.google.com.bo

Software, A. e. (n.d.). Agilisimo en Ingenieria de Software: Scrumban en DevOps.

The Blokehead. (2016). SCRUM ¡guía definitiva de prácticas agiles esenciales de SCRUM! (R. P. Duran,
Trans.) Estados Unidos: Edicion Digital. Retrieved Semptiembre 5, 2018, from
https://books.google.com.bo

Yelmo, J. C. (2014, Octubre Primero). Seminario de formacion sobre metodologias agiles en desarrollo
de software de banca: Metodologias agiles. Proceso SCRUM. Retrieved Septiembre 4, 2018,
from Metodologias agiles. El proceso SCRUM: https://www.youtube.com/watch?v=rQAPBTBq-
OQ

51