Sebastian Prieto Moreno

AYPR30

Desing Thinking
Es una forma de pensamiento o tendencia aplicable a la manera en que las empresas
trabajan, mediante métodos que permitan conocer al usuario y cubrir sus necesidades de
forma creativa. El Desing Thinking aporta herramientas enfocadas en la creatividad e
innovación, teniendo en foco al consumidor pues buscan que tiendan a satisfacer de mejor
manera las necesidades de los usuarios haciéndolos parte activa del proceso de creación.
Tim Brown, considerado como el maestro y creador del Design Thinking, ya que a lo largo
de su carrera Brown ha promovido la idea de tomar al pensamiento de diseño como un
método estratégico para la satisfacción de las necesidades de las personas.

Fases y algunas etapas del Desing Thinking

Empartizar: Aprender de la audiencia para la que se está diseñando.
 Storytelling: Historia del proceso, desde la idealización hasta prototipado
 Dentro/fuera: Facilitar la toma de desciones y consensos
Definir: Constituir un punto de vista basado en las necesidades y percepciones de los
usuarios.
 Blueprint: Experiencia del usuario con un producto o servicio
 Mi turno: Estructurar las aportaciones de cada persona en grupo
Idear: Imaginar soluciones creativas.
 Maquetas: Visualizar y testear una posible solucion
 Scamper: Aumentar el número de ideas
Prototipar: Construir una representación de una o más ideas para mostrar.
 Casos de uso: Mejorar la funcionalidad del producto o servicio
 Lego Serious Play: Facilitar el pensamiento a través del juego
Evaluar: Volver al grupo de pruebas inicial y obtener un feedback.
 Selección N.U.F : Evaluar ideas en base a su viabilidad, nivedad y aporte de valor
 Mas_/Mejor: Obtener feedback constructivo
Casos prácticos:
• Airbnb: Unos años atrás estuvo a punto de quebrar, busco motivar personas,
opiniones cambio estrellas por corazones 30% hoy en día es una de las empresas
con mayores ingresos Sus fundadores decidieron ponerse en la piel de los clientes
para conocer sus necesidades. De este modo, comenzaron a analizar sus posibles
 errores y a hablar directamente con sus clientes, para descubrir cuáles eran los
principales problemas que suponía la plataforma. Después de realizar todos los
cambios que surgieron fruto de su trabajo de investigación y de ir midiendo los
resultados que iban obteniendo, llegaron a su modelo de negocio actual, modelo con
el que han conseguido revolucionar el sector del turismo.

• Apple: Claridad objetivos, crecimiento Innovacion, calidad Resultados, mejora de

procesos y modelo de negocios Steve Jobs decía que ser emprendedor no tiene que
ver con el dinero o la fama, tiene que ver con la capacidad para resolver problemas
en la sociedad y la pasión para crear oportunidades donde la gente sólo ve
problemas.

Desing Thinking vs Desing Sprint

La mayor diferencia es el tiempo que tardan en ejecutar un proyecto pues en Desing Sprint
tienen un tiempo menor que el thinking, el sprint hace un paso a paso y lleva la idea en un
plazo corto. Desing thinking es una disciplina , forma diferente de pensar y tienen en cuenta
la necesidad de la personas, Sprint acelera el tiempo de validación y es tiene propuesta de
propia voz además de que es un proceso o metodología.

SPIRAL MODEL
HISTORIA
El creador del modelo en espiral fue Barry Boehm quien recibió su grado de B.A. de
Harvard en 1957, y sus grados de M.S. y de Ph.D. de UCLA en 1961 y 1964, todo en
matemáticas. El modelo Espiral fue definido por primera vez en el año 1988. Sus
contribuciones al campo incluyen el modelo constructivo del coste (COCOMO), el modelo
espiral del proceso del software, el acercamiento de la teoría win-win a la determinación de
la gerencia y de los requisitos del software y a dos ambientes avanzados de la tecnología de
dotación lógica.
POR QUE SE DENOMINA SPIRAL MODEL
Es un modelo de ciclo de vida del software. Las actividades de este modelo se conforman
en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las
actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función
del análisis de riesgo, comenzando por el bucle interior. Cuando empieza este proceso
evolutivo, el equipo de ingeniería de software gira alrededor de la espiral en la dirección de
las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede
producir el desarrollo de una especificación de productos; los pasos siguientes en la espiral
se podrían utilizar para desarrollar un prototipo y progresivamente versiones más
sofisticadas del software.

CONJUNTO DE TAREAS
1. Comunicación con el cliente: las tareas requeridas para establecer comunicación entre
el desarrollador y el cliente.
2. Planificación: las tareas requeridas para definir recursos, el tiempo y otras
informaciones relacionadas con el proyecto. Son todos los requerimientos.
3. Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras
informaciones relacionadas con el proyecto.
4. Ingeniería: las tareas requeridas para construir una o más representaciones de la
aplicación.
5. Construcción y adaptación: las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario.
6. Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la
evaluación de las representaciones del software creadas durante la etapa de ingeniería e
implementación.

ANTECEDENTES
El modelo espiral tuvo varias modificaciones.
• Modelo Original de Boehm.
• Modelo Típico de Seis Regiones.
• Modelo WINWIN.

ROLES
 Desarrollador: Escribe las pruebas unitarias y produce el codigo del sistema. Define
las tareas que conlleva cada historia de usuario, y estima el tiempo que requiera
cada una.
 Cliente: Asigna la prioridad a las historias de usuario y decide cuales se
implementan en cada iteración centrándose en aportar el mayor valor al negocio.

HITOS DEL PROCESO

1. Objetivos del ciclo de vida (OCV): Define un conjunto de objetos para cada
actividad principal de ingeniería de software. Un conjunto de objetivos asociados a
la definición de los requisitos del producto/sistema del nivel más alto.
 2. Arquitectura del ciclo de vida (ACV): establece los objetivos que se deben
