Está en la página 1de 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
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.

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

3
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 I NGENIERÍ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

4
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

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

6
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

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

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

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

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

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

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

13
Uso de Funcionalidades de
Software
Siempre
7%
Frecuente
mente
13%
Nunca
Algunas 45%
veces
16%

Raramente
19%

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

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

15
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 Procesos y herramientas.


Software funcional Documentación exhaustiva
por sobre
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)

16
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és 11) 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:
Bajo Acuerdo

u ía
q
ar
Requerimientos

A n

Complejo
Complicado
Alt o Acuerdo

Simple Complicado

Alt a Cert eza Baja Cert eza


Tecnología

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

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

funcionalidades
funcionalidades

tiempo tiempo
Valor entregado de un proyecto tradicional Valor ideal que debiera entregar un proyecto

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.

18
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.
Costo del Cambio

Costo del Cambio


Requerimientos Análisis Diseño Implementación Producción Requerimientos Análisis Diseño Implementación Producción
Tiempo Tiempo
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:

19
Derechos del cliente Derechos del desarrollador
 Tener un plan global, y conocer qué  Conocer qué se necesita, con
puede ser logrado, cuándo y a qué costo prioridades declaradas claramente
 Obtener el mayor valor de cada semana  Producir trabajo de calidad en todo
de desarrollo momento.
 Observar el progreso en un sistema  Pedir y entregar ayuda por
funcional, cuyo funcionamiento puede compañeros, superiores y clientes
ser probado por ejecuciones exitosas de
 Actualizar las estimaciones ante nuevos
pruebas repetibles que él puede
descubrimientos técnicos
especificar
 Aceptar responsabilidades en vez de
 Cambiar de opinión, canjear
que le sean asignadas.
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
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].

20
El ambiente de desarrollo de software y el aprendizaje

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:
Desarrollador - ¿Cuál tecnología usar?
Problema en Cliente
resolución: ¿Concuerdan? - ¿Qué sabemos hacer con

¿Concuerdan?
- ¿Cuáles son la la tecnología utilizada?
necesidades actuales? - ¿Cuáles es posible hacer
- ¿Cuáles son (limites) con la
prioritarias? Trabajo en Equipo: tecnología?
- ¿Cómo mantener la motivación?
- ¿Cómo comunicarse efectivamente?
- ¿Hay áreas del proyecto que sólo
?
puedan ser mantenidas por uno?

Equipo de Desarrollo
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.

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

22
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 “Desarrollo guiado por pruebas”, en donde cada segmento del
estructurado del sistema 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 “Cliente in situ”, en donde el cliente es integrado 100% al quehacer
dominio del problema a del grupo como un experto en el dominio a resolver
resolver, y de la estrategias de “Metáfora” que indica qué se debe construir, un lenguaje común
solución entre clientes y desarrolladores usando una comparación
metafórica que facilite el entendimiento del sistema a desarrollar
Conocimiento compartido de la “Planning Game”, que consiste en un juego colaborativo, en donde
estrategia de solución 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 “Estándares de código”, en donde el equipo norma un conjunto de
comunicable 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 “Propiedad colectiva de código”, todos los desarrolladores son
sistema, como una forma de responsables y dueños de todo el código del sistema. Esto se
evitar dependencias excesivas refuerza por “Programación de a pares” y “Mantener el equipo
en un desarrollador específico 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:

23
Principio Explicación
Debe darse a todo nivel, entre desarrolladores y con el cliente. Se entiende
Comunicación abierta y
como la única forma de generar real confianza y un trabajo efectivo en
honesta
equipo, evitar malos entendidos y poder prevenir a tiempo problemas
Es aprovechar las características distintivas de cada persona a favor del
Trabajar con los instintos proyecto, en vez de reprimirlas. Por ejemplo, si alguien se expresa mejor a
de las personas partir de gráficos, motivarlos a su uso, entendiendo eso sí que la verdad
definitiva del software está en lo realmente programado
Responsabilidad aceptada En un equipo XP no se imponen tareas, sino que se exponen necesidades y
(antes que asumida) cada cual se ofrece para aquella para la cual se considere mejor preparado.
Relacionada con el coraje; implica abordar los mayores riesgos o problemas
Atacar problema urgente,
con decisión, definiendo alternativas para resolverlos, y evaluando cada uno
dejando la mayor cantidad
con experimentos pequeños que permitan tomar una decisión informada
de opciones
acerca del camino a seguir.
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
Viajar con equipaje: poco,
documentación, o a los frameworks para realizar pruebas de unidad como
simple y valioso
JUnit, pero evita la dependenciar de grandes y costosas suites de desarrollo
para poder gestionar un proyecto de software.
Cada proyecto tiene su propia realidad por lo que cada equipo deberá
Adaptación local seleccionar aquellas prácticas de XP que mejor le sirvan, complementándolas
con otras originadas en otras metodologías si es necesario
Cada equipo debe mantener un fuerte compromiso con el aprendizaje rápido
Enseñar a aprender y continuo de todos, tanto del proceso de desarrollo, como del problema de
negocio o de las tecnologías ocupadas
Mantener una actitud positiva y optimista orientada a lograr el éxito del
Jugar a ganar
proyecto
Cada producto desarrollado debe tener la mayor calidad posible. Esto no es
Trabajo de Calidad
negociable
Asumir siempre
simplicidad Debe privilegiarse siempre la solución más simple que pueda funcionar.
“Hacer lo más simple que Representada por la sigla YAGNI12
posiblemente funcione”
El trabajo es siempre realizado en incrementos pequeños, lo que permite
Cambios paso a paso
tener que validar cada vez cosas pequeñas, y si se ha fallado, perder poco
Mientras antes sepamos algo, antes se puede reaccionar. Esta
retroalimentación puede venir del cliente, del propio sistema o de la forma
Retroalimentación rápida
en que está trabajando. Representado por la frase “Fail fast” (si algo va a
fallar, que falle antes y con el menor costo posible)
Hay que validar cada decisión abstracta o duda que se tenga con
Experimentos concretos
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 realme nte
se va a necesitar o no. Ver http://c2.com/xp/YouArentGonnaNeedIt.html

24
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

25
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.
entregable
entregablepequeño
pequeño

completar entregar
plan entrega completar entregar
plan entrega iteraciones software
iteraciones software

planning game iteración


planning game iteración

estimar escribir
escribir estimar priorizar planificar completar escribir
escribir historias de priorizar planificar completar tests de
historias historias de historias iteración tareas tests de
historias usuario historias iteración tareas aceptación
usuario aceptación

planificar iteración tarea


planificar iteración tarea
completar
seleccionar dividir estimar asumir escoger listar ítemes completar
seleccionar dividir estimar asumir escoger listar ítemes
historias historias en tareas tareas par por hacer ítemes por
historias historias en tareas tareas par por hacer ítemes por
tareas hacer
tareas hacer

código de colores ítem por hacer


código de colores ítem por hacer

equipo Escribir
equipo cliente desarrollo escribir Escribir refactorizar integrar
completo cliente desarrollo escribir código que refactorizar integrar
completo test código que sin piedad código
test cumple test sin piedad código
cumple test

Ilustración 8: Ritmos de XP 14

14 Fuente: www.diamond-sky.com

26
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.
On Site Customer

Planning Game
40 Hours Week
Metaphor

Refactoring Simple Design

Short Releases
Testing
Pair Programming

Coding Standards

Collective Ownership Continuous Integration

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.

27
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
Defensiva, con cláusulas de Colaborativa en pro del éxito del
Relación cliente-
castigo en caso de no proyecto
desarrollador
cumplimiento
Ciclo de vida Cascada Iterativo
Guía de debe cumplirse Guía que debe ajustarse continuamente
Rol de la planificación
estrictamente a la realidad
Exponencial a medida que Puede lograrse un costo constante
Costo del cambio
avanza el proyecto
Actitud frente al cambio de Enojo, miedo, a la defensiva Positiva, empática con la necesidad que
requerimientos origina el cambio
Tipos de Contratos De precio, tiempo y alcance fijos De alcance variable
Principalmente el comienzo del Emergente a media que se conoce con
proyecto, y del sistema certeza cada incremento del sistema a
Esfuerzo de diseño
completo15 construir. “Lo más simple que pueda
funcionar”
Priorización del esfuerzo Según la perspectiva técnica Según la perspectiva del cliente
Proceso bien definido, que debe Personas bien formadas que comparten
Herramienta para mejorar
seguirse y controlarse un conjunto de valores, principios y
el éxito de los proyectos
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

