M ETODOLOGÍAS

DE DESARROLLO DE
SOFTWARE

Guía completa para la

adopción de buenas prácticas
de desarrollo de software

Mg. DANNY LÉVANO RODRIGUEZ

1
2
 Resumen

El presente libro está elaborado con la finalidad de que les

sirva como guía para el curso de Ingeniería de Software I,
el capítulo I presenta una introducción a la Ingeniería de
Software, el capítulo II habla presenta el OpenUP una
metodología agile basada en RUP, el capítulo III muestra
la Scrum, una de las metodologías ágiles más reconocidas
y aplicadas en el mundo, dentro del contexto del
desarrollo de software y el Capitulo IV, muestra también
las prácticas que aplica la metodología Kanban y el
capítulo 5 presenta las prácticas de ágiles según extreme
programming.

3
4
INDICE

CAPITULO I: INTRODUCCIÓN A LA INGENIERÍA DE

SOFTWARE ................................................................. 7
Evolución del software .................................................. 9
Caracteristicas del software ......................................... 11
Mitos del software ...................................................... 11
Ciclo de vidal del software tradicional .......................... 12
Modelos de desarrollo de software .............................. 15
Principales metodologías de desarrollo en el mundo .... 17
Conclusiones y recomendaciones ................................. 19
CAPITULO II: METODOLOGÍA OPEN UP ..................... 21
Roles de OpenUP ......................................................... 22
Ciclo de vida del OpenUP ............................................. 27
CAPITULO III: METODOLOGÍA SCRUM ....................... 31
Metodologías tradicionales vs las metodologías ágiles . 31
Metodologías ágiles ..................................................... 33
¿Qué es Scrum? ........................................................... 36
Filosofía de Scrum ....................................................... 37
Proceso de ciclo de vida de Scrum ................................ 38
Roles de Scrum ............................................................ 38
Artefactos en Scrum .................................................... 40
Ceremonias de Scrum .................................................. 43
CAPITULO IV: METODOLOGÍA KANBAN ..................... 55
¿Cómo funciona Kanbas? ............................................. 56
Cuáles son los beneficios Kanban ................................. 57
Tablero Kanban ........................................................... 57

5
CAPITULO V: METODOLOGÍA EXTREME
PROGRAMMING ....................................................... 59
PRINCIPIOS BÁSICOS .................................................... 60
REFERENCIAS ............................................................... 65

6
CAPITULO I: INTRODUCCIÓN
A LA INGENIERÍA DE
SOFTWARE

¿Qué es el software?

«El software no solo son programas de computadoras,

sino también son los programas adicionando los
documentos asociados y la configuración de los datos que
se necesitan para hacer que estos programas operen de
manera correcta». Sommerville

«Es el centro neurálgico de las organizaciones».

Roger Pressman

¿Qué es un proceso de software?

«Es un conjunto de actividades cuya meta es el desarrollo
o evolución del software»

7
¿Qué es un modelo de desarrollo de software?

Es una representación simplificada de un proceso del

software, presentada en forma amigable y comprensible
para un equipo de personas.
En la actualidad, en el 2015, existen distintos modelos de
desarrollo de software, algunos mas populares que otros,
cada uno de ellos proporcionan distintos beneficios, a
nivel de procesos, gestión de personas, métricas de gestión
y otros. La figura 1 muestra los modelos mas populares a
nivel internacional

Figura 1: Modelos de desarrollo de software más populares,

2015

8
¿Qué es la Ingeniería de software?

«Es una disciplina de la ingeniería que se enfoca en los

aspectos de la producción del software». Sommerville

«Estudio de los principios y metodologías para desarrollar

y mantener el software». Zelkowitz

«Es la aplicación práctica del conocimiento científico en

el diseño y construcción de programas de computador y la
documentación apropiada para desarrollarlos, operarlos y
mantenerlos». Boehm

Evolución del software

Etapa 1:
 Esfuerzo en el desarrollo de
Hardware
 Carencia de métodos de
desarrollo
 Software a la medida con
baja distribución

Etapa 2:

9
 Masificación de software
en empresas
 Software de gran
extensión
 Problemas de
mantenimiento
 Inicio de las casas de
software
 CRISIS DEL
SOFTWARE

Etapa 3:
 Hardware a bajo costo.
 Popularización de los
computadores personales.
 Grandes inversiones en
desarrollo de software.

Etapa 4:
 Incremento de la demanda de software.
 Se agudiza la crisis del software: mantenimiento.

Etapa 5
 Mejora de los procesos en la producción del software
 Búsqueda de la calidad del software

10
Características del software
El software es un producto intangible:
Se desarrolla no se fabrica:
◦ No es un producto estático
◦ Debe ser flexible para aceptar modificaciones
Se deteriora
◦ Por la labor de mantenimiento
◦ Aparición de nuevas tecnologías
Se desarrolla a la medida
◦ La mayoría de las veces se desarrolla de
acuerdo a las necesidades particulares de los
clientes
◦ Aunque ya existen algunas empresas de
software que desarrollan aplicaciones
genéricas

Mitos del software

Mitos de Gestión:
◦ Siempre lo hemos hecho así y funciona bien:
resistencia al cambio
Mitos del Cliente:
◦ El software lo hará TODO
◦ Hay cosas que no hay que decir, el analista
debe suponerlas
◦ Los detalles se dejan para el final
Mitos de Desarrolladores:

11
 ◦ Los métodos no sirven
◦ Lo único importante es el código
◦ El proyecto termina con el desarrollo del
software (…y la documentación y el
mantenimiento qué ?)

Ciclo de vida del software tradicional

El sistema inicialmente puede ser desconocido para el
analista, y hasta difícil de comprender. Por eso es
necesario tener un buen contacto con el usuario, quien
aunque conozca más y mejor el sistema, posiblemente no
tenga del todo claro sus conceptos. Es función del analista
obtener la información del usuario de una forma clara para
poder desarrollar la solución esperada. La ingeniería de
software ofrece a los analistas, metodologías que
permiten, paso a paso, o mejor, fase a fase, que el analista
se apropie del sistema, al punto que tiene el conocimiento
suficiente para modificar positivamente el sistema.