conocer mientras que se define la arquitectura del software y el sistema. El equipo
del proyecto de software debe demostrar que ha evaluado la funcionalidad de los
componentes del software reutilizables y que ha considerado su impacto en las
decisiones de arquitectura.
3. La capacidad operativa inicial (COI): representa un conjunto de objetivos
asociados a la preparación del software para la instalación/distribución. Preparación
del lugar previamente a la instalación, y la asistencia precisada de todas las partes
que utilizará o mantendrá el software

FASES DEL PROCESO

1. Determinar o fijar los objetivos. En esta etapa se definen los objetivos específicos, para
posteriormente identifica las limitaciones del proceso y del sistema de software, además se
crea una planificación detallada de gestión y se identifican los riesgos.
2. Análisis del riesgo. En esta etapa, se efectúa un análisis detallado para cada uno de los
riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y
luego del análisis de estos riesgos se planean estrategias alternativas.

3. Desarrollar, verificar y validar. En esta etapa, después del análisis de riesgo, se eligen un
paradigma para el desarrollo del sistema de software y se desarrolla.
4. Planificar. En esta última etapa, es donde el proyecto se revisa y se toma la decisión si se
debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan
los planes para la siguiente fase del proyecto.

CARACTERISTICAS
 Mejora los ciclos de vida
 Analiza cada error o alternativa que se presenta en el proceso
 Determina en cada parte del proceso los objetivos y analiza la gestion de riesgos
 Usualmente se combina con otro modelos (cascada,evolutivo)
 En cada giro se construye un nuevo modelo del sistema operativo

VENTAJAS
• El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora.
• El desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de
los nivele evolutivos.
• Reduce riesgos del proyecto debido por cada iteración se toma mediadas.
 DESVENTAJAS

 Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas

operativos
 Se requiere de experiencia para analizar cada parte del proceso

EJEMPLO PRACTICO
SISTEMA OPERATIVO ANDROID Android ha visto numerosas actualizaciones desde su
liberación inicial. Estas actualizaciones al sistema operativo base arreglan bugs y agregan nuevas
funciones. Generalmente cada actualización del sistema es desarrollada bajo un nombre en código
de un elemento relacionado con postres.
- Apple Pie (Tarta de Manzana)
Lanzado el 23 septiembre 2008.
Es la primera versión, no hay mejoras.
No se utilizó comercialmente
1.1 - Banana Bread (Pan de Banana)
Lanzado el 9 Febrero 2009.
Corrigieron errores de la 1.0.
Tampoco se usó comercialmente.
1.5 - Cupcake
Lanzado el 30 Abril 2009.
Basado en el kernel de Linux .
Teclado con predicción de texto.
Soporte para Bluetooth.
Capacidad de conexión automática para conectar a auricular Bluetooth.
Nuevos widgets y carpetas.
Transiciones de pantalla animadas.
1.6 - Donut (Dona)
Lanzado el 15 septiembre 2009.
Una interfaz integrada de cámara, filmadora y galería.
La galería ahora permite a los usuarios seleccionar varias fotos para eliminarlas.
Búsqueda por voz actualizada, con respuesta más rápida y mayor integración con aplicaciones
nativas, incluyendo la posibilidad de marcar a contactos.
Experiencia de búsqueda mejorada que permite buscar marcadores, historiales, contactos y páginas
web desde la pantalla de inicio.
Kitkat (Galleta de chocolate con leche)
Lanzada El 5 de noviembre de 2013.
Se substituyen elementos de la interfaz de azul a blanco.
Las horas del reloj ya no se muestran con números en negrita, tanto minutos como horas son finos.
Transparencias en la barra de estado y barra de navegación.
Desactivado el acceso a las estadísticas de batería a aplicaciones de

SISTEMA GESCAP – TELEFONICA (M. WIN-WIN) Funcionalidad: Este sistema, hace el

manejo de sistema comercial, ventas, facturaciones, además registra todas las solicitudes de un
cliente, este sistema también se encarga de realizar las transacciones con la empresa telefónica, ya
sean por campañas, ofertas, descuentos a determinados clientes y otras peticiones, actualización de
productos, y todas las transacciones del área comercial. Al realizar las actualizaciones también en
determinados periodos se tiene que cambiar el hardware, sistemas operativos.

BIBLIOGRAFIA
 Modeloespiral.blogspot.com
 Scruz334.blogspot.es
 https://prezi.com/kp_p0ycwhovk/modelo-de-vida-en-espiral/
 https://sg.com.mx/content/view/737https://sg.com.mx/content/view/737
 https://es.slideshare.net/miltonarnoldtorresccoa5/metodo-espiral-76832441
 https://www.guru99.com/what-is-spiral-model-when-to-use-advantages-
disadvantages.html

DESING SPRINT

¿QUÉ ES?
Design Sprint es una metodología que permite prototipar y validar ideas con usuarios
finales de manera rápida, con el fin de definir el roadmap de un producto en 5 fases. Este
método fue creado por Google Ventures en 2010, después de haber estudiado cientos de
estrategias de User Research y Design Thinking, el Design Sprint reúne las más efectivas y
propone una forma de trabajar que permite lanzar pronto un producto exitoso y desarrollar
startups.
Dentro de una empresa hay 4 partes claves que integran este proceso que son: estrategia de
negocios, ciencia de comportamiento, design thinking y gestión de procesos.
¿POR QUÉ SE LLAMA ASÍ?
Como se pudo observar en una metodología ágil que se desarrolla en un tiempo de 5 días en
5 fases cada una con una intensidad de 8 o 10 horas.
Sprint significa aceleración para alcanzar la máxima velocidad en el menos tiempo posible,
y design diseño, así que textualmente se puede deducir que es un diseño rápido y veloz.
ACTORES
-Design manager: También llamado facilitador Es el encargado de la agenda y la logística,
también de elegir el teamdream.
-Arbitro: Quien toma de desiciones difíciles, puede ser el el ceo (chief executive officer/
director ejecutivo)
-Equipo de trabajo: Entre 4 a 7, un equipo multidisciplinar  e incluyen experto del tema ,
al diseñador , a quien toma las decisiones (sprint master), gerente de marketing  ,
al ingeniero y a alguien del núcleo de la compañía.
-Tester: Fundamentales en la última fase, son los clientes o stakeholders secundarios que
prueban el prototipo para dar su opinión y retroalimentación acerca de este.