28
Aspectos Tradicional XP
Documentación exhaustiva y Documentación somera, pero útil para
abstracta de requisitos y constituir una base de conversación de
Herramientas de
diseño, principal medio de “banda ancha” entre clientes y
comunicación
comunicación entre clientes y desarrolladores
desarrolladores
Dedicar muchas horas extra a la Dedicar las horas de una jornada normal
Indicador de compromiso
jornada laboral para completar a producir al ritmo más elevado de
con la empresa
las tareas calidad
Vertical, la responsabilidad está Horizontal, el coach tiene un rol de guía
Liderazgo del equipo centrada en el jefe de proyecto y de formador hacia la toma de buenas
decisiones por parte de todos.
Saber siempre Saber expresar claramente lo que
Indicador de capacidad del domina, saber pedir apoyo frente a
desarrollador 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
Programar, probar, depurar, probar, Definir la prueba, programar el código
Ciclo de
depurar, etc. más simple que pase la prueba (Desarrollo
programación
Guiado por Pruebas)
Costo de hacer Más que simplemente programar la Menos, debido a que se evitan ciclos
pruebas solución eternos de depuración
Complejo, previendo muchos casos Simple, lo justo y necesario para lo que
que “podrían alguna vez estamos seguros de necesitar ahora. Para
necesitarse”, (también llamado mantener la simpleza, se refactoriza “sin
“sobrediseño”) piedad” para evitar cualquier duplicación
Diseño
de funcionalidad en el código. Nunca
permanece en el sistema código que no
tenga aplicabilidad directa al problema a
resolver
Dos personas trabajando en una sola Dos personas en un mismo esfuerzo
Trabajo en solitario tarea es un desperdicio, es mejor implica mejores soluciones, menos
versus de a pares paralelizar esfuerzos. defectos y en definitiva, un desarrollado
de calidad más acelerado
Responsabilidad El que estima es un experto, El que estima es la persona que asume la
sobre las usualmente el jefe de proyecto responsabilidad de ejecutar la tarea
estimaciones
Cada desarrollador está a cargo de La propiedad del código es de todo el
una parte del código. Suele equipo, que rota, de a pares
generarse dependencia de un constantemente en la implementación de
Propiedad del código
desarrollador específico debido a funcionalidades
que es el único que conoce cómo
está hecha una parte del sistema
Tabla 8: Comparación entre prácticas de desarrollo tradicional y XP

29
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 1. Estimar tareas colectivamente
2. Estimar las tareas propias 2. Inscribirse en las tareas
3. Re-balancear si alguien está sobrecargado
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

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

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

32
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

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

35
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 Problemas bien Problemas definidos
emergentes definidos vagamente
producen: Significado negociado, y Significados fijos, y Significado negociado, y
entendimiento construido conceptos inmutables entendimiento construido
socialmente 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:

