Un modelo empírico de enseñanza de las metodologías ágiles

184
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

description

Las 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.

Transcript of Un modelo empírico de enseñanza de las metodologías ágiles

Page 1: Un modelo empírico de enseñanza de las metodologías ágiles

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

Page 2: Un modelo empírico de enseñanza de las metodologías ágiles

2

RESUMEN

Las 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.

Page 3: Un modelo empírico de enseñanza de las metodologías ágiles

3

AGRADECIMIENTOS Este 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.

Page 4: Un modelo empírico de enseñanza de las metodologías ágiles

4

TABLA DE CONTENIDOS

RESUMEN ................................................................................................................................................................. 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 .......................................................................................................................... 12 2.2 METODOLOGÍA ........................................................................................................................................................ 12

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

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

3.2 METODOLOGÍAS ÁGILES (MA) Y EXTREME PROGRAMMING (XP) ..................................................................... 16 3.2.1 Bases conceptuales de las MA ................................................................................................................................... 17 3.2.2 La propuesta de Extreme Programming (XP) .................................................................................................. 22 3.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 ..................................................................................... 33 3.3.1 Los antecedentes de la ciencia del aprendizaje ............................................................................................... 33 3.3.2 La ciencia del aprendizaje: aprender con entendimiento .......................................................................... 33

3.4 EDUCACIÓN DE LA INGENIERÍA DE SOFTWARE .................................................................................................... 39 3.4.1 Objetivos y Contenidos de la Educación en Ingeniería de Software ...................................................... 40 3.4.2 Modelos pedagógicos para la formación ingenieros de software .......................................................... 42 3.4.3 Desafíos en la educación de ingeniería de software ...................................................................................... 44 3.4.4 Desafíos de la incorporación de XP en la formación de los ingenieros de software ...................... 46 3.4.5 Caracterización de las aplicaciones de XP en la formación académica de los ingenieros de software ................................................................................................................................................................................................. 47 3.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 ...................................................................................................................................................................... 53 4.1.1 Orígenes del Curso CC62V ........................................................................................................................................... 54 4.1.2 Contexto del curso ........................................................................................................................................................... 55 4.1.3 Diseño Instruccional del curso CC62V ................................................................................................................. 57

4.2 XP COMO ORGANIZADOR DE UN AMBIENTE DE DESARROLLO DE SOFTWARE ...................................................... 66 4.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 .................................. 73 4.3.1 Razones para un nuevo modelo evaluativo ....................................................................................................... 73 4.3.2 Modelo de evaluación de la experiencia .............................................................................................................. 74 4.3.3 Medios de recopilación de evidencias para evaluar la experiencia ....................................................... 74 4.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 ......................................................................................................................... 79 5.1.1 Innovaciones aplicadas al diseño instruccional .............................................................................................. 79 5.1.2 Calendario de Actividades ........................................................................................................................................... 79 5.1.3 Tamaño del curso ............................................................................................................................................................ 80 5.1.4 Proyectos desarrollados ............................................................................................................................................... 80

Page 5: Un modelo empírico de enseñanza de las metodologías ágiles

5

5.2 ANÁLISIS DE RESULTADOS DE LA EXPERIENCIA .................................................................................................... 82 5.2.1 Conocimientos previos .................................................................................................................................................. 82 5.2.2 Aprendizajes logrados durante el curso .............................................................................................................. 82 5.2.3 Calidad en la reproducción del ambiente XP durante el curso ................................................................ 85 5.2.4 Percepciones de los clientes........................................................................................................................................ 87 5.2.5 Encuesta de impacto post curso............................................................................................................................... 89

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

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

6.2 ENUNCIACIÓN DE CLAVES DEL MODELO PEDAGÓGICO APLICADO ........................................................................ 98 6.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 .........................................................................................................................................................103 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..............................................................................................104

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

8.1 APLICACIÓN DEL DISEÑO INSTRUCCIONAL (O ELEMENTOS DE ÉSTE) EN MÁS CURSOS DE LA CARRERA ..........106 8.2 LÍNEAS DE DESARROLLO PARA EL MODELO EXPLICATIVO DE XP Y SU MODELO EVALUATIVO DERIVADO. ......106 8.3 APLICAR ESTE MODELO PEDAGÓGICO A LA CAPACITACIÓN DE PROFESIONALES ...............................................106 8.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 .................................................................................................111 10.1.1 Fase teórica................................................................................................................................................................ 111 10.1.2 Fase práctica ............................................................................................................................................................. 113

10.2 HERRAMIENTAS DE EVALUACIÓN UTILIZADAS ....................................................................................................155 10.2.1 Encuesta de co-evaluación ................................................................................................................................. 155 10.2.2 Encuesta al cliente ................................................................................................................................................. 156 10.2.3 Pauta de Evaluación de Ensayo de XP y Opinión del Primer Ciclo ................................................ 157 10.2.4 Pauta de Evaluación del Proyecto y Proyección a la Vida Profesional ....................................... 159

10.3 RESUMEN DE ENSAYOS DE ALUMNOS ...................................................................................................................161 10.3.1 Proyecto Mapache .................................................................................................................................................. 161 10.3.2 Proyecto XMLSync .................................................................................................................................................. 167

Page 6: Un modelo empírico de enseñanza de las metodologías ágiles

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 ........................................ 17 Ilustración 3: Comparación entre el valor generado por un proyecto tradicional y lo que sería ideal ..... 18 Ilustración 4: Curva de costo de cambio tradicional versus la revisada .............................................................. 19 Ilustración 5: El ambiente del desarrollo de software ............................................................................................... 21 Ilustración 6: El desarrollo de un software a través de la metáfora del desarrollo de un columpio ......... 22 Ilustración 7: Flujo del trabajo en XP............................................................................................................................... 25 Ilustración 8: Ritmos de XP ............................................................................................................................................... 26 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] .................................................................................................................................... 27 Ilustración 10: Flujo de pasos del modelo pedagógico de Aprendizaje Cognitivo ........................................... 38 Ilustración 11: Áreas curriculares de la computación propuestas por CC2001................................................ 39 Ilustración 12: Niveles de cursos y estrategias de implementación ..................................................................... 40 Ilustración 13: Ambiente de trabajo del Software Studio......................................................................................... 50 Ilustración 14: Carrera de Ingeniería Civil en Computación y el contexto en donde se aplica el curso

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

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

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

Page 7: Un modelo empírico de enseñanza de las metodologías ágiles

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).............117 Ilustración 48: Plan de inicios de la segunda iteración ...........................................................................................124 Ilustración 49: Plan al finalizar el proyecto .................................................................................................................127 Ilustració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 ........................................................................135 Ilustración 51: Coach (a la izquierda) liderando el análisis del problema.......................................................138 Ilustración 52: Equipo presentando algunos avances al cliente ..........................................................................139 Ilustración 53: Papelógrafo con el plan obtenido al finalizar la primera iteración .......................................146 Ilustración 54: Plan final del proyecto ..........................................................................................................................150

Page 8: Un modelo empírico de enseñanza de las metodologías ágiles

8

ÍNDICE DE TABLAS

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

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

Page 9: Un modelo empírico de enseñanza de las metodologías ágiles

9

1. INTRODUCCIÓN Desde 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:

Page 10: Un modelo empírico de enseñanza de las metodologías ágiles

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

Page 11: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 12: Un modelo empírico de enseñanza de las metodologías ágiles

12

2. PLAN DE TRABAJO

2.1 Hipótesis de la Investigación Las 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ía El 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.

Page 13: Un modelo empírico de enseñanza de las metodologías ágiles

13

3. ANTECEDENTES

3.1 El problema de la productividad de la industria de software Desde 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.

Page 14: Un modelo empírico de enseñanza de las metodologías ágiles

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 - cuya promesa consiste en generar software funcional a partir de modelos de alto nivel.

Uno de los enfoques más destacados de esta tendencia surge a mediados de los ’90 el “Rational Unified Process” (RUP)2, 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:

requiere de una elevada curva de aprendizaje de los formalismos,

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

Nunca 45%

Raramente 19%

Algunas veces 16%

Frecuentemente 13%

Siempre 7%

Uso de Funcionalidades de Software

Page 15: Un modelo empírico de enseñanza de las metodologías ágiles

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]

Page 16: Un modelo empírico de enseñanza de las metodologías ágiles

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 desde 1996, hasta que en 1999 se publicó el libro “Extreme Programming Explained” [6], 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. 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 Tabla 3.

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)

Page 17: Un modelo empírico de enseñanza de las metodologías ágiles

17

3.2.1 Bases conceptuales de las MA

Las 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) para referirse a todo esfuerzo por llevar un nuevo producto al mercado [52]. 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

Anarq

u

Anarq

uííaa

Alta Certeza Baja Certeza

Alt

o A

cu

erd

oB

ajo

Acu

erd

o

Tecnología

Re

qu

eri

mie

nto

s

Page 18: Un modelo empírico de enseñanza de las metodologías ágiles

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 valor

Tal 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

funcio

nalidades

tiempo

funcio

nalidades

tiempo

funcio

nalidades

tiempo

funcio

nalidades

tiempo

funcio

nalidades

tiempo

funcio

nalidades

tiempo

funcio

nalidades

tiempo

funcio

nalidades

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

Page 19: Un modelo empírico de enseñanza de las metodologías ágiles

19

La revisión a la curva del cambio y la estrategia del timeboxing con contratos de alcance variable

Para 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:

Tiempo

Co

sto

de

l C

am

bio

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

Tiempo

Co

sto

de

l C

am

bio

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

Tiempo

Co

sto

de

l C

am

bio

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

Tiempo

Co

sto

de

l C

am

bio

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

Tiempo

Co

sto

de

l C

am

bio

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

Page 20: Un modelo empírico de enseñanza de las metodologías ágiles

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].

Page 21: Un modelo empírico de enseñanza de las metodologías ágiles

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

cu

erd

an

?

?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?

Page 22: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 23: Un modelo empírico de enseñanza de las metodologías ágiles

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:

Page 24: Un modelo empírico de enseñanza de las metodologías ágiles

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 y cada 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 informada acerca del camino a seguir.

Viajar con equipaje: poco, simple y valioso

Evitar la dependencia de herramientas costosas, sino contar con un kit mí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 como JUnit, pero evita la dependenciar de grandes y costosas suites de desarrollo para 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ápido y continuo de todos, tanto del proceso de desarrollo, como del problema de negocio 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 es negociable

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. Esta retroalimentació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 con experimentos pequeños. Es decir, no hay que adivinar, sino actuar a partir de la 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

Page 25: Un modelo empírico de enseñanza de las metodologías ágiles

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 XP

El 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

Page 26: Un modelo empírico de enseñanza de las metodologías ágiles

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ón

iteración

estimar historias de

usuario

estimar historias de

usuario

dividir historias en

tareas

dividir historias en

tareas

estimar 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ón

tareatarea

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

seleccionar historias

clientecliente

desarrollodesarrolloequipo

completo

equipo completo escribir

test

escribir test

Escribir código que cumple test

Escribir código que cumple test

refactorizarsin piedad

refactorizarsin piedad

integrar código

integrar código

ítem por hacerítem por hacer

código de colorescódigo de colores

completariteraciones

completariteraciones

entregar software

entregar software

entregable pequeñoentregable pequeño

plan entregaplan entrega

planning gameplanning game iteración

iteración

estimar historias de

usuario

estimar historias de

usuario

dividir historias en

tareas

dividir historias en

tareas

estimar 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ón

tareatarea

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

seleccionar historias

clientecliente

desarrollodesarrolloequipo

completo

equipo completo escribir

test

escribir test

Escribir código que cumple test

Escribir código que cumple test

refactorizarsin piedad

refactorizarsin piedad

integrar código

integrar código

ítem por hacerítem por hacer

código de colorescódigo de colores

completariteraciones

completariteraciones

entregar software

entregar software

Page 27: Un modelo empírico de enseñanza de las metodologías ágiles

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 XP

En 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

Page 28: Un modelo empírico de enseñanza de las metodologías ágiles

28

3.2.3 El problema de la adopción de XP en la industria

Al 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 establishment

XP 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

Page 29: Un modelo empírico de enseñanza de las metodologías ágiles

29

Aspectos Tradicional XP

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.

Aspectos Tradicional XP

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

Page 30: Un modelo empírico de enseñanza de las metodologías ágiles

30

Desafío intrínseco: Apropiación del marco conceptual y transferencia de prácticas de XP

En 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íos

Al 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

Page 31: Un modelo empírico de enseñanza de las metodologías ágiles

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 XP

En “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.

Page 32: Un modelo empírico de enseñanza de las metodologías ágiles

32

Herramientas para difundir y adoptar XP

La primera herramienta que se usó para difundir XP y sus principios fue el primer Wiki-Wiki creado por Ward Cunnigham16, 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:

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

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 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:

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

XP Simulation & Games19: 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/

Page 33: Un modelo empírico de enseñanza de las metodologías ágiles

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 aprendizaje

El 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 entendimiento

El 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

Page 34: Un modelo empírico de enseñanza de las metodologías ágiles

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 aprendizaje

La 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

Page 35: Un modelo empírico de enseñanza de las metodologías ágiles

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 instruccional

Dado 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, siguiendo esta ruta:

A partir de los conocimientos previos de sus aprendices,

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

Page 36: Un modelo empírico de enseñanza de las metodologías ágiles

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:

Page 37: Un modelo empírico de enseñanza de las metodologías ágiles

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:

Page 38: Un modelo empírico de enseñanza de las metodologías ágiles

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

Profesor Aprendices

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.

practicar habilidad resolviendo el desafío

APRENDIZAJE COGNITIVOFlujo del modelo pedagógico

Page 39: Un modelo empírico de enseñanza de las metodologías ágiles

39

3.4 Educación de la Ingeniería de Software En 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.

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

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 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

ACMIEEE Computer Society

Information Systems

ACMAssociation for Information

Systems (AIS)Association of InformationTechnology Professionals

(AITP)IEEE Computer Society

Computer Engineering

Computing Curriculum -Computer EngineeringSteering Committee

ACMIEEE Computer Society

Software Engineering

Computing Curriculum -Software EngineeringSteering Committee

ACMIEEE Computer SocietySeveral other societies

Information Technology

Computing Curriculum -Information Technology

Steering Committee

ACMIEEE Computer Society

Page 40: Un modelo empírico de enseñanza de las metodologías ágiles

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 Software

La 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

Page 41: Un modelo empírico de enseñanza de las metodologías ágiles

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

Page 42: Un modelo empírico de enseñanza de las metodologías ágiles

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 software

En 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.

Page 43: Un modelo empírico de enseñanza de las metodologías ágiles

43

Entrega de conocimientos acerca de principios y herramientas para el desarrollo de software

Este 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 profesional

