Tesis Agustin Antonio Villena Moya - Metodologias Agiles

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION

UN MODELO EMPÍRICO DE ENSEÑANZA DE LAS METODOLOGÍAS ÁGILES: EL CASO DEL CURSO CC62V –

TALLER DE METODOLOGÍAS ÁGILES DE DESARROLLO DE SOFTWARE

TESIS PARA OPTAR AL GRADO DE MAGISTER EN CIENCIAS MENCION COMPUTACION

AGUSTÍN ANTONIO VILLENA MOYA

PROFESORA GUÍA: MARIA CECILIA BASTARRICA PIÑEYRO

MIEMBROS DE LA COMISIÓN: LUIS A. GUERRERO BLANCO SERGIO OCHOA DELORENZI

YADRAN ETEROVIC SOLANO

SANTIAGO DE CHILE MARZO 2008

2

RESUMENLas metodologías ágiles de desarrollo de software, y en particular Extreme Programming (XP), constituyen una de las tendencias de mayor impacto en la industria del desarrollo de software en la última década, gracias a su enfoque centrado en la generación temprana de valor y en su acento en el aspecto humano del desarrollo de software. Su adopción sin embargo ha demostrado ser bastante compleja debido a los cambios de paradigma que ellas plantean.

Desde los inicios de estas metodologías surgió el interés de incorporar esta nueva mirada como una forma de enriquecer la formación de los futuros ingenieros de software. En este trabajo se plantea que un buen aprendizaje de las metodologías ágiles de desarrollo de software puede ser logrado por los alumnos a través de una experiencia educativa teórico-práctica basada en la aplicación de dichas metodologías en proyectos reales. Este enfoque ha sido aplicado desde el año 2002 en el curso CC62V “Taller de metodologías ágiles de desarrollo de software” del Departamento de Ciencias de la Computación de la Universidad de Chile, y en esta investigación se pone a prueba esta hipótesis, a partir del análisis de una de las instancias del curso realizada entre los meses de agosto y noviembre del año 2005.

Para realizar este análisis se construyó un modelo evaluativo de aprendizaje basado en cómo las metodologías ágiles, y en particular Extreme Programming (XP), organizan el entorno de un proyecto de desarrollo de software para mantener la sincronía entre los cambiantes elementos que allí están en juego. Dichos elementos son el problema de negocios, la tecnología, la experiencia y destrezas del equipo de desarrollo, y el producto en desarrollo.

El modelo de evaluación fue aplicado sobre los trabajos generados por los alumnos de la versión del curso usado como experimento de esta investigación, complementados con las observaciones realizadas por el profesor en la sala de clases, y otras evidencias tales como las opiniones de los clientes y una encuesta de evaluación de impacto hecha a los alumnos aproximadamente 6 meses después de finalizado el curso.

Con respecto al impacto en el aprendizaje de los alumnos, se observó una comprensión y aplicación generalizada del marco de prácticas de XP, aunque el nivel de logro estuvo muy relacionado al entorno de trabajo logrado por cada uno de los proyectos realizados. En particular se encontró que algunos elementos no considerados en la hipótesis original, tales como la complejidad del problema a resolver y la relación con el cliente, tenían también un impacto relevante sobre el éxito de los proyectos, y no sólo los aspectos pedagógicos. Se comprobó la eficacia de este modelo pedagógico que promueve el equilibro entre teoría y práctica, el ambiente humano de equipo y de colaboración con el cliente y las destrezas entrenadas. Por su parte, la práctica de XP más destacada por los alumnos es la “programación en parejas”, que presenta la mejor evaluación durante el curso y es la más aplicada a posteriori. Otra práctica que causa mucho interés es el “desarrollo guiado por test”, pero se indican problemas de tiempo y experiencia para poder aplicarla después del curso.

En lo que se refiere al modelo pedagógico aplicado para que los alumnos conozcan e internalicen las prácticas de XP, se determina que las claves de su éxito se encuentran en:

� reproducir de manera fiel el ambiente de aprendizaje colaborativo acelerado que se genera en la práctica profesional de las metodologías ágiles,

� y complementar dicho ambiente con una leve capa de acciones docentes orientadas a reflexionar y retroalimentar el dominio de la metodología.

3

AGRADECIMIENTOSEste trabajo está motivado por el cariño y consejos pedagógicos de mi esposa Pamela y el cariño de mis hijos Gerard y Rafael, y por el amor a la educación de mi familia de origen, en particular de mis padres, a quienes dedico todo el esfuerzo involucrado en esta investigación.

No quisiera dejar de mencionar a toda aquella gente que aportó con su grano de arena a esta labor: Sergio Ochoa con sus consejos para encauzar el tema dentro de las ciencias de la ingeniería, el apoyo y la confianza de Cecilia Bastarrica, los consejos de Jesús María Redondo, actual director de la Escuela de Psicología de la Universidad de Chile, quién á través de sus consejos permitió darle solidez a esta investigación desde la perspectiva educacional, y por supuesto a todos los alumnos del curso CC62V, en especial a la generación del 2005 gracias a los cuales fue posible no sólo realizar el curso sino que también extender el contacto y la reflexión mucho más allá en el tiempo y así poder efectivamente obtener un resultado acerca de la experiencia educativa vivida.

Una mención especial merece el apoyo desinteresado y fiel de mi gran amigo Carlos Henríquez, sin el cual el finalizar este trabajo no habría sido posible.

4

TABLA DE CONTENIDOSRESUMEN ...................................................................................................................................................................... 2

TABLA DE CONTENIDOS ............................................................................................................................................... 4

ÍNDICE DE ILUSTRACIONES ......................................................................................................................................... 6

ÍNDICE DE TABLAS ....................................................................................................................................................... 8

1. INTRODUCCIÓN ................................................................................................................................................. 9

2. PLAN DE TRABAJO ........................................................................................................................................ 12

2.1 HIPÓTESIS DE LA INVESTIGACIÓN ................................................................................................................................. 122.2 METODOLOGÍA ................................................................................................................................................................. 12

3. ANTECEDENTES ............................................................................................................................................. 13

3.1 EL PROBLEMA DE LA PRODUCTIVIDAD DE LA INDUSTRIA DE SOFTWARE ................................................................ 133.1.1 Aproximaciones de solución surgidas en la industria ............................................................................... 14

3.2 METODOLOGÍAS ÁGILES (MA) Y EXTREME PROGRAMMING (XP) ......................................................................... 163.2.1 Bases conceptuales de las MA ............................................................................................................................... 173.2.2 La propuesta de Extreme Programming (XP) ............................................................................................... 223.2.3 El problema de la adopción de XP en la industria ....................................................................................... 28

3.3 EL ESTADO DEL ARTE DE LA CIENCIA DEL APRENDIZAJE .......................................................................................... 333.3.1 Los antecedentes de la ciencia del aprendizaje ............................................................................................ 333.3.2 La ciencia del aprendizaje: aprender con entendimiento ........................................................................ 33

3.4 EDUCACIÓN DE LA INGENIERÍA DE SOFTWARE .......................................................................................................... 393.4.1 Objetivos y Contenidos de la Educación en Ingeniería de Software .................................................... 403.4.2 Modelos pedagógicos para la formación ingenieros de software ......................................................... 423.4.3 Desafíos en la educación de ingeniería de software ................................................................................... 443.4.4 Desafíos de la incorporación de XP en la formación de los ingenieros de software ..................... 463.4.5 Caracterización de las aplicaciones de XP en la formación académica de los ingenieros de software ........................................................................................................................................................................................... 473.4.6 Un caso destacable: Role Model Software y su Software Studio .......................................................... 49

4. PROPUESTAS .................................................................................................................................................. 52

4.1 EL CURSO CC62V “TALLER DE METODOLOGÍAS ÁGILES DE DESARROLLO DE SOFTWARE” Y SU DISEÑO

INSTRUCCIONAL ................................................................................................................................................................................ 534.1.1 Orígenes del Curso CC62V ....................................................................................................................................... 544.1.2 Contexto del curso ...................................................................................................................................................... 554.1.3 Diseño Instruccional del curso CC62V .............................................................................................................. 57

4.2 XP COMO ORGANIZADOR DE UN AMBIENTE DE DESARROLLO DE SOFTWARE ......................................................... 664.2.1 Mecanismos de sincronización/armonización en un proyecto de software organizado según XP 68

4.3 UN MODELO DE EVALUACIÓN SOBRE APRENDIZAJE DE XP CENTRADO EN EL INDIVIDUO .................................... 734.3.1 Razones para un nuevo modelo evaluativo .................................................................................................... 734.3.2 Modelo de evaluación de la experiencia ........................................................................................................... 744.3.3 Medios de recopilación de evidencias para evaluar la experiencia ..................................................... 744.3.4 Variables a medir en la experiencia ................................................................................................................... 77

5. EXPERIENCIA REALIZADA: SEMESTRE PRIMAVERA 2005 DEL CURSO CC62V .......................... 79

5.1 DESCRIPCIÓN DE LA EXPERIENCIA ................................................................................................................................ 795.1.1 Innovaciones aplicadas al diseño instruccional ............................................................................................ 795.1.2 Calendario de Actividades ...................................................................................................................................... 795.1.3 Tamaño del curso ....................................................................................................................................................... 805.1.4 Proyectos desarrollados .......................................................................................................................................... 80

5

5.2 ANÁLISIS DE RESULTADOS DE LA EXPERIENCIA .......................................................................................................... 825.2.1 Conocimientos previos .............................................................................................................................................. 825.2.2 Aprendizajes logrados durante el curso ........................................................................................................... 825.2.3 Calidad en la reproducción del ambiente XP durante el curso .............................................................. 855.2.4 Percepciones de los clientes ................................................................................................................................... 875.2.5 Encuesta de impacto post curso ........................................................................................................................... 89

6. RESULTADOS ADICIONALES ...................................................................................................................... 96

6.1 MEJORAS PARA FORTALECER EL DISEÑO INSTRUCCIONAL DEL CURSO .................................................................... 966.1.1 Explicar XP a partir del nuevo modelo planteado en esta investigación. ......................................... 966.1.2 Estrategias para evitar malos entendidos de las prácticas de XP ........................................................ 966.1.3 Pre-selección de los proyectos a trabajar ........................................................................................................ 976.1.4 Involucramiento temprano de los alumnos en la plataforma tecnológica y en el problema ... 976.1.5 Implementar un sistema emergente de organización en los equipos ................................................. 976.1.6 Establecer una base temprana de código funcional ................................................................................... 986.1.7 Fortalecer la aplicación del modelo de aprendizaje cognitivo .............................................................. 98

6.2 ENUNCIACIÓN DE CLAVES DEL MODELO PEDAGÓGICO APLICADO ............................................................................. 986.2.1 Propuesta de prácticas pedagógicas ágiles ................................................................................................. 101

7. CONCLUSIONES ............................................................................................................................................ 103

7.1 HIPÓTESIS 1: ES POSIBLE LA REPRODUCCIÓN EFECTIVA DE UN AMBIENTE DE DESARROLLO ÁGIL (XP) EN UN

CURSO UNIVERSITARIO ................................................................................................................................................................. 1037.2 HIPÓTESIS 2: LA EXPOSICIÓN DE LOS ALUMNOS A UN DESARROLLO AUTÉNTICO EN UN AMBIENTE ÁGIL GENERA

BUENOS APRENDIZAJES SOBRE LAS METODOLOGÍAS ÁGILES .................................................................................................. 104

8. TRABAJO FUTURO ....................................................................................................................................... 106

8.1 APLICACIÓN DEL DISEÑO INSTRUCCIONAL (O ELEMENTOS DE ÉSTE) EN MÁS CURSOS DE LA CARRERA ......... 1068.2 LÍNEAS DE DESARROLLO PARA EL MODELO EXPLICATIVO DE XP Y SU MODELO EVALUATIVO DERIVADO. ..... 1068.3 APLICAR ESTE MODELO PEDAGÓGICO A LA CAPACITACIÓN DE PROFESIONALES ................................................. 1068.4 VALIDAR LA RELACIÓN ENTRE CONTRUCTIVISMO Y MÉTODOS ÁGILES, Y COMO ESTA RELACIÓN POTENCIARÍA

LOS APRENDIZAJES ........................................................................................................................................................................ 107

9. REFERENCIAS Y BIBLIOGRAFÍA .............................................................................................................. 108

10. ANEXOS ...................................................................................................................................................... 111

10.1 DESCRIPCIÓN DETALLADA DE LA EXPERIENCIA ...................................................................................................... 11110.1.1 Fase teórica ........................................................................................................................................................... 11110.1.2 Fase práctica ........................................................................................................................................................ 113

10.2 HERRAMIENTAS DE EVALUACIÓN UTILIZADAS ......................................................................................................... 15510.2.1 Encuesta de co-evaluación ............................................................................................................................. 15510.2.2 Encuesta al cliente ............................................................................................................................................. 15610.2.3 Pauta de Evaluación de Ensayo de XP y Opinión del Primer Ciclo ............................................... 15710.2.4 Pauta de Evaluación del Proyecto y Proyección a la Vida Profesional ...................................... 159

10.3 RESUMEN DE ENSAYOS DE ALUMNOS ......................................................................................................................... 16110.3.1 Proyecto Mapache ............................................................................................................................................. 16110.3.2 Proyecto XMLSync .............................................................................................................................................. 167

6

ÍNDICE DE ILUSTRACIONES

Ilustración 1: Funciones desarrolladas en un software y su nivel de uso efectivo por parte de los usuarios. [48] .......................................................................................................................................................................... 14

Ilustración 2: Complejidad de un NPD de acuerdo a sus niveles de incertidumbre .......................................... 17Ilustración 3: Comparación entre el valor generado por un proyecto tradicional y lo que sería ideal ..... 18Ilustración 4: Curva de costo de cambio tradicional versus la revisada ................................................................. 19Ilustración 5: El ambiente del desarrollo de software .................................................................................................... 21Ilustración 6: El desarrollo de un software a través de la metáfora del desarrollo de un columpio .......... 22Ilustración 7: Flujo del trabajo en XP ...................................................................................................................................... 25Ilustración 8: Ritmos de XP ....................................................................................................................................................... 26Ilustración 9: La interrelación de prácticas de XP, según Kent Beck en la primera edición de "Extreme

Programming Explained"[6] ............................................................................................................................................ 27Ilustración 10: Flujo de pasos del modelo pedagógico de Aprendizaje Cognitivo .............................................. 38Ilustración 11: Áreas curriculares de la computación propuestas por CC2001. ................................................. 39Ilustración 12: Niveles de cursos y estrategias de implementación ......................................................................... 40Ilustración 13: Ambiente de trabajo del Software Studio .............................................................................................. 50Ilustración 14: Carrera de Ingeniería Civil en Computación y el contexto en donde se aplica el curso

CC62V ......................................................................................................................................................................................... 55Ilustración 15: Relación entre los diversos integrantes del curso ............................................................................. 60Ilustración 16: Presentación de valores asociando los principios a cada uno de ellos .................................... 62Ilustración 17: Organizador de prácticas de XP por afinidad ...................................................................................... 63Ilustración 18: El complejo entorno de un proyecto de software desde la mirada de un ingeniero de

software ..................................................................................................................................................................................... 66Ilustración 19: Ciclos de sincronización de un proyecto organizado en torno a XP .......................................... 68Ilustración 20: Entorno de desarrollo de software organizado por las prácticas de XP .................................. 69Ilustración 21: Flujo del Planning Game. ............................................................................................................................... 70Ilustración 22: Contraste entre el modelo evaluativo usado en el curso y de la investigación ..................... 73Ilustración 23: Versión adaptada de la Taxonomía de Bloom por la American Psichology Association .... 77Ilustración 24: Planificación inicial del curso ..................................................................................................................... 80Ilustración 25: Mapa global de comprensión de prácticas ............................................................................................ 82Ilustración 26: Mapa global de evaluación de aplicación de prácticas .................................................................... 85Ilustración 27: Comparación entre plan inicial y lo sucedido en los proyectos realizados ........................... 86Ilustración 28: Opinión del cliente del proyecto Mapache sobre los alumnos .................................................... 88Ilustración 29: Opinión del cliente del proyecto XMLSync sobre los alumnos .................................................... 89Ilustración 30: Gráfico de evaluación a posteriori de los alumnos ............................................................................ 90Ilustración 31: Aspectos destacados del curso según nº de menciones recibidas ............................................. 90Ilustración 32: Rememoración de prácticas de XP ........................................................................................................... 92Ilustración 33: Ilustración 36: Rememoración de prácticas de XP por proyecto ................................................ 93Ilustración 34: Aplicación de elementos de XP ................................................................................................................... 94Ilustración 35: Aplicación deseada por los alumnos pero no lograda ..................................................................... 95Ilustración 36: Complementación natural entre XP y el modelo pedagógico del curso CC62V .................... 99Ilustración 37: Cómo el modelo pedagógico de aprendizaje se realiza en el curso CC62V ......................... 100Ilustración 38: Prácticas pedagógicas instaladas sobre XP ........................................................................................ 101Ilustración 39: "Cómo funciona XP" ..................................................................................................................................... 111Ilustración 40: Reglas para clientes y desarrolladores ............................................................................................... 111Ilustración 41: eXtreme Hour – “Equipo de desarrollo” frente a los “clientes” ................................................. 111Ilustración 42: eXtreme Hour – Los “clientes" inspeccionando el trabajo realizado ..................................... 111Ilustración 43: eXtreme Hour – Tarjetas con las "Historias de usuario" que describen las características

de la máquina ficticia. ....................................................................................................................................................... 112Ilustración 44: eXtreme Hour – Máquina Ficticia: "Producto" generado en el taller ..................................... 112Ilustración 45: Charla sobre Desarrollo Guiado por Tests dada por un alumno .............................................. 113

7

Ilustración 46: Plan inicial del proyecto, construido con post-it's pegados en un papelógrafo, para su fácil remoción, almacenado y reinstalación en cada sesión ............................................................................ 115

Ilustración 47: Alumnos colaborando con el cliente (sentado frente al computador del medio) ............ 117Ilustración 48: Plan de inicios de la segunda iteración ................................................................................................ 124Ilustración 49: Plan al finalizar el proyecto ...................................................................................................................... 127Ilustración 50: Plan inicial del proyecto, construido con post-it’s pegados en un papelógrafo, para su

fácil remoción, almacenado y reinstalación en cada sesión ............................................................................ 135Ilustración 51: Coach (a la izquierda) liderando el análisis del problema ......................................................... 138Ilustración 52: Equipo presentando algunos avances al cliente .............................................................................. 139Ilustración 53: Papelógrafo con el plan obtenido al finalizar la primera iteración ......................................... 146Ilustración 54: Plan final del proyecto ................................................................................................................................ 150

8

ÍNDICE DE TABLAS Tabla 1: Resultados comparados entre 1994 y 2004 [48] ............................................................................................ 13Tabla 2: Sobretiempo y efectividad comparada entre 2000 y 2003 [48] .............................................................. 13Tabla 3: Principios Ágiles ............................................................................................................................................................. 16Tabla 4: Declaración de derechos de clientes y desarrolladores ................................................................................ 20Tabla 5: Buenas prácticas de la industria del software y su versión XP ................................................................. 23Tabla 6: Principios de XP según Kent Beck en "Extreme Programming Explained” .......................................... 25Tabla 7: Comparación entre los conceptos tradicionales y los de XP ....................................................................... 29Tabla 8: Comparación entre prácticas de desarrollo tradicional y XP .................................................................... 29Tabla 9: Contraste entre planificación según XP y su interpretación por un equipo de desarrollo ........... 30Tabla 10: Comparación entre el aprendizaje de personas comunes y estudiantes ........................................... 36Tabla 11: Desafíos derivados de llevar el modelo del taller de oficios a la sala de clases .............................. 37Tabla 12: Propuestas para las hipótesis de esta investigación ................................................................................... 52Tabla 13: Desafíos de la enseñanza de la Ingeniería de Software y cómo XP puede ayudar a abordarlos

....................................................................................................................................................................................................... 54Tabla 14: Esquema estructurado de actividades del curso ........................................................................................... 61Tabla 15: Reglas de convivencia entre clientes y desarrolladores ............................................................................ 64Tabla 16: Estructura de una sesión del curso ..................................................................................................................... 65Tabla 17: Desafíos del Ingeniero de Software en un Proyecto de desarrollo ....................................................... 67Tabla 18: Desafíos de un coach .................................................................................................................................................. 67Tabla 19: Desafíos de un tracker ............................................................................................................................................... 67Tabla 20: Resumen de mecanismos de sincronización de un proyecto de software XP .................................. 72Tabla 21: ítems de evaluación del cliente ............................................................................................................................. 75Tabla 22: Rango de evaluación ocupada por el cliente ................................................................................................... 75Tabla 23: Ítems de co-evaluación ............................................................................................................................................. 76Tabla 24: Rango de evaluación utilizado en las co-evaluaciones ............................................................................... 76Tabla 25: Variables que miden el aprendizaje logrado por los alumnos en el curso ........................................ 78Tabla 26: Áreas en donde hubo problemas de aplicación de XP y la mejora propuesta .............................. 104Tabla 27: pre-conceptos de los alumnos versus conceptos ágiles .......................................................................... 104Tabla 28: Prácticas que deben ser mejor presentadas a los alumnos .................................................................. 105Tabla 29: Comparación entre el plan original y lo realmente sucedido en el proyecto Mapache ............ 114Tabla 30: Matriz del Plan Proyecto Mapache Ciclo 1 .................................................................................................... 116Tabla 31: Plan de la segunda parte del proyecto. En gris se destaca lo no implementado .......................... 125Tabla 32: Comparación entre el plan original y lo realmente sucedido en el proyecto XMLSync ............ 134

9

1. INTRODUCCIÓNDesde fines de la década pasada, las metodologías ágiles han propuesto un nuevo paradigma para el desarrollo de software, que establece la incertidumbre y el consecuente cambio como realidades intrínsecas a esta actividad, tanto en lo que se refiera a los problemas a resolver como en las formas de solucionarlos.

El interés de la industria por este nuevo enfoque, liderado por la metodología ágil más difundida “Extreme Programming” (XP), también ha sido recogido por la academia, que la ha ido incorporando en la formación de los nuevos ingenieros de software. Sin embargo esta inserción no es simple debido a que las metodologías ágiles revisan e incluso contradicen paradigmas instalados fuertemente en la práctica pedagógica académica, tales como el modelo de ciclo de vida de cascada o la curva de costo exponencial del cambio a lo largo de un desarrollo de software

En las experiencias académicas documentadas en los últimos años, se pueden observar dos aproximaciones para la introducción de las metodologías ágiles: una parcial, que incorpora prácticas ágiles de manera aislada como la “programación de a pares” o el “desarrollo guiado por pruebas”, y otra más integral, a través de cursos especializados en la materia. Lo que llama la atención es que los proyectos abordados suelen no ser reales, es decir, se diseñan requerimientos ficticios y personas que actúan el rol de cliente, sin serlo en realidad, paradigma que incluso se repite en experiencias en donde se cuenta con el apoyo directo de empresas reales. Un modelo alternativo de formación de ingenieros de software lo representa el “Software Studio” de la empresa Role Model Software[53], en donde se reproduce un taller de oficios. En éste taller “maestros desarrolladores de software” van guiando y formando a los nuevos desarrolladores-aprendices a medida que éstos se van incorporando a la empresa a través del uso de metodologías ágiles.

En la experiencia local tenemos que desde el año 2002 se lleva a cabo en el Departamento de Ciencias de la Computación de la Facultad de Ciencias Físicas y Matemáticas de la Universidad de Chile el curso CC62V: “Taller de metodologías ágiles de desarrollo de software”, el cual, usando la aproximación pedagógica “aprender haciendo”, es decir, trabajando en proyectos con necesidades y clientes auténticos, ha obtenido resultados bastante interesantes tanto desde la perspectiva de los alumnos como la de los clientes que han participado. Tanto los alumnos como clientes han destacado el buen ambiente humano vivido, los alumnos demuestran un dominio aceptable de los conceptos y prácticas ágiles y los productos de software generados en el curso han sido satisfactorios y entregados sin ocupar ni tiempo ni recursos adicionales a los predefinidos en el curso. Todo lo anterior no deja de llamar la atención, no sólo desde la perspectiva del éxito del enfoque ágil, sino que también desde el punto de vista pedagógico, dado que la estrategia educativa aplicada ocupa un modelo de enseñanza muy distinto al común de los cursos de la carrera.

El objetivo de esta investigación por ende es comprobar mediante un análisis acucioso de un semestre del curso CC62V estos buenos resultados observados de manera informal, buscando además determinar las claves que explican los resultados del modelo pedagógico aplicado en el curso, y el real impacto logrado por éste en los aprendizajes de los alumnos que cursan dicho ramo.

El experimento en cuestión fue realizado durante el curso realizado en el período agosto-noviembre del año 2005. En ese curso se recopilaron un conjunto de evidencias sobre la experiencia educativa:

10

� ensayos de opinión de los alumnos sobre XP,

� ensayos de evaluación del uso de XP en los proyectos de desarrollo abordados en el curso,

� las evaluaciones realizadas por los clientes de los proyectos,

� y una encuesta de evaluación de impacto realizada a los alumnos a partir de 6 meses después de finalizado el curso.

Se realizó un estudio acerca de la problemática de la adopción de las metodologías ágiles en la industria, el estado del arte de las ciencias de aprendizaje, el estado del arte de la educación en ingeniería de software y sobre las experiencias documentadas de incorporación de metodologías ágiles en la formación en dicha ingeniería.

Se documentó el diseño instruccional que se aplica en el curso, explicando como éste busca reproducir de la manera más fiel posible un entorno de desarrollo ágil. Adicionalmente se elaboró un nuevo modelo evaluativo orientado a determinar el real grado de aprendizaje de los alumnos del curso desde la perspectiva ágil. Dicho modelo está basado en cómo las metodologías ágiles – y en particular XP – organizan el entorno de un desarrollo de software para mantener la sincronía entre los cambiantes componentes que allí están en juego, tales como el problema de negocios, la tecnología, la experiencia y destrezas del equipo de desarrollo, y el producto en desarrollo.

Al aplicar el nuevo modelo evaluativo sobre las evidencias recopiladas, se pudo observar que los alumnos adquieren durante el curso una comprensión bastante completa del complejo marco de prácticas de XP, complementada con una aplicación de dichas prácticas en los proyectos abordados. Sin embargo se observa que el nivel de logro está muy relacionado al entorno de trabajo logrado por cada uno de los proyectos realizados. En particular se encontró que algunos elementos no considerados anteriormente, tales como la complejidad del problema y la relación con el cliente, tenían también un impacto relevante sobre el éxito de los proyectos, y no sólo los aspectos pedagógicos. Por otra parte, se comprobó la eficacia de este modelo pedagógico que promueve el equilibro entre teoría y práctica, el ambiente humano de equipo y de colaboración con el cliente y las destrezas entrenadas. En lo que se refiere a la adopción de prácticas de XP, la más destacada por los alumnos es la “programación de a pares”, que presenta la mejor evaluación durante el curso y es la más aplicada a posteriori. Otra práctica que causa mucho interés es el “desarrollo guiado por test”, pero se indican problemas de tiempo, y experiencia para poder aplicarla después del curso.

En lo que se refiere al modelo pedagógico aplicado para que los alumnos conozcan e internalicen las prácticas de XP, se determinó que las claves de su éxito se encuentran en el reproducir de manera fiel el ambiente de aprendizaje colaborativo acelerado que generan las metodologías ágiles, y complementar dicho ambiente con una leve capa de acciones docentes orientadas a reflexionar y retroalimentar el dominio de la metodología.

Como antecedentes de esta investigación se presentarán las bases de las metodologías ágiles, y la experiencia recopilada en la industria y la academia en torno a los desafíos que plantea su adopción y las formas de abordar este tema. También se presentan los últimos avances de las ciencias del aprendizaje y los lineamientos actuales para la formación de ingenieros de software. Los antecedentes de esta investigación son completados por una descripción del contexto de la carrera de Ingeniería civil en Computación de la Universidad de Chile, que es en donde se enmarca la experiencia analizada. Posteriormente se presenta el diseño del experimento realizado y del modelo evaluativo que se usó para analizar los resultados obtenidos. Luego se describe la experiencia realizada incorporando los análisis de

11

aprendizajes logrados por los alumnos a lo largo de cada uno de los proyectos abordados durante el curso. Finalmente, se presentan las conclusiones de esta investigación, con una definición de cuáles son los logros del modelo pedagógico aplicado, las posibles mejoras que pueden aplicarse y la formulación de las claves de éxito de dicho modelo, enunciadas como prácticas complementarias a las tradicionales de las metodologías ágiles y en particular de XP.

12

2. PLAN DE TRABAJO

2.1 Hipótesis de la InvestigaciónLas hipótesis que se busca poner a prueba en esta investigación son:

1. Es posible la reproducción efectiva de un ambiente de desarrollo ágil (XP) en un curso universitario: Se puede ofrecer a los alumnos de ingeniería de software una experiencia representativa de las metodologías ágiles - en particular Extreme Programming – dentro del marco, recursos y tiempo de un curso normal de la carrera.

2. La exposición de los alumnos a un desarrollo auténtico en un ambiente ágil genera buenos aprendizajes sobre las metodologías ágiles. Gracias a la naturaleza de los ambientes de desarrollo ágil, que están orientados a potenciar el aprendizaje continuo en sus integrantes para así lograr la mayor productividad, al reproducirlos fielmente en el contexto de un curso de Ingeniería de Software se obtienen buenos resultados en los aprendizajes de los alumnos.

2.2 MetodologíaEl plan de trabajo aplicado seguido en este trabajo comprendió las siguientes actividades:

� Definición de bases conceptuales, en lo que se refiere al origen de las metodologías ágiles, la ciencia del aprendizaje y su aplicación a la formación de ingenieros de software.

� Conceptualización del problema. Mediante un estudio del estado del arte de la adopción de XP tanto en la academia como en la industria, se definieron los desafíos a abordar en la adopción de buenas prácticas por parte de los desarrolladores. También se analizó el contexto de la carrera en la que se encuentra inmerso este curso.

� Documentación del diseño instruccional de enseñanza de metodologías ágiles aplicado en el curso CC62V “Taller de Metodologías Ágiles de Desarrollo de Software” que se imparte desde el 2002 en el Departamento de Ciencias de la Computación de Facultad de Ciencias Físicas y Matemáticas de la Universidad de Chile.

� Recopilación de evidencias sobre la experiencia de curso realizado en el período agosto-noviembre de 2005. Consistió en la captura de evidencias de aprendizaje desde el curso mencionado, las que fueron usadas en el posterior análisis usando el modelo evaluativo preparado.

� Elaboración de modelo evaluativo, se definió un modelo evaluativo que permitiese, medir el impacto en el aprendizaje de los alumnos sobre metodologías ágiles obtenido mediante la aplicación del diseño instruccional de CC62V.

� Evaluación de la efectividad del modelo de adopción. A partir de las evidencias recogidas en la experiencia, realizar un análisis de los aprendizajes logrados por los alumnos.

� Elaboración de proyecciones del trabajo, en particular definir mejoras al diseño instruccional del curso y enunciar las claves metodológicas que sustentan los buenos resultados percibidos.

13

3. ANTECEDENTES

3.1 El problema de la productividad de la industria de softwareDesde 1994 la consultora norteamericana “The Standish Group” realiza en EEUU un estudio bi-anual llamado “The Chaos Report” [27] cuyo objetivo es medir la efectividad lograda por los proyectos de software, en base a criterios tales como:

� cumplimiento y desviación con respecto a metas de tiempo y costos

� porcentaje de funcionalidad útil realmente lograda

Año 1994 2003 exitosos 16% 34% abortados 31% 15% con problemas 53% 51%

Tabla 1: Resultados comparados entre 1994 y 2004 [48]

Como es posible observar en la Tabla 1, ha existido un aumento en los proyectos exitosos (es decir, que son terminados dentro de los plazos y costos esperados, y que entregan el valor suficiente) pero la cantidad de proyectos en problemas se mantiene casi igual. El aumento promedio por año en la cantidad de proyectos exitosos es pequeño, apenas superior a un 1%, lo que, proyectado en el tiempo arrojaría que para lograr un 50% de proyectos exitosos tenemos que esperar por lo menos hasta el 2015. Sin embargo, existen otros antecedentes que ponen en peligro incluso esta predicción.

Año 2000 2003 sobretiempo promedio 63% 82% % de funcionalidades requeridas logradas 67% 52%

Tabla 2: Sobretiempo y efectividad comparada entre 2000 y 2003 [48]

Tal como es posible observar en la Tabla 2, el sobretiempo sufrido por los proyectos está en aumento, y, lamentablemente, cada vez se logra menos de las funcionalidades esperadas, lo que se refleja en la Ilustración 1, en donde se grafica la proporción de funcionalidades que los clientes declaran realmente usar en los software que reciben.

14

Ilustración 1: Funciones desarrolladas en un software y su nivel de uso efectivo por parte de los usuarios.

[48]

Esta realidad fue la que llevó a acuñar a Kent Beck la siguiente frase: “El Software falla en ser entregado… y falla en entregar valor” [6].

3.1.1 Aproximaciones de solución surgidas en la industria Como una forma de paliar esta situación, ya desde los ‘70 se han planteado modelos de ciclo de vida que dan una estructura más ordenada a los proyectos de software, donde destaca por su penetración en la industria y la academia el conocido ciclo de vida de cascada [44]. Este define un conjunto de pasos secuenciales para el desarrollo de software, donde se hace énfasis en que el equipo de desarrollo debe obedecer un proceso pre-definido, generando diversos productos intermedios durante el desarrollo, tales como documentos de análisis, diseño, pruebas, etc. Surgió entonces, en la década de los ’90, la tendencia a generar formalismos para facilitar la creación de estos artefactos intermedios, y de herramientas de software para apoyar su desarrollo - denominadas CASE1

Uno de los enfoques más destacados de esta tendencia surge a mediados de los ’90 el “Rational Unified Process” (RUP)

- cuya promesa consiste en generar software funcional a partir de modelos de alto nivel.

2

� requiere de una elevada curva de aprendizaje de los formalismos,

, basado en el formalismo UML que representa la ambición de abracar en un solo modelo de proceso cualquier desarrollo de software, sin importar su naturaleza o tamaño. El valor aportado por estas propuestas no es gratis:

� un alto costo de licencias en las herramientas asociadas,

� un gran esfuerzo en horas hombre requerido para gestionar, y controlar el desarrollo,

RUP genera una cantidad no despreciable de productos intermedios requeridos por la metodología: diagramas y especificaciones de casos de uso, diagramas de clases, diagramas de componentes, etc., los que si bien tienen valor, no son el producto final que se busca lograr: software funcional.

Debido a lo anterior, a este tipo de metodologías se les comenzó a denominar “metodologías pesadas”, quedando abierta la discusión acerca de cómo ofrecer una respuesta directa al

1 Computer Assisted Software Engineering 2 http://www-306.ibm.com/software/awdtools/rup

Nunca45%

Raramente19%

Algunas veces16%

Frecuentemente13%

Siempre7%

Uso de Funcionalidades de Software

15

problema de generar productos de software de alta calidad en un ambiente de cambio acelerado, pero además mejorando la relación costo-eficiencia [54].

Otro enfoque con gran presencia en la industria es representado por el Capability Maturity Model [41] que consiste en un modelo de referencia de mejora en etapas propuesto para las organizaciones que desarrollan software, desde el nivel inicial denominado caótico hasta un nivel en el cual la organización pueda aprender y optimizar permanentemente su forma de trabajar. La versión más actualizada de CMM, denominada Capability Maturity Model Integration (CMMi) agrega un fuerte componente de la planificación detallada y de control centralizado a la gestión del desarrollo de software, lo que implica un giro hacia la mirada de la tradicional gestión Tayloriana en donde el foco del trabajo está en seguir estrictamente un plan predefinido, generándose así una fuerte resistencia al cambio e inflexibilidad. [43]

16

3.2 Metodologías Ágiles (MA) y Extreme Programming (XP)Eclipsadas por el imperante paradigma secuencial del desarrollo de software, ya desde los ’60 se plantearon propuestas de ciclos de vida según el modelo iterativo e incremental de desarrollo de software, en donde el ciclo de vida espiral [11] - consistente en la descomposición de los proyectos en mini-cascadas sucesivas dirigidas cada una de ellas a abordar los riesgos - es quizás uno de los más conocidos. En estos modelos iterativos se reconoce la necesidad de la comunicación y el aprendizaje como herramientas cruciales para poder generar soluciones de calidad [29], enfocándose así en las necesidades de las personas que realizan los proyectos por sobre los pasos que ellos debieran seguir.

De acuerdo a esta mirada centrada en el potenciamiento del recurso humano, a mediados de los ’90 comenzó a surgir una alternativa a las metodologías pesadas. El hito seminal de una nueva mirada “liviana” al desarrollo de software tuvo lugar en el proyecto Chrysler Compensation Center en 1996, en donde comenzó a cristalizarse la metodología semi-formal “Extreme Programming” (XP), que recibe su nombre de la intención de llevar al máximo buenas prácticas de desarrollo de software. Esta propuesta se fue tejiendo en las páginas del primer wiki-wiki3

[6]

desde 1996, hasta que en 1999 se publicó el libro “Extreme Programming Explained” , que constituye el punto de partida de la difusión de esta nueva mirada.

Siguiendo el camino de XP, surgieron otras propuestas similares tales como la australiana “Feature Driven Development”4, las norteamericanas “SCRUM”5, “Crystal Clear”6, y la europea “Dynamic Systems Development Model”7

Tabla 3

. En el año 2001, los líderes de este movimiento se reunieron para acordar un piso común de discurso. Es así que acordaron la denominación “ágil” para este tipo de metodologías – en vez del equívoco término “livianas” - y redactaron el “Manifiesto Ágil”, donde se definieron 4 principios que establecen los criterios del movimiento ágil, que se presentan en la .

Individuos e interacciones

por sobre

Procesos y herramientas.

Software funcional Documentación exhaustiva

Colaboración con el cliente Negociación de contratos

Responder al cambio Seguir un plan

Tabla 3: Principios Ágiles

A partir de entonces, la influencia de este tipo de metodologías ha sido notoria, – hay miradas incluso que han tratado de asimilar XP a una configuración específica de RUP - aunque no exenta de polémica [51], existiendo estudios que afirman el crecimiento sostenido de su adopción en la industria del software [40], incluyendo a corporaciones de la importancia de Microsoft8, Yahoo9 y Google10

3 http://c2.com/wiki 4 http://www.featuredrivendevelopment.com/ 5 http://jeffsutherland.com/scrum/ 6 http://alistair.cockburn.us/crystal/wiki 7 http://na.dsdm.org/ 8 Darryl K. Taft, “Microsoft Lauds 'Scrum' Method for Software Projects”, eWeek.com,

http://www.eweek.com/article2/0,1895,1885883,00.asp 9 Pete Deemer, “How and Why go Agile”, http://www.agileadvice.com/archives/2005/05/scrum_gathering.html 10 Dentro de los requisitos para trabajar en algunos de los proyectos de Google, se plantea como deseable tener experiencia en

