Agilidad en Proyectos de Telecomunicaciones

UNIVERSIDAD MAYOR DE SAN SIMON
FACULTAD DE CIENCIAS Y TECNOLOGÍA

DIRECCIÓN DE POSGRADO
“AGILIDAD EN PROYECTOS DE
TELECOMUNICACIONES”
TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE

DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES EMPRESARIALES
VERSIÓN II
POSTULANTE : Julio Rafael Daviú Arévalo

TUTOR : Ing. Nibeth Mena Mamani
Cochabamba – Bolivia
2019
1
Tabla de Contenido
Resumen………………………………………………………………………………………….. 5
Introducción……………………………………………………………………………………… 6
1 Generalidades………………………………………………………………………………..8
1.1 Antecedentes Generales………………………………………………………………………. 8
1.2 Antecedentes Específicos……………………………………………………………………..10
2 Metodología………………………………………………………………………………... 11
3 Conceptos importantes sobre metodologías ágiles………………………………………...13
3.1 Manifiesto ágil…………………………………………………………………………….. 14
3.2 Diferencias entre metodologías agiles y metodologías tradicionales…………………..16
3.3 Dominio en proyectos de Telecomunicaciones………………………………………… 18
3.4 Ventajas al usar metodologías de desarrollo ágiles……………………………………. 19
3.5 Desventajas al usar metodologías de desarrollo ágiles………………………………... 20
4 Metodología Scrum………………………………………………………………………... 21
4.1 Análisis de Contexto –Cynefin…………………………………………………………. 24
4.2 Principios de Scrum…………………………………………………………………….. 27
4.3 Valores de Scrum………………………………………………………………………... 28
4.4 Roles de Scrum……………………………………………………………………………29
2
4.5 Elementos de Scrum………………………………………………………………………35
4.6 El fracaso del modelo Cascada……………………………………………………………43
5 Conclusiones y Recomendaciones…………………………………………………………45
6 Bibliografía………………………………………………………………………………... 46
3
TABLA DE CUADROS, GRAFICOS Y FIGURAS
Descripción Pág.
Figura 1 – Diagrama de Operaciones Empresas Telecom 7
Figura 2 – Flujo Agile 13
Figura 3 – Manifiesto Ágil 16
Figura 4 – Diferencias Metodologías tradicionales vs Metodologías ágiles 22
Figura 5– Marco Scrum 23
Figura 6– Ilustración Scrum 24
Figura 7– Marco Cynefin 20
Figura 8– Equipo Scrum 29
Figura 9– Product Owner 31
Figura 10– Equipo de Desarrollo 32
Figura 11– Scrum Master 34
Figura 12– Product Backlog 35
Figura 13– Triangulo de Hierro 37
Figura 14– Sprint Backlog 38
Figura 15– Sprint Planning parte uno 40
Figura 16– Sprint Planning parte dos 40
Figura 17– Scrum diario 41
Figura 18– Sprint Review 42
4
Resumen
En la presente monografía se explicarán las ventajas, desventajas de aplicar metodologías de
desarrollo ágil en proyectos de telecomunicaciones.
Se analizarán metodologías antiguas y el impacto que tienen en el desarrollo del software.
Se explicará como una metodología de desarrollo ágil puede ayudar al mejoramiento del desarrollo
de software en una empresa de telecomunicaciones teniendo en cuenta que las empresas de
telecomunicaciones si bien prestan servicios al usuario final también manejan productos entre ellos
sistemas de uso interno, considerando que las telecomunicaciones están directamente ligadas a los
sistemas, ya que estas son consideradas dentro del concepto informático como la transmisión de
datos de información por medios electrónicos, para dicho propósito se llegan a usar diversos tipos
de sistemas.
Para el desarrollo de estos sistemas las empresas de telecomunicaciones en un inicio adoptaron el
modelo de desarrollo de software tradicional en Cascada con las fases que son:
• Análisis de requerimientos
• Diseño
• Implementación
• Verificación
• Mantenimiento
Adicionalmente se tratará de demostrar en la presente monografía como impacta negativamente
en la percepción de los clientes finales o clientes internos el uso de metodologías tradicionales.
5
Introducción
Las telecomunicaciones en Bolivia se remontan al año 1965 donde se llega a crear Entel según
decreto supremo Nro. 07441 donde expresaba la creación de la “Empresa Nacional de
Telecomunicaciones” como sociedad económica mixta y de derecho público.
La nueva empresa de telecomunicaciones inicia a partir de 1992 la expansión de las
telecomunicaciones del eje urbano al rural.
A su par comenzó a funcionar la empresa de Telecomunicaciones “Telecel S.A” en el año1993 a
realizar similares trabajos el año 2005 Telecel S.A realiza un cambio de Marca llegando a ser
conocida como Tigo.
Recién el año 1999 es fundada Nuevatel Pcs de Bolivia para dar inicio a su marca comercial
Viva llegando a ser el tercer operador que brinda servicio junto a usuarios de Bolivia.
Las tres empresas de telecomunicaciones cuentan con sus respectivas organizaciones internas,
pero coinciden en el hecho de manejar servicios y productos para usuarios finales y usuarios
internos.
La mayoría de las empresas de telecomunicaciones presenta la siguiente estructura de áreas
internas en cuanto a las operaciones que realizan.
6
Figura 1 – Diagrama de Operaciones Empresas Telecom
Fuente: https://www.tmforum.org/resources/suite/gb921-business-process-framework-etom-
suite-release-18-5/
Cada área ya es responsable de sus procesos internos propios para así poder proporcionar servicios
y a su vez generar productos con los clientes internos y con los clientes finales.
Para este fin hacen uso de metodologías de desarrollo de software para poder crear sistemas de uso
interno, durante el proceso de desarrollo del software acogen lineamientos que plantean las
metodologías tradicionales lo cual ha acarreado ciertos tipos de problemas debido a la complejidad
de los proyectos han llegado a ser identificados plenamente.
7
1 Generalidades
1.1 Antecedentes Generales
¿Qué son las metodologías de desarrollo de software?
Dentro de los conceptos de software las metodologías de desarrollo de software llegan a ser marcos
de trabajo para estructurar, planificar, controlar el proceso de desarrollo en sistema de información.
A lo largo del tiempo una gran cantidad de metodologías han sido desarrolladas llegando a ser
diferenciadas por sus fortalezas y debilidades.
El desarrollo de sistemas tradicionales se remonta a la década de los años 1960 donde se tenía
grandes conglomerados comerciales-empresariales.
¿Qué es el enfoque del desarrollo del software?
Cada metodología de desarrollo de software tiene un determinado enfoque llegando a ser
catalogados como enfoques tradicionales o enfoques ágiles.
En este sentido vamos a considerar las ventajas de aplicar enfoques tradicionales (Cascada) a
proyectos de software o aplicar enfoques ágiles a proyectos de software para llegar a determinar
las ventajas y desventajas que tienen cada uno de ellos.
Una breve historia de la metodología de desarrollo en Cascada
Se trata de un proceso secuencial en los que los pasos de desarrollo son vistos hacia abajo (es de
ahí donde viene su nombre como si fuera una cascada).
Los pasos mencionados son análisis de requerimientos, diseño, implementación, pruebas,
mantenimiento.
La primera descripción formal fue publicada en el año 1970 por Winston Royce aún que el autor
no lo nombra como cascada dentro de este artículo.
8
El proyecto está dividido en fases secuenciales con ciertas superposiciones y splashback entre
fases.
Se hace hincapié en la planificación, horarios, fechas presupuestos de todo en un solo sistema a la
vez.
Se mantiene un estricto control durante la vida del proyecto a través de una amplia documentación
escrita.
Una vez terminado todo el sistema o producto se entrega la documentación al cliente y no se tiene
mucho contacto con el mismo.
Una breve reseña de las metodologías de desarrollo ágiles
Las metodologías ágiles envuelven un enfoque para la toma de decisiones en los proyectos de
software que se refieren a métodos de desarrollo de software basados en iteraciones incremental
donde los requisitos y soluciones evolucionan según la necesidad del proyecto.
Cada iteración del ciclo de vida incluye planificación, análisis de requisitos, diseño codificación,
pruebas y documentación. Se tiene muy en cuenta de que toda la funcionalidad no es entregada en
un todo si no incrementar el valor de software funcional sin errores.
A diferencia de las metodologías tradicionales, en las metodologías ágiles se enfatiza en la
comunicación cara a cara en vez de la documentación al realizar esto los clientes se sienten
comprometidos con el producto y son parte del equipo como un segundo equipo de control de
calidad.
La definición de desarrollo de software evoluciona a mediados de la década de 1990 como
principal reacción contra métodos tradicionales los cuales si bien eran estructurados no se
adaptaban al cambio de las necesidades del proyecto lo cual generaba insatisfacción en los usuarios
9
finales los cuales principalmente notaban que las metodologías tradicionales eran lentas,
sumamente burocráticas y poco abierta a los cambios.
En el año 2001 se reúnen miembros prominentes de la comunidad de desarrollo de software donde
dan origen al manifiesto ágil el cual tiene sus propias directivas, posteriormente forman la “Alianza
Ágil” la cual es una organización sin fines de lucro.
1.2 Antecedentes Específicos
En la época del desarrollo de software donde se hacía hincapié en la metodología tradicional, los
desarrolladores de software realizaban el proceso de creación de código y este era enviado a su
respectivo equipo de control de calidad el código como lo indicábamos viajaba hacia adelante
simulando una Cascada para que posteriormente fluya hacia atrás entre control de calidad y los
desarrolladores de software.
El equipo de control de calidad se encargaba de detectar problemas y estos eran reportados al
equipo de desarrolladores los cuales se encargaban de validar los errores reportados y corregirlos,
este ciclo podía tener mucho intercambio para que finalmente el producto esté listo para salir en
ambientes productivos.
Esto era realizado en todo el sistema y el cliente no tenía idea del avance que se llegase a tener,
porque las metodologías ágiles hacen hincapié en la entrega de un todo bien documentado con
sumo apego a la especificación de requerimientos iniciales.
Este mismo escenario se ve con frecuencia en empresas de telecomunicaciones que muy aparte de
proveer el servicio a los usuarios finales tienen de manera interna sistemas que hacen uso propio
sus mismos empleados, si bien puede existir sistemas provistos por un proveedor externo a la
10
empresa las más de las empresas de telecomunicaciones optan por el desarrollo de software
denominado como “Software made in House” esto por factores de cambios prontos y costos.
Al realizar “Software made in House” las empresas de telecomunicaciones hacen como propias
las metodologías de desarrollo de software llegando a optar generalmente por las tradicionales
como ser Cascada.
¿Por qué aplicar metodologías ágiles?
Porque necesitamos tener equipos más felices, necesitamos dar valor al software funcional, el
cliente es cociente del avance que se tiene por los entregables que recibe,
Por qué es necesario un cambio de paradigma, una adaptación a tiempos modernos y por sobretodo
tener la mentalidad abierta el cambio y no se cerrados como las metodologías tradicionales.
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 información
relacionados al tema de estudio.
1
La investigación bibliográfica es la primera etapa del proceso investigativo que
proporciona el conocimiento de las investigaciones ya existentes, de un modo sistemático,
a través de una amplia búsqueda de: información, conocimientos y técnicas sobre una
cuestión determinada.
1
RIVAS GALARRETA, E. (1994). La investigación bibliográfica y los textos académicos.
11
Dentro de la búsqueda de la verdad en la investigación científica, se acude a la realidad y
de ésta se obtienen: un problema, una hipótesis con su respectiva contrastación y
conclusiones.
El proceso de investigación estará completo cuando se cumpla el objetivo de la
investigación científica: un documento científico al cual los siguientes usuarios buscarán
como referencia, de tal manera que observarán hechos, platearán problemas; funcionando
así, como un nuevo punto de partida, realizado con la mayor objetividad posible, para
futuras investigaciones.
✓ Método Analítico, debido a que se procederá a revisar y analizar ordenadamente
documentos relacionados al tema de estudio y la experiencia de las clases del módulo de
gestión de procesos de desarrollo de Software y experiencias propias.
2
Es aquel método de investigación que consiste en la desmembración de un todo,
descomponiéndolo en sus partes o elementos para observar las causas, la naturaleza y los
efectos. El análisis es la observación y examen de un hecho en particular. Es necesario
conocer la naturaleza del fenómeno y objeto que se estudia para comprender su esencia.
Este método nos permite conocer más del objeto de estudio, con lo cual se puede: explicar,
hacer analogías, comprender mejor su comportamiento y establecer nuevas teorías.
2
http://gmorzingc.blogspot.com/2011/10/metodo-analitico-de-la-investigacion.html
12
3 Conceptos importantes sobre metodologías ágiles
Figura 2 – Flujo Agile