En este modelo, relacionado con la cognición situada24, 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.

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 [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ón

Aquí 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

Page 44: Un modelo empírico de enseñanza de las metodologías ágiles

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 software

El 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 .

Page 45: Un modelo empírico de enseñanza de las metodologías ágiles

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

Page 46: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 47: Un modelo empírico de enseñanza de las metodologías ágiles

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 carrera

La 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. Otros, por su parte, abogan por introducir tempranamente XP en el currículo [26][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 proyectos

Existe 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

Page 48: Un modelo empírico de enseñanza de las metodologías ágiles

48

Herramientas evaluativas

Uno 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 obtenidos

A 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 XP

A 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

Page 49: Un modelo empírico de enseñanza de las metodologías ágiles

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 XP

En 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 Studio

La compañía de software Role Model Software26 ha implementando un modelo alternativo para formar desarrolladores de software denominado “Software Studio” [53] que recuerda en su estructura al taller de oficios medieval, en donde desarrolladores novicios aprenden de maestros desarrolladores27. 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

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

Page 50: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 51: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 52: Un modelo empírico de enseñanza de las metodologías ágiles

52

4. PROPUESTAS En 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

Page 53: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 54: Un modelo empírico de enseñanza de las metodologías ágiles

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 CC62V

El 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.

Page 55: Un modelo empírico de enseñanza de las metodologías ágiles

55

4.1.2 Contexto del curso

El 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

Page 56: Un modelo empírico de enseñanza de las metodologías ágiles

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 alumnos

A 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

Page 57: Un modelo empírico de enseñanza de las metodologías ágiles

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 CC62V

El 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 XP

Como 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

Page 58: Un modelo empírico de enseñanza de las metodologías ágiles

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 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.

Planificación del 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

Page 59: Un modelo empírico de enseñanza de las metodologías ágiles

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 reales

Una 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ón

La 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.

Page 60: Un modelo empírico de enseñanza de las metodologías ágiles

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 docente

Tal 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ácticasPrin

cipiosValores

Conocim

iento

del

Pro

blem

a

Desarrollo

Tec

nolo

gía

Page 61: Un modelo empírico de enseñanza de las metodologías ágiles

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 curso

El 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.

Se

ma

na

Actividades

En horas del taller Fuera del taller

Te

óri

co

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

Page 62: Un modelo empírico de enseñanza de las metodologías ágiles

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

Page 63: Un modelo empírico de enseñanza de las metodologías ágiles

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ón continua

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

Page 64: Un modelo empírico de enseñanza de las metodologías ágiles

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 Desarrollador

Desea

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

Page 65: Un modelo empírico de enseñanza de las metodologías ágiles

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

Page 66: Un modelo empírico de enseñanza de las metodologías ágiles

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 NegocioCliente

Proyecto de Software

Page 67: Un modelo empírico de enseñanza de las metodologías ágiles

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

Page 68: Un modelo empírico de enseñanza de las metodologías ágiles

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

Plan

nin

g Gam

e (Itera

ción

)

Pla

nn

ing

Ga

me (En

trega

ble)

Ciclos de un proyecto XP

Ciclo de Gestión del Proyecto Orientada al Valor

Ciclo de Gestión del Desarrollo

Ciclo de Programación de calidad

Page 69: Un modelo empírico de enseñanza de las metodologías ágiles

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

Ge

stió

n d

el D

esa

rro

llo

en

Eq

uip

o

Pro

gra

ma

ció

n e

n E

qu

ipo

Pro

gra

ma

ció

n In

cre

me

nta

l d

e C

ali

da

d

Integración continua

Estándares de Código

Propiedad Colectiva de Código

Programación de a pares

(+ 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

Ge

stió

n d

el P

roy

ect

o

ori

en

tad

a a

l va

lor Planning Game

Tests de Aceptación del Cliente

Entregas pequeñas

Cliente en terreno

(Un sólo equipo)

Desarrollo

Definición Validación

Page 70: Un modelo empírico de enseñanza de las metodologías ágiles

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 GameGame

SI

Page 71: Un modelo empírico de enseñanza de las metodologías ágiles

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

Page 72: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 73: Un modelo empírico de enseñanza de las metodologías ágiles

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 evaluativo

Las razones que han llevado a tomar la decisión de definir un modelo evaluativo alternativo son las siguientes:

Distintos objetivos de la evaluación

El 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

Page 74: Un modelo empírico de enseñanza de las metodologías ágiles

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 experiencia

Para 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 se encuentran en dos extremos:

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

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”

Page 75: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 76: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 77: Un modelo empírico de enseñanza de las metodologías ágiles

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 experiencia

A 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)

Page 78: Un modelo empírico de enseñanza de las metodologías ágiles

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

Con errores de comprensión

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

Page 79: Un modelo empírico de enseñanza de las metodologías ágiles

79

5. EXPERIENCIA REALIZADA: SEMESTRE PRIMAVERA 2005

DEL 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 Experiencia A continuación se caracterizará la experiencia realizada al alero de esta investigación.

5.1.1 Innovaciones aplicadas al diseño instruccional

Tal 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 Actividades

El 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.

Page 80: Un modelo empírico de enseñanza de las metodologías ágiles

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

No

viem

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 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).

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

Page 81: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 82: Un modelo empírico de enseñanza de las metodologías ágiles

82

5.2 Análisis de Resultados de la experiencia En 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 previos

En 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 taller

Como 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

mn

o

Clie

nte

In S

itu

Pla

nn

ing

Gam

e

Test

s d

e A

cep

taci

ón

Entr

egab

les

Peq

ueñ

os

Rit

mo

So

sten

ido

Lid

eraz

go M

oti

vad

or

Ret

roal

imen

taci

ón

de

avan

ce

Esp

acio

de

Trab

ajo

Info

rmat

ivo

Stan

d U

p M

eeti

ng

Está

nd

ares

de

dig

o

Pro

gram

ació

n d

e a

Par

es

Pro

pie

dad

Co

lect

iva

de

dig

o

Des

arro

llo G

uia

do

po

r Te

sts

Dis

eño

Sim

ple

Inte

grac

ión

Co

nti

nu

a

Ref

acto

riza

ció

n

Clie

nte

In S

itu

Pla

nn

ing

Gam

e

Test

s d

e A

cep

taci

ón

Entr

egab

les

Peq

ueñ

os

Rit

mo

So

sten

ido

Lid

eraz

go M

oti

vad

or

Ret

roal

imen

taci

ón

de

avan

ce

Esp

acio

de

Trab

ajo

Info

rmat

ivo

Stan

d U

p M

eeti

ng

Está

nd

ares

de

dig

o

Pro

gram

ació

n d

e a

Par

es

Pro

pie

dad

Co

lect

iva

de

dig

o

Des

arro

llo G

uia

do

po

r Te

sts

Dis

eño

Sim

ple

Inte

grac

ión

Co

nti

nu

a

Ref

acto

riza

ció

n

Mapache FBFSCTAV

XMLSync BBTHCHCMCSMV

Programación

en Equipo

Programación

de Calidad

Ciclo 1 Ciclo 2

Gestión de

Proyecto

Orientada al

Valor

Gestión del

Desarrollo en

Equipo

Programación en

Equipo

Programación

de Calidad

Gestión de

Proyecto

Orientada al

Valor

Gestión del

Desarrollo en

Equipo

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 83: Un modelo empírico de enseñanza de las metodologías ágiles

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 reflejados

Es 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 destacada

La 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ácticas

Los 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

Page 84: Un modelo empírico de enseñanza de las metodologías ágiles

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 entendidos

Algunas 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”.

Page 85: Un modelo empírico de enseñanza de las metodologías ágiles

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 curso

A 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ácticas

En 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

mn

o

Clie

nte

In S

itu

Pla

nn

ing

Gam

e

Test

s d

e A

cep

taci

ón

Entr

egab

les

Peq

ueñ

os

Rit

mo

So

sten

ido

Lid

eraz

go M

oti

vad

or

Ret

roal

imen

taci

ón

de

avan

ce

Esp

acio

de

Trab

ajo

Info

rmat

ivo

Stan

d U

p M

eeti

ng

Está

nd

ares

de

dig

o

Pro

gram

ació

n d

e a

Par

es

Pro

pie

dad

Co

lect

iva

de

dig

o

Des

arro

llo G

uia

do

po

r Te

sts

Dis

eño

Sim

ple

Inte

grac

ión

Co

nti

nu

a

Ref

acto

riza

ció

n

Clie

nte

In S

itu

Pla

nn

ing

Gam

e

Test

s d

e A

cep

taci

ón

Entr

egab

les

Peq

ueñ

os

Rit

mo

So

sten

ido

Lid

eraz

go M

oti

vad

or

Ret

roal

imen

taci

ón

de

avan

ce

Esp

acio

de

Trab

ajo

Info

rmat

ivo

Stan

d U

p M

eeti

ng

Está

nd

ares

de

dig

o

Pro

gram

ació

n d

e a

Par

es

Pro

pie

dad

Co

lect

iva

de

dig

o

Des

arro

llo G

uia

do

po

r Te

sts

Dis

eño

Sim

ple

Inte

grac

ión

Co

nti

nu

a

Ref

acto

riza

ció

n

Mapache FBFSCTAV

XMLSync BBTHCHCMCSMV

Programación

en Equipo

Programación

de Calidad

Ciclo 1 Ciclo 2

Gestión de

Proyecto

Orientada al

Valor

Gestión del

Desarrollo en

Equipo

Programación en

Equipo

Programación

de Calidad

Gestión de

Proyecto

Orientada al

Valor

Gestión del

Desarrollo en

Equipo

Bien aplicado

Aplicado con dificultades

Mal aplicado

No aplicado / No responde

Con errores de comprensión

Simbología Aplicación

Page 86: Un modelo empírico de enseñanza de las metodologías ágiles

86

Funcionamiento de la gestión ágil

Con 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

No

viem

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.

Page 87: Un modelo empírico de enseñanza de las metodologías ágiles

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 clientes

La 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 Mapache

En 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

Page 88: Un modelo empírico de enseñanza de las metodologías ágiles

88

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

Opinión del cliente del proyecto XMLSync

En 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 Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 89: Un modelo empírico de enseñanza de las metodologías ágiles

89

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

5.2.5 Encuesta de impacto post curso

Unos 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 Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 90: Un modelo empírico de enseñanza de las metodologías ágiles

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

ect

os

Aspectos distintivos del curso

Total

Page 91: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 92: Un modelo empírico de enseñanza de las metodologías ágiles

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

Espacio de Trabajo Informativo

Retroalimentación de avance

Ritmo sostenido

Stand Up Meeting

Desarrollo Guiado por Tests

Diseño Simple

Refactorización

Estándares de Código

Programación de a Pares

Propiedad Colectiva de Código

Brainstormings

mini tareas

planificacion y seguimiento

Reuniones de evaluación

Ge

stió

n d

eP

roye

cto

Ori

enta

da

alV

alo

r

Ge

stió

n d

el

Des

arro

llo e

nE

qu

ipo

Pro

gra

mac

ión

de

Ca

lidad

Pro

gra

mac

ión

en

Eq

uip

oO

tra

s

Nº Menciones

Prá

ctic

a

Rememoración de prácticas

Total

Page 93: Un modelo empírico de enseñanza de las metodologías ágiles

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 situ

Desarrollo Guiado por Tests

Espacio de Trabajo Informativo

Programación de a Pares

Propiedad Colectiva de Código

Refactorización

Ritmo sostenido

Stand Up Meeting

Brainstormings

Cliente in situ

Desarrollo Guiado por Tests

Diseño Simple

Espacio de Trabajo Informativo

Estándares de Código

mini tareas

planificacion y seguimiento

Planning Game

Programación de a Pares

Propiedad Colectiva de Código

Refactorización

Retroalimentación de avance

Reuniones de evaluación

Stand Up Meeting

Tests de Aceptación

Map

ach

eX

MLS

ync

N º de menciones

Gru

po

/ P

ráct

ica

Rememoración de Prácticas

Total

Nunca 10%

Parcialmente

80%

No responde

10%

Aplicación de XP después del curso

Page 94: Un modelo empírico de enseñanza de las metodologías ágiles

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

Espacio de Trabajo Informativo

Retroalimentación de avance

Stand Up Meeting

Desarrollo Guiado por Tests

Diseño Simple

Refactorización

Programación de a Pares

compartir conocimiento

Desarrollo con Tests a posteriori

Ge

stió

n d

eP

roye

cto

Ori

en

tad

a a

lV

alo

r

Ge

stió

n d

elD

esa

rro

llo e

nE

qu

ipo

Pro

gra

mac

ión

de

Cal

ida

d

Pro

gra

mac

ión

en

Eq

ui

po

Otr

as

Nº de menciones

Cic

lo d

e X

P /

Prá

ctic

a a

plic

ad

a

Aplicación de Prácticas Post-Curso

Total

Page 95: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 96: Un modelo empírico de enseñanza de las metodologías ágiles

96

6. RESULTADOS ADICIONALES Ademá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 curso A 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, el cual servirá de base explicativa para los futuros alumnos de este curso.

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

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

Page 97: Un modelo empírico de enseñanza de las metodologías ágiles

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 trabajar

Una 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 equipos

En 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

Page 98: Un modelo empírico de enseñanza de las metodologías ágiles

98

restricciones actuales de la carrera37, 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.

6.1.6 Establecer una base temprana de código funcional

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. Veamos algunos ejemplos:

para el planning game se uso el juego “extreme hour”, con muy buenos resultados.

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 aplicado La 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”

Page 99: Un modelo empírico de enseñanza de las metodologías ágiles

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

Ciclo de Gestión del Proyecto Orientada al Valor

Ciclo de Gestión del Desarrollo

Ciclo de Programación de calidad

Page 100: Un modelo empírico de enseñanza de las metodologías ágiles

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

Profesor Aprendices

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.

practicar habilidad resolviendo el desafío

APRENDIZAJE COGNITIVO Y MODELO

PEDAGÓGICO DEL CURSO CC62VFlujo del modelo pedagógico

Page 101: Un modelo empírico de enseñanza de las metodologías ágiles

101

6.2.1 Propuesta de prácticas pedagógicas ágiles

En 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 XP

Para 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 alumnos

Los 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 trabajar

XP 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.

Ge

stió

n p

ed

ag

óg

ica

de

los

Ap

ren

diz

aje

s

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 d

el P

roye

cto

o

rie

nta

da

al v

alo

r

Ges

tió

n d

el D

esar

rollo

en

Eq

uip

o

Pro

gra

ma

ció

n e

n E

qu

ipo

Pro

gra

ma

ció

n In

cre

men

tal

de

Ca

lid

ad

Planning Game

Tests de Aceptación del Cliente

Entregas pequeñas

Integración continua

Estilo Común de Código

Propiedad Colectiva de Código

Programación de a pares

(+ Mantener el equipo rotando)

Espacio de Trabajo Informativo

Diseño Just In Time

Refactorización

Desarrollo Guiado por Tests

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

Planning Game de la Iteración

Definición Validación

Page 102: Un modelo empírico de enseñanza de las metodologías ágiles

102

Desarrollar en las horas de clases, estudiar e investigar en la casa

Esta 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 aprendizajes

Ante 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 destrezas

Las 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.

Page 103: Un modelo empírico de enseñanza de las metodologías ágiles

103

7. CONCLUSIONES Tal 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:

Page 104: Un modelo empírico de enseñanza de las metodologías ágiles

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:

Page 105: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 106: Un modelo empírico de enseñanza de las metodologías ágiles

106

8. TRABAJO FUTURO

8.1 Aplicación del diseño instruccional (o elementos de éste) en má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

Page 107: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 108: Un modelo empírico de enseñanza de las metodologías ágiles

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

Page 109: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 110: Un modelo empírico de enseñanza de las metodologías ágiles

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.

Page 111: Un modelo empírico de enseñanza de las metodologías ágiles

111

10. ANEXOS

10.1Descripción Detallada de la Experiencia

10.1.1 Fase teórica

El curso se inició con la clase teórica en donde se explican los fundamentos de las metodologías ágiles y de XP, para finalizar realizando el taller práctico “eXtreme Hour”, en donde los alumnos desarrollan el dibujo de una máquina inventada jugando a ser “clientes” y “desarrolladores”, y pudieron experimentar con el modelo de negociación del Planning Game. Debido a que a esta clase sólo asistió la mitad de los alumnos, este taller se repitió la semana siguiente. Luego, se presentaron las prácticas de XP que debían ser expuestas, y los alumnos asistentes eligieron aquellas que más les interesaban. Las presentaciones correspondientes al resto inasistente del curso fueron coordinadas durante la semana por correo electrónico.

Ilustración 39: "Cómo funciona XP"

Ilustración 40: Reglas para clientes y desarrolladores

Ilustración 41: eXtreme Hour – “Equipo de desarrollo” frente a los “clientes”

Ilustración 42: eXtreme Hour – Los “clientes" inspeccionando el trabajo realizado

Page 112: Un modelo empírico de enseñanza de las metodologías ágiles

112

Ilustración 43: eXtreme Hour – Tarjetas con las "Historias de usuario" que describen las

características de la máquina ficticia.

Ilustración 44: eXtreme Hour – Máquina Ficticia: "Producto" generado en el taller

Conocimientos previos de los alumnos

Una de las preguntas iniciales a los alumnos fue “qué sabían de las metodologías ágiles”, y se obtuvo lo siguiente De los 11 alumnos del curso:

6 alumnos no tenían ningún conocimiento previo sobre XP ni sus prácticas,

4 conocían la “programación de a pares”, pues lo habían aplicado en un curso anterior, y

sólo uno conocía algunas prácticas más (en particular el “planning game”) debido a una práctica profesional realizada.

Un descubrimiento interesante es que los que sólo conocían el “pair programming” lo confundían con “extreme programming”, mal entendido que también ha sido observado en algunos reportes recopilados en esta investigación (ver [58]).

Sobre las Charlas Teóricas realizadas

Las charlas de los alumnos fueron distribuidas siguiendo la organización presentada en el organizador de prácticas de XP (Ilustración 17, página 63). Además, se trabajó organizando las charlas de a pares, para mejorar el trabajo realizado. La lista de charlas fue la siguiente:

Cliente In Situ

Entorno Informativo

Programación de a pares

Refactorización

Ritmo Sostenible

Desarrollo Guiado por Tests / Tests de Aceptación del Cliente

Propiedad Colectiva de Código / Estándares de Código

Diseño Simple

Page 113: Un modelo empírico de enseñanza de las metodologías ágiles

113

Como es posible observar, la práctica “Metáfora” no fue considerada, dado que la experiencia del curso ha demostrado que esta es la menos clara de las prácticas propuestas en el libro original de XP. La descripción del modelo de gestión de equipo, y los roles de “Coach” y “Tracker” ya habían sido abordados en la introducción teórica, por lo que tampoco fueron considerados en este listado de charlas.

En este ciclo de charlas, se innovó agregando una descripción de las herramientas automatizadas que han surgido para soportar los Tests de Aceptación, en particular FIT y FITnesse39.

Ilustración 45: Charla sobre Desarrollo Guiado por Tests dada por un alumno

Las charlas tuvieron un nivel aceptable, centradas principalmente en la definición de las prácticas con algunos pocos ejemplos prácticos. La excepción fue la charla de refactorización, que mostró muy poca preparación, lo que se explica dado que el alumno a cargo renunció al curso por sobrecarga laboral. Después de cada charla, cada alumno debió preparar un reporte con su opinión acerca de las presentaciones de sus compañeros, en la cual debían opinar acerca de la práctica expuesta y evaluar su aplicabilidad. Estos reportes serían más tarde la base de los ensayos sobre XP y de evaluación del proyecto que se les solicitarían a los alumnos a la mitad del semestre.

10.1.2 Fase práctica

Para este curso se contó con el concurso de 2 proyectos y sus respectivos clientes: un profesor de la misma carrera y un estudiante de doctorado, ambos trabajando en sistemas para dispositivos móviles.

Los 11 alumnos originales fueron divididos en grupos de 5 y 6 personas. El grupo más pequeño quedó aún más reducido (4 personas) con la deserción ya comentada, pero ambos grupos decidieron mantenerse sin cambios posteriores.

39 Ver http://fit.c2.com/

Page 114: Un modelo empírico de enseñanza de las metodologías ágiles

114

Proyecto Mobile WebServer “Mapache”

Descripción del Proyecto

Este proyecto nace a partir de la existencia de un servidor web de código abierto40 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).