metodologías ágiles. (http://www.google.com/support/jobs/bin/answer.py?answer=23712&query=agile&topic=0&type=agile)

.

17

3.2.1 Bases conceptuales de las MALas metodologías ágiles basan su propuesta en una revisión de la naturaleza del desarrollo de software surgida a la luz de nuevas teorías económicas generadas a raíz de la innovación tecnológica de las últimas décadas. En 1986, surge el concepto “desarrollo de nuevo producto” (NPD por su sigla en inglés11

[52]) para referirse a todo esfuerzo por llevar un nuevo producto al

mercado . A diferencia de la “manufactura predecible”, en los NPD no es posible predecir con precisión los tiempos y plazos que se deberían invertir para implementar un producto terminado. Al contrario, mientras más se avance en la solución del problema (y por ende en su comprensión), mejor será la capacidad de estimar [31]. Esto se debe a que en los NPD existen dos dimensiones de incertidumbre: la (in)certeza acerca de la tecnología, y el nivel de acuerdo en los requerimientos con los clientes, tal como se observa en la Ilustración 2:

Ilustración 2: Complejidad de un NPD de acuerdo a sus niveles de incertidumbre

Un ejemplo típico de un desarrollo con alta incertidumbre de requerimientos pero tecnológicamente cierto es el componente de un sistema que entrega datos a otros. Existen un sinnúmero de tecnologías para enfrentar esta labor, pero acordar qué datos exactos generar es lo realmente complejo. Un ejemplo contrario – simple en requerimientos pero complejo tecnológicamente – sería un sistema de transporte de pasajeros a la Luna. Existe muchísima experiencia de servicios similares – buses, trenes, etc. – pero lo realmente complejo es como implementar tecnológicamente el servicio.

La estrategia propuesta para enfrentar el desafío de un NPD es comparada con la formación de jugadores del rugby llamada Scrum, en donde se forma un grupo cohesionado de profesionales que integra todas las competencias (comerciales, técnicas, operacionales) necesarias para poder definir e implementar el producto. En este esquema, la estrategia ágil

11 New Product Development

ComplicadoComplicado

ComplicadoComplicado

ComplejoComplejo

SimpleSimple

Anarqu

Anarquííaa

Alta Certeza Baja Certeza

Alt

o A

cuer

do

Bajo

Acu

erd

o

Tecnología

Requ

erim

ient

os

18

consiste en una relación colaborativa entre clientes y desarrolladores, a través de la cual se van disminuyendo progresivamente los niveles de incertidumbre en un modelo denominado concurrente, en oposición al tradicional modelo de pasos secuenciales característicos de un modelo cascada. Al ir avanzando en el trabajo es natural entonces que surjan cambios que alteren el plan original de trabajo, siendo el “ajuste de planificación” la labor más cotidiana de gestión en el modelo ágil, en oposición al “control de ejecución del plan” de los modelos secuenciales.

Aumentando la curva de valorTal como fue visto en la sección 3.1, la producción de real valor para el cliente es uno de los mayores problemas de la industria y que, a pesar de todos los esfuerzos, se ha ido acentuando. Es característico de los proyectos de software que el cliente sólo pueda recibir valor - medida en funcionalidades efectivas del sistema - por su inversión al final del proyecto. Esto es debido, entre otras razones, a que los desarrolladores tienen una mirada tecno céntrica, priorizando desarrollos que les “faciliten el trabajo a futuro” (como por ejemplo implementar una infraestructura de Base de datos con mantenedores simples de información) antes de preocuparse de poner en producción funcionalidades que sean directamente útiles a su cliente. Esta situación, contrastada con la ideal, es reflejada en la Ilustración 3:

Ilustración 3: Comparación entre el valor generado por un proyecto tradicional y lo que sería ideal

¿Cómo es posible entonces generar este mayor valor promedio? El principio básico que las MA proponen es realizar un diseño simple, con la ingeniería justa para cumplir con los requerimientos inmediatos del cliente, e ir empaquetando estos en entregables funcionales de forma periódica. En la visión ágil, esto es facilitado por el concepto del Scrum generado entre clientes y desarrolladores, pero tiene una fuerte amenaza radicada en el tradicional concepto de que cambiar es algo costoso en un proyecto de software, y que lo es en mayor medida a medida que el proyecto avanza. Esta creencia es la gran generadora de “sobrediseño” (también llamada “sobreingeniería”), que consiste en generar diseños demasiado ambiciosos y tempranos, antes de que se haya alcanzado la madurez suficiente para saber qué es lo que realmente se necesita, con el consecuente riesgo de generar funcionalidades de software que finalmente no son utilizadas, lo que constituye en sí un desperdicio no sólo por el tiempo que se invirtió en definir y desarrollar dichas funcionalidades, sino por el que se tendrá que invertir en mantener el código fuente del sistema.

tiempo

funci

onal

idad

es

tiempo

funci

onal

idad

es

tiempo

funci

onal

idad

es

tiempo

funci

onal

idad

es

tiempo

funci

onal

idad

es

tiempo

funci

onal

idad

es

tiempo

funci

onal

idad

es

tiempo

funci

onal

idad

es

Valor entregado de un proyecto tradicionalValor entregado de un proyecto tradicional Valor ideal que debiera entregar un proyectoValor ideal que debiera entregar un proyecto

19

La revisión a la curva del cambio y la estrategia del timeboxing con contratos de alcance variablePara lograr la agilidad necesaria para producir real valor lo más pronto posible, las metodologías ágiles se basan en una revisión de la curva del costo del cambio para un proyecto de software, tal como se observa en la Ilustración 4.

Ilustración 4: Curva de costo de cambio tradicional versus la revisada

Es decir, se plantea un modelo en donde el cambio es económicamente aceptable, y por lo tanto es posible adaptarse rápidamente a cambios en los requerimientos. Para poder lograr la curva de la derecha es necesario revisar las variables de gestión usadas predominantemente en la industria:

� Alcance : la funcionalidad esperada del sistema

� Recursos: que se deben invertirse en el proyecto

� Tiempo: que se estima necesario para lograr el alcance

Existe además una cuarta variable, muchas veces oculta: la Calidad (entendida como eficacia, eficiencia y resistencia a fallas). Usualmente en los contratos de software se fijan las tres primeras variables (por ej.: se deben realizar las funcionalidades X,Y,Z con R recursos dentro de un tiempo T). Debido a la incertidumbre, es muy probable que surjan cambios a medida que se vaya conociendo más del problema, tanto de requerimientos por parte del cliente como de las estimaciones por parte del desarrollador, pero ante la rigidez de las variables antes nombradas, la única que queda para ajustar es la calidad, implicando por ejemplo menos tiempo para pruebas, lo que redunda necesariamente en un conflicto dado que ningún cliente quiere realmente algo de poca calidad y ningún desarrollador se sentirá satisfecho con un entorno que lo fuerce a realizar un mal trabajo.

La segunda variable más elástica es el tiempo, dado que en caso de que un proyecto no cumpla con el alcance (aun con una calidad mínima) el plazo tiende a extenderse, es decir, el proyecto se “atrasa”.

Es por esto que se propone una nueva mirada, en la que Tiempo, Recursos y Calidad quedan fijos (dado que en realidad, todas estas variables no tienen mucha elasticidad), dejando el Alcance como la variable a gestionar. Lo anterior implica que la relación entre clientes y desarrolladores se debe realizar en un nuevo contexto, expresado en un conjunto de “deberes y derechos” [7]tal como se presenta en la Tabla 4:

Ti

Co

sto

de

l Ca

mb

io

Requer imientos Análisis Diseño Implementación ProducciónTi

Co

sto

de

l Ca

mb

io


Co

sto

de

l Ca

mb

ioRequer imientos Análisis Diseño Implementación Producción

TiC

ost

o d

el C

am

bio


Co

sto

de

l Ca

mb

ioRequer imientos Análisis Diseño Implementación Producción

20

Derechos del cliente Derechos del desarrollador

� Tener un plan global, y conocer qué puede ser logrado, cuándo y a qué costo

� Obtener el mayor valor de cada semana de desarrollo

� Observar el progreso en un sistema funcional, cuyo funcionamiento puede ser probado por ejecuciones exitosas de pruebas repetibles que él puede especificar

� Cambiar de opinión, canjear funcionalidades y cambiar prioridades sin pagar costos exorbitantes

� Ser informado de cambios de planificación, a tiempo para poder definir cómo ajustar el alcance para poder alcanzar la fecha original

� Cancelar en cualquier momento y tener en sus manos un sistema funcional que refleje lo invertido hasta ese entonces

� Conocer qué se necesita, con prioridades declaradas claramente

� Producir trabajo de calidad en todo momento.

� Pedir y entregar ayuda por compañeros, superiores y clientes

� Actualizar las estimaciones ante nuevos descubrimientos técnicos

� Aceptar responsabilidades en vez de que le sean asignadas.

Tabla 4: Declaración de derechos de clientes y desarrolladores

Estos deberes y derechos se ejecutan en un modelo gestión de tiempo denominado “timeboxing”, consistente en que clientes y desarrolladores acuerdan una fechas de entrega, al final del cual, y luego de un trabajo orientado a la mayor calidad con los recursos disponibles, se obtiene un producto que aporte real valor al cliente, y cuyos detalles se irán acordando a medida que avance el desarrollo. Esto contrasta con el modelo tradicional en donde la fecha de término es incierta y está determinada por la “finalización” del producto pre-definido (hito que, dada la naturaleza incierta del producto que se desea, es bastante subjetiva).

El modelo de tiempo fijo tiene varias ventajas:

� El equipo de trabajo (que incluye al cliente) sabe a priori cuanto tiempo va a tener que dedicar al proyecto, tanto diariamente como semanalmente, lo que desde el punto de vista humano permite bajar la tensión provocada al miedo a equivocarse, que en los modelos tradicionales implican sobretiempos, atrasos en la generación de productos y horas extras. De hecho, el concepto de “atraso” desaparece.

� Existe un incentivo directo a ocupar de manera más productiva el tiempo que se tiene disponible para lograr resultados

� Se previene el uso indiscriminado de las nocivas horas extras, que como ya fue demostrado por Ford a comienzos del siglo 20 sólo provocan caídas sostenidas en la productividad.

� Y por último, en la industria existen testimonios que indican mejoras sustanciales de productividad cuando se ha aplicado este principio, tal como es mostrado por James Martin en su libro “Rapid Application Development” ya en 1991 [34].

21

El ambiente de desarrollo de software y el aprendizaje

Ilustración 5: El ambiente del desarrollo de software

En la Ilustración 5 podemos observar el ambiente de desarrollo de software, y lo complejo que es para las personas involucradas en él. Ellos deben entender tres aspectos: el problema de negocio a resolver, las herramientas tecnológicas que se están utilizando, y el estado del proyecto de desarrollo, y todos son blancos móviles. Además, la comprensión de cada uno difiere: el cliente domina en mayor medida el problema de negocio, mientras que los desarrolladores lo hacen con la tecnología, y a su vez cada miembro del equipo tiene un dominio distinto de las herramientas. Y estas comprensiones también van variando a lo largo del tiempo. Con respecto al estado del proyecto, usualmente son los desarrolladores los que tienen mayor comprensión de lo realizado. Sin embargo, una práctica común como es la estricta división de roles lleva a problemas tales cómo que se repita trabajo previamente realizado por otros, o que el esfuerzo requerido por la integración de los módulos desarrollados sea excesiva. Asimismo, la también común práctica de mantener una comunicación con el cliente restringida a hitos de entrega y basada en intercambio de documentación permite que lo programado por los desarrolladores diverja de las necesidades actuales del negocio. El resultado que se puede esperar sin una sincronización continua entre todos los involucrados es mejor reflejado por una clásica viñeta humorística acerca del desarrollo de un columpio que vemos en la Ilustración 6.

DesarrolladorDesarrolladorDesarrolladorDesarrolladorProblema en resolución:

- ¿Cuáles son la necesidades actuales?

- ¿Cuáles son prioritarias?

ClienteCliente

Avance de Proyecto:- ¿Cuánto hemos avanzado realmente (en generar real valor)?

- ¿Cuáles y cuántas funcionalidades queda por hacer?- ¿Cuánto tiempo se requerirá para dichas funcionalidades?- ¿Qué defectos puede tener el producto?

Método de Trabajo- ¿Qué prácticas y estándares se debe seguir?- ¿Qué errores no se debe repetir?- ¿Qué debemos mejorar?

Tecnología:- ¿Cuál tecnología usar?- ¿Qué sabemos hacer con la tecnología utilizada?

- ¿Cuáles es posible hacer (limites) con la tecnología?

??

Equipo de Desarrollo

¿Concuerdan? ¿C

on

cuerd

an

?

?

(t

?Trabajo en Equipo:- ¿Cómo mantener la motivación?- ¿Cómo comunicarse efectivamente?- ¿Hay áreas del proyecto que sólo puedan ser mantenidas por uno?

r?????

22

Ilustración 6: El desarrollo de un software a través de la metáfora del desarrollo de un columpio

Como una solución a esta problemática, en el libro “Lean Software Development” [43]., los autores plantean que ante la naturaleza inherentemente variable de los proyectos de software, una herramienta fundamental es la “amplificación del aprendizaje”, la cual se obtiene mediante la retroalimentación continua entre clientes y desarrolladores a través la integración de ambos en un sólo equipo y la generación y validación continua de entregables (software funcional) incrementales Por su parte, Ivar Jacobson, uno de los creadores de RUP, ha afirmado que una de las características fundamentales de un buen proceso de desarrollo de software es que este facilite el aprendizaje: “un buen proceso te permite aprender a medida que se avanza, sin frenar el avance del proyecto”, e identifica esta propiedad con las metodologías ágiles [25]. Esto es apoyado por otras investigaciones que han analizado las metodologías ágiles desde el punto de vista de las ciencias del aprendizaje, y ha destacado el beneficio de las actividades de retroalimentación rápida propias a las metodologías ágiles como una manera reducir la complejidad cognitiva inherente en los desarrollos de software haciendo el ambiente de desarrollo más comprensible para los desarrolladores [8].

3.2.2 La propuesta de Extreme Programming (XP) Extreme Programming (XP), la propuesta ágil más importante en la actualidad, recoge desde la industria diversas prácticas reconocidas por su aporte al éxito de los proyectos, y propone llevarlas al extremo (de ahí el nombre “Extreme Programming”). Algunos ejemplos son presentados en la Tabla 5.

23

Práctica u Objetivo Versión “extrema” Revisiones de código “Programación de a pares”, donde hay siempre a lo menos dos

personas revisando el código concurrentemente Sistema de pruebas estructurado del sistema

“Desarrollo guiado por pruebas”, en donde cada segmento del código ha sido construido a partir de una prueba que define su comportamiento correcto

Software funcionando “Integración continua”, en donde periódicamente se ensamblan los módulos del sistema, y “Entregables pequeños” que implica ir entregando incrementos de valor al cliente a través de entregables pequeños lo antes posible

Conocimiento compartido del dominio del problema a resolver, y de la estrategias de solución

“Cliente in situ”, en donde el cliente es integrado 100% al quehacer del grupo como un experto en el dominio a resolver “Metáfora” que indica qué se debe construir, un lenguaje común entre clientes y desarrolladores usando una comparación metafórica que facilite el entendimiento del sistema a desarrollar

Conocimiento compartido de la estrategia de solución

“Planning Game”, que consiste en un juego colaborativo, en donde clientes y desarrolladores definen el alcance de cada iteración del desarrollo

Equipo motivado “40 horas a la semana”, que indica que el trabajo debe hacerse normalmente dentro de la jornada laboral normal, dejando el esfuerzo de trabajar horas extras relegado sólo a situaciones extraordinarias, todo esto con el afán de mantener el equipo descansado y con capacidad máxima de producir Se complementa con “Planning Game”, en el sentido de que esta última busca dar confianza a todos en el proyecto de que éste es realizable

Código fuente legible y comunicable

“Estándares de código”, en donde el equipo norma un conjunto de reglas de formateo y nombrado de entidades en el código fuente “Refactorización”, que indica que ninguna funcionalidad debe estar implementada más de una vez en el sistema, y que en caso de encontrarse alguna duplicidad, debe ser eliminada factorizando el código repetido. Esto evita que defectos arreglados en una parte del código persistan en otras partes “Diseño simple”, que indica que lo que se diseña es sólo lo que realmente se va a utilizar. De esta manera se eliminan “áreas grises”, con código que nunca se usa y que sin embargo engorda el código del sistema, y también se ahorra tiempo de los desarrolladores al no desperdiciar esfuerzos en funcionalidades que puede que nunca sean utilizadas

Conocimiento compartido del sistema, como una forma de evitar dependencias excesivas en un desarrollador específico

“Propiedad colectiva de código”, todos los desarrolladores son responsables y dueños de todo el código del sistema. Esto se refuerza por “Programación de a pares” y “Mantener el equipo rotando”

Tabla 5: Buenas prácticas de la industria del software y su versión XP

Estas prácticas se definen como un conjunto de valiosas herramientas, cuya aplicación debe estar condicionada a la realidad de cada proyecto. Para facilitar este trabajo de aplicación, se propone un conjunto de criterios que se deben seguir, denominados “Principios de XP”[6], que se presentan en la Tabla 6:

24

Principio Explicación

Comunicación abierta y honesta

Debe darse a todo nivel, entre desarrolladores y con el cliente. Se entiende como la única forma de generar real confianza y un trabajo efectivo en equipo, evitar malos entendidos y poder prevenir a tiempo problemas

Trabajar con los instintos de las personas

Es aprovechar las características distintivas de cada persona a favor del proyecto, en vez de reprimirlas. Por ejemplo, si alguien se expresa mejor a partir de gráficos, motivarlos a su uso, entendiendo eso sí que la verdad definitiva del software está en lo realmente programado

Responsabilidad aceptada (antes que asumida)

En un equipo XP no se imponen tareas, sino que se exponen necesidades ycada cual se ofrece para aquella para la cual se considere mejor preparado.

Atacar problema urgente, dejando la mayor cantidad de opciones

Relacionada con el coraje; implica abordar los mayores riesgos o problemas con decisión, definiendo alternativas para resolverlos, y evaluando cada uno con experimentos pequeños que permitan tomar una decisión informadaacerca del camino a seguir.

Viajar con equipaje: poco, simple y valioso

Evitar la dependencia de herramientas costosas, sino contar con un kitmínimo de herramientas simples y valiosas. Esto da origen a los wikis para la documentación, o a los frameworks para realizar pruebas de unidad comoJUnit, pero evita la dependenciar de grandes y costosas suites de desarrollopara poder gestionar un proyecto de software.

Adaptación local Cada proyecto tiene su propia realidad por lo que cada equipo deberáseleccionar aquellas prácticas de XP que mejor le sirvan, complementándolas con otras originadas en otras metodologías si es necesario

Enseñar a aprender Cada equipo debe mantener un fuerte compromiso con el aprendizaje rápidoy continuo de todos, tanto del proceso de desarrollo, como del problema denegocio o de las tecnologías ocupadas

Jugar a ganar Mantener una actitud positiva y optimista orientada a lograr el éxito del proyecto

Trabajo de Calidad Cada producto desarrollado debe tener la mayor calidad posible. Esto no esnegociable

Asumir siempre simplicidad

“Hacer lo más simple que posiblemente funcione”

Debe privilegiarse siempre la solución más simple que pueda funcionar. Representada por la sigla YAGNI12

Cambios paso a paso El trabajo es siempre realizado en incrementos pequeños, lo que permite tener que validar cada vez cosas pequeñas, y si se ha fallado, perder poco

Retroalimentación rápida

Mientras antes sepamos algo, antes se puede reaccionar. Estaretroalimentación puede venir del cliente, del propio sistema o de la forma en que está trabajando. Representado por la frase “Fail fast” (si algo va a fallar, que falle antes y con el menor costo posible)

Experimentos concretos

Hay que validar cada decisión abstracta o duda que se tenga conexperimentos pequeños. Es decir, no hay que adivinar, sino actuar a partir dela realidad

12 De “You aren’t gonna need it” (“No vas a necesitarlo”), es decir, antes de definir una solución validar fuertemente si realmente

se va a necesitar o no. Ver http://c2.com/xp/YouArentGonnaNeedIt.html

25

Principio Explicación

Medir Honestamente

Medir el avance del proyecto de una manera que refleje realmente su estado, considerando sus particularidades y con datos reales.

Tabla 6: Principios de XP según Kent Beck en "Extreme Programming Explained”

Estos principios son englobados por cuatro valores sobre los que deben basarse los equipos XP: Coraje, Comunicación, Retroalimentación y Simplicidad.

Como podemos observar, existe un fuerte énfasis en definir valores y principios que inspiren a las personas que practiquen XP. Esto no es de extrañar, dado el enfoque centrado en potenciar el recurso humano de las metodologías ágiles, que busca en definitiva hacer que cada persona del equipo pueda aportar el mayor valor posible a través de una mejor capacidad para tomar decisiones.

Cómo funciona XPEl funcionamiento de XP puede ser resumido según el esquema presentado en la Ilustración 7:

Ilustración 7: Flujo del trabajo en XP13

El punto de partida consiste en el “Planning Game”, en donde el usuario, en su lenguaje define “historias de usuario”, las que son documentadas en tarjetas indexadas (como las usadas en las bibliotecas) y donde el cliente expresa alguna funcionalidad que espera del sistema. Cada tarjeta es analizada por los desarrolladores para lograr una estimación de esfuerzo, y en el caso de no poder lograrla debido a incertidumbre sin resolver, se le pide al cliente que especifique aún más la historia en una o más nuevas tarjetas. Si la incertidumbre es de tipo técnico, los desarrolladores pueden hacer mini-experimentos para tener una mejor idea del esfuerzo implicado por un requerimiento. Una vez que se logra un conjunto de historias de usuario estimadas, el cliente procede a definir aquellas que son más urgentes y que en su conjunto definan un sistema de software funcional, calculando un esfuerzo tal que calce con una fecha de entrega de la iteración. Con este conjunto de tarjetas, los desarrolladores pasan a

13 Fuente: www.borland.com

26

planificar en detalle la iteración, definiendo tareas específicas surgidas a partir de las historias, y permitiendo que el desarrollador que asuma una tarea sea el encargado de estimarla.

Luego, se pasa a la construcción del software, en donde cada funcionalidad es construida a partir de un test que especifica el funcionamiento esperado del módulo, para luego generar el código más simple que pase ese test. Si durante esta implementación se detecta que se está generando alguna redundancia con alguna otra parte del sistema, se factoriza la funcionalidad en un módulo común.

Para que una historia de usuario sea aceptada, el cliente debe definir para los desarrolladores un conjunto de “pruebas de aceptación”, es decir, una especificación de condiciones que defina con claridad los criterios que se usarán para determinar que una historia de usuario está completa, y que objetivice para los desarrolladores el funcionamiento macro de la historia.

En caso de que alguna historia no pase sus pruebas de aceptación, se pasa a corregir los defectos hasta que se logre el objetivo. Una vez que todas las historias de una iteración estén aprobadas, se empaquetará un “entregable pequeño” para el cliente, quien procederá, si corresponde, a escoger un nuevo conjunto de historias para su implementación en una nueva iteración.

La posibilidad de ajustarse al cambio se expresa en el derecho otorgado al cliente de definir nuevas funcionalidades en cualquier momento, las que pueden ser incorporadas a la carga de trabajo del equipo reemplazando historias de usuario aún no implementadas que impliquen un esfuerzo equivalente a la nueva. De manera similar, si el desarrollador encuentra nueva información que indique un cambio en las estimaciones iniciales, debe comunicarla al cliente y realizar los ajustes necesarios en la carga de trabajo de la iteración, sacando o simplificando historias si es necesario para cumplir con la fecha de entrega definida.

Lo antes explicado puede resumirse en los “ritmos de XP”, graficados en la Ilustración 8.

Ilustración 8: Ritmos de XP 14

14 Fuente: www.diamond-sky.com

entregable pequeñoentregable pequeño

plan entregaplan entrega

planning gameplanning game iteracióniteración

estimar historias de

usuario


usuario

dividir historias en

tareas


tareasestimar tareas

estimar tareas

asumir tareas

asumir tareas

escoger par

escoger par listar ítemes

por hacer

listar ítemespor hacer

completar

ítemes por hacer

completar

ítemes por hacer

planificar iteraciónplanificar iteracióntareatarea

planificar iteración

planificar iteración completar

tareas

completar tareas

escribir tests de

aceptación

escribir tests de

aceptaciónpriorizar historias

priorizar historias

escribir historias

escribir historias

seleccionar historias


clientecliente desarrollodesarrolloequipo

completo

equipo completo escribir

test

escribir test

Escribir código que cumple test


refactorizarsin piedad

refactorizarsin piedad integrar

código

integrar código

ítem por hacerítem por hacercódigo de colores

código de colores

completariteraciones

completariteraciones entregar

software

entregar software

entregable pequeñoentregable pequeñog p qg p qg p qentregable pequeentregable pequeentregable pequeentregable pequeññññññooooooentregable pequeño

plan entregaplan entregaplan entregalan entregalan entregaplan entrega

planning gameplanning gameplanning gameplanningplanningplanningplanninglanninglanning gg egamegamegamegameplanning game iteracióniteracióiteracióniteraciiteraciiteraciiteraciteracite óóóóóóónnnnnnniteración


usuariousua ousua ousua o


usuario


tareasta easta easta easta eas


tareasestimar tareas

estimar tareasestimar stimar mtt tareasareasaestimar tareas

asumir tareas

asumir tareas

escoger par

escoger par listar ítemes

por hacer

listar ítemespor hacerlistar star sta í

hhíeetemesemese

por haceror haceror hacerlistar ítemes

por hacer

completar

ítemes por hacerh

completar

ítemes por hacer

completar ompletar ompletar

íeetemesemese por hacerhacerhacerhacehaceracera

completar

ítemes por hacer

planificar iteraciónp ónplanificar iteraciónplanificar iteraciplanificar iteraciplanificar iteraciplanificar iteraciplanificar iteracilanificar iteracilanificar iteracióóóóóóónnnnnnnplanificar iteracióntareatareatareaatareatareatareatareaareaatarea

planificar iteración

planificar iteraciónplanificar lanificar lanificar teraciteracióóniteracieracie óóónnn

planificar iteración completar

tareas

completar tareascompletar ompletar ompletar tareastareastareasareasa

completar tareas

escribir tests de

aceptaciónp

escribir tests de

aceptación

escribir scribir bir tt ddtestsestsests dtt de e e

óóppaceptacipceptaciceptacióóónnn

escribir tests de

aceptaciónpriorizar historias

priorizar historiaspriorizar riorizar riorizar istoriasistoriashistoriasistoriasistoria

priorizar historias

escribir historias

escribir historiasescribir scribir bir

t it ihistoriasistoriasistoriaescribir historias


seleccionar historiasseleccionar eleccionar ecciohi t ihi t ihistoriasistoriasistoria


clientecliente desarrollodesarrolloequipo

completo

equipo completo escribir

test

escribir testescribir scribir bir t tt ttesteste

escribir test

Escribir código que cumple testtcu p ecu p ecu p e testtesttest


refactorizarsin piedad

refactorizarsin piedad integrar

código

integrar código

ítem por hacerítítem por hacerííííítetetem por hacertem por hacertem por hacertem por hacertem por hacerem por hacerem por hacerítem por hacercódigo de colorescó

código de coloresccccóóóóódddigo de coloresdigo de coloresdigo de coloresesdigo de coloresigo de coloresigo de coloresggcódigo de colores

completariteraciones

completariteracionescompletarompletarompletareracioneseracionesiteracioneseracioneseracio

completariteraciones entregar

software

entregar softwareentregar ntregar ntregar oftwareoftwaresoftwareoftwaretw

entregar software

27

En resumen, XP propone pasar de diseñar-programar-probar-depurar-armar-entregar, a diseñar continuamente, probar continuamente, armar continuamente, revisar continuamente y entregar temprana y frecuentemente.

Interdependencia entre las prácticas Como ya pudo observarse en la Tabla 5, las prácticas de XP funcionan mejor si están apoyadas por otras. Esto ya fue indicado por Kent Beck, tal como se muestra en la Ilustración 9.

Ilustración 9: La interrelación de prácticas de XP, según Kent Beck en la primera edición de "Extreme

Programming Explained"[6]

Por ejemplo, la refactorización es la herramienta fundamental para mantener el diseño del sistema en su estado más simple posible. De manera similar, el Desarrollo Guiado por Pruebas servirá para detectar cualquier problema que una refactorización del código del sistema pueda causar a la funcionalidad ya implementada. El diseño simple es también apoyado por la programación de a pares, por el efecto conocido de que “dos cabezas piensan mejor que una”, lo que conlleva a obtener diseños mejor pensados y más simples. Podrían indicarse otros ejemplos, pero como es posible observar, existe un delicado equilibrio que debe lograrse al implementar este conjunto de prácticas propuesto por XP.

Roles dentro de un equipo XPEn XP se plantean dos roles especiales, que pueden ser compartidos por una persona: el coach y el tracker. El primero es el líder del equipo, quien en base a su experiencia y dominio de XP tiene como labor principal formar a sus compañeros en la mejor toma de decisiones, potenciándolos para que “hagan un trabajo aún mejor”.

El tracker por su parte, es el encargado de ir recogiendo la información de avance del proyecto (tareas logradas, historias aceptadas por el cliente, esperado versus logrado, etc.). Esta información será publicada en un lugar visible por todo el equipo, como medio de retroalimentar el avance y dar al equipo una perspectiva de la sanidad del avance.

On Site Customer

Planning Game

Short Releases

Continuous Integration Collective Ownership

Coding Standards

Pair Programming Testing

Refactoring

Metaphor 40 Hours Week

Simple Design

28

3.2.3 El problema de la adopción de XP en la industriaAl momento de plantear una eventual adopción de alguna metodología ágil, y en particular XP es importante el analizar cuáles son los escollos que es posible esperar, algunos de los cuáles ya fueron planteados por el propio Kent Beck en “Extreme Programming Explained” [6].

Una primera afirmación que es posible realizar, es que la adopción de XP presenta problemas extrínsecos e intrínsecos. Los primeros son los debidos a que XP plantea una mirada revisionista a la ingeniería de software actual, y por ende plantea un cambio calificado incluso de cultural [56]. Los segundos son aquellos planteados por la rica pero compleja gama de herramientas conceptuales que conforman XP (4 valores, 16 principios y 12 prácticas interrelacionadas entre sí).

A continuación se presentarán dichos desafíos en más detalle.

Desafíos extrínsecos: XP versus el establishmentXP plantea un número no despreciable de nuevos paradigmas en el desarrollo de software, lo que claramente implica un esfuerzo no menor de evangelización y cambio cultural, lo que ha sido refrendado por diversos reportes de experiencias [35]. Además debe considerarse que si bien XP plantea como principio trabajar con los instintos de las personas y no en contra de ellos, hay que saber muy bien diferenciar un instinto de un paradigma que la persona puede tener muy internalizado en sí. Por ejemplo, la visión tradicional de la gestión de desarrollos de software contrasta con la visión que XP tiene de la misma, tal como se puede apreciar en la Tabla 7:

Aspectos Tradicional XP

Relación cliente-desarrollador

Defensiva, con cláusulas de castigo en caso de no cumplimiento

Colaborativa en pro del éxito del proyecto

Ciclo de vida Cascada Iterativo

Rol de la planificación Guía de debe cumplirse estrictamente

Guía que debe ajustarse continuamente a la realidad

Costo del cambio Exponencial a medida que avanza el proyecto

Puede lograrse un costo constante

Actitud frente al cambio de requerimientos

Enojo, miedo, a la defensiva Positiva, empática con la necesidad que origina el cambio

Tipos de Contratos De precio, tiempo y alcance fijos De alcance variable

Esfuerzo de diseño

Principalmente el comienzo del proyecto, y del sistema completo15

Emergente a media que se conoce con certeza cada incremento del sistema a construir. “Lo más simple que pueda funcionar”

Priorización del esfuerzo Según la perspectiva técnica Según la perspectiva del cliente

Herramienta para mejorar el éxito de los proyectos

Proceso bien definido, que debe seguirse y controlarse

Personas bien formadas que comparten un conjunto de valores, principios y prácticas comunes

15 Denominado “BDUF”, por la sigla en inglés de “Big Design Upfront” (“Gran Diseño Anticipado”). Ver

http://c2.com/xp/BigDesignUpFront.html

29


Herramientas de comunicación

Documentación exhaustiva y abstracta de requisitos y diseño, principal medio de comunicación entre clientes y desarrolladores

Documentación somera, pero útil para constituir una base de conversación de “banda ancha” entre clientes y desarrolladores

Indicador de compromiso con la empresa

Dedicar muchas horas extra a la jornada laboral para completar las tareas

Dedicar las horas de una jornada normal a producir al ritmo más elevado de calidad

Liderazgo del equipo Vertical, la responsabilidad está centrada en el jefe de proyecto

Horizontal, el coach tiene un rol de guía y de formador hacia la toma de buenas decisiones por parte de todos.

Indicador de capacidad del desarrollador

Saber siempre Saber expresar claramente lo que domina, saber pedir apoyo frente a temas que desconozca, y mantener una actitud siempre abierta al aprendizaje

Tabla 7: Comparación entre los conceptos tradicionales y los de XP

Asimismo, en la praxis de los ingenieros de software prevalecen prácticas que también son revisadas por XP, como vemos en la Tabla 8.


Ciclo de programación

Programar, probar, depurar, probar, depurar, etc.

Definir la prueba, programar el código más simple que pase la prueba (Desarrollo Guiado por Pruebas)

Costo de hacer pruebas

Más que simplemente programar la solución

Menos, debido a que se evitan ciclos eternos de depuración

Diseño

Complejo, previendo muchos casos que “podrían alguna vez necesitarse”, (también llamado “sobrediseño”)

Simple, lo justo y necesario para lo que estamos seguros de necesitar ahora. Para mantener la simpleza, se refactoriza “sin piedad” para evitar cualquier duplicación de funcionalidad en el código. Nunca permanece en el sistema código que no tenga aplicabilidad directa al problema a resolver

Trabajo en solitario versus de a pares

Dos personas trabajando en una sola tarea es un desperdicio, es mejor paralelizar esfuerzos.

Dos personas en un mismo esfuerzo implica mejores soluciones, menos defectos y en definitiva, un desarrollado de calidad más acelerado

Responsabilidad sobre las estimaciones

El que estima es un experto, usualmente el jefe de proyecto

El que estima es la persona que asume la responsabilidad de ejecutar la tarea

Propiedad del código

Cada desarrollador está a cargo de una parte del código. Suele generarse dependencia de un desarrollador específico debido a que es el único que conoce cómo está hecha una parte del sistema

La propiedad del código es de todo el equipo, que rota, de a pares constantemente en la implementación de funcionalidades

Tabla 8: Comparación entre prácticas de desarrollo tradicional y XP

30

Desafío intrínseco: Apropiación del marco conceptual y transferencia de prácticas deXPEn un mundo ideal, en donde no existiese una cultura alterna a la propuesta de XP, aún su adopción sería un desafío. A continuación veremos por qué.

XP plantea un conjunto interrelacionado e interdependiente de prácticas que definen la relación entre cliente-desarrollador, el desarrollo de software en equipo y la forma de programar software. Es decir, no sólo basta con conocer cada práctica, sino que hay que aplicarlas apoyándose en otras que las complementan y fortalecen, buscando generar un balance entre ellas [6].

Se entregan un conjunto de principios orientadores que debieran facilitar este proceso, pero su cantidad tampoco es menor. Así que las preguntas que naturalmente surgen son:

� ¿Por dónde partir?

� ¿Cómo continuar a partir de allí?

Meta-desafíosAl unirse los tipos de desafíos extrínsecos e intrínsecos antes descritos, surgen dos muy particulares que son indicados por Kent Beck[6]:

� “Pequeños malos entendidos pueden ser desastrosos”.

� “Al ser sometidos a stress, la gente vuelve a sus antiguas costumbres”

Analizaremos cada uno más en detalle.

“Pequeños malentendidos pueden ser desastrosos”.

El correcto entendimiento del complejo marco de XP está sometido a un fuerte stress debido a las concepciones imperantes en la industria. Un ejemplo expuesto por el propio Beck [6], plantea que un equipo de desarrollo que estaba adoptando XP estaba teniendo problemas para lograr sus objetivos de desarrollo. Luego de analizar el problema, se encontró lo descrito en la Tabla 9:

Proceso de planificación de tareas propuesto por XP Entendido por el equipo 1. Inscribirse en una tarea 2. Estimar las tareas propias 3. Re-balancear si alguien está sobrecargado

1. Estimar tareas colectivamente 2. Inscribirse en las tareas

Tabla 9: Contraste entre planificación según XP y su interpretación por un equipo de desarrollo

El ligero cambio de orden en el proceso, y la eliminación del último paso provocaban que mucha gente asumiese tareas con una estimación que no calzaba con su propia idea del esfuerzo implicado. Esto generaba un grave desorden en la planificación y seguimiento del proyecto debido a que se perdía inmediatamente contacto con la realidad del avance.

“Al ser sometidos a stress, la gente vuelve a sus antiguas costumbres”

El buen entendimiento de XP es sólo el comienzo. Si bien es posible hacer el cambio de paradigma, bajo stress, la gente vuelve a actuar de la forma en que estaba acostumbrada originalmente [20], por lo cual cualquier cambio logrado debe ser sostenido y gestionado en el tiempo [6]. Este efecto ha sido documentado en diversos reportes de campo, en donde

31

prácticas como “Desarrollo Guiado por Pruebas” suelen abandonarse en los momentos en que más sería necesario sostenerla [28].

La rápida evolución y reformulación de XP

Muchas prácticas del marco conceptual de XP han sido refinadas intensamente en el tiempo. Es así como “40 horas a la semana” se ha replanteado como “productividad sostenida”, o que “cliente in-situ” ahora se llame “un solo equipo (conformado por clientes y desarrolladores)”. Inclusive acaba de salir una segunda versión de “Extreme Programming Explained” que redefine y reorganiza mucho de lo planteado en el libro original, y que, debido al impacto de estos cambios, escapa al alcance de esta investigación.

Todo lo anterior nos lleva al punto siguiente: ¿qué estrategias se han propuesto para la adopción exitosa de XP?

Buscando un punto de partida para aplicar XPEn “Extreme Programming Explained”, Beck ya proponía la siguiente estrategia de adopción:

1. Escoger el peor problema.

2. Resolverlo al estilo XP.

3. Cuando ya no sea el peor problema, escoger otro y repetir.

Esta estrategia deja una pregunta abierta: para resolver un problema “al estilo XP”, primero debo saber aplicarla. Es así que Beck basa la aplicación de XP en la destreza de un coach experto, que sirve de mentor y guía a su equipo. Pero igual queda la duda de cual es el punto inicial por donde dicho coach deberá partir su trabajo.

En el 2001, en “Extreme Programming Applied – Playing to win” [4], dos adoptadores tempranos de XP a partir de su experiencia en la empresa Role Model Software plantean un modelo en el que se priorizan aquellas prácticas que son consideradas fundamentales:

� Planificación y estimación (Planning Game)

� Entregables pequeños (e iteraciones)

� Desarrollo Guiado por Pruebas

� Programación de a pares

� Refactorización

� Integración continua

El resto de las prácticas se consideran “suplementarias”.

Posteriormente en el 2003, en el libro “Lean Software Development” [43] se plantea que el punto de partida inicial (y el pivote a partir del cual puede comenzar el cambio hacia un modelo ágil) está en el planificar el desarrollo en iteraciones de tamaño fijo que entreguen cada una incrementos de valor para el cliente, lo que tiene mucho sentido pues si observamos las otras prácticas antes nombradas, están todas dirigidas por este principio.

32

Herramientas para difundir y adoptar XPLa primera herramienta que se usó para difundir XP y sus principios fue el primer Wiki-Wiki creado por Ward Cunnigham16

� xprogramming.com: sitio de Ron Jeffries, el coach del primer proyecto XP (C3), con diversos artículos donde se presentan aplicaciones de prácticas XP como el desarrollo guiado por pruebas, la programación de a pares, y se reflexiona sobre fundamentos de XP

, en donde se fueron escribiendo y depurando a modo de una lluvia colaborativa de ideas los conceptos fundacionales de XP. Posteriormente se abrieron otros sitios de difusión, entre los que podemos destacar:

� extremeprogramming.org: sitio de Don Wells, otro de los primeros proponentes de XP, donde se presenta mediante diagramas el funcionamiento interno de XP

� www.martinfowler.com: sitio de Martin Fowler, con información sobre XP aplicado en sistemas de bases de datos relacionales, y algunas reflexiones teóricas sobre XP

Otra instancia de difusión de importancia son las conferencias anuales sobre XP (XP2000, XP2001, etc.) que se realizan todos los años desde el 2000, y las que se realizan sobre metodologías ágiles en general.

Herramientas de entrenamiento

La comunidad de desarrolladores que ha adoptado XP también ha diseñado técnicas que hacen más simple el explicar sus prácticas. Por ejemplo, Peter Merel inventó y documentó en el wiki de XP la llamada “Extreme Hour”17

� Games for Programmers

como una forma de explicar de manera simple y significativa el Planning Game. En este taller desarrolladores y clientes se reúnen por una hora, para simular el desarrollo de un invento cuyas funcionalidades serán solicitadas mediante tarjetas, y cuya construcción es realizado en iteraciones de pocos minutos a través de dibujos en una pizarra.

Siguiendo esta línea, han surgido otras herramientas similares, entre las que podemos destacar:

18

� XP Simulation & Games

: donde se listan una serie de talleres en donde se proponen juegos para entrenar al equipo en las prácticas de XP.

19

: aquí la empresa Industrial Logic presenta un kit de tarjetas con las que se pueden realizar diversos juegos para aprender XP. También se proponen talleres para explicar prácticas específicas.

16 http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap 17 http://c2.com/cgi/wiki?ExtremeHour 18 http://www.xp123.com/g4p 19 http://industriallogic.com/games/

33

3.3 El estado del arte de la Ciencia del Aprendizaje Tal como se presentó en el punto 3.2.1, la incertidumbre es parte de la naturaleza del desarrollo de software, lo cual ciertamente impacta tanto la formación cómo la labor diaria de quienes realizan esta labor: los ingenieros de software. Para poder profundizar en este tema, se introducirán algunos descubrimientos realizados en el área de las ciencias de la educación, que servirán a su vez como base para analizar el problema de la incertidumbre como parte natural del desarrollo de software.

3.3.1 Los antecedentes de la ciencia del aprendizajeEl estudio de la mente humana mediante métodos científicos surge a fines del siglo 19, tomando el lugar que anteriormente había sido ocupado por la teología y la filosofía[19]. Uno de los pioneros en esta nueva ciencia denominada “psicología” fue el estudioso alemán Wilhelm Wundt quien, junto a su equipo, trató de poner la conciencia humana bajo análisis principalmente mediante pedir a sus sujetos de estudio que reflexionasen acerca de sus propios proceso de pensamiento mediante la introspección [18].

Al comienzo del siglo XX surge una respuesta denominada conductismo que critica al modelo anterior debido a la subjetividad inherente de la introspección, y abogando por un estudio restringido a observar conductas observables y los estímulos que la provocan. De esta manera los conductistas concibieron el aprendizaje como un proceso interno de formación de relaciones entre estímulos y respuestas. En esta mirada, el aprendizaje aparenta estar motivado por necesidades internas como el hambre, o por fuerzas externas como recompensas o castigos, tal como planteaba Edward L. Thorndike en 1913[19]..

Fruto de esta mirada es la enseñanza orientada al aprendizaje memorístico, en el que el aprendiz orienta su labor al estudio, memorización y repetición de conceptos, siendo esta última una evidencia observable de aprendizaje considerada como suficiente por el conductismo. De más está decir que este modelo pedagógico todavía influencia mucha de la práctica educativa actual.

Una limitación del conductismo es que el foco en la conducta observable hace difícil estudiar fenómenos de importancia fundamental para el aprendizaje tales como el entendimiento, el razonamiento y el pensamiento. Es así que surge el denominado neo-conductismo, que se permite formular hipótesis acerca de los “estados mentales” que explican las conductas observadas, como el planteado por Clark Hull en 1943[19].

A fines de los 1950, se hizo evidente la complejidad del entendimiento humano, lo que dio origen a un nuevo campo de estudio, la ciencia del aprendizaje (también denominada ciencia cognitiva), que enfrenta de manera multidisciplinaria el aprendizaje incorporando elementos antropológicos, filosóficos, y sociológicos, entre otros.

El desarrollo de nuevas herramientas experimentales, como el análisis cualitativo riguroso, ha permitido que el estudio del funcionamiento de la mente humana pueda ser efectivamente estudiado más allá de las conjeturas hipotéticas.

3.3.2 La ciencia del aprendizaje: aprender con entendimientoEl principal énfasis de la ciencia del aprendizaje es el aprender con entendimiento, Por esto, veremos cómo entender el proceso de aprendizaje mediante una teoría de la cognición, y cómo aprovechar este nuevo conocimiento al enseñar para lograr una efectiva mejora en los aprendizajes obtenidos. De esta manera se estará atacando una reconocida falencia de los

34

ambientes de educación formal, que históricamente han sido mejores para seleccionar alumnos que para formarlos [8].

La visión constructivista del proceso de aprendizajeLa ciencia cognitiva no niega la importancia que el conocimiento de hechos tiene para lograr el entendimiento. Sin embargo hay una gran diferencia entre conocer una gran cantidad de hechos desconectados, y el denominado “conocimiento útil”, que servirá de base a para discriminar cuando el conocimiento es aplicable o no a ciertos contextos, y transferir lo conocido a nuevos contextos [46][18]. Es así que el conocimiento de un experto suele estar organizado y conectado en torno a principios importantes, a diferencia del novicio que suele organizar su conocimiento en base a conceptos superficiales. Por ejemplo, y contextualizando en el tema de esta tesis, donde un novicio entenderá superficialmente la práctica de XP “40 horas de trabajo a la semana” como algo solamente aplicable a proyectos con dedicación de jornada completa, y por ende, no podrán transferir este concepto por ejemplo, a un curso sobre XP; en cambio un experto la entenderá dicha práctica como “planificar un tiempo de dedicación al proyecto, y respetarlo, gestionando la carga de trabajo de tal manera que este tiempo sea respetado, y sólo excepcionalmente, excedido. Todo esto buscando generar una productividad sostenida en el equipo”.

Pero, ¿cómo sucede el aprendizaje? De los estudios de Jean Piaget y Lev Vigotsky[19][62], entre otros, se ha conceptualizado a las personas como agentes orientados a objetivos que activamente buscan información, trayendo con ellas un conjunto de conocimientos previos (creencias, habilidades, recuerdos, etc.), los que influencian significativamente qué y cómo captarán y organizarán la nueva información a obtener [18]. Es decir, las personas usarán sus conocimientos previos como base para construir los nuevos, y a su vez re-organizar lo anteriormente aprendido (re-construir). Esta mirada ha dado origen a la teoría del aprendizaje denominada constructivismo.

Es importante, eso sí, hacer notar que los nuevos aprendizajes desarrollados pueden o no ser ciertos. Por ejemplo, un estudio de Vosniadou y Brewer de 1989[19]. mostró cómo niños pequeños que creían que la tierra era plana, al comentárseles que era redonda, asumían entonces que la forma era de tortilla, y no una esfera, dado que según su modelo mental previo, que les permitía entender cómo era posible que ellos pudiesen caminar sobre la superficie de la tierra, lo más asimilable era a una forma de tortilla, pero no a una forma esférica como las que ellos conocen (una pelota, por ejemplo[55]. Un elemento adicional fue aportado por Vigotsky, al conceptualizar la llamada “Zona Proximal de Desarrollo” (ZPD)[62] de los aprendices, que indica que existe un conjunto de aprendizajes que es posible que un aprendiz pueda lograr a partir de sus conocimientos previos. Por ejemplo, un niño que no tenga noción de que vive en un planeta “Tierra”, no estará preparado para apropiarse del conocimiento de que ésta es redonda, ni siquiera con el error de entendimiento antes presentado.

De lo anterior se desprende que uno de los roles fundamentales de un formador es poner atención a los conocimientos previos de sus aprendices, definir qué aprendizajes están en la ZPD de ellos, y luego de la actividad educativa revisar comprensiones incompletas y creencias falsas. El no realizar lo anterior puede implicar que los aprendices no aprendan, o, si lo hacen, vuelvan a sus concepciones anteriores al poco tiempo.

Un error de interpretación común del constructivismo es que los formadores nunca deben indicar a sus alumnos qué aprender, sino que los aprendices siempre deben construir sus aprendizajes ellos mismos. Esta tendencia, llamada por algunos “aprendizaje natural”, confunde una teoría de aprendizaje con una teoría pedagógica, debido a que los aprendices

35

siempre construirán sus aprendizajes sin importar si estos son motivados por un formador o por el medio.

Hacia un aprendizaje activo mediante la metacognición y el soporte instruccionalDado que el entendimiento es tan importante para el aprendizaje, la ciencia cognitiva plantea la importancia de que las personas adquieran la habilidad de reconocer cuándo están realmente entendiendo, y cuando necesitan más información, es decir, tomar control activo de su propio aprendizaje.

La herramienta para lograr esta habilidad es denominada metacognición[17] (literalmente, el entendimiento sobre el mismo entendimiento) que ha sido definida como la habilidad de una persona de predecir su rendimiento en una tarea, poder monitorear sus niveles actuales de maestría y entendimiento, y seguir estrategias para mejorarlos, mediante planificación, predicción, retroalimentación , reflexión y validación constantes[13].

El formador actúa en este contexto frente a sus aprendices a través del denominado soporte instruccional20

� A partir de los conocimientos previos de sus aprendices,

, siguiendo esta ruta:

� Provee un soporte, si bien no necesariamente muy amplio, que sirva como una base sólida de explicación y práctica de conceptos y destrezas fundamentales al aprendizaje esperado (el soporte instruccional), el que está compuesto de recursos, desafíos motivadores, guías y plantillas y apoyo para la metacognición.

� El soporte es retirado gradualmente por el formador a medida que sus aprendices van adquiriendo autonomía en sus estrategias de aprendizaje a través de la práctica y del uso de herramientas metacognitivas.

El constructivismo social, la teoría del aprendizaje situado y el modelo pedagógico de aprendizaje cognitivo21

El constructivismo ha tenido dos enfoques, uno liderado por los planteamientos de Jean Piaget, denominado constructivismo psicológico, el que está centrado en el aprendiz individual y su relación con un formador siguiendo los esquemas de interacción planteados en los puntos anteriores, y el inspirado por los planteamientos de Lev Vigotsky, llamado constructivismo social, en donde el aprendizaje se entiende como inherentemente situado, es decir, está ligado fuertemente al entorno sociocultural. El aprendizaje se produce entonces a través de la relación con una comunidad de aprendices, donde es relevante el contexto físico del aprendizaje y la interacción con los pares. Ambas visiones no son contrapuestas, sino dos partes de un mismo sistema, tal como expresa lo resume Driscoll[61]: “El conocimiento es construido por los aprendices a medida que intentar generar significado de su experiencias”.

Basado en el constructivismo social, la antropóloga Jean Lave propuso una teoría pedagógica denominada aprendizaje situado, la cual plantea que el aprendizaje está naturalmente ligado a actividades auténticas, contexto y cultura [32]. Es decir, el “saber qué” no puede ni debe separarse del “saber cómo”. Como ejemplo de lo anterior, es más difícil aprender un idioma desde actividades antinaturales como leer un diccionario, que sumergiéndose en una comunidad de personas que ya hablen dicho idioma. Esta mirada critica a la educación formal imperante indicando que ésta tiende a abstraer el aprendizaje, segregando los conceptos de

20 Traducción del inglés “instructional scaffolding”, literalmente “andamio instruccional”. 21 Del inglés “Cognitive apprenticeship”. La traducción literal de “apprenticeship” es “aprendizaje”, pero hay que notar que la

acepción común del término castellano falla en recoger la relación maestro-aprendiz subyacente en el vocablo inglés

36

los contextos naturales de aplicación. Sin embargo, durante la mayor parte de la historia de la humanidad, este no ha sido el caso. Las personas suelen adquirir mucho de su aprendizaje en un modelo similar al de “maestro-aprendiz”, común en los talleres de oficios, y mediante los cuales, entre otras cosas, un niño aprende a hablar, un artista aprende su oficio, o los profesionales aprenden los detalles de su oficio una vez que han salido de la universidad. Brown, Collins, y Duguid plantean una comparación entre el aprendizaje de personas comunes, estudiantes y practicantes [14]tal como se aprecia en la Tabla 10:

Personas comunes Estudiantes Practicantes (Aprendices)

Razonan con: Historias casuales Leyes Modelos casuales

actúan en: Situaciones Símbolos (conceptos) Situaciones conceptuales

solucionan: Problemas y dilemas emergentes

Problemas bien definidos

Problemas definidos vagamente

producen: Significado negociado, y entendimiento construido socialmente

Significados fijos, y conceptos inmutables

Significado negociado, y entendimiento construido socialmente

Tabla 10: Comparación entre el aprendizaje de personas comunes y estudiantes

Como es posible observar, existe una gran similitud entre las actividades de un practicante y una persona común. Ambas tienen actividades auténticas situadas en las culturas en la que trabajan, dentro de las cuáles negocian significados y construyen entendimiento. Por su parte, los estudiantes son conminados a razonar sobre reglas y conceptos definidos por otros, actuar sobre sistemas y símbolos aceptados y resolver problemas bien definidos.

En el contexto de un taller de oficios tradicional, el maestro presenta a sus aprendices cómo realizar una tarea desafiante, muchas veces verbalizando y demostrando cada uno de los pasos involucrados en ella, observa cómo el aprendiz realiza partes de la tarea, y luego va paulatinamente entregando más responsabilidad hasta que el aprendiz es suficientemente autónomo para realizar el solo la tarea, lo que rememora el modelo de soporte instruccional presentado anteriormente. Sin embargo, hay que notar que mucho del aprendizaje se produce mientras los aprendices se observan y dialogan entre sí mientras realizan sus labores. Este modelo se produce en un entorno denominado por Jean Lave cultura de práctica, la cual está compuesta además por valores y creencias comunes.

Si se desea llevar este modelo a una sala de clases, nos encontraremos con desafíos particulares los cuales presentamos en la Tabla 11:

37

Contexto del Taller de Oficios Contexto de la Sala de Clases

Visibilidad del aprendizaje

Simple, debido a que la tarea es observable en la construcción del producto

El profesor debe hacer visible su razonamiento.

Surgimiento de tareas

Naturalmente, por requerimientos de construcción de productos tangibles

El profesor debe enseñar materias del currículum (matemáticas, ciencias, lenguaje, etc.), muchas veces divorciadas de los que los niños y adultos hacen en sus vidas. El desafío es contextualizar el conocimiento en contextos significativos (auténticos) para los alumnos.

Habilidades a practicar

Inherentes y restringidas al oficio. (Ejemplo: un aprendiz de sastre debe aprender a medir y cortar tela, y no a cortar piezas de roca o madera, como lo hace un escultor)

Los alumnos deben transferir sus aprendizajes a otros contextos. El profesor debe presentar un conjunto de tareas en contextos distintos, y luego apoyar la reflexión acerca de los elementos comunes entre ellos.

Tabla 11: Desafíos derivados de llevar el modelo del taller de oficios a la sala de clases

Estos desafíos dan pie a un modelo pedagógico denominado aprendizaje cognitivo[14], cuyos pasos son explicados en la Ilustración 10:

38

Ilustración 10: Flujo de pasos del modelo pedagógico de Aprendizaje Cognitivo

Exploración

Metacognición

Práctica Guiada (Coaching)

Retirar paulatinamente el apoyo

Recopilación Estrategias ExpertasConsiderar las estrategias que un experto aplicaría en una tarea.

Diseño soportes instruccionalesDiseñar desafíos que, actuando como soportes instruccionales, motivarán a los aprendices a aplicar las estrategias. Estas actividades estarán situadas u orientadas a resultados relevantes.

Modelado de estrategias Modelar las estrategias a sus alumnos a través de la resolución del desafío

ArticulaciónVerbalizar los razonamientos y métodos usados para resolver el desafío, (metacognición)

ofrecer retroalimentación y consejo experto

ProfesorPPPPPPPPPPPPPPPrrrrrrrrrroooooooooooooofffffffffffeeeeeeeeeeeesssssssssssssoooooooooooorrrrrrrrrr AprendicesAAAAAAAAAAApppppppppppprrrrrrrrreeeeeeeeeeeeennnnnnnnnnnddddddddddddiiiiiiiiiiicccccccccccceeeeeeeeeeeesssssssssssss

Motivación Motivar en sus alumnos la metacognición

ReflexiónReflexionar y aprender de las estrategias usadas por sus pares y por el profesor.

Aplicar estrategias a nuevos problemas.

( g)practicar habilidad resolviendo el

desafío

i

o de estra

Práctica Guiada

lorac

APRENDIZAJE COGNITIVOFlujo del modelo pedagógico

AAAAAAAA RRRRRRRRRRREEEEEEEEEEENNNNNNNNNNNDDDDDDDDDDDDDIIIIIIIZZZZZZZZZZZZZAAAAAAAAAAAAJJJJJJJJJAAAAAAAAAAPPPPPPPPPPPPPPRRRRRRRRR EEEEEEEEEE GGGGGGGGGGGGGGNNNNNNNNNNNNIIIIIITTTTTTTTTTTTIIIIIIVVVVVVVVVOOOOOOOOOOOOOCCCCCCCCCCCCCOOOOOOOOOOOOOGGGGGGCCCCCCCCCCFFFFFFFFllluuuuuuujjjjjjjooooooo dddddddeeeeeeeeellll mmmmmmmoooooodddddddeeeeeeeellloooooo pppppppeeeeeeeedddddddaaaaaaagggggggóóóóóóggggggggiiiicccccccooooooo

39

3.4 Educación de la Ingeniería de SoftwareEn el 2001 la Computer Society of the Institute for Electrical and Electronic Engineers (IEEE-CS) y la Association for Computing Machinery (ACM) formaron un grupo de trabajo denominado Joint Task Force on Computing Curricula 2001 (CC2201)22

, con el objetivo de realizar una revisión detallada de los lineamientos curriculares para programas de pre-grado en computación. El currículum planteado 10 años antes integraba en un solo documento recomendaciones para Ciencias de la Computación e Ingeniería de Software. En esta nueva revisión se reconoce la necesidad de abarcar más disciplinas. De este trabajo, y a partir de la revisión de las experiencias educacionales en varios países surge una subdivisión de la Computación en 5 áreas, de acuerdo a tres criterios: orientación hacia Ciencias de la Ingeniería, grado de énfasis en el hardware y grado de énfasis en aplicaciones. Los nombres de las áreas fueron tomados de programas comunes en los EEUU.

Ilustración 11: Áreas curriculares de la computación propuestas por CC200123

� Ciencias de la Computación: El foco de esta área está en la ciencia y la tecnología de la computación. Existen diversas aproximaciones al currículo de estos programas, tal como se ve en la

.

A continuación se presentaremos una breve descripción de cada área:

Ilustración 12.

22 Ver http://www.sigcse.org/cc2001/ y http://www.acm.org/education/curricula.html 23 http://www-static.cc.gatech.edu/~rich/21st.ppt

Computing Curricula 2001 Structure

OverviewJoint Task Force onComputing Curricula

ACMIEEE Computer Society

Other societies ??Computer Science

Computing Curriculum 2001Steering Committee


Information Systems

ACMAssociation for Information

Systems (AIS)Association of InformationTechnology Professionals

(AITP)IEEE Computer Society

Computer Engineering

Computing Curriculum -Computer EngineeringSteering Committee


Software Engineering

Computing Curriculum -Software EngineeringSteering Committee

ACMIEEE Computer SocietySeveral other societies

Information Technology

Computing Curriculum -Information Technology

Steering Committee


40

Ilustración 12: Niveles de cursos y estrategias de implementación

En el enfoque basado en tópicos, los alumnos reciben una instrucción en diversas áreas técnicas, como algoritmos, sistemas operativos, bases de datos. El enfoque comprimido selecciona sólo alguno de esos tópicos, el enfoque basado en sistemas pone su énfasis en arquitecturas computacionales y el enfoque basado en web se especializa en el desarrollo de software web

� Sistemas de Información: Está orientado al manejo de la información en el contexto de una organización, por lo cual el currículum parte con una perspectiva centrada en la organización y no en la tecnología

� Ingeniería de Computadores: Está orientada en la construcción de sistemas de hardware y software con énfasis ingenieril. Posee una fuerte influencia de tópicos de hardware a través de la carrera.

� Tecnologías de la Información: Es la más nueva de las áreas, y aquí el énfasis es la aplicación de la tecnología computacional en múltiples contextos.

� Ingeniería de Software: Está orientada a la construcción de sistemas de software para resolver necesidades de un cliente, con una mirada ingenieril. Como esta área es el contexto de esta investigación, en el próximo punto detallaremos sus objetivos y contenidos.

3.4.1 Objetivos y Contenidos de la Educación en Ingeniería de SoftwareLa ACM y la IEEE-CS han propuesto en conjunto un documento denominado Software Engineering 2004 (SE2004), el cual provee recomendaciones para la educación de pre-grado en ingeniería de software. Este documento, el Software Engineering Education Knowledge (SEEK)[49], incluye una lista de tópicos que todos los graduados deben conocer, así como una serie de lineamientos para implementar currículos y un conjunto de cursos propuestos.

Los conocimientos y habilidades que un ingeniero de software debería tener al graduarse pueden resumirse en el siguiente listado:

1. Demostrar dominio de un conjunto necesario de conocimientos y habilidades para comenzar su práctica profesional como ingeniero de software

2. Trabajar tanto individualmente como en equipo para desarrollar y generar software ejecutable

3. Reconciliar objetivos en conflicto, encontrar compromisos aceptables dentro de limitaciones de costo, tiempo, conocimiento, sistemas pre-existentes y organizaciones

41

4. Diseñar soluciones apropiadas en uno o más dominios de aplicación, usando enfoques de ingeniería que integren aspectos éticos, sociales, legales y económicos

5. Demostrar entendimiento y poder aplicar teorías, modelos y técnicas actuales que provean una base para identificación de problemas y análisis, diseño de software, desarrollo, implementación y verificación

6. Negociar, trabajar efectivamente, asumir liderazgo cuando sea necesario, y comunicarse bien con los distintos interesados en un ambiente de desarrollo de software típico

7. Aprender nuevos modelos, técnicas y tecnologías a medida que ellas aparecen y apreciar la necesidad de un desarrollo profesional continuo

Las áreas de contenido que un ingeniero de software debería recibir durante su formación son:

� Conceptos Esenciales de Computación: Incluye los fundamentos que soportan el diseño y construcción de productos de software, como teoría de autómatas, programación, orientación a objetos, etc. También incluye conocimiento acerca de la transformación de diseños en implementaciones, las herramientas usadas durante el proceso y métodos formales de construcción de software

� Fundamentos Matemáticos y de Ingeniería: Estos fundamentos son los que permiten describir un software de manera precisa, modelar matemáticamente y facilitar el razonamiento acerca de los productos y sus interrelaciones. Un tema central es el diseño ingenieril como un proceso de toma de decisiones de naturaleza iterativa en donde la computación, la matemática y la ingeniería son aplicados para disponer los recursos eficientemente hacia el logro del objetivo buscado.

� Práctica profesional: se relaciona con el conocimiento, habilidades y actitudes que los ingenieros de software deben poseer para practicar su profesión de una manera responsable y ética. Se incluyen acá las áreas de comunicación interpersonal, dinámicas de trabajo en equipo y psicología, y responsabilidad profesional y social.

� Análisis y Modelamiento de Software: Consideradas como conceptos claves en cualquier disciplina de la ingeniería, el modelamiento y el análisis son primero aplicados en la especificación y validación de requerimientos. Estos representan las necesidades reales de usuarios, clientes y demás contrapartes interesadas y afectadas por el sistema. la construcción de requerimientos incluye un análisis de la factibilidad de un sistema deseado, análisis y ponderación de las necesidades de las distintas contrapartes, la creación de una descripción precisa de lo que un sistema debe y no debe hacer junto con las restricciones en su operación e implementación, y la validación de esta descripción por parte de las contrapartes.

� Diseño de Software: Este tópico trata de técnicas, estrategias, representaciones y patrones usados para determinar cómo implementar un componente o un sistema. Este diseño debe estar de acuerdo a requerimientos funcionales dentro de las restricciones impuestas por otros requerimientos tales como recursos, rendimiento, confiabilidad y seguridad. Esta área también incluye la especificación de interfaces internas entre componentes de software, diseño de arquitecturas, diseño de datos, diseño de interfaces de usuario, herramientas de diseño y la evaluación del diseño.

� Verificación y Validación de Software: Esta área implica el uso de técnicas dinámicas y estáticas de revisión de sistemas para asegurar que el programa

42

resultante satisfaga su especificación y que el programa cumpla con las expectativas de los clientes y usuarios. Las técnicas estáticas tratan con el análisis de las representaciones del sistema durante todas las etapas de la vida del sistema, mientras que las dinámicas sólo involucran al sistema implementado.

� Evolución de Software: Esta se produce por la continua necesidad de soportar los intereses de clientes y usuarios en un contexto de supuestos, problemas, requerimientos, arquitecturas y tecnologías cambiantes. Esta evolución es intrínseca para todos los software que existen en le mundo real. Soportar la evolución requiere de numerosas actividades tanto antes como después de un conjunto sucesivo de versiones o mejoras al software. El concepto de evolución nace y amplía el concepto tradicional de mantención de software.

� Procesos de Software: Esta área abarca la descripción de modelos de ciclos de vida de software y los estándares institucionales de procesos de desarrollo, incluyendo la definición, medición, gestión, cambio y mejora de procesos de software y el uso de un proceso de software definido para ejecutar las actividades técnicas y de gestión requeridas para desarrollo y mantención de software.

� Calidad de Software: Este es un concepto que permea todos los aspectos del desarrollo de software, soporte, revisión y mantención. Abarca la calidad de productos del trabajo (tanto intermedios como finales) y la calidad de los procesos de trabajo usados para desarrollar y modificar los productos. Atributos de calidad son funcionalidad, usabilidad, confiabilidad, seguridad, mantenibilidad, portabilidad, eficiencia, rendimiento y disponibilidad.

� Gestión de Software: Trata acerca de cómo planificar, organizara y monitorear todos las pases del ciclo de vida de un software. La gestión es crítica para asegurar que los proyectos de desarrollo de software son adecuados para una organización, que le trabajo en unidades organizacionales esté coordinado, que se mantengan la información de las diversas configuraciones y versiones del software, que haya recursos disponibles cuando sea necesario, que el trabajo esté distribuido de manera adecuada, que la comunicación fluya, y que el progreso del proyecto sea registrado de manera precisa.

3.4.2 Modelos pedagógicos para la formación ingenieros de softwareEn el 2001, los investigadores Laurie Williams y Richard Upchurch [57], al tratar de definir un marco conceptual para la formación de los ingenieros de software orientado a definir el posible rol de las metodologías ágiles en dicha tarea, describieron los diversos modelo instruccionales que suelen ocuparse en la formación de los ingenieros de software, e hicieron un análisis de fortalezas y debilidades.

Identificación temprana de alumnos habilidosos. Consiste en seleccionar desde un principio a los alumnos con más habilidades inherentes para el diseño de software al ingresar éstos a la carrera. El problema de este enfoque es que se ha encontrado que ni las habilidades inherentes, ni las notas obtenidas en el proceso formativo, son buenos predictores del desempeño profesional, por lo que este enfoque no es una estrategia tan efectiva. Esta tendencia, sin embargo, es justamente la mejor aplicada por los organismos de educación formal, tal como lo vimos en el punto 3.3.2.

43

Entrega de conocimientos acerca de principios y herramientas para el desarrollo de softwareEste modelo consiste en enfocarse en la enseñanza de características de buenos diseños de software tales como encapsulación, modularidad, etc., poniendo énfasis en la entrega de conocimiento declarativo, consistente en el “saber qué”, el cual se obtiene principalmente a través de asistencia a charlas expositivas o a través de actividades de lectura, y en donde no existe una aproximación personalizada de la enseñanza. Pedagógicamente este modelo está relacionado con el modelo conductista de aprendizaje. Sin embargo, el sólo conocer no asegura que los alumnos puedan aplicar estos conocimientos.

Práctica profesionalEn este modelo, relacionado con la cognición situada24

Si un profesor de ingeniería de software sólo enseña conceptos en sus clases (por ejemplo, diseño Top-Down) y envía tareas prácticas a sus alumnos para ser hechas en sus hogares, está suponiendo que el conocimiento declarativo es suficiente para obtener el procedimental, lo que no es efectivo. Los alumnos deben practicar el diseño Top-Down para poder adoptarlo. Se ha encontrado por ejemplo, que enseñar a programar LISP sólo mediante lecturas no es suficiente para que los alumnos puedan resolver problemas de programación real, mientras que resolver efectivamente un problema aumenta en un 50% las probabilidades de éxito

, los aprendices se sumergen en un ambiente auténtico en el que aprenden habilidades que les servirán en el “mundo real”, comúnmente en la forma de un “proyecto”. Aquí se apunta a que hay destrezas importantes que van más allá de habilidades de programación o conocimiento declarativo, las que por lo general no se suelen definir explícitamente. Este conocimiento es llamado conocimiento procedimental, y está relacionado con el “saber cómo”. Sin embargo, se supone que los aprendices por el sólo hecho de sumergirse en este contexto auténtico aprenderán estas habilidades no declaradas.

[1].

Sin embargo, sólo aportar experiencia provoca que los alumnos tengan un entendimiento altamente acoplado con los contextos en que la obtuvieron; es decir, sólo podrán transferir sus destrezas a contextos similares a los ya practicados, lo que sólo podría ser subsanado por exponer al aprendiz a una gama muy diversa de proyectos.

La experticia por sí sola tampoco es buena predictora de éxito profesional. Ella sólo logra desarrollar ciertos niveles de competencia, pero para la mayor parte de las personas desarrollar estos niveles superiores de competencia requiere un esfuerzo deliberado en desarrollar habilidades específicas, como se verá en el punto siguiente.

Conocimiento de procesos de desarrollo de software y metacogniciónAquí el enfoque está en que el profesor debe entender e identificar explícitamente los procesos y roles necesarios para desarrollar software efectivamente. Cada proceso se debe descomponer en sub-procesos, y estos a su vez en habilidades, las que una vez identificadas, permiten por parte del profesor modelar dichas destrezas y poder entrenar y guiar a sus alumnos en ellas. Esta granularidad permitirá a los alumnos conocer de mejor forma los pasos que deben seguir, y entender mejor el rol que deberán cumplir. Este modelo es coherente con la teoría pedagógica del aprendizaje cognitivo expuesta en el punto 3.3.2, la que es una gran herramienta para trabajos cognitivos demandante como el desarrollo de software.

24 Ver 3.3.2

44

Es importante hacer notar el hecho de que cuando los alumnos resuelven problemas de desarrollo de software, no suelen considerar estrategias, planificar su aproximación al problema y evaluar su progreso para modificar su comportamiento. Es por esto por lo que además de impartir a los alumnos conocimientos declarativos sobre procesos de desarrollo de software, como el ciclo de vida de cascada, o modelos iterativos e incrementales (conocimientos declarativos sobre procesos), y llevarlos a aplicar dichos procesos en proyectos concretos de desarrollo de software (conocimientos procedimentales), se les debe hacer reflexionar sobre cada paso a medida que vayan resolviendo el problema, con el objetivo de que el aprendiz sepa cuando cambiar de actitud, y reflejarlo de manera acorde en el proceso que está ejecutando. Se ha establecido que esta actitud metacognitiva provoca en quienes la practican mejor comprensión de conceptos declarativos y mejor rendimiento en tareas procedimentales relevantes en un desarrollo de software [42]. Además, es la puerta hacia la evolución de niveles superiores de competencia en los profesionales que superan las barreras impuestas de los conceptos y experticia puros [16].

Como conclusión, se tiene que el modelo de enfoque en procesos y la reflexión metacognitva sobre ellos tienen las características adecuadas para formar las competencias en un desarrollador de software exitoso, las que nombramos a continuación:

1. entiende el o los procesos de desarrollo

2. conceptualiza un proceso deseado

3. establece acciones de mejora del proceso

4. planifica las mejoras del proceso

5. encuentra los recursos necesitados por el plan

6. ejecuta el plan

7. repite el proceso de mejora

3.4.3 Desafíos en la educación de ingeniería de softwareEl año 2004, Jazaheri [24]expuso un listado de desafíos que debe enfrentar todo currículo que busque formar ingenieros de software, y en base al cual propuso una renovación del currículo de dicha carrera en la universidad de Lugano, en Suiza. Todos estos se resumen en la necesidad de ofrecer a los alumnos una mirada lo más auténtica posible de los reales aspectos involucrados en el desarrollo de software.

En los desafíos tradicionales se encuentra el lograr un balance entre los siguientes aspectos

� Teoría versus práctica: es decir, cuánto se debe enseñar acerca del estado del arte de la práctica versus cuánto debe enseñarse sobre las miradas idealizadas de las teorías que sustentan el desarrollo de software

� Desarrollo versus gestión: consisten entre poner el foco en el producto de software a desarrollar o en cómo se debe realizar éste desarrollo

� Formalidad versus experiencia: representa la dicotomía entre aprender mediante estudio y aprender haciendo. Nótese la relación con lo expuesto en el punto 3.4.2 .

45

Adicionalmente, se plantean desafíos que corresponden a la nueva realidad del siglo 21:

� Distribución: los sistema de software han pasado de ser centralizados y monolíticos a compuestos y distribuidos, lo que plantea un sinnúmero de nuevos desafíos técnicos, como tolerancia a fallas, sincronización de datos, caching, etc., y las consecuentes cambios en las arquitecturas de sistemas enseñadas.

� Computación ubicua/interdisciplinaria: se refiere a que la computación está permeando todos y cada uno de los aspectos de la vida cotidiana de las personas, lo que implica que cada vez es más necesario que los ingenieros de software sepan y deban comunicarse de manera efectiva con expertos de otros dominios para poder desarrollar soluciones realmente efectivas

� Internet: quizás la “culpable” de los fenómenos anteriores, plantea también la posibilidad (y el riesgo) asociado de tener a mano una gran cantidad de información que, para ser realmente útil, debe ser seleccionada de manera efectiva.

� Proliferación de herramientas y ambientes de desarrollo: Tradicionalmente la oferta de una empresa de software ha estado supeditada a ambientes y herramientas específicas sobre los que ha construido experiencia. Esto es cada vez menos factible, dado que aparecen cada vez nuevas y mejores herramientas, las que deben ser apropiadas de manera eficiente. Por esto es que a los alumnos debe dárseles una educación que los exponga a diversos lenguajes de programación y herramientas de desarrollo

� Evolución de software: cada vez es más probable que un ingeniero de software deba trabajar en la evolución (o adaptación) de un sistema existente que crear un sistema desde cero. Es todo un desafío poder ofrecer a los alumnos una experiencia realista de lo que es la evolución de un software.

� Calidad de software: debido a la penetración del software, su calidad adquiere cada vez aspectos más diversos debido la gran cantidad de ámbitos en los que un desarrollo puede contextualizarse. Se critica la falta de técnicas concretas de control del calidad. Y que hay que eliminar el concepto de que “time to market” no puede ser el único mecanismo para medir el éxito de un proyecto.

� Plataformas computacionales: En la actualidad han surgido plataformas de desarrollo de valor agregado (por ejemplo, Java con su J2EE, .NET, los ambientes de desarrollo basados en lenguajes dinámicos basados en Ruby o Python) que pueden servicios similares pero que tienen además grandes diferencias. La elección de cuál o cuáles plataformas usar para la enseñanza de los ingenieros de software no puede estar influida por consideraciones de marketing, como la cantidad de personas que usan tal o cual plataforma, sino que con una mirada de mediano y largo plazo que permita a los alumnos ir evaluando y adoptando nuevas plataformas.

Además, se plantean dos desafíos no técnicos en lo que se refiere a habilidades humanas, que corresponde en el lenguaje expresado por Fred Brooks en su famoso artículo “No Silver Bullet” [12]como la complejidad accidental de un software:

� Comunicación: un ingeniero de software debe dedicar gran parte de su tiempo comunicándose con diversas tipos de interlocutores, debiendo ser capaz de adaptar el grado de abstracción y de tecnicismos en sus conversaciones de acuerdo al lenguaje que domine su contraparte, y además debe ser capaz de escuchar e interpretar

46

correctamente las necesidades expresadas por ellos, necesidades que muchas veces impactarán el diseño e implementación del sistema de software a desarrollar.

� Habilidad de trabajar en equipo: Toda ingeniería de software es ejecutada en equipos, y sin embargo esto es algo sobre lo cuál los alumnos no suelen recibir entrenamiento. La educación de los ingenieros de software por lo regular destaca las características individuales, desmereciendo la capacidad de ser un jugador de equipo. Esto lleva a formar personas que están acostumbradas a realizar acciones individuales (“heroicas”) que poco tienen que ver con un real trabajo de ingeniería. Un ingeniero de software debe no solo ser capaz de generar los productos (documentos, diseños, módulos) de los que es responsable sino que también debe poder encontrar un lugar dentro del equipo de trabajo.

De todo este listado, hay un desafío que no es nombrado y que sin embargo a la luz de esta investigación es evidente: los cambios de perspectiva acerca de cómo debe desarrollarse un software, tal como sucede en la actualidad con la revisión que las metodologías ágiles han provocado . De manera similar a lo expresado con respecto a los nuevos contextos tecnológicos, los ingenieros de software también deberán ser capaces de continuamente evaluar y adoptar en consecuencia nuevas metodologías para hacer más efectivos su trabajo.

3.4.4 Desafíos de la incorporación de XP en la formación de los ingenieros de software

Como ya fue expuesto, las metodologías ágiles nacieron fuera de la academia. Su concepción, nacimiento y posterior crecimiento han sucedido en el terreno aplicado de los proyectos de desarrollo de software que día a día se negocian y ejecutan en el mundo profesional. Por lo tanto no debe sorprender que la cultura académica imperante sea ajena a la realidad planteada por estas metodologías. Por esto, algunos han considerado que XP es de difícil aplicación en dichos contextos [45], arguyendo razones tales como “XP es para profesionales” con lo que quieren decir que XP plantea soluciones a problemas sólo visibles en un contexto profesional, y no en el académico, como por ejemplo el fenómeno de la evolución de los sistemas de software y la consecuente necesidad de sistemas de control de versiones, propiedad colectiva de código, de técnicas de refactorización o de suites de pruebas de regresión, que sería sólo apreciable en proyectos de duración mayor a los semestres académicos. Otro problema es que la formación del ingeniero de software (y los reconocimientos que ella entrega) es individual, por lo que exige un trabajo adicional que los alumnos adopten una mirada solidaria hacia un equipo en detrimento del lucimiento personal.

Además, al igual que sucede en la adopción de XP en la industria, no faltan los casos en que las prácticas, valores y principios de XP son malentendidos en menor o mayor medida por los propios docentes, como por ejemplo confundiendo XP con la Programación de Pares [58], o interpretando “40 horas a la semana” literalmente, y por lo tanto considerándola inaplicable debido a las restricciones horarias del ámbito académico [24], sin considerar su significado de fondo: dar a los desarrolladores un entorno donde se de un ritmo sostenido de productividad.

47

3.4.5 Caracterización de las aplicaciones de XP en la formación académica de los ingenieros de software

Existe un sinnúmero de matices en el espectro de apropiación de XP para la formación de ingenieros de software. A continuación presentaremos una revisión de las características que ha asumido dicha adopción en la academia.

Impacto en el currículo de la carreraLa tendencia inicial ha sido introducir XP como curso de tópicos avanzados de fines de carrera orientado a un grupo reducido de alumnos [29][38][39] lo que tiene dos implicaciones: los alumnos ya tienen una base sólida de programación y quizás conocimiento de ciclos vida de software tradicionales, lo que a su vez puede plantea el desafío de que los alumnos estén familiarizados con conceptos imperantes en la industria que son contradichos por XP25

[26]. Otros,

por su parte, abogan por introducir tempranamente XP en el currículo [10][50][30].

Otra aproximación es ir introduciendo prácticas de XP en diversos ramos como por ejemplo “Desarrollo Guiado por Pruebas” como punto de partida en cursos de Programación [49], “Entregables pequeños” para la gestión de entregas y “Programación de a Pares” para el desarrollo de tareas de programación, y “Diseño Simple” y “Refactorización” para la resolución de problemas. Esta apropiación transversal de las prácticas ha tenido ejemplos interesantes, como el aplicar “programación de a pares” entre el profesor y un aula repleta de alumnos, usando un proyector como pantalla compartida de trabajo [3].

Es importante destacar que muchas veces se suele complementar XP con herramientas y prácticas de las metodologías tradicionales como documentación exhaustiva, UML o arquitectura de software, o en paralelo con otras metodologías[47].

Un caso destacable es el plateado por el Instituto Técnico de Lund, en Suecia [22] donde se realizan dos ramos, uno a comienzos de la carrera, justo después de los ramos de programación básica, en el que se introduce el trabajo en equipo mediante XP, y otro curso posterior de profundización, orientado a la formación de coaches, cuya parte práctica es justamente dirigir a los equipos del primer curso. En dichos ramos, no sólo se enseñan las prácticas de XP “canónicas” (definidas originalmente por Kent Beck), sino muchas otras prácticas que han sido propuestas por la comunidad de desarrolladores que ha adoptado XP, y que complementan las propuestas por Beck [21].

Autenticidad de los proyectosExiste una tendencia marcada a que el proyecto donde los alumnos aplican XP esté orientado al desarrollo de productos de software que no tienen como objetivo resolver problemas de clientes reales. Esto es cierto tanto si son profesores de la misma facultad quienes ejercen el rol de clientes [24][46], o si los alumnos realizan el trabajo práctico en empresas asociadas [37].

Los proyecto suelen asumir la forma de proyectos de juguete, en donde se ha pre-diseñado un problema ficticio y se coloca como cliente a alguna persona que conozca dicho problema. Se suelen además poner restricciones a la temática del proyecto, como por ejemplo que el proyecto no sea “demasiado entretenido” para evitar que los alumnos se involucren como clientes [22].

25 Ver 0

48

Herramientas evaluativasUno de los problemas de la educación de Ingeniería de Software es la falta de visibilidad de lo que realmente están aprendiendo los alumnos [57]. En los casos recopilados en que se aplica XP, se han detectado algunas herramientas orientadas a esta labor, las que no están exentas de limitaciones.

En uno de los casos mejor documentados, el del Instituto Técnico de Lund [22] los alumnos son sometidos a una prueba de conocimientos una vez impartida la parte teórica del curso, la que en caso de ser superada con éxito habilita al alumno a ingresar a la parte práctica del desarrollo. Estos suelen aprobar esta última etapa si tienen un rendimiento normal, y la evaluación se genera recopilando las opiniones de sus pares. La razón de esta aproximación a la evaluación es que se considera muy difícil medir individualmente lo enseñado, como sucede por ejemplo con temas como “calidad de código”, “gestión de proyectos”, “capacidad de trabajo en equipo”, etc. .

Otras herramientas nombradas en las experiencias recopiladas son la realización de artículos donde los alumnos entregan su opinión de XP, y proyectan su experiencia hacia su futuro profesional [24].

Resultados obtenidosA pesar de los desafíos expuestos en el punto anterior, existe una gran cantidad de reportes [22] que indican que XP provee un excelente ambiente cognitivo para la formación de los ingenieros de software debido a su naturaleza que favorece el aprendizaje activo, y su énfasis en ir trabajando, evaluando y retroalimentando el proceso de trabajo en ciclos iterativos, haciéndoles más claro a los alumnos los procesos involucrados en un desarrollo de software [8]

Preconceptos de los alumnos versus XPA los alumnos no les agrada el trabajo adicional implicado por las metodologías tradicionales.

Los alumnos suelen ser reticentes a procesos que exigen demasiado esfuerzo en producir artefactos intermedios tales como documentación, especificaciones y diseños detallados, etc., por lo que el énfasis de XP en producir código funcional por sobre generar documentación lo hace más atractivo a los alumnos [57].

Los alumnos tienden a auto-presionarse para lograr la mayor cantidad de funcionalidades, a pesar de que no se les exija.

En el caso de el Instituto Técnico de Lund, los alumnos se rigen por la regla del “tiempo fijo”, es decir que los alumnos sólo tienen que disponer del tiempo pre-determinado definido para realizar los proyectos del curso, pudiendo este tiempo ser destinado tanto a producir código como a aprender de errores cometidos, en lo que constituye una excelente interpretación de la práctica “40 horas a la semana”. Si bien esta dicotomía de aprender versus producir es vista por algunos como un punto conflictivo, se resuelve naturalmente debido al impulso de los alumnos por generar la mayor cantidad de funcionalidades posibles, aunque no se les exija.

Los alumnos son optimistas sobre el funcionamiento de su código.

Este fenómeno, indica que los alumnos creen que su código funcionará correctamente sin la necesidad de programar pruebas. Esto tiene dos explicaciones: creer que la revisión

49

interactiva resultante de la depuración es suficiente para validar los casos relevantes, y a la ignorancia acerca de los problemas que la evaluación del código puede provocar.

Los alumnos prefieren trabajar en pasos grandes.

La noción de trabajar en pasos pequeños resulta contraintuitiva para muchos, debido a que se cree que si se tiene diseñada una solución completa, lo anterior es una pérdida de tiempo. Este preconcepto se basa en la idea de que el diseño está 100% correcto (lo que nunca es así), y que una vez definido un diseño, éste no variará.

Incomodidad ante cambios de requerimientos.

Los alumnos suelen actuar con incomodidad ante los cambios de requerimientos naturales en todo proyecto de software, muchas veces pensando que esto implicará más trabajo, ignorando por ende el modelo de gestión ágil de alcance variable.

Aceptación de prácticas de XPEn los casos analizados, la Programación de a Pares destaca como la práctica cuya adopción es más fácil y que mejores resultados inmediatos entrega a los alumnos, indicando que ella ayuda a tener mejores ideas, que es más fácil aprender de una área desconocida junto a alguien que sabe, y que por lo regular se generan mejores soluciones [24][46]. Estos logros son similares a los reportados por diversos estudios en lo que respecta a esta práctica [58]. Sin embargo, esta práctica parece ser más simple de adoptar por alumnos que por profesionales [37]

La práctica cuya adopción es más incierta es el Desarrollo Guiado por Pruebas, quizás debido a que cambia fundamentalmente el ciclo de programación al que están acostumbrados los alumnos desde el principio de su formación [24]. Otros reportes indican que si bien los alumnos al comienzo no pudieron adoptarlo, al final lo hicieron aunque con dificultades como que las pruebas estaban definidas a niveles disparejos de profundidad fluctuando entre pruebas de “caja negra” y pruebas de “caja blanca" [21]. No sería de extrañar eso sí, que en aquellos casos en que esta práctica es formada desde un principio este problema sea menor [49].

Otras prácticas cuya adopción ha sido compleja son el “Diseño Simple”, el cual suele ser confundido con “diseñar la solución fácil” por lo alumnos, en vez de apuntar a “Diseñar la solución justa para el problema conocido de manera elegante”, y la “Refactorización de código” que si bien es más intuitiva, muchas veces es abortada por la falta de dominio del Desarrollo Guiado por Pruebas que ayudaría a detectar errores introducidos por la refactorización, o por la falta de acceso a herramientas automáticas que la faciliten .

3.4.6 Un caso destacable: Role Model Software y su Software StudioLa compañía de software Role Model Software26

[53] ha implementando un modelo alternativo

para formar desarrolladores de software denominado “Software Studio” que recuerda en su estructura al taller de oficios medieval, en donde desarrolladores novicios aprenden de maestros desarrolladores27

26 www.rolemodelsoft.com

. El maestro resuelve los problemas verbalizando en voz alta las estrategias de resolución expertas, mientras los aprendices observan, aprenden y asumen tareas menores, dejando al maestro liberado para asumir las tareas más difíciles. Progresivamente, los aprendices van siendo expuestos a problemas más difíciles, aprendiendo

27 Nótese la correspondencia entre esta experiencia y el modelo pedagógico de aprendizaje cognitivo presentado en el punto 3.3.2

50

de esta manera junto con sus pares los diversos aspectos de su oficio. Este modelo favorece un aprendizaje acelerado de destrezas expertas a partir del maestro, que mejora el aprendizaje proveniente de aprender de los propios errores.

La motivación originaria de esta iniciativa proviene de la frustración con respecto a los resultados de los alumnos formados en las universidades, representada en la frase “se aprende más del oficio en los primeros 6 meses de trabajo que en los años de universidad”. Este fenómeno provoca que las empresas deban invertir muchos de sus recursos en capacitar a los jóvenes provenientes de la academia. Y el diagnóstico que se hace del origen del problema es el siguiente: se enfatiza en entregar conocimientos, pero no generar sabiduría. Es decir, los alumnos aprenden un sinnúmero de conceptos y herramientas que creen verdades absolutas, por lo que no tienen criterio formado de cuándo hay que usarlas. Un ejemplo sería un desarrollador novato que gasta muchos esfuerzos en optimizar el ordenamiento mediante el algoritmo de quicksort de una lista que en definitiva sólo va ordenarse al inicializarse el sistema.

Este enfoque en conocimientos es característico de modelos tradicionales de educación y que aún imperan en la educación formal, tal como se vio en el punto 3.3.1

Ilustración 13: Ambiente de trabajo del Software Studio

El Software Studio (cuyo funcionamiento se aprecia en la Ilustración 13) se plantea entonces como un entorno educativo más adecuado que la sala de clases, donde los aprendices son expuestos a proyectos reales, con clientes y necesidades reales, en un ambiente de fuerte colaboración, con un espacio físico adecuado donde se les enseña de manera personalizada tanto destrezas de programación como a relacionarse con el cliente, enfocados siempre a generar software real.

¿Y en qué se basan las destrezas que adquieren los aprendices? En los valores, principios y prácticas de XP, las que ofrecen un contexto natural de aprendizaje de todos los aspectos nombrados anteriormente.

La evaluación del aprendizaje se basa en la calidad del software generado, en la retroalimentación del maestro y en la evaluación de los propios pares, siendo estos últimos los que tienen la ventaja de estar más cerca de la persona evaluada.

51

Una última consideración es que este modelo de enseñanza es independiente de las tecnologías que se utilizan para resolver los problemas, considerándose éste un conocimiento que es específico a cada proyecto.

52

4. PROPUESTASEn este capítulo se presentan las propuestas que se elaboraron para esta investigación, con el objetivo de abordar las hipótesis planteadas en el capítulo 2, tal como se muestra en la Tabla 12.

Hipótesis Propuestas

Es posible ofrecer a los alumnos de ingeniería de software una experiencia representativa de las metodologías ágiles - en particular Extreme Programming – dentro del marco, recursos y tiempo de un curso normal de la carrera.

� Un diseño instruccional que configura un curso de ingeniería de software en un ambiente de trabajo representativo de XP.

Al reproducir fielmente un ambiente de trabajo ágil se obtienen buenos resultados en los aprendizajes de los alumnos gracias a la naturaleza del ambiente ágil orientado a potenciar el aprendizaje continuo en sus integrantes.

� Una conceptualización de cómo XP organiza el ambiente de un desarrollo de software para lograr armonizar los diversos componentes de éste y lograr así una construcción continua de conocimiento y valor.

� Un modelo evaluativo basado en la conceptualización anterior, que servirá para medir los aprendizajes de los alumnos a los que se les aplica el modelo instruccional nombrado anteriormente, y así poner a prueba lo observado en años anteriores de manera intuitiva.

Tabla 12: Propuestas para las hipótesis de esta investigación

53

4.1 El curso CC62V “Taller de metodologías ágiles de desarrollo de software” y su diseño instruccional

Antes de describir en específico el caso del curso CC62V, es bueno preguntarse cuál es el aporte que las metodologías ágiles pueden realizar en la formación de los futuros ingenieros de software.

Desde la reunión que dio origen a la Alianza Ágil, se ha propuesto que una de las mejores formas de impulsar los principios ágiles es a través de la llegada a la formación misma de los desarrolladores en su formación. [15]. Esto ha sido denominado por algunos como una verdadera “inculturación” de los valores, principios y prácticas de XP[56]. Más allá del proselitismo, desde el surgimiento de XP ha existido mucho interés acerca de su aplicación en la formación de los ingenieros de software.

Ahora cabe preguntarse: ¿qué beneficios podría tener el incorporar las metodologías ágiles en la formación de los ingenieros de software? Si contrastamos el listado de desafíos para la educación de ingenieros de software (expuestos en el punto 3.4.3) con la propuesta de XP, podemos observar una interesante correlación, tal como se muestra en la Tabla 13.

Desafío Propuesta de Extreme Programming

Teoría versus práctica El énfasis de XP es claramente práctico, sin embargo se complementa naturalmente con el aprendizaje de contenidos teóricos,

Desarrollo versus gestión

En XP se abarcan ambos aspectos de forma balanceada, integrando conceptos de gestión de requisitos (Planning Game), monitoreo de avance con el tracking y de programación (programación de a pares, refactorización, diseño simple) entre otros

Formalidad versus experiencia

La técnicas de XP son más proclives al enfoque empírico, ajustando los formalismos sólo a lo que acuerde el equipo de trabajo

Distribución

Internet

Proliferación de herramientas y ambientes de desarrollo

Plataformas computacionales

XP es neutro con respecto a estos tópicos. No está asociado tampoco a tecnologías y herramientas específicas sino a técnicas que cuando han sido transformadas en herramientas han sido rápidamente adoptadas por un sinnúmero de plataformas, como sucede en el caso de los frameworks de testing unitario para el desarrollo guiado por pruebas, que existen para la mayoría de los lenguajes y plataformas actuales.

Computación penetrante/ interdisciplinaria

XP soporta directamente el desarrollo interdisciplinario, al integrar en el equipo de desarrollo al cliente y al generar un lenguaje común mediante la metáfora y el Planning Game

Evolución de software XP está diseñado justamente para el diseño y construcción de sistemas cuyo costo de cambio es aceptable

Calidad de software XP propone un conjunto de técnicas concretas de control temprano y constante de la calidad del software, tanto a nivel técnico mediante pruebas de unidad como a nivel del cliente mediante la aplicación de pruebas funcionales para realizar la aceptación de un módulo.

54

Desafío Propuesta de Extreme Programming

Comunicación Es uno de los valores de XP y está soportado por prácticas como programación de a pares, metáfora, diseño simple, Planning Game, y muchos más.

Habilidad de trabajar en equipo

Es un punto abordado directamente por XP. Se propone un sistema de liderazgo motivador (coaching), un ambiente físico que potencie el trabajo y la retroalimentación, y principios como la “responsabilidad asumida” y “jugar a ganar, entre otros.

Cambios de perspectiva acerca de cómo debe desarrollarse un software

XP obviamente propone una mirada comprometida con una perspectiva particular del desarrollo de software. Sin embargo, el principio de “adaptación local” apunta a darle flexibilidad al método de tal forma que sea la realidad del desarrollo mismo la que dicte la mejor forma de trabajar, y no lo expresado en un estándar o en un libro.

Tabla 13: Desafíos de la enseñanza de la Ingeniería de Software y cómo XP puede ayudar a abordarlos

Como podemos observar, existe una gran sintonía entre los desafíos que tiene la educación de los ingenieros de software en la actualidad y las respuestas que XP entrega, por lo cual se justifica plenamente el interés por incorporar a XP y otras metodologías ágiles al currículo.

4.1.1 Orígenes del Curso CC62VEl curso CC62V nace ante la inquietud de poder evaluar en la práctica lo que en el año 2002 era una propuesta interesante pero inexistente en el mercado Informático nacional: Extreme Programming. Es por esto que se propuso al Departamento de Ciencias de la Computación constituir un nuevo curso denominado “Taller de Metodologías Ágiles de Desarrollo de Software”, en donde, de manera colaborativa, los alumnos podrían investigar y aplicar en proyectos reales esta nueva mirada al desarrollo de software. Es así que este taller se impartió por primera vez en el segundo semestre del 2002, con 18 alumnos y 2 proyectos a desarrollar: un sistema de análisis de genes y un sistema de administración de documentación de proyectos para un curso paralelo. Todo el desarrollo se realizó en la horas del curso, y de manera sorpresiva y contrastando con la realidad de otros ramos en los que se desarrollaban proyectos de software, el último día de trabajo los clientes obtuvieron un software validado, funcional y útil, sin que los alumnos tuviesen que invertir horas extra ni entrar en un ritmo estresante para finalizar el proyecto. La opinión de los clientes y de los alumnos registrada en sus ensayos de opinión era clara: “XP funcionaba”. Pero había algo más. En ese curso no sólo se estaba experimentando por primera vez con una forma de desarrollar software, sino que además se había aplicado una nueva manera de enseñarla. Es decir, no sólo XP funcionaba, sino que, y a pesar de lo difícil que es adoptar XP, también el modelo instruccional curso lo hacía, pero no quedaba claro por qué.

Los resultados exitosos se extendieron en los años siguientes. El año 2003 se realizó como único proyecto la continuación del desarrollo del software de análisis de genes, que luego fue finalizado en el curso del 2004, en donde además se implementó un juego educativo en tecnología Macromedia Flash.

Es así que la motivación originaria de esta investigación es descubrir las claves que explican los resultados de este curso, y para esto se utilizó la experiencia de la última encarnación de éste sucedida entre los meses de agosto y noviembre del año 2005.

55

4.1.2 Contexto del cursoEl curso CC62V está inmerso en la realidad de la carrera de Ingeniería Civil en Computación de la Facultad de Ciencias Físicas y Matemáticas de la Universidad de Chile, cuya malla de cursos se puede apreciar en la Ilustración 14.

Ilustración 14: Carrera de Ingeniería Civil en Computación y el contexto en donde se aplica el curso CC62V

56

En los ramos iniciales los alumnos reciben formación sobre los fundamentos de las ciencias de la computación. En el ramo CC31B los alumnos se enfrentan por primera vez a un curso en donde se abordan los conceptos de la Ingeniería de Software y en particular se les introduce a los modelos de ciclos de vida. Después en CC51A deberán realizar un desarrollo de software siguiendo una adaptación del estándar de ciclo de vida de la European Space Agency. El rol de cliente es comúnmente encarnado por otro miembro del staff académico de la facultad. Los alumnos, por su parte, suelen seguir una estricta división de roles, tales como Jefe de Proyecto, Ingeniero de Requerimientos, Ingeniero de Diseño, Ingeniero Codificador, o Ingeniero de Pruebas.

Posteriormente a CC51A viene el ramo CC61A “Proyecto de Software”, en donde los alumnos agrupados en equipo de 5 a 6 personas trabajan durante 3 meses con dedicación de 20 horas a la semana en proyectos reales para clientes externos, usualmente empresas. Al momento de partir el curso CC62V (año 2002), CC61A consistía en una aplicación directa en la realidad de la metodología ESA. Las herramientas de seguimiento y control del ramo tenían una mirada “vertical” del desarrollo del software, reportándose el tiempo ocupado en cada etapa del ciclo de cascada,. Desde el segundo semestre del 2004 el autor de esta tesis se hizo cargo de dicho curso, implementando un modelo híbrido que combina la filosofía de gestión de proyectos de software de XP ya validada en el curso sobre el que trata esta investigación, complementándolas con herramientas simplificadas de documentación.

Caracterización de las destrezas de entrada de los alumnosA partir de lo mostrado en el punto anterior, podemos indicar ciertas características de los alumnos del curso CC62v al llegar a éste.

Fuerte base de Ciencias de la Computación

La malla de la carrera ha ido seleccionando a los alumnos con las destrezas relacionadas con las Ciencias de la Computación, y les ha aportado conocimientos tales como:

� Programación, compilación y depuración de programas de software, especialmente en ambiente UNIX, pero también en Windows

� Diseño y programación de algoritmos

� Teoría y programación de autómatas

� Programación Orientada a Objetos

Además, los alumnos han tenido que trabajar al menos con los lenguajes Java y C. Otros lenguajes que dominan son PHP y Javascript para el desarrollo de aplicaciones web.

Predominancia del ciclo de vida de cascada

Los alumnos desde el comienzo de la carrera se enfrentan a “tareas de programación” cuyos requerimientos son generalmente inequívocos, y que no cambian ni evolucionan en el tiempo, y por lo tanto son susceptibles de ser abordados usando un ciclo de vida de cascada. Esto no corresponde a la realidad de la industria, en donde las funcionalidades realmente necesitadas de un software son descubiertas a medida que este se va desarrollando, en un contexto de permanente adaptación a cambios internos del cliente y del entorno en que este se desenvuelve.

Pocas herramientas de trabajo en equipo

A pesar de que los alumnos desarrollan algunos proyectos en equipos (una pequeña fracción del total), no existe una enseñanza de técnicas que potencien la colaboración y trabajo

57

comunitario, base del concepto ágil de desarrollo. Además, los alumnos están acostumbrados a un modelo de división de roles en donde el ingeniero codificador, por ejemplo, no tiene gran interacción con el cliente, ni realiza acciones de control de calidad.

El concepto sobre la relación cliente-desarrollador es aún más débil, concibiéndose al primero sólo como una contraparte, y no como un colaborador en el contexto de un mismo esfuerzo.

Diversa experiencia laboral

En los ramos finales de la carrera es posible encontrar alumnos que ya tienen años de experiencia laboral y algunos que sólo han realizado las prácticas profesionales obligatorias. Sin embargo, es común que las mejores prácticas de gestión y desarrollo de software que dominan sean sólo aquellas aprendidas durante el transcurso de la carrera, y no desde sus experiencias laborales externas.

4.1.3 Diseño Instruccional del curso CC62VEl objetivo del curso CC62V consiste en que los alumnos puedan experimentar en la práctica las metodologías ágiles de desarrollo de software, y en particular “Extreme Programming” (XP)

Específicamente, se espera que los alumnos logren:

� Apropiarse del marco conceptual de las metodologías ágiles y de XP, en particular de los valores, principios y prácticas.

� Aplicar e internalizar las destrezas enfatizadas por XP a través de sus prácticas

� Discernir el valor relativo de cada práctica y poder decidir informadamente su uso, proyectándolas a su aplicación futura en la vida profesional

Estos objetivos se implementan a través de varios principios de diseño que se explican en detalle a continuación.

Principio de diseño: CC62V como metáfora de XPComo principio general de diseño del curso, se buscó que cada actividad a los que los alumnos se expusieran expresara algún valor, principio o práctica de Extreme Programming, buscando aplicarlo de la manera más completa y cercana al “libro”, en este caso, “Extreme Programming Explained”, lo que constituye una aplicación directa del principio constructivista ”Aprender Haciendo”. A continuación presentamos cómo esto es posible.

Aplicación de valores

Los principios de agilidad, retroalimentación y responsabilidad asumida son aplicados prontamente: luego de una breve introducción teórica sobre las bases de las metodologías ágiles, los alumnos se involucran rápidamente en el descubrimiento y comprensión de la metodología al tener que ellos mismos preparar y luego dictar charlas sobre diversos aspectos de XP para sus compañeros, las que en el momento de ser realizadas son mejoradas a partir de las consultas y del aporte de los alumnos y del profesor.

El principio de “adaptación local” se refuerza a través de pedir a los alumnos ensayos en los que van evaluando la aplicación y utilidad de las prácticas de XP, para finalmente proyectar su uso en la vida profesional el finalizar el ramo

58

Aplicación de prácticas

Las prácticas de desarrollo de software (diseño simple, refactorización, desarrollo guiado por tests, integración continua) son enseñadas y luego aplicadas en un desarrollo de software en equipo durante las horas de sesiones de taller.

Del mismo modo son aplicadas las prácticas de trabajo en equipo (de desarrollo: programación de a pares, estándares y propiedad colectiva de código; y de gestión: espacio de trabajo informativo y “stand up meetings”). En el caso de la programación de pares y del espacio de trabajo informativo, se les insiste a los alumnos en la importancia de transformar su ambiente de trabajo (en este caso de la sala de clases) de tal manera que se logre un ambiente que facilite el trabajo, lo cual ellos no están acostumbrados a realizar.

Principio de dedicación de Tiempo fijo y “miniaturización” de XP

El curso tiene definida una carga de trabajo estimada en 10 horas de trabajo por semana, con 3 horas de sesiones presenciales y el resto a distancia. Siguiendo el principio de gestión de tiempo de timeboxing28

Planificación del desarrollo

y a la práctica de XP “productividad sostenida”, se destina para el desarrollo en equipo las horas presenciales del curso, quedando el trabajo en casa destinado principalmente a la investigación y preparación de ensayos.

Al contar con estos tiempos, se “miniaturiza XP”. Por ejemplo, si en la vida real una iteración de un proyecto XP dura 3 a 4 semanas de trabajo de un equipo en jornada completa, y un entregable se genera en 3 iteraciones, en el curso una iteración consistirá de un conjunto de sesiones del taller, no debiendo superar como regla general la mitad de las sesiones disponibles en el semestre, con el objetivo de que los alumnos puedan experimentar en la práctica un desarrollo iterativo. Asimismo, en el curso, un se motiva a los alumnos a entregar software útil para el cliente al fin de cada ciclo, homologando así los tiempos de una iteración con los de la generación de un entregable. Si los alumnos no logran un producto al final del ciclo, el profesor mediará la relación entre ellos y el cliente para que el resultado final del proyecto sea un software realmente funcional y valioso.

En la primera encarnación del curso, se realizaban en 2 sesiones separadas de 1,5 horas cada una (martes y jueves). Los alumnos de ese entonces, en su evaluación del curso, plantearon que este modelo era incómodo debido a que al comienzo de cada sesión debía gastarse un tiempo no despreciable en poder entrar en ritmo de trabajo (tanto de punto de vista de adaptar el ambiente físico, configurar las herramientas de desarrollo y lograr la concentración del equipo) lo que implicaba que el tiempo productivo fuera reducido. Por esto se propuso que el curso debía tener 2 módulos consecutivos para completar así 3 horas de trabajo lineales, y así poder disponer de más de tiempo de trabajo realmente productivo para el desarrollo.

En las primera sesiones del curso los alumnos y clientes participan de un taller explicativo del “Planning Game” basado en el “extreme hour” – presentado en el punto 0 -. En las clases posteriores, y siguiendo lo aprendido en el taller realizan un “Planning Game” para planificar el proyecto real, que constituye el punto de partida para su desarrollo.

Organización del equipo

La gestión de equipo es liderada por un coach, que es un alumno escogido por sus propios compañeros, y es apoyado por un tracker el cual debe mantener actualizada las herramientas

28 Véase el punto 3.2.1

59

de comunicación grupal que componen el espacio informativo en la sala de taller a partir de la retroalimentación del avance de sus compañeros.

Todos los alumnos son responsables transversalmente de realizar todas las labores de un desarrollo de software (incluyendo diseñar, documentar de acuerdo a requerimientos del cliente, y realizar pruebas). La división de tareas se realiza mediante la distribución entre los desarrolladores de las “historias de usuario” generadas por el cliente, las que deben ser implementadas de punta a cabo por ellos, con ayuda de sus compañeros para programar de a pares, y hasta lograr la aceptación del cliente mediante la aplicación de pruebas de aceptación.

Autenticidad a través de clientes reales con necesidades realesUna de las decisiones de diseño del curso fundamentales fue que los alumnos deberían poner en práctica XP haciendo un proyecto para un cliente real, dentro de un contexto real. La única limitación que debieran cumplir los clientes al respecto es que el producto no debería tener fines de lucro, y el pago del desarrollo del software sería a través de la asistencia a las sesiones del taller para cumplir el rol de “cliente in situ”.

Esta decisión se justificaba por el objetivo principal del taller: poder evaluar en la práctica las metodologías ágiles, para que en definitiva los alumnos puedan desarrollar una opinión propia acerca de lo practicado. Si a los alumnos se les plantease un proyecto de juguete pre-diseñado, sería muy difícil saber si esto está sesgando la apreciación final de los alumnos. Esto explica el por qué no hay distinciones acerca del tema del proyecto, y que no haya limitaciones acerca del tipo de proyecto a abordar.

Al lograrse buenos resultados con los clientes, se reforzó la decisión de dar autenticidad en los proyectos, apoyado además por la naturaleza auto-adaptable del trabajo al estilo XP, que está orientada a obtener el mejor producto posible dados el tiempo y recursos disponibles.

Sistema de evaluaciónLa evaluación del curso tiene 3 componentes:

� Evaluación de resultado (Ponderación: 30%): Como todo curso de ingeniería de software, no debe omitirse la meta de lograr un software satisfactorio en los tiempos y plazos del proyecto. Se basa en la calidad del producto de software desarrollado, y considera en ella la opinión del propio cliente.

� Evaluación de proceso (Ponderación : 40%): Esta evaluación considera los siguientes aspectos:

o Cumplimiento de tareas: puntualidad y cumplimiento requisitos estipulados por el profesor

o Co-evaluación: Evaluación recibida por el alumno de sus pares, de acuerdo a su dedicación, responsabilidad y capacidad de trabajo en equipo.

60

� Evaluación experimental (Ponderación : 30%): en forma grupal e individual los alumnos deberán reflexionar y evaluar la metodología aprendida, considerando:

o Aplicación: el grado de uso y la dificultad relativa experimentada en cada práctica

o Utilidad: qué tan útiles fueron las prácticas enseñadas

Las reflexiones y evaluaciones son plasmadas en ensayos de opinión que son entregadas en la mitad y al finalizar el semestre.

Para aprobar el curso, el alumno debe lograr una calificación superior o igual a 4.0 en los tres componentes especificados. En caso de que el alumno no logre el 4 en alguno de éstos tópicos, deberá realizar un trabajo adicional.

Rol del docenteTal como se aprecia en la Ilustración 15, en el curso conviven clientes, aprendices que conforman un equipo de desarrollo, y el profesor. Este último asume el rol de mediador donde la principal función es el apoyo metodológico, es decir, es quien explica y guía el uso de las prácticas, principios y valores de la metodología, apoyando la tradicional relación cliente-desarrollador.

Ilustración 15: Relación entre los diversos integrantes del curso

Este rol es similar al de un coach, pero a un nivel macro, y tal como aquel puede apoyar también desde el punto de vista técnico aportando ideas y apoyando la investigación de alternativas si es estrictamente necesario. Debe hacerse, eso sí, una salvedad: el docente nunca debe actuar como representante del equipo de desarrollo ante el cliente, porque éste

ProyectoProyecto

ClienteCliente

Equipo de Desarrollo(Aprendices)

Profesor / MediadorProfesor / Mediador

Prácticas PrincipiosValores

Conocimien

to d

el Pro

blema Desarrollo

Tecn

olog

ía

e

61

último entonces tenderá a ignorar a los alumnos como interlocutores válidos ahora que tiene a su disposición una persona de mayor experiencia.

Planificación del cursoEl formato del curso es de sesiones de 3 horas de trabajo presencial a la semana y 7 horas de trabajo de investigación a distancia. Se dispone de un profesor y los cupos disponibles para el curso son 20, y el trabajo se dividirá en grupos con un máximo de 10 alumnos por cada uno.

Sem

ana

Actividades

En horas del taller Fuera del taller

Teó

rico

0 Introducción al curso Informe sobre conocimientos previos

1

Presentaciones Iniciales Informes de opinión y dudas surgidas a partir de lo expuesto en las prácticas 2

Prá

ctic

o

3

Desarrollo del Proyecto usando XP

Investigaciones ad-hoc con respecto al proyecto o a la metodología

Generación de ensayo sobre XP y su aplicación

Generación de informe sobre el proyecto y la aplicación de XP en el proyecto

Investigaciones ad-hoc con respecto al proyecto o a la metodología

4 5

6 7

8 9

10

11

12

13

14

Posterior

Presentación grupal final Generación de informe sobre la aplicación de XP en el proyecto y su proyección futura

Tabla 14: Esquema estructurado de actividades del curso

Tal como se puede apreciar en la Tabla 14, el curso está estructurado en dos grandes secciones, las que serán descritas a continuación.

Fase Teórica (3 a 4 sesiones)

En esta fase todo el curso colabora para explorar en detalle en qué consiste XP. La primera sesión es dictada por el profesor, quien presenta los fundamentos que dieron origen a las metodologías ágiles y a XP en particular, haciendo una breve revisión del estado del arte de la Ingeniería de Software y enfatizando las razones que motivan el surgimiento de esta nueva mirada al desarrollo de software, de manera similar a lo expuesto en el punto 3.2 de esta investigación. Posteriormente se presenta de manera somera el marco conceptual de XP, el cual es explorado en mayor profundidad en sesiones posteriores.

El involucramiento temprano de los alumnos se logra por los siguientes medios:

� Deben discutir en grupo y luego presentar sus conocimientos previos sobre XP

62

� Se realiza un “extreme hour” para poder entender de manera más simple cómo funciona el modelo de gestión de XP.

� Los alumnos se inscriben para realizar charlas sobre prácticas de XP en las sesiones posteriores, de preferencia escogiendo ellos mismos los temas presentados.

Para facilitar la presentación de las prácticas se han diseñado las siguientes herramientas de aprendizaje:

Organización de valores principios y prácticas

Como es presentado en el punto 0, uno de los mayores desafíos de adoptar XP es dominar la gran cantidad de conceptos que subyace en esta propuesta. Para abordar este desafío se generaron dos organizadores de información que permiten presentarla de manera concisa, tal como se ve a continuación.

Ilustración 16: Presentación de valores asociando los principios a cada uno de ellos

Tal como se aprecia en la Ilustración 16, se funden en uno solo el listado de valores y principios, asociando cada uno de éstos últimos con un valor específico.

RetroalimentaciRetroalimentacióónn••RRáápida (favorece el aprendizaje)pida (favorece el aprendizaje)••Medir honestamenteMedir honestamente••Experimentos concretosExperimentos concretos

CorajeCoraje••Jugar a ganarJugar a ganar••Responsabilidad aceptada (antes que asumida)Responsabilidad aceptada (antes que asumida)••Trabajo de CalidadTrabajo de Calidad••Atacar problema urgente, dejando la mayor Atacar problema urgente, dejando la mayor cantidad de opcionescantidad de opciones

SimplicidadSimplicidad••Asumirla siempreAsumirla siempre••Viajar con equipaje: poco, simple y valiosoViajar con equipaje: poco, simple y valioso••Cambios paso a pasoCambios paso a paso••AdaptaciAdaptacióón localn local

ComunicaciComunicacióónn(Centro de todo problema humano)(Centro de todo problema humano)

••Abierta y honestaAbierta y honesta••EnseEnseññar a aprenderar a aprender••Trabajar Trabajar concon los instintos de las personaslos instintos de las personas

RetroalimentaciRetroalimentacióónn••RRáápida (favorece el aprendizaje)pida (favorece el aprendizaje)••Medir honestamenteMedir honestamente••Experimentos concretosExperimentos concretos

CorajeCoraje••Jugar a ganarJugar a ganar••Responsabilidad aceptada (antes que asumida)Responsabilidad aceptada (antes que asumida)••Trabajo de CalidadTrabajo de Calidad••Atacar problema urgente, dejando la mayor Atacar problema urgente, dejando la mayor cantidad de opcionescantidad de opciones

SimplicidadSimplicidad••Asumirla siempreAsumirla siempre••Viajar con equipaje: poco, simple y valiosoViajar con equipaje: poco, simple y valioso••Cambios paso a pasoCambios paso a paso••AdaptaciAdaptacióón localn local

ComunicaciComunicacióónn(Centro de todo problema humano)(Centro de todo problema humano)

••Abierta y honestaAbierta y honesta••EnseEnseññar a aprenderar a aprender••Trabajar Trabajar concon los instintos de las personaslos instintos de las personas

63

Ilustración 17: Organizador de prácticas de XP por afinidad

De manera similar, en la Ilustración 17 las prácticas se presentan organizadas de manera temática, según tres ejes:

� Desarrollo

� Trabajo en equipo

� Planificación y Gestión

Algunas prácticas que sirven de contexto o para enlazar estos temas son presentadas fuera de los ejes organizadores. Adicionalmente, aquellas prácticas que aparecen muy relacionadas entre sí son presentadas “pegadas” unas con otras. Como una forma de facilitar la búsqueda de información acerca de estas prácticas, se les aporta también una versión en inglés con los nombres originales de cada una.

El objetivo de estas herramientas es facilitar a los alumnos el recordar el marco conceptual de XP. Recordemos que diversos estudios han planteado que la memoria de corto plazo del ser humano tiene una capacidad máxima de retener conceptos, establecida en 1956 por Miller en aproximadamente 7 con una variación de 2 dependiendo de la persona [37], cantidad posteriormente revisada por Cowan en solamente 4 [16], por lo cual es de gran importancia organizar y clasificar el marco conceptual para que los alumnos, a partir de recordar ejes organizadores puedan ir recordando y adoptando el lenguaje de XP.

Simplificación de las reglas de gestión

De manera similar a lo realizado con el marco conceptual, se ha reorganizado la declaración de derechos y deberes de desarrolladores y clientes de manera de extraer un modelo simple

Trabajo en equipoTrabajo en equipo

DesarrolloDesarrollo

Valores de XPValores de XP

ComunicaciónRetroalimentación

CorajeSimplicidad

PlanificaciPlanificacióón y Gestin y Gestióónn

Entregas cortas

Integracióncontinua

Estándares de Código

Propiedad Colectiva de

Código

Programación de a pares

(+ Mantener el equipo en movimiento)

MetáforaCliente en terreno

(a.k.a. Un sólo equipo)

Planning Game

(+ Control de avance)

RefactorizarDesarrollo Guiado por

Tests

•40 Horas por semana•No a las horas extra•Ritmo sostenido de avance•Espacio de trabajo informativo

Diseño Simple

Tests de Aceptación del

Cliente

PrPráácticas de XPcticas de XP

64

que establezca las reglas básicas de convivencia para una gestión sinérgica de proyectos, lo que ha sido sistematizado en la Tabla 15:

Tabla 15: Reglas de convivencia entre clientes y desarrolladores

Fase Práctica

En esta fase se comienza a practicar la versión “miniaturizada” de XP, que restringe el desarrollo a la duración de la sesión (3 horas). La sesión inicial parte con un “Planning game”, en donde se define el alcance de la iteración, siguiendo las reglas presentadas en la Tabla 15.

A partir de entonces, cada sesión tiene una estructura de manera similar, tal como se presenta en la Tabla 16:

Momento Descripción

Preparación del ambiente de trabajo.

Consiste en convertir la sala de clases del curso en un ambiente propicio de trabajo. En particular:

Instalación de equipos29: desde hace dos años se dispone de PC portátiles, los que son solicitados e instalados en una sala de clases con conectividad inalámbrica a redes y habilitada con tomas de corriente.

Disposición de puestos de trabajo: se cambia la disposición de mesas y sillas para facilitar la programación de a pares y la rotación dentro del equipo

Ubicación de radiadores de información: Los alumnos disponen en las paredes de la sala los “radiadores de información”, consistentes en papelógrafos en donde hay “post-it” que indican las historias de usuario que deben completar.

Stand-up meeting

Tal como lo indica la práctica de XP, el equipo se reúne de pie y se pone al día acerca de cuál es el estado de avance. Luego se coordinan y distribuyen las metas de la sesión. Idealmente se incluye al cliente, pero por lo regular la conversación con él ocupa más tiempo, por lo cual los desarrolladores conversan con él después.

29 -Antiguamente, se debía solicitar computadores en un laboratorio de computación y trabajar junto a decenas de alumnos

ocupados en labores distintas, lo que obviamente entorpecía el trabajo.

Cliente DesarrolladorDesea maximizar

Valor recibido por cada semana de desarrollo

Calidad del trabajo realizado

Puede definir Qué será implementado, y en qué prioridad, según las necesidades de su negocio

Cuánto se estima que demorará una tarea (idealmente)

Puede cambiar

Funcionalidades solicitadas por otras no implementadas de costo equivalente (canjear)

Sus estimaciones en base a nuevos descubrimientos

C

65

Momento Descripción

Desarrollo Este es el momento del trabajo de desarrollo en sí. La dinámica del trabajo sucede tal como en XP: cada desarrollador se ha anotado para el desarrollo de alguna tarea específica, para lo cual solicita la ayuda de algún compañero para trabajar de a pares. En caso de dudas sobre la historia de usuario deben consultarle al cliente, y en el caso de dudas metodológicas deben consultar al profesor. También se le van presentando al cliente las historias de usuario para su aprobación de acuerdo a las pruebas funcionales anteriormente definidas con él en el planning game. Respetando el principio de adaptabilidad al cambio, el cliente puede en cualquier momento cambiar historias de usuario, solicitando al equipo re-estimar el esfuerzo y canjear la nueva funcionalidad por aquellas de esfuerzo equivalente que aun no hallan sido abordadas.

Con respecto a los descansos, durante la fase teórica, es el profesor quien define un recreo en la mitad de la sesión, en cambio en esta fase se motiva a los alumnos que tomen un descanso (razonable) cada vez que se han obtenido logros, o como una manera de despejarse en el caso de llevar demasiado tiempo empantanados en un problema

Reflexión final y asignación de tareas para la semana

Al ir finalizando el tiempo de la sesión, el profesor motiva el cierre del trabajo, con el objeto de que el curso en conjunto pueda evaluar lo aprendido durante la sesión. Esto se realiza en un diálogo abierto moderado por el profesor, y en donde se incorpora también al o los clientes cliente de él o los proyectos en ejecución.

Fruto de la reflexión, el profesor en conjunto con cada equipo define las tareas de investigación para la semana. En el caso de los alumnos que faltaron a la sesión, se definen la tareas de desarrollo con las que deberán devolver las horas de trabajo que sus compañeros ya aportaron

Cierre de la sesión y vuelta a la normalidad de la sala

El ambiente de trabajo configurado en la sala es retirado: las mesas y sillas devueltas a su posición normal, los computadores devueltos y los radiadores de información son guardados por los alumnos para ser traídos a la sesión siguiente.

Tabla 16: Estructura de una sesión del curso

66

4.2 XP como organizador de un ambiente de desarrollo de software

Tal como se vio en el capítulo 3.2.1, el contexto de un proyecto de desarrollo de software es de alta complejidad cognitiva, debiendo el ingeniero de software lograr una relación armónica con elementos que se encuentran en constante cambio (ver Ilustración 18):

� el problema de negocio (a través del cliente),

� sus compañeros de equipo,

� el producto de software mismo, y a través de éste la o las tecnologías aplicadas,

� todo lo anterior englobado en un proyecto de software, en donde se aplican un conjunto de valores y técnicas, lo que constituye el proceso de desarrollo.

Ilustración 18: El complejo entorno de un proyecto de software desde la mirada de un ingeniero de

software

En la Tabla 17 se describen los diversos desafíos que un ingeniero de software debe resolver en este entorno. Con respecto a Desafío del Ingeniero de Software en un Proyecto de desarrollo El Cliente y el problema de negocio

� Entender cuál es la necesidad que gatilla el desarrollo del producto y las funcionalidades que se están desarrollando

� Establecer una relación de confianza a través de un diálogo continuo en pro de clarificar los requerimientos, ajustarse a sus cambios y validar lo desarrollado

� Tener una actitud decidida en pro de generar valor

Ingeniero de Software

Equipo de Desarrollo

Producto de Software

Tecnología

Problema de Negocioob e a de egocc ocCliente

Proyecto de Software

67

Con respecto a Desafío del Ingeniero de Software en un Proyecto de desarrollo El equipo de desarrollo

� Lograr una relación de confianza y ayuda mutua � Establecer un lenguaje, prácticas y valores comunes � Evitar la atomización/fragmentación del conocimiento

Las tecnologías usadas

� Aprender las funcionalidades y herramientas asociadas a una tecnología. Mantenerse al día en ellas

� Poder evaluar y escoger dentro de las alternativas tecnológicas a partir de sus fortalezas y debilidades, y comunicar las implicancias de ellas para el proyecto

El proyecto y su producto

� Saber qué se ha desarrollado y qué no (visibilidad) � Poder estimar cuánto y qué queda por hacer � Poder percibir el valor aportado al cliente con lo desarrollado

(Importante para la motivación) � Construir un producto de calidad

El proyecto y su proceso de desarrollo

� Dominar las prácticas de la metodología usada � Poder evaluar el trabajo realizado y aplicar mejoras al proceso

Tabla 17: Desafíos del Ingeniero de Software en un Proyecto de desarrollo

Es importante hacer notar que en el caso de que el ingeniero de software esté en el rol de Coach, existen desafíos adicionales, los que se muestran en la Tabla 18.

Con respecto a Desafío del Ingeniero de Software El equipo de desarrollo

� Lograr que cada miembro del equipo pueda poner lo mejor de sí � Transmitir confianza � Mantener al equipo focalizado y motivado � Fomentar la comunicación del conocimiento y logros obtenidos � Demostrar y promover los valores, principios y prácticas de

desarrollo � Fomentar la reflexión crítica acerca del proceso de desarrollo

Tabla 18: Desafíos de un coach

Lo mismo sucede en el caso del ingeniero de software que tenga el rol de Tracker, tal como se muestra en la Tabla 19.

Con respecto a Desafío del Ingeniero de Software El equipo de desarrollo

� Mantener a sus compañeros al tanto de los avances

El proyecto y su proceso de desarrollo

� Obtener la información que permita medir los avances logrados en la construcción del producto

Tabla 19: Desafíos de un tracker

Las metodologías ágiles, y en particular XP proponen una mirada sistémica y basada en los requerimientos de la persona involucrada en un desarrollo de software, que le permiten a esta

68

última entrar en una relación armónica con el entorno del proyecto de desarrollo, tal como veremos en el punto siguiente.

4.2.1 Mecanismos de sincronización/armonización en un proyecto de software organizado según XP

Un estudio detallado de los valores y prácticas propuestas por XP permite descubrir una interesante dinámica interna. Como podremos observar en la Ilustración 19, no sólo es posible organizar las prácticas de XP según su aplicación en alguno de los ámbitos del entorno de un proyecto de software (individuo, equipo, cliente-negocio y tecnología), sino que además podemos modelar estas relaciones como una arquitectura de mecanismos de retroalimentación que permite mantener sincronizados estos ámbitos entre sí durante toda la vida del proyecto. La duración de estos ciclos sigue el principio de tiempo fijo y alcance variable, explicado en el punto 3.2.1, gracias al cual se le imprime al trabajo un ritmo que mantiene una frecuencia de producción y retroalimentación sostenida durante todo el proyecto.

Ilustración 19: Ciclos de sincronización de un proyecto organizado en torno a XP

En primer lugar podemos notar la presencia de un ciclo cuyo objetivo es lograr el mayor valor posible en el proyecto. Es organizado a través del Planning Game, en donde se definen y estiman las “Historias de Usuario” (que se documentan usualmente en tarjetas indexadas), para luego pasar a un ciclo de desarrollo, del que se obtendrán funcionalidades que deben ser validadas con tests de aceptación (también llamados tests de cliente), para luego generar un software funcional con un incremento pequeño de valor agregado (denominado “entregable pequeño”). Todos estos pasos pueden retroalimentar a los anteriores. Por ejemplo, el

Plan Diario

Planning Gam

e (Iteración)

Planning Gam

e (Entregable)

Ciclos de un proyecto XP

Ciclo de Gestión del Proyecto Orientada al ValorCiclo de Gestión del Proy to Orientada al Valor

Ciclo de Gestión del Desarrollo

Ciclo de Programación de calidad

69

desarrollo aportará nuevos conocimientos que pueden ajustar el plan de la iteración, o el entregable pequeño al ser puesto en producción aportará nuevas luces sobre el negocio, lo que también retroalimentará. Al estar involucrado el cliente en todo este ciclo (gracias a la práctica “cliente in situ”), se está generando una sincronización continua entre el problema de negocio y la solución de software, lo que elimina el problema diagnosticado de la industria de software de generación de funcionalidades que no aportan real valor al cliente.30

Ilustración 20: Entorno de desarrollo de software organizado por las prácticas de XP

El Planning Game organiza este ciclo sincronizando las expectativas del cliente y la visión técnica de los desarrolladores. Ambas contrapartes entran a un juego colaborativo regido por reglas similares a las declaradas anteriormente en la página 64. Los clientes deberán expresar en su propio lenguaje sus requerimientos en narraciones denominadas “historias de usuario”. Los desarrolladores por su parte deberán ser capaces de transmitir al cliente una apreciación del costo de desarrollo en horas/hombre de los requerimientos del cliente, la que pueden realizar a partir de su experiencia, o bien, si no la tienen, realizando experimentos concretos donde pueden apreciar las posibilidades de la tecnología. Si los desarrolladores no pueden percibir el alcance de la historia, deberán solicitar al cliente que divida la historia hasta hacerla estimable. El resultado esperado del planning game es que las contrapartes tengan confianza en que lo planificado puede ser realmente realizado. Este flujo es graficado en la Ilustración 21.

30 Tal como se vio en el capítulo 3.1 El problema de la productividad de la industria de software

Ges

tión

del

Des

arro

llo e

n Eq

uipo

Pro

gram

ació

n en

Equ

ipo

Pro

gram

ació

n In

crem

enta

l de

Cal

idad

Integración continua


Propiedad Colectiva de Código


(+ Mantener el equipo rotando)

Espacio de Trabajo Informativo

Diseño Simple

Refactorización

Desarrollo Guiado por

Tests

Ritmo Sostenido ( No a las horas extra)

Retroalimentaciónde Avance(Tracking)

Liderazgo Motivador(Coaching)

Stand Up Meeting

Planning Game de la Iteración

Ges

tión

del

Pro

yect

o

orie

ntad

a al

val

or

Planning Game

Tests de Aceptación del Cliente

Entregas pequeñas

Cliente en terreno

(Un sólo equipo)

Desarrollo

po)

ciónDefinición Validación

g

D

Planning Game de la Iteraciónam

70

Ilustración 21: Flujo del Planning Game.31

Otro mecanismo de sincronización es el que llamaremos ciclo de programación incremental de calidad, en donde los desarrolladores efectivamente implementan las nuevas funcionalidades del producto en incrementos pequeños. Este ciclo parte en un planning game de la iteración, en donde las historias de usuario se descomponen en tareas que son asumidas por los miembros del equipo de manera voluntaria. Estas tareas se van implementando a partir de un diseño simple (es decir, que busca implementar lo que realmente se necesita para la historia de usuario en cuestión, y nada más) que permite definir un conjunto de tests que son programados, para luego implementar el código que permita

31 Versión revisada del original creado por Roger Whitney en la Universidad de San Diego en el año 2000. Ver

http://www.eli.sdsu.edu/courses/summer2000/XPPics/

Fase de Maniobra

Cliente requiere nueva historia

Plan no es adecuado

Fase de Compromiso

Fase de ExploraciónCEscribir Historias

para toda la iteración

NO

DEstimar Historias

DExperimentos Concretos

¿Estimable?

CDividir Historias

DOrdenar por Riesgo

COrdenar por Valor

DDefinir Velocidad

CDecidir Alcance

Iteración

CPlanning Game de la Iteración

DDesarrollo XP

DTestFuncionales

CNueva Historia

DRecuperación

DRe-Estimar

Velocidadsobreestimada

Ejecutar

CValidar ¿OK?

si

no

C = ClienteD = Desarrollador

El flujo delEl flujo del Planning Planning GameGamePlannila

SI

71

pasar dichos tests de manera exitosa. Una vez logrado esto se integra la nueva funcionalidad incrementalmente en el código general del sistema. En cada momento de este ciclo el nuevo código se va integrando al resto refactorizando el código anterior, es decir, incorporando generalizaciones que permitan incorporar de manera natural las nuevas funcionalidades evitando incorporar redundancias en el código, y por ende la posibilidad de que en el futuro existan defectos debido a implementaciones múltiples e incongruentes de funcionalidad.

Fruto de este ciclo se logra una sincronización entre la historia de usuario, su implementación técnica, y el sistema general, dejando un mecanismo que permite chequear a futuro su buen funcionamiento a partir de los tests implementados.

Este ciclo, al ser realizado en equipo, posee otros mecanismos de sincronización orientados específicamente a este ámbito, como la programación de a pares que complementada con la rotación del equipo no sólo permite diseños de mejor calidad gracias a la suma de las destrezas de los desarrolladores, sino que mantiene sincronizado y distribuido el conocimiento de todo el sistema en todo el equipo. Esto es fortalecido por los estándares de código y la propiedad colectiva del código, a partir de la adopción de un estilo común de codificación y eliminando el concepto de “un programador – un módulo” respectivamente.

Finalmente, el equipo en su conjunto se mantiene sincronizado a través del standup meeting (reunión de pie) realizado al comenzar cada sesión de trabajo, en donde se acuerdan las tareas a realizar, y el espacio de trabajo informativo, el cual gracias a la retroalimentación de los propios miembros del equipo y a la sistematización del trabajo del tracker va informando a todos de los logros obtenidos.

En la Tabla 20 se resumen los mecanismos de sincronización antes nombrados:

Ciclo Meta Herramienta de

Sincronización Resultado

Ciclo principal: Gestión del Proyecto orientada al valor

Sincronizar problema de negocio y la solución de software

Planning Game Un plan compartido y confianza de su factibilidad

Tests de aceptación Software funcional entregado de manera incremental y validado por el cliente

Ciclo de Gestión del desarrollo en equipo

Información del avance del proyecto y desafíos en los diversas tareas del plan

Stand Up Meetings Tracking Espacio de Trabajo Informativo

Apreciación por parte del equipo de los logros obtenidos y claridad en los desafíos pendientes

Ciclo de Programación Incremental de Calidad

Funcionalidades validadas técnicamente, integradas armónicamente en el sistema y con mecanismos de

General Suite de Tests

Verificación automática de calidad técnica del software

72

Ciclo Meta Herramienta de Sincronización

Resultado

verificación que permitan validar a futuro su funcionamiento (suite de test)

Equipo Programación de a pares Propiedad colectiva de código Estándares de código

Equilibrio en el uso de las destrezas de los desarrolladores y conocimiento compartido de cómo está implementada técnicamente la solución

Tabla 20: Resumen de mecanismos de sincronización de un proyecto de software XP

Gracias a este modelo que hemos construido para explicar el funcionamiento de XP, ahora tenemos un marco que nos permitirá evaluar cuáles son los aprendizajes que han obtenido los alumnos en relación al modelo de desarrollo ágil, pudiendo afirmarse que a mayor dominio (comprensión y aplicación) de los ciclos presentados, se obtendrá mayor éxito en la labor de desarrollo.

73

4.3 Un modelo de evaluación sobre aprendizaje de XP centrado en el individuo

En este capítulo se presentará el modelo de evaluación diseñado a propósito de esta investigación para poder medir los aprendizajes obtenidos por los alumnos desde la perspectiva de las metodologías ágiles. Antes de entrar en el detalle de éste modelo evaluativo es importante explicar por qué es necesario definir uno nuevo, dado que ya existía un sistema de evaluación que fue aplicado durante los años que este curso ha sido impartido.

4.3.1 Razones para un nuevo modelo evaluativoLas razones que han llevado a tomar la decisión de definir un modelo evaluativo alternativo son las siguientes:

Distintos objetivos de la evaluaciónEl sistema evaluativo del curso está basado en el principio de que los alumnos deben llevar a cabo las prácticas de XP según su criterio, siempre buscando lograr llevar a cabo un software funcional que satisfaga los requerimientos de su cliente de turno en los plazos que se les ha dado, y a partir de entonces poder concluir sobre la utilidad percibida de las prácticas. Es decir, en esta mirada se relativiza la aplicación de XP en favor de la experiencia concreta de desarrollo. Esta mirada se basa en el hecho de que los alumnos vienen con una formación basada en paradigmas distintos (y hasta opuestos) a los de las metodologías ágiles, tal como vimos en el punto 4.1.2.

En cambio, en esta investigación buscamos definir cuál es el real impacto en los aprendizajes de los alumnos, desde la perspectiva de las metodologías ágiles, lo que en la práctica pone en el centro los mecanismos internos del desarrollo ágil considerándolos como un objetivo en sí y realizando una evaluación crítica de cómo el diseño instruccional del curso y su aplicación han permitido a los alumnos percibir dichos mecanismos, lo que se resume en la Ilustración 22.

Ilustración 22: Contraste entre el modelo evaluativo usado en el curso y de la investigación

Este nuevo modelo de evaluación se basa en la conceptualización de cómo XP organiza un ambiente de desarrollo de software, que hemos explicado en el punto 4.2.1.

Integración de nuevos elementos El sistema evaluativo aplicado en el curso estaba basado fuertemente en la intuición, dada la poca experiencia sobre el tema cuando se inició este curso: no más de 3 años desde que XP se hizo público y menos de un año desde la redacción del “Manifiesto Ágil”.

versus

Modelo del Curso Modelo requerido por la investigación

74

Durante esta investigación se ha profundizado en áreas como los fundamentos conceptuales de las metodologías ágiles, las teorías del aprendizaje, la educación de los ingenieros de software y experiencias alternativas en la academia de educación de XP y las metodologías ágiles, por lo cual un nuevo modelo evaluativo puede resultar fortalecido al integrar estos nuevos elementos.

4.3.2 Modelo de evaluación de la experienciaPara poder concluir cuál es el impacto en los aprendizajes de los estudiantes de ingeniería de software que realizan el curso, se ha definido un modelo de evaluación que sirve un marco para el análisis. Por lo general experiencias de aplicación de XP en la academia32

� Evalúan la opinión de los alumnos acerca de cada práctica de XP por separado, o

se encuentran en dos extremos:

� Analizan los resultados de manera global, a partir de opiniones de los clientes, de los compañeros o de la evaluación del producto final.

El modelo evaluativo que se propone en esta tesis recoge elementos de los polos anteriores y los integra en una mirada sistémica (que también podría ser denominada holística), la cual se basa en la relación del aprendiz de ingeniería de software con el entorno de un proyecto de desarrollo, y de qué manera el primero se va haciendo más efectivo en su quehacer aprendiendo de manera integrada los valores, principios y herramientas de XP.

De esta mirada queda excluida cualquier evaluación acerca de las destrezas de diseño y de programación de los alumnos, dado que en el contexto del curso sobre el que trata esta investigación ellos ya han recibido una formación intensiva en dichas áreas en cursos anteriores.

4.3.3 Medios de recopilación de evidencias para evaluar la experiencia Evaluar los aprendizajes y el rendimiento individual de cada alumno en el contexto de un proyecto de software es bastante complejo, debido a lo difícil que es discriminar cuál es el aporte individual de cada uno en el trabajo global. Para esta labor, se ha creado un conjunto de medios de recopilación de evidencias que, en conjunto con el modelo de evaluación de medios y actitudes expuesto en los puntos anteriores, podrá dar luces acerca del impacto del curso en los alumnos.

Es importante hacer notar que la mayoría de estos medios sólo son efectivos cuando el proyecto ya está en marcha, dado que, por ejemplo, sería muy difícil evaluar cuales son las “actitudes” de un alumno cuando recién está comenzando el curso, o cuando aún ni el cliente ni los compañeros tienen un dominio claro del marco conceptual de XP ni del trabajo en equipo como para emitir opiniones bien fundadas. Es por esto que estos medios serán aplicados a la mitad y al final del curso, para poder además determinar cuál fue la evolución experimentada por los alumnos durante la experiencia.

Trabajos individuales sobre el marco conceptual de la metodología y la evaluación de la experiencia

Una buena forma de determinar el grado de comprensión (al menos teórica) del complejo marco conceptual de XP es que los alumnos realicen un ensayo en donde expliquen en sus propias palabras “qué es XP”. Esto permitirá tener una evidencia del grado de comprensión de

32 Ver capítulo 3.4.5 “Caracterización de las aplicaciones de XP en la formación académica de los ingenieros de software”

75

la metodología y la profundidad lograda por el alumno, viendo si es capaz de realizar relaciones entre los diversos elementos que la componen.

Otro ejercicio de gran valor es solicitar a los alumnos que evalúen la experiencia de aplicación de XP, indicando qué prácticas fueron aplicadas y cómo funcionaron. Se debe hacer notar que el grado de comprensión logrado sobre las prácticas determinará necesariamente la capacidad de los alumnos no sólo de reconocer la aplicación de una práctica, sino que poder evaluar su uso.

La opinión del cliente sobre el proceso y el producto

El cliente representa en el mundo real el evaluador más importante de los resultados de un proyecto de software. Aquí se centrará la evaluación en las actitudes de los alumnos que observa el cliente, y el valor percibido por el cliente a partir del trabajo de los alumnos. Los ítems considerados en la evaluación se describen en la Tabla 21.

Actitud Descripción Actitud de diálogo con el cliente y receptividad de críticas

Fueron capaces de sostener una actitud de diálogo, admitiendo sus equivocaciones y recibir críticas

Afiatamiento percibido del equipo

Se percibió un equipo de desarrollo coordinado y afiatado entre sí

Comunicación dentro del equipo

La comunicación entre los desarrolladores y el cliente fue fluida, periódica y abierta

Dedicación a generar valor Cumplieron con las tareas asumidas de manera adecuada, transparentando su labor y buscando generar el mayor valor posible por cada día de trabajo

Proactividad para el éxito del proyecto

Demuestran iniciativa para lograr el éxito del proyecto

Visibilidad entregada del avance

El proyecto fue visible, pudiendo saber el cliente en todo momento qué se había desarrollado y cuanto quedaba por realizarse

Puntualidad y Asistencia Cumplieron con los horarios puntualmente y mantuvieron la asistencia acordada

Tabla 21: ítems de evaluación del cliente

El cliente utilizará los evaluadores indicados en la:

Evaluación Valor numérico Siempre 100%,

Regularmente 65%

A Veces 60%

Con Dificultad 25%

Nunca 0%.

Tabla 22: Rango de evaluación ocupada por el cliente

Las evaluaciones se complementarán además con comentarios escritos.

76

La herramienta de aprendizaje: el proyecto de Software, y el producto obtenido

El aprendizaje de los alumnos estará necesariamente contextualizado en el proyecto de software que deben emprender durante el curso debido a las características peculiares del problema a resolver. Dado que todos los alumnos han sido expuestos a la misma experiencia instruccional, al contrastar los resultados en su conjunto de cada proyecto realizado podrá determinarse cómo el proyecto enfrentado afectó los aprendizajes de los alumnos.

Recopilación de aprendizajes previos

Es el único medio de recopilación de evidencias que puede ser aplicado al comienzo del curso, y consiste en solicitar a los alumnos que indiquen al resto del curso cuáles son sus conocimientos previos con respecto a XP y qué es lo que desean aprender en el curso.

Co-evaluación al interior del equipo de trabajo

En cada ciclo los alumnos evaluaron a sus compañeros en los ítems descritos en la Tabla 23:

Actitud Descripción Actitud de diálogo: con el cliente

Ha mantenido un buen diálogo con el cliente aportando con el desarrollo del proyecto

Actitud de diálogo: con el equipo

Muestra una actitud de diálogo que facilita el trabajo en equipo

Actitud positiva frente a las críticas

Es capaz de admitir sus equivocaciones y recibir críticas

Autoperfeccionamiento Demuestra interés por investigar y perfeccionarse en el cumplimiento de sus tareas asumidas y de su rol dentro del proyecto

Dedicación a generar valor Cumple con las tareas asumidas de manera adecuada, transparentando su labor y buscando generar el mayor valor posible por cada día de trabajo

Disposición a apoyar a los otros en sus labores

Asume el proyecto como un trabajo en equipo, ofreciendo apoyo en las tareas derivadas del proyecto

Disposición a recibir apoyo del resto del equipo

Es capaz de pedir ayuda cuando ha tenido problemas

Proactividad para el éxito del proyecto

Demuestra iniciativa para lograr el éxito del proyecto

Tabla 23: Ítems de co-evaluación

Los alumnos además utilizarán los siguientes evaluadores:

Evaluación Valor numérico Siempre 100%,

Regularmente 65%

A Veces 60%

Con Dificultad 25%

Nunca 0%.

Tabla 24: Rango de evaluación utilizado en las co-evaluaciones

La evaluación de un alumno es el promedio de las evaluaciones del resto de sus compañeros.

77

Gracias a esta herramienta, es posible identificar problemas de actitud y/o de relaciones al interior del equipo, y así poder actuar en consecuencia.

Bitácora del curso

La bitácora del curso consiste en un breve registro que contiene los desafíos y logros de los alumnos en el transcurso de la experiencia. Este registro incluye notas, fotos y videos.

4.3.4 Variables a medir en la experienciaA partir de la versión revisada de la Taxonomía de Objetivos Educacionales de Bloom [2][9]esquematizada en la Ilustración 23, se definieron las siguientes variables de medición de aprendizajes en la fase práctica del curso, que se presentan en la Tabla 25.

Crear

Evaluar

Analizar

Aplicar

Comprender –Describir, Explicar

Conocer - Recordar

Concebir un método, una idea, un producto original

Estimar aplicando criterios

Identificar los componentes de un todo

Transferir conocimientos y estrategias a una situación familiar

Procesar la información

Recuperar la información

Ilustración 23: Versión adaptada de la Taxonomía de Bloom por la American Psichology Association33

33 basado en la publicación de Anderson, L.W. & Krathwohl, D.R. (Eds.) (2001)

78

Variable Qué mide Valores Posibles

1. Rememoración de las prácticas de XP

Si una práctica es recordada pro los alumnos en los ensayos construidos durante el curso

Ícono Mencionada

En blanco

No Mencionada

2. Comprensión de las prácticas de XP

Si las prácticas mencionadas son bien definidas y/o explicadas por los alumnos en sus ensayos

Bien entendido

No hay claridad

Con errores de comprensión

No menciona 3. (Evaluación de

) Aplicación de las prácticas de XP

Cuál es la apreciación de los alumnos acerca de la aplicación de las prácticas de XP durante el proyecto, complementada con la observación del profesor durante el curso.

Bien aplicado

Aplicado con dificultades

Mal aplicado

No aplicado / No responde


Tabla 25: Variables que miden el aprendizaje logrado por los alumnos en el curso

Como es posible observar, si un alumno no logra un nivel de aprendizaje, no podrá lograr el siguiente nivel. Por ejemplo: si un alumno no comprende una práctica, no tiene sentido considerar su opinión acerca de si fue o no bien aplicada.

La medición ha sido estructurada adicionalmente en torno a los siguientes criterios:

� se ha privilegiado un análisis centrado en las prácticas de XP por sobre resto del marco conceptual (valores y principios), debido a la dificultad de evaluar los últimos

� el análisis será segmentará según los ciclos de sincronización de XP definidos en el punto 4.2.1, para poder tener una apreciación del funcionamiento de cada ciclo

� los proyectos de trabajo, para poder detectar si hay diferencias entre las experiencias de los alumnos

� las dos etapas en que se dividió el desarrollo del curso, para determinar si existen mejoras en la comprensión y/o aplicación entre la primera y segunda etapa

79

5. EXPERIENCIA REALIZADA: SEMESTRE PRIMAVERA 2005DEL CURSO CC62V

A continuación se describirán las características de la experiencia realizada y los resultados obtenidos de aplicar el modelo evaluativo explicado en el punto 0. Adicionalmente, en los anexos, en el punto 10.1 se presenta una descripción detallada de esta experiencia.

5.1 Descripción de la ExperienciaA continuación se caracterizará la experiencia realizada al alero de esta investigación.

5.1.1 Innovaciones aplicadas al diseño instruccionalTal como todos los años, se incorporaron elementos al diseño instruccional del curso para potenciar sus logros, los que son presentados a continuación.

Incorporación de Actividades de Reflexión en cada clase (metacognitivas)Como una manera de reforzar los aprendizajes y de obtener información para esta investigación, al finalizar cada sesión del taller, se motivó la reflexión acerca de lo vivido, buscando desarrollar la capacidad de análisis y de ir evaluando y reconstruyendo el cómo lograron los aprendizajes a medida que realizaban sus labores.

División del proyecto en 3 iteraciones Como una manera de forzar la gestión iterativa del proyecto, se definieron a priori 3 iteraciones de 4 semanas cada una.

5.1.2 Calendario de ActividadesEl curso se programó desde la última semana del mes de julio del 2005 hasta la segunda semana del mes de noviembre del mismo año, considerando una primara clase expositiva, dos clases expositivas a cargo de los alumnos y 12 sesiones de desarrollo. Cada sesión consistió de 3,5 horas y se realizó los viernes desde las 14:30 a las 18:00 horas.

Un esquema del calendario inicial del curso se presenta en la Ilustración 24.

80

Mes

# Plan

Viernes Simbología

0 29 Introducción al curso

Ago

sto

1 5 Presentaciones Iniciales

2 12 Primer Ciclo

3 19 Segundo Ciclo

4 26 Tercer Ciclo

5 2 Feriados Se

pti

emb

re

6 9

16 7 23

8 30

Oct

ub

re

9 7

14

10

21

11

28

12

4

Nov

iem

bre

13

11

14

18

Ilustración 24: Planificación inicial del curso

5.1.3 Tamaño del curso El curso fue tomado por 11 alumnos, uno de los cuales lo abandonó por problemas de tiempo con su trabajo al mes de comenzado el curso.

5.1.4 Proyectos desarrollados Se seleccionaron dos proyectos para ser implementados por los alumnos durante el curso, ambos representados por un profesor y un estudiante de doctorado respectivamente. A continuación se describe el objetivo de cada uno.

Proyecto Mobile WebServer “Mapache”Este proyecto nace a partir de la existencia de un servidor web de código abierto34

34 Ver

que podía ser ejecutado en un dispositivo móvil, y cuyo estado de desarrollo no permitía albergar servicios web en él, debido a varios defectos de implementación. La meta de este proyecto sería entonces, a partir del código del servidor web original, desarrollar la capacidad de albergar servicios web sobre un dispositivo móvil. A este software se le llamó “MicroServer” o “Mapache” (por la relación entre ser una aplicación para dispositivos móviles y ser un servidor web de código abierto como lo es Apache).

La plataforma de desarrollo fue .NET Compact Framework 2.0, y el ambiente de desarrollo fue Visual Studio 2005 (Beta).

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/NETCFMA.asp

81

Proyecto Sincronización XML Peer2Peer “XMLSync”El objetivo de este proyecto era desarrollar un mecanismo de sincronización de archivos XML descentralizado, en modalidad “peer 2 peer”, para ser usado en dispositivos móviles. La plataforma de desarrollo fue .NET Compact Framework 2.0, y el ambiente de desarrollo fue Visual Studio 2005, que en esos momentos estaba en su versión beta final.

82

5.2 Análisis de Resultados de la experienciaEn este capítulo se analizarán los resultados obtenidos de la experiencia realizada. Para una descripción en profundidad de dicha experiencia, consultar el anexo 10.1.

5.2.1 Conocimientos previosEn su mayoría los alumnos desconocían el marco conceptual de las metodologías ágiles, a excepción de un alumno que había hecho su práctica profesional en una empresa que comenzaba a adoptar XP. El concepto más reconocido por lo alumnos era la “Programación de a Pares” la cual era entendida como sinónimo de XP.

5.2.2 Aprendizajes logrados durante el curso A partir del los ensayos realizados por los alumnos análisis de los ensayos de los alumnos, se obtienen el mapa de comprensión de prácticas de XP logradas a mitad y a final del curso, organizadas según el marco conceptual definido en el capítulo 4.2, reflejado en la Ilustración 25

Ilustración 25: Mapa global de comprensión de prácticas

A continuación se presenta un análisis de los aprendizajes observados.

Se observa un avance de los aprendizajes durante el transcurso del tallerComo tendencia generalizada se puede observar que para cada ciclo de sincronización de XP y cada proyecto, existe una mejora sustantiva entre la primera y segunda etapa del curso en las tres variables medidas: rememoración, comprensión y aplicación de las prácticas de XP.

La principal excepción la observamos en el caso de la práctica “diseño simple” en el proyecto XMLSync, en donde la apreciación inicial de correcta comprensión cambió cuando los alumnos

Grupo Alu

mno

Clie

nte

In S

itu

Plan

ning

Gam

e

Test

s de

Ace

ptac

ión

Entr

egab

les

Pequ

eños

Ritm

o So

sten

ido

Lide

razg

o M

otiv

ador

Retr

oalim

enta

ción

de

avan

ce

Espa

cio

de T

raba

jo In

form

ativ

o

Stan

d U

p M

eetin

g

Está

ndar

es d

e Có

digo

Prog

ram

ació

n de

a P

ares

Prop

ieda

d Co

lect

iva

de C

ódig

o

Des

arro

llo G

uiad

o po

r Te

sts

Dis

eño

Sim

ple

Inte

grac

ión

Cont

inua

Refa

ctor

izac

ión

Clie

nte

In S

itu

Plan

ning

Gam

e

Test

s de

Ace

ptac

ión

Entr

egab

les

Pequ

eños

Ritm

o So

sten

ido

Lide

razg

o M

otiv

ador

Retr

oalim

enta

ción

de

avan

ce

Espa

cio

de T

raba

jo In

form

ativ

o

Stan

d U

p M

eetin

g

Está

ndar

es d

e Có

digo

Prog

ram

ació

n de

a P

ares

Prop

ieda

d Co

lect

iva

de C

ódig

o

Des

arro

llo G

uiad

o po

r Te

sts

Dis

eño

Sim

ple

Inte

grac

ión

Cont

inua

Refa

ctor

izac

ión

Mapache FBFSCTAV

XMLSync BBTHCHCMCSMV

Programación en Equipo

Programación de Calidad

Ciclo 1 Ciclo 2Gestión de Proyecto

Orientada al Valor

Gestión del Desarrollo en

Equipo



Gestión de Proyecto

Orientada al Valor


Equipo

Bien entendido

No hay claridad


No menciona

Simbología Comprensión

83

pasaron del trabajo principalmente teórico del ciclo 1 al trabajo práctico del ciclo 2, en donde, a pesar de aplicar esta práctica, no la reconocieron.

Se observa una relación entre el proyecto en que se trabajó y los aprendizajes reflejadosEs posible observar una notoria diferencia entre los aprendizajes logrados por los alumnos de los dos proyectos realizados. Se puede observar que no sólo influye el problema en que se trabajó, sino la calidad de la relación establecida con el cliente y aquella lograda al interior del equipo de trabajo.

Con respecto a lo vivido en este curso, el proyecto más complicado fue XMLSync, en donde costó mucho establecer una relación de colaboración entre el cliente y los alumnos, y entre estos últimos. Esta situación tuvo como efecto secundario que el profesor tuviese que volcar gran parte de sus esfuerzos en apoyar a este equipo, por lo cual, el otro (Mapache) quedó desatendido, justo cuando sus integrantes empezaron a relajar la responsabilidad y por ende el ritmo de trabajo (asistencia a clases, cumplimiento de tareas, etc.) por lo que terminaron generando menos valor que el esperado dados los logros que habían obtenido al comienzo.

“Programación de a pares” como práctica destacadaLa programación de a pares destaca como una práctica entendida por todos y con una aplicación evaluada mayoritariamente como positiva, actuando como gran catalizadora del trabajo en equipo y de generación de código simple, conocido por todos y con pocos defectos, propiedades ya reconocidas por investigaciones anteriores.

Hay Pre-conceptos que afectan el aprendizaje de algunas prácticasLos alumnos al llegar al curso poseían una formación en metodologías tradicionales, que impactó, en algunos casos negativamente, su aprendizaje. Veamos cuáles son los pre-conceptos que más desafíos generan:

“Jefe de proyecto” versus “Liderazgo motivador”

En ambos proyectos hubo problemas de comprensión y aplicación de los alumnos que asumieron el rol de coach, en donde la influencia del clásico rol de “jefe de proyecto” es notoria, en especial en lo que se refiere a un liderazgo solitario, asignador de tareas y que asume de manera aislada la relación con el cliente y el problema de negocio.

Claramente existió una carencia en la explicación del estilo de liderazgo buscado y en la forma de seleccionar a los coaches, basada principalmente en “experiencia en proyectos” o en “disposición a asumir el cargo”, y no en la capacidad de asumir el rol de coach.

“Gran diseño” versus “Diseño incremental”

Es notoria la influencia del concepto de diseño tradicional, como un gran hito donde se define a priori todo lo que se va desarrollar.

Muchas veces el diseño y la refactorización son entendidas como actividades en las que debe abarcarse todo el sistema de una sola vez. Este problema fue particularmente notorio en el proyecto en que se tenía que trabajar con código legado, donde aplicar estas prácticas se entendía como tener que hacerlo todo de nuevo. Por su parte el término “simple”, cuyo significado apunta a realizar realmente lo que se necesita y nada más, se confunde con realizar lo más fácil, aunque sea desorganizado – todo esto mirado desde el paradigma de “gran

84

diseño” en donde se cree tener una comprensión cabal y ordenada de todo lo que será el sistema a desarrollar -, asignando a la refactorización el rol de ser la herramienta para ordenar el caos obtenido. Contrasta esta perspectiva con la que subyace a las metodologías ágiles, donde el diseño que se realiza está sujeto a la restricción de lo que realmente se sabe que se necesita, siendo la refactorización la herramienta que permite ir integrando las nuevas características que vayan necesitándose a medida que se adquiere un conocimiento suficiente sobre ellas.

“Desarrollo Guiado por Tests” versus “Desarrollo Tradicional”

Este es otro ejemplo del efecto que las personas ante presión vuelven a las antiguas prácticas. Algunos alumnos justificaron el abandono del desarrollo guiado por tests por el poco tiempo disponible, lo que les “obligó a privilegiar el desarrollo de nuevas funcionalidades”. Esto es una expresión del concepto arraigado de que “si un código se ejecuta, ya está listo”, aunque no se haya realizado ninguna prueba seria de su funcionamiento, ni se haya dejado ninguna evidencia de su correctitud, lo que finalmente podría traer grandes problemas de robustez y mantenibilidad.

Hay prácticas de XP cuyos nombres llevan a malos entendidosAlgunas de las prácticas de XP aplicadas poseen nombres que llevaron a malos entendidos a quienes participaron en el proyecto.

“Estándares” de código

La palabra “estándares” está asociada con el concepto de un conjunto de definiciones y reglas que se definen luego de largo proceso de análisis y diseño consensuado. Sin embargo lo que quiere expresar esta práctica en el contexto de XP es que los desarrolladores usen convenciones comunes al escribir el código, de tal forma que se facilite el entendimiento compartido de éste. Lo anterior puede lograrse perfectamente sin mucha burocracia, por ejemplo adoptando lineamientos ya definidos – como el estilo pre-existente de un código legado – o a través de ir acordando criterios de manera paulatina.

“40 horas” a la semana

Esta práctica ya tenía como nombre alternativo “no a las horas extra”, y se ha llamado también en el último tiempo como “ritmo (de productividad) sostenido”, que refleja su verdadero objetivo, para lo cual el negarse a las horas extras ayuda. La cantidad de horas es tomada literalmente por los alumnos, por lo cual no percibieron que el restringir el desarrollo sólo a las horas de taller (3 por semana) es una expresión de esta práctica.

Cliente “in situ”

Si se interpreta literalmente el nombre de esta práctica (como ocurrió en el proyecto XMLSync), se puede dar el caso de que a pesar de ubicar a clientes y desarrolladores en un espacio compartido, esto no lleve necesariamente a un real trabajo colaborativo.

La idea detrás de colocar al cliente en el mismo espacio del equipo de desarrollo apunta a que se establezca un esfuerzo mancomunado entre ambas partes para superar todos los problemas e incertidumbres que aparecen en todo proyecto de software, idea que ha sido mejor expresada al rebautizar esta práctica como “un sólo equipo (entre clientes y desarrolladores)” y posteriormente “real involucramiento del cliente”.

85

“Propiedad colectiva” de código

En esta práctica hay dos malentendidos. Por “propiedad colectiva” algunos alumnos entendieron que todos los desarrolladores tenían que conocer siempre todo el código, lo que sería ideal pero en la práctica es casi imposible. Lo que realmente se necesita es que todos tengan el derecho a intervenir cualquier parte del software sin herir ninguna susceptibilidad. Para esto, es importante construir o poner en funcionamiento herramientas que les permitan a todos el acceso a entender el código común, como documentación adecuada, convenciones de código, etc.

5.2.3 Calidad en la reproducción del ambiente XP durante el cursoA continuación se presenta un análisis acerca de la calidad que alcanzó la experiencia de desarrollo desde la perspectiva de XP

Grado y logro en la aplicación de las prácticasEn la Ilustración 26 se observa la evaluación que realizan los alumnos de la aplicación de las diversas prácticas de XP35

. Como es posible observar, en el ciclo 2 se llega a lograr una aplicación mayoritaria de las prácticas XP en ambos proyectos, aunque el proyecto XMLSync tuvo mayores dificultades en la calidad de la aplicación.

Ilustración 26: Mapa global de evaluación de aplicación de prácticas

35 Nótese que se marcan en gris aquellos alumnos cuya opinión no es válida dado que no comprenden el concepto que están

evaluando.

Grupo Alu

mno

Clie

nte

In S

itu

Plan

ning

Gam

e

Test

s de

Ace

ptac

ión

Entr

egab

les

Pequ

eños

Ritm

o So

sten

ido

Lide

razg

o M

otiv

ador

Retr

oalim

enta

ción

de

avan

ce

Espa

cio

de T

raba

jo In

form

ativ

o

Stan

d U

p M

eetin

g

Está

ndar

es d

e Có

digo

Prog

ram

ació

n de

a P

ares

Prop

ieda

d Co

lect

iva

de C

ódig

o

Des

arro

llo G

uiad

o po

r Te

sts

Dis

eño

Sim

ple

Inte

grac

ión

Cont

inua

Refa

ctor

izac

ión

Clie

nte

In S

itu

Plan

ning

Gam

e

Test

s de

Ace

ptac

ión

Entr

egab

les

Pequ

eños

Ritm

o So

sten

ido

Lide

razg

o M

otiv

ador

Retr

oalim

enta

ción

de

avan

ce

Espa

cio

de T

raba

jo In

form

ativ

o

Stan

d U

p M

eetin

g

Está

ndar

es d

e Có

digo

Prog

ram

ació

n de

a P

ares

Prop

ieda

d Co

lect

iva

de C

ódig

o

Des

arro

llo G

uiad

o po

r Te

sts

Dis

eño

Sim

ple

Inte

grac

ión

Cont

inua

Refa

ctor

izac

ión

Mapache FBFSCTAV

XMLSync BBTHCHCMCSMV



Ciclo 1 Ciclo 2Gestión de Proyecto

Orientada al Valor


Equipo



Gestión de Proyecto

Orientada al Valor


Equipo

Bien aplicado

Aplicado con dificultades

Mal aplicado

No aplicado / No responde


Simbología Aplicación

86

Funcionamiento de la gestión ágilCon respecto al aspecto de la aplicación de gestión ágil en los proyectos realizados, en la Ilustración 27 se presenta una comparación entre el plan inicialmente diseñado y el calendario que resultó para cada uno de los proyectos realizados. Como es posible observar, ambos proyectos tuvieron su propia dinámica en lo que se refiere a sus ciclos de trabajo, logrando el proyecto “Mapache” la entrega de tres entregables incrementales, lo que en la caso del proyecto “XMLSync” sólo sucedió en dos casos.

Mes

# Plan Inicial

Mapache XMLSync

Viernes Viernes Viernes Simbología

0

29 29 29 Introducción al curso

Ago

sto

1

5 5 5 Presentaciones Iniciales

2

12 12 12 Primer Ciclo

3

19 19 19 Segundo Ciclo

4

26 26 26 Tercer Ciclo

5

2 2 2 Feriados

Sep

tiem

bre

6

9 9 9

16 16 16

7

23 23 23

8

30 30 30

Oct

ub

re

9

7 7 7

14 14 14

10

21 21 21

11

28 28 28

12

4 4 4

Nov

iem

bre

13

11 11 11

14

18 18 18

Ilustración 27: Comparación entre plan inicial y lo sucedido en los proyectos realizados

La razón subyace en la discrepancia entre la planificación inicial y lo realmente sucedió, es la primera fue fijada sin involucrar a desarrolladores y clientes en esa decisión. Esto llevó a que finalmente esa duración perdiese sentido, dado que la dinámica de cada proyecto “empujó” la fecha de término hasta una duración adecuada para obtener realmente un entregable. Entre los efectos perniciosos de esta definición también está que los equipos no percibieron el planning game como una instancia para lograr una confianza compartida con el cliente de poder lograr un resultado en los tiempos estimados y recursos disponibles.

Existen además una serie de aspectos que aparecen como mejorables para aportar a los alumnos un ambiente de trabajo ágil de mejor calidad.

Elección de coach sin información suficiente

Como ya fue indicado anteriormente, el rol de “jefe de proyecto” está demasiado arraigado, por lo cual es demostró como importante conocer a alumnos antes de seleccionar aquellos que tengan el perfil de liderazgo motivador requerido por los coachs de XP.

87

Alumnos se enfrentaron a planificar y estimar sin base de conocimientos suficiente

Este es otro aspecto que afectó al planning game como práctica. Los alumnos llegaron a la planificación con poco o nulo conocimiento de las herramientas y dominio de los problemas a resolver, por lo cual no tenían un sustrato de experiencia previa que pudiesen usar para estimar el costo de las tareas a realizar. Esto se subsanó a la tercera sesión de trabajo en el proyecto Mapache, pero en el proyecto XMLSync sólo se alcanzó en las sesiones finales del proyecto, dando a los alumnos de este grupo una débil experiencia del modelo de gestión ágil.

Tiempo excesivo en disponer de una base de código funcional sobre la cual implementar

En caso del proyecto Mapache se poseía de entrada un código original sobre el cual construir, pero en el otro proyecto no se logró una base compartida de código hasta fines del primer ciclo, generándose hasta ese entonces un conjunto de pedazos de código que no poseían ni una historia compartida ni un lugar estándar donde ser accedido ni actualizado, lo que agregó una variable adicional de incertidumbre al proyecto.

Ritmo sostenido con las (pocas) horas disponibles en el taller

El escaso tiempo disponible para el desarrollo compartido durante el taller hace que problemas tales como instalar ambientes de trabajo u otros inconvenientes afecten el lograr un ritmo de trabajo realmente sostenido. Algún alumno planteó que si se dividiesen las 3 horas de trabajo en 2 días durante la semana daría más continuidad al trabajo, pero justamente ese modelo fue el adoptado al comienzo del curso y fue desechado porque el tiempo efectivo de trabajo era aún menor que en el caso actual dado que era necesario para cada sesión el lograr ritmo de trabajo, pero con menos tiempo para capitalizarlo. Además, algunos alumnos no tienen el hábito de la puntualidad, lo que en el modelo de bloques de taller separados en la semana impacta aún más la productividad.

De todos los problemas mencionados, este es el único al parecer insalvable dado el escaso tiempo que se dispone por horario para el trabajo en conjunto.

5.2.4 Percepciones de los clientesLa opinión de los clientes fue evolucionando de forma distinta para cada uno de los proyectos desarrollados, por lo cual acá se presenta cada una por separado

Opinión del cliente del proyecto MapacheEn el ciclo 1 podemos observar una ligera diferencia en la percepción del cliente entre el coach (FB) y el resto del grupo, principalmente en la actitud proactiva para generar el éxito del proyecto. La evaluación del cliente con respecto al producto de este primer ciclo fue satisfactoria. En el ciclo 2, se refleja una baja leve en la evaluación de las actitudes de los alumnos, en particular en el afiatamiento al interior del grupo, y una en las actitudes de proactividad y comunicación del coach (FB). Es interesante destacar que a pesar de que hubo varias inasistencias durante este ciclo, el cliente evalúa el ítem igual al ciclo anterior.

Con respecto a la evaluación del producto, el cliente no quedó muy conforme con lo recibido, dado que la implementación de tipos complejos en los servicios web lograda fue demasiado restringida a aquellos tipos implementados en el ciclo, siendo que él hubiese esperado una implementación más genérica.

La evaluación realizada sobre las actitudes de los alumnos está reflejada en la Ilustración 28

88

Ilustración 28: Opinión del cliente del proyecto Mapache sobre los alumnos

Opinión del cliente del proyecto XMLSyncEn el ciclo 1 la evaluación del cliente de este proyecto es muy negativa en varios aspectos, tales como la dedicación a generar valor, en el afiatamiento del equipo y en la proactividad para el éxito del proyecto en donde sólo obtiene evaluación positiva el coach de este ciclo (CH), indicando la relación preferencial establecida con éste último, en detrimento del resto del equipo.

En el ciclo 2, el cliente evalúa mejor la “dedicación a generar valor” y el “afiatamiento del equipo”, aunque baja la “actitud de diálogo con él y receptividad a críticas”, y la “puntualidad y asistencia”. Llama la atención la baja evaluación que realiza el cliente del nuevo coach (BB) en lo que se refiere a “comunicación dentro del equipo”. Como el cliente no entregó ningún comentario adicional, sólo se puede suponer que él no entendió el cambio de liderazgo sucedido en el grupo, el cual sí tuvo efectos positivos evidentes.

Con respecto a la evaluación del producto, el cliente obtuvo, luego de muchos intentos fallidos, un módulo de código que cumplía las funcionalidades más básicas que esperaba al comenzar el proyecto, por lo cual, quedó con la idea de que se pudo haber logrado más.

No obstante, él también reconoció que no había ponderado las exigencias que implicaba el ser cliente en un proyecto de XP, y que le costó asumir ese rol.

El resumen de las opiniones del cliente de este proyecto a lo largo del mismo se puede apreciar en la Ilustración 29.

Evaluación Cliente Alumno Eje Concepto Ciclo FB FS CT AV

Proyecto Dedicación a generar valor 1 75% 75% 75% 75%2 75% 75% 75% 75%

Proactividad para el éxito del proyecto 1 100% 50% 50% 75%2 75% 50% 75% 75%

Cliente Actitud de diálogo con el cliente y receptividad de críticas 1 100% 100% 100% 100%2 100% 100% 100% 100%

Puntualidad y Asistencia 1 75% 75% 75% 75%2 75% 75% 75% 75%

Visibilidad entregada del avance 1 75% 75% 75% 75%2 75% 75% 75% 75%

Equipo Afiatamiento percibido del equipo 1 75% 50% 50% 75%2 50% 50% 50% 50%

Comunicación dentro del equipo 1 100% 75% 75% 75%2 75% 75% 75% 75%

Evaluador CalificadorSiempre 100%Regularmente 75%A Veces 60%Con Dificultad 25%Nunca 0%

89

Ilustración 29: Opinión del cliente del proyecto XMLSync sobre los alumnos

5.2.5 Encuesta de impacto post cursoUnos 6 meses después de finalizado el curso se comenzó a realizar realizó una encuesta a los alumnos, con el objetivo de recopilar su opinión con respecto a la experiencia vivida, aprendizajes logrados y aplicación de lo aprendido en su práctica diaria.

A continuación presentamos un resumen de la encuesta, el cual está centrado en las prácticas de XP (en detrimento de los valores y principios), siguiendo de esta manera un criterio similar al utilizado al analizar los trabajos de los alumnos realizados durante el curso.

Como observación, se indica que en los casos en que exista una diferencia sustantiva de resultados entre los alumnos de los dos proyectos realizados, el análisis agrupará los resultados por proyecto.

Evaluación Cliente Alumno Eje Concepto Ciclo BB TH CH CM CS MV

Proyecto Dedicación a generar valor 1 25% 25% 25% 25% 25% 25%2 50% 50% 75% 50% 50% 50%

Proactividad para el éxito del proyecto 1 25% 25% 75% 25% 25% 25%2 25% 50% 50% 25% 25% 25%

Cliente Actitud de diálogo con el cliente y receptividad de críticas 1 100% 100% 100% 100% 100% 100%2 50% 50% 50% 50% 50% 50%

Puntualidad y Asistencia 1 100% 100% 100% 100% 100% 100%2 75% 75% 75% 75% 75% 75%

Visibilidad entregada del avance 1 75% 75% 75% 75% 75% 75%2 75% 75% 75% 75% 75% 75%

Equipo Afiatamiento percibido del equipo 1 25% 25% 25% 25% 25% 25%2 50% 50% 50% 50% 50% 50%

Comunicación dentro del equipo 1 50% 50% 75% 75% 50% 50%2 25% 50% 75% 75% 50% 50%

Evaluador CalificadorSiempre 100%Regularmente 75%A Veces 60%Con Dificultad 25%Nunca 0%

90

Calificación de la experiencia

1. ¿Cómo calificaría la experiencia vivida en este curso?

muy mala mala regular buena excelente

Los alumnos califican positivamente la experiencia vivida. La mayoría de los alumnos califica la experiencia de “buena” (7) y el resto de excelente (3)

Ilustración 30: Gráfico de evaluación a posteriori de los alumnos

Comparación de este curso con el resto de la carrera

2. ¿Cómo compararía la experiencia de este curso con el resto de los ramos de la carrera? ¿Qué elementos destacaría?

Ilustración 31: Aspectos destacados del curso según nº de menciones recibidas

0 1 2 3 4 5 6 7 8 9 10

Otros

Destrezas

Ambiente humano

Relación entre teoría y práctica

Nº menciones

Asp

ecto

s

Aspectos distintivos del curso

Total

91

Los temas que los alumnos destacan como distintivos pueden agruparse en 4 temas:

Relación entre Teoría y Práctica

La mayor cantidad de menciones la obtiene el aspecto práctico del curso. Se destaca el ambiente auténtico vivido, que permite un mejor aprendizaje de lo que es un desarrollo en la vida profesional. Se destaca también el equilibro entre teoría y práctica, contrastando con la mayoría de cursos con enfoque teórico existentes en la carrera, y entregando un ambiente más controlado de aprendizaje que el curso “Proyecto de Software”, en donde los alumnos desarrollan un proyecto trabajando en una empresa real, sin apoyo docente in situ.

Ambiente humano

Tres alumnos destacan el ambiente humano logrado en el curso entre alumnos y clientes, como muestra de la relación que propugnan las metodologías ágiles.

Destrezas

Dos alumnos destacan el aprendizaje de buenas prácticas y habilidades

Otros

Un alumno destaca el contenido del curso - las metodologías ágiles -, dado el enfoque innovador al desarrollo presentado.

La única mención negativa apunta a un cierto desorden percibido en las actividades del curso.

Lecciones aprendidas

3. ¿Cuáles son las lecciones principales que aprendió en el curso?

3.1 Relación con clientes 3.2 Trabajo en equipo 3.3 Programación

Relación con clientes

Siete alumnos declaran haber aprendido lecciones en este tópico. El concepto es que la relación con el cliente definida por XP, es decir, cercana y flexible, ayuda mucho para la rapidez y éxito de los proyectos. Se plantea también la importancia de ser capaces de llevar a los clientes a este modelo de relación.

Sólo un alumno del grupo XMLSync declara no haber obtenido lecciones debido a la lejanía con el cliente, y dos no indican nada.

Trabajo en equipo

Esta es la pregunta donde más riqueza de aprendizajes demuestran los alumnos. Ellos plantean la importancia de:

� conocer al equipo, � mantenerse sincronizados en lo que se está haciendo, y entrenar al equipo para

aprovechar las herramientas que facilitan este objetivo, � mantener un nivel parejo de interés por el proyecto entre los integrantes, � aprender a ceder por el beneficio del grupo, � que todos “remen en la misma dirección”, � tener estándares de trabajo que todos respeten, � compartir el conocimiento, � conformar un solo equipo entre desarrolladores y clientes.

92

Dos alumnos no entendieron la pregunta, evaluando la experiencia del curso en vez de señalar aprendizajes.

Programación

En este tópico destaca por sobre el resto el aprendizaje de la programación de a pares, que es evaluada como una efectiva forma de trabajar mejor, más motivados, compartiendo el conocimiento y más rápido. Se menciona también la refactorización, los estándares y el desarrollo guiado por tests.

Adicionalmente, un alumno indica que aplicaría un subconjunto de las prácticas, en particular el entorno de trabajo, las reuniones y las metas pequeñas y claras. Otro alumno plantea que, a pesar que las prácticas de XP hacen más productivo el trabajo, hay gran resistencia a adoptarlas.

Rememoración de prácticas

5. ¿Qué tanto recuerda de XP?

Lejos la práctica más recordada es la programación de a pares, secundada por el Desarrollo Guiado por Tests y el Cliente In Situ. Es interesante también que los alumnos mencionan prácticas que siguen el espíritu de XP pero que no son “estándares” según la teoría .

Ilustración 32: Rememoración de prácticas de XP

Es interesante observar que los miembros del grupo XMLSync mencionan muchas más prácticas que su compañeros del otro proyecto.

0 1 2 3 4 5 6 7 8 9 10

Cliente in situ

Planning Game

Tests de Aceptación


Retroalimentación de avance

Ritmo sostenido

Stand Up Meeting

Desarrollo Guiado por Tests

Diseño Simple

Refactorización


Programación de a Pares


Brainstormings

mini tareas

planificacion y seguimiento

Reuniones de evaluación

Ges

tión

de

Proy

ecto

O

rient

ada

al

Val

or

Ges

tión

del

Des

arro

llo e

n Eq

uipo

Prog

ram

aci

ón d

e Ca

lidad

Prog

ram

aci

ón e

n Eq

uipo

Otr

as

Nº Menciones

Prá

ctic

a

Rememoración de prácticas

Total

93

Ilustración 33: Ilustración 36: Rememoración de prácticas de XP por proyecto

Aplicación de XP

6. ¿Ha aplicado XP en algún proyecto? ¿En cuántos? Nunca Parcialmente Totalmente

La mayoría de los alumnos han aplicado parcialmente XP desde que hicieron el curso.

0 1 2 3 4 5 6 7

Cliente in situDesarrollo Guiado por Tests

Espacio de Trabajo InformativoProgramación de a Pares

Propiedad Colectiva de CódigoRefactorización

Ritmo sostenidoStand Up Meeting

BrainstormingsCliente in situ

Desarrollo Guiado por TestsDiseño Simple

Espacio de Trabajo InformativoEstándares de Código

mini tareasplanificacion y seguimiento

Planning GameProgramación de a Pares

Propiedad Colectiva de CódigoRefactorización

Retroalimentación de avanceReuniones de evaluación

Stand Up MeetingTests de Aceptación

Map

ache

XMLS

ync

N º de menciones

Gru

po /

Prá

ctic

a

Rememoración de Prácticas

Total

Nunca10%

Parcialmente

80%

No responde

10%

Aplicación de XP después del curso

94

Aplicación de prácticas específicas

7. ¿Qué elementos de XP ha podido usar?

Ilustración 34: Aplicación de elementos de XP

Otra vez la práctica programación de a pares aparece destacada, siendo la más aplicada por la mayoría de los alumnos después del curso. Más abajo aparecen el Espacio de Trabajo Informativo y el Cliente In Situ. Al igual que en los puntos anteriores, los alumnos nombran prácticas distintas de las tradicionales pero afines con XP, como “compartir el conocimiento” y “Desarrollar Test a posteriori”.

0 1 2 3 4 5 6 7 8 9 10

Cliente in situ

Entregables Pequeños

Planning Game


Retroalimentación de avance

Stand Up Meeting


Diseño Simple

Refactorización

Programación de a Pares

compartir conocimiento

Desarrollo con Tests a posteriori

Ges

tión

de

Proy

ecto

O

rient

ada

al

Val

or

Ges

tión

del

Des

arro

llo e

n Eq

uipo

Prog

ram

ació

n de

Cal

idad

Pro

gra

mac

ión

en

Equi

poO

tras

Nº de menciones

Cicl

o de

XP

/ P

ráct

ica

aplic

ada

Aplicación de Prácticas Post-Curso

Total

95

Aplicación deseada de prácticas, pero no lograda

8. ¿Cuáles elementos de XP le hubiese gustado usar, pero no ha podido hacerlo? ¿Por qué?

Ilustración 35: Aplicación deseada por los alumnos pero no lograda Aparece muy destacado en los ex-alumnos del grupo XMLSync, el deseo frustrado de aplicar Desarrollo Guiado por Test. Se indica que no ha sido fácil aplicarlo por “falta de tiempo”, por “carencia de conocimientos técnicos sobre su aplicación a código legado”, y “falta de dominio de los frameworks de testing”. Un desafío mayor es el proyectar dichos aprendizajes en su práctica profesional, de manera tal que los alumnos puedan reproducir lo aprendido a pesar de que el medio no conozca de la nueva forma de trabajar que implica esta metodología.

96

6. RESULTADOS ADICIONALESAdemás del análisis que corresponde directamente a la validación de las hipótesis del trabajo, se obtuvieron dos resultados adicionales: un conjunto de mejoras al diseño instruccional para atacar las debilidades detectadas, y adicionalmente, a la luz de los antecedentes teóricos recopilados, poder enunciar cuáles son las claves pedagógicas que constituirían los pilares del diseño instruccional analizado en este trabajo. La validación de estas claves puede constituir en sí un trabajo futuro de investigación.

6.1 Mejoras para fortalecer el diseño instruccional del cursoA partir de lo ya expuesto en este capítulo, se desprende que el modelo pedagógico requiere de mejoras para fortalecer los aprendizajes de los alumnos, los que se detallarán a continuación.

6.1.1 Explicar XP a partir del nuevo modelo planteado en esta investigación.A las largo de cada una de las versiones del curso, se han ido organizando las prácticas de XP de manera tal que cada vez vaya siendo más simple su entendimiento por los alumnos. Uno de los frutos de esta investigación es un modelo que explica de manera más clara el rol de cada práctica, agrupadas ahora en los denominados “ciclos de sincronización de XP”36

6.1.2 Estrategias para evitar malos entendidos de las prácticas de XP

, el cual servirá de base explicativa para los futuros alumnos de este curso.

Como vimos anteriormente, varias prácticas de XP (en particular sus nombres) son difíciles de entender debido a los pre-conceptos de los alumnos. Una estrategia para subsanar este problema es escoger nuevos nombres que:

� Sean más claros con respecto al objetivo de la práctica

� Sean reconocibles por los alumnos en la literatura

� No entren en conflicto con respecto a los pre-conceptos de los alumnos

Para diseño simple, se escoge el nombre diseño justo-a-tiempo (just-in-time design), derivado del modelo de gestión ágil de Toyota, usado entre los practicantes de metodologías ágiles y que explica mejor el momento del diseño dentro del proceso del producción. Dado que el término “simple” está muy difundido en la metodología, hay que reforzar el significado que se le quiere dar en este contexto: “conciso-preciso-directo” cada vez que se use.

Para cliente in-situ, se propone el nombre definido por Kent Beck en la nueva versión de XP, involucramiento real del cliente (real customer involvement), que claramente refleja mejor la actitud que el cliente debe asumir: más que estar al lado del equipo, involucrarse en el proyecto.

Para estándares de código, se propone estilo común de codificación, que es exactamente lo que busca dicha práctica.

36 Ver capítulo 4.2.1

97

Para propiedad colectiva de código, se escoge mantener el nombre pero reforzar su significado: todos en el equipo deben poder entender y modificar cualquier parte del sistema.

Finalmente, en el caso del coaching, (también llamado liderazgo motivador) se determina que el nombre es muy adecuado, pero lo que falta es reforzar la práctica con ejemplos concretos.

6.1.3 Pre-selección de los proyectos a trabajarUna de las fortalezas de este modelo pedagógico es la autenticidad, que parte con el hecho de que los alumnos desarrollan para clientes reales con necesidades reales. Sin embargo, debido al poco tiempo efectivo de desarrollo disponible durante el curso (aproximadamente 10 sesiones con 3 horas de trabajo efectivas), hay que limitar los proyectos a aquellos que posean las siguientes características:

� un cliente con la real disponibilidad de involucrarse en el desarrollo, dado que no existe mucho margen para “convencerlo”

� incertidumbres técnicas y de requerimientos acotadas, es decir, que el proyecto posea una madurez tal que

� el cliente tenga claras sus prioridades de negocio

� el desarrollo técnico pueda partir rápidamente, sin tener que invertir demasiado tiempo en investigar alternativas.

De esta manera se estará asegurando que el cliente pueda recibir un producto útil al final del semestre, y lo que es más importante, que los alumnos puedan aplicar en su totalidad la metodología.

De no respetarse este criterio, puede suceder lo que sucedió con el proyecto XMLSync, situación que terminó perjudicando al curso completo.

6.1.4 Involucramiento temprano de los alumnos en la plataforma tecnológica y en el problema

Una de las deficiencias observadas en el Planning Game, fue que los alumnos no tenían una base de experiencia sobre la cual basar sus estimaciones. Para evitar este problema a futuro, los alumnos deberían tener como tarea para la casa la realización de cursos tutoriales sobre la plataforma tecnológica a usar en el proyecto, de tal manera que tengan una percepción básica sobre el esfuerzo de implementar una funcionalidad específica, y así llegar mejor preparados a un Planning Game.

Esta idea es también aplicable para el caso en que el problema de negocios requiera un entendimiento más acabado que aquel que es posible lograr de las reuniones con el cliente durante el taller, aunque esta práctica no debiera ser de mucha importancia si se sigue el criterio de pre-seleccionar los proyectos.

6.1.5 Implementar un sistema emergente de organización en los equiposEn equipos tan horizontales como los de XP, el coach asume un rol preponderante de liderazgo motivador, cohesionador de esfuerzos y guía en la aplicación de valores, principios y prácticas. Dado que no es posible contar con coaches experimentados debido a las

98

restricciones actuales de la carrera37

6.1.6 Establecer una base temprana de código funcional

, el definir un coach a priori basado en un currículo escrito o en la cantidad de proyectos realizados no es un buen predictor de éxito, dado el enfoque de liderazgo tradicional. Es mejor entonces comenzar con una estructura plana de equipo y dejar que el coach (y tracker) emerja(n) a partir de la dinámica interna del equipo en forma natural.

Esta práctica es recogida de la experiencia de la Universidad de Lund [22], y consiste en poner como primera meta de desarrollo a los alumnos un software ejecutable, que incluye los componentes básicos que tendrá la aplicación y que no implementa ninguna historia de usuario, el cual constituirá la base de partida para el desarrollo de la aplicación. Junto a ella se establecerá como práctica obligatoria la utilización de sistemas de control de versiones de código, para tener prontamente un repositorio unificado del código.

A esta práctica se le denomina “iteración 0”.

6.1.7 Fortalecer la aplicación del modelo de aprendizaje cognitivo Hasta el momento se ha implementado implícitamente en el curso un modelo similar de “aprendizaje cognitivo”38

� para el planning game se uso el juego “extreme hour”, con muy buenos resultados.

. Veamos algunos ejemplos:

� ante cada charla de sus compañeros, los alumnos deben preparar ensayos reflexionando sobre lo expuesto, y expresando sus dudas para ser retroalimentados por el profesor.

Siguiendo la línea del primer punto, se postula entonces la creación de talleres similares para las prácticas que han demostrado ser las más complejas de adoptar, que son diseño simple, en donde se integrarían técnicas tales como análisis orientado a objetos usando tarjetas clase-responsabilidad-colaborador, y para el desarrollo guiado por tests. Estos talleres serían diseñados por el profesor, pero podrían ser dictados por algunos alumnos del propio curso – con el apoyo del docente –.

Con respecto a la retroalimentación de ensayos, dudas expresadas y opiniones de los alumnos, la gestión personalizada por parte del profesor exige una carga administrativa no despreciable, por lo cual es necesaria la implementación de herramientas de coordinación que faciliten el entregar una retroalimentación oportuna que realmente sea efectiva para mejorar los aprendizajes de los alumnos.

6.2 Enunciación de claves del modelo pedagógico aplicadoLa motivación original de esta investigación consistió en encontrar las claves del éxito del modelo instruccional aplicado en este curso. Después del trabajo realizado se puede enunciar que la clave fundamental de este modelo radica en haber reproducido de manera efectiva la dinámica del desarrollo ágil, y en la sintonía existente entre esta última y las necesidades cognitivas de las personas involucradas en un proyecto de software, hecho ya sugerido en la industria tal como vimos en el punto .

37 En contraste con la experiencia de la Universidad de Lund, visto en 0, en donde alumnos de cursos más avanzados ejercen estos

roles 38 Ver 0 “El constructivismo social, la teoría del aprendizaje situado y el modelo pedagógico de aprendizaje cognitivo”

99

La necesidad de armonizar aspectos que están siempre cambiando como el problema de negocio, la tecnología, las funcionalidades del producto, el conocimiento dentro del equipo de desarrollo, etc. es resuelta por las metodologías ágiles instalando diversas herramientas de reflexión y sincronización permanente (dicho de otra manera, de aprendizaje acelerado) en los participantes del entorno de desarrollo de software, las que una vez puestas en funcionamiento activan una cultura de reflexión y aprendizaje sostenido.

Si deseamos mejorar en los desarrolladores la práctica de las metodologías ágiles, sólo hace falta enfatizar en los momentos de evaluación la reflexión metodológica (¿Qué prácticas necesitamos aplicar o mejorar? ¿Qué dudas tengo con respecto a tal o cual práctica?, etc.), acción que probablemente haría cualquier buen coach de XP.

De lo anterior se desprende que dado que el modelo inicial del curso tenía como principio el reproducir de la forma más auténtica posible un proyecto guiado según los valores, principios y prácticas de XP, se benefició de esta cultura de reflexión y aprendizaje sostenido, sólo exigiendo de parte del profesor agregar una leve capa de prácticas pedagógicas para evaluar y retroalimentar la aplicación de la metodología, lo que representa en la Ilustración 36.

Ilustración 36: Complementación natural entre XP y el modelo pedagógico del curso CC62V

Podemos resaltar además las similitudes entre los principios de este modelo pedagógico y la teoría de aprendizaje situado visto en 0, en particular en lo que se refiere a exponer a los alumnos a situaciones auténticas-. También es posible extender esta comparación al modelo pedagógico de aprendizaje cognitivo, tal como podemos apreciar en la Ilustración 37.

Profesor / Meta-Coach/ esesor //PrProfofee

Ciclo de Gestión del Proyecto Orientada al ValorCiclo de Gestión del Proyecto Orientada al Va

Ciclo de Gestión del Desarrollo

Ciclo de Programación de calidad

100

Ilustración 37: Cómo el modelo pedagógico de aprendizaje se realiza en el curso CC62V

Desarrollo de Proyecto Auténticousando XP

Reflexión continua, Ensayos de opinión personal, etc.

Tutoriales de Prácticas de XP

eXtreme Hour (Planning Game),Análisis Orientado a Objectos – CRC,

Desarrollo Guiado por Test

Principios y Prácticas de XP

Exploración

Metacognición

Práctica Guiada (Coaching)

Retirar paulatinamente el apoyo

Recopilación Estrategias ExpertasConsiderar las estrategias que un experto aplicaría en una tarea.

Diseño soportes instruccionalesDiseñar desafíos que, actuando como soportes instruccionales, motivarán a los aprendices a aplicar las estrategias. Estas actividades estarán situadas u orientadas a resultados relevantes.

Modelado de estrategias Modelar las estrategias a sus alumnos a través de la resolución del desafío

ArticulaciónVerbalizar los razonamientos y métodos usados para resolver el desafío, (metacognición)

ofrecer retroalimentación y consejo experto

ProfesorPPPPPPPPPPrrrrrrrrooooooooooffffffffffeeeeeeeeeesssssssssoooooooooorrrrrrrr AprendicesAAAAAAAppppppppprrrrrrrreeeeeeeeennnnnnnndddddddddiiiiiiiccccccccccceeeeeeeeeessssssssssspppppp

Motivación Motivar en sus alumnos la metacognición

ReflexiónReflexionar y aprender de las estrategias usadas por sus pares y por el profesor.

Aplicar estrategias a nuevos problemas.

( g)practicar habilidad resolviendo el

desafío

tes ins

do de estra

Práctica Guiada

M t

loraci

APRENDIZAJE COGNITIVO Y MODELO

PEDAGÓGICO DEL CURSO CC62VFlujo del modelo pedagógico

AAAAA RRRRRRRREEEEEEEEEENNNNNNNNNNNDDDDDDDDDIIIIIZZZZZZZZZZZAAAAAAAAAAAJJJJJJJAAAAAAAAAAPPPPPPPPRRRRRRRRRR EEEEEEEEEE CCCC GGGGGGGGGGNNNNNNNNIIIIIITTTTTTTTIIIIIIVVVVVVVVVOOOOOOOOOCCCCCCCCOOOOOOOOOGGGGGCCCCCCCC OOOOOOOO YYYYY MMMMMOOOOOOOOOODDDDDDDDEEEEEEELLLOOOOOOOOOYYYYY MMMMYYYYY

PPPPPPPPPPEEEEEEEEEEEDDDDDDDDDDDDAAAAAAAAAGGGGGGGGÓÓÓÓÓÓÓÓÓGGGGGGGGGGGIIIIIICCCCCCCCCCOOOOOOOOOO DDDDDDDDDEEEEEEEEEELLLLLOOOOOOOO DDDDDDD CCCCCCUUUUUUUUUUURRRRRRRRRRSSSSSSSSSOOOOOOOLLLLLLL CCCCCCCCC CCCCCCCCCCCCCCCCCCC6666666666662222222222VVVVVVVVVOO YYYY MMMMMMMOOOOOOOODDDDDDDDEEEEELLLLLOOOOOOOOOOYY MMMMMYY

OOOOOOOOOO CCCCCCCCCFFlFlFFFFlFFluujujjjujuuju o ooooo dedededededeedell ll momoomomommmomoodedededededeedeeloololooooloo p p ppppppededededededeedde agagagagagaagagaagggógógógógógógóggógggicicciicccicoooooo

101

6.2.1 Propuesta de prácticas pedagógicas ágilesEn congruencia con la idea de que el modelo del curso CC62V complementa a XP con una capa de prácticas pedagógicas, en la Ilustración 38 presentamos su relación con XP en general.

Ilustración 38: Prácticas pedagógicas instaladas sobre XP

Reproducción fiel de XPPara enseñar XP lo más importante es construir un ambiente de aprendizaje que refleje lo más fielmente posible sus prácticas, principios y valores. La labor del profesor-coach estará inicialmente abocada a “echar a andar” con sus alumnos los ciclos de sincronización de XP para luego ir perdiendo protagonismo y dedicarse a la acompañar y retroalimentar el trabajo de sus alumnos.

Involucramiento temprano de los alumnosLos alumnos deben asumir lo antes posible un rol activo en el curso, tanto a través de talleres prácticos, como actuando ellos mismos de mediadores entre los contenidos teóricos y sus compañeros, apoyándose en la guía del profesor.

Corta introducción teórica, y a trabajarXP presenta un marco conceptual complejo con el cual los alumnos deben familiarizarse antes de aplicar la metodología. La idea de esta práctica es destinar sólo el tiempo necesario para explicar y presentar los fundamentos de las metodologías ágiles y de las prácticas, en el entendido de que los alumnos sólo van a lograr interiorizarlas una vez que las apliquen en la realidad.

Ges

tión

ped

agóg

ica

de lo

s A

pren

diza

jes

Reproducción fiel de XP

Involucramiento temprano de los

alumnos

Corta introducción

teórica

Desarrollo en clases, Estudio e

Investigación en casa

Retroalimentación temprana a los

alumnos

Aprendizaje Cognitivo de

nuevas destrezas

Ges

tión

del

Pro

yect

o

orie

ntad

a al

val

or

Ges

tión

del

Des

arro

llo e

n Eq

uipo

Pro

gram

ació

n en

Equ

ipo

Pro

gram

ació

n In

crem

enta

l de

Cal

idad

Planning Game

Tests de Aceptación del Cliente

Entregas pequeñas

Integración continua

Estilo Común de Código



(+ Mantener el equipo rotando)


Diseño Just In Time

Refactorización


Ritmo Sostenido ( No a las horas extra)

Retroalimentaciónde Avance(Tracking)

Liderazgo Motivador(Coaching)

Cliente en terreno(Un sólo equipo)

Stand Up Meeting

Desarrollo

noo)

ión

Planning Game de la Iteración

Definición Validación

102

Desarrollar en las horas de clases, estudiar e investigar en la casaEsta práctica está ligada a la restricción horaria del curso, y tiene que ver con priorizar en tiempos del taller aquellas experiencias que sólo pueden reproducirse en ese ámbito, tales como el desarrollo incremental, el trabajo en equipo y la relación cercana cliente-desarrolladores. La carga horaria restante del curso, a ser realizada como trabajo personal del alumno fuera de las sesiones del taller puede ser destinada entonces a realizar investigación o a profundizar conceptos.

Retroalimentar tempranamente los aprendizajesAnte la gran cantidad nuevos conceptos que plantean las metodologías ágiles, es fundamental, además de presentar claramente sus fundamentos, el detectar y corregir lo antes posible cualquier duda o malentendido que presenten los alumnos.

Aprendizaje cognitivo de nuevas destrezasLas nuevas destrezas de gestión, trabajo en equipo y desarrollo que implican las metodologías ágiles son demostradas y transferidas paulatinamente siguiendo un modelo de aprendizaje cognitivo, en donde es rol del profesor preparar los soportes de aprendizaje para que sus alumnos vayan incorporando las nuevas destrezas hasta poder actuar de manera autónoma.

103

7. CONCLUSIONESTal como se indicó al inicio de este trabajo, este curso fue pensado para reflejar de la manera más fiel posible un ambiente de trabajo ágil, y en particular, de XP. La observación informal de las primeras versiones del curso mostraba que los alumnos y clientes agradecían la experiencia vivida, y que se obtenían resultados bastante positivos tanto del punto de vista de la opinión de los clientes como de los alumnos que participaban de él. Todo lo anterior dio pie a las dos hipótesis de esta investigación, que aquí contrastaremos con los resultados obtenidos.

7.1 Hipótesis 1: Es posible la reproducción efectiva de un ambiente de desarrollo ágil (XP) en un curso universitario

“Se puede ofrecer a los alumnos de ingeniería de software una experiencia representativa de las metodologías ágiles - en particular Extreme Programming – dentro del marco, recursos y tiempo de un curso normal de la carrera. “

Los resultados obtenidos de la experiencia, en particular en lo que se refiere a la amplitud de aplicación lograda dentro del espectro de prácticas de XP lograda por los alumnos a lo largo del curso, permite validar que es posible que los alumnos experimenten personalmente un proyecto XP dentro del contexto y restricciones de un curso universitario, y más aún, asumir un desafío real para un cliente con necesidades auténticas. Se descubre además que la práctica “Programación de a pares” surge como aquella cuya aplicación sirve de puerta de entrada a muchas de las otras prácticas del método.

Fruto de este trabajo surgen también algunas limitaciones:

� el lapso de tiempo disponible cada semana (3,5 horas) es bastante reducido si se quiere reflejar correctamente la práctica “productividad sostenida”, dado que pequeños problemas en el desarrollo que sufran los alumnos tendrán un alto impacto en el total de tiempo disponible para trabajar. Si bien esta es una limitante difícil de eliminar del modelo, no es fundamental para entender la metodología en sí.

� dada la influencia que tiene el proyecto en que se trabaja en la comprensión lograda, es necesario seleccionar aquellos que, sin perder autenticidad, tengan una complejidad que esté suficientemente acotada como para poder poner en marcha la metodología sin entramparse en temas específicos al problema a resolver, y así poder vislumbrar buenos resultados al final del curso, tanto de aprendizaje como de producto.

Surgieron además en la experiencia algunos problemas puntuales de reproducción del ambiente ágil, para los cuales se propone un conjunto de mejoras al diseño del curso, tal como se muestra en la Tabla 26:

104

Área con Problema Mejora propuesta

elección de coaches Implementación de un modelo emergente de organización en los equipos

estimación de tareas Pre-selección de proyectos, para desechar aquellos con complejidad excesiva

Involucramiento temprano de los alumnos en la plataforma y en el problema

generación de una base de código funcional

Establecer una base temprana de código funcional (que será el objetivo de una “Iteración 0”), administrado por un sistema de control de versiones

Tabla 26: Áreas en donde hubo problemas de aplicación de XP y la mejora propuesta

7.2 Hipótesis 2: La exposición de los alumnos a un desarrollo auténtico en un ambiente ágil genera buenos aprendizajes sobre las metodologías ágiles

“Gracias a la naturaleza de los ambientes de desarrollo ágil, que están orientados a potenciar el aprendizaje continuo en sus integrantes para así lograr la mayor productividad, al reproducirlos fielmente en el contexto de un curso de Ingeniería de Software se obtienen buenos resultados en los aprendizajes de los alumnos.”

Los alumnos que se presentan al curso poseen una formación en paradigmas que muchas veces contradicen lo que en este curso se plantea, lo que se refleja en una serie de pre-conceptos que entran en conflicto con las metodologías ágiles, tal como vimos en el punto 5.2.2, los que se resumen en la Tabla 27:

Pre-concepto Concepto ágil

Liderazgo de equipo vertical, reflejado en el rol clásico de “jefe de proyecto”

Roles horizontales y liderazgo

Diseño como actividad globalizadora y a realizarse antes del desarrollo como tal

Diseño incremental a medida de que se va comprendiendo el problema a resolver

Divergencia entre la programación de funcionalidades y la validación de éstas, considerando ésta última como una actividad separada, a posteriori, y en último caso, sacrificable.

Desarrollo guiado por tests

Tabla 27: pre-conceptos de los alumnos versus conceptos ágiles

Además, algunas prácticas poseen nombres que, dados los pre-conceptos, llevan a confusión, por lo que se propone a futuro una nueva manera de presentarlas a los alumnos:

105

Práctica Nueva forma de presentarla

“Estándares de código” “Estilo común de codificación”

“40 Horas a la semana” “Productividad sostenida”

“Diseño simple” “Diseño justo-a-tiempo”

“Cliente in-situ” “Real involucramiento del cliente”

“Propiedad colectiva del código” Mantener el nombre y reforzar su significado

“Coaching” Mantener el nombre y reforzar su significado

Tabla 28: Prácticas que deben ser mejor presentadas a los alumnos

A pesar de los problemas presentados, la comprensión lograda de las prácticas que involucra XP es bastante aceptable en la mayoría de los alumnos del curso, notándose una clara mejora en la comprensión a medida que transcurrió el curso. Esto se refuerza por el hecho de que los alumnos declaran en su mayoría haber sido influenciados en su práctica de desarrollo al introducir algunas prácticas ágiles aprendidas en el curso. Queda eso sí el desafío de reforzar mediante técnicas de “aprendizaje cognitivo” nuevas destrezas que requiere el desarrollo ágil en XP, como el “desarrollo guiado por test” o la continúa gestión de alcance con el cliente.

Por último, se establece una fuerte analogía entre el modo de funcionamiento de un proyecto según las metodologías ágiles y el cómo aprenden las personas según la perspectiva constructivista del aprendizaje, por lo cual se enuncia una nueva hipótesis (posible origen de nuevas investigaciones), que plantea que los buenos resultados percibidos a lo largo de la aplicación del diseño pedagógico del curso CC62V, al basarse en metodologías ágiles, potencian en forma natural el aprendizaje y por ende permiten al docente asumir un rol de meta-coach que retroalimente en los alumnos la comprensión y aplicación de la metodología.

106

8. TRABAJO FUTURO

8.1 Aplicación del diseño instruccional (o elementos de éste) enmás cursos de la carrera

Al momento de finalizar esta tesis, hay dos cursos de la carrera que ya se están beneficiando de este modelo pedagógico mejorado de metodologías ágiles, el curso CC62V en sus nuevas versiones y el curso obligatorio CC61A, último ramo obligatorio de la carrera donde los alumnos trabajan también en proyectos reales usando principalmente las prácticas del ciclo de gestión de valor y de equipo de XP. Posiblemente existen otros ramos a los cuáles se les podría aportar algunas de las herramientas pedagógicas desarrolladas.

8.2 Líneas de desarrollo para el modelo explicativo de XP y su modelo evaluativo derivado.

De esta investigación derivan dos sub-productos con valor propio: el modelo que explica XP a partir de “ciclos de sincronización”, y el modelo evaluativo que evalúa los aprendizajes siguiendo esa perspectiva sistémica.

En lo que se refiere al primero, sería interesante el madurarlo aún más y probar su validez tratando de explicar con él las innovaciones que se han producido en el mundo de las metodologías ágiles. De hecho ya existe desde el 2005 una versión revisada de XP [5], que redefine el marco de valores, principios, prácticas, y que ha ido profundizando en las bases conceptuales que explican la lógica de las metodologías ágiles. Por lo tanto existe el desafío permanente de evaluar e incorporar aquellas innovaciones en el modelo y así mantener al día el mensaje entregado a los alumnos.

Con respecto al modelo evaluativo: dado que en esta investigación las evidencias de los aprendizajes fueron tomadas antes de que este modelo evaluativo estuviera maduro, la estructura de la información no estaba sincronizada con el análisis que fue necesario realizar, debiendo realizarse un gran esfuerzo de lectura minuciosa de los ensayos y otras evidencias, y de reorganización y selección de la información más relevante. Para la aplicación efectiva de este modelo entonces es necesario diseñar y validar herramientas de evaluación que permitan con un esfuerzo razonable medir los aprendizajes y retroalimentar ágilmente a los alumnos.

8.3 Aplicar este modelo pedagógico a la capacitación de profesionales

El modelo pedagógico analizado en esta investigación posee características permiten proyectar su aplicación al ámbito de la capacitación de profesionales, tales como el poco tiempo en el que es posible introducir el nuevo lenguaje de las metodologías ágiles y muchas de sus prácticas, lo auténtico del aprendizaje y la satisfacción que logra en los alumnos. Los mayores desafíos que se pueden esperar en este nuevo ámbito son:

� un mayor arraigo de los conceptos tradicionales: por lo que es esperable mayor resistencia al paradigma ágil

107

� mayor heterogeneidad de capacidades técnicas: EL modelo ha sido aplicado en de las mejores escuelas del país en el área, lo que conlleva también a poseer los alumnos con mejores destrezas técnicas, como el análisis y la programación. En el ámbito profesional, en cambio, existen personas con muy diversos niveles de destrezas técnicas y de formación, por lo que debería existir algún tipo de diagnóstico de entrada y consecuente acciones de nivelación para los alumnos lleguen con oportunidades similares a experimentar este modelo.

8.4 Validar la relación entre contructivismo y métodos ágiles, y como esta relación potenciaría los aprendizajes

A lo largo de esta investigación se ha hecho una analogía entre los últimos avances en la ciencia del aprendizaje y cómo las metodologías ágiles organizan el complejo entorno cognitivo de un proyecto de software, y al hacerlo se propone que dicha similitud podría ser responsable de un ambiente acelerado de aprendizaje. Queda entonces abierta la puerta a nuevas investigaciones quizás más cercanas a la psicología educacional que permitan validar fehacientemente dicha hipótesis.

108

9. REFERENCIAS Y BIBLIOGRAFÍA[1] Anderson, J. R., Cornrad, F., & Corbett, A., “Skill acquisition and the LISP Tutor,” Cognitive Science, 13, 1989,

pp. 467-505.

[2] Anderson, L.W., & Krathwohl, D.R. (Eds.) (2001). “A taxonomy of learning, teaching, and assessment: A revision of Bloom's taxonomy of educational objectives.” New York: Longman.

[3] Astrachan, O. ; Duvall, R ; Wallingford, E.; “Bringing Extreme Programming to the Classroom” Proceedings of XP Universe Conference’01, 2001.

[4] Auer, Ken; Miller, Roy, “Extreme Programming Applied: Playing to Win” Addison-Wesley Professional; 1st edition, October 1, 2001.

[5] Beck, Kent y Andres, Cynthia, “Extreme Programming Explained” Addison-Wesley Professional, 2nd. edition 2004.

[6] Beck, Kent, “Extreme Programming Explained”, Addison-Wesley Professional, 1st Edition, 1999.

[7] Beck, K., Fowler, M, “Planning Extreme Programming”, Addison-Wesley Professional, 1st edition, 2000.

[8] Bergin, J., Caristi, J., Dubinsky, Y., Hazzan, O., Williams, L. “Teaching software development methods: the case of extreme programming”, Proceedings of the 35th SIGCSE technical symposium on Computer science education

[9] Bloom, B.S. 1964 “Stability and Change in Human Characteristics”. New York: Wiley. Bransford, J.D., and B.S. Stein

[10] P. Becker-Pechau, H. Breitling, M. Lippert, A. Schmolitzky, “Teaching Team Work: An Extreme Week for First-Year Programmers, in Proceedings of XP2003”, LNCS 2675, pp. 386 – 393, Genova, Italia,Mayo 2003..

[11] Boehm, B. “A spiral model of software development and enhancement”. IEEE Computer, 21(5) 61-72, 1986.

[12] Brooks, Fred. “No silver bullet: Essence and Accidents of Software Engineering”, Computer, Vol. 20, Nº 4 (April 1987): 10-19

[13] Brown, A. L. “The development of memory: Knowing, knowing about knowing, and knowing how to know”. In Advances in Child Development and Behavior (Vol. 10), H.W. Reese, ed. New York: Academic Press, 1975.

[14] Collins, A., Brown, J. S., & Newman, S. E. “Cognitive apprenticeship: Teaching the crafts of reading, writing, and mathematics”. In L. B. Resnick, (Ed.), Knowing, learning, and instruction: Essays in honor of Robert Glaser. Hillsdale, NJ, USA: Lawrence Erlbaum Associates, 453-494, 1989.

[15] Conn, Samuel, “A New Teaching Paradigm in Information Systems Education: An Investigation and Report on the Origins, Significance, and Efficacy of the Agile Development Movement“, Information Systems Education Journal, Volume 2, Number 15, February 11, 2004.

[16] Cowan, Nelson. “The Magical Number 4 in Short-term Memory: A Reconsideration of Mental Storage Capacity”. Behavioral and Brain Sciences 24, 2001

[17] Davidson, J. E., Deuser, R. & Sternberg, R. J., “The Role of Metacognition in Problem Solving,” J. Metcalfe & A. P. Shimamura (eds.), Metacognition: knowing about knowing. Cambridge, MA: MIT Press, 1994, pp. 207-226.

[18] deGroot, A.D. 1965 “Thought and Choice in Chess”. The Hague, the Netherlands: Mouton

[19] Donovan, M. Suzanne; Bransford, John D.; Pellegrino, James W. “How People Learn: Brain, Mind, Experience, and School” Expanded edition Washington: National Academies Press, 2003.

[20] M. R. Endsley. “Situation awareness and workload: Flip sides of the same coin”. Technical report, Department of Aviation, The Ohio State University, 1993.

[21] Hedin, G., Bendix, L., Magnusson, B., “Introducing Software Engineering by means of Extreme Programming” Proceedings of the 25th International Conference on Software Engineering, pp. 586- 593, 2003

[22] Hedin, G., Bendix, L., Magnusson, B., “Teaching Software Development using Extreme Programming” en el “Book of Scandinavian Pedagogy of Programming Network” en http://www.spop.dk/chap-v3/SPOP-Lund-051104.pdf

109

[23] IEEE Computer Society. “Customer Satisfaction Action Plan”. Customer Satisfaction Action Plan Group, and Software Engineering Standards Committee of the IEEE Computer Society. http://computer.org/standards/sesc/cspg/plan.htm, February 1999.

[24] M. Jazayeri, “Education of a Software Engineer”, Keynote presentation at ASE 2004, Linz, Austria, 2004.

[25] Jacobson, Ivan, “A Resounding "Yes!" to Agile Processes -- But Also to the "Next Big Thing", http://www-128.ibm.com/developerworks/rational/library/2814.html

[26] Johnson, D., Caristi, J. “Extreme Programming and the Software Design Course”, Proceedings of XP Universe, 2001.

[27] Johnson , Jim, “ROI, It’s your job”, Proceedings of XP2002 Conference, Sardinia, Italia, 2002.

[28] Karlstrom, Daniel, “Introducing Extreme Programming An Experience Report”, Proceedings of XP2002, Sardinia, Italia, 2002.

[29] Larmar, Craig y Basili, Victor. “Iterative and Incremental Development: A Brief History”, IEEE Computer, June 2003 (Vol. 36, No. 6) pp. 47-56

[30] Lappo, Peter, “No Pain, No XP Observations on Teaching and Mentoring Extreme Programming to University Students”, Proceedings of XP 2002, Sardinia, Italia, 2002.

[31] Larman, Craig. “Agile and Iterative Development: A Manager's Guide”, Addison-Wesley Professional, 1st edition, 2003.

[32] Lave, J., “Cognition in Practice: Mind, Mathematics and Culture in Everyday Life (Learning in Doing S.)”, Cambridge University Press, July 29, 1988.

[33] Lund, M. and Zapata, S. “Proposal to Measure Software Customer Satisfaction”. Proceedings Argentine Symposium on Software Engineering. Argentina, 2000.

[34] Martin , James, “Rapid Application Development”, Macmillan Coll Div, 1991

[35] Manns, Mary Lynn; Rising Lynda, “Leading Fearless Change: Introducing Agile Approaches and Other New Ideas Into Your Organization”, Proceedings of XP 2004, pp. 210, Garmisch-Partenkirchen, Germany, 2004.

[36] Maturana, H. y Varela, F. “El árbol del conocimiento”. Madrid: Debate, 1990.

[37] Miller, G.A.” The magical number seven, plus or minus two: Some limits on our capacity for processing information”. Psychological Review, 63, 81-97, 1956.

[38] Müller, M., Link, J. , Sand, R., Malpohl, G. “Extreme Programming in Curriculum: Experiences from Academia and Industry”, Proceedings of XP 2004, pp. 294-302, Garmisch-Partenkirchen, Germany, 2004.

[39] M. Müller, W. Tichy, “Case study: extreme programming in a university environment”, Proceedings of ICSE 2001, pp. 537-544, Toronto, Ontario, Canada, May 2001.

[40] Uttam Narsu, Liz Barnett, “Lessons Learned Practicing Agile Development”, Giga Group Research, 2002

[41] M. Paulk, B. Curtis, M. Chrissis y C. Weber, “Capability Maturity Model for Software (Version 1.1)”, Technical Report, CMU/SEI-93-TR-024.

[42] Pirolli, P. & Recker, M., “Learning Strategies and Transfer in the Domain of Programming,” Cognition and Instruction, 12, 1994.

[43] Mary y Tom Poppendieck, “Lean Software Development: An Agile Toolkit for Software Development Managers”, Addison-Wesley, 2003.

[44] Royce, W.W, “Managing the development of large system processes”, Proceeding of IEEE WESON, 1970.

[45] Jean-Guy Schneider, Lorraine Johnston, “eXtreme Programming at universities: an educational perspective”. ICSE 2003, pp: 594 – 599, Portland, Oregon, USA.

[46] Simon, H.A., and W.G. Chase 1973 Skill in chess. American Scientist 61:394-403.

[47] Shukla, A. Williams, L. “Adapting Extreme Programming For A Core Software Engineering Course”, Proceedings of the 15th Conference on Software Engineering Education and Training, Covington, KY, USA, pp. 184 – 191, 2002.

[48] The Standish Group, CHAOS Report, 2002.

110

[49] Software Engineering Education Knowledge, disponible en http://sites.computer.org/ccse/SE2004Volume.pdf

[50] Steinberg, Daniel H. “The effect of unit tests on entry points, coupling and cohesion in an introductory Java programming course”, Proceedings of XP Universe Conference’01, 2001.

[51] Stephens, Matt; Rosenberg , Doug: “Extreme Programming Refactored: The Case Against XP”, APress, 2003.

[52] Takeuchi H., Nonaka I, “The New New Product Development Game”, Harvard Business Review, 1986.

[53] Talbott, N., Auer, K., “Apprenticeship in a Software Studio: An Old and New Model for Education”, Educator’s Symposium, OOPSLA 2000, Minneapolis, Minnesota, USA, October 15-19, 2000.

[54] Truex, D., Baskerville, R. And Klein, H.: “Growing Systems in an Emergent Organization”, Communications ACM, 42, (8), pp. 117-123, 1999.

[55] Vosniadou, S., and W.F. Brewer 1989 “The Concept of the Earth’s Shape: A study of Conceptual Change in Childhood”. Unpublished paper. Center for the Study of Reading, University of Illinois, Champaign, Illinois.

[56] West, David. “Enculturating Extreme Programmers”, Proceedings of XP Universe, 2001.

[57] Williams, L., Upchurch, R. “Extreme Programming For Software Engineering Education?” 31st Annual Frontiers in Education Conference, 2001.

[58] Wong, Tim “Is Extreme Programming (XP) a Useful Tool for Computer Science Education?”, Proceedings of The National Conference on Undergraduate Research (NCUR), University of Utah, Salt Lake City, March 13-15, 2003.

[59] Williams, L. Bergin, J., Caristi, J., Dubinsky, Y., Hazzan, O., “Teaching software development methods: the case of extreme programming”, Proceedings of the 35th SIGCSE technical symposium on Computer Science education, Norfolk, Virginia, USA, pp. 448 – 449, 2004.

[60] Williams et al, “Extreme Programming Evaluation Framework for Object-Oriented Languages” North Carolina State University Department of Computer Science TR-2004-18, 2004.

[61] Driscoll, M.P. 1994. “Psychology of Learning for Instruction”. Needham Heights: Allyn & Bacon.

[62] Vygotsky, L.S. (1978). Mind and society: The development of higher psychological processes. Cambridge, MA: Harvard University Press.

Tesis Agustin Antonio Villena Moya - Metodologias Agiles

Documents

Transcript of Tesis Agustin Antonio Villena Moya - Metodologias Agiles