Fuente: https://comunidad.iebschool.com/metodologiasagiles/general/concepto-
metodologias-agiles/
Para poder tener mejor comprensión acerca de las metodologías ágiles se mantendrán los
términos de referencia en inglés esto para estar a la par de la terminología según
convenciones ágiles.
Tras la reunión que se mencionó anteriormente en el año 2001 surge el pilar fundamental
de las metodologías ágiles, se trata del Manifiesto ágil.
13
3.1 Manifiesto ágil
El manifiesto ágil es considerado como la piedra fundamental de las metodologías ágiles
está compuesto por cuatro principios y doce valores, esto según la Agile Alliance.
Figura 3 – Manifiesto Ágil

Fuente: Libro Proyectos Ágiles con #Scrum (Martín Alaimo – Martín Salías)
Valores
1. Individuos e interacciones sobre procesos y herramientas
2. Software funcionando sobre documentación extensiva
3. Colaboración con el cliente sobre negociación contractual
4. Respuesta ante el cambio sobre seguir un plan
14
Principios
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y
continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos 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.
6. El método más eficiente y efectivo 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 deben ser capaces de mantener un ritmo constante de
forma indefinida.
9. La atención continua a la excelencia técnica y al 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.
15
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.
3.2 Diferencias entre metodologías agiles y metodologías tradicionales
Figura 4 – Diferencias Metodologías tradicionales vs Metodologías ágiles