Conocimientos previos de los alumnos

Los alumnos poseían un conocimiento básico del protocolo HTTP, pero casi ningún conocimiento sobre SOAP, el estándar sobre el que se construyen protocolos de interacción de servicios Web. Tampoco tenían conocimiento previo ni de la plataforma .NET Compact Framework, ni del ambiente de desarrollo Visual Studio (en ninguna de sus versiones), ni del código fuente del sistema a mejorar.

Desarrollo del Proyecto

Mes # Plan Mapache

Viernes Viernes Simbología

0

29 29 Introducción al curso

Ago

sto

1

5 5 Presentaciones Iniciales

2

12 12 Primer Ciclo

3

19 19 Segundo Ciclo

4

26 26 Tercer Ciclo

5

2 2 Feriados

Sep

tiem

bre

6

9 9

16 16

7

23 23

8

30 30

Oct

ub

re

9

7 7

14 14

10

21 21

11

28 28

12

4 4

No

vie

mb

re

13

11 11

14

18 18

Tabla 29: Comparación entre el plan original y lo realmente sucedido en el proyecto Mapache

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

Page 115: Un modelo empírico de enseñanza de las metodologías ágiles

115

Este proyecto fue planteado por el profesor para ser realizado en tres iteraciones de 4 sesiones cada una, pero la primera iteración terminó alargándose 3 semanas adicionales, tiempo que se explica porque el tiempo original era arbitrario, y no correspondía a la realidad del desafío involucrado. Posteriormente el equipo definió con el cliente dos iteraciones cortas, de 2 y 3 semanas respectivamente.

Primera Iteración, semanas 1 a 9

Gestión Orientada al Valor

En la Ilustración 46 presentamos el plan inicial del proyecto:

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

Page 116: Un modelo empírico de enseñanza de las metodologías ágiles

116

El plan conseguido en el Planning Game definió un listado de tareas agrupadas en una matriz dividida en tópicos (columnas) y entregables (filas), que se presenta en la Tabla 30:

Instalación Investigación Crear Tests Implementar

MicroServer Validación

Entregable Responder WebService con datos básicos

Ambiente de desarrollo que permitiese ejecutar el servidor web

Ponerse al día de temas como Web Services y SOAP,

Los tests validarían las funcionalidades básicas esperadas del servidor web, en particular implementar los métodos GET y POST, y ser capaz de responder un requerimiento SOAP

Añadir soporte para servicios. Corregir defectos como manejo de rutas y de espacios de nombres

Implementar aplicación cliente “calculadora”, usando WebServices

Validar cálculos de la aplicación

Implementar servicio calculadora

Implementar aplicación Winforms de calculadora

Implementar Servicio Web para acceder archivos

Archivos adjuntos (Attachments) en SOAP

Validar envío de archivos

Implementar Attachments

Implementar aplicación Winforms para manejar attachments

Tabla 30: Matriz del Plan Proyecto Mapache Ciclo 1

Esta planificación inicialmente no incluyó estimaciones de tiempo para las tareas. El argumento de los alumnos fue el siguiente: “no sabemos cómo vamos a estimar”. Se les sugirió entonces dedicar las horas de trabajo personal para investigar y así poder lo antes posible realizar estimaciones de tiempos.

En lo que se refiere al involucramiento del cliente, como éste era un avezado programador, no tenia reparos en involucrarse en el desarrollo con los alumnos41, tal como se ve en la Ilustración 47, pero los alumnos tendían a no acercarse a él y trataban de resolver las dudas en solitario –con la ocasional excepción del coach del equipo, con quien estableció una relación preferente-. Al consultárseles, ellos indicaron que creían que tenían que “aprender WebServices sin pedir ayuda”, pero se les aclaró que este no era el objetivo del curso, sino que pudiesen generar un software con el mayor valor agregado en el menor tiempo, para lo cual aprovechar el know-how del cliente sería fundamental. A medida que avanzó la iteración el trabajo se realizó codo a codo con el cliente. De hecho, el primer entregable se obtuvo desde un trabajo en conjunto, en donde se logró que todos los tests de métodos GET y SOAP de MicroServer se ejecutaran correctamente y se bajó la prioridad de los tests del método POST, priorizando implementar servicios web. Es importante hacer notar que el cliente tuvo que ausentarse una sesión, pero esto no retrasó el desarrollo del proyecto. La presentación del

41 Lo cual fue visto como negativo por el cliente del otro grupo, quien consideraba que el trabajo de desarrollo era tarea de los

alumnos exclusivamente.

Page 117: Un modelo empírico de enseñanza de las metodologías ágiles

117

software final del ciclo se delegó a un alumno que faltó a la última sesión para ser realizado durante la semana, antes del ciclo siguiente.

Ilustración 47: Alumnos colaborando con el cliente (sentado frente al computador del medio)

Evaluación de aprendizajes

Los alumnos al final de esta iteración entregaron un ensayo en donde definían XP y evaluaban su aplicación en el proyecto. A continuación presentamos el análisis de estos trabajos42:

Al momento de evaluar el grado la calidad de aplicación de las prácticas observamos lo siguiente

42 Es importante hacer notar que un alumno (AV) no entregó parte de los trabajos, lo que explica las lagunas en los datos.

Page 118: Un modelo empírico de enseñanza de las metodologías ágiles

118

Los conceptos mal entendidos están en directa relación con los pre-conceptos de los alumnos, derivados del modelo de cascada. Por ejemplo, se consideran como naturales (y casi inevitables) los atrasos y el sobretiempo, que las pruebas son algo a definir al final del proyecto, o se adjudica al planning game el “defecto” de que al comienzo del proyecto exista incertidumbre en los requerimientos.

Podemos destacar que la práctica “cliente in situ” es la más recordada y la mejor entendida, quizás debido a la estrecha relación establecida con el cliente.

Al momento de evaluar la aplicación de las prácticas, los alumnos indicaron lo siguiente:

Los alumnos indican que el planning game se vio afectado por la inexperiencia del grupo con respecto al problema a resolver, lo que fue mejorando a medida que se conocía más del

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 119: Un modelo empírico de enseñanza de las metodologías ágiles

119

proyecto, adquiriendo la capacidad de estimar las tareas derivadas de los requerimientos del cliente.

La práctica test de aceptación fue mal evaluada por un alumno, pero como presenta errores de concepto no se considera su opinión como válida.

Con respecto al cliente in situ, a pesar de ser considerada “muy importante”, algunos alumnos indican que el cambio en el rol del cliente, el cual incluso podía apoyar directamente en el desarrollo, fue difícil de interiorizar, dada la concepción tradicional de cliente.

Por su parte, la práctica entregables pequeños es la que fue mejor evaluada en su aplicación.

Evaluación del cliente

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.

Gestión del Desarrollo en Equipo

En las sesiones iniciales, los alumnos comenzaban a trabajar creyendo estar sincronizados con el cliente y, por ende, tenían la tendencia a obviar el stand up meeting, o no incluir al cliente en esta actividad. Al obligárseles a revisar la planificación en conjunto con el cliente, se les hizo notorio que no estaban realmente de acuerdo, y que no tenían real claridad acerca del avance logrado en el plan. Ante la necesidad de tener un plan comprendido por todos, se redistribuyeron las tareas sobre el papelógrafo del plan de tal manera de poder darle una visibilidad mayor, eliminando las tareas ya realizadas y usando ahora una distribución vertical que permitiese agregar post-it's con el detalle de las tareas a realizar. Además, se comenzó a detallar en las tareas el tiempo estimado de logro (en horas).

Evaluación de aprendizajes

Del análisis de los trabajos de los alumnos se obtiene la siguiente evaluación de la comprensión de las prácticas de gestión de desarrollo en equipo:

Evaluación Cliente Alumno

Eje Concepto Ciclo FB FS CT AV

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

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

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

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

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

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

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

Evaluador Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 120: Un modelo empírico de enseñanza de las metodologías ágiles

120

Observamos que aproximadamente la mitad del grupo recuerda estas prácticas, lo que no deja de ser llamativo dada la aplicación intensiva de ellas. Los que las recuerdan eso sí, no tienen errores de comprensión. Caso especial es el del coach, quien es el único que habla sobre ese rol en el grupo, lo que indica un bajo impacto en la memoria de sus compañeros. Esto puede ser explicado porque el coach comete el error conceptual de que, por liderar el grupo, debía trabajar más aislado y de preferencia negociando con el cliente. Además, con respecto al “ritmo sostenido” cree que no se han ocupado horas extra sólo porque no ha habido presión, y no por un principio de mantener la productividad. Adicionalmente, llama la atención que él sea justamente quien olvide el resto de las prácticas de trabajo en equipo, lo que puede indicar una tendencia a trabajar en solitario.

Con respecto a la evaluación de la aplicación de las prácticas, en su mayoría fueron bien evaluada, a excepción de algunas dificultades indicadas por un alumno en específico (CT), quien indica dificultades al estimar que afectan el ritmo sostenido, leer el plan generado en el espacio de trabajo informativo y que las stand up meetings no han sido lo concisas que debieran ser.

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 121: Un modelo empírico de enseñanza de las metodologías ágiles

121

Evaluación interna de los alumnos

Los dos alumnos mejor co-evaluados son el coach (FB) y el alumno AV. El punto más deficitario lo presentan los alumnos FS y CT en el auto-perfeccionamiento, el cual se evalúa que sucede sólo “a veces”.

Ciclo de Programación Incremental de Calidad

El trabajo se realizó en equipos portátiles facilitados por la facultad sólo para las horas de clase, por lo cual se debió invertir una sesión casi completa en la instalación del ambiente de desarrollo. Es importante hacer notar que a veces los equipos entregados para una sesión no

Co-Evaluación Alumno

Eje Concepto Ciclo FB FS CT AV

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

Proactividad para el éxito del proyecto 1 83% 75% 75% 83%

Cliente Actitud de diálogo : con el cliente 1 92% 75% 58% 92%

Equipo Actitud de diálogo : con el equipo 1 92% 75% 92% 100%

Actitud positiva frente a las críticas 1 100% 75% 92% 92%

Autoperfeccionamiento 1 67% 50% 50% 92%

Disposición a apoyar a los otros en sus labores 1 100% 83% 83% 92%

Disposición a recibir apoyo del resto del equipo 1 92% 58% 83% 75%

Evaluador Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 122: Un modelo empírico de enseñanza de las metodologías ágiles

122

eran los mismos de las sesiones anteriores, por lo que había que reconfigurarlos, con la consiguiente pérdida de tiempo y de ritmo de trabajo.

Al poco andar, los alumnos descubrieron que el MicroServidor sobre el que trabajaban no estaba en el nivel de madurez esperado: cuando aplicaron los tests desarrollados, y no funcionaron, creyeron que era problema de ellos, pero al final se descubrió que el problema recaía en el código original. Esto fue un éxito desde la perspectiva del Desarrollo Guiado por Tests.

Evaluación de aprendizajes

De los trabajos de los alumnos tenemos los siguientes resultados.

En el ámbito de las prácticas de programación en equipo, la práctica que menos se entendió fue estándares de código, porque los alumnos en vez de entender que debían generar código programado de manera similar para facilitar su comprensión por el resto, fueron influenciados por la fuerza de la palabra “estándares”, que para ellos implicaba una formalización propia de reglas de codificación que no siempre es necesaria, aún más en este caso en el que se siguió implícitamente el estilo de código de la aplicación original.

Es importante destacar que el único que plantea problemas de comprensión con la programación a pares es el coach, quien afirma que programando solo avanza más rápido. No entiende que no sólo se trata de programar, sino de que el conocimiento fluya por el equipo

El ciclo de programación incremental de calidad por su parte es el que tiene más problemas de comprensión. Tanto en el caso de los estándares de código, y del diseño simple. Existe una confusión generalizada sobre sus significados, dado que términos tales como “diseño”, “simple” y “estándares” están demasiado teñidos con un significado previo. Por ejemplo, se cree que diseñar es en realidad re-diseñar totalmente, que acordar estándares requiere un proceso largo y tedioso, y que algo “simple” es algo “fácil”. La refactorización también es mal entendida, dado que es entendida como una reorganización global del código,

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 123: Un modelo empírico de enseñanza de las metodologías ágiles

123

que no es posible dada la envergadura del código legado. En ambos casos se ignora el principio de cambios incrementales propugnado por XP, y que por ende las prácticas antes mencionadas son totalmente aplicables de manera iterativa/evolutiva a código legado.

Al momento de evaluar la aplicación, muchas de las opiniones están invalidadas por los problemas de comprensión anteriormente explicados, como vemos en la tabla siguiente.

Los problemas de aplicación detectados son:

en el desarrollo guiado por tests no se consideró el valor de tener una batería de pruebas sino hasta el final del ciclo, y que el código legado no tenía su batería propia, por lo cual era difícil validar su integridad,

existió desincronización entre los desarrolladores al realizar programación de a pares,

En lo que se refiere a la aplicación positiva de las prácticas, destaca la opinión del coach, quien es el único capaz de reconocer el uso de la refactorización en el proyecto al reutilizar un módulo interno del servidor (método GET) para implementar su equivalente en SOAP.

Segunda y Tercera Iteración (semanas 10 y 11, y 12 a 14, respectivamente)

Gestión orientada al valor

Al comenzar el segundo ciclo, el plan tenía el siguiente aspecto:

Page 124: Un modelo empírico de enseñanza de las metodologías ágiles

124

Ilustración 48: Plan de inicios de la segunda iteración

Page 125: Un modelo empírico de enseñanza de las metodologías ágiles

125

Los objetivos relevantes de las iteraciones siguientes se resumen en la siguiente tabla: Instalación Investigación Crear Tests Implementar

MicroServer Validación

Entregable Implementar aplicación cliente “calculadora”, usando WebServices

Terminar de corregir defectos como manejo de rutas y de espacios de nombres. Implementar modelo simple de configuración

Validar cálculos de la aplicación

Implementar servicio calculadora

Implementar aplicación Winforms de calculadora

Implementar ServicioWeb para acceder archivos

Archivos adjuntos (Attachments) en SOAP

Validar envío de archivos

Uso de tipos complejos en los servicios Implementar Attachments

Implementar aplicación Winforms para manejar attachmnets

Tabla 31: Plan de la segunda parte del proyecto. En gris se destaca lo no implementado

La mini-iteración de dos semanas logró el objetivo de implementar la calculadora que probase los servicios web del micro-servidor. De ahí en adelante el trabajo consistió en abordar la segunda aplicación, la que finalmente se redujo a sólo el envío de tipos de datos complejos específicos, quedando la implementación de attachments fuera del alcance del proyecto.

Al finalizar el curso, los alumnos debieron realizar un nuevo ensayo evaluando la aplicación de XP globalmente en el proyecto. Ahora, como ayuda memoria, se les presentó un gráfico con todas las prácticas de XP, tal como aparece en el punto 10.2.4 “Pauta de Evaluación del Proyecto y Proyección a la Vida Profesional”.

Evaluación de aprendizajes

A continuación presentamos los resultados de aprendizaje y las evaluaciones de aplicación, comparando con el ciclo anterior. Veamos cómo estuvo el aprendizaje y la aplicación de prácticas en comparación al ciclo anterior.

Page 126: Un modelo empírico de enseñanza de las metodologías ágiles

126

Como podemos ver, comparativamente las menciones a las prácticas fueron más, y la comprensión mejoró levemente. Los errores conceptuales que permanecen al final del proyecto fueron los siguientes: el alumno AV considera que el planning game no sirvió al comienzo para “generar un plan” debido a la incertidumbre inicial, siendo que ésta es justamente la herramienta para dilucidar las incertidumbre iniciales. Por su parte, el alumno CT persiste en considerar que los tests de aceptación se deben definir a final, cuando “hay que probar”.

Con respecto a cómo evaluaron la aplicación de las prácticas se obtuvo lo siguiente:

Se aprecia que mejora la evaluación de todas las prácticas. Ya no existen complicaciones con el rol del cliente y el planning game, sino que sólo presenta algunas complicaciones.

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 127: Un modelo empírico de enseñanza de las metodologías ágiles

127

La práctica menos recordada es tests de aceptación, quizás porque la forma en que se gestionó efectivamente la aprobación del producto no difiere mucho de la manera tradicional: que el cliente revise el software al finalizar el desarrollo, quizás definiendo algunos criterios de aceptación, pero de manera tardía.

El punto planteado por CT en el tema de entregables pequeños es muy relevante. Este grupo presentó una buena salud al inicio del proyecto, pero no se previó que con el poco tiempo disponible en las iteraciones finales había que mantener el ritmo de trabajo para lograr buenos resultados, lo que terminó afectando el desempeño global del grupo, tal como se detalla en el punto siguiente.

Ilustración 49: Plan al finalizar el proyecto

Page 128: Un modelo empírico de enseñanza de las metodologías ágiles

128

Evaluación del cliente

En esta ocasión 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.

Gestión del Desarrollo en Equipo

Este equipo había ido a buen ritmo, sincronizado con el cliente y produciendo resultados. Esto provocó que los alumnos se confiaran y dejaran el ritmo de trabajo original. Por ejemplo, algunos miembros del equipo faltan a algunas sesiones, usualmente de manera justificada. Sin embargo, las reglas del curso indicaban que ellos debían “devolver esas horas”, con trabajo en casa, para lo cual los miembros del equipo que si asistieron les asignaban tareas que estaban pendientes. Lamentablemente, no se cumplió con estos trabajos, perdiéndose finalmente estas horas de trabajo. El coach actúa muy bien como motivador dentro de la sesión, pero no asume su rol en las otras horas del curso, confundiendo el concepto de “no usar horas extra” con el “omitir horas debidas de trabajo”. En esto sería mal evaluado por uno de sus compañeros más tarde.

