El documento describe varias metodologías para el desarrollo de proyectos de software, incluyendo metodologías ágiles y tradicionales. Explica que las metodologías ágiles valoran la interacción entre individuos, entregas funcionales rápidas y respuesta al cambio, mientras que las metodologías tradicionales se enfocan más en la planificación y documentación. También describe dos metodologías ágiles específicas: Scrum, la cual se basa en iteraciones cortas llamadas sprints, y eXtreme Programming, c

1. “Beneficios del Uso de
Metodologías en el
Desarrollo de Proyectos”

2.  ¿Podré cumplir con los
plazos?
 ¿Estaré dentro de lo
presupuestado?
 ¿El cliente quedará
satisfecho?
Las Metodologías pueden ser la ayuda que
necesitamos, si podemos usarlas
correctamente !!

3. Metodologías ...

4. ¿Qué es una Metodología ...
Las metodologías imponen un proceso
disciplinado sobre el desarrollo de
software con el fin de hacerlo más
predecible y eficiente.

5. Metodología Tradicional
Existen hace mucho tiempo, no han sido exitosas
porque son muy burócratas, se han orientado al
documento más que a los resultados.

6. Metodología Ágil
Son la justa medida entre “ningún proceso” y
“demasiado proceso”, proporcionando simplemente
“suficiente proceso” para que el esfuerzo valga la
pena !!!

7. Metodologías Ágiles

8.  Las Metodologías Ágiles (AMs) valoran:
 Al individuo y las interacciones en el equipo de
desarrollo más que a las actividades y las
herramientas
 Desarrollar software que funciona más que conseguir
una buena documentación  Minimalismo respecto
del modelado y la documentación del sistema
 La colaboración con el cliente más que la negociación
de un contrato
 Responder a los cambios más que seguir
estrictamente una planificación

9.  Dificultad para implantar metodologías tradicionales.
 Una solución a medida para un segmento importante
de proyectos de desarrollo de software
 “Aceptar el cambio” ...

10. Tradicionales
 Grandes
 Con requerimientos estables
 Aplicaciones críticas
 Grandes equipos de desarrollo
 Equipo de desarrollo distribuidos geográficamente
Agiles
 Ambientes dinámicos, con equipos de trabajo pequeños y
produciendo aplicaciones no críticas
 Requerimientos desconocidos o inestables, garantizando
un menor riesgo ante la posibilidad de cambio en los
requerimientos

11. Costo
del
cambio
tiempo
Tradicional
Suposición AMs

12. Principios:
1. La prioridad principal es satisfacer al cliente
mediante tempranas y continuas entregas de
software que le reporte un valor
2. Dar la bienvenida a los cambios. Los AMs capturan
los cambios para que el cliente tenga una ventaja
competitiva
3. Entregar frecuentemente software que funcione,
desde un par de semanas a un par de meses, con el
menor intervalo de tiempo posible entre una
entrega y la siguiente

13. 8. Los procesos ágiles promueven un desarrollo
sostenible. Los promotores, desarrolladores y
usuarios deberían ser capaces de mantener una paz
constante
9. La atención continua a la calidad técnica y al buen
diseño mejora la agilidad
10. La simplicidad es esencial
11. Las mejores arquitecturas, requisitos y diseños
surgen de los equipos organizados por sí mismos
12. En intervalos regulares, el equipo reflexiona respecto
de cómo llegar a ser más efectivo, y según esto
ajusta su comportamiento

14. Metodología Ágil Metodología No Ágil
Pocos Artefactos Más Artefactos
Pocos Roles Más Roles
No existe un contrato tradicional
o al menos es bastante flexible
Existe un contrato prefijado
Cliente es parte del equipo de
desarrollo (además in-situ)
El cliente interactúa con el
equipo de desarrollo mediante
reuniones
Grupos pequeños (< 10
integrantes) y trabajando en el
mismo sitio
Grupos grandes
Menos énfasis en la arquitectura La arquitectura es esencial

15.  Crystal Methodologies, Alistarir Cockburn,
www.crystalmethodologies.org
 SCRUM, Ken Schwaber & Jeff Sutherland,
www.controlchaos.com
 DSDM (Dynamic Systems Development Method),