36
Contexto del Taller de Oficios Contexto de la Sala de Clases
Visibilidad del Simple, debido a que la tarea es El profesor debe hacer visible su
aprendizaje observable en la construcción del razonamiento.
producto
Surgimiento de Naturalmente, por requerimientos El profesor debe enseñar materias del
tareas de construcción de productos currículum (matemáticas, ciencias,
tangibles 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 Inherentes y restringidas al oficio. Los alumnos deben transferir sus
practicar (Ejemplo: un aprendiz de sastre debe aprendizajes a otros contextos. El
aprender a medir y cortar tela, y no a profesor debe presentar un conjunto de
cortar piezas de roca o madera, como tareas en contextos distintos, y luego
lo hace un escultor) 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:

37
APRENDIZAJE COGNITIVO
Flujo del modelo pedagógico

Profesor Aprendices
Recopilación Estrategias Expertas
Considerar las estrategias que un experto
aplicaría en una tarea.

Diseño soportes instruccionales


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

Práctica Guiada (Coaching)


ofrecer retroalimentación y consejo practicar habilidad resolviendo el
experto desafío

Metacognición
Articulación
Motivación Verbalizar los razonamientos y métodos usados
Motivar en sus alumnos la para resolver el desafío, (metacognición)
metacognición

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

Exploración
Retirar paulatinamente el Aplicar estrategias a nuevos
apoyo problemas.

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

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

Computing Curricula 2001 Structure


Overview
Joint Task Force on
Computing Curricula

ACM Information Systems


Computer Science IEEE Computer Society
Other societies ?? ACM
Computing Curriculum 2001 Association for Information
Steering Committee Systems (AIS)
Association of Information
ACM Technology Professionals
IEEE Computer Society (AITP)
IEEE Computer Society

Computer Engineering Software Engineering Information Technology

Computing Curriculum - Computing Curriculum - Computing Curriculum -


Computer Engineering Software Engineering Information Technology
Steering Committee Steering Committee Steering Committee

ACM ACM ACM


IEEE Computer Society IEEE Computer Society IEEE Computer Society
Several other societies

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

39
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

40
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

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

42
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

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

44
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

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

46
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

47
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

48
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

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

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

51
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  Un diseño instruccional que configura un curso
ingeniería de software una experiencia de ingeniería de software en un ambiente de
representativa de las metodologías trabajo representativo de XP.
ágiles - en particular Extreme
Programming – dentro del marco,
recursos y tiempo de un curso normal
de la carrera.
Al reproducir fielmente un ambiente de  Una conceptualización de cómo XP organiza el
trabajo ágil se obtienen buenos ambiente de un desarrollo de software para
resultados en los aprendizajes de los lograr armonizar los diversos componentes de
alumnos gracias a la naturaleza del éste y lograr así una construcción continua de
ambiente ágil orientado a potenciar el conocimiento y valor.
aprendizaje continuo en sus
integrantes.  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

52
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 En XP se abarcan ambos aspectos de forma balanceada, integrando
gestión 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 La técnicas de XP son más proclives al enfoque empírico, ajustando los
experiencia formalismos sólo a lo que acuerde el equipo de trabajo
Distribución 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
Internet
transformadas en herramientas han sido rápidamente adoptadas por un
Proliferación de sinnúmero de plataformas, como sucede en el caso de los frameworks de
herramientas y testing unitario para el desarrollo guiado por pruebas, que existen para la
ambientes de mayoría de los lenguajes y plataformas actuales.
desarrollo
Plataformas
computacionales
Computación XP soporta directamente el desarrollo interdisciplinario, al integrar en el
penetrante/ equipo de desarrollo al cliente y al generar un lenguaje común mediante la
interdisciplinaria 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.

53
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 Es un punto abordado directamente por XP. Se propone un sistema de
en equipo 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 XP obviamente propone una mirada comprometida con una perspectiva
perspectiva acerca de particular del desarrollo de software. Sin embargo, el principio de
cómo debe “adaptación local” apunta a darle flexibilidad al método de tal forma que
desarrollarse un sea la realidad del desarrollo mismo la que dicte la mejor forma de trabajar,
software 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.

54
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

55
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

56
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

57
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

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

59
 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.
a

De
lem

sa
r
rob

ro
llo
lP
de
to

Cliente
ien
cim
no

Proyecto Equipo de Desarrollo


Co

(Aprendices)
a
ogí
n ol
Tec

s
Va pio
lor
es
Profesor / Mediador
rin ci
P
Prácticas

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

60
ú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.
Semana

Actividades
En horas del taller Fuera del taller
Introducción al curso Informe sobre conocimientos previos
1 0

Informes de opinión y dudas surgidas


Teórico

Presentaciones Iniciales a partir de lo expuesto en las


prácticas
12 11 10 9 8 7 6 5 4 3 2

Investigaciones ad-hoc con respecto


al proyecto o a la metodología
Generación de ensayo sobre XP y su
aplicación
Desarrollo del Proyecto usando
XP Generación de informe sobre el
proyecto y la aplicación de XP en el
proyecto
Práctico

Investigaciones ad-hoc con respecto


al proyecto o a la metodología
14 13

Generación de informe sobre la


Poste
Presentación grupal final aplicación de XP en el proyecto y su
rior
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

61
 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.
Comunicació
Comunicación Simplicidad
(Centro de todo problema humano) •Asumirla siempre
•Abiertay honesta •Viajar con equipaje: poco, simple y valioso
•Enseñ
Enseñar a aprender •Cambios paso a paso
•Trabajar con los instintos de las personas •Adaptació
Adaptación local

Coraje Retroalimentació
Retroalimentación
•Jugar a ganar •Rápida (favorece el aprendizaje)
•Responsabilidad aceptada (antes que asumida) •Medir honestamente
•Trabajo de Calidad •Experimentos concretos
•Atacar problema urgente, dejando la mayor
cantidad de opciones

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.

62
Prácticas de XP
Desarrollo

Diseño Simple Planificació


Planificación y Gestió
Gestión
Desarrollo Tests de Planning
Refactorizar Guiado por Aceptación del Game
Tests Cliente (+ Control de
avance)

Metáfora
Cliente en Integración Entregas
terreno continua cortas
(a.k.a. Un sólo
equipo)
Trabajo en equipo
Programación de a
Valores de XP
pares •40 Horas por semana
(+ Mantener el equipo en •No a las horas extra
movimiento)
•Ritmo sostenido de Comunicación
Propiedad avance Retroalimentación
Estándares de •Espacio de trabajo
Colectiva de
Código
Código informativo Coraje
Simplicidad

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

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

Cliente Desarrollador
Desea Valor recibido por cada Calidad del trabajo realizado
maximizar semana de desarrollo
Qué será implementado, y en Cuánto se estima que
Puede definir qué prioridad, según las demorará una tarea
necesidades de su negocio (idealmente)
Funcionalidades solicitadas Sus estimaciones en base a
Puede por otras no implementadas nuevos descubrimientos
cambiar
de costo equivalente (canjear)

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 Consiste en convertir la sala de clases del curso en un ambiente propicio de
del ambiente trabajo. En particular:
de trabajo.
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 Tal como lo indica la práctica de XP, el equipo se reúne de pie y se pone al día
meeting 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.

64
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 Al ir finalizando el tiempo de la sesión, el profesor motiva el cierre del
final y trabajo, con el objeto de que el curso en conjunto pueda evaluar lo aprendido
asignación de durante la sesión. Esto se realiza en un diálogo abierto moderado por el
tareas para la profesor, y en donde se incorpora también al o los clientes cliente de él o los
semana 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 El ambiente de trabajo configurado en la sala es retirado: las mesas y sillas
sesión y devueltas a su posición normal, los computadores devueltos y los radiadores
vuelta a la de información son guardados por los alumnos para ser traídos a la sesión
normalidad siguiente.
de la sala
Tabla 16: Estructura de una sesión del curso

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

Cliente Problema de Negocio

Proyecto de
Software
Ingeniero
de Software

Producto de
Equipo de Software
Desarrollo
Tecnología

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  Entender cuál es la necesidad que gatilla el desarrollo del producto y
problema de las funcionalidades que se están desarrollando
negocio  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

66
Con respecto a Desafío del Ingeniero de Software en un Proyecto de desarrollo
El equipo de  Lograr una relación de confianza y ayuda mutua
desarrollo  Establecer un lenguaje, prácticas y valores comunes
 Evitar la atomización/fragmentación del conocimiento
Las tecnologías  Aprender las funcionalidades y herramientas asociadas a una
usadas 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  Saber qué se ha desarrollado y qué no (visibilidad)
producto  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  Dominar las prácticas de la metodología usada
proceso de  Poder evaluar el trabajo realizado y aplicar mejoras al proceso
desarrollo
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  Lograr que cada miembro del equipo pueda poner lo mejor de sí
desarrollo  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  Mantener a sus compañeros al tanto de los avances
desarrollo
El proyecto y su  Obtener la información que permita medir los avances logrados en
proceso de la construcción del producto
desarrollo
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

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

Ciclos de un proyecto XP

Planning Game (Entregable)


Ciclo de Gestión del Proyecto Orientada al Valor
Planning Game (Iteración)

Ciclo de Gestión del Desarrollo


Plan Diario

Ciclo de
Programación
de calidad

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

68
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

Entregas
Planning Game pequeñas
Gestión del Proyecto
orientada al valor

Cliente en
terreno
(Un sólo equipo)

Tests de Aceptación
Definición del Cliente Validación

Desarrollo

Planning Game de la Iteración


Gestión del Desarrollo en Equipo

Liderazgo Motivador
Diseño
Programación de a Simple
Programación Incremental

(Coaching)
Programación en Equipo

pares
(+ Mantener el
Retroalimentación
equipo rotando)
de Calidad

de Avance Desarrollo
Integración
(Tracking) Guiado por
continua
Tests
Estándares de Código
Stand Up Meeting

Espacio de Trabajo Propiedad Colectiva Refactorización


Informativo de Código

Ritmo Sostenido
( No a las horas extra)

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

69
El flujo del Planning Game C = Cliente
D = Desarrollador

Escribir Historias C Fase de Exploración


para toda la iteración

Estimar Historias D

Dividir Historias C
NO
¿Estimable?

SI Experimentos Concretos D

Fase de Compromiso
Ordenar por Valor C

Ordenar por Riesgo D

Definir Velocidad D

Decidir Alcance C

Recuperación D Fase de Maniobra


Nueva Historia C
Velocidad
Iteración
Cliente requiere
sobreestimada Planning Game de la Iteración C nueva historia

Plan no es
Desarrollo XP D
adecuado
Re-Estimar D Test Ejecutar D
¿OK? no
Funcionales Validar C
si

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/

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


Sincronización
Ciclo principal: Sincronizar problema Planning Game Un plan compartido y
Gestión del de negocio y la solución confianza de su
Proyecto de software factibilidad
orientada al
valor Tests de aceptación Software funcional
entregado de manera
incremental y
validado por el cliente
Ciclo de Gestión Información del avance Stand Up Meetings Apreciación por parte
del desarrollo en del proyecto y desafíos Tracking del equipo de los
equipo en los diversas tareas Espacio de Trabajo logros obtenidos y
del plan Informativo claridad en los
desafíos pendientes
Ciclo de Funcionalidades General Verificación
Programación validadas técnicamente, Suite de Tests automática de calidad
Incremental de integradas técnica del software
Calidad armónicamente en el
sistema y con
mecanismos de

71
Ciclo Meta Herramienta de Resultado
Sincronización
verificación que Equipo Equilibrio en el uso de
permitan validar a Programación de a las destrezas de los
futuro su pares desarrolladores y
funcionamiento (suite Propiedad colectiva de conocimiento
de test) código compartido de cómo
Estándares de código 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.

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

versus

Modelo del Curso Modelo requerido por la investigación

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

73
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 academia 32 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”

74
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 Fueron capaces de sostener una actitud de diálogo,
cliente y receptividad de admitiendo sus equivocaciones y recibir críticas
críticas
Afiatamiento percibido del Se percibió un equipo de desarrollo coordinado y afiatado
equipo entre sí
Comunicación dentro del La comunicación entre los desarrolladores y el cliente fue
equipo 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 Demuestran iniciativa para lograr el éxito del proyecto
del proyecto
Visibilidad entregada del El proyecto fue visible, pudiendo saber el cliente en todo
avance 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.

75
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 Ha mantenido un buen diálogo con el cliente aportando con
cliente el desarrollo del proyecto
Actitud de diálogo: con el Muestra una actitud de diálogo que facilita el trabajo en
equipo equipo
Actitud positiva frente a las Es capaz de admitir sus equivocaciones y recibir críticas
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 Asume el proyecto como un trabajo en equipo, ofreciendo
otros en sus labores apoyo en las tareas derivadas del proyecto
Disposición a recibir apoyo Es capaz de pedir ayuda cuando ha tenido problemas
del resto del equipo
Proactividad para el éxito del Demuestra iniciativa para lograr el éxito del proyecto
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.

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

Concebir un método, una idea,


un producto original
Crear
Evaluar Estimar aplicando criterios

Identificar los
Analizar componentes de un todo

Transferir conocimientos y
Aplicar estrategias a una situación familiar

Comprender – Procesar la información


Describir, Explicar

Conocer - Recordar 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)

77
Variable Qué mide Valores Posibles
1. Rememoración Si una práctica es recordada pro los Ícono Mencionada
de las prácticas alumnos en los ensayos construidos
de XP durante el curso En No Mencionada
blanco
2. Comprensión Si las prácticas mencionadas son bien Bien entendido
de las prácticas definidas y/o explicadas por los alumnos No hay claridad
de XP en sus ensayos
Con errores de
comprensión
No menciona
3. (Evaluación de Cuál es la apreciación de los alumnos Bien aplicado
) Aplicación de acerca de la aplicación de las prácticas de
Aplicado con
las prácticas de XP durante el proyecto, complementada
dificultades
XP con la observación del profesor durante
el curso. 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

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