Fuente: https://comunidad.iebschool.com/metodologiasagiles/general/concepto-
Para poder citar las diferencias entre las metodologías tradicionales con las metodologías
ágiles se debe entender la complejidad de los proyectos donde pueden ser aplicadas, para esto
se usará Cynefin que nos ayudará en entender el entorno al cual pertenece según la
complejidad de su entorno.
16
Diferencias según la certidumbre del proyecto
Tradicional Ágil
✓ Se define todo desde el principio ✓ Refactorización
✓ Predictivos ✓ Adaptables
✓ Plan detallado ✓ Se trabaja sobre funcionalidades
✓ Contratos estrictos ✓ Contratos de alcance variable
✓ Propiedad individual ✓ Propiedad colectiva
Diferencias en cuanto a la gestión del cambio del proyecto
Tradicional Ágil
✓ Se resiste al cambio ✓ El cambio forma parte del proyecto
✓ Poca retroalimentación ante los ✓ Aprendizaje continuo
problemas ✓ Desarrollo con base a las necesidades
✓ Posible desfase entre lo solicitado y lo ✓ Se agrega valor con cada entregable
entregado ✓ Poco énfasis en la arquitectura
✓ Burocracia excesiva ✓ Equilibrio entre la “excesiva
burocracia” contra la “anarquía
caótica”
17
Diferencias en cuanto a la gestión de los equipos del proyecto
Tradicional Ágil
✓ Cliente delega la responsabilidad ✓ Individuos e Interacciones
✓ Castigo y penalización ✓ Colaboración, beneficio común
✓ Beneficio individual ✓ Flujo de valor continuo
✓ Baja motivación del equipo ✓ Equipos motivados y comprometidos
✓ Especialidad ✓ Multifuncionalidad
✓ Responsabilidad asignada ✓ Responsabilidad por compromiso
3.3 Dominio en proyectos de Telecomunicaciones
En el mundo de las telecomunicaciones por experiencia propia se tienen dominios de tipo
complicado con cierta tendencia a dominios de tipo complejo.
En este sentido la aplicación de metodologías tradicionales esta trayendo problemas de
manera interna, debido a la insatisfacción que generan a los clientes internos los cuales no
se sienten parte del proyecto cuando debería ser todo lo contrario ya que son el punto de
retroalimentación inicial para saber que se esta haciendo bien o mal.
Las metodologías tradicionales se oponen a los cambios esto puede ser considerado como
un absurdo ya que se llegaría a pensar que un proyecto en lo largo del tiempo no podrá sufrir
cambios de objetivos, estos cambios no son aceptados en las metodologías tradicionales lo
cual genera una perdida de confianza en los equipos de desarrollo.
18
3.4 Ventajas al usar metodologías de desarrollo ágiles
Las metodologías de desarrollo ágiles presentan las siguientes características las cuales
llegan a ser consideradas como ventajas con las siguientes:
Rápida respuesta a los cambios
Al ser procesos evolutivos, los equipos de trabajo pueden implementar soluciones sobre la
marcha. Ya no es necesario esperar hasta el final para corregir fallos a diferencia de las
metodologías ágiles donde las fallas son encontradas al final cuando se entrega el producto.
Las metodologías ágiles están siempre abiertas al cambio.
Intervención del cliente en el proceso
El cliente interviene de una forma activa en cada una de las etapas del proceso. Puede aportar
ideas y opinar sobre los resultados que se le van entregando progresivamente.
Como se ha mencionado anteriormente el cliente es parte fundamental en las metodologías
ágiles, esto debido a la retroalimentación que se tiene por parte del cliente es parte del equipo.
Entregas del producto en intervalos
Las entregas parciales o en bloques mejoran la optimización de recursos y optimizan las
labores de seguimiento y control. El producto final es, en realidad, la suma de varios
productos parciales que han sido monitorizados varias veces.
Esta entrega periódica genera una gran satisfacción en el cliente el cual tiene la certeza de
que su entregable cumple con la especificación de requerimientos respecto ala funcionalidad
solicitada.
19
Eliminación de tareas innecesarias
Al priorizar las tareas de un proceso, los responsables del mismo saben con certeza cuáles
tienen un mayor peso y cuáles resultan secundarias o, incluso, innecesarias. Esta distinción
ayuda a centralizar esfuerzos y a unificar criterios de actuación.
Transparencia y coordinación en el equipo
Al tener reuniones periódicas se realiza un seguimiento adecuado, en estas reuniones se llega
a tener transparencia sobre el alcance del producto en su conjunto donde se llega a estimar
y coordinar de manera adecuada las tareas respectivas, se llega a ser abierto con el equipo
respecto al producto en su conjunto no existe información confidencial.
3.5 Desventajas al usar metodologías de desarrollo ágiles
Como se logran identificar fortalezas en las metodologías ágiles también se han logrado
identificar eslabones débiles los cuales son los siguientes:
Fuerte dependencia de los líderes
Los equipos de trabajo dependen en buena medida del liderazgo de la persona responsable.
Las reuniones continuas y las evaluaciones periódicas hacen que la persona que encabeza el
proyecto centralice casi todas las decisiones y responsabilidades.
Al tener tanta dependencia de decisiones y responsabilidades se puede incurrir en que el
proceso llegue a tener un cuello de botella y se pierda tiempo valioso para el desarrollo del
producto.
20
Falta de documentación
Las metodologías Ágiles no plantean alternativas a para la recolección de la información de
los proyectos. Simplemente plantea la manera cómo se llevarán a cabo las acciones.
Si bien la documentación es exhaustiva en las metodologías de desarrollo ágil llegando a ser
tediosas en la realización de la mismas, en las metodologías ágiles se llega a tener un cierto
vacío debido a que no se le pone en énfasis adecuado, en caso de cambio de personal del
equipo de desarrollo se llega a tener un serio problema.
Soluciones erróneas en etapas largas
Cuando las iteraciones tienden a ser muy largas, se corre el riesgo de que las soluciones
esbozadas al inicio de las etapas no sean las correctas. Una fase larga puede evolucionar
mientras se está ejecutando y, por tanto, las medidas tomadas tienen a perder vigencia.
4 Metodología Scrum
Es un marco de trabajo que nos permite encontrar prácticas emergentes en dominios
complejos, como la gestión de proyectos de innovación, presenta las siguientes características:
• Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y
ejecución completa de un producto
• Trata de basar la calidad del resultado más en el conocimiento tácito de las personas
en equipos auto organizados que en la calidad de los procesos empleados
Estos comportamientos fueron identificados y definidos por Ikujiro Nonaka e Hirotaka
Takeuchi a principios de los años 80.
21
En este entendido se debe tomar en cuenta a Scrum como una posible solución a la
problemática que presentan las empresas de telecomunicaciones al usar metodologías de
desarrollo tradicionales.
Figura 5– Marco Scrum

Fuente: Libro Scrum Manager l, Juan Palacio
Scrum no es un proceso completo, y mucho menos, una metodología. En lugar de proporcionar
una descripción completa y detallada de cómo deben realizarse las tareas de un proyecto,
genera un contexto relacional e iterativo, de inspección y adaptación constante para que los
involucrados vayan creando su propio proceso. Esto ocurre debido a que no existen ni mejores
ni buenas prácticas en un contexto complejo. Es el equipo de involucrados quien encontrará
la mejor manera de resolver sus problemáticas. Este tipo de soluciones serán emergentes.
22
Figura 6– Ilustración Scrum
Para este entendido se debe generar un proceso de incepción en el nuevo marco de trabajo,
aquí se debe hacer hincapié en que el equipo debe estar abierto al cambio, dispuesto a dar un
salto de fe y tener un cambio de paradigma dejando atrás las metodologías de desarrollo
tradicionales y aceptar las nuevas prácticas de las metodologías de desarrollo ágiles.
El progreso de los proyectos que utilizan Scrum se realiza y verifica en una serie de iteraciones
llamadas Sprints.
Estos Sprints tienen una duración fija, pre-establecida de no más de un mes. Al comienzo de
cada Sprint el equipo de desarrollo realiza un compromiso de entrega de una serie de
funcionalidades o características del producto en cuestión.
Al finalizar el Sprint se espera que estas características comprometidas estén terminadas, lo
que implica su análisis, diseño, desarrollo, prueba e integración al producto.
En este momento es cuando se realiza una reunión de revisión del producto construido durante
el Sprint.
23
El feedback obtenido en esta reunión puede ser incluido entre las funcionalidades a construir
en futuros Sprints.
4.1 Análisis de Contexto –Cynefin
Figura 7– Marco Cynefin

24
Cynefin es un 3framework conceptual que ayuda a la toma de decisiones en la cual se detallan
cinco tipos de dominios de complejidad diferentes: simple, complicado, complejo, caótico y
desordenado.
Dominio Simple
El dominio simple se opera con problemáticas sencillas donde es fácil identificar las causas y
efectos, por lo cual la respuesta es clara y conocida por todos sin ser sujeta a discusión, los
procesos son más eficientes ya que especifican una serie lógica de pasos llegando a tener
conceptualmente las mejores prácticas.
Dominio Complicado
En este dominio encontramos problemas complejos donde existen múltiples soluciones para
dar solución a una misma problemática. A diferencia del dominio simple se requiere que un
experto esté involucrado el cual ya tiene un conocimiento de consideración el cual podrá
orientar dentro de las soluciones propuestas.
Dominio Complejo
En este dominio no se tiene certeza de los resultados es decir se vuelven más impredecibles,
en este punto no existen ni mejores prácticas ni buenas prácticas, simplemente no se llega a
3
Framework, es una estructura conceptual y tecnológica de soporte definido, normalmente con
artefactos o módulos de software concretos, que puede servir de base para la organización y
desarrollo de software.
25
saber con anticipación si determinada solución será efectiva, en caso de que la solución
encontrada sea efectiva será replicable en el tiempo en casos similares. Se debe considerar que
en el dominio complejo se debe tener un ambiente adecuado donde la solución a experimentar
sea de bajo impacto, podría considerarse un ambiente de desarrollo sin que afecte al ambiente
productivo.
Dominio Caótico
El dominio caótico requiere de una acción inmediata para reestablecer el orden, en este tipo
de dominios no es prudente tratar de aplicar metodologías ágiles, alguien debe tomar
decisiones sin importar la metodología y dar una pronta solución ya sea temporal o de fondo
con el fin de analizar posteriormente la solución más robusta se permite improvisar.
Dominio Desordenado
Se trata de un dominio desordenado cuando no se puede saber en qué espacio nos
encontramos, se trata de una zona peligrosa ya que no se puede medir las situaciones ni se
puede determinar la forma de actuar, de sobremanera el mayor peligro de este dominio es errar
en la manera de proponer una solución lo cual implicaría un alto costo de recursos.
Una vez se ha comprendido los dominios del entorno que rodean a un proyecto se puede
entender la diferencias que pueden existir entre las metodologías tradicionales vs las
metodologías ágiles.
26
4.2 Principios de Scrum
Considerando que Scrum es el modelo más utilizado dentro de las metodologías ágiles,
muchos de sus valores del manifiesto ágil tienen su origen en scrum.
Individuos e interacciones por sobre procesos y herramientas
Scrum se apoya en la confianza hacia las personas y sus interacciones.
Los equipos identifican lo que hay que hacer y toman la responsabilidad de hacerlo, estos
equipos trabajan en conjunto con otras partes de la organización cuando los impedimentos
están fuera de control.
Software funcionando sobre documentación exhaustiva
Scrum requiere que al final de cada Sprint se entregue un producto funcionando, en Scrum
la documentación es entendida como un producto intermedio sin valor de negocio, deja
abierta la documentación al equipo como crea conveniente documentar.
Ninguno de estos documentos es considerado como resultado de un sprint, el progreso del
proyecto se mide con base a la entrega iterativa de funcionalidades.
Colaboración con el cliente por sobre la negociación de contratos
La colaboración con el cliente en Scrum está por sobre la negociación de contratos a
diferencia de las metodologías tradicionales donde es prácticamente lo contrario, para este
entendido se tiene un actor dedicado netamente a ser el nexo entre el cliente y el equipo
Scrum, es el Product Owner el cual está encargado de garantizar que el entregable tenga el
mayor valor al final de cada iteración.
27
Respuesta al cambio por sobre el seguimiento de un plan
Scrum por diseño se asegura de que cada individuo dentro del equipo scrum tenga toda la
información para que pueda realizar toma de decisiones en cualquier momento ya habíamos
mencionado anterior mente la transparencia con el equipo diferencia puntual con las
metodologías de desarrollo de software tradicionales, al realizar esto el proyecto puede
cambiar fácilmente de alcance, “Fomentar el cambio es una ventaja competitiva”.
4.3 Valores de Scrum
Adicional a los cuatro principios de Scrum explicados anteriormente, Scrum se hace fuerte
considerando cinco pilares que son los siguientes:
Foco
Los equipos de Scrum se enfocan en un conjunto acotado de características, esto permite que
al final de cada Sprint se entregue un producto de alta calidad.
Coraje
Considerando que los equipos de Scrum trabajan como verdaderos equipos, pueden apoyarse
entre compañeros de equipo y así poder asumir compromisos desafiantes que les permitan
crecer como profesionales y como equipo.
Apertura
Los equipos Scrum privilegian la transparencia y la discusión abierta de problemas, no
existen agendas ocultas ni triangulación de conflictos, esto debido a que la información esta
disponible para todos en cualquier momento.
28
Compromiso
Los equipos Scrum tienen mayor control sobre sus actividades, por ello se espera un
compromiso profesional para el logro de los objetivos con éxito.
Respeto
Debido a que los miembros de un equipo Scrum trabajan de forma conjunta donde llegan a
compartir éxitos y fracasos se tiene que fomentar el respeto mutuo aspecto fundamental para
mantener buenas relaciones laborales.
4.4 Roles de Scrum
En un equipo Scrum se espera que intervengan los siguientes roles:
Product Owner, Equipo de desarrollo, Scrum Master
Figura 8– Equipo Scrum

