El documento presenta diversas metodologías de desarrollo ágil de software, destacando la importancia de adaptabilidad, entrega continua y la colaboración entre equipos. Se analizan enfoques como Scrum, Extreme Programming, y Domain-Driven Design, cada uno con sus principios y prácticas específicas para optimizar el proceso de desarrollo. Se enfatiza en la necesidad de una comunicación efectiva y en la incorporación de feedback constante para mejorar la calidad del software desarrollado.

1. Christian Paolo Vera Livia
METODO PARA EL DESARROLLO DE SOFTWARE
30-Set 2016

2. christianv16@gmail.com

3. Christian Paolo Vera Livia
AGENDA
• METODOS PARA EL DESARROLLO DE SOFTWARE.
• Caracteristicas principales ADAPTACIÒN A LOS CAMBIOS
• OPUESTOS A LOS METODOS TRADICIONALES (Predicitvos)
• Definen al Inicio .
• Alcance (Funcionalidad, Tecnologia)
• Costo
• Tiempo
• Establecen metodos de Monitoreo y Control
• Para prevenir desvios
20 Min

4. Proyecto de Desarrollo de Software
¿Para que un método de Gestión ?
PROBLEMA Intangibilidad del Software
¿De que color es algo que no podemos ver?
SOLUCIÓN
Método ÁgilMétodo Tradicional

6. Desarrollo Agil : Manifesto
Propósito :
Estamos descubriendo mejores formas de desarrollar software haciéndolo y
ayudando a que otros lo hagan.
A través de este trabajo hemos llegado a valorar:
Esto quiere decir : Aunque valoramos los elementos de la
derecha, valoramos más los elementos de la izquierda.
http://agilemanifesto.org/iso/es/manifesto.html

8. SCRUM
ROLES
• Scrum Master
• Dueño de Producto
• Equipo
ARTEFACTOS
• Backlog de Producto
• Backlog de Sprint
• Incremento de Producto
CEREMONIAS
• Planificación
• Reunión diaria
• Revisión
• Retrospectiva

9. LEAN KANBAN
El concepto de Lean optimiza el sistema de una organización para producir resultados
valiosos sobre la base de sus recursos, necesidades y alternativas, mientras reduce las
perdidas.
Las perdidas, por ejemplo, podrían ser la construcción incorrecta de un producto, el no
saber aprender, o las prácticas que impiden el proceso. Debido a que estos factores son
de naturaleza dinámica, una organización ágil evalúa la totalidad de su sistema y
continuamente hace ajustes de sus procesos.
 Tres Reglas
• Mostrar el proceso tablero
• Limitar el trabajo en curso (WIP Work In Progress)
• Optimizar el flujo de trabajo
Es de origen Japonés es ideada por Toyota en productos tangibles , y quiere decir capacidad de
comprometerse al trabajo si solamente se tiene la posibilidad de hacerlo.

10. Extreme Programming (XP)
XP hace que sea posible mantener el costo de cambiar el software sin que éste aumente
radicalmente con el tiempo. Los atributos claves de XP incluyen el desarrollo gradual,
horarios flexibles, pruebas automatizadas de código, la comunicación verbal, el diseño en
constante evolución, Colaboración cercana y la vinculación de las unidades, de largo como
de corto plazo, de todos los involucrados
 Valores
• Comunicación
• Simplicidad
• Retroalimentación
• Respeto
• Coraje
Hacer modificaciones a un software pero por detrás , modificar el código fuente sin alterar el
funcionamiento externo
 Practicas
1. Cliente InSitu
2. Metáfora
3. Refactoring
4. Entregas cortas
5. TDD
6. Semana de 40 Horas
7. KISS
8. Propiedad Colectiva
9. Código Estándar
10. Programación de a pares
11. Integración Continua
12. Juego de planificación

11. Métodos Crystal
La intención de los métodos Crystal es centrarse en las personas; ser ligeros y fáciles de
adaptar. Debido a que las personas son primordiales, en el proceso de desarrollo y las
herramientas no son fijas, sino que se ajustan a los requerimientos y características
especificas del proyecto.
Se utiliza colores para decidir sobre la variante de un proyecto.
La familia Crystal se divide en:
• Crystal Clear (claro como el cristal - Para equipos de hasta 8 personas o menos.)
• Crystal Yellow (cristal amarillo - Entre 10 y 20 personas. ).
• Crystal Orange (cristal naranja - Equipos entre 20 y 50 personas.).
• Crystal Orange Web (cristal naranja web).
• Crystal Red (cristal rojo - Entre 50 y 100 personas.).
• Crystal Maroon (cristal marrón).
• Crystal Diamond (cristal diamante).
• Crystal Sapphire (cristal zafiro).
Metodologías Crystal tiene como característica dos dimensiones, tamaño y criticidad.