79
Mes
Plan
#
Viernes Simbología
29 Introducción al curso

6 5 4 3 2 1 0
5 Presentaciones Iniciales
12 Primer Ciclo

Agosto
19 Segundo Ciclo
26 Tercer Ciclo
2 Feriados
9
Septiembre

16
23
9 8 7

30
7
14
Octubre

21
12 11 10

28
4
Noviembre

11
14 13

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

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

81
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
Ciclo 1 Ciclo 2
Gestión de Gestión del Gestión de Gestión del
Proyecto Programación en Programación Proyecto Programación Programación
Desarrollo en Desarrollo en
Orientada al Equipo de Calidad Orientada al en Equipo de Calidad
Equipo Equipo
Valor Valor
Espacio de Trabajo Informativo

Espacio de Trabajo Informativo


Propiedad Colectiva de Código

Propiedad Colectiva de Código


Retroalimentación de avance

Retroalimentación de avance
Desarrollo Guiado por Tests

Desarrollo Guiado por Tests


Programación de a Pares

Programación de a Pares
Entregables Pequeños

Entregables Pequeños
Estándares de Código

Estándares de Código
Integración Continua

Integración Continua
Liderazgo Motivador

Liderazgo Motivador
Tests de Aceptación

Tests de Aceptación
Stand Up Meeting

Stand Up Meeting
Ritmo Sostenido

Ritmo Sostenido
Refactorización

Refactorización
Planning Game

Planning Game
Diseño Simple

Diseño Simple
Cliente In Situ

Cliente In Situ
Alumno

Grupo
Mapache FB
FS
CT
AV
XMLSync BB
TH
CH
CM
CS
MV

Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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

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

84
“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.
Ciclo 1 Ciclo 2
Gestión de Gestión del Gestión de Gestión del
Proyecto Programación en Programación Proyecto Programación Programación
Desarrollo en Desarrollo en
Orientada al Equipo de Calidad Orientada al en Equipo de Calidad
Equipo Equipo
Valor Valor
Espacio de Trabajo Informativo

Espacio de Trabajo Informativo


Propiedad Colectiva de Código

Propiedad Colectiva de Código


Retroalimentación de avance

Retroalimentación de avance
Desarrollo Guiado por Tests

Desarrollo Guiado por Tests


Programación de a Pares

Programación de a Pares
Entregables Pequeños

Entregables Pequeños
Estándares de Código

Estándares de Código
Integración Continua

Integración Continua
Liderazgo Motivador

Liderazgo Motivador
Tests de Aceptación

Tests de Aceptación
Stand Up Meeting

Stand Up Meeting
Ritmo Sostenido

Ritmo Sostenido
Refactorización

Refactorización
Planning Game

Planning Game
Diseño Simple

Diseño Simple
Cliente In Situ

Cliente In Situ
Alumno

Grupo
Mapache FB
FS
CT
AV
XMLSync BB
TH
CH
CM
CS
MV

Simbología Aplicación
Bien aplicado
Aplicado con dificultades
Mal aplicado
No aplicado / No responde
Con errores de comprensió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.

85
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
# Mapache XMLSync
Inicial
Viernes Viernes Viernes Simbología
29 29 29 Introducción al curso
0

5 5 5 Presentaciones Iniciales
2 1

12 12 12 Primer Ciclo
Agosto

19 19 19 Segundo Ciclo
6 5 4 3

26 26 26 Tercer Ciclo
2 2 2 Feriados
9 9 9
Septiembre

16 16 16
23 23 23
9 8 7

30 30 30
7 7 7
14 14 14
Octubre

14 13 12 11 10

21 21 21
28 28 28
4 4 4
Noviembre

11 11 11

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.

86
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

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

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.

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

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.

89
Calificación de la experiencia

muy mala
mala
1. ¿Cómo calificaría la experiencia vivida en este curso? 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?

Aspectos distintivos del curso


Relación entre teoría y práctica
Aspectos

Ambiente humano

Destrezas
Total

Otros

0 1 2 3 4 5 6 7 8 9 10

Nº menciones

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

90
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.1 Relación con clientes


3. ¿Cuáles son las lecciones principales que aprendió en el 3.2 Trabajo en equipo
curso?
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.

91
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 .
Rememoración de prácticas

Reuniones de evaluación
planificacion y seguimiento
Otras

mini tareas
Brainstormings
Desarrollo en Programació Programació
n de Calidad n en Equipo

Propiedad Colectiva de Código


Programación de a Pares
Estándares de Código
Refactorización
Práctica

Diseño Simple
Desarrollo Guiado por Tests Total
Stand Up Meeting
Gestión del

Equipo

Ritmo sostenido
Retroalimentación de avance
Espacio de Trabajo Informativo
Orientada al

Tests de Aceptación
Gestión de
Proyecto

Valor

Planning Game
Cliente in situ

0 1 2 3 4 5 6 7 8 9 10
Nº Menciones

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.

92
Rememoración de Prácticas
Tests de Aceptación
Stand Up Meeting
Reuniones de evaluación
Retroalimentación de avance
Refactorización
Propiedad Colectiva de Código
Programación de a Pares
XMLSync

Planning Game
planificacion y seguimiento
mini tareas
Grupo / Práctica

Estándares de Código
Espacio de Trabajo Informativo
Diseño Simple
Desarrollo Guiado por Tests Total
Cliente in situ
Brainstormings
Stand Up Meeting
Ritmo sostenido
Refactorización
Mapache

Propiedad Colectiva de Código


Programación de a Pares
Espacio de Trabajo Informativo
Desarrollo Guiado por Tests
Cliente in situ

0 1 2 3 4 5 6 7

N º de menciones

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

Aplicación de XP

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

Aplicación de XP después del curso


No
responde
10%
Nunca
10%

Parcialmen
te
80%

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

93
Aplicación de prácticas específicas

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

Aplicación de Prácticas Post-Curso

Desarrollo con Tests a posteriori


de Calidad po Otras

compartir conocimiento
Prog

Orientada al Desarrollo en Programación Equi


n en
ació
ram
Ciclo de XP / Práctica aplicada

Programación de a Pares

Refactorización

Diseño Simple

Desarrollo Guiado por Tests

Stand Up Meeting
Gestión del

Total
Equipo

Retroalimentación de avance

Espacio de Trabajo Informativo

Planning Game
Gestión de
Proyecto

Valor

Entregables Pequeños

Cliente in situ

0 1 2 3 4 5 6 7 8 9 10
Nº de menciones

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

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

95
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

96
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

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

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

Ciclo de Gestión del Proyecto Orientada al Valor

Ciclo de Gestión del Desarrollo

Ciclo de
Programación
de calidad

Profesor / Meta-Coach

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.

99
APRENDIZAJE COGNITIVO Y MODELO
PEDAGÓGICO DEL CURSO CC62V
Flujo del modelo pedagógico

Profesor Aprendices
Recopilación Estrategias Expertas Principios y
Considerar las estrategias que un experto Prácticas de XP
aplicaría en una tarea.

Diseño soportes instruccionales Tutoriales de


Diseñar desafíos que, actuando como
soportes instruccionales, motivarán a los Prácticas de XP
aprendices a aplicar las estrategias. Estas
actividades estarán situadas u orientadas a
eXtreme Hour (Planning Game),
resultados relevantes. Análisis Orientado a Objectos – CRC,
Desarrollo Guiado por Test
Modelado de estrategias
Modelar las estrategias a sus alumnos a
través de la resolución del desafío

Práctica Guiada (Coaching)


ofrecer retroalimentación y consejo practicar habilidad resolviendo el
experto desafío

Reflexión Metacognición
continua, Articulación
Motivación
Ensayos de Motivar en sus alumnos la Verbalizar los razonamientos y métodos usados
para resolver el desafío, (metacognición)
opinión metacognición
personal,
Reflexión
etc. Reflexionar y aprender de las estrategias usadas
por sus pares y por el profesor.

Desarrollo de Exploración
Proyecto
Retirar paulatinamente el Aplicar estrategias a nuevos
Auténtico apoyo problemas.
usando XP
Ilustración 37: Cómo el modelo pedagógico de aprendizaje se realiza en el curso CC62V

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

Entregas
Planning Game pequeñas

Gestión del Proyecto


orientada al valor
Cliente en terreno
(Un sólo equipo)

Reproducción Tests de Aceptación