Evaluación de aprendizajes

Observemos lo que dice el análisis de comprensión.

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 Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 129: Un modelo empírico de enseñanza de las metodologías ágiles

129

Comparando ambas muestras ahora vemos que existe una mejor rememoración y comprensión de las prácticas. Es notoria eso sí la ya nombrada confusión del coach con lo que respecta al ritmo sostenido. Otro alumno (AV) presenta dos problemas: indica que no es posible lograr ritmo sostenido en 3 horas a la semana, pero no justifica. Es notorio en este alumno además la presencia de un preconcepto errado: desde el comienzo del curso él abogó por el uso de herramientas distintas a un plan construido con post-it para gestionar el avance (las que nunca se implementaron), y como se puede apreciar, él ignoró o no comprendió todas las instancias de sincronización grupal presentes y aprovechadas por sus compañeros. Considera, por ejemplo, que el plan ubicado en el espacio de trabajo informativo no es útil, y en el caso de stand-up meetings, sólo lo considera como un mecanismo para “ponerse de acuerdo”, lo que “podría suceder en cualquier momento” por lo cual “no debería ser necesario realizarla al comenzar el trabajo”. Esto contrasta con opiniones de sus compañeros que incluso destacan que el realizar también reuniones de evaluación al final de cada sesión fue un gran aporte, como podemos apreciar en la evaluación de aplicación de las prácticas que se muestra a continuación:

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 130: Un modelo empírico de enseñanza de las metodologías ágiles

130

El alumno FS hace notar que el ritmo sostenido se ha debilitado debido a la falta de comunicación y compromiso para realizar las tareas acordadas fuera del horario del taller, lo cual también es considerado como problema del liderazgo motivador.

El alumno CT, por su parte no ve tan útil el espacio informativo, como podría serlo un software administrador de proyectos. En lo que refiere a las stand up meetings, indica que en las sesiones en que las tareas estaban asignadas se ahorraba este tiempo, lo que se reemplazaba por una reunión de evaluación al final. Cabe hacer notar la incongruencia que aquí se produce, dado que muchas tareas que se acordaron realizar como trabajo en casa no se hicieron, dejando el estado de avance del proyecto en una incertidumbre.

Page 131: Un modelo empírico de enseñanza de las metodologías ágiles

131

Evaluación interna de los alumnos

La actitud de “dedicación a generar valor” se invirtió, pasando a ser los alumnos FS y CT los mejor evaluados. Además, se percibe una mejora global en “autoperfeccionamiento”. El resto de los puntos se mantiene aproximadamente igual al ciclo anterior.

Llama la atención la contradicción entre lo planteado en los trabajos escritos y esta herramienta, dado que en los primeros algunos alumnos criticaron la baja de productividad debido a la falta de cumplimiento de tareas e inasistencia.

Co-Evaluación Alumno

Eje Concepto Ciclo FB FS CT AV

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

2 67% 75% 75% 58%

Proactividad para el éxito del proyecto 1 83% 75% 75% 83%

2 83% 75% 75% 83%

Cliente Actitud de diálogo : con el cliente 1 92% 75% 58% 92%

2 92% 75% 67% 92%

Equipo Actitud de diálogo : con el equipo 1 92% 75% 92% 100%

2 92% 92% 92% 92%

Actitud positiva frente a las críticas 1 100% 75% 92% 92%

2 92% 75% 92% 100%

Autoperfeccionamiento 1 67% 50% 50% 92%

2 75% 75% 92% 92%

Disposición a apoyar a los otros en sus labores 1 100% 83% 83% 92%

2 67% 83% 83% 67%

Disposición a recibir apoyo del resto del equipo 1 92% 58% 83% 75%

2 83% 67% 83% 75%

Evaluador Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 132: Un modelo empírico de enseñanza de las metodologías ágiles

132

Ciclo de Programación Incremental de Calidad

Evaluación de aprendizajes

Como podemos observar, la comprensión de estas prácticas aumenta significativamente al finalizar el proyecto, quedando algunos errores que indicamos a continuación. Dos alumnos entienden demasiado literalmente el término estandarizar. La propiedad colectiva del código se entiende como un conocimiento absoluto de todo el código por todo el equipo, lo que sería ideal pero no muy factible. También persiste el problema de entender mal diseño simple, entendiéndolo como “rediseñar el código recibido, porque el diseño original no es ‘simple’ ”.

Con respecto a la evaluación de aplicación de las prácticas, lo obtenido es lo siguiente:

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 133: Un modelo empírico de enseñanza de las metodologías ágiles

133

Los alumnos evalúan de manera más positiva la aplicación de las prácticas. Con respecto al “desarrollo guiado por tests” existe discrepancia debido a que fue una práctica que, a medida que avanzó el proyecto y los plazos fueron acortándose, fue dejada progresivamente de lado, lo que fue considerado un error por un alumno (FS), dado que aparecieron errores en el código que con tests podrían haber sido descubiertos en una mejor oportunidad.

Como podemos notar, muchos de los problemas presentados se deben a tener que desarrollar contra el tiempo, del cual se dispuso aún menos debido a las inasistencias. Este es un claro ejemplo del principio de que “ante presión las malas prácticas reaparecen”.

Proyecto Sincronización XML Peer2Peer “XMLSync”

Descripción del Proyecto

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.

Conocimientos previos de los alumnos

Dos alumnos poseían conocimientos sobre manejo de XML a partir del trabajo práctico realizado en un curso anterior. El resto sólo tenía nociones básicas a partir de su conocimiento de HTML. Nadie conocía el lenguaje C# ni el ambiente de desarrollo Visual Studio 2005. Conocían eso sí el lenguaje Java, lo que les facilitó la adopción de C#, y generar la solución final tal como veremos más adelante.

Page 134: Un modelo empírico de enseñanza de las metodologías ágiles

134

Desarrollo del Proyecto

Mes #

Plan XMLSync

Viernes Viernes Simbología

0 29 29 Introducción al curso

Ago

sto

1 5 5 Presentaciones Iniciales

2 12 12 Primer Ciclo

3 19 19 Segundo Ciclo

4 26 26 Tercer Ciclo (planificado pero no alcanzado)

5 2 2 Feriados

Sep

tiem

bre

6 9 9

16 16

7 23 23

8 30 30

Oct

ub

re

9 7 7

14 14

10

21 21

11

28 28

12

4 4

No

vie

mb

re

13

11 11

Tabla 32: Comparación entre el plan original y lo realmente sucedido en el proyecto XMLSync

Tal como se indicó para el grupo anterior, el profesor planteó un desarrollo estructurado en tres iteraciones de 4 sesiones cada una, pero la primera iteración terminó alargándose 3 semanas adicionales, tiempo que se explica porque el tiempo original era arbitrario, y no correspondía a la realidad del desafío involucrado (situación similar al del otro proyecto). El resto de las semanas correspondió al ciclo final del proyecto.

Page 135: Un modelo empírico de enseñanza de las metodologías ágiles

135

Primera Iteración, semanas 1 a 9

Gestión Orientada al Valor

Ilustració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

El plan obtenido del Planning Game realizado en la primera sesión dedicada al desarrollo, definió una lista de requerimientos de alto nivel, junto con algunas tareas específicas. Los requerimientos solicitados para la aplicación deseada fueron:

Sincronización de XMLs, entre dispositivos portátiles que corren Windows CE

Minimizar uso de red: Comunicación entre PDAs en modo optimizado (resumido)

Cada documento debe tener identificador, tiempo de modificación (timestamp) y posiblemente nº de versión

Minimizar tipos de conflicto

Eficiencia

Robustez y persistencia

(Alta) Disponibilidad de los datos (documentos XML)

Como es posible observar, el fruto del Planning Game es un conjunto bastante difuso de requerimientos y metas, y no un plan de trabajo específico.

Page 136: Un modelo empírico de enseñanza de las metodologías ágiles

136

Evaluación de aprendizajes

El estudio de los trabajos entregados por los alumnos permite determinar que lograron un conocimiento teórico bastante bueno, tal como podemos ver a continuación.

Los únicos problemas detectados (además de aquellos que olvidaron los temas) son los de un alumno en específico, quien confundió “historias de usuario” (las que deben estar en el lenguaje del cliente) con “tareas” (que deben estar en el lenguaje de los desarrolladores), y que no consideró que lo principal de la práctica entregables pequeños es generar valor lo antes posible al cliente.

Sin embargo, aparecen grandes problemas en la aplicación, tal como vemos a continuación.

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 137: Un modelo empírico de enseñanza de las metodologías ágiles

137

En la observación in situ del curso, se pudo observar que una de las causas de los problemas de aplicación declarados se encuentra en la relación entre el equipo de desarrollo y el cliente. Como ya se observó en el plan generado al comienzo del trabajo, el flujo de información entre las partes no fue de buena calidad. El cliente, al ser un profesor de la carrera generaba un respeto tal que provocó en los alumnos una actitud tímida, que los inhibió de consultarle ante la gran cantidad de dudas que los asaltaron al abordar el desafío propuesto. Además, aunque el cliente estuvo presente la mayoría de las reuniones, estaba demasiado ocupado en tareas propias como para dar pie a ser “interrumpido” por los alumnos.

El problema planteado, por su parte, mostró ser bastante complejo, y en realidad requería de un análisis y discusión entre los alumnos y el cliente que simplemente no se produjo con la fluidez necesaria para lograr una definición satisfactoria sobre las reales necesidades de la solución requerida. Esto explica que el plan generado no considerase estimaciones de esfuerzo para cada “historia de usuario”. De hecho, muchos de los requerimientos entregados no tenían una verdadera “historia de uso” que los respaldase, dado que no existía una verdadera profundización sobre la naturaleza del problema en cuestión. Por ejemplo, uno de los temas cruciales fue definir que el algoritmo de sincronización entre los XML debía suponer que existía un origen común entre los documentos, pero esta fundamental definición no quedó clara hasta bastante avanzada la iteración.

La sincronización de XMLs demostró tener una complejidad tal, que los alumnos se sintieron imposibilitados de dividirlo en pasos pequeños y así lograr abordarlo de manera iterativa. Fue el coach designado por el equipo quien asumió por propia iniciativa la responsabilidad de liderar el análisis, gracias a lo cual se lograron algunos resultados, pero al no confiar ni involucrar sus compañeros en esta labor, su gestión no tuvo mucho éxito, como veremos más adelante.

Cuando los alumnos se enfrentaron al requerimiento de XP de generar un “entregable pequeño”, intentaron convencer al cliente de priorizar el requisito de implementar la comunicación optimizada entre dispositivos móviles, dado que era un problema más claro. El

Page 138: Un modelo empírico de enseñanza de las metodologías ágiles

138

cliente, ejerciendo su derecho a priorizar, decidió por su parte enfocar los esfuerzos en el requerimiento de sincronización de dos documentos XML, aunque esto sucediese en un ambiente local y no entre dispositivos móviles. De esta manera, se postergaba para más adelante la ejecución del algoritmo en una PDA y la implementación de comunicación óptima entre estos dispositivos. En la práctica, el entregable de menor tamaño posible para generar algún valor exigió un esfuerzo bastante largo para el tiempo disponible en el curso, lo que llevó a prolongar el primer ciclo casi al doble del tiempo pre-planificado.

Los test de aceptación, por su parte, sólo aparecieron muy al final de la iteración, probablemente por la poca comprensión del detalle de las funcionalidades buscadas.

Ilustración 51: Coach (a la izquierda) liderando el análisis del problema

Page 139: Un modelo empírico de enseñanza de las metodologías ágiles

139

Ilustración 52: Equipo presentando algunos avances al cliente

Evaluación del cliente

La evaluación del cliente 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.

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%

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

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

Puntualidad y Asistencia 1 100% 100% 100% 100% 100% 100%

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

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

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

Evaluador Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 140: Un modelo empírico de enseñanza de las metodologías ágiles

140

Gestión del Desarrollo en Equipo

Tal como se observó en la Ilustración 50, las tareas técnicas obtenidas del planning game fueron las siguientes:

Investigación de tecnologías

Investigar métodos XML para C#

Investigar XPath 2.0

(Cómo) Borrar nodos y ramas de un XML

Investigar Sync XML

Políticas de Sincronización Automáticas/Manuales (para ser aplicadas por los usuarios)

Sincronización por ramas

Habilitación de infraestructura

Instalación de Software (Visual Studio)

Ninguna de estas tareas poseyó estimaciones inicialmente, lo que se fue solucionando a medida que avanzó la iteración, en donde también se definieron tareas más específicas derivadas del problema de sincronizar XMLs.

Evaluación de aprendizajes

Veamos lo que dice la comprensión demostrada por los alumnos en sus trabajos:

Un primer punto a destacar son las carencias conceptuales del coach, quien no se puede desligar de la concepción tradicional de jefe de proyecto, como por ejemplo, asumir las responsabilidades sólo, o demostrar una desconfianza patente ante su grupo. También hay

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 141: Un modelo empírico de enseñanza de las metodologías ágiles

141

problemas de comprensión del espacio de trabajo informativo y tracking, debido a la poca utilidad que tuvo en la práctica el plan allí registrado.

Veamos cómo evalúan los alumnos la aplicación de las prácticas de desarrollo equipo en este ciclo:

Lo primero que destaca es que hay muchas prácticas que ni siquiera son recordadas por los miembros del equipo, y que la práctica peor evaluada es el liderazgo motivador (coaching). Destaca eso sí la evaluación positiva que realiza un alumno sobre el ritmo de trabajo logrado y la dedicación del grupo.

El coach, dentro de su estilo más tradicional y de su decisión de asumir personalmente la responsabilidad de abordar el problema, enfrentó de manera más decidida al cliente para obtener la tan requerida retroalimentación. En este contexto, si bien el plan se fue actualizando en el espacio de trabajo informativo y se generaban tareas más específicas, el grupo no asumió la información que allí aparecía como propia. Esto provocó una distancia entre el grupo y el coach que más tarde provocaría un quiebre en la organización grupal.

Page 142: Un modelo empírico de enseñanza de las metodologías ágiles

142

Evaluación interna de los alumnos

Lo más importante que surge en esta co-evaluación es la dispar evaluación que recibe el coach (CH), quien a pesar de ser el mejor evaluado en varios ítems, posee las más bajas evaluaciones en los ítems “actitud positiva frente a las críticas” y “disposición a recibir apoyo del resto del equipo”, clara señal del aislamiento en que él había caído.

Ciclo de Programación Incremental de Calidad

Como ya fue indicado en el análisis del otro proyecto, el trabajo se realizó en equipos portátiles facilitados por la facultad, en los cuales usualmente hubo que instalar y a veces reconfigurar el ambiente de desarrollo utilizado (Visual Studio) con la ya comentada pérdida de tiempo y de ritmo de trabajo.

Evaluador Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 143: Un modelo empírico de enseñanza de las metodologías ágiles

143

Evaluación de aprendizajes

Como podemos observar, varios alumnos enuncian una descripción de las prácticas que son mínimas, sin entrar en detalles que permitan evaluar su comprensión real. Destacan dos casos de errores conceptuales. El coach (CH) confundió el concepto de “simple” con “fácil” y “desorganizado”. Esto tiene relevancia considerando que él asumió muchas decisiones a solas, y por ende su error de concepto afectó el desarrollo grupal. En otro caso, el alumno CM declara que no domina la práctica estándares de código debido al poco código que se produjo en la iteración. Ahondaremos en este detalle cuando se presente la evaluación de aplicación de prácticas realizadas por los alumnos.

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 144: Un modelo empírico de enseñanza de las metodologías ágiles

144

Lo que primero resalta es que el diseño partió con problemas. Todos los alumnos que se pronuncian sobre el tema declaran que la gran complejidad del problema hizo imposible un diseño simple. Ante esta situación, el coach realizó una investigación personal sobre herramientas de sincronización de documentos XML, encontrando XMiddle43, de Java, y XMLDiff44 de Microsoft. Optó por la segunda, dado que ella estaba disponible en la misma plataforma que requería la aplicación final. Sin embargo, esta decisión se tomó a ciegas, sin tener claridad en las limitaciones de dicha herramienta, lo que implicó que, si bien se logró algún avance, posteriormente se encontrara que XMLDiff era un camino sin salida y hubo que cambiar radicalmente de estrategia.

Es importante también señalar que todo el esfuerzo que hubo que invertir para dilucidar la incertidumbre existente, provocó que el tiempo finalmente disponible para obtener una solución concreta fuera muy poco, desarrollándose poco código. Esto fue considerado por muchos alumnos como una limitante para haber podido observar cómo funcionaban las prácticas de programación de XP durante este ciclo.

El desarrollo guiado por tests también fue víctima de los problemas enunciados anteriormente. No existió mucha claridad para definir qué era lo que realmente tenía que cumplir la solución, y por ende sólo se implementaron algunos tests para validar ciertos casos de sincronización de documentos XML. Esto se suma al cambio de paradigma en la forma de desarrollar que implica esta práctica, que la hace en sí compleja de adoptar. El poco código generado también desincentivó esta práctica, dado que aparecía más simple arreglar los problemas directamente sobre la marcha parchando el escaso código programado que hacer tests.

Tanto la refactorización como la integración continua se evalúan como difíciles por los alumnos los que hacen notar la falta de un sistema de control de versiones que unificase el