29
Product Owner
Es la persona responsable del éxito del producto desde el punto de vista de los stakeholders
o partes interesadas, tiene determinadas responsabilidades como ser:
• Determinar la visión de producto
• Gestionar las expectativas de los stakeholders
• Recolectar requerimientos
• Determinar las funcionalidades de Alto y Bajo nivel
• Generar el plan de entregas
• Maximizar la rentabilidad del producto
• Determinar las prioridades en el proyecto
• Aceptar o Rechazar el producto construido durante el Sprint
• Participar de la revisión del sprint junto a los miembros del equipo de desarrollo
30
Figura 9– Product Owner
El Product Owner se focaliza en maximizar la rentabilidad del producto, de esta manera
puede re organizar la cola de trabajo del equipo de desarrollo para que se construya con
anticipación lo que considera prioritario y de mayor valor.
Otra de las responsabilidades importantes del Product Owner es la gestión de expectativas
de las partes interesadas mediante la comprensión completa de la problemática de negocio.
31
Equipo de Desarrollo
El equipo de desarrollo está formado por todos los individuos necesarios para la construcción
de un producto, ellos son los únicos responsables por la construcción y calidad de un
producto.
Figura 10– Equipo de Desarrollo

El equipo de desarrollo es auto organizado, esto significa que no existe un líder externo que
asigne las tareas ni que determine la forma como serán encaradas, el mismo equipo es el que
determina la forma en cómo se realizaran las tareas.
Se recomienda que un equipo Scrum este compuesto de hasta nueve personas, cada una de
ellas debe tener todas las habilidades para realizar el trabajo requerido, esto significa que
32
dentro del equipo no existen especialistas exclusivos si no individuos generalistas con
capacidades especiales sus responsabilidades son las siguientes:
• Proveer estimaciones de esfuerzo para cada una de las características del producto.
• Comprometerse al comienzo de cada sprint a construir un conjunto de características
mientras dura el mismo.
• Responsable por la entrega del producto terminado al finalizar cada Sprint
Scrum Master
Es el coach del equipo y es quien ayuda a alcanzar el máximo de su nivel de productividad
posible, es un líder por ser un ejemplo a seguir, facilitador por fomentar contextos de
apertura y discusión donde todos pueden expresar sus opiniones y lograr consensos
comunes, provocador por desafiar las estructuras rígidas y antiguas concepciones de cómo
se hacían las cosas antiguamente, detective por involucrarse activamente en la búsqueda e
identificación de indicios en la narrativa del equipo saber lo que expresa su equipo, soplador
de brasas por que llegar a reconectar a las personas con sus pasiones dormidas o por
apagarse.
Se espera que el Scrum Master acompañe al equipo de trabajo en su día a día y que garantice
que todos incluyendo el Product Owner utilicen Scrum de manera correcta.
33
Figura 11– Scrum Master
Las responsabilidades del Scrum Master son la siguientes:
• Velar por el correcto empleo y evolución de Scrum
• Facilitar el uso de Scrum a medida que avanza el tiempo
• Asegurar que el equipo de desarrollo sea multifuncional y eficiente
• Proteger al equipo de distracciones externas
• Detectar, monitorear y facilitar le remoción de impedimentos que puedan surgir con
respecto al proyecto o la metodología.
• Asegurar la cooperación y comunicación dentro del equipo.
34
Adicional a estas responsabilidades el Scrum Master debe detectar problemas y conflictos
interpersonales dentro del equipo de trabajo.
También incluye en asegurar que el desarrollo del producto tenga la mayor probabilidad de
ser completado de forma exitosa, para lograr esto trabaja de forma directa con el Product
Owner asegurando una correcta priorización de requerimientos.
4.5 Elementos de Scrum
Product Backlog
Elemento principal de Scrum, conocido también como la pila de producto.
Figura 12– Product Backlog

35
Es básicamente el listado de ítems (Products Backlog Items) o características del producto a
construir, es mantenido y priorizado por el Product Owner, es importante que exista una
clara priorización ya que esto determinara el orden del equipo.
El equipo de desarrollo puede sugerir la priorización de los PBIs pero el Product Owner es
quien tiene la última determinación para elegir el orden de prioridades.
Una forma de priorizar los PBIs es según su valor de negocio.
Otra forma de priorizar los PBIs es según el Retorno de la Inversión, donde se llega a calcular
cual es el beneficio económico que se obtendrá en función a la inversión bajo la siguiente
fórmula:
Como no es posible predecir de manera directa como van variando pos PBIs el Product
Backlog va mutando en el tiempo con respecto al alcance.
Para esto se debe considerar que el alcance puede tener variación dependiendo de las
variables a considerar, por ejemplo, se considerará las variables tiempo y costo respecto al
alcance y se mostrará cómo afectan tanto enfoques tradicionales como ágiles.
36
Figura 13– Triangulo de Hierro
Como se puede observar en el enfoque tradicional el alcance es inamovible, a diferencia de
un enfoque ágil donde el alcance es variable, pero tendrá una incidencia directa en las
variables del tiempo y costo, es donde el Product Owner debe hacer énfasis con las partes
interesadas.
37
Sprint Backlog
Sprint Backlog es el conjunto de PBIs que fueron seleccionados para trabajar durante un
cierto Sprint, conjuntamente con las tareas que ha identificado el equipo de desarrollo para
poder crear un incremento funcional potencialmente entregable al finalizar el Sprint.
Figura 14– Sprint Backlog