12. Métodos Crystal
Las 7 propiedades de las metodologías Crystal
1. Entregas frecuentes, en base a un ciclo de vida iterativo e incremental.
2. Mejora reflexiva. Que viene a ser mejora continua. Las iteraciones ayudan a ir
ajustando el proyecto, a ir mejorándolo.
3. Comunicación osmótica.
4. Seguridad personal.
5. Enfoque.
6. Fácil acceso a usuarios expertos.
7. Entorno técnico con pruebas automatizadas, gestión de la configuración e integración
continua.

13. Dynamic Systems Development Methods (DSDM)
DSDM establece la calidad y el esfuerzo en términos de costo y el tiempo desde el principio y ajusta los
entregables del proyecto para cumplir con los criterios establecidos, dando prioridad a las prestaciones
en las siguientes categorías: lo que "deben tener", "deberían tener", "podrían tener", y "no tendrán"
(mediante la técnica MoSCoW Prioritization).
Principios del DSDM
• Involucrar al cliente es la clave para llevar un proyecto
eficiente y efectivo.
• El equipo del proyecto debe tener el poder para tomar
decisiones que son importantes.
• DSDM se centra en la entrega frecuente de productos.
• El desarrollo es iterativo e incremental.
• Todos los cambios durante el desarrollo son reversibles.
• Las pruebas son realizadas durante todo el ciclo vital del
proyecto.
• La comunicación y cooperación entre todas las partes
interesadas .
Requisitos previos para el uso de DSDM:
• Interactividad, los usuarios y los jefes de Desarrollo.
• Motivación y participación entre las partes (humanas)
que integran el equipo.
• Intercambio de ideas o funcionalidades necesarias .
Fases :
• Pre-proyecto
• Viabilidad
• Fundamentos
• Exploración e Ingeniería.
• Despliegue
• Evaluación de Beneficios.

14. Feature Driven Development (FDD)
Opera bajo el principio de la realización de un proyecto donde éste se separa en pequeñas funciones
valoradas por el cliente que pueden ser entregadas en menos de dos semanas. FDD tiene dos
5 Procesos:
• Desarrollar el modelo global (Develop overall model),
• Construir una lista de características (Build feature list),
• Planificar (Plan by feature),
• Diseñar (Design by feature)
• Construir (Build by feature).
Principios
• El desarrollo de software es una
actividad humana
• El desarrollo de software es una
funcionalidad valorada por el cliente..
6 Roles principales
• Administrador de Proyecto
• Arquitecto Jefe
• Jefe de Desarrollo
• Programadores Jefe
• Dueños de clases (Trabajan bajo la guía del programador jefe en
diseño, codificación, prueba y documentación)
• Expertos en el dominio(Cliente, patrocinador , analista de negocios)
FDD es un método de desarrollo de ciclos cortos que se concentra en la fase de diseño y construcción. En la primera fase, el
modelo global de dominio es elaborado por expertos del dominio y desarrolladores; el modelo de dominio consiste en
diagramas de clases con clases, relaciones, métodos y atributos. Los métodos no reflejan conveniencias de programación
sino rasgos funcionales.

15. Test Driven Development (TDD)
Test Driven Development es un método de desarrollo de
software que consiste en escribir primero un código de
prueba automatizado y el desarrollo con la menor
cantidad de código necesarios para luego pasar la prueba.
El proyecto se divide en características pequeñas de valor
para el cliente que deben ser desarrolladas en el ciclo de
desarrollo más corto posible.
Las pruebas se escriben basadas en los requisitos y
especificaciones de los clientes.
Esto tiene unas implicaciones técnicas:
Diseñar el código según escribimos nuestros tests:
debemos encontrar un balance entre el diseño de UMLs y
la realización de tests para que nos orienten por donde
tenemos que ir.
El entorno de desarrollo tiene que ser capaz de decirnos
rápidamente el estado de nuestro código en todo
momento (debe ser rápido o sino se deja de hacer
pruebas, por lo que hay que diseñarlos para q sean lo más
rápido posibles)
TDD se puede clasificar en dos niveles:
Acceptance TDD (ATDD) que requiere
una prueba de aceptación
específica y Developer TDD (DTDD) que
tiene que ver con escribir sólo una
prueba de desarrollador.
· Diseñar componentes altamente cohesivos y muy poco acoplados para conseguir probarlos fácilmente.s en la fase
precedente se utilizan para diseñar y escribir el código de producción.
Principios
• Escribir nuevo código si tenemos
primero un test que falla.
• Eliminar duplicación (conseguir un
código lo más "bonito" posible)