Las fases comunes a las metodologías son las presentadas:

definición, análisis, diseño, desarrollo, pruebas y
mantenimiento. Las flechas de cada fase indican el grado
de participación del analista(s) y el usuario(s). En
cualquier fase puede ser necesario la ayuda del usuario,
normalmente por una captura deficiente de los
requerimientos que se hace evidente al entrar en el detalle
necesario cada que se avanza en el proyecto.

La figura 2, muestra las etapas del ciclo de vida de

desarrollo de software tradicional.

12
 Sistema Abstracto para el
analista....y posiblemente
para el usuario!

Conocedor del
sistema...aún
cuando no lo Usuario
tenga muy claro Analista
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenimiento

Figura 2: Ciclo de vida tradicional de desarrollo de

software

De la figura 2, se puede identificar que:

Fase 1: Definición = conocer

◦ Estar en contacto constante con el cliente
◦ Establecer los requisitos
◦ Definir el problema
◦ Determinar los límites y su interacción con el
entorno
◦ Es junto con el análisis la fase más importante

Fase 2: Análisis = entender

◦ Objetivo del Software
◦ ¿Para qué el software?
◦ Procesos del sistema
◦ ¿Qué será resuelto?
◦ Contacto constante con el cliente

13
Fase 3: Diseño = “solucionar”
◦ “La fase de diseño marca una transición desde
la descripción de cómo debe lucir la solución
(especificaciones) hacia cómo será resuelto el
problema” von Mayrhauser.
◦ Solución planteada, comúnmente en la
actualidad, con el Paradigma Orientado a
Objetos
“Diseño: traza o delineación de un edificio o una
figura”. RAE. La IS es un arte.

La solución no se obtiene de ese recetario que es

el método. La solución es un planteamiento del
analista, construido gracias al conocimiento
adquirido con ayuda, ahora sí, del método. La IS
es una ciencia.

Fase 4: Desarrollar la solución

◦ Traducir el diseño al código
◦ También se utiliza el paradigma orientado a
objetos.

Fase 5: Pruebas = nada es perfecto

◦ Verificar el funcionamiento del sistema
desarrollado.
◦ Corregir los errores encontrados.
◦ Hacer mejoras con base en la apreciación del
cliente
Fase 6: Mantenimiento = NADA ES PERFECTO

14
 ◦ Corregir errores no hallados en la fase de
pruebas.
◦ Mejoras propuestas por el cliente.
◦ Nuevas funciones (cliente o analista).
◦ Revisión del funcionamiento.

Modelos de desarrollo de software

Las metodologías tradicionales

Las metodologías tradicionales de desarrollo de software
son orientadas por planeación. Inician el desarrollo
de un proyecto con un riguroso proceso de
elicitación de requerimientos, previo a etapas de
análisis y diseño. Con esto tratan de asegurar
resultados con alta calidad circunscritos a un
calendario.

En las metodologías tradicionales se concibe un solo

proyecto, de grandes dimensiones y estructura definida; se
sigue un proceso secuencial en una sola dirección y sin
marcha atrás; el proceso es rígido y no cambia; los
requerimientos son acordados de una vez y para todo el
proyecto, demandando grandes plazos de planeación
previa y poca comunicación con el cliente.

Las metodologías agiles

Las metodologías ágiles son flexibles, pueden ser
modificadas para que se ajusten a la realidad de cada
equipo y proyecto.

15
Los proyectos ágiles se subdividen en proyectos más
pequeños mediante una lista ordenada de características.
Cada proyecto es tratado de manera independiente y
desarrolla un subconjunto de características durante un
periodo de tiempo corto, de entre dos y seis semanas. La
comunicación con el cliente es constante al punto de
requerir un representante de él durante el desarrollo.

Los proyectos son altamente colaborativos y se adaptan

mejor a los cambios; de hecho, el cambio en los
requerimientos es una característica esperada y deseada,
al igual que las entregas constantes al cliente y la
retroalimentación por parte de él. Tanto el producto como
el proceso son mejorados frecuentemente.

Metodologías Tradicionales Metodologías ágiles

1. Predictivos 1. Adaptativos
2. Orientado a procesos 2. Orientado a personas
rígidos 3. Proceso Flexible
3. Se concibe como un 4. Un proyecto es subdividido
proyecto en proyectos mas pequeños
4. Poca comunicación con el 5. Comunicación constante
cliente con el cliente
5. Entrega de Software al 6. Entrega Constantes de
finalizar el desarrollo software.
6. Documentación extensa 7. Poca Documentación

Tabla 1: Metodologías tradicionales vs metodologías agiles

16
Principales metodologías de desarrollo en el
mundo

Figura 3: modelo Swebok

Figura 4: modelo RUP

17
Figura 5: Extreme Programming

Figura 6: Metodología Scrum

18
Conclusiones y recomendaciones

El SW es actualmente un elemento de vital importancia

para la humanidad.

El SW esta por doquier: dispositivos móviles,

electrodomésticos, etc Dada esta importancia es
paradójico que aún los enfoques metodológicos no hayan
penetrado suficientemente en el desarrollo.

Es imperativo que los estudiantes de ingeniería de

sistemas y ciencias afines entiendan la importancias de
estos enfoques, para garantizar el futuro de las empresas
de software.

19
20
CAPITULO II: METODOLOGÍA
OPEN UP

Guía para procesos de desarrollo de software basada en

RUP, guía orientada a desarrollo de proyectos de software
agiles, guía desarrollada por Scott Ambler y Eclipse. Guía
de desarrollo de software orientada al desarrollo iterativo
– incremental.

Figura 7: Modelo incremental OpenUP

21
Roles de OpenUP
Rol es un conjunto de actividades que desempeña 1 o mas
personas del equipo de desarrollo.
1 persona puede desempeñar 1 o mas roles dentro del
desarrollo de software.
Dentro del Open UP representa a una persona que tendrá
parte dentro del desarrollo de software.

Figura 8: interacción de roles de OpenUP

Analista

Es la persona que tiene como responsabilidad la

identificación de los problemas a resolver y definir cuales
serán las caracteristicas del software, la figura 9 muestra
las principales tareas y entregables del analista.

22
 Figura 9: tareas y entregrables del analista

Arquitecto
Este rol es responsable de definir cual será la arquitectura
de software que se utilizará para la solución técnica del
software y para el futuro mantenimiento del software. Las
principales tareas y entregables de este rol están
presentadas en la figura 10.

Figura 10: tareas y entregrables del arquitecto

Desarrollador
Este rol es responsable para el desarrollo de las partes del
software, incluyendo la cordinación del diseño de la
arquitectura, el prototipo de la interfaz con el usuario y la
implementación e integración de los componentes de las
partes de la solución, la figura 11, presenta las principales
tareas y entregables del desarrollador.

23
 Figura 11: tareas y entregrables del desarrollador

Administrador del proyecto

También conocido como director de Proyecto, es el
encargado de realizar la planificación del proyecto,
cordinar las iteraciones con los stakeholders y establecer
el alcance, tiempo y costos del proyecto; asi mismo
controlarlo y reducir los riesgos del proyecto. En la figura
12 se puede ver las principales tareas y entregables del
gestor del proyecto.

Figura 12: tareas y entregrables del director de proyecto

Stakeholder
Es representada por el Lider de usuarios de la
organización, no cumple ninguna actividad dentro del
desarrollo de software, solo el de proporcionar la
información requerida para el desarrollo del proyecto. Su
principal tarea es el de proporcionar información de los
proceso de la organización al equipo de desarrollo.

24
Testeador
Este rol es responsable para el cumplimiento de
actividades mediante las pruebas. Sus actividades incluye
la identificación, definición, implementación y
conducción necesarias de las pruebas, estas pruebas
devuelven un analisis de resultados. La figura 13 presenta
las principales tareas y entregables del testeador.

Figura 13: tareas y entregrables del testeador

Any Role
El OpenUP deja libre la posibilidad de establecer un rol
adicional en el proceso de desarrollo de software este rol
adicional se agregará dependiendo de exclusividad del un
proyecto de software.

Figura 13: Tarea del Any Role

25
Diciplinas
Es una colección de tareas desarrolladas concerniente a la
fase del proyecto.
Es un grupo de actividades que satisfacen el cumplimiento
o logro de los objetivos del proyecto.
Conjunto de actividades que muestran la interrelación
entre: Rol – Rol, Rol - tarea y Tarea – entregable.

Arquitectura
En esta disciplina se desarrolla los documentos necesarios
para establecer la arquitectura de software que se utilizara
para dar solución al proyecto y para establecer la
estructura del software.

Arquitectura
Esta disciplina establece el control de los cambios en los
artefactos y la sincronización de desarrollo del software.
Establece las normativas para el control de versiones del
software

Desarrollo
Esta disciplina establece las actividades para el diseño y
la implementación de la solución.
Se documenta los avances de la documentación para
actualizar la estructura del software.

Administrador de Proyecto
En esta disciplina se determinan y establece la
planificación del proyecto.
Se establecen los objetivos y documentos de control.
Se detalla la lista de identificación de riesgos del proyecto.

26
Requerimientos
Se documenta el resultado del conjunto de actividades
referentes a la identificación del problema a resolver, de
las características del proyecto, y el modelo de caso de uso
del proyecto.

Pruebas
Se documenta los casos de prueba a la solución del
software. Se realiza las pruebas a los distintos módulos del
software. Se establece las Scripts de pruebas a utilizar.

Ciclo de vida del OpenUP

El ciclo de vida es la estructuración de las actividades en
etapas para el desarrollo de software. Se basa en el ciclo
de vida del software que establece RUP.
Esta compuesta por cuatro partes:
 Inception (inicio)
 Elaboration (Elaboración)
 Construction (Construcción)
 Transition (Implantación)

El ciclo de vida del software que propone OpenUp

establece un conjunto de entregables al finalizar cada fase,
como se puede ver en la figura 14.

27
 Figura 14: fases del OpenUP
Fase de Inicio

Figura 15: Secuencia de actividades del la fase de inicio

28
Fase de Elaboración

Figura 16: Secuencia de actividades del la fase de elaboración

Fase de construcción

Figura 17: Secuencia de actividades del la fase de construcción

29
Fase de transición

Figura 18: Secuencia de actividades del la fase de transición

Conclusión

El OpenUP es una guia básica para desarrollo de software.

Esta guía se puede adaptar a proyectos de software

pequeños y medianos

Es una metodología adaptable para pymes.

Es una metodología mas adaptable a la realidad de

construcción de software en nuestro Pais.

30
CAPITULO III: METODOLOGÍA
SCRUM

Metodologías tradicionales vs las

metodologías ágiles
Las metodologías tradicionales están basadas en 2
principales paradigmas, el Cowboy Coding y el desarrollo
de software en Cascada.

Cowboy Coding
Este paradigma estuvo orientada a un desarrollo caótico,
bajo el pensamiento “¡Hacerlo y Punto!”. Los equipos de
desarrollo se entraban enfrascados en la “ausencia de
reglas”, una comunicación ocasional, flexibilidad
indefinida con el cliente y nada de lecciones aprendidas.
Los pocos resultados positivos que se obtenían eran por 1
o 2 integrantes que se les conocía como “héroes del
equipo”

Waterfall
El waterfall o modelo en cascada, está enfocada en el
desarrollo de software por fases o etapas a través de una
correlación de actividades de tiempo, pasando de una
etapa a otra sin opción a retroceso de fase o etapa. como
se ve a continuación.
1 2 3 4 5