El resultado de cada Sprint debe ser un incremento funcional potencialmente entregable.
38
Sprint
Las iteraciones en Scrum se las conocen como Sprints, como en todas las metodologías de
desarrollo ágiles se tratan de procesos iterativos donde el producto va adquiriendo mayor
valor en el tiempo.
En general Scrum recomienda que la duración de un Sprint este entre 1 y 4 semanas, siendo
lo habitual una duración de 2 a 3 semanas. Esto llegara a marcar la velocidad del equipo de
desarrollo, pero existe un cierto riesgo el no mantener Sprints constantes ya que se llega a
tener una falsa idea de la velocidad del equipo de desarrollo llegando a subestimar el alcance
de los PBIs,
Sprint Planning Meeting
Al comienzo de cada Sprint se realiza una reunión de planificación del Sprint donde serán
generados los acuerdos y compromisos entre el equipo de desarrollo y el Product Owner
sobre el alcance de cada Sprint, en estas reuniones se divide en dos partes para abordar el
alcance la primera parte estratégica en el “que” y la segunda parte táctica donde se aborda el
“como”.
39
Parte Uno: ¿Qué trabajo será realizado?
Figura 15– Sprint Planning parte uno

Parte Dos: ¿Cómo será realizado el trabajo?
Figura 16– Sprint Planning parte dos

40
Scrum Diario
Uno de los beneficios de Scrum está en el incremento de la comunicación dentro del equipo
en el proyecto, esto facilita la coordinación de acciones entre los miembros del equipo de
desarrollo. Para lograr estos beneficios se llevan a cabo reuniones denominadas Dayli
Scrums o reuniones de Scum diarias, son reuniones cortas no más de 15 minutos donde acude
el Scrum Master y el equipo de desarrollo, en caso de ser necesario se puede convocar a las
partes interesadas o Stake holders inclusive el Product Owner.
El Scrum Master es quien lidera esta reunión y cada uno de los miembros debe responder a
estas tres preguntas que hará el Scrum master diariamente
• ¿Qué hice desde la última reunión diaria hasta ahora?
• ¿En qué voy a estar trabajando hasta la próxima reunión diaria?
• ¿Qué problemas o impedimentos tengo?
Figura 17– Scrum diario

41
Sprint Review
Al finalizar cada Sprint se realiza una reunión de revisión del Sprint, donde se evalua el
incremento funcional potencialmente construido por el equipo de desarrollo.
En esta reunión participaran los stake holders y el equipo scrum revisando el resultado del
sprint donde aceptaran o rechazaran la funcionalidad que se les está entregando.
Figura 18– Sprint Review

42
Retrospectiva
En un método empírico como Scrum, la retrospección del equipo es el núcleo de la mejora
continua y las practicas emergentes, mediante este mecanismo el equipo reflexiona sobre la
forma que realizo su trabajo, esta reunión tiene lugar inmediatamente después de la reunión
de revisión del sprint, donde podrán expresarse sin censura dentro del marco de respeto.
Se aplicarán técnicas de facilitación y análisis de causa raíces para lograr identificar
fortalezas como debilidades posteriores a ello el equipo decide las acciones a tomarse para
llevar a cabo las mejoras en el siguiente Sprint.
Refinamiento del Product Backlog
El refinamiento del Product Backlog es una actividad constante a lo largo de todo el sprint,
aunque algunos equipos prefieren llevarla a cabo en una reunión especifica en función a las
necesidades de los PBIs para asi determinar los riesgos implícitos en los PBIs para este fin
es esencial la participación de todo el equipo Scrum.
4.6 El fracaso del modelo Cascada
El desarrollo de software no es una disciplina sencilla, en las últimas décadas los lenguajes
estructurados modernos, de modelado y herramientas varias intentaron ser soluciones
sencillas a un problema complejo.
El modelo secuencial de procesos o Cascada se convirtió por décadas en el modelo
metodológico más utilizado dentro de la industria.
En la industria del software no existía ningún lineamiento formal, así que el modelo
secuencial en cascada fue adoptado para el desarrollo del software.
43
Con el pasar del tiempo si bien se estuvo alineado al modelo tradicional en cascada se vieron
principalmente los siguientes problemas:
• Los clientes quieren ver el producto a medida que este es desarrollado, siendo ellos
mismos los que realicen las pruebas
• Retrasar las pruebas hasta una etapa de cierre de proyecto conduce a riesgos de coste
mayor y generación de un impacto negativo en el cliente
• Los clientes en este punto desconocen la calidad del producto que se está
desarrollando, pueden quedar insatisfechos en la entrega final
• No existe flexibilidad al cambio, en el modelo de desarrollo en cascada el alcance
del proyecto es inmovible
• No existe trabajo en equipo, al separar las actividades por secuencias, se trabaja con
especialista aislados el concepto de equipo es débil.
• Al tener poca entrega de valor en el producto la gestión de cobros se hace tediosa
porque no existe ese entregable el cual genera valor al producto y que puede ser
percibido por las partes interesadas
Todo esto lleva a que el modelo en cascada haya fracasado en el ámbito del desarrollo del
software.
44
5 Conclusiones y Recomendaciones
En cuanto a las empresas de telecomunicaciones aplicaron como el resto de las empresas
que tienen que ver con el ámbito de la informática la metodología tradicional de desarrollo
en cascada. Al tener entornos más complejos se volvió obsoleta y poco manejable la
aplicación de estas metodologías tradicionales, con base a la experiencia propia se ha podido
percibir grados de insatisfacción altos por parte de clientes internos y clientes finales, por lo
burocrático y poca accesibilidad al cambio que maneja la metodología de desarrollo
tradicionales en cascada.
Como conclusión se puede afirmar que el modelo en de desarrollo en cascada está obsoleto
para la aplicación de proyectos en entornos complejos.
Se recomienda la aplicación de metodologías ágiles para este tipo de entornos, los más se
adecuan a las empresas de telecomunicaciones, se recomienda el uso de Scrum como marco
de trabajo, es ideal para la aplicación en empresas de telecomunicaciones por el alto valor
de entregables funcionales de manera iterativa que plantea este marco de trabajo.
45
6 Bibliografía
• Palacio, J. (2015). Scrum Manager l: Las reglas de scrum. Buenos Aires: Safecreative.
• Alaimo, M & Salías, M (2015). Proyectos Ágiles con #Scrum. Buenos Aires: Kleer.
• Verheyen, G. (2014). Scrum - A Pocket Guide. Van Haren Publishing: Van Haren.
• Frameworx P. (2019). Business Process Framework. 2019-05-31, de TM FORUM Sitio
web: https://www.tmforum.org/resources/suite/gb921-business-process-framework-etom-
suite-release-18-5/
• UV-MDAP. (2018). Metodologías ágiles vs Metodologías tradicionales. 2019-06-18, de
UV-MDAP Sitio web: https://uv-mdap.com/programa-desarrollado/bloque-iv-
metodologias-agiles/metodologias-agiles-vs-tradicionales/
• Alaimo M. (2018). Waterfall la historia detrás del error. 2019-06-11, de Kleer Sitio web:
https://medium.com/kleer/waterfall-la-historia-detr%C3%A1s-del-error-39f589a12115
• Comunidad IEBS. (2018). Metodologías ágiles. 2019-06-18, de Comunidad IEBS Sitio
web: https://comunidad.iebschool.com/metodologiasagiles/general/concepto-
46