Definición del Cliente Validación
fiel de XP
Gestión pedagógica de los Aprendizajes

Involucramiento Desarrollo
temprano de los
alumnos

Corta Planning Game de la Iteración


introducción
teórica
Gestión del Desarrollo en Equipo

Diseño
Liderazgo Motivador
Desarrollo en clases, (Coaching) Programación de a Just In Time
Estudio e

Programación Incremental
pares
Programación en Equipo

Investigación (+ Mantener el equipo


Retroalimentación rotando)
en casa
de Avance Desarrollo

de Calidad
(Tracking) Guiado por Tests Integración
continua

Retroalimentación Estilo Común de Código


Stand Up Meeting
temprana a los
alumnos
Espacio de Trabajo Propiedad Colectiva de Refactorización
Informativo Código

Aprendizaje
Cognitivo de Ritmo Sostenido
nuevas destrezas ( No a las horas extra)

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.

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

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

103
Á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 Establecer una base temprana de código funcional (que será
código funcional 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 Roles horizontales y liderazgo
rol clásico de “jefe de proyecto”
Diseño como actividad globalizadora y a Diseño incremental a medida de que se va
realizarse antes del desarrollo como tal comprendiendo el problema a resolver
Divergencia entre la programación de Desarrollo guiado por tests
funcionalidades y la validación de éstas,
considerando ésta última como una actividad
separada, a posteriori, y en último caso,
sacrificable.
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:

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

105
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

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

107
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

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

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

110
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” Ilustración 42: eXtreme Hour – Los “clientes"
frente a los “clientes” inspeccionando el trabajo realizado

111
Ilustración 44: eXtreme Hour – Máquina Ficticia:
Ilustración 43: eXtreme Hour – Tarjetas con las
"Producto" generado en el taller
"Historias de usuario" que describen las
características de la máquina ficticia.

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

113
Proyecto Mobile WebServer “Mapache”
Descripción del Proyecto
Este proyecto nace a partir de la existencia de un servidor web de código abierto 40 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
29 29 Introducción al curso
6 5 4 3 2 1 0

5 5 Presentaciones Iniciales
12 12 Primer Ciclo
Agosto

19 19 Segundo Ciclo
26 26 Tercer Ciclo
2 2 Feriados
9 9
Septiembre

16 16
23 23
9 8 7

30 30
7 7
14 14
Octubre

14 13 12 11 10

21 21
28 28
4 4
Noviembre

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

114
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

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


Entregable MicroServer
Responder Ambiente Ponerse al día Los tests Añadir soporte
WebService de de temas como validarían las para servicios.
con datos desarrollo Web Services y funcionalidades Corregir
básicos que SOAP, básicas defectos como
permitiese esperadas del manejo de
ejecutar el servidor web, en rutas y de
servidor particular espacios de
web implementar los nombres
métodos GET y
POST, y ser capaz
de responder un
requerimiento
SOAP
Implementar Validar cálculos Implementar Implementar
aplicación de la aplicación servicio aplicación
cliente calculadora Winforms de
“calculadora”, calculadora
usando
WebServices
Implementar Archivos Validar envío de Implementar Implementar
Servicio Web adjuntos archivos Attachments aplicación
para acceder (Attachments) Winforms
archivos en SOAP 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 alumnos 41, 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.

116
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

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

117
Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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

118
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


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%

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:

119
Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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.

120
Evaluación interna de los alumnos
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%

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

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

Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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,

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

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

124
Los objetivos relevantes de las iteraciones siguientes se resumen en la siguiente tabla:

Instalación Investigación Crear Tests Implementar Validación


Entregable MicroServer
Implementar Terminar de
aplicación corregir
cliente defectos
“calculadora”, como manejo
usando de rutas y de
WebServices espacios de
nombres.
Implementar
modelo
simple de
configuración
Validar Implementar Implementar
cálculos de la servicio aplicación
aplicación calculadora Winforms de
calculadora
Implementar Archivos Validar envío Uso de tipos Implementar
ServicioWeb adjuntos de archivos complejos en aplicación
para acceder (Attachments) los servicios Winforms
archivos en SOAP Implementar para
Attachments 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.

125
Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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.

126
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

127
Evaluación del cliente
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%

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.

128
Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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:

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

130
Evaluación interna de los alumnos
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%

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.

131
Ciclo de Programación Incremental de Calidad

Evaluación de aprendizajes

Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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:

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

133
Desarrollo del Proyecto

Mes Plan XMLSync


#
Viernes Viernes Simbología
29 29 Introducción al curso
6 5 4 3 2 1 0

5 5 Presentaciones Iniciales
12 12 Primer Ciclo
19 19 Segundo Ciclo
Septiembre Agosto

26 26 Tercer Ciclo (planificado pero no alcanzado)


2 2 Feriados
9 9
16 16
23 23
9 8 7

30 30
7 7
14 14
21 21
13 12 11 10
bre Octubre

28 28
4 4
Nov
iem

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.

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

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

Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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.

136
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

137
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

138
Ilustración 52: Equipo presentando algunos avances al cliente

Evaluación del cliente


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%

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.

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

Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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

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

141
Evaluación interna de los alumnos

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

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.

142
Evaluación de aprendizajes

Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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.

143
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

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

145
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

146
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

Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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.

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

148
Evaluación del cliente
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%

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

150
Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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.

151
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


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%

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

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

Evaluación de aprendizajes

Simbología Comprensión
Bien entendido
No hay claridad
Con errores de comprensión
No menciona

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.

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

154
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

Saavedra Trujillo
Ítems a evaluar Baytelman Cespedes, Muñoz, Villavicencio
Pilowsky, Felipe Claudio Theoduloz,
Felipe Bruno Ignacio Alejandro Andres
Felipe
Asume el proyecto como un S S S S
trabajo en equipo,
ofreciendo apoyo en las
tareas derivadas del proyecto
Es capaz de pedir ayuda R AV AV R
cuando ha tenido problemas
Cumple con las tareas S S S S
asumidas de manera
adecuada, transparentando
su labor y buscando generar
el mayor valor posible por
cada día de trabajo
Demuestra iniciativa para R R R R
lograr el éxito del proyecto
Muestra una actitud de S S S
diálogo que facilita el trabajo
en equipo
Ha mantenido un buen S S S S
dialogo con el cliente
aportando con el desarrollo
del proyecto
Demuestra interés por R R R R
investigar y perfeccionarse
en el cumplimiento de sus
tareas asumidas y de su rol
dentro del proyecto
Es capaz de admitir sus S S S S
equivocaciones y recibir
críticas

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


XXXXX
XXXXX
XXXXX
XXXXX

El proyecto fue visible, pudiendo Al principio fue un poco confuso, pero


saber el cliente en todo momento después que le tomaran el timing al lo que
qué se había desarrollado y cuanto R R R R
tenian que hacer, hubo mayor fluidez de
quedaba por realizarse información.
A veces se quedaban atados con algún
La comunicación entre los
problema, y daban vuelta y vuelta, y no me
desarrolladores y el cliente fue S R R R
fluida, periódica y abierta preguntaban ya que yo podía tener algunos
hints para la solución.
Se percibió un equipo de
desarrollo coordinado y afiatado R A A R
entre sí
Cumplieron con las tareas
asumidas de manera adecuada,
transparentando su labor y R R R R
buscando generar el mayor valor
posible por cada día de trabajo
Creo que Felipe Baytelman es un componente
motivador y fundamental del equipo desarrollo
Demuestran iniciativa para lograr
el éxito del proyecto S A A R 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 S S S S
equivocaciones y recibir críticas
Cumplieron con los horarios
puntualmente y mantuvieron la R R R R
asistencia acordada

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


asignado 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 10
el desarrollo del curso )

total 28

Observaciones:

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


que aborda el proyecto.
Considerando los valores,
principios y prácticas de 10
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
Detección de otras 3
problemáticas no
abordadas desde el punto
de vista de XP, y
propuestas para
solucionarlas
total

Observaciones:
__________________________________________________________
__________________________________________________________
__________________________________________________________

158
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
Comunicació
Comunicación Simplicidad
(Centro de todo problema humano) •Asumirla siempre
•Abiertay honesta •Viajar con equipaje: poco, simple y valioso
•Enseñ
Enseñar a aprender •Cambios paso a paso
•Trabajar con los instintos de las personas •Adaptació
Adaptación local