31
¿Pero que complicaciones hay con el modelo en cascada?,
la figura 19, muestra de que si en una de las etapas hemos
realizado una estimación fallido del tiempo, se verán
afectados otras etapas, o la fecha estimada de entrega del
producto.

Análisi Diseño Construcción Prueb Entreg

s as a

Análisi Diseño Construcción Prueb Entreg

s as a

Análisi Diseño Construcción Prueb Entreg

s as a

Figura 19: Efecto de los desfases del tiempo

Asimismo dentro del enfoque tradicional, a pesar que está

orientado una secuencia unidireccional, si exitiera la
necesidad de retroceder una etapa ya realizada, esta
generaría en el tiempo mayor esfuerzo y sobrecostos, la
figura 20, muestra el modelo en cascada rumbo al obejtivo
del procesos, que es el software, en la figura 21 se muestra
el efecto que generaría al realizar un reprocesos, si en la
fase de pruebas se identificaría un error crítico se tendría
que volver a realizar todas las fases o etapas del ciclo de
vida

Análisi Diseño Construcción Prueba Entreg

S
W

Figura 20: Ciclo de vida esperado en el modelo en cascada

32
 Análisis Diseño Construcción Pruebas Entrega

Análisis Análisis Análisis

Diseño Diseño

Construcc
ión
Figura 21: efecto de errores de uan fase identificados en fases
posteriores

Esto se da porque los supuestos en los que nos basamos

durante las etapas de análisis, Diseño y construcción son
validados recién en la etapa de Prueba.

¿Pero porque falla waterfall?, porque la exposición al

cliente es al final del ciclo de vida, el pago al equipo de
desarrollo son lentos y retardados, existe un aislamiento
entre etapas, la tasa de cambios nos es positiva y la
detección de errores es al final del proceso.

Metodologías ágiles
Las metodologías ágiles están basadas en 4 valores que
alinean los paradigmas del desarrollo de software.

Figura 22: valores ágiles

33
La figura 22 indica que el manifiesto ágil valora el
Software Funcionando por sobre documentación
detallada, Colaboración con el cliente Por Sobre la
negociación de contratos y la Respuesta a los cambios Por
sobre el seguimiento de un plan.

Asimismo estas se encuentran bajo 12 principios que son:

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,

34
 desarrolladores y usuarios debemos 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.
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.

Las metodologías ágiles a diferencia de las metodologías

tradicionales se enfocan en el desarrollo iterativo e
incremental como se muestra en la figura 23, esta evita los
problemas que muestra el modelo en cascada, ya que en
cada iteración hay un producto potencialmente entregable
para el cliente.

Análisis Diseño Construcción Pruebas Entrega

waterfall

Iteración 1 Iteración 2 Iteración N

Agile

Figura 23: modelo iterativo

35
Asimismo las metodologías ágiles entregan los siguiente
resultados:
 Entregas frecuentes
 Priorización de requerimientos
 Valor al final de cada sprint
 Al detener un proyecto
o El mayor valor fue entregado
 Cancelación de proyecto
o Los req. más críticos entregados
 Test durante cada iteración
 Resolución temprana de bugs críticos
 Proyecto cancelado
o Funcionalidad probada
o Lista para ser entregada
 Transparencia y visibilidad a través del uso de los:
o TaskBoard
o Daily Standup Meeting
o Burn Down Charts
o Retrospectivas

¿Qué es Scrum?
Scrum más que una metodología es un framework (marco
de trabajo) para la gestión de proyectos complejos. Se
basa principalmente en la premisa de ejecutar un proyecto
en iteraciones de entre dos y cuatro semanas, llamadas
Sprints, y de duración fija (timebox).

36
Filosofía de Scrum
Tratar de predecir fechas, esfuerzo y alcance en el
desarrollo del producto con absoluta precisión es
imposible.
El negocio varía mucho durante la ejecución de este tipo
de proyectos
Comienza con una hoja de ruta, estimaciones de alto nivel
y fechas aproximadas.
Revisar y adaptar continuamente estos planes.
Crear compromisos de corto plazo&alcance fijo (sprint)
Antes de cada iteración se define el alcance y los detalles
basados en resultados de sprint anteriores y
requerimientos cambiantes
Durante la iteración, el equipo se encuentra 100%
concentrado en entregar un producto completamente
funcionando, potencialmente entregable
Las interrupciones son evitadas
Al final de cada iteración, el producto resultante es
evaluado
El equipo evalúa el trabajo realizado durante la iteración
y se implementan mejoras en cada iteración

37
Proceso de ciclo de vida de Scrum

Figura 24: Ciclo de vida de scrum

Roles de Scrum
Scrum divide los roles a nivel de 2 enfoques, los
“comprometidos” el Product Owner, Scrum Master y los
miembros del equipo, y los “involucrados” el stakeholder.

Cada rol en Scrum tiene sus respectivas responsabilidades

y funciones, como se muestra a continuación:

El product Owner
o Responsable por la visión del producto
o Conoce los detallers de Epics, Features, user
stories.
o Gerencia el backlog

38
 o Determina prioridades basado en el valor de
negocio
o Redefine prioridades entre sprint
o Acepta o rechaza características del producto
luego de cada iteración
o Da Feedback
o Representa al cliente

El Scrum Master
o Responsable por el proceso que sigue el equipo
o Reafirma los valores y principios Scrum
o Asegura las reuniones o ceremonias
o Impide interrupciones externas al equipo
o Remueve impedimentos
o Asegura la fuerte colaboración dentro del equipo
o Promueve la auto-organización
o Asegura que el equipo sea funcional

El equipo
o Compuesto por todos los miembros del equipo
o Responsable por el desarrollo del producto
o Auto-organizado
o Con funciones cruzadas
o Provee estimaciones para cada user story
o Se compromete en cada sprint planning a convertir
una cierta cantidad del Product backlog en
producto potencialmente entregable

39
Artefactos en Scrum

