GUA DE BUENAS PRCTICAS EN EL USO DE METODOLOGAS GILES SCRUM/XP

ORIENTADA A EQUIPOS SIN EXPERIENCIA

GOOD PRACTICES GUIDE IN THE USE OF SCRUM AND XP METHODOLOGIES
ORIENTED TO INEXPERIENCED TEAMS
Giannina Costa 1

Romina Torres 2

David Ruete3

RESUMEN
Uno de los principales factores de xito de las metodologas giles en la generacin de software de calidad
reside en la experiencia de los equipos de desarrollo. Tpicamente equipos inexpertos suelen cometer errores
recurrentes para los cuales equipos seniors ya cuentan con buenas prcticas para evitarlos o mitigar sus efectos.
Lamentablemente, esa informacin no siempre es de fcil acceso. En este trabajo, proponemos una gua de
buenas prcticas orientada a equipos inexpertos en la utilizacin especfica de Scrum como metodologa de
gestin y Extreme Programming como metodologa de desarrollo de software, la cual est inspirada en patrones y antipatrones recolectados en la literatura. Nuestra propuesta est siendo validada utilizando una muestra de alumnos
en trabajo de ttulo de la Universidad Andrs Bello.
Keywords: Equipos inexpertos, calidad, metodologa Scrum, metodologa XP, patrones, anti patrones.
ABSTRACT
One of the main success factors of the agile methodologies on the production of software with high levels of quality
resides on the experience of the development teams. Typically, inexperienced teams often make recurrent errors for
which, senior teams already have good practices to avoid them or to mitigate their effects. Unfortunately, this
information not always is easy to find. In this work, we propose a guide of good practices oriented to inexperienced
teams on the specific use of Scrum as management methodology and extreme programming as software development
methodology, which is inspired on patterns and anti-patterns recollected from the literature. Our proposal is being
validated using a sample of students from the Universidad Andrs Bello working on software projects, which are their
final project to obtain their professional degree.
Keywords: inexpert teams, quality, Scrum methodology, XP methodology, patterns, anti-patterns.
I. INTRODUCCIN
Uno de los principales temas de inters de la comunidad
informtica, es el creciente aumento de proyectos
utilizando metodologas giles (MAs) tanto en el
desarrollo como en la gestin de stos [12]. Estas
metodologas se han hecho muy populares en los ltimos
aos, debido a la posibilidad que brindan de realizar
entregas funcionales a los clientes rpidamente,
manteniendo fijo los costos y tiempos del proyecto,
adems de aceptar cambios de requisitos [3]. Las MAs
apuestan a equipos multidisciplinarios, auto organizados
y bien gestionados donde el rol jefe de proyecto deja de
tener relevancia, pues todos los integrantes tienen el
mismo poder de opinin y decisin en los temas que se
plantean. Para medir la calidad tanto del producto final
como de las entregas funcionales tempranas existen
diversos modelos de calidad, tales como el modelo de
ISO/IEC 9126-2001 el cual se enfoca en la calidad del
producto de Software (tanto interna como externa) junto
a la calidad en uso. En la Figura 1 detallamos las
1
2
3

categoras y sub categoras que aborda la calidad del

producto de software y en la Figura 2 se muestran las sub
categoras que se consideran en la calidad de uso.

Figura 1: Categoras y Sub Categoras de Calidad del

producto de Software

Facultad de Ingeniera, Universidad Andrs Bello, Quillota 980, Via del Mar Chile E-mail: g.costa@uandresbello.edu
Facultad de Ingeniera, Universidad Andrs Bello, Quillota 980, Via del Mar Chile E-mail: romina.torres@unab.cl
Facultad de Ingeniera, Universidad Andrs Bello, Sazi 2324, Santiago
Chile E-mail: druete@unab.cl

Figura 2: Sub categoras de la calidad de uso

Lamentablemente, un equipo inexperto depende de l
mismo para enfrentar situaciones que pueden afectar
directamente la calidad interna y externa del producto,
tales como la validacin y verificacin de los
requisitos en cuanto al nivel requerido de especificacin
de estos tanto en la primera etapa (para comprender el
alcance del proyecto, identificar objetivos y construir una
visin de desarrollo comn) como en etapas posteriores.
Empricamente se observ durante el primer semestre de
este ao en la Universidad Andrs Bello (UNAB) el
desarrollo de cinco proyectos de software llevados por
equipos inexpertos con metodologa Scrum [13] y
Extreme Programming (XP) [2]. Dentro de los
principales inconvenientes observados en el estudio de la
muestra se encuentran la falta de disciplina y auto
organizacin del equipo de desarrollo, junto a la falta de
conocimiento terico y prctico de las metodologas con
las cuales se trabajaba. Dada nuestras constantes
observaciones, los equipos de desarrollo comenzaron a
apartarse lentamente a la filosofa gil, desencadenando
con esto una desorientacin en el desarrollo y gestin de
sus proyectos afectando tanto la calidad externa y en
sobre manera a la calidad interna del producto a
desarrollar.
En este trabajo hemos construido una gua de buenas
prcticas (BPs) que permite orientar a equipos inexpertos
en el desarrollo y gestin de un proyecto gil con el
fin de contribuir en la mejora de la calidad del producto
de software. Para este propsito se realizaron las
siguientes etapas: (1) levantamiento de los problemas
experimentados por la muestra de proyectos llevados por
equipos inexpertos en la UNAB, (2) establecimiento de
relacin causa efecto entre problemas identificados en el
estudio inicial y los efectos en la calidad del producto, (3)
identificacin en la literatura de anti-patrones giles ms
recurrentes en equipos de desarrollo inexpertos [10],
[6], [5], (4) identificacin en la literatura de patrones
giles, (5) establecimiento de la relacin entre estos
problemas detectados y los anti-patrones que
presentaba la literatura y, (6) establecimiento de una
gua de BPs inspirada en los patrones giles que aborden
los problemas o los anti-patrones relacionados. Adems
se encuentran en curso las siguientes etapas: (7)
socializacin de la gua de BPs a la misma muestra
adems de nuevos equipos inexpertos y, (8) recopilacin
y anlisis de resultados intermedios en cada sprint.

El resto de este artculo se divide en las siguientes

secciones. Seccin II se caracteriza el problema en cuanto
a la baja calidad percibida por los product owners en las

entregas parciales de los productos versus un estudio de

las causas posibles asociadas a problemas de mal uso de
las metodologas. Seccin III se presentan los antipatrones y patrones giles recolectados de las MAs.
Seccin IV presenta nuestra propuesta que consiste en
un conjunto de BPs que contribuirn a mejorar la
calidad del producto. Seccin V presenta nuestra
propuesta de validacin. Seccin VI discute propuestas
de otros autores intentando resolver parcial o
completamente el mismo problema que nosotros
atacamos. Para dar trmino al trabajo se desarrolla la
Seccin VII que establece lneas bases de futuras
investigaciones.
II.- CARACTERIZACIN DEL PROBLEMA
Para lograr determinar la calidad externa del producto se
cre una encuesta considerando las categoras y sub
categoras de calidad del producto de software, junto
a los atributos de calidad, utilizando para ello la escala
liker, dando como resultado la encuesta que fue aplicada
a los product owner de cada equipo desarrollo. Esta
encuesta fue respondida por cada product owner los
cuales determinaron la calidad del producto que fue
desarrollado en el sprint. Del mismo modo, para
determinar la calidad interna del producto de software
se desarroll una encuesta que permiti determinar si el
proceso y la gestin del desarrollo de software se
realizaron acorde a las MAs. Para la creacin de esta
encuesta se tom como base los principales patrones
y anti-patrones giles, junto a los problemas frecuentes
encontrados en los equipos de desarrollo inexpertos.
Esta encuesta mide cinco aspectos de inters que
permiten apoyar a la calidad interna del producto
estos son: Trazabilidad, Comprensin de MAs por
parte del Scrum Master, Comprensin de MAs por
parte del equipo de desarrollo, Trabajo colaborativo,
MAs adecuada. La encuesta se desarroll utilizando
preguntas dicotmicas (Si o No), lo cual permito
conocer en forma rpida y fcil, que tareas se
desarrollaron y cules no. Esta encuesta se aplic al
equipo de desarrollo una vez finalizado el sprint.
Por lo tanto, luego de la entrega de funcionalidad del
sprint de los proyectos a su correspondiente product
owner, se procedi a determinar la calidad de esta
entrega. La Figura 3 muestra los porcentajes obtenidos
en cada una de las categoras y subcategoras
correspondiente a la calidad externa y calidad interna,
destacndose dentro de esta muestra el aspecto de
confiabilidad como uno de los puntos ms dbiles
obteniendo un 51% de aprobacin por parte del product
owner. En el otro extremo se encuentra la usabilidad la
cual se encuentra con la mejor evaluacin por parte de
los product owners obteniendo un 62% de aprobacin.
Finalmente la calidad del producto (externa) por parte
de equipos inexpertos obtuvo un 56 % de aprobacin
por parte de los product owners. Dado el bajo nivel de
calidad externa del producto establecido por la encuesta
anterior, se procedi a determinar mediante una revisin
del proceso de gestin y desarrollo cules podran ser

Universidad Andrs Bello Direccin Postal 250000 E-mail:g.costa@uandresbello.edu romina.torres@unab.cl druete@unab.cl

los factores incidentes (calidad interna) de este efecto

obtenindose un promedio general de 17% de
aprobacin.

hecho de la abundancia de material sin gua para la

adecuacin a su proyecto puede haber incidido
negativamente en este resultado.

Figura 3 : Calidad externa y de uso de la entrega de

funcionalidad
La Figura 4 muestra los porcentajes promedios
obtenidos en cada factor, dentro de los cuales, destacan
como l peor evaluado la compresin del equipo de
desarrollo sobre la metodologas Scrum/XP (8 %) y el
mejor evaluado el trabajo colaborativo (23 %).

Figura 5: Valores actuales de los sub factores que inciden en

la calidad interna del producto
Posterior a esto, y en base a revisiones se detectaron los
siguientes sub problemas tanto en el desarrollo como
en la gestin de sus proyectos:
Problema 1: El 0 % de los equipos de desarrollo logr unificar
en forma adecuada los roles de ambas metodologas.
Problema 2: El 0 % de los equipos de desarrollo logro
definir correctamente las fases de Scrum/XP

Figura 4: Valores promedio de los factores que inciden en la

calidad interna del producto.

La Figura 5 muestra los detalles de los criterios

considerados para medir cada factor. Respecto a estos
resultados es interesante destacar varios puntos. Cada
equipo estaba conformado por dos personas cuyo
product owner eran ellos o clientes finales que
asumieron la responsabilidad, creemos que el trabajo
colaborativo obtuvo el mayor ndice de aprobacin
debido a que los equipos de trabajo estn
conformados por dos personas y que la Universidad
semanalmente revisaba su avance. Respecto a la
compresin del equipo de desarrollo
sobre la
metodologas Scrum/XP, si bien los equipos fueron
apoyados con literatura y material referente a MAs y
que cuentan con un curso previo de Metodologas de
Desarrollo de Software y de Direccin de proyectos, el

Problema 3: El 10 % de los equipos de desarrollo logr definir

los artefactos que se utilizan tanto para Scrum como para XP,
pero ninguno de ellos logro determinar en qu instante del
proceso deba realizarse.
Problema 4: Si bien ms del 60 % de los equipos ejecut la
actividad estimacin de las historias de usuarios, solo un 20%
lo realiz considerando el tamao cualitativo no cuantitativo.
Problema 5: El 100 % de los equipos de desarrollo
convirtieron las historias de usuarios en tareas, pero gran
parte de ellos omitieron un gran nmero de tareas que resultan
de vital importancia para que la estimacin sea definida en
forma correcta.
Problema 6: Aunque los equipos definieron la arquitectura
preliminar no tenan evidencia de que sta evolucionara a
medida que avanzaba el proyecto.

Universidad Andrs Bello Direccin Postal 250000 E-mail:g.costa@uandresbello.edu romina.torres@unab.cl druete@unab.cl

Problema 7: La mayora de los proyectos no lograron

conseguir que el product owner priorizar de forma efectiva
las historias de usuario, lo que complic en gran medida las
funcionalidades que deban realizarse en primera instancia.
Problema 8: La mayora de los equipos dijo poder realizar ms
historias de usuario por sprint de las que logr implementar.
Problema 9: Gran parte de las historias de usuario definidas
eran requerimientos funcionales.

continuacin se muestra una recopilacin de los antipatrones divididos por reas de gestin de proyecto,
desarrollo de software, pruebas, equipo de desarrollo y
arquitectura.
Anti-patrones de Gestin de proyecto:

Problema 10: La mayora de los equipos priorizaron las

historias de usuario acorde a su opinin ms que en base a lo
establecido por el product owner.

Problema 11: Gran parte de los equipos propusieron

diferentes duraciones para cada uno de sus sprints.

Anti-patrn 1 -Ausencia de documentacin [7].

Anti-patrn 2 -No adaptacin de la Metodologa gil
al contexto [14].
Anti-patrn 3 - Las MAs son fciles de implementar
y no necesitan ajuste [9].
Anti-patrn 4 -Tendencia a complicar las cosas
violando el principio KISS.
Anti-patrn 5 -Tendencia a
implementar
funcionalidades no solicitadas -YAGNI (You aint
gonna need it).
Anti-patrn 6 - No reusabilidad -DRY (Dont Repeat
Your- self).

Problema 12: Ningn equipo defini meta para su sprint.

Anti-patrones de desarrollo de software:

Problema 13: Ningn equipo estim la velocidad del equipo
de desarrollo, lo que ocasion estimaciones deficientes.

Problema 14: La mayora de los equipos seleccion product

owners que desconocan las tcnicas de historias de usuario,
criterios de aceptacin y priorizacin, adems de no tener
conocimiento cabal de las necesidades que se deseaban
satisfacer.

Problema 15: Ningn equipo us ni defini los estndares de

codificacin a utilizar durante el desarrollo de producto.
Problema 16: Ningn
cdigo.

equipo

Anti-patrones de Pruebas:

realiz refactorizacin de

Problema 17:
Ningn equipo realiz planificacin de
pruebas unitarias, integracin, sistemas, aceptacin.
Problema 18: La mayora de los equipos ejecutaron reuniones
acorde a sus necesidades y no acorde a lo que exigan las
metodologas seleccionadas.

Problema 19: Ningn equipo defini el alcance de cada

release tal como indican estas metodologas.
Problema 20: La mayora de los equipos seleccion Scrum
masters que desconocan sus funciones y responsabilidades.

III. MARCO TERICO

III-A. Anti-patrones giles

Gamma et al. [8] defini el trmino patrn el cual
concentra un conjunto de buenas soluciones y prcticas
para el diseo. Por otro lado, Brown [5] introdujo como
4 contrapartida natural los anti-patrones de diseo. A

Anti-patrn 11 -Auto-engaarse con pruebas

unitarias de baja efectividad - Mentiroso.
Anti-patrn 12 -El Setup Excesivo de ambiente
necesario para ejecutar una prueba puede
dificultar determinar su resultado - Setup Excesivo.
Anti-patrn 13 Probar una nica unidad requiere
gran cantidad de tiempo - Gigante.
Anti-patrn 14 -Casos de prueba que no abordan
su objetivo de prueba - Burla.
Anti-patrn 15 -Casos de pruebas con alta
dependencia de la estructura del cdigo quedan
obsoletos al realizar refactorizacin al cdigo Inspector.

Anti-patrones Equipo de desarrollo:

Problema 21: Ningn equipo public ni mantuvo actualizado

su tablero de tareas, ni grfico burndown.

Con el objetivo de establecer una lnea base en la

confeccin de la gua de BPs, en esta Seccin nos
enfocamos en el estudio de los patrones y anti-patrones
en el desarrollo y gestin de un producto de software
utilizando MAs. A fin de poder contrastarlos con los
problemas detectados.

Anti-patrn 7 -No asegurar la alta cohesin y el

bajo acoplamiento (Hollywood - dont call us, well
call you).
Anti-patrn 8 -No aplicar el principio de diseo de
responsabilidad - Clase de Dios [4].
Anti-patrn 9 -Cdigo de uso temporal presente
Fantasmas.
Anti-patrn 10 -Cdigo espagueti [4].

Anti-patrn 16 -Asumir que el scrum master es el

Jefe de Proyecto.
Anti-patrn 17 -El slo hecho de tener
programadores expertos dentro del equipo de
desarrollo asegurar el xito del proyecto.
Anti-patrn 18 - El cliente es el Jefe del proyecto.
Anti-patrn 19 -Mientras ms miembros en el
equipo, mejor.
Anti-patrn 20 - El cdigo es mo.

Anti-patrones Arquitectura

Anti-patrn 21 -Vendor Lock-In (Arquitectura

dependiente del producto).
Anti-patrn 22 -Architecture by implication
(Arquitectura implcita).
Anti-patrn 23 -Reinvent the wheel (Reinventar la
rueda).
Anti-patrn 24 -No es necesario definir una
arquitectura cuando se usan MAs.

Universidad Andrs Bello Direccin Postal 250000 E-mail:g.costa@uandresbello.edu romina.torres@unab.cl druete@unab.cl

III-B. Patrones giles

Acorde a Alexander [1] cada patrn describe un
problema que ocurre una y otra vez en nuestro entorno,
para describir despus el ncleo de la solucin a ese
problema, de tal manera que esa solucin pueda ser
usada ms de un milln de veces de la misma forma.
En este contexto, Muela [11] realizo un estudio que
permiti definir un conjunto de patrones que resultan de
inters en la metodologa de desarrollo XP dentro de los
que se mencionan:

Patrn 1 - El product owner debe ser capaz de

generar historias de usuario que aporten valor al
negocio.
Patrn 2 - Las historias de usuario deben ser
escritas siguiendo una estructura definida.
Patrn 3 - Toda historia de usuario debe ser
convertida a un conjunto de tareas que consideran
desde aspectos funcionales hasta temas de
arquitectura, pruebas y refactorizacin.
Patrn 4 - La estimacin ms eficiente se basa en la
estimacin por puntos de historia, la cual permite
determinar el tamao de una historia de usuario.
Patrn 5 - Los desarrolladores deben ser capaces de
estimar cada tarea, y de dividir las tareas que
necesiten ms de unos das en ser implementadas.
Patrn 6 - Dividir epopeyas (historias de usuario con
gran alcance) en historias de usuarios que permita
disminuir el alcance de lo que se realizar.
Patrn 7 - Se debe determinar la velocidad del equipo
de desarrollo a fin de poder determinar el nmero de
puntos de historias que puede ser realizado en una
iteracin.
Patrn 8 -El product owner debe dar valor a las
historias de usuario, con el fin de poder generar el
product backlog a ser desarrollado.
Patrn 9 -Determinar y monitorear historias de
usuario clasificadas como de alto riesgo.
Patrn 10 -Los desarrolladores determinan que
tareas desean realizar, manteniendo un equilibrio en el
trabajo con respecto al resto del equipo.
Patrn 11 -El trabajo
realizado
por
cada
desarrollador debe ser integrado en forma rpida
pocas horas (1 da como mximo).
Patrn 12 -No considerar finalizada una historia
de usuario hasta que pase todas las pruebas.
Patrn 13 -Escribir los casos de prueba antes de
comenzar el cdigo.
Patrn 14 -Validar cada requisito utilizando al menos
una prueba de unidad.
Patrn 15 -Las pruebas de integracin se
efectuarn siempre, antes de aadir cualquier nueva
funcionalidad al proyecto, o despus de modificar
cualquiera existente.
Patrn 16 - Monitorear la falta de amplitud o el
exceso de casos de prueba aadiendo nuevos o
quitando elementos respectivamente.
Patrn 17 - Disear antes de construir.
Patrn 18 - Generar cdigo en parejas.
Patrn 19 -Registrar y monitorear progreso
frecuentemente

IV PROPUESTA
Mediante el cruce de patrones, anti-patrones utilizados
frecuentemente en MAs y los problemas detectados en
los equipos inexpertos se cre un conjunto de BPs. Esta
consiste en 31 BPs que contribuirn en el desarrollo de
un producto de calidad. Estas BPs fueron trazadas con
los patrones y anti- patrones giles mencionados en el
marco terico junto a los problemas detectados en los
equipos inexpertos de la muestra.
Las BPs orientadas a la gestin de proyectos son:
BP1: Definir roles de acuerdo a metodologa Scrum/XP. Al
definir de forma adecuada los roles que participarn en el
proyecto, permite dar respuesta a anti-patrn 1 y a problema 1
enfrentado por equipos inexpertos en el desarrollo y
gestin de proyectos giles.
BP2: Definicin de fases de acuerdo a metodologa
Scrum/XP. Al establecer las fases con las que contar el
proyecto y las actividades a desarrollar en cada una de ellas,
permite enfrentar a los anti-patrones 3 y 4, y al problema 2
detectado en equipos inexpertos.
BP3: Definicin concepto HECHO. El establecer el trmino
HECHO, permite al equipo de desarrollo tener claridad en
lo que debe ser finalizado al termino del Sprint, dando
respuesta a los anti-patrones 2 y 3.
BP4: Definir nmero y metas de releases. Al planificar el
proyecto deben tenerse claridad del nmero de release
(liberaciones) y la meta de cada uno de ellos, con lo cual se
evitan los anti-patrones 3 y 4, y dando solucin al problema
19.
BP5: Definir nmero de sprints y duracin de cada uno. Es
importante en el proceso de planificacin establecer una
duracin fija de los Sprint y la cantidad a desarrollar
durante el proyecto, para de esta forma evitar ambigedades y
desconcierto dentro del equipo. Esta buena prctica permite
evitar los anti-patrones 4 y 5, junto a dar solucin a los
problemas 11 y 12.
BP6: Definir product owner apropiado al proyecto. La
eleccin apropiada del product owner resulta gravitante en las
MAs, debido al alto grado de participacin e influencia
dentro del proyecto. Esta buena prctica apunta a solucionar
anti-patrn 18, junto a dar solucin al problema 14.
BP7: Definir Scrum Master con conocimiento de MAs
(prctica y/o terica). El Scrum Master dentro de un proyecto
gil, resulta ser el evangelizador de las MAs, promoviendo el
correcto uso de ellas, para lo cual debe prepararse a
conciencia para enfrentar el desafo. El cumplimiento de esta
buena prctica da respuesta al anti-patrn 16 y18, junto a dar
solucin al problema 20.
BP8: Definir esqueleto de la arquitectura a utilizar. El
concepto equvoco de que no es necesario definir arquitectura
al inicio de un
proyecto gil,
ocasiona
grandes
inconvenientes en el desarrollo de este. Esta buena prctica
apunta a solucionar el anti-patrn 21, 22, 23 y 24 junto a dar
solucin al problema 6.
BP9: Planificar fecha, duracin y lugar de reuniones de
planificacin, diaria, retrospectiva y entrega. La planificacin
inicial de reuniones estableciendo fechas, lugar y hora permite
al grupo de desarrollo una estructura de trabajo definida.
Dando respuesta de esta forma a los anti-patrones 2 y 3, junto
a dar solucin al problema 18.
BP10: Establecer el uso y la mantencin de tableros. El
mantener irradiadores de informacin resulta clave no solo
para el equipo de desarrollo, sino que tambin para toda la

5
Universidad Andrs Bello Direccin Postal 250000 E-mail:g.costa@uandresbello.edu romina.torres@unab.cl druete@unab.cl

organizacin, el patrn 19 hace mencin a la importancia de

ello. Permitiendo de esta forma evitar anti-patrn 1 y
contribuir con Problema 21.
BP11: Establecer procedimientos de emergencias que mitigen
el retraso del desarrollo del proyecto. Es importante contar
durante el proyecto con procedimientos que permitan enfrentar
eventuales problemas que puedan producir retrasos o aumento
de los costos.

Las BPs orientadas al desarrollo del proyecto son:

BP12: Conocer orden y forma de utilizar los artefactos de
Scrum/XP. El equipo de desarrollo debe contar con el
conocimiento de los artefactos que deben ser construidos
durante el proyecto, el orden en que se realizan cada uno de
ellos y la importancia de estos para el proyecto. Evitando de
esta forma caer en el anti-patrn 2 o 3 y solucionando el
problema 3.
BP13: Creacin de Historias de Usuario ptimas. La correcta
definicin de las historias de usuario, permitir un ptimo
proceso de elitacin
de
requerimientos
evitando
ambigedades e inconsistencias. Los patrones 1 y 2 hacen
referencia a ello, permitiendo de esta forma evitar antipatrn 3,4 5 y dar respuesta al Problema 9.
BP14: Estimacin de Historias de usuarios. El estimar
historias de usuario permite al equipo de desarrollo tener una
visin cualitativa de las historias que revisten mayor riesgo
dentro del proyecto. Pudiendo de esta forma evitar anti-patrn
3,4 y contribuyendo a la solucin del Problema 4.Patrn 4
hace mencin a esto.
BP15: Asignar prioridad a las historias de usuario. Cada
historia de usuario aporta valor al negocio, el product owner
debe ser el llamado a definir cul de ellas es la que resulta de
mayor importancia al negocio. El patrn 8 hace referencia a
esto. Dando respuesta al problema 7 y evitando de esta forma
los anti-patrn 3,4
BP16: Creacin del Product Backlog. La creacin de la Pila
de productos priorizada, permite organizar de forma adecuada
las historias de usuario a realizar, evitando de esta forma los
anti-patrn 3 y 4 y contribuyendo a los Problema 7 y 10.
BP17: Creacin del Sprint Backlog. La creacin de los Sprint
Backlog resulta ser una de las tareas ms importantes dentro
del proyecto, pues ac se determinan las historias de usuario a
realizar. Considerando para ello, los riesgos, estimacin de
puntos de historia, velocidad del equipo. La correcta
creacin sprint backlog evita anti-patrn 3 y 4 y da
solucin a Problema 8.
BP18: Definir Meta de Sprint. Es primordial que cada Sprint
tenga una meta clara, de forma tal de orientar al equipo de
desarrollo a lo que se espera de ellos en cada Sprint, evitando
de esta forma caer en anti-patrn 1, 2 y 3 y contribuyendo a la
solucin del Problema 12.
BP19: Convertir historias de usuario en tareas. La correcta
definicin de tareas que conforman una historia de usuario,
permite cumplir con los tiempos y plazos establecidos.
Patrn 3, 5, 9 dejan claro la importancia de esta etapa. Al
definir en forma correcta todas las tareas que estn
involucradas se evita anti-patrn 1,2, 3 y da solucin Problema
5.
BP20: Estimar velocidad del equipo. Resulta poco apropiado
establecer compromisos de entrega si no se conoce la
velocidad de equipo, resulta importante saber la capacidad del
equipo de desarrollo (patrn 7). Esto permitir evitar antipatrn 1,2, 3 y contribuir a la solucin Problema 13
BP21: Creacin tarjetas CRC. XP dentro de sus artefactos
establece las tarjetas CRC (clase, relacin, colaboracin). Las
cuales contribuyen al diseo (patrn 17) del proyecto y evitan

de algn modo los anti-patrn 8, 9, 10. Esta buena prctica

apoya a la solucin Problema 3.
BP22: Gestin de riesgos. Todo proyecto tiene asociados
riesgos los cuales deben ser detectados y gestionados, patrn 9
hace mencin a ellos.
BP23: Creacin y mantencin de tableros. Las MAs
establecen el seguimiento del proyecto apoyado en el uso de
tableros que permitan evidenciar el estado de avance del
proyecto (patrn 19), evitando de esta forma documentacin
innecesaria (anti-patrn 1). Apoyando a la solucin del
Problema 21.
BP24: Creacin y diseo de pruebas antes de la codificacin.
La creacin de un plan de pruebas resulta de gran
importancia para el desarrollo de productos de calidad, existen
muchos anti-patrones que hacen referencia a la deficiente
gestin de plan de pruebas (anti-patrn 11, 12, 13,14, 15). En
contrapartida existen patrones que dan respuesta a la
importancia de las pruebas (patrn 12, 13, 14, y 15). Esta
buena prctica evitar Problema 17.
BP25: Establecer patrones de interrupcin. Es de importancia
dejar tiempo para poder reaccionar si ocurren inconvenientes
(Tareas no consideradas, tareas mal estimadas), estableciendo
para ellos un buffer de tems inesperados. De esta forma se
evita caer en anti-patrn 4.
Las BPs orientadas a la codificacin son:
BP26: Creacin de estndares de codificacin. Es muy
importante establecer estndares de codificacin dentro del
equipo de desarrollo a fin de evitar cdigos ambiguos y poco
trazables. Esto contribuye a evitar anti-patrn 8, 9,10, 20.
Dando solucin al problema 15.
BP27: Refactorizacin constante del cdigo. El concepto de
refactorizacin es una de claves dentro de las MAs, pues esta
apunta a la mejora del diseo, eficiencia y calidad.. Evitando
de esta forma anti-patrn 5, 6, 7, 20 y contribuyendo en la
solucin del Problema 16.
BP28: Preocuparse de mantener cdigo limpio, la propiedad
colectiva del cdigo hace que resulta importante el mantener
un cdigo limpio durante del desarrollo, con el fin de poder
evitar anti-patrn 10.
BP29: Establecer la Programacin en pares. MAs en
especial XP, aconseja programacin de pares ya que afirma
que el cdigo resultante es ms eficiente y limpio (patrn
18), evitando de esta forma caer anti-patrn 19.
BP30: Evangelizar sobre la propiedad colectiva del cdigo. Al
tomar conciencia sobre la propiedad colectiva del cdigo, el
equipo tender a utilizar estndares de codificacin, a realizar
cdigos limpios y ptimos (patrn 18), evitando de esta forma
anti-patrn 20 y apoyando a la solucin Problema 15 y 16.
BP31: Mantener un ritmo sostenible de codificacin. Es de
relevancia que equipo mantenga un ritmo sostenible dentro del
proyecto pues esto permitir determinar velocidad de equipo
evitando de esta forma malas aproximaciones. Patrn 19
apoya esta buena

V. VALIDACION
Tal como se realiz en la Seccin II para medir la
calidad del producto, se realizarn dos encuestas tanto
al product owner, como al equipo de desarrollo, para
determinar si la introduccin de las BPs refleja un
incremento en la calidad del producto de Sw.
Actualmente ya se realiz una induccin de la gua de
BPs a alrededor de 20 desarrolladores que se encuentran
trabajando en proyectos giles dentro de la UNAB. Esta
induccin tuvo una duracin de 120 minutos en la cual

Universidad Andrs Bello Direccin Postal 250000 E-mail:g.costa@uandresbello.edu romina.torres@unab.cl druete@unab.cl

se fue explicando en forma detallada como cumplir a

cabalidad las BPs. En forma paralela se ha ido apoyando
la aplicacin de las BPs en forma personal. En este
momento estamos a puertas del trmino de un sprint
para los grupos de muestra. Finalizado el sprint se
medir la calidad del entregable generado, as como el
cumplimiento de las BPs de manera de determinar si
existe una correlacin entre su uso y el aumento de la
calidad.
VI. TRABAJO RELACIONADO
Como alternativa a nuestra propuesta hemos encontrado
el trabajo de Muela [11], quien realiza un estudio que
permiti definir un conjunto de patrones que resultan de
inters en la metodologa de desarrollo XP. A diferencia
del trabajo de Muela [11] nuestra propuesta establece un
conjunto de buenas prcticas no slo para la
metodologa de desarrollo sino para su uso con una
metodologa de gestin. Es importante notar que el 45%
de nuestras buenas prcticas (14 buenas prcticas)
pueden ser encontradas en los patrones del trabajo de
Muela [11] pero el 55 % restante (17 buenas prcticas)
no.
VII. CONCLUSIONES Y TRABAJOS FUTUROS

En este trabajo hemos presentado una propuesta de un

conjunto de buenas prcticas en base a patrones
recopilados de las metodologas giles que responden a
los principales problemas detectados que
tienen
relacin con anti-patrones conocidos. Creemos que
nuestros primeros resultados sern prometedores, en
cuanto a la calidad de los entregables liberados en cada
Sprint por parte de equipos de desarrollo usando nuestra
propuesta. Esta aseveracin se fundamenta en el hecho
que hemos notado que varios de los problemas
detectados en los equipos inexpertos han sido resueltos
con el apoyo de esta gua, dado que algunos de estos
problemas eran causa del efecto de baja calidad,
creemos que vamos en buen camino. Creemos que la
importancia de este trabajo radica tambin en contar ya
con valores cuantificables de la calidad de los
entregables que puede ser utilizado por otros autores a
fin de comparar propuestas.
Este es un trabajo que se encuentra en desarrollo.
Actualmente se encuentra pendiente la realizacin del
segundo experimento que consiste en la aplicacin de
las encuestas a equipos de desarrollo y product owner
que se encuentren trabajando con la gua de BPs. Dentro
de los trabajos futuros se considera extender la muestra
(tanto para el estudio de la ocurrencia de problemas en
equipos inexpertos como de la correlacin de la mejora
en las liberaciones de aquellos equipos que aun siendo
inexpertos utilizan la gua de BPs) de la sede actual de
la UNAB a sus diferentes sedes, a otras Universidades,
para finalmente llevarlo al mbito empresarial. Dada
estas nuevas muestras con valor estadsticos
significativo nos permitir refinar esta gua para
eliminar aquellas prcticas en que notemos no tienen
correlacin positiva con la mejora en la calidad del

producto como de ir agregando nuevas necesarias.

Como trabajo futuro, creemos que es posible describir
nuestras BPs en el formato de un patrn de manera
que su entendimiento y aplicacin resulten ms
simple para la comunidad informtica

AGRADECIMENTOS
A los alumnos de proyecto de ttulo ao 2014 de la
carrera de Ingeniera en Computacin e Informtica sede
Via del Mar de la UNAB.

REFERENCIAS
[1]
C. Alexander, S. Ishikawa, and M. Silverstein. A Pattern
Language: Towns, Buildings, Construction.
Center for
Environmental Structure Berkeley, Calif: Center for Environmental
Structure series. OUP USA,1977.
[2]
Kent Beck and Cynthia Andres.
Extreme Programming
Explained: Embrace Change (2Nd Edition). Addison-Wesley
Professional, 2004.
[3] Carlos Ble Jurado, Juan Gutierrez Plaza, Fran Reyes Perdomo,
and Gregorio Mena. Disen o A gil con TDD. lulu.com, 2010.
[4] Martin Robert C Cdigo limpio: manual de estilo para el
desarrollo gil de software, Anaya Multimedia-Anaya Interactiva,
2012
[5] William J. Brown, Raphael C. Malveau, Hays W. McCormick,
III, and Thomas J. Mowbray. AntiPatterns: Refactoring Software,
Architectures, and Projects in Crisis. John Wiley & Sons, Inc., New
York, NY, USA,1998.
[6] William J. Brown, Hays W. McCormick, and Scott W. Thomas.
Anti- Patterns Project Management. John Wiley & Sons, Inc., New
York, NY, USA, 1st edition, 2000.
[7] Martin Fowler.
Patterns of Enterprise Application
Architecture. Addison-Wesley Longman Publishing Co., Inc., Boston,
MA, USA, 2002.
[8] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
De- sign Patterns: Elements of Reusable Object-oriented Software.
Addison- Wesley Longman Publishing Co., Inc., Boston, MA, USA,
1995.
[9] Javier Garzs. Gestin de proyectos gil . . . y las experiencias de
ms de 12 aos de proyectos giles. 233 grados de TI, 2014.
[10] Mitch Lacey and Jonathan Wanagel. Technical interviewing youre doing it wrong, 2013.
[11]
Patricia Muela Gordillo. Uso de patrones de producto en
metodologas giles. Masters thesis, Universidad Carlos III de
Madrid. Departamento de Informtica, Espaa, 2010.
[12]
Pilar Rodrguez Gonzlez. Estudio de la aplicacin de
metodologas giles para la evolucin de productos software.
Masters thesis, Escuela Universitaria de Informtica, Universidad
Politcnica de Madrid, Espaa, 2008.
[13] J. Sutherland, R. Van Solingen, and E. Rustenberg. The Power
of Scrum. CreateSpace, 2011.
[14] Jeff Sutherland. Agile Can Scale: Inventing and Reinventing
SCRUM in Five Companies. Vol. 14, No. 12, December 2001.

Universidad Andrs Bello Direccin Postal 250000 E-mail:g.costa@uandresbello.edu romina.torres@unab.cl druete@unab.cl