FASES DEL DESIGN SPRINT

Previo al inicio del design se debe establecer un brief y además un equipo de trabajo.
1. Entender
Primera fase, y quizás la más importante. En este momento el equipo de trabajo debe:
Saber quién es el usuario, cuáles son sus necesidades, motivaciones y sueños.
Conocer el contexto del producto y de la organización.
¿Qué trabajos deben realizarse durante esta primera etapa del sprint design?
-Mapa de asunciones.
-Safari de producto.
-Mapa de ecosistema.
-Definición de problemas a resolver.
-Triangulación etnográfica.
-Definición sobre cuáles van a ser los principales actores.
-Entrevistas.
-Trabajo de campo.
-Volcado de información.
-Análisis de información.
-User Journey.
-Retrospectiva final de la fase.

2. Idear
Después de comprender el contexto del producto y a los potenciales usuarios a los que
nos vamos a dirigir, es momento de idear posibles soluciones al problema planteado.
Para ello el equipo debe:
Plantear ideas sin importar la calidad, solo la cantidad (tengamos en cuenta la
divergencia)
Ser multidisciplinar con el objetivo de tener diferentes visiones.
¿Qué trabajos deben realizarse durante esta segunda etapa del sprint design?
-Sesiones de creatividad. Trabajemos la divergencia y la ideación rápida.
-Revisión de contenidos.
-Job Stories.
Convergencia.
-Story Boards.
-Retrospectiva final de la fase.

3. Decidir
Fase de toma de decisiones sobre lo trabajado en las dos fases anteriores. Es aquí
cuando el equipo debe:
Tomar decisiones apoyándose en las conclusiones y la información recabada en las
fases anteriores.
Trabajar en equipo y discutir sobre las decisiones a tomar.
¿Qué trabajos deben realizarse durante esta tercera etapa del sprint design?
-Elegir mejores ideas. Por ello es fundamental apostar al 100.
-Explicar las elecciones a todo el equipo.
-Retrospectiva final de la fase.

4. Protoripar
En esta fase hay que hacer, hacer y hacer. El equipo debe:
Decidir si en este sprint va a querer validar toda la solución o solamente una parte.
Bocetar prototipos, quitando importancia al diseño final. Recordemos que lo importante
es la validación de la idea.
¿Qué trabajos deben realizarse durante esta cuarta etapa del sprint design?
-Wireframing.
-Creación de artefacto que nos permite tangibilizar nuestra idea.
-Prototipo en papel. Keynote o Power Point.
-Marvel.
-POP.
-Invision.
-Axure.
-Retrospectiva final de la fase.
 5. Testear
Llegamos a uno de los momentos clave: la fase de pruebas con usuarios reales. En este
momento el equipo debe:
Probar el prototipo con usuarios reales.
Dejar total libertad de uso. No olvides que ell usuario es el rey.
Aprender del uso dado por el usuario.
¿Qué trabajos deben realizarse durante esta quinta etapa del sprint design?
-Preparación de los testers.
-Búsqueda de público objetivo.
-Guiones para los test.
-Trabajo de campo.
-Análisis de la información.
-Refinamiento.
-Retrospectiva final de la fase.

Conceptos claves
- Google Ventures: Se trata de una iniciativa de Google para apoyar la innovación y
promover a empresas jóvenes o start-ups prometedoras de la industria tecnológica
relacionada con Internet, software, energías renovables, biotecnología y el cuidado
de la salud.
- Startups: Es una empresa de nueva creación que comercializa productos y/o
servicios a través del uso intensivo de las tecnologías de la información y la
comunicación (TIC’s), con un modelo de negocio escalable el cual le permite un
crecimiento rápido y sostenido en el tiempo.
- Brief: El brief o briefing es un documento informativo que contiene la información
imprescindible para poder empezar a planificar o ejecutar un proyecto.
BIBLIOGRAFÍA
Definiciones:
https://www.fayerwayer.com/2009/03/nace-google-ventures-para-financiar-nuevos-
emprendimientos-tecnologicos/
https://www.cicerocomunicacion.es/que-es-un-brief-o-briefing-y-como-hacer-uno/
https://www.gv.com/sprint/
Fases:
http://theherocamp.com/blog/que-es-fases-sprint-design/
https://platzi.com/blog/que-es-design-sprint/
https://platzi.com/blog/que-es-para-que-sirve-design-sprint/
Actores
https://www.youtube.com/watch?v=xA488shvWBo
Caso práctico:
https://uxplanet.org/reto-design-sprint-u2-8b0b4379519d
RESUMEN DEL MODELO CASCADA (WATERFALL METHODOLOGY)
El modelo cascada es un modelo de desarrollo de software, donde se desarrolla mediante de
etapas donde se soluciona en orden secuencial. Este modelo fue propuesto por Winston W.
Royce en 1970 y posterior mente revisada por Barry Boehm en 1980 e Ian Somerville en
1985. Esta fue la primera herramienta creada para el desarrollo de software, posteriormente
fue reemplaza por distintos modelos, como lo son: Spiral Model, Kanban, Scrum y demás.
Este modelo se divide en seis etapas: Recopilación y análisis de requerimientos, diseño del
sistema, implementación, integración y pruebas, despliegue de sistema y por ultimo
mantenimiento. La etapa de recopilación y análisis de resultados consiste en analizar las
necesidades del cliente y así determinar cómo desea el software, esta es la etapa más
importante para que sea eficaz el modelo de cascada. Diseño de sistema describe la
estructura interna del software y las relaciones entre las entidades que lo componen, es
importante distinguir los dos tipos de diseños, arquitectónico y detallado. Implementación,
esta fase consiste en programar los requisitos especificados y diseñados en la etapa anterior.
En integración y pruebas los elementos ya programados se ensamblan para componer el
sistema y se realizan las correctas pruebas para verificar que el proceso realizado este bien.
Despliegue de sistema, esta etapa es donde el usuario final ejecuta el sistema después de las
pruebas hechas por los programadores y por último el mantenimiento, esta etapa es la más
costosa ya que se destina el 75% de los recursos del software, existen tres tipos de
mantenimiento: Mantenimiento preventivo y perfectivo, correctivo y evolutivo.
Para este desarrollo se divide en un equipo de trabajo. El desarrollador, el cual es el que
desarrolla o crea el código, después uno de los más importantes, el ingeniero de
requerimientos y su funcionamiento es el entregar una especificación de requerimientos de
software correcta y completa. Probador, realiza las pruebas finalizando las etapas, de este
personaje depende de los errores en todo el proceso. Un analista de negocios, el cual es el
encargado de hacer que el software se conozca, darle lo que quiere el usuario. Gerente de
proyectos, sencillamente es el jefe de todo el proyecto, responsable de la calidad del
software.
Pero como toda idea este proceso, modelo cascada. Tiene ventajas y desventajas. La
principal ventaja depende de que el usuario está completamente seguro de lo que necesita
en su software, ya que para hacer modificaciones en las últimas etapas es muy difícil y es
muy probable que ocurran errores, otra ventaja es que es muy perfeccionista y si el proceso
sale como se espera, lograría un resultado perfecto. La desventaja es la dificultad de reparar
los errores ya una vez finalizado las etapas, la posibilidad de error depende de la claridad de
los requerimientos dados por el usuario.
BIBLIOGRAFÍA: https://www.ecured.cu/Modelo_en_cascada,
https://openclassrooms.com/en/courses/4309151-gestiona-tu-proyecto-de-
desarrollo/4538221-en-que-consiste-el-modelo-en-cascada, https://www.obs-
edu.com/int/blog-project-management/actualidad-project-management/gestion-de-
proyectos-siguiendo-el-modelo-de-cascada, http://metodologiaencascada.blogspot.com/,
https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

Pair programming
Programación de pares es una técnica de desarrollo de software ágil en la que
dos programadores trabajan juntos en una estación de trabajo. Cada miembro realiza una
acción que el otro no está haciendo actualmente: Mientras que uno codifica las pruebas de
unidades el otro piensa en la clase que satisfará la prueba
1. Roles
- el conductor es escribe el código
- el observador o el navegador es el que revisa cada línea de código a medida que se
escribe
Los dos programadores cambian de rol con frecuencia.

2. Cuando se usa
Vamos a meternos de lleno en materia. Como cualquier otro tipo de programación,
el pair programming solicita a ambos miembros de su concentración y esto no
siempre puede darse por la diferente naturaleza de las personas. Algunas tareas,
como las tareas simples, pueden no ser adecuadas para una pareja.
- Muchos desarrolladores prefieren trabajar solos y encuentran el ambiente
emparejado incómodo.
3. Ejemplo practico
IBM informó haber gastado alrededor de “250 millones de dólares en la
reparación y reinstalación de soluciones a 30,000 problemas informados por los
clientes”. El pair programming reduciría significativamente estos gastos al reducir
los defectos en los programas.
4. Como medirlo
Por supuesto, es difícil medir el valor y la razón es que hay muchas cosas para
medir y esas métricas son difíciles de obtener. Los valores que valen la pena
considerar podrían ser:
- Tiempo de desarrollo: cuánto más/menos tiempo se gasta en desarrollo
 - Tiempo de reparación: cuánto más/menos tiempo se gasta en corregir errores o
refactorizar
- Disfrute: cuánto más/menos satisfacción laboral sienten los empleados
- Satisfacción del usuario: ¿Cuántos clientes más/menos felices y usuarios finales
tiene usted?
- Dinero: si obtienes estos datos, también debes tener una idea del valor económico.

Es imprescindible detectar todos los errores de su software, aplicación, sitio web,

… Si se lanza un producto sin habernos dado cuenta de todos los errores que
experimentarían los usuarios en tiempo real, probablemente se perderán clientes y
dinero.
5. Herramientas para pair programming
- Pramp.com Está enfocado a entrevistas
- Leaps. Es un servicio para editar colaborativamente tus archivos
- Floobits Herramienta de colaboración remota para equipos de desarrollo
- Atom Teletype Permite a los desarrolladores compartir su espacio de trabajo
6. bibliografía
. https://www.beeva.com/beeva-view/desarrollo/pair-programming-mejora-la-
productividad/
-https://medium.com/@weblab_tech/pair-programming-guide-a76ca43ff389
-https://es.wikipedia.org/wiki/Programaci%C3%B3n_en_pareja
-http://www.extremeprogramming.org/rules/pair.html

EXREME PROGRAMMING (XP) O PRORAMACION EXTREMA