User Stories
o Breve Descripción de funcionalidad, contada
desde la perspectiva del usuario
o Propósito
o Oportunidad para estimar
o No limitado a la UI
o Escrita por el cliente
o Qué debería hacer el sistema
o En términos del negocio
 Sin tecnicismos
o Criterios de aceptación
o Pruebas de aceptación
 Si se pueden automatizar: mucho
mejor
o Uno o más para comprobar cada historia
o Diferenciación de los requerimientos
tradicionales:
o Nivel de detalle
o Centradas en el usuario
 Evitar diseño de la interfaz de
usuario
 Evitar diseños específicos de
tecnología
 Evitar el diseño de base de datos
 Evitar algoritmos

40
El user story es una tarjeta que indica los requerimientos
y los criterios de aceptación del cliente

Reglas de
negocio

Figura 25: Modelo de User Story

Figura 26: Modelo de User Story

41
Release Plan
el release plan, es un artefacto que establece los
requerimientos a entregar en una iteración.
o Establece fecha de releases de alto nivel y
features/stories en cada release.
o Puede estar alineado con hitos externos
o Determina la priorización de los items del Backlog
o El product Owner es responsable de construirlo

Figura 27: Release planning

Product Backlog
El producto backlog es la representación de la lista de
requerimientos por cumplir para alcanzar los objetivos del
producto de software.
● Lista de items del Backlog que representa todo el
trabajo que se realizará en un futuro predecible.

42
 ● Los items del Backlog pueden ser:
● EPICS (Requerimientos de alto nivel)
● FEATURES (Requerimientos
Intermedios)
● USER STORIES (Requerimientos de bajo
nivel)

Figura 28: Product backlog

Ceremonias de Scrum

● Un Sprint tiene una duración fija, time-boxed,

iteración durante la cual el equipo se concentra en
entregar el Incremento del producto basado en el
Backlog Comprometido
● El objetivo y trabajo involucrado en un Sprint
también es fijo, como el time-box. Una vez que
comienza, no hay lugar para cambios en el
alcance.

43
 ● Durante un Sprint, el Quipo y solo el equipo el
100% Responsable por el incremento del
producto.
● El Scrum Master elimina los impedimentos y
preserva al equipo de interrupciones externas.
● El Sprints sucede uno tras otro. Puede haber
pausas entre Sprint
● Puede durar de 2 a 4 semanas

Sprint planning
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 del Sprint.

Esta reunión de planificación habitualmente se divide en

dos partes con finalidades diferentes: una primera parte
estratégica y enfocada en el “qué”, y una segunda parte
táctica cuyo hilo conductor principal es el “cómo”.

Parte estratégica: ¿qué vamos a hacer?

Podríamos decir que se trata de un taller donde el

Product Owner expone todos y cada uno de los PBIs que
podrían formar parte del Sprint, mientras que el equipo
de desarrollo realiza todas las preguntas que crea
necesarias para conocer sus detalles y así corroborar o
ajustar sus estimaciones.

Aún asumiendo que los PBIs ya han sido estimados con

anterioridad27, debido al principio de “aceptar los
cambios aun en etapas avanzadas del proyecto”, es posible

44
que en esta reunión aparezcan PBIs que no habían sido
estimados anteriormente. Frente a esta situación, el equipo
de desarrollo indagará y estimará esos PBIs de inmediato.

El objetivo buscado durante esta parte de la reunión es

identificar “qué” es lo que el equipo de desarrollo va a
realizar durante el Sprint, es decir, todos aquellos PBIs
que el equipo se comprometerá a transformar en un
producto funcionando y utilizable o en otras palabras:
incremento funcional potencialmente entregable.

El Product Owner y el equipo de desarrollo deben

participar de esta parte de la reunión como protagonistas
principales. El ScrumMaster, al tiempo que facilita la
reunión, también debe asegurar que cualquier stakeholder
del proyecto que sea requerido para profundizar en
detalles esté presente o sea contactado.

El equipo de desarrollo utiliza su capacidad productiva

(también conocida como Velocidad o Velocity), obtenida
de los Sprints pasados, para conocer hasta cuánto trabajo
podría comprometerse a realizar. Esto determinaría en un
principio cuáles serían los PBIs comprometidos en este
Sprint.

Como se ha visto, hemos hablado en potencial: el equipo

de desarrollo “podría”, esto “determinaría”. La razón es
que cada uno de los ítems del Product Backlog debe ser
discutido para entender cuáles son sus criterios de
aceptación y así conocer en detalle qué se esperará de cada
uno. De esta manera, el equipo de desarrollo discutirá con
el Product Owner sobre cada PBI y generará un

45
compromiso de entrega para aquellos que considera
suficientemente claros como para comenzar a trabajar y
que además podrían formar parte del alcance del Sprint
que está comenzado. A esto se lo conoce como
planificación basada en compromisos o Commitment-
based Planning.

Al finalizar esta primera parte de la reunión, tanto el

Product Owner como los stakeholders involucrados (si
los hubiese) se retirarán, dejando así al ScrumMaster y al
equipo de desarrollo para que den comienzo a la segunda
parte de esta reunión, que se describe a continuación.

Parte táctica: ¿cómo lo vamos a hacer?

Durante este espacio de tiempo el equipo de desarrollo

determinará la forma en la que llevará adelante el trabajo.
Esto implica la definición inicial de un diseño de alto
nivel, el cual será refinado durante el Sprint mismo y la
identificación de las actividades que el equipo en su
conjunto tendrá que llevar a cabo.

Se espera que el diseño sea emergente, es decir, que surja

de la necesidad del equipo de desarrollo a medida que éste
avance en el conocimiento del negocio. Por esta misma
razón es que indicamos la no necesidad de realizar un
diseño completo y acabado de lo que será realizado
durante el Sprint. En cambio, se buscará un acuerdo de
alto nivel que será bajado a detalle durante la ejecución de
la iteración.