Coraje Retroalimentació
Retroalimentación
•Jugar a ganar •Rápida (favorece el aprendizaje)
•Responsabilidad aceptada (antes que asumida) •Medir honestamente
•Trabajo de Calidad •Experimentos concretos
•Atacar problema urgente, dejando la mayor
cantidad de opciones

Estructura modular de adopción de XP

Trabajo en equipo motivador


Planificació
Planificación y Gestió
Gestión
colaborativa orientada al valor Retroalimentación Liderazgo
de Avance Motivador
(Tracking) (Coaching)
Cliente en
terreno Stand Up
Planning Game
(a.k.a. Un sólo Ritmo Sostenido / Meeting
equipo) 40 horas a la
semana

Espacio de
Trabajo
Tests de
Informativo
Aceptación del Entregas
Cliente pequeñas

Integración
Programació
Programación orientada a continua Propiedad
Estándares de
la calidad Código
Colectiva de
Código

Diseño Simple Refactorización

Programación de a
Desarrollo
pares
Guiado por (+ Mantener el equipo en
Tests movimiento)

Valores de XP
Comunicación
Retroalimentación
Coraje
Simplicidad

159
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) 4
que aborda el proyecto.
Considerando los valores,
principios y prácticas de XP: 7
 Explicitar cuales se aplicaron y
como se ejemplifican.
 Explicitar cuáles no se aplicaron y
el por qué.
Detección de otras 3
problemáticas no abordadas
desde el punto de vista de XP,
y propuestas para solucionarlas
Proyectar el uso de XP en la vida profesional:
 ¿Qué es más simple de adoptar? 7
 ¿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?
Qué destrezas u aprendizajes 7
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)
total 28

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

Observaciones:
-

160
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


Considera que la nebulosa en los requerimientos que sucedió
Planning al comienzo del proyecto es una carencia de XP, pero es algo
Game FS natural de todo desarrollo de software
Cree que los tests el cliente los define sólo cuando hay que
Tests de probar las funcionalidades, y no antes, ojala cuando se definen
Aceptación CT las historias de usuario.

Aplicación

Concepto Alumno Problemas detectados


Planning “Pese a en un comienzo no haber sido capaces de estimar
Game 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
FB estimado que nos tomaría tanto tiempo”
Planning “Falta de experiencia en el problema dificulta las
Game CT evaluaciones/estimaciones”
Planning (Tiene error de concepto, se queja de lo mismo pero
Game FS atribuye la incertidumbre inicial a un defecto de XP)

Concepto Alumno Problemas


Cliente in “A pesar de que esta practica es muy útil, y prácticamente
situ 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,
FS fabricar una solución, y consultar por su aprobación.”

161
Cliente in "podamos aprovechar al cliente en el terreno y que esto no
situ 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
CT estaremos abusando de su conocimiento"
Ciclo de desarrollo en equipo

Comprensión

Concepto Alumno Errores de concepto


“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
Ritmo dispuesto a trabajar extra cuando hay otras cosas que hacer), más
Sostenido FB que por “fidelidad a la metodología”.
Liderazgo “jugando un poco el rol de coach o negociando y trabajando junto
Motivador FB al cliente, he tomado un papel un tanto más solitario”.

Aplicación

Concepto Alumno Problemas


Espacio de
Trabajo “Al replanificar, las tareas cambian de disposición en el
Informativo CT papelógrafo lo que hace difícil leerlo para evaluar el avance”
Se indica la siguiente limitante, derivada de la incertidumbre
inicial del Planning Game: "no ser capaces en un comienzo de
Ritmo estimar los esfuerzos y completar los objetivos de manera
Sostenido CT limpia y precisa"
Stand Up "al principio la gente se sentaba y las reuniones se alargaban"
Meeting CT "algunas de estas reuniones han tardado demasiado tiempo"
Ciclo de Programación Incremental de Calidad

Comprensión

Concepto Alumno Errores


Estándares “al no haber incorporado mucho aún al código fuente, es que no
de Código FB 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”

162
Concepto Alumno Problema
Programación Indica que programando solo avanza más rápido. No entiende que
de a pares no sólo se trata de programar, sino de que el conocimiento fluya
FB por le equipo

Concepto Alumno Errores


Hay una confusión con el significado tradicional de "diseño",
Diseño Simple FB por lo cual se cree que si no hay diseño formal no hay diseño
Se considera que “diseño simple” ante un sistema pre-
existente implica rediseñarlo, y no definir la solución más
Diseño Simple FS adecuada a las condiciones
Diseño Simple CT “No se usa cuando se basa en código ya hecho”
“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
Refactorización FS se debería construir una solución desde cero.”
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
Refactorización CT agregarle funcionalidad
“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
Refactorización AV del proyecto seria un desperdicio de tiempo de desarrollo”
Desarrollo
Guiado por
Tests CT Propone definir todos los test al inicio
Integración No se usa cuando se basa en código ya hecho, dado que no
continua CT hay que "integrar" nuevos módulos

Aplicación

Concepto Alumno Problemas


Desarrollo “En un comienzo no se le dio el real peso que significa tener
Guiado por una batería de pruebas, quedando plasmado su uso casi al
Tests FS final de la iteración.”
Programación “Hubo desincronización inicial en las parejas en ritmo de
de a Pares FS trabajo”

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

Concepto Alumno Evaluación


“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
Refactorización FB éste invoca los métodos del módulo GET de SOAP”

Ciclo 2
Ciclo de generación de valor

Comprensión

Concepto Alumno Errores


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
Planning Game AV esa incertidumbre.
Tests de Cree que los tests de aceptación se definen al final, cuando
Aceptación CT “hay que probar”

Aplicación

Concepto Alumno Problemas


Planning “nunca fue fácil estimar cuánto trabajo era necesario para
Game FB concretar el proyecto, ya que siempre existían cabos sueltos”
Planning “Solución al problema de definir tareas y estimar fue una larga
Game CT reunión con el cliente”
“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
Entregable productos funcionales entregados, lo cual nos hubiera dado una
s pequeños CT mejor idea de los tiempos tomados para cada entrega”

164
Ciclo de desarrollo en equipo

Comprensión

Concepto Alumno Errores


“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,
Stand Up no un gran aporte en general pues dada la naturaleza del trabajo
Meeting AV no se necesitaban decisiones más allá de “quien hace qué”.
Ritmo
Sostenido AV No hay suficiente información para evaluar
“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
Ritmo a trabajar extra cuando se estaba solo, y con otras cosas que
Sostenido FB hacer), más que por “fidelidad a la metodología”.

Aplicación

Concepto Alumno Problemas


Falta de comunicación fuera del ambiente de trabajo para
Ritmo Sostenido FS lograr la productividad esperada
Indica que hubo problemas fuera del ambiente de trabajo,
donde al no poseer la presencia de un liderazgo motivador,
Liderazgo influyó en la no realización de tareas y coordinación del
Motivador FS equipo.
Espacio de
Trabajo
Indica "no es tan necesario un acceso constante al estado
Informativo
de avance general del proyecto. Para estos casos es
CT preferible el uso de software administrador de proyectos",
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
Stand Up trabajo en casa no se habían trabajado, dejando el estado de
Meeting CT avance del proyecto en una nebulosa.

165
Ciclo de Programación Incremental de Calidad

Comprensión

Tema Concepto Alumno Errores


Programación Estándares de Consideran que la no haber intervenido
en Equipo Código FB 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
AV palabra estandarizar.
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.
Propiedad
Colectiva de Este error no fue detectado en el ensayo del
Código AV ciclo anterior.
Programación Indican de manera muy similar “Estando
de Calidad Diseño Simple FB 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
AV total

Aplicación

Alumno Concepto Problemas


“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
Programación de a adquiriendo más compromisos, y cumpliéndolas con
FB Pares mayor responsabilidad. “
Desarrollo Guiado “no se utilizó esta práctica, principalmente por la baja
FS por Tests complejidad que presentaba el testear “
“No se simplificó o mejoró el diseño, por falta de tiempo.
Dieron "prioridad a prácticas que son más centradas en
CT Refactorización la producción de resultados rápidos y funcionales".
“Por "ahorrar" tiempo se dejó de usar, pero problemas
Desarrollo Guiado surgidos posteriormente indican que si debieron
CT por Tests usarla.”

166
Alumno Concepto Problemas
“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
Integración abandonamos y dado a eso hemos tenido problemas
AV Continua con la entrega final.”
“Se intento aplicar, pero dado la complejidad de los test,
Desarrollo Guiado y la necesidad de crear test para componentes ya
AV por Tests 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 confunde tareas con "historias de usuario", sin entender la
Game BB diferencia
Indica lo bueno de un entregable pequeño para obtener
Entregables feedback temprano , pero olvida lo fundamental: aportar valor
Pequeños BB lo antes posible al cliente