Introducción.
Extreme programming surge como una nueva manera de encarar proyectos de software,
proponiendo una metodología basada esencialmente en la simplicidad y agilidad. Hace
parte de nuevos métodos los cuales buscan un punto medio entre la ausencia de procesos y
el abuso de los mismos, proponiendo un proceso cuyo esfuerzo valga la pena. XP es una de
las llamadas metodologías ágiles de desarrollo de software más exitosas de los tiempos
recientes. La metodología propuesta en XP está diseñada para entregar el software que los
clientes necesitan en el momento en que lo necesitan. XP alienta a los desarrolladores a
responder a los requerimientos cambiantes de los clientes, aún en fases tardías del ciclo de
vida del desarrollo. La metodología también enfatiza el trabajo en equipo. Tanto gerentes
como clientes y desarrolladores son partes del mismo equipo dedicado a entregar software
de calidad.
Roles en XP.
- Programador. Hace las pruebas unitarias, produce el código, define tareas de
acuerdo a la historia de cada usuario y estima el tiempo para cada una.
 - Cliente. Escribe la historia del usuario, hace pruebas funcionales y asigna prioridad
de las historias de usuarios para las iteraciones.
- Tester. Ayuda a escribir pruebas funcionales, ejecuta pruebas y define los
resultados del trabajo en equipo.
- Tracker. Está pendiente del seguimiento, realiza retroalimentación al equipo y
verifica el grado de acierto entre las estimaciones realizadas.
Ciclo de vida.
La metodología XP define cuatro variables para cualquier proyecto de software: costo,
tiempo, calidad y alcance. Además, se especifica que, de estas cuatro variables, sólo tres de
ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores
(clientes y jefes de proyecto). El valor de la variable restante podrá ser establecido por el
equipo de desarrollo, en función de los valores de las otras tres. El ciclo de vida de un
proyecto XP incluye, al igual que las otras metodologías, entender lo que el cliente
necesita, estimar el esfuerzo, crear la solución y entregar el producto final al cliente. Sin
embargo, XP propone un ciclo de vida dinámico, donde se admite expresamente que, en
muchos casos, los clientes no son capaces de especificar sus requerimientos al comienzo de
un proyecto. Por esto, se trata de realizar ciclos de desarrollo cortos (llamados iteraciones),
con entregables funcionales al finalizar cada ciclo. En cada iteración se realiza un ciclo
completo de análisis, diseño, desarrollo y pruebas, pero utilizando un conjunto de reglas y
prácticas que caracterizan a XP (y que serán detalladas más adelante).
Si bien el ciclo de vida de un proyecto XP es muy dinámico, se puede separar en fases.
Varios de los detalles acerca de las tareas de éstas fases se detallan más adelante, en la
sección “Reglas y Practicas”: Fases de exploración, planificación, iteraciones y puesta en
producción.
Reglas y prácticas.
1. Planificación. Se recopila las historias de los usuarios y luego de ser obtenidas se
mira el tiempo de desarrollo de cada una, evitando los riesgos se realizan pruebas.
2. Diseño.
3. Desarrollo.
4. Pruebas.
Acá se realizan las historias de los usuarios, plan de entregas, plan de iteraciones y
reuniones diarias de seguimiento.
Desarrollo del código.
Se debe tener en cuenta la disponibilidad del cliente el involucramiento del cliente es
fundamental para que pueda desarrollarse un proyecto con la metodología XP. Al comienzo
del proyecto, el cliente debe proporcionar las historias de usuarios. Estos detalles deben ser
proporcionados por el cliente, y discutidos con los desarrolladores, durante la etapa de
desarrollo. Además, el cliente está en todo el proceso para prevenir situaciones no
deseables.
El uso de estándares, esto no es una idea nueva, XP promueve la programación basada en
estándares, de manera que sea fácilmente entendible por todo el equipo, y que facilite la
recodificación.
Programación dirigida por las pruebas, la metodología XP propone un modelo inverso, en
el que, lo primero que se escribe son los test que el sistema debe pasar. Las pruebas a los
que se refiere esta práctica, son las pruebas unitarias, realizados por los desarrolladores.
La programación en pares que se desarrolle en pares de programadores, ambos trabajando
juntos en un mismo ordenador. Si bien parece que ésta práctica duplica el tiempo asignado
al proyecto (y, por ende, los costos en recursos humanos), al trabajar en pares se minimizan
los errores y se logran mejores diseños, compensando la inversión en horas.
Pruebas.
- Las pruebas unitarias es lo que habilita que funcione la propiedad colectiva del
código. En este sentido, el sistema y el conjunto de pruebas debe ser guardado junto
con el código, para que pueda ser utilizado por otros desarrolladores.
- Detección y corrección de errores cuando se encuentra un error (“bug”), éste debe
ser corregido inmediatamente, y se deben tener precauciones para que errores
similares no vuelvan a ocurrir.
- Las pruebas de aceptación son creadas en base a las historias de usuarios, en cada
ciclo de la iteración del desarrollo. El cliente debe especificar uno o diversos
escenarios para comprobar que una historia de usuario ha sido correctamente
implementada.
Bibliografía.
- https://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf

INGENIERIA DE REQUERIMIENTOS

La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción

de software, ya que enfoca un área fundamental la cual se encarga de recopilar, analizar y
verificar las necesidades del cliente para un sistema de software.
La meta de la ingeniería de requerimientos es entregar una especificación de requerimientos
de software correcta y completa.
Apunta a mejorar la forma en que comprendemos y definimos sistemas de software
complejos.
Para entender mejor la ingeniería de requerimientos debemos entender primero lo que es un
requerimiento o un requisito
Un requisito es una condición que se debe cumplir para satisfacer una necesidad o
especificación, entre los requisitos tenemos dos para la solución de problemas, los cuales
son los requisitos funcionales y los no funcionales
Funcionales= Especifican lo que debe hacer o los servicios que debe proporcionar el
sistema o declaraciones de los servicios que proveerá el sistema, de la manera en que éste
reaccionará a entradas particulares.
No Funcionales= Son aquellos requerimientos que no se refieren directamente a las
funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste
como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.
Poniendo como ejemplo un caso práctico podríamos suponer una empresa que necesita
catalogar sus productos por medio de códigos de barras, en este caso el requisito funcional
sería el código de barras y el numero que a este corresponde, y un requisito no funcional
sería el color del código de barras, o el tamaño de este en el empaque, así podemos
diferenciar estos dos requisitos
En la ingeniera de requisitos encontramos dos roles importantes, que son los
desarrolladores y la parte interesada, la parte desarrolladora es el equipo de trabajo que se
encarga de realizar el software o el proyecto a realizar, en este equipo de trabajo
encontramos a los siguientes personajes
- Analista de sistema: El Analista del Sistema lidera y coordina la identificación de
requisitos y el modelamiento de casos de uso esbozando las funcionalidades y
delimitando el sistema
- Especificador de Requisitos: especifica los detalles de una o más partes de las
funcionalidades del sistema describiendo uno o más aspectos de los requisitos.
- Arquitecto de Software: es responsable de la arquitectura del sistema, que incluye
las decisiones técnicas clave que delimitan el diseño general y la implementación
para el proyecto
- Revisor Técnico: es responsable de proveer una retroalimentación apropiada al
proceso de revisión
La parte interesada estaría compuesta por el comprador del software, el usuario de este y
los stakeholders.
Para entender mejor la ingeniería de requisitos veremos un caso práctico:
La empresa “El Regalo S.A.” es una cadena de tiendas de pequeños artículos de
regalo. Actualmente, los empleados que trabajan en estas tiendas cada vez que efectúan una
venta deben apuntar el código del producto que venden, así como una descripción de este
para verificar que no se ha producido ningún error de transcripción.
Requisito principal
 - el coste de instalación en cada una de las tiendas debe ser mínimo por lo que la
aplicación a desarrollar deberá poderse ejecutar en ordenadores de pequeña
potencia, y sin necesidad de adquirir ningún tipo de licencia de ejecución (run-
time), o cualquier otro software específico
Tareas para realizar
- Identificar los requisitos (funcionales y no funcionales).
- Identificar falta y/o deficiencias en la información. Proponer preguntas destinadas a
satisfacer estas deficiencias de datos.
- Derivar nuevos requisitos de las respuestas.
- Identificar los casos de uso
Conclusión
Según podemos ver la ingeniería de requerimientos, es un software que pretende
cumplir todos los requerimientos pedidos por el usuario, llevando a cabo un programa
que cumpla con todas las funcionalidades pedidas a ser desarrolladas y se enfoca en un
campo especifico.

Bibliografía
- https://users.dcc.uchile.cl/~avignaga/padan4/material/slides/04.pdf
- http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2_-_Ingenier
%C3%ADa_de_requerimientos.pdf?sequence=4

KANBAN

¿Qué es?
En metodologías agiles kanban es una técnica de representación visual de información para
mejorar la eficiencia en la ejecución de las tareas de un proyecto.
La metodología Kanban 
La metodología Kanban está ganando gran popularidad en corporaciones y empresas de
todo el mundo como una manera de gestionar el trabajo de forma fluida…
Cómo funciona Kanban?
++Visualice lo que hace (su flujo de trabajo): una visualización de todas sus tareas y
elementos en una tabla contribuirá a que todos los miembros de su equipo se mantengan al
corriente con su trabajo
++Limite la cantidad de Trabajo en Proceso (límites del TEP): establezca metas asequibles.
Mantenga el equilibrio de su flujo de trabajo mediante la limitación de los trabajos en
proceso para prevenir el exceso de compromiso en la cantidad de tareas que será incapaz de
terminar.
++Realice un seguimiento de su tiempo: El seguimiento del tiempo confluye con la
metodología Kanban. Realice un seguimiento de su tiempo de forma continua y evalúe su
trabajo con precisión.

++Lectura fácil de indicadores visuales: conozca lo que está ocurriendo de un solo vistazo.

Utilice tarjetas de colores para distinguir los Tipos de trabajo, Prioridades, Etiquetas,
Fechas límite y más.

++Identifique los cuellos de botella y elimine lo que resulta descartable: aproveche al

máximo los plazos y ciclos de ejecución, del Flujo Acumulativo y de los informes de
tiempo. Estos criterios le permitirán evaluar su rendimiento, detectar los problemas y
ajustar el flujo de trabajo en consecuencia.

Roles en kanban
Service request Manager:

Maneja las relaciones con el stakeholder y gestiona la demanda y los requisitos

dentro del Kanban.
Service Delivery Manager

Responsable del flujo del sistema Kanban y/o determinados items del trabajo.

El tablero kanban
El tablero kanban le permite asignar tareas a los miembros del equipo, adjuntar
comentarios, descripciones, enlaces y archivos. Por tanto – las tareas no necesitan más
tiempo que pueda perderse hablando. Por supuesto, mediante el aumento de la
productividad en general, No hay más pérdida de tiempo en la discusión del trabajo, que es
más rápido, ¡y explicado de forma visual! El método Kanban se basa en la idea de
visualizar lo que se está haciendo ahora, lo que se está terminando y lo que hay que hacer a
continuación.

, cada una de las tareas corresponderá a una tarea dentro de un proyecto software, y vamos a
tener una serie de posiciones por las que las tarjetas se van a ir moviendo. Esto nos va a
permitir, con una gestión muy visual, ver cómo evoluciona el proyecto.

