De Nada a lo Monumental y a lo Ágil § La mayoría del desarrollo software actual se caracteriza por… Actividad Caótica “Code and Fix” Esto no funciona en proyectos grandes
De Nada a lo Monumental y a lo Ágil § La Metodología: - Nace para solucionar los problemas anteriores - Produce disciplina - Mas predecible - Más eficiente Todo resuelto … (¿Seguro?)
De Nada a lo Monumental y a lo Ágil Por lo anterior se les denomina “Metodologías pesadas (hightweight)” o “Metodologías Monumentales” (J. Highsmith). Principal crítica: Burocracia: tantas cosas que desarrollar que la velocidad de desarrollo baja.
De Nada a lo Monumental y a lo Ágil Para reaccionar al anterior problema aparecen otras metodologías, denominadas “Metodologías de peso ligero” y ahora “Metodologías Ágiles” Reacción ante la burocracia. Compromiso entre el no proceso y el proceso monumental. No están orientadas por la documentación, enfatizan poca documentación.
Diferencias entre lo Pesado y lo Ágil Ágiles Pesados Predictivos Adaptativos Bienvenido el cambio, adaptación y evolución en el cambio. Orientados a la gente Orientados al proceso Trabajan bien hasta que cambian las cosas, su naturaleza es restringir el cambio. Plan largo y documental Plan corto y casi sin documentos
Error 1: Separación de Diseño y Construcción § La inspiración inicial partió de las ingenierías clásicas (mecánica, civil, etc.): - Enfatizan la planificación antes de la construcción. - Planos precisos. - La construcción tiene poca destreza intelectual y más manual, por tanto existen dos actividades diferenciadas: el diseño y la construcción (fácil de predecir). § Está es la aproximación de muchas metodologías software - El diseño pretende controlar la implementación - En software las notaciones de diseño, como UML, pretenden hacer todas las decisiones de diseño y construir un plan de construcción
Cuestiones cruciales § ¿Se puede conseguir un diseño capaz de poder moldear la codificación en la actividad de construcción? § ¿Cómo de difícil es conseguir un diseño UML en un estado para poder pasarse a los programadores? El diseño UML puede ser correcto en papel, pero erróneo para la codificación. A los diseños mecánicos no les sucede esto pues están soportados por las matemáticas. § Además, en software, el tiempo (coste) de codificación es menor al de diseñar, esto no ocurre en otras ingenierías
Conclusiones § En Software el diseño requiere creatividad y talento. § Los procesos creativos no son fáciles de planificar, § La predictibilidad puede ser imposible. Deberíamos ser muy cuidadosos a la hora de hacer símiles entre ingenierías clásicas e ingeniería del software. Son actividades diferentes y requieren procesos diferentes
Error 2: Lo impredecible de los requisitos § Comprender los requisitos es duro § Uno de los motivos es la naturaleza intangible del software: sólo cuando se usa una primera versión se comprende qué es valioso y qué no lo es § Si esperásemos a tener un conjunto de requisitos estables estaríamos muertos Economía, principal fuerza del negocio Buenos requisitos ahora no lo serán mañana Algunos requisitos de negocios son impredicibles
Cómo controlar un proceso impredecible § Entonces, si no tiene sentido un proceso predecible… ¿cómo controlar? - Lo más difícil es saber dónde estamos. - Necesitamos un mecanismo de feedback que nos diga donde estamos a intervalos frecuentes, - la clave de este feedback es el desarrollo iterativo (esto no es nuevo, ha tenido muchos nombres, espiral, evolucional, incremental, etc.). - Producir versiones de trabajo con un subconjunto de las características requeridas. - Cómo de largas son las iteraciones: En XP de 1 a 3 semanas, en SCRUM un mes, etc.
Mito: "A methodology per project" § Son necesarias múltiples metodologías dependiendo del tamaño del proyecto (gente a coordinar), lo crítico del sistema y las prioridades del proyecto. § Cada proyecto merece su propia metodología y a medida. § “Peso ligero” y comunicación cara a cara son atributos deseables.
4 principios en el diseño de una metodología § Grandes metodologías para grandes equipos. § Densas metodologías para los proyectos más críticos. § El peso es costoso. § La comunicación interactiva y cara a cara es la más efectiva.
Una metodología precisa un alcance definido envisioning proposal sales setup requirements design & code test deploy train alter Project Lifecycle designer/programmer writer tester reuse point UI expert lead designer business expert expert user project manager project sponsor trainer secretary contractor night watchman janitor Roles Activities rest and recreation project development timesheets technical education vacations and basic business
Errores estándars 1. Sólo un tamaño de metodología… los proyectos varían 2. Metodología intolerante… la gente varía 3. Embellecer 4. Pesado… menos escribir 5. No probada
Principales metodologías Ágiles § XP (Extreme Programming) § Crystal Family § Adaptive Software Development § SCRUM § Feature Driven Development § DSDM (Dynamic System Development Method)
Definición § XP es una deliberada y disciplinada aproximación light al desarrollo software § Formada por pequeñas reglas o guidelines que juntas crean una nueva disciplina de desarrollo § Principal autor: - Kent Beck § Proyecto origen: - “Chrysler Comprehensive Compensation” (C3), iniciado en 1990 y convertido a XP en 1997. Para el salario de 10000 empleados
“XP es el movimiento más importante hoy en nuestro campo. Predigo que será tan esencial para la presente generación como el SEI y su CMM lo fueron en el pasado” Tom DeMarco
La polémica XP § XP cambia las asunciones comunes sobre el desarrollo software § NO al desarrollo up-front (Análisis, Diseño, etc.) § NO escribir y mantener documentación NO a los CASEs § NO a las técnicas de diseño cómo UML, principios y patrones § Para sus detractores es volver al “code and fix”
La curva del coste : cambio de asunción § La histórica curva del cambio Cambio cuando hay un error Los métodos tradicionales se han centrado en la prevención de errores en fases tempranas
La curva del coste: cambio de asunción § El diseño anticipado (antes de codificar) - crea facilidades extra para anticipar futuros requisitos (cambios) - Invertir tiempo presente para tiempo futuro. - Asume que un poco de tiempo ahora ahorrará mucho después Pero, pudiera ser más rápido diseñar después (rediseñar el código), cuando ya sabemos de verdad que es lo que hay que cambiar y no tenemos que adivinarlo
La curva del coste: cambio de asunción § La nueva curva del cambio En los entornos de hoy NO podemos prevenir lo que no conocemos Los cambios aparecen iterativamente
La curva del coste: cambio de asunción § Diseñar después…Rediseñar…Refactoring § Refactoring: “cambio hecho a la estructura interna del software para hacerlo más fácil de entender y más barato de modificar sin cambiar su comportamiento observable” (Fowler) § Si los cambios son continuos nunca completaremos un desarrollo software tradicional § ¡¡Cuánto más impredecibles sean los cambios más diseño anticipado derrocharemos!!
La curva del coste: cambio de asunción § En la actualidad Ratio de cambio alto Se impone el diseño a posteriori, el Refactoring Según esta idea el Diseño (UML) pierde sentido
La idea subyacente en XP: Riesgo § El calendario varía: “el software no estará hasta dentro de 6 meses” § Proyecto cancelado. § Ratio de defectos: tantos defectos que el software deja de usarse § Incomprensión del negocio: el software es puesto en producción pero no soluciona el problema de negocio para el que se propuso § Rotación de personal: los programadores empiezan a odiar el programa y se van El problema básico del desarrollo software es el RIESGO
La idea subyacente en XP: Riesgo “El desarrollo software falla en las entregas, y falla al entregar valor. Este fallo tiene terrible impacto económico y humano. Necesitamos otra manera de desarrollar software” Kent Beck
XP, el Miedo § Debido al miedo debe imponerse un proceso software El desarrollo software es un riesgo. La gente involucrada tiene miedo de lo que pueda salir mal. Para desarrollar eficientemente necesitamos reconocer ese miedo
Explicitación de los miedos Miedos del Cliente No conseguir lo que pidieron De pedir algo equivocado Pagar demasiado A técnicas que no controlan Nunca ver un plan significativo No saber que ocurre No poder rehacer sus decisiones No saber la verdad Miedos del Desarrollador Se les pedirá más de lo que saben hacer Se les pedirán cosas sin sentido De ser muy estúpidos Caer por la técnica Tomar responsabilidad sin autoridad Definiciones no claras Sacrificar calidad por plazos Solucionar problemas complejos sin ayuda No tener tiempo para finalizar con éxito
El cliente tiene derecho a… § un plan general, a saber qué puede realizarse, cuándo y a qué coste. § conseguir el mayor valor posible de cada semana de programación § ver la evolución en un sistema ejecutable, § cambiar de opinión, sustituir funcionalidad, y cambiar prioridades sin pagar un coste exagerado § ser informado de cambios en la agenda, en tiempo para escoger como reducir el alcance para retornar a la fecha original. § Puede cancelar en cualquier momento y quedarse con un sistema que trabaje de forma útil que refleje la inversión hasta la fecha.
El programador tiene derecho a… § saber lo que es necesario, con claras declaraciones de prioridad § producir trabajo de calidad en todo momento. § pedir y recibir ayuda de iguales, managers y clientes. § hacer y modificar sus propias estimaciones. § aprobar sus responsabilidades en vez de que sean asignadas.
Los cuatro valores § Comunicación: - XP enfoca construir persona a persona, mutua comprensión del entorno del problema mediante mínima información documental y máxima interacción cara a cara § Simplicidad - Hacer las cosas lo más simple posibles - YAGNI (You aren’t going need it) - Trabajar en una cosa errónea temprano es más derrochador que trabajar en la solución correcta después - Diseño complejo = dificil de entender = dificil de modificar - Según esto… ¿los patrones no tienen sentido?
Las 12 prácticas § Planning Game: Tres semanas por ciclo y asignando historias (características requeridas) § Small release: los más pequeñas y con el mayor valor de negocio § Metaphor: descripción general del proyecto
Las 12 prácticas § Diseño simple: - Diseñar sólo la funcionalidad requerida, NADA de futura funcionalidad - Crear el diseño que mejor pueda comunicar esa funcionalidad - “Si el futuro es incierto y puedes cambiar tus pensamientos fácilmente entonces poner funcionalidad especulante es de locos” § Refactoring: - El rediseño continuo mejora la respuesta al cambio § Testing
Las 12 prácticas § Pair Programming § Posesión colectiva: - Cualquiera del proyecto puede cambiar cualquier código en cualquier momento § Integración Continua § 40 horas por semana: - “Don´t burn out the troops” (Hightsmit) - No más de una semana con sobre tiempo
Valores y prácticas “El éxito de XP no vendrá sólo de cosas como el pair programming o 40 hour work for week, dependerá de que principios y valores se alineen con la organización” Jim Hightsmit
¿Son los patrones 23 errores en XP? § La esencia de este argumento es que los patrones son con frecuencia sobre usados. § Son buenas ideas, el problema está en su mal uso. § XP puede tratar de otra forma el uso de patrones pero no los elimina. § Los patrones son de vital importancia. Los patrones son las espina dorsal del conocimiento de diseño, tan importante como pueda serlo el proceso. § Diferentes procesos pueden enfocar el uso de patrones de diferente manera. XP enfatiza no usar patrones hasta que sea necesario.
XP y UML § El problema tiene dos causas: - Algunas personas encuentran útiles los diagramas software, otras no. Esto debe ser aceptado. - Diagramas software tienden a asociarse con procesos pesados que gastan mucho tiempo dibujando diagramas que no ayudan y que pueden ser dañinos.
Cómo usar bien los diagramas § Dibujar diagramas para una comunicación efectiva: - Seleccionar las cosas importantes y pasar por alto cosas menos importantes: § Un problema común con los diagramas es que la gente tiende ha hacerlos comprensivos. El código es la mejor fuente de información comprensiva. § Cambiar el diseño no implica necesariamente cambiar los diagramas. § Es razonable el dibujar diagramas para comprender el diseño y después tirarlos. Los diagramas no pueden ser artefactos.
¿XP contra los CASEs? § Otro uso de diagramas UML es la documentación, que generalmente reside en un CASE. § La idea es que mantener esta documentación ayuda a la gente a trabajar en el sistema. § Esto en la práctica no funciona: - Demasiado grandes para actualizarse, mala sincronización con el código. - Quedan ocultos en el CASE y nadie los mira.
Aspectos perniciosos del CASE (R.Devis) § Suele ser preferible empezar una determinada técnica “a mano”, para una tarea o rango de tareas, y después abordar su automatización. § Un procesador de textos no convierte a su usuario en escritor § Claro que “esperar al Mesías” es esperar a alguien que ya llegó. § Se pretende producir menos, no más, software de baja calidad.
Aspectos perniciosos del CASE (R.Devis) § Las herramientas CASE deben ser adquiridas-usadas por su adecuación a cada proyecto software concreto. § El costo “CASE” debe asimilarse como parte del tributo por estar en el negocio software. § Cuando se analizan e imputan costos CASE a proyectos software ha de tenerse en cuenta no sólo el costo directo de la compra, sino también los altos costos que se hubieran generado de no haber realizado tales compras.
¿Está muerto el Diseño? § NO, pero su naturaleza a cambiado. En XP el diseño: - Deseo constante por mantener el código lo más claro posible. - Refactoring permite hacer las mejoras necesarias de forma confiada - Buen conocimiento de patrones: no sólo las soluciones, también cuando usarlos y cómo evolucionan - Conocer cómo comunicar el diseño a quien necesita comprenderlo, usando código, diagramas y lo mejor… conversando.
A tener en cuenta sobre los procesos Ágiles § No deben ser usados por todo el mundo, aunque si deberían usarse por más gente de lo que ahora los usa. § Donde se utiliza mucho un “codifica y prueba” es más fácil implantar un Ágil que un Pesado. § Problema: equipos grandes § Deben usarse cuando los requisitos son volátiles. § Barrera importante: el cliente.
A tener en cuenta sobre los procesos Ágiles § Problema: ¿proyecto grande y requisitos cambiantes? § Se debe apostar por los desarrolladores: si estos están poco preparados y con poca motivación entonces es preferible un proceso predecible. § Si los requisitos son volátiles o inciertos, los desarrolladores están motivados y son responsables y el cliente comprende y se involucra, entonces Adaptativo. § Con equipos de más de 50 personas, precios fijos o alcance fijo y contrato cerrado, entonces Predictivo.
pacificspatialsolutions
riyaamemiya
egmc
ham0215
mh4gf
os1ma
tetsuyaooooo
toru_kubota
yu4u
yokawasa
pelelgrino
tsukasa_ishimaru
eitanlees
lauravandoore
jennybc
mraible
sachag
carmenintech
quramy
robhawkes
maltzj
aki_iinuma
marcduiker
andyhume
![Agile Methods y eXtreme Programming Javier Garzás [email protected] [email protected]](https://files.speakerdeck.com/presentations/023d73ad28774e4fb506140dfe3796f8/slide_0.jpg){kind=link}