43 http://xmiddle.sourceforge.net/ 44 http://msdn.microsoft.com/XML/XMLCodeSamples/default.aspx?pull=/library/en-us/dnxmlnet/html/xmldiffgui.asp

Page 145: Un modelo empírico de enseñanza de las metodologías ágiles

145

código producido. Sin embargo, la necesidad que subyace a este problema es la falta de una base de código funcional que sirviese como piso para el desarrollo. Esta base de código funcional la constituyó al final de la iteración la suite de tests que se logró producir, la que reunió el conjunto desintegrado de pedazos de código que lograron implementar los alumnos para los casos de sincronización resueltos, pero es algo que no es recordado por los alumnos. El uso de la refactorización fue detectado sólo por algunos de ellos, indicando que su uso fue excesivo dada la necesidad de armonizar los diversos intentos por generar soluciones funcionales.

Con respecto a los estándares de código, el único que declara problemas es el coach, quien no está satisfecho con cómo programa la gente “a su cargo”. El resto considera esta práctica casi natural dado el poco código generado de manera colectiva.

Las prácticas programación de a pares y propiedad colectiva de código son las mejor evaluadas en su aplicación. Para la primera se indica que hay preconceptos que son más fuertes en caso de presión, lo que es una demostración del principio enunciado por Kent Beck y fundamentado por la ciencia psicológica “bajo presión, la gente vuelve a sus antiguas costumbres” “Al ser sometidos a stress, la gente vuelve a sus antiguas costumbres” ya explicado en el capítulo 0. Para la práctica de propiedad colectiva de código, el coach plantea otra vez que el código es sólo su responsabilidad, ignorando el trabajo de los demás. Otro alumno (MV) indican que podría mejorarse si existiese una mayor rotativa sobre el código generado, mientras que existe una evaluación particularmente positiva (CM), en donde se indica una perspectiva contradictoria a lo indicado por el alumno CS en la refactorización: “la propiedad colectiva de código ha servido para evitar refactorizaciones inútiles”. Como los compañeros evaluaron a CS como más alejado del equipo, pareciera que lo que él percibe como refactorizaciones desordenadas es interpretado por CM como desarrollo normal, denotando un nivel de conocimiento dispar del código generado entre CS y el resto del grupo.

Page 146: Un modelo empírico de enseñanza de las metodologías ágiles

146

Segunda iteración (semanas 10 a 14)

Gestión Orientada al Valor

Ilustración 53: Papelógrafo con el plan obtenido al finalizar la primera iteración

Page 147: Un modelo empírico de enseñanza de las metodologías ágiles

147

Al comenzar el segundo ciclo, el plan generado muestra una evolución con respecto al plan logrado en el Planning Game inicial, al que se le incorporaron tareas más concretas. Sin embargo, es notorio el congelamiento de los requerimientos de valor agregado, ante los pocos resultados obtenidos en el ciclo anterior. Al poco andar en este ciclo, se encontró un caso de sincronización de XMLs que la herramienta base escogida (XMLDiff) no soportaba – realizar la sincronización cuando a uno de los XMLs se le había borrado un nodo o una rama - , por lo cual la mayor parte del trabajo realizado hasta el momento resultó ser inservible. Ante esta crisis, hubo cambios estructurales en el equipo (que veremos más adelante) y una decisión de estudiar más decididamente el problema de la sincronización de XMLs. Contando con el apoyo del profesor y ahora también del cliente, y con investigación propia, los alumnos adquirieron una comprensión más profunda de los diversos algoritmos y herramientas disponibles para sincronizar XMLs, gracias a la cual se pudo evaluar y validar con certeza una biblioteca de código abierto alternativa que sí resolvía el problema de la sincronización (XMiddle). Como pequeño valor agregado, se validó que la solución corría en una PDA, quedando el requerimiento de comunicar eficientemente los dispositivos fuera del proyecto.

Evaluación de aprendizajes

La comprensión teórica de las prácticas mantuvo los buenos resultados del ciclo anterior, a excepción de un alumno que entiende el Planning Game como un momento específico dentro del proyecto, y no vislumbra su proyección continua al resto de éste. Hay también dos alumnos que no entregaron información suficiente para evaluar su comprensión en otras prácticas (CS en test de aceptación y MV en entregables pequeños).

Con respecto a la evaluación de aplicación de prácticas, en este ciclo se produjo un vuelco en el proyecto.

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 148: Un modelo empírico de enseñanza de las metodologías ágiles

148

Se evalúa una mejoría en la práctica cliente in situ. Incluso un alumno recuerda que aquél les hizo ver que debían acercarse más decididamente para obtener la información requerida. También se destaca que el cliente ahora colaboró con investigación propia aportando ejemplos de código y posibles luces para el problema de sincronización de XMLs. El único alumno que evalúa negativamente la aplicación fue CH, quien en esta iteración perdió su condición de coach, y al parecer quedó algo aislado de los resultados finales obtenidos por el grupo.

Con respecto al planning game dos alumnos mencionan mejorías en él, indicándose que a 2 o 3 semanas de finalizar el proyecto se obtuvo por fin un plan orientador, aunque con algunas dificultades, como lentitud o desorden. Llama la atención, eso sí, que la mayoría del grupo ni siquiera mencione esta práctica, que fue estructural en el resultado final del desarrollo.

Por su parte, dos alumnos consideran que hubo problemas con los tests de aceptación, pues fueron definidos al final del desarrollo e indican que en algunos casos fueron propuestos por los propios alumnos. Esto no es compartido por todos, realizando una evaluación mayoritariamente positiva.

Por su parte, la práctica entregables pequeños, muestra una mejor percepción, gracias a la mayor divisibilidad que se logro al tener un mejor conocimiento del problema. Se mantienen eso sí las críticas a la estrategia del primer ciclo de adoptar una herramienta a ciegas (XMLDiff), por el impacto negativo en los resultados, y también se plantea que el resultado final fue muy pequeño.

Page 149: Un modelo empírico de enseñanza de las metodologías ágiles

149

Evaluación del cliente

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.

Gestión del Desarrollo en Equipo

Tal como ya fue explicado, durante este ciclo el grupo tuvo una crisis: el problema técnico enfrentado y la gran distancia entre el coach original y sus compañeros obligaron al profesor a intervenir con varias acciones, como por ejemplo una invitación a los alumnos a almorzar para conocerse mejor, distender los ánimos y definir vías de solución. Una de las acciones tomadas fue el reemplazo del coach original, quien abandonó el rol y se sintió alivianado de la carga que llevaba. El alumno BB asumió el rol con apoyo implícito del profesor, y su actuar fue mucho más conciliador y aunador de esfuerzos, lo que permitió que el grupo asumiera unido el desafío de lograr algún resultado realmente útil de este proyecto. Uno de los resultados se puede apreciar en el plan final, el que redefinió y simplificó totalmente al plan anterior, indicando tareas técnicas mucho más claras, directas y estimables. Otra de las decisiones tomadas fue dedicar horas adicionales a experimentación de desarrollo fuera de las horas de

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 Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 150: Un modelo empírico de enseñanza de las metodologías ágiles

150

sesión, lo que no fue considerado por los alumnos como “horas extra”, pero en realidad sí lo eran. El ánimo del grupo mejoró y comenzaron a celebrarse los logros ante los resultados que comenzaron a obtenerse.

Ilustración 54: Plan final del proyecto

Evaluación de aprendizajes

Al analizar la comprensión teórica de las prácticas, obtenemos los siguientes resultados:

En lo que respecta a ritmo sostenido sólo dos alumnos presentan problemas derivados de entender literalmente el nombre “40 horas a la semana”. En lo que se refiera al liderazgo motivador sólo dos alumnos no aportan información suficiente para evaluar, y el coach de la primera iteración (CH) muestra una mejora en su entendimiento. En lo que se refiere al espacio de trabajo informativo sólo un alumno (MV) declara no comprender su utilidad.

Page 151: Un modelo empírico de enseñanza de las metodologías ágiles

151

Con respecto a la evaluación de aplicación de las prácticas, se tiene lo siguiente:

El liderazgo motivador aparece como un punto álgido. Si bien hubo un cambio de coach, la práctica es evaluada por varios alumnos sólo tomando en cuenta al coach original y su estilo autoritario. Sólo algunos alumnos, incluyendo al coach original, consideran que el cambio de liderazgo fue positivo aunque no exento de problemas. Llama eso sí la atención que sólo uno de los alumnos (CM) haya notado la explícita intervención del profesor en un rol de supra-coach.

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 152: Un modelo empírico de enseñanza de las metodologías ágiles

152

El espacio de trabajo informativo por su parte presentó cambios. El plan en papelógrafo fue reemplazado por un listado de tareas que se escribía y actualizaba directamente en la pizarra de la sala de clases, y que era respaldado en un conjunto de post-it’s. Si bien a algunos alumnos esto les pareció útil, para otros sólo fue un apoyo para el real pilar de la coordinación de equipo que fueron las stand-up meetings. Esta última práctica, por su parte, sólo fue afectada por los atrasos en la llegada de los alumnos a clases, lo que retrasaba y a veces alargaba más de la cuenta estas reuniones.

La retroalimentación de avance es evaluada sólo por dos alumnos, de manera positiva, quizás porque fue sólo efectiva al final y fue una responsabilidad que terminó distribuyéndose en el grupo.

Por último es importante hacer notar que a pesar de haberse roto la regla de “no sobretiempo”, dado que los alumnos decidieron invertir tiempo extra para investigar y desarrollar experimentos, esto no fue notado por los alumnos.

Evaluación interna de los alumnos

En general se observa una mejor evaluación, en particular del nuevo y del antiguo coach. Dos alumnos (CS y MV) presentan algunas bajas en su evaluación.

Ciclo de Programación Incremental de Calidad

El esfuerzo de desarrollo de este ciclo fue dejar de lado la implementación fallida basada en XMLDiff, encontrar el código minimal de la librería Java XMiddle que resolvía el problema de la sincronización de XMLs, y portar dicho pedazo al lenguaje C#. Se logró que dicho código

Co-Evaluación Alumno

Eje Concepto Ciclo BB TH CH CM CS MV

Proyecto Dedicación a generar valor 1 75% 80% 85% 80% 70% 70%

2 90% 75% 100% 80% 55% 80%

Proactividad para el éxito del proyecto 1 85% 70% 95% 80% 70% 60%

2 90% 75% 100% 80% 65% 65%

Cliente Actitud de diálogo : con el cliente 1 70% 70% 90% 60% 60% 55%

2 80% 65% 80% 65% 50% 45%

Equipo Actitud de diálogo : con el equipo 1 85% 70% 55% 80% 80% 65%

2 95% 85% 50% 80% 80% 75%

Actitud positiva frente a las críticas 1 90% 75% 30% 90% 90% 75%

2 80% 85% 60% 90% 80% 90%

Autoperfeccionamiento 1 75% 75% 100% 65% 70% 60%

2 85% 80% 90% 65% 50% 65%

Disposición a apoyar a los otros en sus labores 1 80% 80% 80% 75% 85% 75%

2 85% 75% 85% 75% 40% 60%

Disposición a recibir apoyo del resto del equipo 1 75% 80% 45% 85% 90% 75%

2 80% 85% 60% 85% 75% 60%

Evaluador Calificador

Siempre 100%

Regularmente 75%

A Veces 60%

Con Dificultad 25%

Nunca 0%

Page 153: Un modelo empírico de enseñanza de las metodologías ágiles

153

funcionase sin problemas en una PDA dado que se utilizó el ambiente multi-plataforma de desarrollo de Visual Studio 2005.

Evaluación de aprendizajes

A primera vista resalta el diseño simple como el concepto menos entendido. Un alumno (CH) considera que dado que lo que se hizo fue reutilizar código existente eliminándole lo innecesario para resolver el problema no constituye un diseño simple, y eso es exactamente lo que es. Este error conceptual también afecta a los alumnos BB y CS, quienes sugieren que por usar una base de código ajeno en la solución final no se realizó diseño simple. Por su parte, MV también ignoró la estrategia de diseño simple aplicada en el ciclo y que permitió entregar una solución al cliente, como veremos más adelante. Es notorio el contraste con el primer ciclo, en donde los alumnos demostraron dominio teórico de esta práctica, pero que al ser llevada a la práctica se demostró que el entendimiento no era tal.

En lo que se refiera a la propiedad colectiva de código, un alumno interpreta literalmente el término “propiedad”, indicando que dado que se usó código de terceros no podía ser considerado como “propio”. Aquí el alumno obvia el sentido de la práctica, que es que todos dentro del equipo pueden intervenir cualquier parte del código, sin que existan parcelas aisladas de conocimiento. Otro alumno (CM), por su parte, asume una posición algo extrema, deseando que todos conociesen todo el código siempre, que es algo ideal pero casi imposible.

Con respecto a estándares de código, se aprecia en dos alumnos la posible creencia de que los estándares deben definirse de una manera formalizada. Esta sospecha está fundada en que además no hablan del estilo común de código que terminó usándose en la práctica.

Bien entendido

No hay claridad

Con errores de comprensión

No menciona

Simbología Comprensión

Page 154: Un modelo empírico de enseñanza de las metodologías ágiles

154

En lo que se refiere a la evaluación de la aplicación de prácticas, se observó lo siguiente:

En el diseño simple, los alumnos que comprendieron el concepto evalúan como positiva su aplicación cuando se decidió portar a C# sólo aquella parte de XMiddle que necesitaban para resolver el problema de la sincronización, validando antes la efectividad del código y borrando todo lo innecesario.

El desarrollo guiado por test asumió un rol relevante en este ciclo. De hecho el único código que pudo reutilizarse luego de cambiar de XMLDiff a XMiddle fue la suite de test, y el entregable final evolucionó a partir de la funcionalidad contenida por dicho módulo. El mayor problema percibido fue que no se realizaron los tests al inicio del desarrollo, sino que al finalizar cada incremento de código, lo que si bien no es lo ideal, ya es un avance con respecto a la práctica tradicional

La programación de a pares, la propiedad colectiva de código y la integración continua fueron evaluados positivamente. Las dos últimas se vieron favorecidas por la definición de un repositorio común de código, lo que aceleró el desarrollo haciendo que al final del ciclo, cada día arrojase un producto integrado. Sólo existe una queja acerca de que se podría haber rotado más las parejas para haber compartido más el conocimiento del código. Un solo alumno, el ex-coach, plantea que no se sintió acompañado al programar, quizás por la situación que le tocó vivir personalmente.

Page 155: Un modelo empírico de enseñanza de las metodologías ágiles

155

10.2 Herramientas de evaluación utilizadas

10.2.1 Encuesta de co-evaluación

Universidad de Chile Facultad de Cs. Físicas y Matemáticas Departamento de Cs. de la Computación CC62V – Taller de Metodologías Ágiles de Desarrollo de Software

Pauta de Co-Evaluación

Nombre: Claudio Trujillo Muñoz

Rango de Evaluación (de mayor a menor logro) Siempre : S Regularmente : R A Veces : AV Con Dificultad : CD Nunca : N

Ítems a evaluar Baytelman Pilowsky, Felipe Bruno

Saavedra Cespedes, Felipe Ignacio

Trujillo Muñoz, Claudio Alejandro

Villavicencio Theoduloz, Andres Felipe

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

S S S S

Es capaz de pedir ayuda cuando ha tenido problemas

R AV AV R

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

S S S S

Demuestra iniciativa para lograr el éxito del proyecto

R R R R

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

S S S

Ha mantenido un buen dialogo con el cliente aportando con el desarrollo del proyecto

S S S S

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

R R R R

Es capaz de admitir sus equivocaciones y recibir críticas

S S S S

Page 156: Un modelo empírico de enseñanza de las metodologías ágiles

156

10.2.2 Encuesta al cliente

Universidad de Chile Facultad de Cs. Físicas y Matemáticas Departamento de Cs. de la Computación CC62V– Taller de Metodologías Ágiles de Desarrollo de Software

Pauta de Evaluación Cliente Versión 23-10-2005 16:12:31

Rango de Evaluación (de mayor a menor logro) Siempre : S Regularmente : R A Veces : AV Con Dificultad : CD Nunca : N

Ítems a evaluar

XX

XX

X

XX

XX

X

XX

XX

X

XX

XX

X

Comentarios

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

R R R R

Al principio fue un poco confuso, pero después que le tomaran el timing al lo que tenian que hacer, hubo mayor fluidez de información.

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

S R R R

A veces se quedaban atados con algún problema, y daban vuelta y vuelta, y no me preguntaban ya que yo podía tener algunos hints para la solución.

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

R A A R

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

R R R R

Demuestran iniciativa para lograr el éxito del proyecto S A A R

Creo que Felipe Baytelman es un componente motivador y fundamental del equipo desarrollo y cuando le puso energía al proyecto, esto se transmitió al resto del equipo, y empezaron a aparecer los resultados.

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

S S S S

Cumplieron con los horarios puntualmente y mantuvieron la asistencia acordada

R R R R

Page 157: Un modelo empírico de enseñanza de las metodologías ágiles

157

10.2.3 Pauta de Evaluación de Ensayo de XP y Opinión del Primer Ciclo

Pauta de evaluación Fecha de entrega: 21 de octubre de 2005,

por e-mail e impreso en secretaría docente

(No se aceptarán trabajos atrasados y sin la presentación adecuada)

Primera parte: Ensayo sobre Extreme Programming

Nombre: ___________________________

En un ensayo de entre 5 a 10 páginas refiérete a o lo que entiendes por

metodología XP. Tomando en cuenta los siguientes puntos a desarrollar.

Indicadores Puntaje

asignado

Puntaje

obtenido

La motivación que dio origen a la