Concepto Alumno Errores


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
Planning conversaciones del grupo de desarrollo, solamente con la aprobación del
Game TH 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

167
Aplicación

Concepto Alumno Problemas de Aplicación

“El cliente no ha sido parte del equipo”.


“Fue cliente tradicional y quería soluciones y además complicadas”
Cliente In “El cliente no estuvo en todas las sesiones”
Situ CM “No supieron sacarle ‘el jugo al cliente’ "
“Creo que ésta práctica es la que debemos atacar de forma mas decidida
Cliente In para el resto del proyecto, debido a su fuerte impacto, obviamente
Situ CS asumiendo que es posible contar con el tiempo del cliente.”
“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
Cliente In momento surgen dudas o decisiones que tienen que ser tomadas junto
Situ MV con él y que nos hacen difícil avanzar.”
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
Cliente In resto del grupo, pese a que he delegado esa tarea (siento que no me
Situ CH corresponde delegar tareas, pero he tenido que hacerlo).”

Concepto Alumno Problemas de Aplicación


“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
Planning el grupo más con el proyecto y nos esforzamos por empaparnos del
Game CM problema a solucionar en el ‘hoy’.”
“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
Planning delegar tareas, no ha resultado muy bien. No ha habido suficiente
Game CH retroalimentación.”

168
Concepto Alumno Problemas de Aplicación
“El cliente no nos ha apoyado lo necesario en generar las pruebas, (y
Tests de menos en el desarrollo), aún cuando le hemos pedido. Hemos debido
Aceptación CH insistir, par que el nos genere pruebas”
“Dificultad de obtener retroalimentación del cliente
Dejaron pasar mucho tiempo sin feedback del cliente
Tests de Usado solamente para finalizar la iteración, por lo que "se perdió de vista
Aceptación CM el objetivo por lo mismo"
“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,
Tests de y dependientes de las restricciones que generamos después de
Aceptación CS desarrollado el software.”

Concepto Alumno Problemas de Aplicación


Entregables “No aportó mucho valor al proyecto. Al no usar Test de Aceptación,
Pequeños CM ‘ambas prácticas se hundieron juntas’.”
"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
Entregables suficientemente chicas que ni siquiera sabíamos si nos iban a ayudar, y
Pequeños MV entrábamos en conflicto con simple design”.
“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
Entregables para mi), sólo enfocarme en el diseño simple para el entregable de esta
Pequeños CH iteración”
Concepto Alumno Evaluación
“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
Cliente In se logró una mejor comunicación con el cliente en las últimas sesiones de
Situ BB desarrollo.
“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
Cliente In siguió pensando que el proyecto estaba a mis cuestas y no en el resto del
Situ CH equipo, aun cuando yo mismo le insistiese que no era así. “

169
Concepto Alumno Problemas de Aplicación
“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
Cliente In momento surgen dudas o decisiones que tienen que ser tomadas junto
Situ MV con él y que nos hacen difícil avanzar”.
"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
Cliente In jugársela por el proyecto, llevándose tareas para la casa, que aportaban
Situ CM información valiosa a las horas de programación en clases."

Ciclo de desarrollo en equipo

Comprensión

Alumno Concepto Errores


Espacio de Trabajo El mismo declara que no entiende su sentido: “no estoy
MV Informativo entendiendo el sentido o la verdadera utilidad que tiene.”
Toma literalmente el concepto de “40 horas a la semana”, por
lo que indica que no se aplicó, pero luego indica que se logró
MV Ritmo Sostenido un ritmo de trabajo adecuado.
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). “
Liderazgo ” siento que nadie aparte de mi, está realmente interesado en
CH Motivador el que el proyecto llegue a un éxito”
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.”
Retroalimentación
CH de avance

170
Alumno Concepto Errores
Liderazgo
CS Motivador No entrega información suficiente para hacer una evaluación
Liderazgo
MV Motivador No entrega información suficiente para hacer una evaluación

Aplicación

Alumno Concepto Evaluación


“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
MV Ritmo Sostenido significativamente.”

Alumno Concepto Problemas


"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
Liderazgo siento que nadie aparte de mi, está realmente
CH Motivador interesado en el que el proyecto llegue a un éxito”
“Lo usamos, pero quizá no le hemos sacado todo el provecho
que hemos podido. Están las tareas realizadas, las tareas en
Espacio de Trabajo curso, la estimación, pero quizás yo no estoy entendiendo el
MV Informativo sentido o la verdadera utilidad que tiene.”
“sólo está haciendo una labor de notificación del planning
Retroalimentación game, al profesor, y no al resto del equipo. Este rol también
CH de avance falla, porque no participa en el planning game”
“se opta por lo que cada uno piensa es correcto y el coach
aprueba, en vez de asegurarse preguntándole a un cliente
Liderazgo que tiene la capacidad técnica para entender nuestras
CS Motivador preguntas.”

171
Alumno Concepto Problemas
“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,
Liderazgo es decir, cada miembro del equipo debe sentirse motivado
MV Motivador por el proyecto y actuar en consecuencia.”

Ciclo de Programación Incremental de Calidad

Comprensión

Tema Concepto Alumno Errores


Programación Diseño
de Calidad Simple BB No aporta información suficiente para evaluar
Programación Refactoriz
de Calidad ación TH No aporta información suficiente para evaluar
“Generalmente uno debe hacer un diseño simple,
(aunque sea desordenado) y después ordenarlo
Programación Diseño y generar un código limpio y entendible (esto
de Calidad Simple CH permitirá después mayor comunicación).”
Propiedad
Programación Colectiva No tiene claro el significado de la práctica debido
en Equipo de Código CM a la poca cantidad de código generado.
Propiedad
Programación Colectiva
en Equipo de Código CH No aporta información suficiente para evaluar
Programación Estándares No reconoció aplicación "Partimos programando
en Equipo de Código CM como si nos hubiéramos puesto estándares".
Programación Estándares
en Equipo de Código MV No aporta información suficiente para evaluar

Aplicación

Concepto Alumno Problemas


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

172
Concepto Alumno Problemas
“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
Diseño Simple CH complejidad a las soluciones que hay que resolver”
“se intentó usar, lamentablemente, creo que por nuestra
inexperiencia o por nuestra mente acostumbrada a las tareas
Diseño Simple CM cc10 (un curso anterior) no se hizo”
“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
Diseño Simple CS cualquier impureza.”
“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
Diseño Simple MV acercándonos a la solución”

Concepto Alumno Problemas


“Hemos diseñado pruebas para los diseños, pero por la poca
Desarrollo claridad del tema (y la falta de comunicación), los test
Guiado por terminan haciéndose al final, o no son los test que realmente
Tests CH interesan”
“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
Desarrollo muy poco tiempo. A estas alturas, el tiempo que nos demoramos
Guiado por en arreglar las funcionalidades fue muchísimo menor al que
Tests CM hubiéramos utilizado en hacer tests para cada funcionalidad.”

173
Concepto Alumno Problemas
“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.
Desarrollo Me llama la atención las estadísticas sobre su eficacia, pero creo
Guiado por que se necesita un mayor entrenamiento y supervisión para
Tests CS ponerlo en práctica.”
“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.
Desarrollo Tal vez si en la próxima iteración somos capaces de dividir mejor
Guiado por las tareas, hacerlas aún mas atómicas, es posible usar esta
Tests MV práctica en forma efectiva.”

Concepto Alumno Problemas


“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
Integración puede ser bastante ineficiente, por el hecho de que no se está
Continua CH programando uniformemente en los grupos de trabajo”
Integración
Continua CM “No hubiera sido demasiado útil, dado el poco código que tienen”
“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.”
Integración “El control de versiones, este problema es tremendamente
Continua MV complejo, de hecho, es el problema.”
“Yo en particular traté de incitar que se haga todo de manera
ordenada y funcional (todo lo repetido se refactoriza), pero he
Refactorización CH logrado poco éxito, por las formas de programar de los demás.”
Refactorización CM “No tuvimos necesidad de usarlo”

174
“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
Refactorización CS excesivo refactoring que hemos sufrido.”

Concepto Alumno Problemas


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

Concepto Alumno Problemas