Scrum vs Kanban
1. En Scrum existen los roles de Scrum Master, de Product Owner y del equipo, mientras
que Kanban no existen roles.
2. En Scrum se trabaja con iteraciones de tiempo fijo, con unos ciclos fijos que se
denominan Sprints, mientras que en Kanban tenemos un trabajo continuo y no
tenemos esas interacciones o esos ciclos durante el desarrollo.
3. Scrum limita el WIP (work in process o número de tareas que se pueden tener en
paralelo en una de las posiciones del tablero) por iteración, mientras que Kanban
limitar ese WIP por el estado del flujo de trabajo.
4. Mientras que Scrum exige equipos multidisciplinares, para que todos los miembros del
equipo puedan realizar varias tareas y sea todo más más ágil, en Kanban se permiten
los equipos formados por especialistas. En este caso podemos tener algún problema a
la hora de gestionar esos equipos, pero existen una serie de normas o de prácticas para
llevar a cabo para solucionarlo.
5. En Scrum no se permiten cambiar las tareas del Sprint, es decir, una vez que la tarea
asignada al mismo no puede ser movida, en todo caso lo que se permite es modificar la
fecha de entrega del Sprint, pero no esa tarea. En Kanban, por el contrario, se puede
modificar la tarea hasta que entra en flujo, hasta ese momento podemos modificar la
tarea.
6. En Scrum la pila del producto, es decir, el conjunto de tareas que tenemos que realizar
durante el Sprint, tiene que tener al menos el tamaño de un Sprint, ya que,
lógicamente, no podemos tener menos de un Sprint. En Kanban, al tener un ritmo de
trabajo continuo, lo que se hace es ir arrastrando las nuevas tareas por el panel hasta
que lleguen a su estado final y finalicen. Cualquier nuevo requisito del cliente será una
nueva tarjeta o post-it que se añadirá al flujo de entrada y que seguirá su flujo normal
hasta la salida.
7. En Scrum se mide todo lo que sea necesario, se miden historias, es decir, cuánto nos
va a llevar realizar cada historia de usuario, se mide cuánto tiempo o esfuerzo nos va a
llevar realizar cada una de las tareas y se mide también la velocidad del equipo, que es
la cantidad de trabajo que hemos realizado dividido por la cantidad de tiempo. En
Kanban, como ya tenemos una cierta habilidad de la metodología, no se miden ni
tareas ni velocidad.
8. En Scrum se necesita una pila del producto priorizada, porque como el desarrollo
completo lo vamos a dividir en distintos Sprints, la necesitamos para que los primeros
Sprints se encarguen de realizar las tareas de mayor prioridad. Con lo que vamos a
conseguir llevar valor al cliente de una manera mucho más rápida y las tareas con
menor prioridad serán realizando en los Sprints posteriores. Esta priorización la hará el
Product Owner. En Kanban la historia o tarea es arrastrada directamente desde el
cliente, por lo cual no necesita esa priorización.
9. En Scrum se tienen una serie de reuniones y se utilizan una serie de gráficos, como el
burn down, en el que podemos ver el avance del proyecto, y el burn up, que sirve para
medir la velocidad del equipo. En Kanban no se considera ni ese tipo de reuniones ni
de gráficos.
10. En Scrum los tableros se van a resetear al final de cada Sprint, es decir, conforme
vamos finalizando el mismo, el tablero queda vacío y comenzamos de nuevo añadir
nueva nuevas historias de usuario, las siguientes en prioridad. En Kanban, como
vamos a tener un flujo de entrada-salida, conforme las tarjetas van pasando por cada
 uno de los estados hasta llegar al estado final, cuando llegan a ese estado salen del
tablero y se archivan, vamos a tener un flujo continuo.

los beneficios de utilizar kanban

1. Estímulo del rendimiento. Análisis profundo y estimaciones que permiten medir su

rendimiento. Detección de cualquier problema existente y ajuste del flujo de trabajo
para ganar en eficiencia. El método Kanban es muy flexible y le permite perfeccionar
sus procesos para obtener los mejores resultados.

2. Organización y colaboración. La metodología Kanban le permite beneficiarse del

poder del enfoque visual, mediante el uso de columnas, carriles y tarjetas de colores.
Usted será capaz de trabajar en el mismo tablero que su equipo y colaborar en tiempo
real. Los tableros digitales Kanban le permitirán acceder a su flujo de trabajo desde
cualquier sitio, compartir tareas con facilidad y comunicarse en su trabajo con sus
colegas.

3. Distribución del trabajo. Una cómoda visión general de los trabajos en curso y menos
tiempo dedicado a la distribución y presentación de los trabajos. Las estimaciones son
imperfectas, por consiguiente, un flujo constante de tareas reducirá su tiempo de espera
y el ti0065mpo dedicado a la asignación de tareas. Usted selecciona sus tareas, por tanto
no tendrá que esperar a que la tarea vaya hacia usted.

Bibliografía
https://kanbantool.com/es/metodologia-kanban
https://openwebinars.net/blog/diferencias-scrum-kanban/
https://www.youtube.com/watch?time_continue=39&v=BWyMyq4xu48
https://kanbanize.com/es/recursos-de-kanban/software-kanban/ejemplos-de-tableros-
kanban/
https://iswugkanbansite.wordpress.com/inicio/roles/
https://www.masdigital.net/nuestro-blog/5-beneficios-de-kanban-que-tu-mediana-empresa-
necesita
https://www.linkedin.com/pulse/caso-práctico-para-aplicar-lean-kanban-en-de-vásquez-
málaga-cscp

SCRUM
¿QUE ES SCRUM?
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para
trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas
prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar
de equipos altamente productivos.
PRINCIPALES CARACTERISTICAS
Gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación,
retorno de inversión, mitigación de riesgos, por último, equipo motivado. Se hace uso de equipos
auto-dirigidos y auto-organizados. Se realiza a diario una reunión de Scrum, que es una reunión de
avance diaria que no dura más de 15 minutos con el objetivo de obtener realimentación sobre las
tareas del equipo y los obstáculos que se presentan.
ROLES EN SCRUM
1. Product Owner (dueño del producto): A veces es el mismo cliente. En otros casos,
especialmente cuando se trata de proyectos complejos, actúa como su representante directo, el de
los usuarios del producto y, en general, el de todas aquellas partes que tengan algún interés en él. Es
el único con la potestad para decidir las funcionalidades y características del producto. Tiene un
diálogo directo y permanente con el Scrum Máster, que es su nexo directo con quienes ejecutan las
labores. Sólo entra en contacto con el Scrum Team al final de cada una de las iteraciones para
evaluar las entregas parciales.
2. Scrum Máster (director o figura visible del proyecto): Es el encargado de garantizar que el
proceso cumplirá con las directrices del modelo Scrum. Muchos lo denominan líder de proyecto,
pero en realidad es mucho más que eso. Es el encargado de mantener una visión global del mismo y
de emplearse a fondo ante cualquier circunstancia, sea la que sea. Además, fluctúa entre el plano
práctico y el plano directivo; es decir, interactúa de igual manera con el Product Owner y con los
integrantes del Scrum Team que están a su cargo.
3. Scrum Team (equipo de trabajo): Hace referencia al grupo de personas que ejecuta las tareas
propuestas. Aquí entran tanto los arquitectos, ingenieros, programadores, diseñadores y demás
profesionales como las personas que realizan labores administrativas. Es posible que dentro del
Scrum Team surja algún líder o primer responsable; cuando no es así, esta labor la asume el Scrum
Máster . En cualquier caso, es importante que sus integrantes definan los roles de equipo. Su
relación con el Product Owner se reduce a la presentación de los resultados de cada iteración.
ROLES AUXILIARES
Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no se
involucran frecuentemente en el "proceso Scrum", sin embargo, deben ser tomados en cuenta. Un
aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los
usuarios, expertos del negocio y otros interesados ("stakeholders"). Es importante que esa gente
participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear
cada sprint
1.Stakeholders (Clientes, Proveedores, Vendedores, etc): Son las personas que hacen posible el
proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su desarrollo. Sólo
participan directamente durante las revisiones del "sprint".
2.Administradores (Managers): Son los responsables de establecer el entorno para el desarrollo
del proyecto.
HITOS DEL SCRUM
Los hitos son una serie de etapas dentro de un mismo proyecto, provienen de la gestión de
proyectos en cascada, son una forma de conocer el avance del proyecto sin estar familiarizado con
el mismo y simbolizan el haber conseguido un logro importante en el proyecto.
¿QUÉ ES UN SPRINT?
Sprint es un contenedor para el resto de eventos de Scrum. El Sprint es continuo, es decir, su
duración no debe cambiar mientras está en marcha el desarrollo del producto, y se puede interpretar
como una medida de ritmo constante a lo largo del tiempo, permitiéndonos reducir complejidad y
comparar resultados a lo largo de diferentes Sprints. El Sprint permite la transparencia, así como
inspeccionar y adaptar los otros eventos de Scrum.
1ª ceremonia: Sprint Planning: El Sprint Planning es una reunión que se realiza al comienzo de
cada Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el Backlog del
Producto (Product Backlog ) y que el equipo de desarrollo seleccione los Product Backlog Items en
los que va a trabajar durante el siguiente Sprint.
2ª ceremonia: Daily Scrum: El Daily Scrum, conocido comúnmente sólo como “La Daily”, es una
reunión diaria de 15 minutos en la que participa exclusivamente el Development Team.
3ª ceremonia: Sprint Review: El Sprint Review es la reunión que ocurre al final del Sprint,
generalmente el último viernes del Sprint, donde el product owner y el Develpment Team presentan
a los stakeholders el incremento terminado para su inspección y adaptación correspondientes.
4ª ceremonia: Sprint Retrospective: La retrospectiva ocurre al final del Sprint, justo después del
Sprint Review. En algunos casos y por comodidad de los equipos, se realiza conjuntamente con el
Sprint Planning, siendo la retrospectiva la parte inicial de la reunión.El objetivo de la retrospectiva
es hacer de reflexión sobre el último Sprint e identificar posibles mejoras para el próximo.
5ª ceremonia: Sprint Grooming o Refinement: El refinamiento del Product Backlog es una
práctica recomendada para asegurar que éste siempre esté preparado. Esta ceremonia sigue un
patrón similar al resto y tiene una agenda fija específica en cada Sprint. Se estima su duración en 2
horas máximo por semana del Sprint. Es responsabilidad del product owner agendar, gestionar y
dirigir esta reunión.
DOCUMENTOS
El product backlog se trata como un documento de alto nivel para todo el proyecto.
El sprint backlog es el subconjunto de requisitos que serán desarrollados durante el siguiente
sprint.
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el
Backlog del proyecto pendientes al comienzo de cada Sprint.
EQUIPO AUTO-ORGANIZADO
El Manifiesto Ágil incluye los equipos auto-organizadores como uno de los elementos clave de los
equipos Agiles. La capacidad de un equipo de auto-organizarse es fundamental, pero no debe mal
interpretarse, y debe siempre entenderse entorno a los objetivos que debe alcanzar el equipo.
¿Qué es el Producto Mínimo Viable (MVP)?
El producto mínimo viable es aquel que nos permite lanzar el producto con el mínimo de funciones
posible para que podamos aprender información relevante de su lanzamiento y uso de los usuarios
mediante una serie de métricas.

BIBLIOGRAFIA

 https://proyectosagiles.org/que-es-scrum/
 https://www2.deloitte.com/es/es/pages/technology/articles/ceremonias-scrum.html
 http://scrum.menzinsky.com/2017/10/como-planificar-utilizando-hitos-en.html
 https://proyectosagiles.org/2010/09/26/ejemplo-tablero-pizarra-tareas-scrum-taskboard/
 https://www.emprenderalia.com/que-es-el-mvp-producto-viable-minimo/