16. Adaptive Software Development (ASD)
Significa Desarrollo Adaptable de Software es un
modelo de implementación de patrones ágiles para
desarrollo de software. Al igual que otras
metodologías ágiles, su funcionamiento es cíclico y
reconoce que en cada iteración se producirán cambios
e incluso errores.
El desarrollo de software adaptable (Adaptive
Software Development - ASD) es una metodología de
desarrollo que hace énfasis en aplicar las ideas que se
originaron en el mundo de los sistemas complejos,
adaptación continua del proceso al trabajo.
CICLO DE VIDA
Especular : Una primera fase de iniciación para establecer los principales objetivos y metas del proyecto en su
conjunto y comprender las limitaciones (zonas de riesgo) con las que operará el proyecto.
Colaborar : Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cíclica. Un
trabajo importante es la coordinación que asegure que lo aprendido por un equipo se transmite al resto y no
tenga que volver a ser aprendido por los otros equipos.
Aprender : La última etapa termina con una serie de ciclos de colaboración, su trabajo consiste en capturar lo
que se ha aprendido, tanto positivo como negativo. Es un elemento crítico para la eficacia de los equipos.
CARACTERISITICAS
Sus principales características del ASD son:
• Iterativo.
• Orientado a los componentes de
software (la funcionalidad que el
producto va a tener, características, etc.)
más que a las tareas en las que se va a
alcanzar dicho objetivo.
• Tolerante a los cambios.
• Guiado por los riesgos
• La revisión de los componentes sirve
para aprender de los errores y volver a
iniciar el ciclo de desarrollo

17. Agile Unified Process (AUP)
El Proceso Unificado Agil es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe
de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando
técnicas ágiles y conceptos que aún se mantienen válidos en RUP.
El AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD),
Modelado Agil, Gestión de Cambios Agil, y Refactorización de Base de Datos para mejorar la productividad.
El proceso unificado (Unified Process o UP) es un marco de desarrollo software iterativo e incremental.
A menudo es considerado como un proceso altamente ceremonioso porque especifica muchas actividades y
artefactos involucrados en el desarrollo de un proyecto software. Dado que es un marco de procesos, puede
ser adaptado y la más conocida es RUP (Rational Unified Process) de IBM.
AUP se preocupa especialmente de la gestión de riesgos. Propone que aquellos elementos con alto riesgo
obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo. Para ello,
se crean y mantienen listas identificando los riesgos desde etapas iníciales del proyecto. Especialmente
relevante en este sentido es el desarrollo de prototipos ejecutables durante la base de elaboración del
producto, donde se demuestre la validez de la arquitectura para los requisitos clave del producto y que
determinan los riesgos técnicos.
El proceso AUP establece un Modelo más simple que el que aparece en RUP por lo que reúne en una única
disciplina las disciplinas de Modelado de Negocio, Requisitos y Análisis y Diseño. El resto de disciplinas
(Implementación, Pruebas, Despliegue, Gestión de Configuración, Gestión y Entorno) coinciden con las
restantes de RUP.

18. Domain-Driven Design (DDD)
Fue concebido por Eric Evans en el año
2004 y gira en torno al diseño de un dominio básico.
"Dominio" se define como un área de actividad a la
que el usuario aplica un programa o funcionalidad.
Muchas de estas áreas se procesan por lotes y un
modelo es diseñado. El modelo consiste en un sistema
de abstracciones que se pueden utilizar para diseñar el
proyecto general y resolver los problemas
relacionados con los dominios loteados. Los valores
centrales de
Lenguaje Ubicuo. El usuario puede decir: “quiero
convertir a un prospecto en cliente cuando se cierre
una venta”. Esa petición así planteada es tan vaga que
el programador no puede hacer nada práctico con ella.
Pero es el punto de partida para definir con precisión
lo que es un prospecto, lo que es un cliente y cuándo y
cómo se convierte uno en el otro. DDD pone mucho
énfasis en que los programadores aprendan e
implementen el Lenguaje Ubícuo con las definiciones y
terminología exactamante como las usa el cliente.
Cada Contexto Acotado puede tener su propio
Lenguaje Ubícuo, o, dicho de otra forma, la misma
cosa (o muy parecida) se puede llamar de manera
diferente en un contexto que en otro.
La calidad de los modelos con los cuales construimos software tiene un impacto directo en los resultados
obtenidos, en la comunicación con los expertos del dominio y en la simpleza de mantenimiento.
La técnica DDD ha tomado nueva relevancia últimamente por la compatibilidad entre el concepto de
microservicios, relacionado con la arquitectura de software.
DDD no consiste solo en patrones y arquitecturas recomendadas.
DDD es una forma de afrontar los proyectos, forma de trabajar el equipo de desarrollo y su relación
directa con los expertos del dominio mediante el ‘lenguaje ubicuo’. Esta forma de trabajar y diseñar,
fundamental para el ciclo de vida de una aplicación

19. ¿DUDAS,PREGUNTAS,COME
NTARIOS?