metodología XP

9

Los valores y principios subyacentes de la

metodología XP

9

Las prácticas de desarrollo y como

funcionan en conjunto (expuestas durante

el desarrollo del curso )

10

total

28

Observaciones:

Page 158: Un modelo empírico de enseñanza de las metodologías ágiles

158

Segunda parte: Evaluación de proyecto realizado desde la

perspectiva de XP

De acuerdo al trabajo realizado en la primera iteración. Escribe un informe con

un máximo de diez páginas. Refiriéndote a los siguientes ítems.

Indicadores Puntaje asignado Puntaje obtenido

Definición del problema

que aborda el proyecto.

7

Considerando los valores,

principios y prácticas de

XP:

Explicitar cuales se

aplicaron y como se

ejemplifican.

Explicitar cuáles no se

aplicaron y el por qué.

Proyectar su uso en la

próxima iteración

10

Detección de otras

problemáticas no

abordadas desde el punto

de vista de XP, y

propuestas para

solucionarlas

3

total

Observaciones:

__________________________________________________________

__________________________________________________________

__________________________________________________________

Page 159: Un modelo empírico de enseñanza de las metodologías ágiles

159

10.2.4 Pauta de Evaluación del Proyecto y Proyección a la Vida Profesional

Pauta de evaluación Fecha de entrega: 28 de noviembre de 2005,

a través de U-Cursos (No se aceptarán trabajos atrasados y sin la presentación adecuada)

Experiencia vivida en el Curso

De acuerdo al trabajo realizado desde la primera iteración, y usando el

siguiente marco referencial:

Valores y Principios de XP

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

Estructura modular de adopción de XP

ProgramaciProgramacióón orientada a n orientada a

la calidadla calidad

PlanificaciPlanificacióón y Gestin y Gestióón n

colaborativacolaborativa orientada al valororientada al valor

Trabajo en equipo motivadorTrabajo en equipo motivador

Planning Game

Tests de Aceptación del

Cliente

Tests de Aceptación del

Cliente

Entregas pequeñasEntregas pequeñas

Integración continua

Integración continua Estándares de

Código

Propiedad Colectiva de

Código

Programación de a pares

(+ Mantener el equipo en movimiento)

Espacio de Trabajo

Informativo

Diseño SimpleDiseño Simple RefactorizaciónRefactorización

Desarrollo Guiado por

Tests

Desarrollo Guiado por

Tests

Ritmo Sostenido / 40 horas a la

semana

Retroalimentaciónde Avance(Tracking)

Retroalimentaciónde Avance(Tracking)

Liderazgo Motivador(Coaching)

Liderazgo Motivador(Coaching)

Valores de XPValores de XPComunicación

RetroalimentaciónCoraje

Simplicidad

Cliente en terreno

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

Stand UpMeeting

Page 160: Un modelo empírico de enseñanza de las metodologías ágiles

160

Escribe un informe con un máximo de veinte páginas. Refiriéndote a los

siguientes ítems.

Indicadores Puntaje asignado Puntaje obtenido

Evaluación del proyecto visto desde XP

Definición del problema (desde

el punto de vista del cliente)

que aborda el proyecto.

4

Considerando los valores,

principios y prácticas de XP: Explicitar cuales se aplicaron y

como se ejemplifican.

Explicitar cuáles no se aplicaron y

el por qué.

7

Detección de otras

problemáticas no abordadas

desde el punto de vista de XP,

y propuestas para solucionarlas

3

Proyectar el uso de XP en la vida profesional: ¿Qué es más simple de adoptar?

¿Qué promete a pesar de no haber

sido adoptado en su totalidad?

¿Qué será más difícil de adoptar

¿Qué no entrega valor evidente?

7

Qué destrezas u aprendizajes

principales obtuve en el curso

que me servirán en mi trabajo,

y gracias a qué lo obtuve

(Hint: contrastar lo que sabían

antes del curso con lo que

saben ahora)

7

total 28

Nota: eviten hacer juicios sin dominar el sentido real de un principios/valores o prácticas

Observaciones: -

Page 161: Un modelo empírico de enseñanza de las metodologías ágiles

161

10.3 Resumen de ensayos de alumnos

10.3.1 Proyecto Mapache

Ciclo 1

Ciclo de generación de valor

Comprensión

Concepto Alumno Errores

Planning Game FS

Considera que la nebulosa en los requerimientos que sucedió al comienzo del proyecto es una carencia de XP, pero es algo natural de todo desarrollo de software

Tests de Aceptación CT

Cree que los tests el cliente los define sólo cuando hay que probar las funcionalidades, y no antes, ojala cuando se definen las historias de usuario.

Aplicación

Concepto Alumno Problemas detectados

Planning Game

FB

“Pese a en un comienzo no haber sido capaces de estimar correctamente los esfuerzos necesarios para cada objetivo, la negociación con el cliente fue mejorando hasta establecer claramente qué quiere y en qué orden. La temática relacionada con el proyecto, así como con el grupo con que trabajamos, incidió directamente en no ser capaces en un comienzo de estimar los esfuerzos y completar los objetivos de manera limpia y precisa. Gran parte del semestre ha sido derrochada en “sumergirnos en el proyecto” sin haber estimado que nos tomaría tanto tiempo”

Planning Game CT

“Falta de experiencia en el problema dificulta las evaluaciones/estimaciones”

Planning Game FS

(Tiene error de concepto, se queja de lo mismo pero atribuye la incertidumbre inicial a un defecto de XP)

Concepto Alumno Problemas

Cliente in situ

FS

“A pesar de que esta practica es muy útil, y prácticamente gratis para el equipo desarrollador, fue muy difícil de ponerla en práctica a cabalidad. Su causante es la visión que se poseía del cliente debido a lo que por costumbre uno tiende a realizar, esto es, consultar lo que quiere, fabricar una solución, y consultar por su aprobación.”

Page 162: Un modelo empírico de enseñanza de las metodologías ágiles

162

Cliente in situ

CT

"podamos aprovechar al cliente en el terreno y que esto no se transforme, en nuestro caso, en que el cliente desarrolle la solución". "Hemos tenido que decidir que es mejor no preguntarle al cliente pues sabemos que de cierta forma estaremos abusando de su conocimiento"

Ciclo de desarrollo en equipo

Comprensión

Concepto Alumno Errores de concepto

Ritmo Sostenido FB

“Las 40 horas semanales han sido reemplazadas por sólo 3: es verdad que no hemos realizado trabajo en la casa, respetando el tema de “limitar las horas de trabajo” pero ello ha sido porque también la presión no ha sido suficiente (o nadie está muy dispuesto a trabajar extra cuando hay otras cosas que hacer), más que por “fidelidad a la metodología”.

Liderazgo Motivador FB

“jugando un poco el rol de coach o negociando y trabajando junto al cliente, he tomado un papel un tanto más solitario”.

Aplicación

Concepto Alumno Problemas

Espacio de Trabajo Informativo CT

“Al replanificar, las tareas cambian de disposición en el papelógrafo lo que hace difícil leerlo para evaluar el avance”

Ritmo Sostenido CT

Se indica la siguiente limitante, derivada de la incertidumbre inicial del Planning Game: "no ser capaces en un comienzo de estimar los esfuerzos y completar los objetivos de manera limpia y precisa"

Stand Up Meeting CT

"al principio la gente se sentaba y las reuniones se alargaban" "algunas de estas reuniones han tardado demasiado tiempo"

Ciclo de Programación Incremental de Calidad

Comprensión

Concepto Alumno Errores

Estándares de Código FB

“al no haber incorporado mucho aún al código fuente, es que no ha surgido la necesidad de estandarizar nuestra programación”

Estándares de Código FS “No se uso debido al bajo nivel de programación”

Estándares de Código CT “No se uso pues nos basamos en código ya hecho”

Estándares de Código AV “es inaplicable ya que se nos ha impuesto un código”

Page 163: Un modelo empírico de enseñanza de las metodologías ágiles

163

Concepto Alumno Problema

Programación de a pares

FB

Indica que programando solo avanza más rápido. No entiende que no sólo se trata de programar, sino de que el conocimiento fluya por le equipo

Concepto Alumno Errores

Diseño Simple FB Hay una confusión con el significado tradicional de "diseño", por lo cual se cree que si no hay diseño formal no hay diseño

Diseño Simple FS

Se considera que “diseño simple” ante un sistema pre-existente implica rediseñarlo, y no definir la solución más adecuada a las condiciones

Diseño Simple CT “No se usa cuando se basa en código ya hecho”

Refactorización FS

“Al igual que en diseño simple, se pretende implementar en su totalidad dentro de la siguiente iteración, cuando se comienzo el desarrollo de extensiones a la aplicación, donde se debería construir una solución desde cero.”

Refactorización CT

No sabe si se aplicó porque tiene confusión en la relación entre refactoring y "nueva funcionalidad". El cree que solo se puede aplicar si se agregan nuevos módulos. Pero refactorizar es justamente hacer "mejor" el código sin agregarle funcionalidad

Refactorización AV

“Otra practica dejada de lado es la de refactoring, pues nuestro conocimiento del webserver en si no llega aun al nivel necesario para realizar uno, además que dado el scope del proyecto seria un desperdicio de tiempo de desarrollo”

Desarrollo Guiado por Tests CT Propone definir todos los test al inicio

Integración continua CT

No se usa cuando se basa en código ya hecho, dado que no hay que "integrar" nuevos módulos

Aplicación

Concepto Alumno Problemas

Desarrollo Guiado por Tests FS

“En un comienzo no se le dio el real peso que significa tener una batería de pruebas, quedando plasmado su uso casi al final de la iteración.”

Programación de a Pares FS

“Hubo desincronización inicial en las parejas en ritmo de trabajo”

Page 164: Un modelo empírico de enseñanza de las metodologías ágiles

164

Desarrollo Guiado por Tests AV

“El hecho de tener el código ya creado, con un diseño que no era de nuestra elección, dificulto de gran manera la creación de un conjunto de test completo”

Concepto Alumno Evaluación

Refactorización FB

“se han tomado algunas decisiones de diseño basadas en la refactorización: particularmente, a la hora de invocar el módulo de SOAP, cuando no es necesario aplicar servicios éste invoca los métodos del módulo GET de SOAP”

Ciclo 2

Ciclo de generación de valor

Comprensión

Concepto Alumno Errores

Planning Game AV

Considera que el planning game no sirvió porque había mucha incertidumbre el comienzo. No se entiende que el planning game fue justamente la herramienta para eliminar esa incertidumbre.

Tests de Aceptación CT

Cree que los tests de aceptación se definen al final, cuando “hay que probar”

Aplicación

Concepto Alumno Problemas

Planning Game FB

“nunca fue fácil estimar cuánto trabajo era necesario para concretar el proyecto, ya que siempre existían cabos sueltos”

Planning Game CT

“Solución al problema de definir tareas y estimar fue una larga reunión con el cliente”

Entregables pequeños CT

“La primera entrega se realizó muy próxima al término del curso, por lo que el tiempo que restó para la entrega final creo que no fue el óptimo, y eso sumado a nuestro exceso de confianza nos produjo un retraso de la entrega final. Creo que pudieron haberse

definido entregables más pequeños en pos de poder tener productos funcionales entregados, lo cual nos hubiera dado una mejor idea de los tiempos tomados para cada entrega”

Page 165: Un modelo empírico de enseñanza de las metodologías ágiles

165

Ciclo de desarrollo en equipo

Comprensión

Concepto Alumno Errores

Stand Up Meeting AV

“el concepto de stand up meeting tiene que ver más con la capacidad del equipo de lograr reuniones rápidas y al grano en cualquier momento. Esto si bien fue posible en nuestro proyecto, no un gran aporte en general pues dada la naturaleza del trabajo no se necesitaban decisiones más allá de “quien hace qué”.

Ritmo Sostenido AV No hay suficiente información para evaluar

Ritmo Sostenido FB

“Las 40 horas semanales fueron reemplazadas por sólo 3: es verdad que no hemos realizado trabajo en la casa, respetando el tema de “limitar las horas de trabajo” pero ello ha sido porque también la presión no ha sido suficiente (o nadie estuvo dispuesto a trabajar extra cuando se estaba solo, y con otras cosas que hacer), más que por “fidelidad a la metodología”.

Aplicación

Concepto Alumno Problemas

Ritmo Sostenido FS Falta de comunicación fuera del ambiente de trabajo para lograr la productividad esperada

Liderazgo Motivador FS

Indica que hubo problemas fuera del ambiente de trabajo, donde al no poseer la presencia de un liderazgo motivador, influyó en la no realización de tareas y coordinación del equipo.

Espacio de Trabajo Informativo

CT

Indica "no es tan necesario un acceso constante al estado de avance general del proyecto. Para estos casos es preferible el uso de software administrador de proyectos",

Stand Up Meeting CT

Por falta de tiempo, indica que en las sesiones en que las tareas estaban asignadas se ahorraba este tiempo, lo que se reemplazaba por una reunión de evaluación al final.

Cabe hacer notar la incongruencia que aquí se produce, dado que muchas tareas que se habían asignado para trabajo en casa no se habían trabajado, dejando el estado de avance del proyecto en una nebulosa.

Page 166: Un modelo empírico de enseñanza de las metodologías ágiles

166

Ciclo de Programación Incremental de Calidad

Comprensión

Tema Concepto Alumno Errores

Programación en Equipo

Estándares de Código FB

Consideran que la no haber intervenido mucho el código fuente legado, no hubo la necesidad de estandarizar nuestra programación más allá de respetar el estilo original del sistema. Se entiende mal la palabra estandarizar. AV

Propiedad Colectiva de Código AV

Considera que la propiedad colectiva del código sólo se cumple si todos revisan todo el código, El concepto es que todos tienen derecho a intervenir cualquier parte del código, sea esto o no necesario.

Este error no fue detectado en el ensayo del ciclo anterior.

Programación de Calidad Diseño Simple FB

Indican de manera muy similar “Estando restringidos por el hecho de partir con una base de código ajeno, y los estándares de la W3C esto es inaplicable”. Aquí no piensan en un diseño evolutivo, sino en un rediseño total AV

Aplicación

Alumno Concepto Problemas

FB Programación de a Pares

“El nivel de compromiso del "segundo a bordo" en cada par fue, durante el comienzo del semestre, mucho menor que el "piloto" de cada pareja. Se podía reconocer a primera vista quién está trabajando y quién está sentado mirando la pantalla sin nada que hacer. Creo que esta situación fue mejorando a lo largo del semestre, donde cada miembro del equipo fue adquiriendo más compromisos, y cumpliéndolas con mayor responsabilidad. “

FS Desarrollo Guiado por Tests

“no se utilizó esta práctica, principalmente por la baja complejidad que presentaba el testear “

CT Refactorización

“No se simplificó o mejoró el diseño, por falta de tiempo. Dieron "prioridad a prácticas que son más centradas en la producción de resultados rápidos y funcionales".

CT Desarrollo Guiado por Tests

“Por "ahorrar" tiempo se dejó de usar, pero problemas surgidos posteriormente indican que si debieron usarla.”

Page 167: Un modelo empírico de enseñanza de las metodologías ágiles

167

Alumno Concepto Problemas

AV Integración Continua

“En cada sesión trabajamos en 2 sectores diferenciados del código, hacia el final del día uníamos el código y terminábamos con un prototipo funcional, esta practica fue bastante útil para poder ver nuestro avance, lamentablemente hacia el final del proyecto la abandonamos y dado a eso hemos tenido problemas con la entrega final.”

AV Desarrollo Guiado por Tests

“Se intento aplicar, pero dado la complejidad de los test, y la necesidad de crear test para componentes ya creados el resultado no fue de gran calidad”

10.3.2 Proyecto XMLSync

Ciclo 1

Ciclo de generación de valor

Comprensión

Concepto Alumno Problema

Planning Game BB

confunde tareas con "historias de usuario", sin entender la diferencia

Entregables Pequeños BB

Indica lo bueno de un entregable pequeño para obtener feedback temprano , pero olvida lo fundamental: aportar valor lo antes posible al cliente

Concepto Alumno Errores

Planning Game TH

Entiende el planning game como un momento específico dentro del proyecto, y no vislumbra su proyección continua al resto de éste.

"en la segunda iteración, y cuando se debió cambiar el track del proyecto, no se realizo esta actividad y las tareas a desarrollar fueron generadas en conversaciones del grupo de desarrollo, solamente con la aprobación del cliente".

Tests de Aceptación CS El alumno no aporta la información suficiente para evaluar

Entregables Pequeños MV No aporta información suficiente para evaluar

Page 168: Un modelo empírico de enseñanza de las metodologías ágiles

168

Aplicación

Concepto Alumno Problemas de Aplicación

Cliente In Situ CM

“El cliente no ha sido parte del equipo”. “Fue cliente tradicional y quería soluciones y además complicadas” “El cliente no estuvo en todas las sesiones” “No supieron sacarle ‘el jugo al cliente’ "

Cliente In Situ CS

“Creo que ésta práctica es la que debemos atacar de forma mas decidida para el resto del proyecto, debido a su fuerte impacto, obviamente asumiendo que es posible contar con el tiempo del cliente.”

Cliente In Situ MV

“Dado que el proyecto es bastante complejo e involucra muchas decisiones de diseño, la ayuda del cliente ha sido fundamental, aunque nuevamente hay que hacer notar que el cliente es un tanto especial pues tiene conocimiento técnico y mucha experiencia y sobre todo, lo cual hace aún mas valiosa su ayuda. Tanto es así, que las veces en que ha faltado a las sesiones nos hemos sentido un tanto perdidos, pues a cada momento surgen dudas o decisiones que tienen que ser tomadas junto con él y que nos hacen difícil avanzar.”

