desarrollo agil, producto proceso, scrum
TRANSCRIPT
Grado en Ingeniería InformáticaLunes, 10 de Octubre de 2011
RUP / DESARROLLO ÁGIL.
PRODUCTO - PROCESO
2
PROCESO UNIFICADO RATIONAL (RUP)
01• Definición
02• Aspectos característicos
03• Mejores prácticas
04• Fases del proceso
3
DEFINICIÓN
Proceso de software genérico
Enfoque disciplinado en la asignación de tareas y responsabilidades
Está basado en componentes e interfaces bien definidas
Utiliza el Lenguaje Unificado de Modelado (UML)
PROCESO UNIFICADO
4
ASPECTOS CARACTERÍSTICOSPROCESO UNIFICADO
Dirigido por casos
de Uso
Centrado en la
Arquitectura
Iterativo e Incremental
5
DIRIGIDO POR CASOS DE USO
Caso de uso: Fragmento de funcionalidad que proporciona al usuario un resultado importante
Modelo de casos de uso: Funcionalidad total del sistema
¿Qué debe hacer el sistema … para cada usuario?
PROCESO UNIFICADO
6
CENTRADO EN LA ARQUITECTURA
Describe diferentes vistas del sistema
Incluye los aspectos estáticos y dinámicos más significativos
La arquitectura y los casos de uso evolucionan en paralelo
PROCESO UNIFICADO
7
ITERATIVO E INCREMENTAL
Se divide el trabajo en mini-proyectos
Cada mini-proyecto es una iteración que resulta en un incremento
La iteración Trata un conjunto de casos de uso que extienden la usabilidad Trata los riesgos más importantes
En cada iteración se persiguen unos objetivos concretos
PROCESO UNIFICADO
8
ITERATIVO E INCREMENTALPROCESO UNIFICADO
9
MEJORES PRÁCTICASPROCESO UNIFICADO
Desarrollo iterativo de software
Gestión de requisitos
Arquitecturas basadas en componentes
Modelado visual del software
Verificación de la calidad del software
Control de cambios del software
10
DESARROLLO ITERATIVO
El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada.
Un proceso iterativo permite una comprensión creciente de los requisitos a la vez que se va haciendo crecer el sistema.
Se abordan las tareas con más riesgo primero.
Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.
PROCESO UNIFICADO
11
GESTIÓN DE REQUISITOS
El proceso describe cómo:
– Obtener los requisitos
– Organizarlos
– Documentar la funcionalidad y restricciones
– Rastrear y documentar decisiones
– Captar y comunicar los requisitos del negocio
Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar los requisitos y guiar el diseño, la implementación y las pruebas.
PROCESO UNIFICADO
12
ARQUITECTURAS BASADAS EN COMPONENTES
El proceso se basa en diseñar tempranamente una arquitectura base ejecutable.
La arquitectura debe ser:– Flexible– Fácil de modificar– Intuitivamente comprensible– Promueve la reutilización de componentes
RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.
PROCESO UNIFICADO
13
MODELADO VISUAL DEL SOFTWARE
El modelado es importante porque ayuda al equipo a visualizar, especificar, construir y documentar la estructura y comportamiento de la arquitectura del sistema.
Permiten:– La comunicación en el equipo de desarrollo– Fácil de entender– Fácil de modificar
UML es la base del modelamiento visual.
PROCESO UNIFICADO
14
VERIFICACIÓN DE LA CALIDAD DEL SOFTWARE
La funcionalidad y el rendimiento son factores esenciales.
Ayuda a planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen estas cualidades.
La verificación y administración de la calidad durante el ciclo de vida del proyecto es esencial para lograr mantener los objetivos y el tiempo estimado de desarrollo.
PROCESO UNIFICADO
15
CONTROL DE CAMBIOS DEL SOFTWARE
Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto.
Indica como controlar, rastrear y monitorizar los cambios dentro del proceso iterativo de desarrollo.
PROCESO UNIFICADO
16
DIMENSIÓN DEL PROCESOPROCESO UNIFICADO
Iter #n
------------Iter #2
Test
Iter #n-1
------Iter #1
Implementac.
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboraciónConcepciónFlujos de trabajo / Fases
17
FASES DEL PROCESO UNIFICADOPROCESO UNIFICADO
Comunicación
Planificación
Modelado
Despliegue
Incremento del Software
Construcción
Concepción Elaboración
Construcción
TransiciónProducción
• Los modelos del caso de uso• De requerimientos• Del diseño• De la implementación• Del despliegue
18
DESARROLLO ÁGIL
01• Manifiesto por el desarrollo ágil de software
02• La agilidad y el coste del cambio
03• Un proceso ágil
04• Principios de agilidad
05• Programación extrema (XP)
06• Otros modelos ágiles
07• Scrum
19
MANIFIESTO POR EL DESARROLLO ÁGILDESARROLLO ÁGIL
Los individuos y sus
interacciones, sobre los
procesos y las herramientas
El software que funciona,
más que la documentación
exhaustiva
La colaboración con el cliente, y no tanto la negociación del contrato
Responder al cambio, mejor que apegarse
a un plan
20
LA AGILIDAD Y EL COSTE DEL CAMBIO
Recomienda las estructuras de equipo y las actitudes que hacen más fácil la comunicación
Pone énfasis en la entrega rápida de software funcional y resta importancia a los productos intermedios.
Adopta al cliente como parte del equipo de desarrollo Un plan de proyecto debe ser flexible.
DESARROLLO ÁGIL
DESARROLLO TRADICIONAL vs DESARROLLO ÁGIL
21
UN PROCESO ÁGILDESARROLLO ÁGIL
Adaptable IncrementalmenteIncrementos de
software
22
PRINCIPIOS DE AGILIDADDESARROLLO ÁGIL
Satisfacción al cliente
Adaptación a los cambios
Entregas de software
Trabajo en equipo
Motivación en el trabajo
Diálogo
Software funcional
Desarrollo sostenible
Atención continua
Simplicidad
Organización
Efectividad
23
PROGRAMACIÓN EXTREMA (XP)DESARROLLO ÁGIL
Planificación Diseño
Prueba
Incremento del SoftwareVelocidad calculada del
proyecto
Codificación
• Historias de usuario• Valores• Orden
Valor Riesgo
• Velocidad del proyecto
Diseño simple
Programación por parejas
Prueba unitariaIntegración continuaPruebas de aceptación
PrototiposSoluciones en punta
Lanzamiento
24
OTROS MODELOS ÁGILESDESARROLLO ÁGIL
Desarrollo adaptativo de software (DAS)
Scrum
Método de desarrollo de sistemas dinámicos
Cristal
Desarrollo impulsado por las características (DIC)
Desarrollo esbelto de software (DES)
Modelo ágil
Proceso unificado ágil (PUA)
25
SCRUMDESARROLLO ÁGIL
26
PRODUCTO - PROCESO
No hay producto sin proceso, pero el proceso puede matar al producto
Si el proceso es deficiente, no cabe duda de que el producto final sufrirá
Privilegiar un punto de vista sobre otro supone un error
El producto y el proceso son tratados como si fueran contrarios en lugar de ser comprendidos como una dualidad
27
PRODUCTO - PROCESO
…La empresa en la que trabajo es resultado de la fusión de dos y en su momento viví la experiencia del grupo de trabajo orientado al producto y donde el método brillaba por su ausencia. Reconozco que el producto final ganaba mucho y que todos nos sentíamos identificados con nuestros trabajos pero las desviaciones en los presupuestos y los problemas con los clientes eran demasiado frecuentes.
Cuando digo que no había metodología me refiero a que no se controlaban las horas, la tecnología dominaba sobre los requisitos del cliente, en muchísimas ocasiones ni siquiera existían esos requisito (un comercial había vendido una web, venga todos a currar), no había ningún tipo de entrega, etc.. No había metodología ni externa (de cara al cliente) ni interna (en el propio proceso de desarrollo).
28
PRODUCTO - PROCESO
No funcionaba, en esa línea acabar todos en la calle era cuestión de tiempo. Y eso les ha pasado a muchos pequeños estudios que han terminado cerrando: no salen los números. Solución: hay que poner orden, definamos un método.
Nos vamos la lado contrario, el desarrollo del proyecto se define por un método definido en un esquema precioso lleno de flechas y diagramas de alguien que realmente disfruta con el Visio y que hay que seguir con todo rigor. Resultados: gente cabreada, alejamiento del desarrollador del producto y, lo peor, productos mediocres. Además en esa época desarrollábamos proyectos pequeños y la burocratización del proceso de desarrollo hacía que tampoco fuesen demasiado rentables; no se puede pasar más tiempo reunido o comentando incidencias que desarrollando.
29
PRODUCTO - PROCESO
Sin embargo la experiencia fué positiva, de esa larga lista de procedimientos que implicaba el desarrollo de una web fueron quedando los realmente necesarios y, lo más importante, la gente se fue acostumbrando a asumir las horas que se habían comprometido, a hacer la parte del trabajo que le correspondía, a trabajar por fases… todas esas cosas que a muchos os parecerán lo más normal del mundo pero que no lo son tanto.
Finalmente y una vez asumida e interiorizada una metodología interna que ya está más o menos implícita en cualquier trabajo podemos volver a orientarnos al producto y esto se nota muchísimo en tres cosas: satisfacción de los clientes, mejora de los productos e identificación de los desarrolladores con lo que hacen.
30
PRODUCTO - PROCESO
Resumiendo, creo que en ningún caso puede haber una orientación al producto sin tener asumido un proceso metodológico básico y que funcione pero si se cumple ese requisito lo que manda es el producto, es la estrella. Una empresa de desarrollo web que haga malas webs, que vamos a decir.
31
MUCHAS GRACIAS