Integración de incidentes a la metodología Scrumban para la administración efectiva de Proyectos de TI

Vista previa del material en texto

Tecnológico 
de Monterrey 
- TECNOLÓGICO 
• D~ MONTERREY• 
Campus Ciudad de MéxicoB I B L I O TECA 
Escuela de Graduados en Ingeniería y Arquitectura 
Maestría en Ciencias de la Computación 
"Integración de incidentes a la metodología Scrumban 
para la administración efectiva de Proyectos de TI: El 
Caso de la Implementación en Sistemas Financieros en 
México" 
AUTOR: Lic. Liliana Carolina Flores Leyva¡\ 
ASESOR: Dr. José Martín Malina Espinosa 
México D.F., noviembre 2014 
'TC'S LS 
,5tf ,.g 
t56 
)o¡~ 
' · 
CJv 
AGRADECIMIENTOS 
A mi esposo Carlos por su amor, comprensión y apoyo incondicional que me hicieron lograr este 
cometido porque sin su insistencia no hubiera retomado este pendiente y sin su apoyo y amor no 
hubiera tenido la fortaleza para seguir adelante y superarme día a día. 
A mi padre Ramón, que es mi ángel de la guarda y sigue impulsándome a ser mejor cada día de mi 
vida, a ser diferente a todos y siempre la mejor en lo que hago, te amaré siempre. 
A mi madre Fidelina, por ser un roble y un ejemplo de vida, formarme y enseñarme a ser una mujer 
completa, darme siempre su amor incondicional, pero sobre todo su apoyo. A ti y a mi padre les 
estaré siempre agradecida por todos y cada uno de los sacrificios que hicieron para mi formación 
personal y profesional. 
A mi hermana y mejor amiga, Adriana, por ser el mejor ejemplo que me llena de fuerza y 
motivación para seguir adelante siempre con la cabeza adelante y defender lo que quiero ante la 
vida y todos los obstáculos que se pongan ante mí. A mi cuñado César, por ser mi mejor ejemplo de 
bondad y éxito y ser un hermano para mí. 
A todos y cada uno de los miembros de mi familia por su presencia y compañía siempre, sus 
valores, amor y cariño que me han dado durante toda mi vida y por compartir la felicidad de cada 
uno de mis logros. 
A mi familia política, que desde el día que conocí a Carlos, me han tratado como parte de su misma 
familia y han compartido conmigo los logros, tristezas y alegrías. 
A mis jefes y compañeros de trabajo del Banco de México por siempre creer en mí y en m1 
superación para cumplir esta meta a la par de desarrollarme profesionalmente dentro de esta gran 
institución. 
A mi asesor de tesis el Dr. Maitín Molina por su tiempo, apoyo incondicional sin el cual no hubiera 
sido posible la culminación de mis estudios de maestría. A mis maestros por impulsar el desarrollo 
de mi formación profesional. 
A todas las personas que estuvieron conmigo en la realización de esta tesis y que no podría 
nombrar, pero de antemano saben que agradezco de corazón su apoyo y ayuda, pero sobretodo su 
amistad. 
Liliana Carolina Flores Leyva 
2 
CONTENIDO 
Agradecimientos ..........................................................•......................•......................... 2 
Contenido ...................................................................................................................... 3 
Lista de Tablas ................................................................................................................ 5 
Lista de Figuras ............................................................................................................... 6 
Capítulo 1 ...................................................................................................................... 7 
Introducción .....................•..................•..........•......................•....................................... 7 
1.1 Motivación .................................................................................................................. 8 
1.2 Definición del Problema .............................................................................................. 8 
1.3 Objetivos .................................................................................................................. 10 
1.4 Hipótesis .................................................................................................................... 11 
1.5 Metodología .............................................................................................................. 11 
1.6 Estructura de la Tesis .................................................................................................. 12 
Capítulo 2 .................................................................................................................... 14 
Estado del Arte ............................................................................................................ 14 
2.1 Certificación ITIL: Gestión de Incidentes, Perspectiva General.. ................................... 14 
2.1.1 Descripción del proceso .......................................................................................... 14 
2.1.1.1 Gestión de Incidentes .......................................................................................... 15 
2.2 Sobre la Administración de Proyectos - Project Manager (Rol) ................................... 16 
2.3 Administración de Proyectos - Metodologías paira Administración de Proyectos de TI 21 
2.3.1 Metodologías para Administración de Proyectos Tradicionales ................................ 22 
2.3.1.1 
2.3.1.2 
2.3.2 
2.3.2.1 
2.3.2.2 
2.3.2.3 
2.3.2.4 
2.3.2.5 
2.3.2.6 
2.3.2.7 
Administración de Proyectos en RAD (Rapid Application Development) ................ 22 
Administración de Proyectos en RUP (Rational Unified Process) ........................... 23 
Metodologías para Administración de Proyectos Ágiles ........................................... 24 
Administración de Proyectos en SCRUM .............................................................. 25 
Administración de Proyectos en KAMBAN ............................................................ 27 
SCRUMBAN ................................................ , ......................................................... 28 
Ventajas en SCRUMBAN ....................................................................................... 30 
Cuándo considerarlo ............................................................................................. 31 
KANBAN vs SCRUMBAN ....................................................................................... 31 
SCRUM VS SCRUMBAN .......................................................................................... 32 
2.4 Encuestas sobre Fallas en Proyectos de TI .................................................................. 33 
2.4.1 Encuestas en México .............................................................................................. 33 
2.4.1.1 Formato de la Encuesta ....................................................................................... 34 
2.4.1.2 Detalle y Aplicación de la Encuesta ...................................................................... 34 
2.4.1.3 Resultados .......................................................................................................... 35 
2.4.2 Encuestas Fallas en Proyectos de TI en Otros Países ................................................ 37 
-, 
.) 
2.4.2.1 Generalidades de la Encuesta .............................................................................• 37 
2.4.2.2 Factores de fracaso y éxito en los proyeictos ......................................................... 38 
2.4.2.3 Recomendaciones para Proyectos Exito,sos .......................................................... 40 
Capítulo 3 .................................................................................................................... 42 
Propuesta .................................................................................................................... 42 
3.1 Definición original de la metodología a modificar ....................................................... 42 
3.1.1 ¿Qué es SCRUMBAN? ............................................................................................. 42 
3.1.2 Proceso de implantación de SCRUMBAN................................................................. 47 
3.1.2.1 Identificar Etapas para el Proceso de D1:!sarrollo de Software ................................ 47 
3.1.2.2 Creación del tablero Kanban ................................................................................. 48 
3.1.2.3 Definición de límites iniciales de WIP .................................................................... 49 
3.1.2.4 Contenido de tarjetas Kanban ............................................................................... 50 
3.1.2.5 Preparación del work backlog .............................................................................. 50 
3.1.2.6 Establecimiento de juntas recurrentes ................................................................. 52 
3.1.2.7 Retos en SCRUMBAN ........................................................................................... 52 
3.2 Definición de propuesta de modificaciones a la metodología ...................................... 53 
3.2.1 Objetivo de la propuesta ........................................................................................ 54 
3.2.2 Proceso de implantación de SCRUMBAN (Afectado) ................................................ 58 
3.2.2.1 Creación del tablero Kanban ................................................................................ 59 
3.2.2.2 Contenido de tarjetas Kanban de Incidentes ........................................................ 62 
3.2.2.3 Preparación del Work Backlog ............................................................................. 62 
3.2.2.4 Establecimiento de juntas recurrentes ................................................................. 64 
Capítulo 4 .................................................................................................................... 65 
3.3 Definición de la propuesta ......................................................................................... 68 
3.4 Descripción de la propuesta ....................................................................................... 69 
3.4.1 Proceso de implantación de SCRUMBAN con manejo prioritario de Incidentes ......... 69 
3.4.1.1 Identificar Etapas del Desarrollo del Sistema de Pagos lnterbancarios .................. 69 
3.4.1.2 Creación de tableros ............................................................................................ 70 
3.4.1.3 Creación del Work Backlog .................................................................................. 72 
3.4.1.4 Establecimiento de juntas recurrentes ................................................................. 80 
3.5 Comprobación de la aplicación .................................................................................. 81 
Capítulo 5 .................................................................................................................... 84 
Conclusiones ............................................................................................................... 84 
Referencias ................................................................................................................. 86 
Anexo 1 ........................................................................................................................ 88 
4 
LISTA DE TABLAS 
TABLA l. COMPARACIÓN KANBAN-SCRUMBAN .................................................... 32 
TABLA 2. COMPARACIÓN SCRUM-SCRUMBAN ....................................................... 33 
TABLA 3. CONCEPTOS SCRUM-KANBAN .................................................................. .44 
TABLA 4. EJEMPLOS INCIDENTES POR TIPO DE SISTEMA .................................... 57 
TABLA 5. LISTADO DE ACTIVIDADES PARA APLICACIÓN DE PROPUESTA ..... 74 
TABLA 6. WORK BACKLOG DE ACTIVIDADES PARA APLICACIÓN DE 
PROPUESTA ....................................................................................................................... 78 
TABLA 7. WORK BACKLOG DE INCIDENTES PARA APLICACIÓN DE 
PROPUESTA ....................................................................................................................... 80 
5 
LISTA DE FIGURAS 
Figura 1. TENDENCIAS EN USO DE PROJECT MANAGEMENT ................................ 18 
Figura 2. FACTORES DE ÉXITO EN LA GESTIÓN DE PROYECTOS ......................... 20 
Figura 3. ITERACIONES .................................................................................................... 27 
Figura 4. TABLERO KANBAN .......................................................................................... 28 
Figura 5. PORCENTAJE DE ÉXITO/FRACASO DE PROYECTOS EN MÉXICO ......... 36 
Figura 6. PORCENTAJE DE ÉXITO/FRACASO DE PROYECTOS ................................ 39 
Figura 7. RAZONES DE FRACASO DE LOS PROYECTOS ........................................... 40 
Figura 8. FUSIÓN DE SCRUM Y KANBAN ..................................................................... 43 
Figura 9. TABLERO SCRUMBAN ..................................................................................... 45 
Figura 10. EQUIPOS KANBAN .......................................................................................... 46 
Figura 11. TABLERO KANBAN GRANDE ...................................................................... .49 
Figura 12. DIAGRAMA DE ACTIVIDADES URGENTES-IMPORTANTES ................. 54 
Figura 13. TABLERO SCRUMBAN CON INCIDENTES ................................................. 56 
Figura 14. TABLERO SCRUMBAN CON INCIDENTES EJEMPLO .............................. 58 
Figura 15. TABLERO KANBAN CON TRES CANALES ................................................. 59 
Figura 16. TABLERO KANBAN CON TRES CANALES E INCIDENTES .................... 61 
Figura 17. USO DE LOS MEDIOS DE PAGO DISTINTOS AL EFECTIVO ................... 66 
Figura 18. FLUJO EN SISTEMA DE PAGOS MEXICANO ............................................. 67 
Figura 19. TABLERO SCRUMBAN CON PROPUESTA APLICADA ............................ 71 
Figura 20. TABLERO KANBAN CON TRES CANALES E INCIDENTES Y 
PROPUESTA APLICADA .................................................................................................. 72 
6 
CAPÍTULO 1 
INTRODUCCIÓN 
La administración de proyectos en cualquier ámbito laboral, se hace más importante cada 
día. Es necesario administrar los recursos, las actividades, el tiempo, entre otros factores, 
para lograr conseguir la distribución más eficiente que permita cumplir con las actividades 
definidas dentro del proyecto general en tiempo y forma, así como lograr los objetivos 
establecidos desde el inicio del proyecto. 
Como lo explica el libro, "A Guide to the Prc?ject Management Body c?f Knowledge 
(PMBOK Cuide)" [Project Management Institute PMI, 2013], un proyecto es un esfuerzo 
temporal para crear un producto, servicio o resultado único e incluye la definición de un 
inicio y un fin. 
Por lo tanto, la Administración de Proyectos, es la aplicación de conocimientos, 
habilidades, herramientas y técnicas para completar actividades que satisfagan los 
requerimientos de un proyecto. Los procesos están propiamente integrados en 5 Grupos de 
Procesos: 
• Iniciación 
• Planeación 
• Ejecución 
• Monitoreo y Control y 
• Cierre 
• Existen diversas metodologías de administración de proyectos para estructuras las 
actividades de tal forma que se puedan concluir las tareas para alcanzar el objetivo 
definido en un principio. 
• Como caso práctico, se hablará sobre una nueva metodología de administración 
existente: SCRUMBAN, la cual mezcla aspectos de la metodología de 
administración de proyectos existente denominada scrum, y la metodología 
denominada kanhan. 
7 
1.1 MOTIVACIÓN 
A lo largo de este trabajo de investigación, se mencionará la integración de incidentes en 
ambientes operativos a un proyecto en desarrollo bajo un esquema de metodología de 
administración de proyectos Scrumban, todo esto basado en la necesidad de resolver 
problemas urgentes I enel menor tiempo posible y que surgen cuando el proyecto ya está 
definido y las actividades ya han sido delimitadas y distribuidas entre los miembros del 
equipo de trabajo. La resolución de incidentes absorbe tiempo y recursos humanos para ser 
resuelta, además de ser catalogados como la tarea de mayor importancia y urgencia dentro 
de un proyecto, cuando este se encuentra en un ambiente de operación para el usuario, ya 
que puede llegar a detener las actividades cotidianas de los usuarios de un producto, 
sistema o servicio. 
Por estas razones, esta investigación está enfocada en la propuesta de una metodología de 
administración de proyectos que desde su planeación permita garantizar el cumplimiento de 
las actividades que lo integran y la utilización óptima de los recursos asignados para los 
proyectos que ya se encuentran en funcionamiento pero aún requieren de mantenimiento y 
desarrollo. Esto al contemplar, desde la creación del plan de trabajo, la reservación de 
ciertos recursos para la resolución de los incidentes que se vayan presentando en el 
proyecto en el tiempo paralelo en el que se vayan llevando a cabo las actividades planeadas, 
tomando en cuenta que de ahora en adelante nos referiremos a un incidente como una 
interrupción del servicio (el usuario no puede continuar con sus funciones primordiales). 
1.2 DEFINICIÓN DEL PROBLEMA 
La falta de consideración de las actividades que surgen durante el desarrollo adicional 
dentro un proyecto de sistema operativo o ya existente, ha hecho que la planeación del 
mismo sea inconsistente con el tiempo en que se desarrollan sus actividades, 
1 La continuidad del proceso de operación está interrumpida por esta falla y por eso se considera urgente de 
resolver. 
8 
desencadenando en desorganización de las prioridades, actividades, recursos y asignación 
de estos últimos. 
Por otro lado, es importante tomar en cuenta que a lo largo de un proyecto administrado por 
una metodología de administración de proyectos ya definida o existente, no siempre se 
toman en cuenta los incidentes o actividades sobre el ambiente productivo que se 
desencadenan fuera del tiempo considerado o planeado desde un principio, lo cual absorbe 
recursos humanos y de toda índole durante el desarrollo de actividades planeadas y retrasa 
la culminación de las mismas en tiempo y forma y puede causar el fracaso del proyecto 
completo. 
Adicional a esto, el registro de estas actividades llega a ser confuso o nulo dentro de la 
documentación de la administración de las actividades del proyecto, lo cual hace difícil de 
rastrear las actividades de los miembros del equipo y a su vez, el consumo de recursos por 
parte del proyecto. 
Por esta razón, existe la necesidad de investigar si existe alguna alternativa para incluir 
estos factores de alguna forma a las metodologías de administración de proyectos, en este 
caso, a un ejemplo específico como scrum2 y kanhan3, conjuntándose en una metodología 
llamada Scrumban4, donde se les puedan incluir actividades prioritarias que afectan el 
ambiente productivo en tiempo real (incidentes) y que proporcionan valor estratégico a la 
compañía para su resolución en el menor tiempo posible, por lo cual demandan una gran 
cantidad de recursos asignados para su solución y apoyar a la administración del proyecto 
mediante la estimación temprana de esfuerzo. 
El valor agregado será permitir al administrador del proyecto distribuir las actividades de 
tal forma que le facilite la planeación del proyecto y la distribución de las actividades con 
e Es una forma para los equipos de trabajar juntos para desarrollar un producto, a través de pequeña~ partes donde cada 
parte va creando otra parte mayor. Es electivo para la colaboración de equipo en proyectos complejos. 
https://www.scrum.org/Rcsourccs/What-is-Scrum 
.1 Es visto principalmente como el elemento central de la manufactura de soporte y es probablemente el más usado en el 
sistema de empuje para enviar los materiales a producción de acuerdo a la demanda del cliente. 
hllp://uk.kaizen.com/knowledgc-centcr/kanban.html 
4 Es un proceso mejorado usando kanban basado en tlujos tan cercano a tlujos de una sola pieza. 
http://xprocess.blogspot.mx/2013/06/what-is-scrumhan.htm 1 
9 
los recursos que cuenta tratando de aprovechar al máximo las capacidades de los mismos 
pero al mismo tiempo atendiendo las actividades con mayor urgencia de atención sin dejar 
de lado algunas actividades que son parte del ciclo de vida del proyecto. 
Los incidentes son parte de cualquier proyecto de TI que se encuentre en un ambiente 
productivo y tienen que ser atendidos en tiempo récord ya que pueden poner en riesgo la 
operación de una empresa u organización, por lo que es importante dedicar un porcentaje 
del equipo de trabajo dentro de los ,\prints del proyecto para que puedan dedicarse a la 
resolución de este tipo de actividades, aunque no se trate de actividades cotidianas ni 
definidas desde el principio del .\print ni del proyecto incluso. 
1.3 ÜBJETIVOS 
El objetivo principal de este proyecto de investigación es meJorar el proceso de 
administración de proyectos, basándose en determinar una forma metodológica para 
incorporar los incidentes y problemas en ambientes productivos a un modelo de 
administración de proyectos que se basa en un tablero de actividades; y con esto, incorporar 
el costo por consumo de tiempo en la atención de incidentes en ambientes productivos para 
ayudar al desarrollo de proyectos exitosos. 
El proyecto tendrá como beneficio principal maximizar la utilización del tiempo y recursos 
dentro de la distribución de actividades para ayudar a disminuir el número de proyectos 
incumplidos en tiempo, evaluando en recursos utilizados el valor que estos aportan al 
negocio. 
La aportación principal del trabajo será presentar una propuesta de metodología de 
administración de proyectos que incluya la optimización de recursos, basándose en el mejor 
aprovechamiento de los que se cuentan (tiempo, personal, recursos tecnológicos y 
económicos, etc.). 
10 
1.4 HIPÓTESIS 
En esta investigación se buscará demostrar que se puede garantizar el cumplimiento en 
tiempo del proyecto con base a lo acordado con el usuario, sin dejar de lado ninguna de las 
actividades que se definen desde el principio del proyecto e incorporando la atención de 
incidentes que surgen durante la marcha del sistema (al tratarse de un sistema en ambiente 
productivo), así como las actividades con mayor prioridad que se presenten durante el 
desarrollo del mismo. 
1.5 METODOLOGÍA 
Para la realización de este trabajo se propone la investigación de los factores de éxito y 
fracaso en la realización de los proyectos de tecnologías de información en el ámbito para 
comprobar la hipótesis al respecto de la administración de los mismos respecto al uso de las 
metodologías de administración en los equipos de trabajo y su aplicación. 
Todo ello para relacionarlo con las existentes metodologías de administración de proyectos 
en el ámbito de tecnologías de información a lo largo de la historia de este giro, la 
evolución que han tenido y los factores que han intervenido en esta evolución para dar paso 
a nuevas metodologías y a la desaparición de anteriores. 
De esto se desprende la selección de dos metodologías preferidas por su composición e 
integración que al unirlas dan paso a una metodología más completa e integrada y que 
permite dar paso a la inclusión de los incidentes y actividades no planeadas, que es el área 
de oportunidad que se ve en el inicio de nuestro trabajo, el cual llevará a la disminución de 
fracaso en el tiempo comprometido con nuestros clientes que se demostrará con las 
estadísticas de los estudios realizados a lo largo del país y del mundo entero en el ámbito de 
proyectos tecnológicos. 
Finalmente, se propone un caso práctico de aplicación en el sistema financiero mexicano 
con la metodología de administraciónde proyectos de tecnologías de información para 
integrar actividades no planeadas en un sistema de este tipo de acuerdo a la prioridad de las 
11 
actividades que así se requieran sin descuidar las actividades ya planeadas proveyendo las 
herramientas necesarias para su monitoreo y contemplando las cargas de trabajo de los 
elementos del equipo de trabajo de una manera equilibrada sin descuidar ningún factor del 
proyecto general. 
1.6 ESTRUCTURA DE LA TESIS 
En el Capítulo I del presente trabajo, se describe la motivación de esta investigación y el 
problema a solucionar con la propuesta que se presentará al final del mismo, explicando el 
estado actual de la administración de los proyectos de software y la importancia de que los 
administradores de los proyectos apliquen adecuadamente la metodología elegida para 
evitar retrasos en sus entregas evitando con esto las fallas en los proyectos mencionados y 
así poder cumplir con las estrategias del negocio y así dejar claro el valor que los proyectos 
de TI pueden agregar. De esta manera, para el caso práctico se presenta la incorporación de 
las actividades no planeadas, y siempre resueltas de forma urgente por el equipo de trabajo, 
a la planeación de los proyectos dentro de los tiempos contemplados y los registros de las 
actividades para evitar que el rastreo de las mismas y de las asignaciones de los equipos de 
trabajo sean mal monitoreadas o ineficientemente extraviadas dentro de la organización, 
derivándose en incumplimiento de fechas y tiempos comprometidos con el cliente. 
Posteriormente, se presentan los objetivos de la investigación, el cual consiste en mejorar el 
proceso de la administración de proyectos misma, basándose en la incorporación de estas 
actividades no planeadas en el modelo de administración de proyectos basado en un tablero 
de control de actividades incluyendo un manejo eficiente de recursos. Todo esto se aplica 
posteriormente a un sistema informático del sistema financiero mexicano. 
Por último, se detallan los cambios que se hacen a la metodología existente, en granularidad 
a todos sus componentes para poder incluir los factores necesarios para manejar las 
actividades no planeadas de manera adecuada y obtener el resultado deseado de conclusión 
del trabajo en tiempos acordados con el usuario final. 
12 
En el Capítulo 2, se detalla el grupo central de conceptos y teorías para formular el 
argumento presentado en la investigación. Primero se describen las principales 
metodologías existentes para administrar los proyectos de tecnologías de información. 
Posteriormente se interioriza en los tipos diferentes de administración de proyectos, estilos 
que se han utilizado en lo largo de la evolución de los proyectos de acuerdo a las 
necesidades de las organizaciones. Lo cual deriva en la descripción de las metodologías 
base para la metodología elegida, la metodología SCRUM Y KANBAN, llevando a una 
posterior comparación entre ellas y una descripción de la metodología que nos centra a este 
trabajo, SCRUMBAN. 
Para fortalecer el punto de vista de las fallas que se presentan por la mala administración de 
proyectos se presentan estadísticas respaldadas por encuestas globales y en el país que son 
analizadas por diversos factores que se derivan ele ella. 
En el Capítulo 3, se presenta la propuesta de solución, donde se especifica paso a paso el 
procedimiento para garantizar el valor estratégico que aportará una modificación a la 
metodología de administración de proyectos Scrumban, iniciando por una descripción 
profunda de lo que ésta se trata. Asimismo, se presenta a detalle cómo se deberá modificar 
cada uno de los factores que se requiere en esta metodología para que pueda aplicarse la 
factibilidad de su manejo de actividades no planeadas. 
En el Capítulo 4, se puntualiza la aplicación de la propuesta a un ejemplo de sistema 
financiero mexicano, que es el caso práctico propuesto a desarrollar y cada uno de los 
aspectos que se deberá integrar para hacerlo. Se describen las actividades que integrarán 
esta propuesta en un ejemplo aplicado real y la forma en que deberán integrarse en esta 
metodología de acuerdo a la propuesta de modificación de este trabajo, de la misma forma 
se presenta una comprobación de efectividad de la propuesta a través de los resultados de 
entrevistas realizadas a administradores de proyectos que posterior a la lectura del presente 
trabajo dieron sus conclusiones al respecto. 
Finalmente, en el capítulo 5 se presentan las conclusiones que se desprenden de este trabajo 
de investigación. 
13 
CAPÍTULO 2 
Estado del Arte 
El siguiente trabajo está sustentado en referencias bibliográficas principalmente asociados a 
la administración de proyectos y las metodologías que existen para esta disciplina. Sin 
embargo, a esto se le asocian varios conceptos de soporte como lo son los incidentes y las 
estadísticas de fallas de proyectos de tecnologías de información recolectadas de encuestas 
llevadas a cabo a nivel mundial y específicamente en nuestro país. 
Toda la investigación referente a estos temas tienen cabida en este apartado, sustentados en 
bibliografía y metodologías asociados a estos campos. 
2.1 Certificación ITIL: Gestión de 
Incidentes, Perspectiva General 
En esta investigación se tratan de incluir los incidentes en la administración de un proyecto 
para evitar fracasos en los proyectos por no planear el tiempo invertido en la resolución de 
los mismos. Por tanto, cobra relevación hablar de una metodología que se basa 
principalmente en administrar los incidentes y solicitudes de servicio totalmente a fondo. 
Un incidente se describe como una interrupción no planeada de un servicio de tecnologías 
de información o una reducción en la calidad de un servicio de tecnologías de información, 
según la certificación ITIL 5. 
2.1.1 Descripción del proceso 
La certificación ITIL se encarga de manejar el ciclo de vida de todos los incidentes, 
teniendo como finalidad principal devolver el servicio a los usuarios lo antes posible. Se 
establecen diferencias entre los incidentes y las solicitudes de servicio (requerimientos 
5 http://wiki.es.it-processmaps.com/index.php/ITI L _ Gestion _ de __ Incidentes 
14 
adicionales que no intervienen con el ciclo normal de funcionamiento del sistema, ejemplo: 
solicitud de contraseñas). De los incidentes se encarga el módulo de Gestión de Incidentes 
en ITIL 6 además de clasificar también los Incidentes Graves. Adicional a esto, existe una 
interfaz entre los módulos de gestión de eventos y de incidentes para que los eventos 
significativos puedan desencadenar en un incidente. 
2 .1.1.1 Gestión de Incidentes 
A forma de conocer el módulo en ITIL que se encarga de administrar los incidentes, este se 
describirá a través de qué sub procesos se compone: 
Soporte a Gestión de Incidentes: Proveer y mantener las herramientas para manejo 
de incidentes de forma efectiva y eficiente. 
Registro y Categorización de incidentes: Registrar y asignar prioridades a los 
incidentes para dar solución a los mismos de forma efectiva e inmediata. 
Resolución de incidentes por el soporte de primera línea: Resolver el incidente 
(interrupción del servicio) en el periodo acordado. La meta con el usuario es 
restablecer el servicio de TI lo más pronto posible, aunque sea con una solución 
provisional. Si es comprobado que la primera línea no puede resolver el incidente o 
es excedido el tiempo compromiso, entonces el incidente se turnará al grupo 
adecuado de soporte de segunda línea. 
Resolución de incidentes por el soporte ele segunda línea: La meta de igual forma es 
restablecer el servicio lo antes posible, aun con una solución temporal e 
involucrando a grupos de soporte especiales e incluso, externos (tercera línea). Si no 
es posible esta alternativa, se crea un registro del problema y se transfiere el caso a 
Gestión de Problemas. 
Gestión de Incidentes Graves:Causan interrupciones considerables en la empresa y 
deben resolverse con mayor urgencia. Se busca el restablecimiento temprano de los 
" lnformation Technology !nfrastnicture libra,y, Conjunto de Conceptos y Prácticas para la gestión de 
tecnologías de la if!lormación, desarrollo de las tecnologías de la if!lormación y las operaciones relacionadas 
con la misma en general. Da descripciones detalladas de un extenso COf!junto de procedimientos 
independientes del proveedor, desarrollados como guía para abarcar toda la infraestructura, desarrollo y 
operaciones de TI. http://www.itil-<~[ficialsite.com/ 
15 
servicios, aunque sean soluciones temporales. Si no es posible resolverse, se crea un 
registro del problema y se transfiere el caso a Gestión de Problemas. 
Monitorización y Escalado de Incidentes: Monitorear el estatus del procedimiento 
de incidentes pendientes para contrarrestar de forma inmediata efectos adversos en 
caso de que peligren niveles de servicio. 
Cierre y Evaluación de Incidentes: Someter el registro de incidente al control de 
calidad final antes de un cierre, la meta es asegurarse de que se haya resuelto y que 
toda la información para describir el ciclo de vida del incidente haya sido sometida 
con suficiente detalles y los hallazgos se documentarán para futuras referencias. 
Información pro-activa a usuarios: Informar a los usuarios de fallos en el servicio 
tan pronto como se conozcan en la mesa de servicio para que los usuarios se 
encuentren en posición de hacer ajustes ante las interrupciones, esta información 
proactiva dada a los usuarios ayuda a reducir las solicitudes de los mismos. 
Informes de Gestión de Incidentes: Proveer información relacionada con los 
incidentes para uso en otros procesos de gestión de servicios y para asegurar que los 
incidentes previos sirvan para potenciar las mejoras. 
2.2 Sobre la Administración de Proyectos 
Project Manager (Rol) 
En 2012, un estudio del Pn~ject Management /nsütute7 citado en un artículo de la revista 
Harvard Business Review8 sobre el rol de Prqject Manager (administrador de proyectos), 
arrojó resultados favorables sobre esta profesión y un aumento de la importancia de ésta 
dentro de las organizaciones. 
De acuerdo con el estudio, la importancia que ha cobrado este rol dentro de las empresas 
surge de la necesidad (en tiempos de crisis) de las empresas de obtener el máximo de sus 
inversiones, aumentar su capacidad de adaptación y la velocidad de lanzamiento de sus 
productos, para lo cual la gestión de proyectos cobra un papel determinante. 
7 http://www.pmi.org/-/media/PDF/Research/2012 _Pulse_ of _the _profession.ashx 
8 http://blogs.hbr.org/2012/06/when-risk-reduction-is-rocket/ 
16 
Los principales puntos de atención en las empresas en 2012 para consegutr estos 3 
objetivos son: 
Mejorar el talento en la gestión de programas, proyectos y portafolios. Gestionar los 
proyectos de forma más efectiva y definir carreras profesionales relacionadas con la 
gestión de los proyectos. 
Adaptarse a las duras condiciones económicas mediante una buena gestión del 
portafolio de proyectos. Realizar una buena selección de los proyectos y una buena 
adecuación de los recursos para conseguir la adecuada implantación de la estrategia, 
conseguir un control de presupuesto y dar mayor visibilidad global utilizando 
prácticas de Porfolio Managemenl. 
Incrementar el uso de las prácticas de gestión de cambio y de gestión de riesgos 
para aumentar la agilidad de la organización. 
Conseguir una mayor adaptabilidad mediante el uso de métodos iterativos e 
incrementales corno Ag;fe o Extreme Proiecl Managemenl. 
Lograr una mayor concentración en la realización de los beneficios corno métrica 
para el éxito o fracaso de un proyecto. 
Las tendencias en el uso de la administración de proyectos han sido positivas en los últimos 
años hacia el uso de la mayoría de las prácticas de implantación de Project Management en 
las empresas. El dato negativo es la disminución del proceso formal de desarrollo de 
competencias del Projecl Manager. 
17 
Uso gestión de cambios 
Uso gestión de riesgos 
Tener una MPO 
Uso de program management 
Uso de prácticas estandarizadas de 
project management 
Uso de portfolio management 
Uso de procesos formales de PPM 
Tener un proceso fromal de 
desarrollo de competencias del 
PM 
Uso de earned value 
Uso de prácticas ágiles 
Uso de métodos extremos de 
Project Management 
.2.(iJ.1 
---------- 73% 71%·- 71% 
68% 67% 
63% 65% 
::: =-=--·:··· .:.., .:.:··-;:;·"·;;;;,···· ;;,;····;;;;,•"·;;.;-- ·- --··""'P\~ ... ~ .. -.-.. :-"'.'.'.'.'. .... ::-:.,--:::::=:. {)~9fo 
52% 
51% 
50% 
37% 
24% 
15% 
55% 
50% 
47% 
42% 
- -------- 27% 
20% 
FIGURA l. TF.NDENCIAS EN lJSO DE PRO.JECT MANAGF.MENT 
DATOS {PMI. 20 12). ELAUORACIÓN PROPIA 
La figura I nos indica el porcentaje de uso en el año 201 O y el porcentaje de uso en el año 
2011 en cada una de las prácticas de administración de proyectos que se trataron en el 
estudio, así como la marcada diferencia de tendencia que han tenido estas estrategias entre 
ambos años. Del mismo, destaca que, las más utilizadas, sin sorpresas, son: 
18 
• Uso de gestión de cambios: desde hace I O años, esta práctica ha aparecido como la 
más madura. 
• Uso de gestión de riesgos: sigue su incremento en los últimos años como respuesta 
a la creciente incertidumbre que tiene que abordar los proyectos. 
• Disponer de una PMO (Oficina de Gestión de Proyectos): sigue creciendo y se ha 
convertido en la respuesta organizativa que adoptan las empresas para coordinar las 
actividades de Pr<~ject Management. 
De las que se encuentran en una tendencia descendente, la palabra formal es un factor 
común en ellas, que se tratan de: 
• Tener un proceso formal de desarrollo de competencias del Pr<~ject Manager. 
• Uso de procesos formales de gestión de proyectos, programas y portafolios (PPPM): 
contrasta con el aumento en el uso de prácticas, parece que se tiende a procesos más 
adaptables y menos formales. 
En cuanto a las que se adoptan con mayor rapidez, resalta la flexibilidad, orientación de 
resultados y control de las inversiones. Se engloban: 
• Uso de valor agregado (earned value): aumenta un 10%, parece que la mayor 
preocupación del control de costos y de las inversiones está provocando su adopción 
rápida. 
• Uso de métodos extremos de Project Management: aumenta un 5%, junto con los 
métodos ágiles que son una respuesta a la necesidad de resultados y flexibilidad. 
En cuanto a la revisión de los factores de éxito en la gestión de un proyecto, en la figura 2 
se muestran los resultados de un estudio que arrojó la forma en que se clasifican estos 
factores y el porcentaje de éxito de cada uno de ellos. 
19 
FIGURA 2. FACTORES DE i::xrro EN LA GESTIÓN DE PROYECTOS 
DATOS (PMI. 2012). ELABORACIÓN PROPIA 
Clasificando estos factores en tres grupos dependiendo de los factores que afectan a la 
organización, al Project Manager y a los métodos en general: 
A la organización: 
o Tener sponsors activos en el 80% de la organización. 
o Tener una PMO. 
Projecl Manager: 
o Tener más del 35% de Project Managers certificados PMP 
o Tener una carrera profesional para los Project Managers 
20 
o Tener un proceso formal para el desarrollo de competencias del Project 
Manager 
Métodos: 
o Uso de risk management 
o Uso de portafolio management 
o Uso de prácticas estándar de Project Management 
o Uso de gestión de cambios 
o Tener un proceso formal de madurez de las prácticas existentes 
o Uso de agile Project Management 
A partir de esta clasificación de factores, se concluye que las empresas que tienen mejores 
resultados en la gestión de proyectos cuidan la metodología de gestión de proyectos, le dan 
importancia al Prqject Manager y adaptan la organización a las características de los 
proyectos. 
de Proyectos 2.3 Administración 
Metodologías para 
Proyectos deTI 
Administración de 
Una metodología para administración de tecnologías de información es un conjunto de 
procesos repetitivos diseñados para construir sistemas de aplicaciones cualitativos. La 
metodología consiste de cuatro componentes básicos: guías, técnicas, herramientas y 
plantillas. 
Las guías son los pasos necesarios para el desarrollo del producto y usualmente 
contienen recomendaciones. 
Las técnicas son las descripciones de los procesos detallados de las actividades 
necesarias para completar el proyecto. 
Las herramientas en las tecnologías de la información generalmente incluyen las 
características del hardware y software del sistema a desarrollar. Esta sección debe 
ser específica en cuanto a las versiones y tipo de software a utilizar. 
21 
Las plantillas generalmente consisten de listas de cosas por hacer y hojas de 
consejos para mejores prácticas. 
La función de una metodología es asegurarse de que el desarrollo de un producto cumpla 
con las especificaciones y estándares establecidos en el análisis de diseño preliminar. En 
cuanto a los beneficios que puede proporcionar el uso de una metodología de 
administración de tecnologías de información se encuentra el avanzado conocimiento de las 
especificaciones del producto a ser desarrollado, adherencia a los diseños originales del 
producto, resultados de alta calidad, incrementos en productividad, mejoras en 
comunicación, minimización de costo y tiempo por devolución del producto en tiempos 
detallados de las etapas del proyecto. 
2.3 .1 Metodologías para Administración de 
Proyectos Tradicionales 
Se trata de metodologías lineales que se gestionan de manera predictiva y siguiendo una 
planificación inicial sin entregar valor al cliente hasta que se produce una entrega final 9. 
2.3 .1.1 Administración de 
RAD (Rapid 
Development) 
Proyectos en 
Application 
Involucra un proceso iterativo y la construcción de prototipos, es un término que se utilizó 
originalmente por James Martín en 1991. Los principios generales son: 
El objetivo principal es un desarrollo y entrega rápida de un sistema de alta calidad 
a un bajo costo de inversión. 
9 Diferencias entre la gestión tradicional y la gestión ágil de Proyectos de Software. 17 de Enero de 2013. 
http:/ /proyectosgestionyexcelencia.com/2013/01 / 1 7 /diferencias-entre-la-gestion-trad icional-y-la-gestion-agi !-
de-proyectos-de-software/ 
22 
Trata de reducir el riesgo del proyecto dividiéndolo en pequeños segmentos y a la 
vez provee facilidad de cambios en el mismo durante el proceso de desarrollo. 
Intenta producir sistemas de alta calidad rápido, principalmente vía prototipos 
iterativos (en cualquier etapa del desarrollo), con involucramiento activo del usuario 
y herramientas computarizadas de desarrollo. Estas herramientas incluyen interfaces 
gráficas de usuario (GUI), sistemas de manejo de base de datos (DBMS), lenguajes 
de programación de cuarta generación, generadores de código y técnicas orientadas 
a objetos. 
Énfasis a las necesidades del negocio mientras que mantiene su liderazgo en 
excelencia de ingeniería de desarrollo. 
lnvolucramiento activo del usuario es imperativa. 
Producción iterativa de un software productivo, opuesto a un prototipo desechable. 
Generación de documentación necesaria para facilitar el desarrollo y mantenimiento 
futuro. 
Métodos de análisis y diseño estándar de sistemas. 
2.3.1.2 Administración de Proyectos en RUP 
(Rational Unified Process) 
Se trata de una metodología iterativa que unifica a miembros de seis equipos de ingeniería 
de software para cumplir con las necesidades de la organización y producir software de alta 
calidad. 
Las seis disciplinas que abarca RUP son: 
Modelo de negocio. 
Diseño de Requerimientos. 
Análisis y Diseño. 
Diseño de Proceso y Software e Implementación. 
Pruebas de Software y Aplicación. 
Pruebas Finales. 
23 
La metodología sigue un proceso iterativo con fases dentro de la organización, las fases 
dentro de la organización se listan a continuación: 
1. Creación: Los casos de negocio son creados para discutir entre los miembros de la 
organización, estos incluyen los factores de éxito, asesorías de riesgo, creación de 
un plan de proyecto y un modelo de casos de uso. El administrador del proyecto 
creará un documento de iniciación del proyecto o gráfica de proyecto durante esta 
fase. 
2. Elaboración: Esta fase está marcada por la mitigación de los riesgos por el propio 
análisis del mismo. Incluye el desarrollo de la forma básica de la arquitectura del 
proyecto y la descripción de los casos de uso. Los casos de uso son revisados para 
revisar los riesgos del proyecto y asegurar que la administración del riesgo del 
proyecto sea posible. Luego el desarrollo del plan es concluido, seguido por la 
conclusión de los prototipos para demostrar cada uno de los riesgos técnicos que se 
han tomado en cuenta y si no, el proyecto se cancela. 
3. Construcción: Se concentra en la parte fuerte del ciclo de vida del desarrollo, el 
código es escrito para los varios componentes y otras partes del software. 
Dependiendo del tamaño del sistema, las iteraciones pueden incrementarse. 
4. Transición: El producto se mueve de la fase de desarrollo a producción en esta fase 
de la metodología RUP, el usuario puede tener una primera vista del software como 
producto final. El software pasa por una fase beta para ser probado contra un plan 
de calidad de proyecto detallado que se generó durante la fase de creación. 
2.3.2 Metodologías para Administración de 
Proyectos Ágiles 
Derivado de la alta ineficiencia que representaba la necesidad de documentación en las 
metodologías tradicionales como RUP, donde se sigue una metodología basada en el ciclo 
de vida, se desarrollaron metodologías de administración de proyectos ágiles en las cuales 
se aplican mejores prácticas para llevar a cabo los procesos de administración basados en el 
24 
proceso de desarrollo del proyecto de forma ágil y rápida sm necesidad de procesos 
innecesarios e ineficientes. 
Se mencionan dos axiomas en el desarrollo del software de manera ágil: 
Axioma 1. Es posible dividir el trabajo en incrementos pequeños de valor agregado 
que pueden ser independientemente calendarizados. 
Axioma 2. Es posible desarrollar cualquier incremento de valor agregado en un 
flujo continuo de requerimiento a deployment. 
A continuación la descripción de las principales metodologías de desarrollo de proyectos 
ágiles seleccionadas para fines de este trabajo. 
2.3.2.1 Administración 
SCRUM 
de Proyectos en 
Scrum enfatiza la idea de control de proceso empírico, es decir, usa el progreso de un 
proyecto en el mundo real, no un buen pronóstico o aproximación, para hacer un plan de 
entregas. Se organizan los proyectos en cadenas de trabajo continuas conocidas como 
sprints que normalmente duran entre una y tres semanas. Al final de este periodo, los 
promotores del proyecto y los miembros del equipo se reúnen para concluir el avance del 
proyecto y planear los siguientes pasos del mismo. Esto permite marcar una dirección que 
puede ser ajustada o re-orientada basada en trabajo completado y pendiente y no en 
especulaciones o predicciones. Es mejor orientado a proyectos de desarrollo y productos. 
Lo que permite a scrum llevar a cabo este tipo de trabajo son los roles que marca dentro del 
equipo, así como las responsabilidades que asigna a cada uno de estos roles y las juntas que 
nunca cambian. Los roles que existen dentro de esta metodología son los siguientes: 
• Product Owner: es el responsable de la comunicación de la visión del producto al 
equipo de desarrollo, a su vez también representa los intereses del consumidor a 
través de la priorización de requerimientos. Es quien tiene mayor prioridad entre los 
roles y por lo tanto quien tiene mayor responsabilidad, por lo tanto es difícil 
25 
encontrar su balance de involucramiento. Deben saber mantenersu nivel de micro 
administración del proyecto y a la vez estar disponibles para preguntas de cualquier 
miembro del equipo. 
• Scrum Master: Actúa como un facilitador para el product owner y el equipo. Este 
rol no maneja al equipo, sin embargo elimina cualquier impedimento que 
obstaculice al equipo de cumplir sus metas de equipo. En corto plazo, este rol ayuda 
al equipo a mantener la creatividad y productividad mientras que se asegura de que 
el éxito esté visible para el product owner. También se encarga de advertir al 
product owner de cómo maximizar el retorno de inversión (ROi) para el equipo. 
• Team Member: En esta metodología, el equipo es el responsable de completar el 
trabajo. Idealmente, consisten de siete miembros funcionales en todas las áreas. Para 
proyectos de software, incluye una mezcla de seis ingenieros de software, 
arquitectos, programadores, analistas, expe1tos QA, tester.\· y diseñadores de 
interfaces. Cada ,\print, el equipo es responsable de determinar cómo será 
completado el trabajo asignado, esto le delega al equipo un alto grado de autonomía, 
acompafiado de un alto grado de responsabilidad para completar las metas 
acordadas en cada ,\print. 
La descripción de los pasos del proceso de administración de proyectos que se realiza en 
esta metodología se lista a continuación: 
Dividir la organización en equipos pequeños, funcionales y auto organizacionales. 
Dividir el trabajo en una lista de entregables pequeños y concretos, ordenándolos 
por prioridad y estimando el esfuerzo relativo para cada uno de ellos. 
Dividir el tiempo en pequeñas iteraciones tijas (usualmente de entre I y 4 semanas) 
con entregables potenciales, demostrables y acumulables después de cada iteración. 
La descripción gráfica de las iteraciones se aprecia en la figura 3, donde se 
distribuyen las actividades en diferentes periodos de tiempo de la misma duración, 
durante 4 meses (de enero a abril), y que contienen diferentes actividades para ser 
completadas en cada una de esas repeticiones. 
26 
FIGURA 3. ITERACIONES 
DATOS (KNl8ERG & SKARIN. 2010), ELABORACIÓN PROPIA 
Optimizar el plan de entrega y actualizar las prioridades en colaboración con el 
cliente, basándose en las introspectivas obtenidas de los resultados 
entregados/obtenidos después de cada iteración. 
Optimizar el proceso teniendo una retrospectiva después de cada iteración. 
En conclusión, la administración de proyectos en scrum consiste en sustituir un grupo 
grande de trabajo invirtiendo un largo tiempo para construir un gran proyecto por pequeños 
equipos invirtiendo varios periodos de tiempo pequeños en construir proyectos menores e 
integrándolos constantemente para llegar a un objetivo más grande y completo. 
2 .3 .2 .2 Administración 
KAMBAN 
de Proyectos en 
Kanhan es una metodología mejor conocida por su aplicación durante el soporte al proceso 
de producción. El proceso de administración de proyectos que se realiza en kanhan se lleva 
a cabo a través de las siguientes actividades gent:::rales: 
• Visualizar el flujo de proyecto: 
o Dividir el trabajo en actividades,. escribir cada una de ellas en una tarjeta y 
colocarla en la pared o tablero. 
o Usar columnas nombradas para ilustrar en cuál de estas columnas se 
encuentra cada una de las actividades. 
• Limitar el Trabajo en Proceso (WIP): Asignar límites específicos para cuántas 
actividades pueden estar en progreso en cada estado del flujo del proyecto (trabajo). 
27 
• Medir el tiempo de "completado": se trata del tiempo que se necesita para completar 
una actividad, también se nombra "tiempo de ciclo". Tratar de optimizar el proceso 
para que el tiempo sea tan pequeño y predecible como sea posible. 
ACTIVIDADES 
Por hacer En desarrollo Pruebas Publicadas Terminadas 
_l,-1 1 fFl i A 1 
¡- --------,..,_-t-----;:-.:::.:::-.:::.:::~- --t--- ----'--------+----'---..¿__-
l J ! ! B ! _, ____ ........J L ___ ; 
- ·--- ------;---- ----- ---f----- --· ·- ··-- ·-·--·-----···--- --------··-
·----~ 
j H 1 
. ! E 
FIGURA 4. TABLERO KANBAN 
DATOS (KNIBERG & SKARIN, 2010), ELABORACIÓN PROPIA 
El tablero kanban se representa en la figura 4 con todo el flujo del proyecto, las etapas en 
donde se van movimiento las actividades durante su ciclo de vida, dependiendo del avance 
que haya dentro de ellas. Comienzan en una etapa "por hacer" que es donde se encuentran 
todas las actividades de forma inicial y a medida que se van avanzando, se moverán por las 
etapas de desarrollo, pruebas, publicadas hasta llegar al estado final "terminadas" donde se 
dan por completadas en el proyecto. 
2.3.2.3 SCRUMBAN 
Después de describir brevemente de qué se trata scrum y kanban por separado como 
metodologías de administración de proyectos, Pahuja (2012) nos ayuda a entender de qué 
se trata una conjunción de ambas metodologías llamada Scrumban. 
Utiliza la perspectiva natural de scrum para ser ágil. 
28 
Usa la mejora de proceso de Kanban para permitir al equipo mejorar el mismo 
dentro del proyecto. 
Scrumban fue creado para las situaciones cuando no es suficiente Scrum ni Kanban para 
satisfacer las necesidades de la compañía. Se trata de una metodología comprometida entre 
scrum y kanban que incrementa la aplicabilidad y versatilidad en una herramienta, se ha 
vuelto popular por su habilidad para incrementar la eficiencia de administración del 
proyecto sin el consumo excesivo de tiempo y decremento de la ílexibilidad en la 
administración del equipo, mezcla la flexibilidad de kanban y las características básicas de 
scrum. 
Esta metodología está basada en el valor de negocio, que no es lo mismo que valor del 
cliente o utilidad del usuario. Se busca proveer al equipo de desarrollo con la mejor cosa 
siguiente para hacer y no más ni menos, planear más a futuro no aporta nada y simplemente 
se considera una pérdida de tiempo hacerlo. 
Podemos utilizar nuestros ciclos entre procesos y diagramas de flujos para demostrar las 
debilidades y oportunidades para mejorar. Al acercarse a etapas productivas, estaremos 
menos concertados sobre la distribución del tiempo de trabajo y más preocupados sobre el 
ciclo del trabajo completo, a consecuencia de que uno es el efecto del otro y el otro es la 
causa. El tiempo promedio invertido en las actividades y en el ciclo de trabajo será el 
objetivo primario de enfoque para el desempeño. Si el ciclo del proyecto está bajo control y 
la capacidad del trabajo está bien balanceada contra la demanda, entonces el tiempo de 
conducción está bajo control, si este tiempo está bajo control entonces la distribución del 
tiempo en las actividades (burndown) es predecible y desinteresada. 
El principio pul! es bien conocido por los equipos kanban, ya que la idea es que los 
miembros del equipo conozcan bien las tareas en las que podrán trabajar a lo largo del 
proyecto. Estas tareas se colocarán en el tablero y no se asignarán arbitrariamente sino que 
los miembros del equipo las elegirán de acuerdo a las habilidades que tengan y con las que 
se sientan capaces de resolver esas tareas. Posterior a ello, el líder del proyecto tendrá que 
procesar la selección de estas tareas y priorizar la demanda de las mismas para asegurarse 
29 
que la selección haya sido equitativa de acuerdo a las actividades que tienen más valor para 
ser real izadas prioritariamente. 
Ahora el equipo trabaja con una fila de actividades formadas con perspectiva de iteración y 
siempre hay una actividad que hacer después de otra, por esto es importante utilizar un 
mecanismo que permita satisfacer esta condición. Esto se distribuye en el backlog tratando 
de reducir los espacios disponibles con las actividades siguientes en base a las 
retrospectivas que se van realizando en las iteraciones. El tiempo invertido en estimar 
planear iteraciones puede ser reemplazado con un control de inspección de calidad al 
mismo tiempo que el trabajo es enviado al segmento de trabajo terminado. 
2.3.2.4Ventajas en SCRlJMBAN 
Algunas de las ventajas obtenidas al utilizar una metodología híbrida como Scrumban, 
como existe hasta el momento son: 
Calidad. 
En tiempo oportuno (JIM), las decisiones y hechos justo cuando son necesitados. 
Bajo tiempo de conducción. 
Mejora continua (revisiones cotidianas). 
Minimizar pérdidas (todo lo que no agrega valor al cliente). 
Procesar mejoras agregando algunos valores a Scrum cuando sean necesitados. 
Una de sus mayores ventajas es la habilidad de ahorrar tiempo, esto al insistir en la 
planeación basado en la técnica del trabajo demandado o requerido, esto significa que los 
equipos planearán las tareas en la etapa inicial y cuando haya una solicitud o demanda de 
trabajo del usuario. Además de esto, la metodología sigue flujos y diagramas de 
interprocesos para demostrar debilidades y oportunidades en los procesos, dando la 
oportunidad al equipo de eliminar todo aquello que no aporte valor al usuario o 
consumidor. Y lo más importante, Scrumban limita el work in progress del equipo para que 
los miembros del mismo puedan terminar lo que tenga mayor prioridad. 
30 
2.3.2.5 Cuándo considerarlo 
Este tipo de metodologías se debe considerar cuando se requieren llevar a cabo acciones, 
sobre todo, para: 
Mantenimiento de proyectos. 
Trabajo de manejo de eventos: 
o Soporte técnico y ayuda. 
o Fases de codificación y empacamiento. 
Proyectos con historias frecuentes o inesperadas o errores de programación. 
Equipos de sprints enfocados en el desarrollo de nuevos productos. 
o Trabajo precedente de desarrollo de sprints. 
o Trabajo posterior al desarrollo de sprint,\·. 
Si scrum es desafiado por problemas en el flujo de trabajo, recursos y procesos. 
Para manejar mejoras en las comunidades durante o antes su entrada o salida del 
scrum. 
Proyectos con historias de usuario frecuentes e inesperadas. 
Sub-equipos de productos con muchas dependencias externas. 
Equipos experimentando retos con las reuniones y nuevas características scrum. 
2.3.2.6KANBAN vs SCRUMBAN 
De la misma forma, es importante resaltar las diferencias principales de la metodología 
kanban anteriormente descrita y esta última en conjunto con scrum (Scrumban), que es la 
que nos servirá como referencia para integrarle los incidentes en cierta etapa del proceso de 
administración de proyectos. 
Para este efecto, la tabla 5 detalla la comparación de los principales factores que 
diferencian a ambas metodologías: 
31 
Roles 
KANBAN SCRUMBAN 
Sin roles pre-establecidos Roles del equipo más necesarios 
Para reducir el trabajo continuo en 
los requerimientos y reducir el 
tiempo de inactividad de los 
Reunión diaria de scrum Sin reuniones miembros del equipo de trabajo 
Puede ser hecha para llenar los 
espacios de tiempos "muertos" 
Puedenserhechassegúnsean 
necesarias para mejorar el 
procedimiento y compartir Reunión de revisión y 
retrospectiva 
Flujo de trabajo 
No prestablecidas 
Continuo 
aprendizajes 
Igual a Kanban. Agrega límite de 
espacio para que el proceso sea 
empujado a ser más cómodo 
TABLA l. COMl'ARACIÓN KANBAN-SCIWMBAN 
DATOS (KNIBERG & SKARIN. 2010). ELABORACl()N PROPIA 
2.3.2.7 SCRUM vs SCRlJMBAN 
Es importante resaltar las diferencias principales de la metodología primeramente descrita 
(scrum) y esta última en conjunto con kanban (Scrumban), que es la que nos servirá como 
referencia para la propuesta de este trabajo donde se le integrarán los incidentes en el 
proceso de administración de proyectos de esta metodología. 
Para este efecto, a continuación en la tabla 2 se mencionan los principales factores que 
diferencian a la metodología scrum y Scrumban en un mayor detalle. 
SCRUM 
Tablero/Artefactos Tableros, pilas de tareas, entregables 
Reuniones 
Iteraciones 
Tiempo 
iteración 
por 
Tamaño del 
equipo 
Estimaciones 
Reunión diaria de scrum, planeación 
de sprint, rev1swn de sprint, 
retrospectiva de sprint 
Sí (.1prints) 
Fijo 
Máximo 10 (aprox) 
Sí 
SCRUMBAN 
Tableros 
Scrum diario (planeación, 
revisión y retrospectiva según sea 
necesaria) 
No (flujo continuo) 
Opcional 
Sin prescripción 
No (tamaño similar) 
32 
Equipos Debe ser bi-funcional Debe ser especializado 
Dueño del producto, Especialista 
Roles Scrum, Equipo Equipo y roles necesarios 
Colaborativo de acuerdo a lo necesario 
Equipo de trabajo por las tareas 
Trabajo en 
proceso Controlado por contenido del sprint 
Cambios 
Pila de tareas 
Impedimentos 
Debe esperar al siguiente sprint 
Lista de historias priorizadas 
estimadas 
Tratado inmediatamente 
y 
Creado para lograr tareas 
Controlado por estado del flujo 
del trabajo 
Agregado como se necesite en el 
tablero (por hacer) 
Tareas ''just in time" 
Evitado 
TABLA 2. COMPARACIÓN SCIHIM-SCRUMBAN 
DATOS (KNIBERG & SKARIN, 2010), léLAl30RACIC)N PROPIA 
Después de conocer las características de todas estas metodologías y las diferencias entre 
ellas, podemos comenzar a trabajar en la integración de nuevos factores a las mismas. 
2.4 Encuestas sobre Fallas en Proyectos de 
TI 
Para conocer acerca de las consecuencias una mala planeación y administración de 
proyectos de sistemas, una de las mejores opciones es consultar las estadísticas existentes 
sobre las fallas que se han presentado en la entrega y tiempos comprometidos en proyectos 
de tecnologías de información a nivel global así como los factores que han llevado a estas 
fallas. 
2.4.1 Encuestas en México 
Es importante también limitar estos resultados al nivel de nuestro país para saber de qué 
forma se está aplicando la administración de proyectos en nuestro entorno y de qué forma 
se puede perfeccionar. 
33 
2.4.1.1 Formato de la Enc-uesta 
En México, el trabajo de Espinosa (2013) se enfoca en mostrar el resultado de una encuesta 
realizada para conocer el comportamiento de los proyectos desarrollados en México 
durante 2012 en áreas de TI. Esta encuesta conjuga diversos conceptos de encuestas 
realizadas en diferentes países del mundo y áreas de conocimiento para poder utilizarse 
como parámetro de referencia. 
Esta encuesta divide los proyectos de TI en tres grandes grupos para su análisis: 
• Proyectos exitosos: aquellos que cumplieron con los objetivos deseados dentro del 
presupuesto y finalizaron en el tiempo planeado. 
• Proyectos parcialmente exitosos: finalizaron fuera del tiempo estimado, su alcance 
fue menor a lo planeado inicialmente o el presupuesto fue mayor al planeado. 
• Proyectos no exitosos: proyectos que fueron cancelados en algún momento del 
desarrollo o abandonados al poco tiempo de su implementación. 
2.4.1.2 Detalle y Aplicación de la Encuesta 
De acuerdo a la segmentación de los proyectos en estas categorías, se les aplicaron 5 
preguntas a los participantes donde se busca identificar el fracaso de los proyectos de 
acuerdo a siete factores principales específicos y una posibilidad de especificar en caso de 
ser otro que no se encuentre en esta lista: 
1. Especificaciones y requerimientos inestables o incompletos. 
2. Falta de involucramiento de los usuarios. 
3. Mínimo conocimiento técnico por parte del equipo de trabajo. 
4. Uso inadecuado de las herramientas y métodos. 
5. Expectativas poco realistas. 
6. Falta de soporte gerencial 
7. Débil administración de proyectos (no identificación de riesgos, falta de 
planificación y comunicación deficiente) 
34 
Esta encuesta fue distribuida de forma electrónica a los participantes para motivar y 
facilitar a su participación. 
Las preguntas se formularon de forma cualitativa para poder valorar los resultados y 
conocer el número de proyectos exitosos y no exitosos en las organizaciones participantes. 
Estas preguntas fueron generales de forma que pudieran ser contestadas fácilmente por 
cualquier líder de proyecto. 
A continuación algunos ejemplos de las preguntas en cuestión dentro de la encuesta: 
¿En cuántos proyectos estuvo involucrado durante el año?: esto para definir unplazo medible de tiempo y proyectos dentro de él. 
¿Cuántos proyectos terminaron en tiempo, presupuesto y alcanzaron los objetivos 
deseados?: es decir, cuántos proyectos fueron exitosos para el usuario dentro de la 
organización objetivo y acorde al plan. 
¿Cuántos proyectos finalizaron con tiempo extra, presupuesto extra o el alcance fue 
menor al planeado?: en otras palabras, se concluyeron pero no fueron 
completamente exitosos porque no se cumplieron en el tiempo y forma planeados al 
principio de la planeación por algún motivo surgido dentro del mismo. 
¿Cuántos proyectos fueron cancelados en algún punto de su desarrollo o 
abandonados al poco tiempo de su implementación?: es el número de proyectos que 
NO lograron concretarse por el motivo que haya sido, es decir, su planeación fue 
errónea y no permitió concluir su objetivo. Para estos objetivos, es necesario indicar 
cuál fue la causa de su fracaso, de acuerdo a las 7 causas indicadas arriba, ya que 
eso permitirá investigar más a fondo la raíz de los problemas en la administración o 
planeación de los proyectos. 
2.4.1.3 Resultados 
Derivado del estudio llevado a cabo por Espinosa durante Enero y Febrero de 2013, los 
resultados según se aprecia en la figura 5, arrojan que en México durante 2012 en las 
empresas de TI más del 50% de los proyectos fueron concluidos exitosamente. 
35 
~ f· .. <1•.c 1,-.1.f·,lUJlT 0:11,Y><Y, 
1 Jr., E\ llll '>1 1 ') 
FIGllRA 5. PORCE!'ITAJE DE ÉXITO/FRACASO DE PROYECTOS EN MÉXICO 
FUENTE (l:Sl'INOSA, 2013) 
Sin embargo, el resultado más notable de este estudio no es el número de proyectos 
exitosos sino el de los proyectos no exitosos. De acuerdo a otros estudios realizados, como 
la encuesta Khaled El Emam y A. Günes y la encuesta de STRA TMOR alrededor de más 
del 11 % de los proyectos son NO exitosos. Y es importante resaltar que este par de 
encuestas son de las más optimistas respecto al porcentaje de proyectos no exitosos ya que 
el resto de las encuestas realizadas muestran números aún mayores. Aun así, el número 
obtenido de la encuesta de Espinosa, realizada en México, es menor al obtenido en estas 
dos encuestas en cuestión que fueron llevadas a cabo en otros países. 
Por último, es importante notar los motivos por los cuáles principalmente los 
administradores de los proyectos indicaron que estos fallaron o se cancelaron. En primer 
lugar, por especificaciones y requerimientos inestables o incompletos; seguido por la falta 
de involucramiento de los usuarios, en tercer lugar por expectativas pocos realistas. En 
cuarto lugar se ubicó una débil administración de los proyectos, el siguiente motivo fue una 
36 
falta de soporte gerencial. En penúltimo lugar se ubicó un uso inadecuado de métodos y 
herramientas y por último el poco conocimiento técnico del equipo del proyecto. 
Es muy importante notar que el primer factor por el que los proyectos han sido no exitosos 
es la definición o especificación de requerimientos inestables o incompletos, que es parte 
del problema que un sistema presente INCIDENTES o FALLAS dentro de un ambiente 
productivo al tratarse de un sistema que ya se encuentra funcionando y se requiere un 
proyecto para hacerle una modificación o nuevo requerimiento. Por tal motivo, el estudio 
de Espinosa (2013) fortalece aún más esta investigación que trata de explicar que el retraso 
y muchas veces fracaso de los proyectos se debe a la planeación del alcance de los mismos 
sin inclusión de fallas inesperadas que pueden retrasar las actividades planeadas y que 
absorben recursos de todo tipo (humanos, de tiempo, materiales, etc.) que pueden retrasar la 
conclusión del plan de trabajo definido con anterioridad en el inicio del proyecto. 
2.4.2 Encuestas Fallas er1 Proyectos de TI en 
Otros Países 
Como se comentó anteriormente, es relevante conocer los resultados de la aplicación de las 
metodologías en otros países y obtener las buenas prácticas que podemos aprender o no de 
ellos. 
2.4.2.1 Generalidades de la Encuesta 
En encuestas recientes de Gartner (Handler, 2011 y Mieritz, 2012) es importante destacar 
que el estudio se llevó a cabo en Octubre 2011 para examinar el desempeño de los 
proyectos de TI en Norteamérica (EU y Canadá), Francia, Alemania y Reino Unido. 
37 
2.4.2.2 Factores de fracaso y éxito en los 
proyectos 
En el estudio antes mencionado se muestran porcentajes altos del número de proyectos que 
no se cumplen en tiempo y forma de acuerdo a lo planeado en un principio. La tasa de 
incumplimiento en los proyectos grandes TI con presupuesto que excede el millón de 
dólares se encontró que es 50% más alto a los proyectos con presupuesto menos a 
U$350,000. 
De acuerdo a este mismo análisis, las recomendaciones para evitar el fracaso de los 
proyectos de TI son: 
Para optimizar el éxito, se debe limitar el tamaño, complejidad y duración de 
proyectos de forma individual asegurando que el objetivo principal sea logrado. 
Permanecer en el límite de costos, especialmente para proyectos grandes 
asegurando que existan los mecanismos apropiados para identificar los factores que 
afectan el presupuesto y anticiparse a estos. Revisar regulannente cómo se hizo la 
estimación de costos permite comprender qué tan adecuadas y efectivas son las 
aproximaciones e integrar oportunidades de mejora. 
Mantener un calendario de trabajo realista, muchos proyectos fracasan porque las 
condiciones del negocio son cambiantes y esto no se contempla después de 
establecer el alcance del proyecto porque lo que se desligan completamente estos 
factores y lo que el negocio en un futuro requiere, lo cual implica un pago por el 
tiempo que tardará más el proyecto en ser entregado. 
Se deben invertir tiempo y recursos en entender totalmente las expectativas del 
negocio y la funcionalidad que se requiere del proyecto, asegurándose que la 
asignación inicial de actividades y recursos sea suficiente para cumplir las 
expectativas y requiera revisión en múltiples puntos durante el proyecto. 
Incrementar la frecuencia de las reuniones de revisión sobre el estado del proyecto 
así como alinear el proyecto con la estrategia de negocios, identificando y 
38 
cancelando lo más pronto posible los proyectos que no buscan cumplir las 
necesidades de la compañía. 
Los resultados de la encuesta muestran que sm importar el tamaño del proyecto, en 
promedio el porcentaje de fracaso de los proyectos de TI es entre 20 y 28%, como lo 
muestra la figura 6. 
Proyectos pequeños de IT (<$350M) 
Proyectos medianos de IT ($350K, a $1M) 
Proyectos grandes de IT (presupuesto> $1M) 
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 
i8l %Exitosos \2 %No Exitosos 
FIGllRA 6. PORCENTA.IE DE f:XITO/FRACASO DE PROYECTOS 
DATOS (MIERITZ. 2012) ELABORACIÓN PROPIA 
En conclusión, respecto a los resultados de la gráfica anterior se observa que al mantener 
los proyectos en un tamaño pequeño, sin exceder los 6 meses de duración, el porcentaje de 
éxito del proyecto se incrementaría altamente. Es más prudente ver los proyectos largos y 
caros, como una serie de pequeños proyectos donde cada uno de ellos provee un entregable 
parte del proyecto principal. 
En este mismo estudio, se establecieron posibilidades de falla para los proyectos y los 
resultados que se obtuvieron de los participantes fueron de la siguiente manera: 
39 
Porcentaje de respuestas 
100% 1 
90% 
80% 
70% 
60% 
50% 
40% 
30% 
20% 
10% 
0% 
Proyectos grandes de Proyectos medianos Proyectos pequeños 
de 1T IT de 1T 
ill Otras razones 
Can celados después del inicio 
ti. Sustancialmente demorado 
m Pobre calidad 
111 Alta varianza en costo 
Fallas funcional es 
FIGURA 7. RAZONES DE FRACASO DE LOS PROYECTOS 
DATOS (GARTNER, 2012) ELABORACIÓN PERSONAL 
Con estos resultados se comprueba que las razones más frecuentes de fracaso de un 
proyecto es la realización en tiempo, presupuesto y con la funcionalidad mencionada, al 
representar dos terciosde los resultados de la encuesta. El detalle de estas razones se puede 
apreciar en la figura número 7. 
2.4.2.3 Recomendaciones 
Exitosos 
para Proyectos 
Según los estudios realizados por Gartner respecto al fracaso o éxito de los proyectos de TL 
las dos razones más grandes para el fracaso en el desarrollo de proyectos son la 
funcionalidad e incumplimiento de tiempos, los cuales simbolizan el 63% de fracaso en los 
proyectos menos exitosos. 
El estudio se resume principalmente en las siguientes recomendaciones: 
Mejorar la habilidad de capturar los requerimientos del proyecto e integrarlos en la 
estimación de tiempos y esfuerzos requeridos. 
40 
Facilitar el vínculo con el plan de negocios a través de una comunicación abierta, 
procesos estandarizados y una administración expectante, poniendo especial 
atención para el cambio de requerimientos y su implicación en las estimaciones. 
Entender completamente la capacidad del equipo de proyecto para prevenir una 
subestimación en los recursos. 
41 
CAPÍTULO 3 
Propuesta 
3 .1 Definición original de la metodología a 
modificar 
Previo a la presentación de nuestra propuesta en este trabajo, recapitularemos de qué forma 
está definida inicialmente la metodología que se propone modificar para entrar en contexto 
de los cambios propuestos. 
3.1.1 ¿Qué es SCRUMBAN? 
De acuerdo al escrito de Swisher10 (2014), Scrumban conjuga los conceptos clave de un 
equipo que trabajan juntos para completar un trabajo (Scrum) y la carga de trabajo 
necesaria limitada para obtener una carga óptima (Kanban) combinados en una 
metodología para alto alcance y visibilidad en el proceso de desarrollo. 
Según el trabajo de Bicheler, Gómez Andrade y Palacin Rubio 11 (2012), el escenario de la 
metodología Scrumban conjunta los elementos comunes de estas dos metodologías como: 
tablero y tareas, además de tomar los elementos únicos de Kanban como el límite de trabajo 
en proceso y prioridades y los elementos de Scrum, el backlog, los .<,prints y las revisiones 
diarias y mensuales. 
10/mplemenfing ScrumBan, a short guide to implementing scrumban to your organiza/ion. 
www.SwitchingToScrum.com. 
11 Scrum-Ban. http://Vvww.pmi.lu/event/l 20201-ScrumBan.pdf 
42 
Junta diaria de Scrum 
Tareas del backlqg 
por equipo 
Sprint Backlog 
__ ""'"v) 
Entrega potencial 
Incremento del producto Product Backlog 
Priorizado por Product Owner 
Por hacer En proceso Completado 
D D 
FIGllRA 8. FUSIÓN DE SCRllM Y KANBAN 
DATOS (lllClll:U:R, GOMl:Z ANDRADE, Pi\LACIN RUBIO, 2012) ELABORACIÓN PERSONAL 
Como todas las metodologías, el equipo de trabajo tiene que revisar cotidianamente ésta 
para adaptar el proceso y hacer ajustes para mejorar la experiencia de las estrategias que 
mejor funcionen en el desarrollo del trabajo. 
En la tabla 3 se aprecian los conceptos de cada una de las metodologías que se toman para 
crear Scrumban, no se encuentran listadas por importancia ni relevancia dentro de la 
metodología, únicamente se listan cuáles son los factores que contempla Scrumban y su 
origen inicial. 
SCRUM 
* Product owner (Dueño del producto)-Liga entre el 
área de negocios y la de ingeniería dentro de las 
organizaciones; es dueño del Product Backlog, que 
contiene las actividades a realizar y valida el trabajo 
completado. 
KANBAN 
* Pulling Work (Trabajo apilado)-EI trabajo es 
apilado o distribuido en la línea de trabajo en tanto 
la capacidad del equipo esté disponible de acuerdo 
al trabajo previamente seleccionado para ser 
completado en un periodo de tiempo arbitrario. 
43 
* Scrum Master-Supervisor del proceso; evita 
impedimentos y coordina con los recursos externos 
para facilitar la compleción de unidades de trabajo. 
* Developers (Desarrolladores)-Codificadores, testers, 
ingenieros de base de datos, etc. Cualquier miembro en 
el equipo que contribuye en completar las unidades de 
trabajo. 
* Daily Standup (Reunión diaria)-Pequeña reunión con 
el equipo completo para discutir el progreso, identificar 
obstáculos y dirigir las preguntas sobre el trabajo en 
proceso (WIP). 
* Demonstrations (Demostraciones)-Los 
desarrolladores muestran el avance de trabajo 
obtenido al product owner para validación y 
aceptación. 
* Delivery of Business Value (Entrega de valor de 
* Work in progress (WIP) Limits (Límites de trabajo 
en proceso)-Límites que son diseñados para 
mantener un balance de lo que el equipo está 
trabajando en cierto tiempo dado. Se ajusta en base 
a las evidencias para encontrar los niveles óptimos 
de cada etapa en las unidades de trabajo. 
*Process Stages (Etapas del proceso)- Etapas para 
completar el trabajo donde el trabajo está 
claramente definido y las métricas de desempeño 
para cada una. 
" Kanban Board (tablero Kanban)-Un tablero visible 
públicamente que muestra las etapas de las líneas 
del trabajo y las unidades de trabajo en progreso. 
'' Expedited Channel (Canal Urgente)-Las unidades 
de trabajo con alta prioridad y que se necesitan lo 
más pronto posible se asignan en un camino 
especial sobre el trabajo actual. 
"Analysis and Adjustment (Análisis y ajustes)-
Revisiones periódicas del proceso, herramientas, 
desempeño del equipo y límites de WIP para 
negocio)-Se enfoca en entregar un valor de negocio con encontrar mejoras y eliminar ineficiencias y 
cada unidad de trabajo completada. desperdicios. 
* Definition of Done-Estándar global que todos las 
unidades de trabajo deben cumplir para considerarse 
completadas. 
TABLA 3. CONCIWl'OS SCRUM-KANBAN 
DATOS (WILLIAM l'ATRICK SWISI-ILR). LLAllORACIÓN PROPIA 
Los cuatro conceptos clave alrededor de los cuales giran el resto de los factores de la 
metodología Scrumban se tratan de: 
Work Backlog: Es equivalente al Product Backlog de scrum con menores 
diferencias de cómo son rastreados y monitoreados los Workitems (unidades de 
trabajo). 
Workitem: Descripciones individuales de funcionalidades necesarias por el negocio 
que también definen las mejoras y defectos. 
Workline: Series de etapas en el proceso de desarrollo de software que va formando 
el trabajo del Work Backlog y produce valor de negocio entregable. 
Stages: Pasos comunes y discretos que se necesitan para entregar software dentro de 
la organización. 
Las etapas de ejecución es un concepto original de kanban y es una gran diferenciación de 
scrum, el proceso de desarrollo de software es dividido en pequeñas etapas claras y visibles 
44 
para todo el equipo, éstas son conocidas como workline y en el mundo real se representa 
por el tablero que muestra el progreso de las unidades de trabajo (workitems) con tarjetas 
físicas que son circuladas entre los miembros del equipo de trabajo. 
La asignación y empuje de trabajo basado en la capacidad y límites es otro concepto 
proveniente de kanban. Cada etapa del workline tiene un límite con base al número de 
workilems que abarca cada etapa del proceso. Esto mantiene a los miembros del equipo de 
trabajo libres de trabajar en demasiadas cosas al mismo tiempo y además elimina los 
desperdicios al asegurarse de que una etapa no produzca más trabajo del que puede ser 
manejado en la siguiente etapa. Conforme van cumpliéndose los workitems en cada etapa, 
tienen que esperar a que la siguiente etapa tenga capacidad para absorber más unidades para 
ser procesadas. 
La figura 9 nos muestra una definición visual de cómo se compone el tablero del escenario 
Scrumban, las etapas en las que las actividades van avanzando dentro del proceso de 
desarrollo del proyecto y su flujo a través de ellas. 
~ 
14 
-14 ; 
-· 14 
-14 
Preparl:!sJ~[ill 
-14 
FIGURA 9. TABU:RO SCRlJMBAN 
DATOS (BICIIELER, GOMEZ ANDRADI·:. l'ALACIN RUBIO, 2012) ELABORACIÓN Pl:RSONAL 
45 
Con Scrumban, aunque cada una de las etapas del proceso de desarrollo son claramente 
identificadas dentro del tablero de trabajo y el trabajo es monitoreado a través de esta 
definición, todos los miembros del equipo de trabajo se espera que trabajen