Cliente In Situ CH

Su rol del coach le entrega una perspectiva distinta a los de sus compañeros:

“Nuestro cliente fue un poco reacio a ayudarnos en un principio, y no nos ha podido entregar ayuda para solucionar algunos problemas que hemos tenido. En algunos casos se comunica sólo conmigo y no con el resto del grupo, pese a que he delegado esa tarea (siento que no me corresponde delegar tareas, pero he tenido que hacerlo).”

Concepto Alumno Problemas de Aplicación

Planning Game CM

“Simplemente a que usábamos nuestro planning game para inventar soluciones a problemas que no existían aún. Creo que podemos mejorar en este aspecto si nos comprometemos todo el grupo más con el proyecto y nos esforzamos por empaparnos del problema a solucionar en el ‘hoy’.”

Planning Game CH

“Acá ha sido nuestro factor flaco. Hemos intentado definir metas, pero no ha sido una cosa donde aporten todos, y el tracker tampoco ha aportado en establecer horas. Yo por otro lado, ya he terminado haciendo esta labor solo, sin mucho interés, y aun cuando he tratado de delegar tareas, no ha resultado muy bien. No ha habido suficiente retroalimentación.”

Page 169: Un modelo empírico de enseñanza de las metodologías ágiles

169

Concepto Alumno Problemas de Aplicación

Tests de Aceptación CH

“El cliente no nos ha apoyado lo necesario en generar las pruebas, (y menos en el desarrollo), aún cuando le hemos pedido. Hemos debido insistir, par que el nos genere pruebas”

Tests de Aceptación CM

“Dificultad de obtener retroalimentación del cliente Dejaron pasar mucho tiempo sin feedback del cliente Usado solamente para finalizar la iteración, por lo que "se perdió de vista el objetivo por lo mismo"

Tests de Aceptación CS

“Los tests realizados por el cliente ha sido una práctica que tampoco hemos utilizado de buena forma, fueron realizados al final de la iteración, y dependientes de las restricciones que generamos después de desarrollado el software.”

Concepto Alumno Problemas de Aplicación

Entregables Pequeños CM

“No aportó mucho valor al proyecto. Al no usar Test de Aceptación, ‘ambas prácticas se hundieron juntas’.”

Entregables Pequeños MV

"Fue muy complicado el dividir el problema al principio en sub-tareas pequeñas, pues si no sabíamos muy bien como acercarnos siquiera a la solución, mal podríamos haber hecho una división apropiada en tareas suficientemente chicas que ni siquiera sabíamos si nos iban a ayudar, y entrábamos en conflicto con simple design”.

Entregables Pequeños CH

“mucho de mi trabajo ha sido adelantarme a la iteración por la petición del cliente, porque el en todo minuto está mirando al producto global y no a la iteración actual, y con ese guía, es difícil para el grupo (o quizás para mi), sólo enfocarme en el diseño simple para el entregable de esta iteración”

Concepto Alumno Evaluación

Cliente In Situ BB

“La práctica no fue llevada a cabo como es de esperarse en la metodología, no solo debido a este motivo sino también por la actitud algo tímida del grupo hacia el cliente. En muchas ocasiones se prefirió asumir lo que el cliente esperaba antes de preguntarle directamente. Esta actitud afortunadamente fue cambiando en el transcurso del proyecto y se logró una mejor comunicación con el cliente en las últimas sesiones de desarrollo.

Cliente In Situ CH

“el cliente participó aún menos, por la clara decepción de la primera entrega, en particular en momentos claves. Finalmente fue casi como un cliente de las metodologías normales, y no entregó mucho aporte al proyecto, más que de aprobar lo que nosotros creíamos que era lo que quería y podíamos hacer. Por otro lado, en todo momento el cliente siguió pensando que el proyecto estaba a mis cuestas y no en el resto del equipo, aun cuando yo mismo le insistiese que no era así. “

Page 170: Un modelo empírico de enseñanza de las metodologías ágiles

170

Concepto Alumno Problemas de Aplicación

Cliente In Situ MV

“Dado que el proyecto es bastante complejo e involucra muchas decisiones de diseño, la ayuda de Sergio ha sido fundamental, aunque nuevamente hay que hacer notar que el cliente es un tanto especial pues tiene conocimiento técnico y mucha experiencia y sobre todo, lo cual hace aún mas valiosa su ayuda. Tanto es así, que las veces en que ha faltado a las sesiones nos hemos sentido un tanto perdidos, pues a cada momento surgen dudas o decisiones que tienen que ser tomadas junto con él y que nos hacen difícil avanzar”.

Cliente In Situ CM

"en la primera iteración no supimos “sacarle el jugo” al cliente. Esto llevó a que el cliente no formara parte integrante del equipo. El

"El hecho de no presionarlo o como dijo él mismo: “apretarlo en un rincón” con preguntas y con soluciones para que diera opiniones. "Con el cliente formando parte integrante de nuestras “stand up meetings” y aportando ideas o por último diciendo “si, puede ser...” con algún esbozo de sonrisa argentina. Eso llevó a que el equipo cobrara fuerzas y lograra jugársela por el proyecto, llevándose tareas para la casa, que aportaban información valiosa a las horas de programación en clases."

Ciclo de desarrollo en equipo

Comprensión

Alumno Concepto Errores

MV Espacio de Trabajo Informativo

El mismo declara que no entiende su sentido: “no estoy entendiendo el sentido o la verdadera utilidad que tiene.”

MV Ritmo Sostenido

Toma literalmente el concepto de “40 horas a la semana”, por lo que indica que no se aplicó, pero luego indica que se logró un ritmo de trabajo adecuado.

CH Liderazgo Motivador

Tiene varias frases que indican su actitud de fondo:

“no le he dado mucha opción a los demás de dar opiniones (aunque no creo que hayan tenido muchas). “

” siento que nadie aparte de mi, está realmente interesado en el que el proyecto llegue a un éxito”

CH Retroalimentación de avance

No se entiende que el tracker es quien trasparenta la avances al grupo, y la “motivación” es un producto posible derivado de los avances logrados

“El medidor del avance, debe ser el que determina que los plazos se estén cumpliendo”

vs “Debe también ayudar al coach a motivar al grupo.”

Page 171: Un modelo empírico de enseñanza de las metodologías ágiles

171

Alumno Concepto Errores

CS Liderazgo Motivador No entrega información suficiente para hacer una evaluación

MV Liderazgo Motivador No entrega información suficiente para hacer una evaluación

Aplicación

Alumno Concepto Evaluación

MV Ritmo Sostenido

“A pesar que la mayoría de los días nos vamos más tarde del horario, no es tan grave dado que las sesiones ocurren solo una vez a la semana.

“En general trabajamos concentrados y constantes, además tenemos un compañero al lado, lo cual implícitamente nos incita a dar lo mejor y a no distraerse. Las salidas a comprar algo para comer o simplemente relajarse, ayudan significativamente.”

Alumno Concepto Problemas

CH Liderazgo Motivador

"no he logrado como Coach lograr que el resto del equipo trabaje mejor, solo he logrado que trabaje, porque me ha tocado tomar decisiones definitivas, y ver la idea general del proyecto (aún cuando se me ha dicho que no lo haga), pero aún así, siento que si no lo hubiese hecho, estaríamos aún más atrás en el avance del proyecto. La moral del equipo ha estado baja, en parte, por la dificultad del proyecto , y porque siento que nadie aparte de mi, está realmente interesado en el que el proyecto llegue a un éxito”

MV Espacio de Trabajo Informativo

“Lo usamos, pero quizá no le hemos sacado todo el provecho que hemos podido. Están las tareas realizadas, las tareas en curso, la estimación, pero quizás yo no estoy entendiendo el sentido o la verdadera utilidad que tiene.”

CH Retroalimentación de avance

“sólo está haciendo una labor de notificación del planning game, al profesor, y no al resto del equipo. Este rol también falla, porque no participa en el planning game”

CS Liderazgo Motivador

“se opta por lo que cada uno piensa es correcto y el coach aprueba, en vez de asegurarse preguntándole a un cliente que tiene la capacidad técnica para entender nuestras preguntas.”

Page 172: Un modelo empírico de enseñanza de las metodologías ágiles

172

Alumno Concepto Problemas

MV Liderazgo Motivador

“Siento a veces que tenemos ideas, pero no las transmitimos eficazmente y finalmente nos dejamos llevar por las decisiones del coach, y actuamos de forma pasiva. Creo que como no hemos logrado avances significativos, existe desazón en el equipo y estamos todavía en una nebulosa de la cual no nos será fácil salir. No es culpa del coach tampoco, es decir, cada miembro del equipo debe sentirse motivado por el proyecto y actuar en consecuencia.”

Ciclo de Programación Incremental de Calidad

Comprensión

Tema Concepto Alumno Errores

Programación de Calidad

Diseño Simple BB No aporta información suficiente para evaluar

Programación de Calidad

Refactorización TH No aporta información suficiente para evaluar

Programación de Calidad

Diseño Simple CH

“Generalmente uno debe hacer un diseño simple, (aunque sea desordenado) y después ordenarlo y generar un código limpio y entendible (esto permitirá después mayor comunicación).”

Programación en Equipo

Propiedad Colectiva de Código CM

No tiene claro el significado de la práctica debido a la poca cantidad de código generado.

Programación en Equipo

Propiedad Colectiva de Código CH No aporta información suficiente para evaluar

Programación en Equipo

Estándares de Código CM

No reconoció aplicación "Partimos programando como si nos hubiéramos puesto estándares".

Programación en Equipo

Estándares de Código MV No aporta información suficiente para evaluar

Aplicación

Concepto Alumno Problemas

Diseño Simple BB “Se desperdiciaron varas horas de desarrollo intentando diseñar la solución completa sin tener una buena visión del problema”,

Page 173: Un modelo empírico de enseñanza de las metodologías ágiles

173

Concepto Alumno Problemas

Diseño Simple CH

“En esto hemos tratado de hacer todo lo más simple posible, intentando basarnos en algo existente, para evitarnos la complejidad, pero el cliente en cada conversación piensa en lo que hay que desarrollar para adelante, y eso implica agregarle complejidad a las soluciones que hay que resolver”

Diseño Simple CM

“se intentó usar, lamentablemente, creo que por nuestra inexperiencia o por nuestra mente acostumbrada a las tareas cc10 (un curso anterior) no se hizo”

Diseño Simple CS

“En este punto también tenemos serios problemas. Por un lado tenemos una estrategia de sincronización basado en un software conocido, el cual es bastante complejo, y por otro lado tenemos un coach que no es receptivo en cuanto a nuevas ideas, por lo que en el desarrollo se limita a soluciones del coach, que no necesariamente son simples, e incluso en algunas ocasiones incomprendidas a cabalidad. Es difícil mantener un diseño simple cuando se pierde de vista, debido a seguir un modelo probado pero complejo, el algoritmo general del software. Para mejorar el uso del diseño simple es necesario el intercambio de ideas y brainstorm como grupo de la solución. Cuando todos tengamos claro el camino podemos limpiar el mismo de cualquier impureza.”

Diseño Simple MV

“A mi parecer, el área donde más hemos fallado. Ahora, siento que tampoco es culpa nuestra, es que en realidad el problema es muy complejo y mi sensación es que el equipo esta todavía muy perdido en el problema, siento además que no estamos seguros si lo que estamos desarrollando nos vaya a servir realmente para ir acercándonos a la solución”

Concepto Alumno Problemas

Desarrollo Guiado por Tests CH

“Hemos diseñado pruebas para los diseños, pero por la poca claridad del tema (y la falta de comunicación), los test terminan haciéndose al final, o no son los test que realmente interesan”

Desarrollo Guiado por Tests CM

“No considero que haya sido demasiado necesaria a este nivel del proyecto. Porque, como mencionaba, tenemos muy poco código programado, a lo más tenemos 100 o 200 líneas de código. Sin embargo, podría habernos sido útil para no seguir construyendo sobre barro. Porque encontramos, al integrar, que algunas funcionalidades fallaban.

Como decía, esto no fue para nada grave, pues se arreglaron en muy poco tiempo. A estas alturas, el tiempo que nos demoramos en arreglar las funcionalidades fue muchísimo menor al que hubiéramos utilizado en hacer tests para cada funcionalidad.”

Page 174: Un modelo empírico de enseñanza de las metodologías ágiles

174

Concepto Alumno Problemas

Desarrollo Guiado por Tests CS

“El desarrollo orientado a las pruebas ha sido una práctica muy difícil de usar durante el desarrollo, aún se programa y se crean tests al final para que cumplan lo que se cree programó con anterioridad. Este cambio de paradigma ha sido más fuerte de lo que esperaba, y ha encontrado gran resistencia. Creo no ser aún capaz de evaluarlo, debido a que no creo que haya sido respetado de una manera importante. Me llama la atención las estadísticas sobre su eficacia, pero creo que se necesita un mayor entrenamiento y supervisión para ponerlo en práctica.”

Desarrollo Guiado por Tests MV

“Al principio, lo usamos cuando desarrollamos las primeras tareas sobre adentrarnos a XML y C-sharp en código (agregar, modificar, borrar nodos). Después, cuando ya entramos en tareas más complicadas como sincronizar para el caso de la inserción, y similares, rápidamente volvimos a la antigua práctica de primero codificar las funciones, y luego programar los unit tests. Siendo honesto, al menos yo admito que caí en esos vicios. Nunca pude entender cómo programar un test para probar algo tan complicado y con tantos casos como la sincronización de XML’s. Tal vez si en la próxima iteración somos capaces de dividir mejor las tareas, hacerlas aún mas atómicas, es posible usar esta práctica en forma efectiva.”

Concepto Alumno Problemas

Integración Continua CH

“No ha resultado muy bien esto, y se ha tenido que dedicar una pareja de trabajo exclusivamente a esto sesión por medio, lo que puede ser bastante ineficiente, por el hecho de que no se está programando uniformemente en los grupos de trabajo”

Integración Continua CM “No hubiera sido demasiado útil, dado el poco código que tienen”

Integración Continua MV

“Nos ha faltado eso de al final de cada sesión de trabajo dejar algo de tiempo para juntar lo desarrollado, siento que las cosas como que quedan un poco en el aire, no quedan suficiente aterrizadas en un programa ejecutable que muestre el avance de tal sesión. Es también un problema de tiempo y de no planificar estas tareas que son necesarias.”

“El control de versiones, este problema es tremendamente complejo, de hecho, es el problema.”

Refactorización CH

“Yo en particular traté de incitar que se haga todo de manera ordenada y funcional (todo lo repetido se refactoriza), pero he logrado poco éxito, por las formas de programar de los demás.”

Refactorización CM “No tuvimos necesidad de usarlo”

Page 175: Un modelo empírico de enseñanza de las metodologías ágiles

175

Refactorización CS

“Hemos utilizado muchos esta práctica, pero de manera desordenada, nos falta establecer un orden lógico de cada uno de los módulos del software (como unidades de código), para de ésta forma realizar refactoring solo las veces que sea necesario realizarlo. Debo hacer notar la necesidad que hemos tenido a lo largo de todo el proyecto de una herramienta de sincronización, ya sea CVS u otra solución, esto se ha traducido en serios problemas de orden de archivos en el proyecto, siendo una razón más para el excesivo refactoring que hemos sufrido.”

Concepto Alumno Problemas

Estándares de Código CH

“En esto he hecho lo posible para comunicar algunos estándares de codificación (programar en un dll independiente del test, documentar, etc.), pero no hemos podido concretar en todos los grupos el mismo esquema.”

Concepto Alumno Problemas

Programación de a Pares TH

“Dada su naturaleza, es una de las prácticas más difíciles de asimilar, ya que generalmente uno esta acostumbrado a desarrollar en solitario, siendo uno su propio crítico y jefe. “

Programación de a Pares CS

“Sin embargo en momentos de tensión, o de necesitarse rapidez al desarrollar, aún se tiende a dividir el trabajo de a una persona, lo que supone que aún no nos creemos realmente que es mejor y más rápida la programación de a pares, sino que la estamos probando por que el ramo nos lo pide.”

Concepto Alumno Problemas

Propiedad Colectiva de Código CH

“En lo personal siento que todo el código es mi responsabilidad, excepto el código externo, y es este el que nos ha causado más problema”

Propiedad Colectiva de Código MV

“no ha habido una real “rotativa” del equipo sobretodos los temas, y siento que aún hay mucha incertidumbre. Ojalá en la segunda iteración cambiáramos todos la línea de las tareas que hemos ido desarrollando, para que todos tengamos esa visión “overall” del sistema.”

Page 176: Un modelo empírico de enseñanza de las metodologías ágiles

176

Concepto Alumno Comentario

Propiedad Colectiva de Código CM

“Usamos esta práctica y resultó muy bien. Creo que esto se logró por el poco código que tenemos. Si no hubiera sido por eso... creo que hubiéramos necesariamente tenido que recurrir al refactoring.”

Ciclo 2

Ciclo de generación de valor

Comprensión

Concepto Alumno Errores

Planning Game TH

"en la segunda interacción, y cuando se debió cambiar el enfoque del proyecto, no se realizo esta actividad y las tareas a desarrollar fueron generadas en conversaciones del grupo de desarrollo, solamente con la aprobación del cliente".

Tests de Aceptación CS El alumno no aporta la información suficiente para evaluar

Aplicación

Concepto Alumno Evaluación

Cliente In Situ BB