“Dada su naturaleza, es una de las prácticas más difíciles de
Programación asimilar, ya que generalmente uno esta acostumbrado a
de a Pares TH desarrollar en solitario, siendo uno su propio crítico y jefe. “
“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
Programación más rápida la programación de a pares, sino que la estamos
de a Pares CS probando por que el ramo nos lo pide.”

Concepto Alumno Problemas


Propiedad “En lo personal siento que todo el código es mi responsabilidad,
Colectiva de excepto el código externo, y es este el que nos ha causado más
Código CH problema”
“no ha habido una real “rotativa” del equipo sobretodos los
temas, y siento que aún hay mucha incertidumbre. Ojalá en la
Propiedad segunda iteración cambiáramos todos la línea de las tareas que
Colectiva de hemos ido desarrollando, para que todos tengamos esa visión
Código MV “overall” del sistema.”

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

Ciclo 2
Ciclo de generación de valor

Comprensión

Concepto Alumno Errores


"en la segunda interacción, y cuando se debió cambiar el
enfoque del proyecto, no se realizo esta actividad y las tareas a
Planning desarrollar fueron generadas en conversaciones del grupo de
Game TH 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


“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
Cliente In se logró una mejor comunicación con el cliente en las últimas sesiones de
Situ BB desarrollo.”
“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
Cliente In siguió pensando que el proyecto estaba a mis cuestas y no en el resto del
Situ CH equipo, aun cuando yo mismo le insistiese que no era así. “
“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
Cliente In momento surgen dudas o decisiones que tienen que ser tomadas junto
Situ MV con él y que nos hacen difícil avanzar”.
176
"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
Cliente In tareas para la casa, que aportaban información valiosa a las horas de
Situ CM programación en clases."

Concepto Alumno Evaluación


Planning “En el planning game de la primera iteración, por mi proactividad,
Game 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
CH prácticas. “
Planning “Sólo hasta unas 2 o 3 semanas antes del fin de la 2da y última iteración nos
Game 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
CM alternativos.”

Concepto Alumno Evaluación


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

177
“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 de tests. Si el cliente usará o no tests propios para validar el ejecutable, lo hará
Aceptación CH fuera de nuestra vista."

Concepto Alumno Evaluación


“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
Entregables herramienta previa en vez de desarrollar una solución propia, llevaron a un
Pequeños BB atraso general en el desarrollo del proyecto”.
“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
Entregables comparación con lo inicial, dejando en “pequeño” un término algo
Pequeños CH subjetivo”.

“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
Entregables principio eras casi “parchados” y muy poco robustos, pero por lo menos
Pequeños CM nos dieron el ánimo de estar entregando un poco de valor al cliente”.
“Debido a los múltiples problemas enfrentados durante el proyecto no fue
Entregables posible realizar entregas pequeñas, esto es directa consecuencia de la
Pequeños CS naturaleza del problema, pues su divisibilidad es baja.”
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
Entregables tareas pequeñas como “sincronizar en el caso de inserción”, “en caso de
Pequeños MV eliminación”.
Ciclo de desarrollo en equipo

Comprensión
Concepto Alumno Errores de comprensión
“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
Ritmo solo día, lo que hacia que el horario no fuera homogéneo a lo largo de la semana, lo que
Sostenido TH 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

178
Motivador
Liderazgo
Motivador MV No hay información suficiente para evaluar

Aplicación

Concepto Alumno Problemas


“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
Liderazgo nuevo planning game con el cliente y replanteamos la solución a
Motivador CM nuestro problema por medios alternativos”.
“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
Liderazgo de asignar tareas en las cuales algunos se habían sentido más
Motivador TH cómodos. Esa parte del Coach nunca existió.”
“(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
Liderazgo subió (por el relajo de no ser coach), y pudimos avanzar por tierra
Motivador CH derecha”
Liderazgo BB Se abstiene de opinar, por ser el mismo el nuevo coach

179
Motivador
“Se contó con un liderazgo asignador, la motivación entregada no se
Liderazgo sintió, y simplemente se dividían tareas según su propia visión del
Motivador CS problema.
“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.
Liderazgo No es culpa del coach tampoco, es decir, cada miembro del equipo
Motivador MV debe sentirse motivado por el proyecto y actuar en consecuencia.”

Concepto Alumno Comentario


Espacio de “Todas las tareas estaban visibles en papeles postix amarillos
Trabajo pegados a la pared, los cuales estaban ordenados por
Informativo BB funcionalidad e indicaban la estimación de esfuerzo”
“El radiador de información se encontraba presente pero este no
Espacio de era visto y consultado periódicamente por el grupo de desarrollo
Trabajo mas que para actualizar las tareas. La única utilización que se le
Informativo TH dio fue en las Stand-up Meetings,”
“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
Espacio de nos tocaban, y por tanto se cumple en mayor medida el objetivo de
Trabajo esta práctica, aun cuando su aplicación fue bastante mas
Informativo CH desordenada.”

“No se dieron tiempo de actualizarlo seriamente. Sin embargo las


Espacio de Stand up meetings hicieron el papel de informativo
Trabajo excelentemente, y lo que pudo faltar por ambiente informativo, lo
Informativo CM lograron las stand up meetings.”

Concepto Alumno Comentario


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

180
“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
Stand Up opiniones las dejaba para el final). En todo caso, fue mejor, porque
Meeting CH todos aportaron, aunque alargó mucho más esta práctica”

Ciclo de Programación Incremental de Calidad

Comprensión

Tema Concepto Alumno Error

“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
Programación estrategia de diseño directo a resolver el
de Calidad Diseño Simple CH problema que es exactamente un diseño simple.

“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
Programación por un programa externo, que para el grupo en
de Calidad Diseño Simple CS ningún momento fue “simple””.

“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
Programación que significó que no hubo mucho diseño
de Calidad Diseño Simple Biedderman involucrado.”

“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
Programación que el equipo estuvo muy perdido en el
de Calidad Diseño Simple MV problema”

181
Tema Concepto Alumno Errores
Programación
de Calidad Refactorización BB No aporta información suficiente para evaluar

Tema Concepto Alumno Errores


“es mi opinión, que como no programamos
nosotros el código, difícilmente podemos
Propiedad sentirnos dueños del código, ni individual, ni
Programación Colectiva de colectivamente, por la forma en que se terminó
en Equipo Código CH el proyecto”
Propiedad “hubo que perder tiempo preguntando "oye qué
Programación Colectiva de hiciste en este pedazo de código?" y eso es
en Equipo Código CM totalmente contrario a la práctica”

Tema Concepto Alumno Errores


Programación Estándares de “No se llego a ningún acuerdo, ni tampoco fue
en Equipo Código CS conversado.”
“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,
Programación Estándares de priorizar el desarrollar algo realmente útil para
en Equipo Código MV el cliente.”

182
Aplicación

Tema Concepto Alumno Comentarios


“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
Programación Diseño momento). En la segunda iteración, se buscó otra
de Calidad Simple TH solución simple y funcionó mejor.“
“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
Programación Diseño minimal de este XMiddle que llenara los requisitos
de Calidad Simple CM pedidos por el cliente”

Tema Concepto Alumno Problemas


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
Desarrollo salida esperada. De esta manera se programaba la
Programación Guiado funcionalidad y se ejecutaba la aplicación. El test era
de Calidad por Tests BB aprobado si la salida del programa era la esperada.
"..en un comienzo, se desarollaron los test antes de
crear las clases a ser probadas, pero a medida que
Desarrollo avanzaba el proyecto, desarrllábamos clases antes de
Programación Guiado desarrollar los test, lo que no cumple rigurosamente
de Calidad por Tests TH con TDD".

183
En la segunda iteración, se eliminaron los units, para
Desarrollo trabajar finalmente siempre con un ejecutable que
Programación Guiado ejecutara tests, finalmente este ejecutable se modificó
de Calidad por Tests CH para hacer el entregable final.
Desarrollo
Programación Guiado Estoy consciente que esta práctica debe ser muy útil,
de Calidad por Tests CM pero no pude darme cuenta con este proyecto.
El desarrollo guiado por tests no fue utilizado de forma
Desarrollo consistente, si bien este se aprendió al inicio del
Programación Guiado semestre la poca confianza tomada por el grupo de
de Calidad por Tests CS trabajo en el sistema no permitió su real uso.
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
Desarrollo vicios. Nunca pude entender cómo programar un test
Programación Guiado para probar algo tan complicado y con tantos casos
de Calidad por Tests MV como la sincronización de XML’s.

184