46
Esto mismo sucede con las actividades del Sprint, es decir
que no es estrictamente necesario enumerar por completo
todas las actividades que serán realizadas durante la
iteración ya que muchas aparecerán a medida que
avancemos. Recordemos que a esta altura los PBIs ya han
sido estimados y el surgimiento de actividades durante el
Sprint no habilita a incrementar las estimaciones de los
PBIs, salvo excepciones donde la estimación inicial no
había considerado la totalidad del esfuerzo necesario.
Adicionalmente, es recomendable que las actividades
duren idealmente menos de un día. Esto permitirá detectar
bloqueos o retrasos durante las reuniones diarias (ver
siguiente).

Si bien el Product Owner no participa de esta reunión,

debería ser contactado en el caso de que el equipo de
desarrollo necesite respuestas a nuevas preguntas con la
finalidad de clarificar su entendimiento de las
necesidades.
Al finalizar esta reunión, el equipo habrá arribado a un
Sprint Backlog o Commited Backlog que representa el
alcance del Sprint en cuestión. Este Sprint Backlog es el
que se coloca en el taskboard (pizarra de actividades) del
equipo. Se dará comienzo al desarrollo del productopara
este Sprint.

● Son reuniones que se realizan antes de cada

Sprint
● Dura 4 horas y se divide en 2:
● Discusión del «que»: 2 horas
● PO, SM, Equipo
● Discusión del «Como»: 2 horas

47
Daily standup meeting
Uno de los beneficios de Scrum está dado por el
incremento de la comunicación dentro del equipo de
proyecto. Esto facilita la coordinación de acciones entre
los miembros del equipo de desarrollo y el conocimiento
“en vivo” de las dependencias de las actividades que
realizan.

Por otro lado, se requiere además aumentar y explicitar los

compromisos asumidos entre los miembros del equipo de
desarrollo y dar visibilidad a los impedimentos que surjan
del trabajo qu está siendo realizando y que muchas veces
nos impiden lograr los objetivos. Estos tres objetivos: 1)
incrementar la comunicación 2) explicitar los
compromisos y 3) dar visibilidad a los impedimentos, son
logrados mediante las reuniones diarias o Daily Standup
Meetings. Estas reuniones tienen, como su nombre lo
indica, una frecuencia diaria y no deberían llevar más de
15 minutos. Estos 15 minutos son un timebox, es decir,
que no se pueden superar.

A la reunión diaria acude el ScrumMaster y el equipo de

trabajo. En el caso de que sea necesario, se podrá requerir
la presencia del Product Owner y de los stakeholders. De
todas maneras, se intenta que sea una reunión abierta
donde cualquier interesado en escuchar lo que sucede
pueda participar en calidad de observador. Se recomienda
que los observadores no participen activamente en la
reunión, y mucho menos, que soliciten a los miembros del
equipo justificación del progreso y explicación de los
problemas.

48
Esta reunión es facilitada por el ScrumMaster. Todos y
cada uno de los miembros toman turnos para responder las
siguientes tres preguntas, y de esa manera comunicarse
entre ellos:

1. ¿Qué hice desde la última reunión diaria hasta ahora?

2. ¿En qué voy a estar trabajando desde ahora hasta la

próxima reunión diaria?

3. ¿Qué problemas o impedimentos tengo?

Es importante destacar que en ningún momento se trata de

una reunión de reporte de avance o status al ScrumMaster
ni a otras personas. Por el contrario, es un espacio de
estricta comunicación entre los miembros del equipo de
desarrollo.

El objetivo de la primera pregunta (¿qué hice...?) es

verificar el cumplimiento de los compromisos contraídos
por los miembros del equipo en función del cumplimiento
del objetivo del Sprint. La finalidad de la segunda
pregunta (¿qué voy a hacer...?) es generar nuevos
compromisos hacia el futuro. Cuando hablamos de
compromisos, hacemos referencia a aquéllos que los los
miembros del equipo asumen ante sus compañeros.

La última pregunta (¿qué problemas...?) apunta a detectar

y dar visibilidad a los impedimentos. Estos impedimentos
no se resuelven en esta reunión, sino en posteriores. Es
responsabilidad del ScrumMaster que se resuelvan lo

49
antes posible, generando las reuniones que sean necesarias
e involucrando a las personas correctas.

En el caso de que los PBIs del Sprint se hubiesen podido

dividir en actividades de menos de un día: si una de estas
actividades se encuentra en progreso durante dos
reuniones diarias seguidas (con 24hs de separación)
claramente se advierte un retraso.

● Se realizan 15 Minutos al día

● Se debe realizar al mismo tiempo + mismo lugar
● Es importante la participación de todo el equipo
● Preguntas que se discuten son:
● Que se hizo ayer?
● Que hará Hoy?
● Hay impedimentos para el trabajo?

Review meeting
Al finalizar cada Sprint se realiza una reunión de revisión
(review/demo) del incremento funcional potencialmente
entregable construido por el equipo de desarrollo (el
“qué”). En esta reunión el equipo expondrá el resultado
del Sprint frente al Product Owner. Cuando decimos
“resultado” hablamos de “producto utilizable” y
“potencialmente entregable” que el Product Owner
utilizará y evaluará durante esta misma reunión,
aceptando o rechazando así las funcionalidades
construidas.

El Product Owner evalúa en tiempo real las

funcionalidades construidas y provee su feedback.

50
Los stakeholders del proyecto también pueden participar
en esta reunión para aportar sus impresiones, que pueden
ser acerca de cambios en la funcionalidad construida o
bien nuevas funcionalidades que surjan de ver el producto
en acción.

Toda la retroalimentación que el Product Owner y los