Agilidad en Proyectos de Telecomunicaciones

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Agilidad en Proyectos de Telecomunicaciones

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGÍA

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE

POSTULANTE : Julio Rafael Daviú Arévalo

1.1 Antecedentes Generales………………………………………………………………………. 8

1.2 Antecedentes Específicos……………………………………………………………………..10

3 Conceptos importantes sobre metodologías ágiles………………………………………...13

3.1 Manifiesto ágil…………………………………………………………………………….. 14

3.2 Diferencias entre metodologías agiles y metodologías tradicionales…………………..16

3.3 Dominio en proyectos de Telecomunicaciones………………………………………… 18

3.4 Ventajas al usar metodologías de desarrollo ágiles……………………………………. 19

3.5 Desventajas al usar metodologías de desarrollo ágiles………………………………... 20

4.1 Análisis de Contexto –Cynefin…………………………………………………………. 24

4.2 Principios de Scrum…………………………………………………………………….. 27

4.3 Valores de Scrum………………………………………………………………………... 28

4.4 Roles de Scrum……………………………………………………………………………29

4.6 El fracaso del modelo Cascada……………………………………………………………43

Figura 1 – Diagrama de Operaciones Empresas Telecom 7

Figura 2 – Flujo Agile 13

Figura 3 – Manifiesto Ágil 16

Figura 4 – Diferencias Metodologías tradicionales vs Metodologías ágiles 22

Figura 5– Marco Scrum 23

Figura 6– Ilustración Scrum 24

Figura 7– Marco Cynefin 20

Figura 8– Equipo Scrum 29

Figura 9– Product Owner 31

Figura 10– Equipo de Desarrollo 32

Figura 11– Scrum Master 34

Figura 12– Product Backlog 35

Figura 13– Triangulo de Hierro 37

Figura 14– Sprint Backlog 38

Figura 15– Sprint Planning parte uno 40

Figura 16– Sprint Planning parte dos 40

Figura 17– Scrum diario 41

Figura 18– Sprint Review 42

En la presente monografía se explicarán las ventajas, desventajas de aplicar metodologías de

desarrollo ágil en proyectos de telecomunicaciones.

Se analizarán metodologías antiguas y el impacto que tienen en el desarrollo del software.

de software en una empresa de telecomunicaciones teniendo en cuenta que las empresas de

Para el desarrollo de estos sistemas las empresas de telecomunicaciones en un inicio adoptaron el

Adicionalmente se tratará de demostrar en la presente monografía como impacta negativamente

en la percepción de los clientes finales o clientes internos el uso de metodologías tradicionales.

decreto supremo Nro. 07441 donde expresaba la creación de la “Empresa Nacional de

Telecomunicaciones” como sociedad económica mixta y de derecho público.

La nueva empresa de telecomunicaciones inicia a partir de 1992 la expansión de las

telecomunicaciones del eje urbano al rural.

A su par comenzó a funcionar la empresa de Telecomunicaciones “Telecel S.A” en el año1993 a

conocida como Tigo.

La mayoría de las empresas de telecomunicaciones presenta la siguiente estructura de áreas

internas en cuanto a las operaciones que realizan.

metodologías tradicionales lo cual ha acarreado ciertos tipos de problemas debido a la complejidad

de los proyectos han llegado a ser identificados plenamente.

1.1 Antecedentes Generales

¿Qué son las metodologías de desarrollo de software?

de trabajo para estructurar, planificar, controlar el proceso de desarrollo en sistema de información.

diferenciadas por sus fortalezas y debilidades.

grandes conglomerados comerciales-empresariales.

¿Qué es el enfoque del desarrollo del software?

Cada metodología de desarrollo de software tiene un determinado enfoque llegando a ser

catalogados como enfoques tradicionales o enfoques ágiles.

las ventajas y desventajas que tienen cada uno de ellos.

Una breve historia de la metodología de desarrollo en Cascada

ahí donde viene su nombre como si fuera una cascada).

Los pasos mencionados son análisis de requerimientos, diseño, implementación, pruebas,