“La práctica no fue llevada a cabo como es de esperarse en la metodología, no solo debido a este motivo sino también por la actitud algo tímida del grupo hacia el cliente. En muchas ocasiones se prefirió asumir lo que el cliente esperaba antes de preguntarle directamente. Esta actitud afortunadamente fue cambiando en el transcurso del proyecto y se logró una mejor comunicación con el cliente en las últimas sesiones de desarrollo.”

Cliente In Situ CH

“el cliente participó aún menos, por la clara decepción de la primera entrega, en particular en momentos claves. Finalmente fue casi como un cliente de las metodologías normales, y no entregó mucho aporte al proyecto, más que de aprobar lo que nosotros creíamos que era lo que quería y podíamos hacer. Por otro lado, en todo momento el cliente siguió pensando que el proyecto estaba a mis cuestas y no en el resto del equipo, aun cuando yo mismo le insistiese que no era así. “

Cliente In Situ MV

“Dado que el proyecto es bastante complejo e involucra muchas decisiones de diseño, la ayuda de Sergio ha sido fundamental, aunque nuevamente hay que hacer notar que el cliente es un tanto especial pues tiene conocimiento técnico y mucha experiencia y sobre todo, lo cual hace aún mas valiosa su ayuda. Tanto es así, que las veces en que ha faltado a las sesiones nos hemos sentido un tanto perdidos, pues a cada momento surgen dudas o decisiones que tienen que ser tomadas junto con él y que nos hacen difícil avanzar”.

Page 177: Un modelo empírico de enseñanza de las metodologías ágiles

177

Cliente In Situ CM

"en la primera iteración no supimos “sacarle el jugo” al cliente. Esto llevó a que el cliente no formara parte integrante del equipo. El

hecho de no presionarlo o como dijo él mismo: “apretarlo en un rincón” con preguntas y con soluciones para que diera opiniones.Con el cliente formando parte integrante de nuestras “stand up meetings” y aportando ideas o por último diciendo “si, puede ser...” con algún esbozo de sonrisa argentina. Eso llevó a que

el equipo cobrara fuerzas y lograra jugársela por el proyecto, llevándose tareas para la casa, que aportaban información valiosa a las horas de programación en clases."

Concepto Alumno Evaluación

Planning Game

CH

“En el planning game de la primera iteración, por mi proactividad, generalmente era el primero en dar ideas, y temas de planificación, lo que causaba que mis compañeros de equipo se quedaran callados sin nada que aportar. Por esto, se encontró que mi labor de coach fue autoritaria, y dictatorial, lo que en un minuto terminó siendo bastante cierto, por la costumbre. Eso si, en la segunda iteración el planning game se hizo más efectivo, porque decidí, como parte de dejar de ser coach, también dejar de ser el primero que hablaba, y por tanto cedí mi opción de hablar primero para que los otros del equipo fueran los que tomaran las decisiones de planning game. Esto causo que los planning game fueran mucho más lentos, pero eso causo que los compañeros del grupo se tuvieran que (un poco a la fuerza) interesar en el proyecto y dar ideas, cosa que en la primera iteración ocurrió en baja medida. Esta vez, los planning game, fueron bastante más desorganizados en términos de definir las horas de trabajo, ya que estábamos todos tratando de sacar el proyecto adelante, más que de seguir las buenas prácticas. “

Planning Game

CM

“Sólo hasta unas 2 o 3 semanas antes del fin de la 2da y última iteración nos vinimos a dar con un planning game como la gente que dijera: “basta, por aquí no va la cosa, o lo hacemos de otro modo o el proyecto se muere catastróficamente”.

“Para llegar a este punto tuvimos que contar con la ayuda del profesor que actuó como coach alternativo. Con esto hicimos un nuevo planning game con el cliente y replanteamos la solución a nuestro problema por medios alternativos.”

Concepto Alumno Evaluación

Tests de Aceptación BB

“Los tests de aceptación fueron hechos al final del desarrollo y mostrados al cliente, quién mostró poca satisfacción con el resultado de estos”

Page 178: Un modelo empírico de enseñanza de las metodologías ágiles

178

Tests de Aceptación CH

“El cliente dejó su test antiguo, y no se motivó a darnos nuevos tests. Por esto, tuvimos que hacer tests nosotros, y validar el ejecutable con estos tests. Si el cliente usará o no tests propios para validar el ejecutable, lo hará fuera de nuestra vista."

Concepto Alumno Evaluación

Entregables Pequeños BB

“Esta es otra práctica mal desempeñada durante el desarrollo del proyecto. La mala decisión de diseño inicial y una constante fijación en encontrar una herramienta previa en vez de desarrollar una solución propia, llevaron a un atraso general en el desarrollo del proyecto”.

Entregables Pequeños CH

“Con respecto a las entregas pequeñas, no existieron muchas después de la primera iteración, dado que la entrega final ya era pequeña en si, en comparación con lo inicial, dejando en “pequeño” un término algo subjetivo”.

Entregables Pequeños CM

“Se usó también esta práctica, y a partir de la primera entrega, al fin de la primera iteración, fue útil. Creo que no cumplimos el objetivo real de ésta práctica al entregar pequeños programas totalmente funcionales, puesto que nuestros entregables al principio eras casi “parchados” y muy poco robustos, pero por lo menos nos dieron el ánimo de estar entregando un poco de valor al cliente”.

Entregables Pequeños CS

“Debido a los múltiples problemas enfrentados durante el proyecto no fue posible realizar entregas pequeñas, esto es directa consecuencia de la naturaleza del problema, pues su divisibilidad es baja.”

Entregables Pequeños MV

Una mayor comprensión del problema permitió dividirlo y enfrentar el desafío de generar un entregable pequeño. “Luego de adentrarnos y madurar un poco el entendimiento del problema, pudimos establecer tareas pequeñas como “sincronizar en el caso de inserción”, “en caso de eliminación”.

Ciclo de desarrollo en equipo

Comprensión

Concepto Alumno Errores de comprensión

Ritmo Sostenido TH

“Se contaba con aproximadamente 3 horas semanales para realizar la Stand-up Meeting, desarrollar y conversar con el cliente. A demás, estas horas estaban todas juntas en un solo día, lo que hacia que el horario no fuera homogéneo a lo largo de la semana, lo que torno casi imposible llevar un ritmo sostenible.”

Ritmo Sostenido MV Indica "Claramente no" pero luego dice que si hubo un buen ritmo de trabajo

Concepto Alumno Errores de comprensión

Liderazgo CS No hay información suficiente para evaluar

Page 179: Un modelo empírico de enseñanza de las metodologías ágiles

179

Motivador

Liderazgo Motivador MV No hay información suficiente para evaluar

Aplicación

Concepto Alumno Problemas

Liderazgo Motivador CM

“Yo creo que principalmente fue por la visión que estábamos acabando el proyecto y estábamos llegando a ningún buen fin. Esto fue muy influenciado creo yo por el cambio de coach y de tracker en el equipo que hubo, lo que produjo que se renovara un poco el espíritu. Los nuevos coach y tracker integraron al cliente en el proyecto como de igual a igual (principalmente impulsados, repito, por la desesperación de ver que teníamos casi nada muy útil) y con esto lograron expandir al resto del equipo, incluyendo el cliente, el conocimiento general de en qué condiciones estaba el proyecto y cómo lograr llegar a soluciones concretas (aunque ni el mismo coach creo que veía la luz)”. “Para llegar a este punto tuvimos que contar con la ayuda del profesor que actuó como coach alternativo. Con esto hicimos un nuevo planning game con el cliente y replanteamos la solución a nuestro problema por medios alternativos”.

Liderazgo Motivador TH

“Al principio, el Coach simplemente fue como el Jefe de Proyecto, es decir, era quien integraba todos los conocimientos del grupo, quien hablaba con el cliente y quien tenia la ultima palabra en decisiones de asignación de tareas, etc. Sin embargo, el Coach nunca se preocupo de la parte motivadora de su trabajo, de mantener al equipo contento con el trabajo, de felicitar por logros realizados, o de asignar tareas en las cuales algunos se habían sentido más cómodos. Esa parte del Coach nunca existió.”

Liderazgo Motivador CH

“(El equipo) encontró que mi labor de coach fue autoritaria, y dictatorial, lo que en un minuto terminó siendo bastante cierto, por la costumbre. Eso si, en la segunda iteración el planning game se hizo más efectivo, porque decidí, como parte de dejar de ser coach, también dejar de ser el primero que hablaba, y por tanto cedí mi opción de hablar primero para que los otros del equipo fueran los que tomaran las decisiones de planning game. Esto causo que los planning game fueran mucho más lentos. En particular, BB tomo la labor de coach y se la pudo tomar con más ánimo y liviandad (lo ideal), en particular porque no teníamos ya nada que perder, puesto que en nuestro proyecto llevábamos efectivamente nada, dado que gran parte del código desarrollado se perdió, por el track elegido. Con el nuevo coach, la moral del grupo, y mi moral de participante subió (por el relajo de no ser coach), y pudimos avanzar por tierra derecha”

Liderazgo BB Se abstiene de opinar, por ser el mismo el nuevo coach

Page 180: Un modelo empírico de enseñanza de las metodologías ágiles

180

Motivador

Liderazgo Motivador CS

“Se contó con un liderazgo asignador, la motivación entregada no se sintió, y simplemente se dividían tareas según su propia visión del problema.

Liderazgo Motivador MV

“Siento a veces que tenemos ideas, pero no las transmitimos eficazmente y finalmente nos dejamos llevar por las decisiones del coach, y actuamos de forma pasiva. Creo que como no hemos logrado avances significativos, existe desazón en el equipo y estamos todavía en una nebulosa de la cual no nos será fácil salir. No es culpa del coach tampoco, es decir, cada miembro del equipo debe sentirse motivado por el proyecto y actuar en consecuencia.”

Concepto Alumno Comentario

Espacio de Trabajo Informativo BB

“Todas las tareas estaban visibles en papeles postix amarillos pegados a la pared, los cuales estaban ordenados por funcionalidad e indicaban la estimación de esfuerzo”

Espacio de Trabajo Informativo TH

“El radiador de información se encontraba presente pero este no era visto y consultado periódicamente por el grupo de desarrollo mas que para actualizar las tareas. La única utilización que se le dio fue en las Stand-up Meetings,”

Espacio de Trabajo Informativo CH

“se reemplazo el papel craft, usado en la primera iteración, que fue una buena idea, pero al final nadie lo miraba (por la cantidad de tareas, y el tamaño), por escribir directamente en el pizarrón (de manera menos ordenada, pero en frente de todos), de manera poder verlo. En ese sentido, todos teníamos más claro que tareas nos tocaban, y por tanto se cumple en mayor medida el objetivo de esta práctica, aun cuando su aplicación fue bastante mas desordenada.”

Espacio de Trabajo Informativo CM

“No se dieron tiempo de actualizarlo seriamente. Sin embargo las Stand up meetings hicieron el papel de informativo excelentemente, y lo que pudo faltar por ambiente informativo, lo lograron las stand up meetings.”

Concepto Alumno Comentario

Stand Up Meeting BB

“Lo único que puede haber jugado algo en contra de esta práctica fue la poca puntualidad del equipo y la falta de asistencia. Exceptuando eso, esta práctica fue desempeñada satisfactoriamente.”

Page 181: Un modelo empírico de enseñanza de las metodologías ágiles

181

Stand Up Meeting CH

“Con respecto al Stand Up Meeting, por motivos de que todos llegaban tarde, o algunos faltaban, no se hicieron siempre . Pero en la segunda iteración, por la mayor motivación se llevaron a cabo estos stand up meeting con un poco más de entusiasmo, pero en general sin muchas opiniones si no eran presionadas (mis opiniones las dejaba para el final). En todo caso, fue mejor, porque todos aportaron, aunque alargó mucho más esta práctica”

Ciclo de Programación Incremental de Calidad

Comprensión

Tema Concepto Alumno Error

Programación de Calidad Diseño Simple CH

“El diseño simple no se aplicó mucho, ya que en ellla se empezó de cero utilizando código existente, y solo arreglando lo que funcionaba mal, y borrando lo que no necesitábamos”. Justamente acá el alumno está expresando una estrategia de diseño directo a resolver el problema que es exactamente un diseño simple.

Programación de Calidad Diseño Simple CS

“Un gran problema tenido durante el semestre, debido principalmente a la adopción de una estrategia de sincronización externa, de alta complejidad y difícil entendimiento, muchas secciones del código siguen una pauta definida por un programa externo, que para el grupo en ningún momento fue “simple””.

Programación de Calidad Diseño Simple Biedderman

“Una vez comenzado el desarrollo esto fue facilitándose y comenzó a mejorar. Pero en ningún momento hubo un diseño simple y funcional. Finalmente se portó otra solución, lo que significó que no hubo mucho diseño involucrado.”

Programación de Calidad Diseño Simple MV

“A mi parecer, el área donde más fallamos. Ahora, siento que tampoco es culpa nuestra, es que en realidad el problema fue muy complejo y que el equipo estuvo muy perdido en el problema”

Page 182: Un modelo empírico de enseñanza de las metodologías ágiles

182

Tema Concepto Alumno Errores

Programación de Calidad Refactorización BB No aporta información suficiente para evaluar

Tema Concepto Alumno Errores

Programación en Equipo

Propiedad Colectiva de Código CH

“es mi opinión, que como no programamos nosotros el código, difícilmente podemos sentirnos dueños del código, ni individual, ni colectivamente, por la forma en que se terminó el proyecto”

Programación en Equipo

Propiedad Colectiva de Código CM

“hubo que perder tiempo preguntando "oye qué hiciste en este pedazo de código?" y eso es totalmente contrario a la práctica”

Tema Concepto Alumno Errores

Programación en Equipo

Estándares de Código CS

“No se llego a ningún acuerdo, ni tampoco fue conversado.”

Programación en Equipo

Estándares de Código MV

“En realidad no sé si para el tamaño del proyecto llegue a ser necesario definir estándares de codificación, además esto toma algo de tiempo y creo que en este momento que siento que no hemos avanzado mucho, priorizar el desarrollar algo realmente útil para el cliente.”

Page 183: Un modelo empírico de enseñanza de las metodologías ágiles

183

Aplicación

Tema Concepto Alumno Comentarios

Programación de Calidad

Diseño Simple TH

“Por otro lado, se buscó la simplicidad en todas las iteraciones, pero desgraciadamente, no resultó muy bien en la primera iteración (pese a que se miró de la manera más simple posible, dado el estado del grupo en ese momento). En la segunda iteración, se buscó otra solución simple y funcionó mejor.“

Programación de Calidad

Diseño Simple CM

“Aunque la segunda iteración nos faltó mucho de SimpleDesign, sin embargo siento que la usamos (no a cabalidad, pero un gran poco que nos resultó ser el salvador de nuestro proyecto) casi al finalizar la segunda iteración. Lo noté particularmente al “estremecer” del salir a flote del proyecto, en aquél quiebre de Microsoft XMLDiff y entrada de XMiddle. Aquí vimos que realmente teníamos poco tiempo y comenzamos con la verdadera metodología ágil. Desechamos muchos de los detalles inservibles para nuestro proyecto que había en las librerías JAVA de XMiddle y decidimos hacer un conjunto minimal de este XMiddle que llenara los requisitos pedidos por el cliente”

Tema Concepto Alumno Problemas

Programación de Calidad

Desarrollo Guiado por Tests BB

El desarrollo de todo el proyecto fue guiado por tests. Antes de cada funcionalidad se programó el test y este debía ser satisfactorio para declarar realizada una funcionalidad o tarea. Inicialmente se usó el sistema de tests de unidad programados en Visual Studio. Más adelante en el proyecto los test consistían en verificar que la mezcla de archivos XML fuera según lo especificado por los requerimientos, lo que llevó a una serie de tests manuales. Estos test constaban de archivos de ejemplo que especificaban la entrada y salida esperada. De esta manera se programaba la funcionalidad y se ejecutaba la aplicación. El test era aprobado si la salida del programa era la esperada.

Programación de Calidad

Desarrollo Guiado por Tests TH

"..en un comienzo, se desarollaron los test antes de crear las clases a ser probadas, pero a medida que avanzaba el proyecto, desarrllábamos clases antes de desarrollar los test, lo que no cumple rigurosamente con TDD".

Page 184: Un modelo empírico de enseñanza de las metodologías ágiles

184

Programación de Calidad

Desarrollo Guiado por Tests CH

En la segunda iteración, se eliminaron los units, para trabajar finalmente siempre con un ejecutable que ejecutara tests, finalmente este ejecutable se modificó para hacer el entregable final.

Programación de Calidad

Desarrollo Guiado por Tests CM

Estoy consciente que esta práctica debe ser muy útil, pero no pude darme cuenta con este proyecto.

Programación de Calidad

Desarrollo Guiado por Tests CS

El desarrollo guiado por tests no fue utilizado de forma consistente, si bien este se aprendió al inicio del semestre la poca confianza tomada por el grupo de trabajo en el sistema no permitió su real uso.

Programación de Calidad

Desarrollo Guiado por Tests MV

Al principio, lo usamos cuando desarrollamos las primeras tareas sobre adentrarnos a XML y C# en código (agregar, modificar, borrar nodos). Después, cuando ya entramos en tareas más complicadas como sincronizar para el caso de la inserción, y similares, rápidamente volvimos a la antigua práctica de primero codificar las funciones, y luego programar los unit tests. Siendo honesto, al menos yo admito que caí en esos vicios. Nunca pude entender cómo programar un test para probar algo tan complicado y con tantos casos como la sincronización de XML’s.