stakeholders aporten debe ser ingresada como PBIs en el
Product Backlog. Para esto, los PBIs nuevos deben ser
priorizados con respecto a todos los ya existentes en el
Product Backlog. También es necesario que estos nuevos
PBIs sean estimados antes de incluirlos como parte del
Product Backlog ya que el Product Owner deberá decidir
cuáles de los PBIs existentes cuya estimación de costo es
similar a la de los nuevos PBIs deben ser eliminados para
no incurrir en el incremento desmedido del alcance (Scope
Creeping): si se agrega trabajo entonces debemos quitar
trabajo de otro lado. El Product Owner cuenta para esto
con la priorización de los ítems del Backlog como
herramienta para la toma de este tipo de decisiones.

En el caso de que una funcionalidad sea rechazada, el PBI

correspondiente reingresa al Product Backlog con máxima
prioridad, para ser tratado en el siguiente Sprint. La única
excepción a esta regla es que el Product Owner, por
decisión propia, prefiera dar mayor prioridad a otros. En
este caso, nada debe salir del Backlog ya que esto no sería
considerado como un incremento en el alcance.

Al finalizar la revisión del producto, es recomendable

definir la fecha de la próxima reunión de revisión, que

51
corresponderá al final del Sprint siguiente. De este modo
ya se tendrán las agendas bloqueadas a tal fin.
● Se realiza una reunión al final de cada Sprint
● El equipo muestra el producto potencialmente
entregable que construyeron recientemente en el
ultimo Sprint.
● El Product Owner acepta o rechaza funcionalidad
● El Producto Owner verifica la realización del
Backlog acordado.

Retrospectiva
En un método empírico como Scrum, la retrospección del
equipo es el corazón de la mejora continua. Mediante el
mecanismo de retrospección, el equipo reflexiona sobre la
forma en la que realizó su trabajo y los acontecimientos
que sucedieron en el Sprint que acaba de concluir para
mejorar sus prácticas. Todo esto sucede durante la reunión
de retrospectiva.

Esta reunión tiene lugar inmediatamente después de la

reunión de revisión. Mientras que la reunión de revisión
se destina a revisar el producto (el “qué”), la retrospectiva
se centra en el proceso (el “cómo”).
Este tipo de actividad necesita un ambiente seguro donde
el equipo de desarrollo pueda expresarse libremente, sin
censura ni temores, por lo cual se restringe solo al equipo
de desarrollo y al ScrumMaster. En el caso de que se
requiera la participación del Product Owner, stakeholders
o gerentes, estos podrán ser convocados.

Valiéndose de técnicas de facilitación y análisis de causas

raíces, se buscan tanto fortalezas como oportunidades de

52
mejora. Luego, el equipo de desarrollo decide por
consenso cuáles serán las acciones de mejora a llevar a
cabo el el siguiente Sprint. Estas acciones y sus impactos
se revisarán en la próxima reunión de retrospectiva.

● Reunión realizada luego de la Review

● Generalmente de 3 a 4 horas time-box
● Consiste en una revisión en cómo se hizo el
trabajo en el sprint anterior. Se revisa el proceso
● Facilitado por el Scrum Master. Hecho por el
equipo
● Centrada en la identificación de:
● ¿Qué funcionó bien?
● ¿Qué no funcionó?

53
54
CAPITULO IV: METODOLOGÍA
KANBAN
Kanban es un conjunto de buenas prácticas que permite
visualizar el flujo de trabajo del proceso de desarrollo de
software.

Kanban divide el trabajo en bloques, escribe cada

elemento en una tarjeta y ponlo en el muro.

Utiliza columnas con nombre para ilustrar dónde está cada

elemento en el flujo de trabajo.

Limita el WIP (Work in Progress, trabajo en curso) -

asigna límites concretos a cuántos elementos pueden estar
en progreso en cada estado del flujo de trabajo.

Mide el lead time (tiempo medio para completar un

elemento, a veces llamado "tiempo de ciclo"), optimiza el
proceso para que el lead time sea tan pequeño y predecible
como sea posible.

Figura 29: tablero Kanban

55
¿Cómo funciona Kanbas?
Existe una serie de principios básicos con el fin de obtener
el máximo rendimiento de su flujo de trabajo.

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 metodologia Kanban. Realice
un seguimiento de su tiempo de forma contínua 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.

56
Cuáles son los beneficios 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
tiempo dedicado a la asignación de tareas. Usted
selecciona sus tareas, por tanto no tendrá que esperar a que
la tarea vaya hacia usted.

Tablero Kanban
El tablero Kanban impulsado por Kanban Tool le permite
asignar tareas a los miembros del equipo, adjuntar

57
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, podrá charlar más en los
descansos para el café. 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.

El hecho de dar pequeños pasos mientras se está

trabajando también contribuye a una mejor prioridad de
tareas – todos los trabajos parecen urgentes en cuanto a
volumen, pero cuando se descomponen en piezas más
pequeñas- usted ve con claridad lo que se necesita hacer
en primer lugar. Es útil para hacer que las tareas sean más
manejables, con sólo limitar la cantidad de trabajo en
curso a una o dos tareas por persona. De esta forma queda
mucho más claro quién está haciendo qué exactamente.

Luego de que el trabajo está hecho, usted puede analizar

el flujo de trabajo mediante el uso el análisis de gráficos y
Kanban. La función de Seguimiento de Tiempo de
Kanban Tool no deja sitio a la estimación acerca de cuánto
tiempo llevó hacer las cosas.
Realmente no existen mejores formas de mejorar su forma
de trabajo. Utilice la metodología Kanban y reduzca el
tiempo perdido en las caóticas discusiones acerca del
trabajo e incremente por montones el trabajo realmente
hecho. Además, ¡haga de su equipo de trabajo un equipo
feliz!

58
CAPITULO V: METODOLOGÍA
EXTREME PROGRAMMING

La programación extrema es una metodología de

desarrollo ágil que tiene como principal objetivo aumentar
la productividad a la hora de desarrollar un proyecto
software. Da prioridad a los trabajos que dan un resultado
directo y en los cuales se reduce la burocracia que pueda
existir en el entorno de trabajo.

Vamos a recordar que son las metodologías ágiles, ellas

