FACCI METODOLOGIAS AGILES
-
Upload
afrancoing -
Category
Documents
-
view
589 -
download
6
description
Transcript of FACCI METODOLOGIAS AGILES
“Beneficios del Uso de
Metodologías en el
Desarrollo de Proyectos”
¿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 !!
Metodologías ...
¿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.
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.
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 !!!
Metodologías Ágiles
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
Dificultad para implantar metodologías tradicionales.
Una solución a medida para un segmento importante de proyectos de desarrollo de software
“Aceptar el cambio” ...
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
Costo del
cambio
tiempo
Tradicional
Suposición AMs
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
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
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
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
eXtreme Programming
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
“Haz la cosa mas simple posible que funcione”
“Mantén el sistema en la condición mas simple posible”
El cliente es parte del equipo de desarrollo
Comunicación entre gestión y desarrollo
Comunicación entre desarrolladores
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
Reacción frente a los cambios
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
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
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
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
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
SCRUM
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.
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.
Product Backlog.
Sprint Backlog.
Spring Planning meeting.
Revisión de Sprint.
Propietario del producto.
Usuarios del producto.
Scrum master.
Equipo scrum.
Base del desarrollo en Scrum.
Periodo mensual donde se llevan a cabo una serie de
tareas previamente establecidas.
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.
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.
Después de solventar cualquier tipo de duda sobre los
requisitos se pasa a decidir las tareas a desarrollar en el
Sprint.
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.
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.
VENTAJAS:
Programación organizada
Menor taza de errores
Satisfacción del programador
DESVENTAJAS:
Es recomendable emplearlo solo en proyectos a corto plazo
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.
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.
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.
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
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: