Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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
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.
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].
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.
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
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
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
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].
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.
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:
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
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
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
Short Releases
Testing
Pair Programming
Coding Standards
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
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:
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.
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
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:
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
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.
Modelado de estrategias
Modelar las estrategias a sus alumnos a
través de la resolución del 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.
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.
39
Ilustración 12: Niveles de cursos y estrategias de implementación
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.
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
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.
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 .
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
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.
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.
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.
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
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
(Aprendices)
a
ogí
n ol
Tec
s
Va pio
lor
es
Profesor / Mediador
rin ci
P
Prácticas
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
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:
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
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
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)
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.
Proyecto de
Software
Ingeniero
de Software
Producto de
Equipo de Software
Desarrollo
Tecnología
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.
Lo mismo sucede en el caso del ingeniero de software que tenga el rol de Tracker, tal como se
muestra en la Tabla 19.
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.
Ciclos de un proyecto XP
Ciclo de
Programación
de calidad
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
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
Ritmo Sostenido
( No a las horas extra)
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.
69
El flujo del Planning Game C = Cliente
D = Desarrollador
Estimar Historias D
Dividir Historias C
NO
¿Estimable?
SI Experimentos Concretos D
Fase de Compromiso
Ordenar por Valor C
Definir Velocidad D
Decidir Alcance C
Plan no es
Desarrollo XP D
adecuado
Re-Estimar D Test Ejecutar D
¿OK? no
Funcionales Validar C
si
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:
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.
versus
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.
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
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
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.
Identificar los
Analizar componentes de un todo
Transferir conocimientos y
Aplicar estrategias a una situación familiar
Ilustración 23: Versión adaptada de la Taxonomía de Bloom por la American Psichology Association33
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
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.
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
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.
Retroalimentación de avance
Desarrollo Guiado por Tests
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
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.
Retroalimentación de avance
Desarrollo Guiado por Tests
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
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
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.
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
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
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)
2. ¿Cómo compararía la experiencia de este curso con el resto de los ramos de la carrera? ¿Qué
elementos destacaría?
Ambiente humano
Destrezas
Total
Otros
0 1 2 3 4 5 6 7 8 9 10
Nº menciones
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
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
Reuniones de evaluación
planificacion y seguimiento
Otras
mini tareas
Brainstormings
Desarrollo en Programació Programació
n de Calidad n en Equipo
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
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
0 1 2 3 4 5 6 7
N º de menciones
Aplicación de XP
Nunca
6. ¿Ha aplicado XP en algún proyecto? ¿En cuántos? Parcialmente
Totalmente
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
compartir conocimiento
Prog
Programación de a Pares
Refactorización
Diseño Simple
Stand Up Meeting
Gestión del
Total
Equipo
Retroalimentación de avance
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
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é?
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.
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.
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.
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
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.
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
Involucramiento Desarrollo
temprano de los
alumnos
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
de Calidad
(Tracking) Guiado por Tests Integración
continua
Aprendizaje
Cognitivo de Ritmo Sostenido
nuevas destrezas ( No a las horas extra)
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.
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
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.
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.
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.
Ilustración 45: Charla sobre Desarrollo Guiado por Tests dada por un alumno
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
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.
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:
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.
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.
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”.
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
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.
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:
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.
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.
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
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
5 5 Presentaciones Iniciales
12 12 Primer Ciclo
19 19 Segundo Ciclo
Septiembre Agosto
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
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.
138
Ilustración 52: Equipo presentando algunos avances al cliente
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.
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)
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.
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
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.
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.
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
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
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: ___________________________
total 28
Observaciones:
157
Segunda parte: Evaluación de proyecto realizado desde la
perspectiva de XP
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)
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
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
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.
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
Aplicació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
Aplicación
Comprensión
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
Aplicación
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”
Ciclo 2
Ciclo de generación de valor
Comprensión
Aplicación
164
Ciclo de desarrollo en equipo
Comprensión
Aplicación
165
Ciclo de Programación Incremental de Calidad
Comprensión
Aplicación
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”
Comprensión
167
Aplicació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.”
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."
Comprensión
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
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.”
Comprensión
Aplicación
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”
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.”
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.
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
Aplicación
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."
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
178
Motivador
Liderazgo
Motivador MV No hay información suficiente para evaluar
Aplicación
“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.”
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”
Comprensión
181
Tema Concepto Alumno Errores
Programación
de Calidad Refactorización BB No aporta información suficiente para evaluar
182
Aplicación
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