tienen como punto fuerte la adaptación a cualquier cambio
en un proyecto para aumentar sus posibilidades de éxito.

Una metodología ágil tiene varios principios:

Los individuos y sus interacciones son más importantes

que los procesos y las herramientas.

El software que funciona es más importante que

la documentación exhaustiva.

Colaboración con el cliente en lugar de negociación de

contratos.

No hay que seguir un plan cerrado, sino adaptarse al

cambio.

59
PRINCIPIOS BÁSICOS
Tenemos 12 principios básicos que se agrupan en 4
categorías distintas:
o Retroalimentación.
o Proceso continuo en lugar de por bloques.
o Propiedad intelectual compartida.
o Entendimiento compartido.

RETROALIMENTACIÓN
Principio de pruebas: lo primero que se debe hacer es
establecer un período de pruebas de aceptación del
programa, en el cual se definirán las entradas y salidas del
sistema. Básicamente se define lo que debe hacer el
software desarrollado. Como si fuese una caja negra.

Planificación: el cliente (o su representante) escribirá sus

necesidades para definir concretamente las actividades
que el sistema debe realizar. En esta fase se creará un
documento que contendrá historias de usuario que forman
el plan de liberación, el cual define los tiempos de entrega
de la aplicación para poder recibir feedback por parte del
cliente.

Cliente in-situ: el cliente (o su representante) deberá

formar parte del equipo de desarrollo. Se le dará poder
para determinar los requisitos de la aplicación, definir la

60
funcionalidad y dar prioridad a determinadas cosas.
Gracias a esto, habrá una fuerte interacción con los
programadores, disminuyendo así el tiempo de
comunicación y la cantidad de documentación a
redactar. El cliente estará con el equipo durante todo el
proceso de desarrollo del proyecto.

Pair-programming: este punto junto con el anterior son

los más radicales de esta metodología. Consiste en escribir
código en parejas compartiendo una sola máquina. Según
los experimentos ya realizados sobre este método, se
producen mejores y más consistentes aplicaciones a igual
o menor coste.

Proceso continuo en lugar de por bloques

Integración continua: consiste en implementar
progresivamente las nuevas características del software.
En lugar de crear versiones estables en función de una
planificación previamente realizada, los programadores
reunen su código y reconstruyen el proyecto varias veces
al día si hace falta.

Refactorización: mediante la constante eliminación de

código duplicado y/o ineficiente los equipos de
programación mejoran el diseño del sistema. El código se
evalúa continuamente para ofrecer la mayor calidad
posible.

Entregas pequeñas: el producto es evaluado en un

ambiente real mediante la colocación de un sistema

61
sencillo en producción el cual se actualizará rápidamente,
es decir, cada 2 semanas (3 como máximo) el software
será puesto en producción.

Entendimiento compartido
Diseño simple: el mejor programa será aquel que cumpla
con los requisitos y sea más simple. Es importante
proporcionar un software que cubra las necesidades de un
cliente. Ni más ni menos.

Metáfora: expresa la visión evolutiva del proyecto y

define los objetivos del sistema mediante una historia.

Propiedad colectiva del código: el código tiene

propiedad compartida. Nadie es propietario de nada, ni
siquiera de lo que ha desarrollado. Todos los
programadores son “dueños” de todo el código. Según
esta metodología, cuantos más programadores haya
trabajando en una parte de código, menos errores tendrá.

Estándar de programación: define las reglas para

escribir y documentar código, además de cómo se
comunican las diferentes piezas de código desarrolladas
por diferentes equipos. El objetivo de esto es que parezca
que el código ha sido escrito por una única persona.

Bienestar del programador

Semana de 40 horas: los programadores cansados
escriben peor código. Es importante minimizar las

62
horas extras y mantener a los programadores frescos
y descansados. De esta manera, se generará mejor código.
Si es necesario hacer horas extras, quiere decir que el
proyecto está mal planificado.

Opiniones/Conclusiones
Os dejo unas tiras de Dilbert sobre extreme
programming que me han hecho gracia:

– “Vamos a probar algo llamado programación

extrema. Primero, escoged una pareja. Ambos trabajaréis
con un sólo ordenador durante 40 horas a la semana”.
– “El nuevo sistema tiene un minuto y ya odio a todo el
mundo”.

– “No puedo hacer todo esto para la primera versión y

cada versión necesita una historia de usuario”.
– “De acuerdo, aquí tienes una historia: haz todo lo que te
pido o arruinaré tu vida”.

63
Esta metodología existe desde el año 2001, es decir, que
tiene relativamente poco tiempo. Aunque lleve tan sólo
unos años ha revolucionado el mundo de la industria de
desarrollo software generando diversas opiniones, tanto
buenas como no tan buenas. Entre los puntos negativos,
podemos encontrar varios:

Los programadores suelen querer ser propietarios del

código que desarrollan: como se ha mencionado
anteriormente, nadie es propietario de nada. Se tiene
como objetivo el desarrollo de un código homogéneo,
del cual no podamos saber quién lo ha escrito. Además,
se establecerá un estándar de programación que ayudará
a cumplir esto.

¿40 horas semanales de trabajo? A veces son más: si los

programadores tienen que estar haciendo horas extra,
quiere decir que el problema está mal planteado. Es
posible que haya que trabajar más horas, pero no como
se debe tomar como norma. Programadores cansados =
peor código.

La programación extrema funciona mejor con gente con

talento: profesionales capaces de hacer un diseño simple
y escalable. Ellos mismos sabrán amoldarse y adaptarse al
entorno de trabajo.

64
REFERENCIAS

1. Henry Kniberg, Scrum y XP desde las trincheras,

2007
2. Martín Alaimo, Introducción a la Agilidad y
Scrum, 2012
3. Henrik Kniberg, Kanban y Scrum – obteniendo lo
mejor de ambos, 2010
4. Programación Extrema: Qué es y principios
básicos, https://geekytheory.com/programacion-
extrema-que-es-y-principios-basicos/

65