www.dsdm.org
 Lean Programming, Mary Poppendieck, www.poppendieck.com
 FDD (Feature-Driven Development), Peter Coad & Jeff De Luca,
www.nebulon.com/fdd, www.coad.com/peter/#fdd
 Extreme Programming, Kent Beck
www.extremeprogramming.org, www.xprogramming.com
 Adaptative Software Development, Jim Highsmith
www.adaptivesd.com

17. eXtreme Programming

18.  Metodología liviana de desarrollo de software
 Conjunto de practicas y reglas empleadas para
desarrollar software
 Basada en diferentes ideas acerca de cómo
enfrentar ambientes muy cambiantes
 Originada en el proyecto C3 para Chrysler
 En vez de planificar, analizar y diseñar para el
futuro distante, hacer todo esto un poco cada
vez, a través de todo el proceso de desarrollo

20.  “Haz la cosa mas simple posible que
funcione”
 “Mantén el sistema en la condición mas
simple posible”

21.  El cliente es parte del equipo de desarrollo
 Comunicación entre gestión y desarrollo
 Comunicación entre desarrolladores

22.  Velocidad, pero además calidad
 Testeo continuo a través de todo el proceso
 Testeo como herramienta de especificación y
desarrollo
 Testeo como garantía de integridad del
código frente a cambios

23.  Reacción frente a los cambios

25. Prototipo
arquitectónico
Planificación
de entregas
Iteración
Tests de
aceptación
Pequeñas
entregas
Historias de
usuario
Metáfora de
sistema
Prototipo
requerimientos
Estimación
incierta
Estimación
confiable
Plan de
entregas
Versión mas
reciente
Aprobación
del cliente
Escenarios de testeo
Historias nuevas
Velocidad del proyecto
Próxima
iteración
bugs

26. Próxima
iteración
Planificación
de iteración
Desarrollo
Versión mas
reciente
Velocidad de
proyecto
Plan de
iteración
Plan de
entregas
Bugs
Historias de
usuario
Tests de
aceptación
fallados
Funcionalidades
nuevas
Corrección de
bugs
Día a día
Historias nuevas,
Velocidad de proyecto
Aprender y
comunicar

27. Corrección de
bugs
Reunión
de pie
Manejo colectivo
del software
Próxima tarea o test
de aceptación fallido
Plan de
iteración
Día a día
tareas
Tests de
aceptación
fallados
Tests de unidad
pasados al 100%
Test de
aceptación
aprobado
Tareas sin terminar
Demasiado por
hacer
Nueva
funcionalidad
Aprender y
comunicar
Programación en pares
Reconstrucción de código

28. Próxima tarea
o test de
aceptación
Creación de
unidad de
testeo
Programación
en pares
100% de
unidades de
testeo pasados
Pares
Unidad de
testeo fallida
Mover Gente
Se necesita
ayuda
Cambio
de par
Unidad de
testeo
aprobada
Código
simple
Código
complejo
Reconstrucción
despiadada
Ejecutar
todas las
unidades
de testeo
Test de
aceptación
aprobado
Ejecutar
test de
aceptación
fallados

29.  Proceso de
planificación
 Entregas pequeñas
 Metáfora del sistema
 Diseño simple
 Testeo
 Reconstrucción
 Programación en
pares
 Propiedad colectiva
 Integración continua
 Semana de 40 horas
 Cliente siempre
disponible

30. SCRUM

31.  Scrum es una metodología ágil de desarrollo de
software.
 Ken Schwaber y Jeff Sutherland fueron los
precursores de este método demostrando
ampliamente su valía en proyectos de gran
envergadura con un alto número de personal
involucrado es su consecución.

32.  Desarrollo de software por medio de iteraciones (Sprints).
 Indicado para proyectos con un rápido cambio de
requerimientos.
 Gran protagonismo de reuniones a lo largo del proyecto.

33.  Product Backlog.
 Sprint Backlog.
 Spring Planning meeting.
 Revisión de Sprint.

34.  Propietario del producto.
 Usuarios del producto.
 Scrum master.
 Equipo scrum.

36.  Base del desarrollo en Scrum.
 Periodo mensual donde se llevan a cabo una serie de
tareas previamente establecidas.

37.  Lista de las tareas a realizar durante todo el proyecto.
 No es una lista fija se puede eliminar o añadir tareas
conforme avance el proyecto.
 Se prioriza las tareas según los requisitos de los usuarios
o del propietario de la aplicación.

38.  Reunión que se realiza antes de cada Sprint.
 Se hace conjuntamente con el Propietario del producto el
Scrum Master y el equipo Scrum.
 Enfocar la reunión hacia los requisitos mas prioritarios.

39.  Después de solventar cualquier tipo de duda sobre los
requisitos se pasa a decidir las tareas a desarrollar en el
Sprint.

40.  Lista elaborada por el equipo Scrum.
 Se especifican las tareas que se van a desarrollar a lo
largo del Sprint.
 Tiene gran importancia ser realista en la elaboración del
Sprint Backlog para poder finalizar las tareas acordadas.

41.  Se realiza al final de cada Sprint.
 Se deben reunir el propietario de la aplicación los
usuarios así como el Scrum Master y su equipo , además
también es recomendable que acudan ingenieros de otros
proyectos para dar su punto de vista.

44. VENTAJAS:
 Programación organizada
 Menor taza de errores
 Satisfacción del programador
DESVENTAJAS:
 Es recomendable emplearlo solo en
proyectos a corto plazo

45. SEMEJANZAS
 Es un Agile Manifiesto.
 Existen una Interacción de Usuario a Usuario.
 Realizan los Proyectos en un Corto Periodo de
Tiempo.
 Trabajan en Equipo.

46. SCRUM XP (EXTREME PROGRAMMING)
Las iteraciones de entregas son de 2 a 4
semanas.
Las iteraciones de entrega son a 1 a 3
semanas.
Lo que se termina, funciona y este bien, se
aparta y ya no se toca.
Las tareas q se van entregando a los
diferentes clientes son susceptibles a las
modificaciones.
Cada miembro del Scrum Team trabaja de
forma individual.
Los miembros programan en pareja en un
proyecto XP.
El Scrum Team trata de seguir el orden de
prioridad que marca el Product Owner, en
el Sprint Backlog pueden ser modificadas.
El equipo de desarrollo sigue estrictamente
el orden de prioridad de las tareas definidas
por el cliente.
Esta basada en la administración del
proyecto.
Se centra mas en la propia programación o
creación del producto.

48. HISTORIA DE USUARIOS - EJEMPLOS
Historia de Usuario
Número: 1 Nombre :Ingreso de Calificaciones
Modificación de Historia de Usuario (Nro. y Nombre):
Usuario/Rol: Secretaria Iteración/Sprint Asignada: 1
Prioridad en Negocio: Alta
(Alta / Media / Baja)
Riesgo en Desarrollo: Alta
(Alto / Medio / Bajo)
Descripción: Permite el ingreso de las calificaciones de cada parcial de los estudiantes
que se encuentran matriculados tanto en la modalidad semestral como anual
Observaciones: Actualmente la información es llevada de maneja semi automática en
hojas de cálculo.

49. Historia de usuario
Numero:2 Nombre: Operaciones de corte
Usuario/Rol: Jefe de producción
Modificación de historia numero: Iteración asignada: 2
Prioridad en Negocio: Alta
(Alta / Media / Baja)
Riesgo en Desarrollo: Medio
(Alto / Medio / Bajo)
Descripción: El jefe de producción tendrá la tarea de marcar el producto al ser finalizado
en esta área, para que pueda ser pasado por el horno de templado, es necesario llevar el
control porque una vez templado el vidrio no puede ser modificado
Observaciones:
HISTORIA DE USUARIOS - EJEMPLOS

50. HISTORIA DE USUARIOS - EJEMPLOS
Historia de usuario
Numero:3 Nombre: Generación de reportes
Usuario/Rol: Ingeniero de templado
Modificación de historia numero: Iteración/Sprint asignada: 2
Prioridad en Negocio: Alta
(Alta / Media / Baja)
Riesgo en Desarrollo: Medio
(Alto / Medio / Bajo)
Descripción: El ingeniero de templado tendrá la opción de marcar los vidrios una vez
hayan sido procesados por el horno de templado para dar orden de culminación y
entrega del producto.
Observaciones: