FACCI METODOLOGIAS AGILES

Post on 13-Jan-2015

582 views 6 download

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: