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
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 !!
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 !!!
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
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
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
19.
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
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
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.
35.
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.
42.
43.
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.
47.
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: