1

Abstract - Las metodologas giles son sin duda uno de los

Eleccin de Metodologa gil

Pablo Cneo, Estudiante de Sistemas, Universidad de Palermo
temas nuevos en ingeniera de software que estn acaparando
gran inters, estn revolucionando la manera de producir
software.
El desarrollo de software no es una tarea fcil. Prueba de ello
es que existen numerosas propuestas metodolgicas que inciden
en los proceso de desarrollo. No existe una metodologa universal
por lo cual tengo que decidirme por alguna.
Resolver con que metodologa quedarme a la hora
desarrollo de un proyecto, basndome en el anlisis de
metodologas ms relevantes, el tipo de proyectos y
tecnologas al alcance influyen directamente en el xito
desarrollo del proyecto.

del
las
las
del

Es por eso que este estudio se basara en la eleccin de una

metodologa gil, dentro de un contexto dado bajo determinadas
caractersticas para seleccionar la metodologa que mejor se
adapte.
Palabras Clave: Agile Unified Process, Kanban, Metodologia Agil,
Scrum, Test Driven Development.

I. NOMENCLATURA
Test Driven Development (TDD), Agile Unified Process
(AUP)
II. LINTRODUCCIN
a realizacin del Paper consisti una primera etapa en
investigar las metodologas agiles que haba disponibles en el
mercado, recolectando informacin como caractersticas,
tipos, enfoques, antigedad, casos xito. Una vez tomada toda
esa informacin se analizo y se llego a un acuerdo en las
metodologas agiles a profundizar, quedndome con Scrum,
Test Driven Development, Agile Unified Process y Kanban.
III. CASO
El anlisis y eleccin de una de estas metodologas se basara
en proyectos de software desarrollos en el rea argentina, con
una importante inversin econmica, bajo requerimientos
cambiantes, sin una abundancia de recursos pero lo
suficientemente capaces e involucrados en el xito del
proyecto.
IV. MARCO TERICO
A. Las Metodologas giles valoran:

Al individuo y las interacciones en el equipo de desarrollo

ms que a las actividades y las herramientas.
Desarrollar software que funciona ms que conseguir una
buena documentacin, implica minimalismo respecto del
modelado y la documentacin del sistema.
La colaboracin con el cliente ms que la negociacin de un
contrato.
Responder a los cambios ms que seguir estrictamente una
planificacin.
B. Las Metodologas
A continuacin se indicaran
las metodologas giles a
desarrollar en este estudio en las empresas de desarrollo de
software de la Argentina.

Scrum

Test Driven Development

Agile Unified Process

Kanban

C. Scrum:
Scrum es un proceso en el que se aplican de manera regular un
conjunto de buenas prcticas para trabajar colaborativamente,
en equipo, y obtener el mejor resultado posible de un
proyecto. Estas prcticas se apoyan unas a otras y su seleccin
tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.
En Scrum se realizan entregas parciales y regulares del
producto final, priorizadas por el beneficio que aportan al
receptor del proyecto. Por ello, Scrum est especialmente
indicado para proyectos en entornos complejos, donde se
necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovacin, la
competitividad, la flexibilidad y la productividad son
fundamentales [2].
C.1. Sprint:
Un proyecto administrado mediante Scrum se organiza en
iteraciones, llamadas sprints, que normalmente tienen entre
dos y cuatro semanas de duracin. Al principio de cada sprint
se establece una lista de requerimientos llamada backlog, que
debe completarse cuando ste finalice. A diario se realizan
breves reuniones del equipo de desarrollo, en las que se
exponen los avances y los problemas encontrados, y se
sealan posibles caminos para resolverlos [3].
C.2. Backlog:
Un proceso Scrum reconoce tres tipos de backlog: el backlog
de producto, el backlog de versin y el backlog de sprint. El
backlog de producto es un repositorio de requerimientos
enunciados por los interesados en el xito del proyecto (los
llamados stakeholders, que pueden ser usuarios,
administradores, tcnicos de soporte, etc.). Por lo general, los
requerimientos incluidos en este backlog son de alto nivel,
evitan detallar cuestiones tcnicas o de implementacin, y
tienen asociadas estimaciones de tiempos tambin de alto
nivel, realizadas por los stakeholders.
El backlog de versin (release backlog) consiste en una lista
de requerimientos extrada del backlog de producto, priorizada
para la prxima versin (release) del producto. Los elementos
de este backlog tienen un mayor nivel de detalle en cuanto a
los requerimientos y tienen asociadas estimaciones ms
precisas, realizadas por los miembros del equipo de Scrum.
El backlog de sprint se arma al principio de cada sprint, y
rene aquellos requerimientos que el equipo se compromete a
completar para cuando finalice dicho sprint. Completar un
requerimiento implica codificarlo, testearlo y documentarlo.
El backlog de sprint se arma dividiendo los requerimientos del
backlog de release en tareas que comnmente pueden
completarse en perodos de 8 a 16 horas.

C.3. Equipo:
En Scrum, los equipos de desarrollo deben estar formados por
una cantidad aproximada de siete miembros. El lder del
equipo es el denominado Scrum Master, y su trabajo consiste
en implementar y administrar el proceso Scrum en el proyecto.
Al inicio del proyecto, el equipo debe ponerse de acuerdo en
cuanto a las prcticas que se van a implementar, la frecuencia
de las reuniones, los artefactos por utilizar, etc.
A partir de all, es responsabilidad del Scrum Master asegurar
que el equipo se atenga a las normas establecidas. El Scrum
Master asume el rol de facilitador, y su autoridad es, en su
mayor parte, indirecta. Su trabajo consiste en atajar las
interferencias externas para que el equipo de desarrollo
optimice su productividad, resolviendo los impedimentos que
no pueden ser resueltos por los miembros del equipo. Su
responsabilidad tambin incluye el hecho de asegurar la
transparencia del proceso de desarrollo, manteniendo los
artefactos definidos para el proceso (ver el recuadro Los roles
de un Scrum).
C.4. Reuniones:
Las reuniones de Scrum deben llevarse a cabo diariamente,
aunque el equipo puede ponerse de acuerdo al inicio para
realizarlas con una periodicidad diferente; por ejemplo, da por
medio. Es importante que se efecten siempre en el mismo
lugar y a la misma hora, y que su duracin no exceda los 30
minutos.
Durante la reunin, el Scrum Master hace a cada miembro del
equipo tres preguntas: qu hizo desde la ltima reunin de
Scrum, qu obstaculiz su trabajo y qu planea hacer desde
ese momento hasta la prxima reunin. La conversacin debe
limitarse a las respuestas de los miembros del equipo a las tres
preguntas anteriores. Sobre la base de las respuestas obtenidas
y de los problemas que stas reflejen, pueden agendarse
reuniones para llevar a cabo en forma inmediata luego de la
reunin de Scrum, entre un subgrupo del equipo, para dar
solucin a los inconvenientes detectados. El Scrum Master
seala los caminos de solucin a los problemas y es
responsable de identificar impedimentos externos que puedan
frenar el proceso.
C.5. Fases:
El proceso de desarrollo Scrum se compone de cinco
actividades principales: revisin de los planes de release;
distribucin, revisin y ajuste de los estndares de producto;
sprint; revisin de sprint, y cierre.
La fase de sprint es en la que se realiza el desarrollo de
software propiamente dicho. Dentro de un sprint se efectan
varias sub-actividades: desarrollo, empaquetado, revisin y
ajuste. No existe secuencia dentro de esta fase. Algunas veces,
un tem del backlog debe ser desarrollado, empaquetado y
revisado, y otras veces, el tem slo debe ser revisado y
ajustado; todo depende de las caractersticas del tem en
cuestin.
Cada sprint es seguido por un proceso de revisin. Durante
esta etapa, se revisa el software desarrollado en el sprint que
acaba de finalizar y, de ser necesario, se agregan nuevos tem
en el backlog. El grupo de revisores debe incluir a los
stakeholders, los administradores del proyecto, los
desarrolladores y los usuarios.

C.6. Las actividades de sprint y revisin de sprint tienen que

repetirse hasta que el producto est en condiciones de ser
distribuido por los accionistas. Luego, el proyecto entra en la
fase de cierre, tras la cual el producto queda en condiciones
para el cierre de versin (release) y distribucin. En la fase de
cierre, se realizan las ltimas tareas de depuracin
(debugging), luego de lo cual se construyen los entregables y
el proyecto se da por finalizado. Debido a lo imprevisible de
los procesos de desarrollo de software, no es posible definir
exactamente cundo ocurrir la fase de cierre, de modo que los
proyectos pueden demorarse ms o menos de lo planeado.
Pero mediante el uso de los controles que provee Scrum, se
pueden
hacer
estimaciones
sobre
su
duracin.
C.7. Ventajas [4]:
Entrega de un pro producto funcional al finalizar cada
Sprint.

Posibilidad ajustar la funcionalidad en base a la

necesidad de negocio del cliente.
Visualizacin del proyecto da a da
Alcance acotado y viable.
Equipos integrados y comprometidos con el proyecto,
toda vez que ellos definieron el alcance y su autoadministracin
C.8. Desventajas:
No genera toda la evidencia o documentacin de otras
metodologas
No es apto para todos los proyectos
Tal vez sea necesario complementarlo con otros procesos

D. Testing driven Development

El Desarrollo Dirigido por Tests (Test Driven Development),
al cual me referir como TDD, es una tcnica de diseo e
implementacin de software incluida dentro de la metodologa
XP [5].
TDD es una tcnica para disear software que se centra en tres
pilares fundamentales:
La implementacin de las funciones justas que el cliente
necesita y noms.
La minimizacin del nmero de defectos que llegan al
software en fase de produccin.
La produccin de software modular, altamente reutilizable
y preparado para el cambio.
Hasta ahora estbamos acostumbrados a que las tareas, o los
casos de uso, eran las unidades de trabajo ms pequeas sobre
las que ponerse a desarrollar cdigo. Con TDD intentamos
traducir el caso de uso o tarea en X ejemplos, hasta que el
numero de ejemplos sea suficiente como para describirla tarea
sin lugar a malinterpretaciones de ningn tipo.
En TDD dejamos que la propia implementacin de pequeos
ejemplos, en constantes iteraciones, haga emerger la
arquitectura que necesitamos usar

La esencia de TDD es sencilla pero ponerla en prctica

correctamente es cuestin de entrenamiento, como tantas otras
cosas. El algoritmo TDD solo tiene tres pasos:
D.1. Escribir la especificacin:
Una vez que tenemos claro cul es el requisito, lo expresamos
en forma de cdigo. Si estamos a nivel de aceptacin o de
historia, lo haremos con un framework tipo Fitnesse,
Concordion o Cucumber. Esto es, ATDD. Si no, lo haremos
con algn framework xUnit.
Los test de aceptacin o de cliente son el criterio escrito de
que el software cumple los requisitos de negocio que el cliente
demanda. Son ejemplos escritos por los dueos de producto
D.2. Implementar el cdigo:
En este paso, la mxima es no implementar nada ms que lo
estrictamente obligatorio para cumplir la especificacin actual.
Teniendo el ejemplo escrito, codificamos lo mnimo necesario
para que se cumpla, para que el test pase.
D.3. Refactorizacin:
Segn Martn Fowler, refactorizar es modificar el diseo sin
alterar su comportamiento. En este tercer paso del algoritmo
TDD, rastreamos el cdigo en busca de lneas duplicadas y las
eliminamos refactorizando. Adems, revisamos que el cdigo
cumpla con ciertos principios de diseo [6].
D.4. Como afrontar TDD:
El mtodo a seguir es sencillo. Consiste en elegir uno de los
requisitos a implementar, buscar un primer ejemplo sencillo
del requisito, crear una prueba unitaria, ejecutar la prueba,
implementar el cdigo mnimo para superar la prueba y
ejecutar de nuevo la prueba para ver que se supera.
Obviamente la gracia de ejecutar la prueba despus de crearla
es ver que esta falla y que ser necesario hacer algo en el
cdigo para que esta pase.
A continuacin solo es necesario volver a aplicar el proceso
descrito anteriormente hasta haber resuelto la funcionalidad o
funcionalidades que se deban implementar.
A dems una vez pasada la prueba es necesario revisar el
cdigo, por si requiere refactoring. Si es el caso, se revisara,
corregir y se ejecutaran las pruebas unitarias, de nuevo.
Es importante tener presente que solo se crea un test por
iteracin y solo se implementa el cdigo mnimo necesario
para resolver ese caso. No es bueno emocionarse
implementando y desarrollar ms de lo necesario para resolver
el caso de prueba. Si nos vamos por las ramas desarrollando
ms casos perderemos una gran parte de la eficacia de este
mtodo [7]

Fig. 1. Ciclo de desarrollo de TDD

Elegir un requisito a desarrollar (Fig. 1)

Crear la prueba o test
Ejecutar los test: falla (ROJO)
Crear cdigo especifico para resolver el test
Ejecutar de nuevo los test: pasa (VERDE)
Refactorizar el cdigo
Ejecutar los test: pasa (VERDE)
D.5. Ventajas [8]:
Entre las ventajas que se desprenden del uso de esta
prctica encontramos las siguientes:
Al escribir primero los casos de prueba, se definen de
manera formal los requisitos que se espera que cumpla la
aplicacin. Los casos de prueba sirven como
documentacin del sistema.
Al escribir una prueba unitaria, se piensa en la forma
correcta de utilizar un mdulo que an no existe.
Las pruebas permiten perder el miedo a realizar
modificaciones en el cdigo, ya que tras realizar
modificaciones se volvern a ejecutar los casos de
pruebas para comprobar si se ha cometido algn error.
D.6. Desventaja:
TDD es difcil de usar en situaciones donde hacen falta
todas las pruebas funcionales para determinar xito o
fracaso. Ejemplos de esto son interfaces de usuario,
programas que trabajan con bases de datos, y algunos que
dependen de configuraciones de red especficas.
El soporte de la gestin es esencial. Sin la creencia de
toda la organizacin de que TDD va a mejorar el
producto, la gestin sentir que se pierde tiempo
escribiendo pruebas.
Las pruebas se han visto histricamente como una
posicin ms baja que los desarrolladores o arquitectos.
E. Agile Unified Process
El proceso unificado (Unified Process o UP) es un marco de
desarrollo software iterativo e incremental. A menudo es
considerado como un proceso altamente ceremonioso porque
especifica muchas actividades y artefactos involucrados en el
desarrollo de un proyecto software.

Dado que es un marco de procesos, puede ser adaptado y la

ms conocida es RUP (Rational Unified Process) de IBM.
AUP se preocupa especialmente de la gestin de riesgos.
Propone que aquellos elementos con alto riesgo obtengan
prioridad en el proceso de desarrollo y sean abordados en
etapas tempranas del mismo. Para ello, se crean y mantienen
listas identificando los riesgos desde etapas inciales del
proyecto. Especialmente relevante en este sentido es el
desarrollo de prototipos ejecutables durante la base de
elaboracin del producto, donde se demuestre la validez de la
arquitectura para los requisitos clave del producto y que
determinan los riesgos tcnicos [9].
E.1. Principios:
La AUP es gil, porque est basada en los siguientes
principios:
1. El personal sabe lo que est haciendo. La gente no va a leer
detallado el proceso de documentacin, pero algunos quieren
una orientacin de alto nivel y / o formacin de vez en cuando.
La AUP producto proporciona enlaces a muchos de los
detalles, si usted est interesado, pero no obliga a aquellos que
no lo deseen.

calidad. Esto incluye la bsqueda de defectos, validar que el

sistema funciona tal como est establecido, y verificar que se
cumplan los requisitos.
4. Despliegue: Realizar un plan para la presentacin del
sistema y ejecutarlo para hacer que el sistema se encuentre a
disposicin de los usuarios finales.
5. Gestin de Configuracin: Realizar la gestin de acceso a
artefactos de su proyecto. Esto incluye no slo el seguimiento
de las versiones del artefacto en el tiempo, sino tambin el
control y la gestin de cambios para ellos.
6. Gestin del Proyecto: Dirigir las actividades que se lleva a
cabo en el proyecto. Esto incluye la gestin de los riesgos, la
direccin de personas (la asignacin de tareas, el seguimiento
de los progresos, etc.), y coordinar con las personas para
garantizar que se entrega a tiempo y dentro del presupuesto.
7. Ambiente: Apoyar el resto de los esfuerzos por garantizar
que el proceso adecuado, la orientacin (normas y directrices),
y herramientas (hardware, software, etc.) estn disponibles
para el equipo segn cuando ellos lo necesiten.

2. Simplicidad. Todo se describe concisamente utilizando un

puado de pginas, no miles de ellos.
3. Agilidad. El ajuste a los valores y principios de la Alianza
gil.
4. Centrarse en actividades de alto valor. La atencin se centra
en las actividades que se ve que son esenciales para el de
desarrollo, no todas las actividades que suceden forman parte
del proyecto.
5. Herramienta de la independencia. Usted puede usar
cualquier conjunto de herramientas que usted desea con el gil
UP. Lo aconsejable es utilizar las herramientas que son las ms
adecuadas para el trabajo, que a menudo son las herramientas
simples o incluso herramientas de cdigo abierto.
6. Adaptacin de este producto para satisfacer sus propias
necesidades. La AUP producto es de fcil acomodo comn a
travs de cualquier herramienta de edicin de HTML. No se
necesita comprar una herramienta especial, o tomar un curso,
para adaptar la AUP.
En comparacin de las disciplinas del RUP que son 9, el AUP
tiene solamente 7 las cules algunos son combinaciones de dos
disciplinas del RUP
1. Modelo: Entender el negocio de la organizacin, el
problema de dominio que se abordan en el proyecto, y
determinar una solucin viable para resolver el problema de
dominio.
2. Implementacin: Transformar el modelo(s) en cdigo
ejecutable y realizar un nivel bsico de pruebas individuales.
3. Prueba: Realizar una evaluacin objetiva para garantizar la

Fig. 2. Ciclo de vida del proceso unificado gil:

Al igual que en RUP, en AUP se establecen cuatro fases que

transcurren de manera consecutiva y que acaban con hitos
claros alcanzados (Fig. 2):
Incepcin (Concepcin): El objetivo de esta fase es obtener
una comprensin comn cliente equipo de desarrollo del
alcance del nuevo sistema y definir una o varias arquitecturas
candidatas para el mismo.
Elaboracin: El objetivo es que el equipo de desarrollo
profundice en la comprensin de los requisitos del sistema y
en validar la arquitectura.
Construccin: Durante la fase de construccin el sistema es
desarrollado y probado al completo en el ambiente de
desarrollo.
Transicin: el sistema se lleva a los entornos de
preproduccin donde se somete a pruebas de validacin y
aceptacin y finalmente se despliega en los sistemas de
produccin.

F. Kanban
E.2. Incremento y desarrollo de AUP:
Los equipos de AUP suelen ofrecer versiones de desarrollo al
final de cada iteracin en preproduccin rea (s). Una versin
de desarrollo de una aplicacin es algo que podran ser
liberados en la produccin si se ponen a travs de su preproduccin de garanta de calidad (QA), las pruebas y los
procesos de despliegue. La primera produccin de liberacin a
menudo toma ms tiempo para entregar versiones posteriores.
La primera produccin de liberacin puede tomar doce meses
para entregar la segunda versin de nueve meses, y luego otras
liberaciones se entregan cada seis meses. Una de las primeras
se centra en cuestiones de despliegue, no slo permite evitar
los problemas, sino que tambin permite tomar ventaja de sus
experiencias durante el desarrollo. Por ejemplo, cuando
despliegue un software en su rea deber tomar notas de lo
que funciona y lo que no, toma nota de que puede servir como
la columna vertebral de su instalacin de scripts [10].
E.3. Ventajas [11]:
El personal sabe lo que est haciendo: no obliga a conocer
detalles.
Simplicidad: apuntes concisos.
Agilidad: procesos simplificados del RUP
Centrarse en actividades de alto valor: esenciales para el
desarrollo.
Herramientas independientes: a disposicin del usuario.
Fcil adaptacin de este producto: de fcil acomodo
(HTML)
E.4. Desventajas:
El AUP es un producto muy pesado en relacin al RUP.
Como es un proceso simplificado, muchos desarrolladores
eligen trabajar con el RUP, por tener a disposicin mas
detalles en el proceso.

Kan-ban es una palabra japonesa que literalmente significa

letrero o tarjeta en espaol.
Es un sistema que controla el flujo de recursos en procesos de
produccin a travs de tarjetas. Est basada en la demanda y
consumo del cliente, y no en la planificacin de la demanda.
La funcin principal e inmediata de un Kanban es ser una
orden de trabajo, no slo es una gua para cada proceso, sino
una orden la cual debe cumplirse.
Kanban no es una tcnica especfica del desarrollo software,
es gestionar de manera general como se van completando
tareas, pero en los ltimos aos se ha utilizado en la gestin de
proyectos de desarrollo software, a menudo con Scrum (lo que
se conoce como Scrumban) [12].

F.1. Las principales reglas de Kanban son:

(1) Visualizar el trabajo y las fases del ciclo de produccin o
flujo de trabajo, (2) determinar el lmite de trabajo en curso
(o Work In Progress) y (3) medir el tiempo en completar una
tarea (lo que se conoce como lead time). Veamos que
significa
cada
uno
de
los
anteriores.
a) Visualizar el trabajo en Kanban y las fases del ciclo
de produccin, o flujo de trabajo.
Al igual que Scrum, Kanban se basan en el desarrollo
incremental, dividiendo el trabajo en partes. Una de las
principales aportaciones es que utiliza tcnicas visuales para
ver la situacin de cada tarea, y que quizs habrs visto
representado pizarras llenas de post-it.
El trabajo se divide en partes, normalmente cada una de esas
partes se escribe en un post-it y se pega en una pizarra. Los
post-it suelen tener informacin variada, si bien, aparte de la
descripcin, debieran tener la estimacin de la duracin de la
tarea.
La pizarra tiene tantas columnas como estados por los que
puede pasar la tarea (ejemplo, en espera de ser desarrollada, en
anlisis, en diseo, etc.). Abajo dejo una figura con un ejemplo
de tablero Kanban.
El objetivo de esta visualizacin es que quede claro el trabajo
a realizar, en qu est trabajando cada persona, que todo el
mundo tenga algo que hacer y el tener clara la prioridad de las
tareas.
Las fases del ciclo de produccin o flujo de trabajo se deben
decidir segn el caso, no hay nada acotado. En la figura se han
puesto un conjunto de fases de ejemplo.
b) Determinar el lmite de trabajo en curso.
Quizs una de las principales ideas del Kanban es que el
trabajo en curso (Work In Progress) debera estar limitado, es
decir, que el nmero de tareas que se pueden realizar en cada
fase debe ser algo conocido.

En Kanban se debe definir cuantas tareas como mximo puede

realizarse en cada fase del ciclo de trabajo (ejemplo, como
mximo 4 tareas en desarrollo, como mximo 1 en pruebas,
etc.), a ese nmero de tareas se le llama lmite del work in
progress. A esto se aade otra idea tan razonable como que
para empezar con una nueva tarea alguna otra tarea previa
debe haber finalizado.
En la anterior figura de ejemplo el nmero lmite del work in
progress se ha colocado entre parntesis debajo del nombre
de cada tarea. Podis, por ejemplo, ver que el lmite del work
in progress para las pruebas es 1.
c) Medir el tiempo en completar una tarea.
El tiempo que se tarda en terminar cada tarea se debe medir, a
ese tiempo se le llama lead time. El lead time cuenta
desde que se hace una peticin hasta que se hace la entrega.
Aunque la mtrica ms conocida del Kanban es el lead time,
normalmente se suele utilizar tambin otra mtrica importante:
el cycle time. El cycle time mide desde que el trabajo
sobre una tarea comienza hasta que termina. Si con el lead
time se mide lo que ven los clientes, lo que esperan, y con el
cycle time se mide ms el rendimiento del proceso.
F.2. Reglas de Kanban
Regla 1: No se debe mandar material defectuoso a los
procesos subsiguientes
El procesamiento de materiales defectuosos implica costos
tales como inversin en materiales, equipo y mano de obra que
no va a poder ser vendida. Este es el mayor desperdicio de
todos. Si se encuentra un defecto, se deben tomar medidas
antes que todo, para prevenir que este no vuelva a ocurrir.
Observaciones: El proceso que ha producido un producto
defectuoso, lo puede descubrir inmediatamente. El problema
descubierto se debe divulgar a todo el personal implicado, no
se debe permitir la recurrencia.
Regla 2: Los procesos subsiguientes requerirn slo lo que es
necesario
El proceso subsiguiente pedir solamente el material que
necesita al proceso anterior, en la cantidad necesaria y en el
momento adecuado. Se crea una prdida si el proceso anterior
abastece de partes y materiales al proceso subsiguiente en el
momento que ste no los necesita o en una cantidad mayor a la
que necesita. La prdida puede ser muy variada, incluyendo la
prdida por el exceso de tiempo extra, prdida en el exceso de
inventario, y prdida en la inversin de nuevos proyectos sin
saber que la existente cuenta con la capacidad suficiente. La
peor prdida ocurre cuando los procesos no pueden producir lo
que realmente es necesario, cuando stos estn produciendo lo
que
no
es
necesario.
Para eliminar este tipo de errores se usa esta segunda regla. No
se trata de abastecer a los procesos subsiguientes sino pedir,
los procesos subsiguientes, a los procesos anteriores la
cantidad necesaria en el momento adecuado. La decisin la
toma el proceso subsiguiente.
Regla 3: Procesar solamente la cantidad exacta requerida por
el proceso subsiguiente

El cumplimiento de esta regla implica alcanzar el objetivo de

reducir al mnimo los inventarios. No enviar contenedores de
materiales sin una tarjeta Kanban.
Regla 4: Balancear la produccin
Con el fin de producir solamente la cantidad necesaria
requerida por los procesos subsiguientes, se hace necesario
para todos estos procesos hacer un mantenimiento tanto de las
maquinarias como del personal. Por ejemplo, si el proceso
subsiguiente pide material de manera incontinua con respecto
al tiempo y a la cantidad, el proceso anterior requerir
personal y mquinas en exceso para satisfacer esa necesidad.
Por eso se hizo esta regla.
Regla 5 Tener en cuenta que Kanban es un medio para evitar
especulaciones
La nica informacin que deben tomar en cuenta los procesos
y la nica orden que deben cumplir para llevar a cabo su
trabajo es Kanban. No se debe especular sobre si el proceso
subsiguiente va a necesitar ms material, y tampoco el proceso
subsiguiente debe preguntarle o exigirle al proceso anterior si
podra empezar el siguiente lote un poco ms temprano.
Ninguno de los dos debe mandar informacin al otro,
solamente
la
que
est
contenida
en
Kanban.
Regla 6 Estabilizar y racionalizar el proceso
El trabajo defectuoso existe si el trabajo no se realiza en base a
un estndar y a un procedimiento racionalizado; si esto no es
tomado en cuenta seguirn existiendo partes defectuosas [13].
F.3. Ventajas [14]:
Identificacin del estado de proyecto y confeccin de
los informes de seguimiento: Los Jefes de Proyectos y sus
asistentes tendrn que dedicar mucho menos tiempo en
estas tareas ya que la mayora de la informacin est en el
tablero.
Coordinacin y colaboracin en los proyectos: vemos
estas tareas ms enfocadas y requiriendo menos tiempo
debido a la imagen completa del estado y las
dependencias en el proyecto visualizadas en el tablero.
Priorizacin de los requisitos de usuario: El principio
actual usado a menudo es "el que ms llora ms requisitos
implementados consigue". Nuestra intencin es de
vincular la priorizacin de los requisitos con la capacidad
del equipo disponible y los resultados actuales del
proyecto.

F.4. Desventajas:
Herramienta: El mantenimiento manual del tablero se ve
factible a largo plazo. Por lo tanto, tenemos que encontrar
una herramienta Kanban que puede ser fcilmente
integrada con el sistema de gestin de la empresa.
Planificacin inicial del proyecto: Kanban est abierto
acerca de la planificacin del proyecto. Sin embargo, al
Cliente se le tiene que dar una estimacin inicial del
esfuerzo y de la fecha fin del proyecto. Para ello vamos a
seguir con los mtodos tradicionales de estimacin hasta
que podamos incorporar mtricas de Kanban en ellas.

V. DESARROLLO
La eleccin de las metodologas de anlisis se debi al uso que
actualmente tienen en el mercado, a la cantidad de
informacin disponible de cada una y a la recomendacin del
tutor a cargo.
Luego de la eleccin de las metodologas, puntualic en las
caractersticas de los proyectos de software en los que iban a
estar aplicadas estas metodologas. Las caractersticas tenan
que ser propias de los proyectos de software, tendran que
tener una descripcin y un rango para evaluar su aplicacin.
Las caractersticas elegidas fueron recursos, requerimientos,
duracin, complejidad y tecnologa.
Cumplida la primera etapa de definiciones de metodologas y
caractersticas y habiendo utilizado esto dos conceptos para
armar un cuadro comparativo, me introduje en el grueso de la
investigacin, en la relacin de los proyectos con lo gil.
Profundizando en cada una de las metodologas para ir
cubriendo todos los aspectos de los proyectos de software.
La investigacin no fue nada sencilla debido a su reciente a
crecimiento y la escasa informacin de algunas metodologas
en trminos de xito.
Por ltimo, y una vez completado el cuadro comparativo,
aborde los tipos de herramientas que dan soporte a las
metodologas descriptas. Entre las existente opte por las ms
populares tanto para Test Driven Development como para
Scrum. Con ellas desarrolle la relacin de metodologa y
herramientas como un objetivo de simplificar todas las tareas
que forman parte de proceso de desarrollo de software.
Llegando al final de la investigacin y antes de darle un cierre
al paper con una conclusin, expuse algunos sitios donde se
podra seguir la investigacin con otras metodologas no
desarrolladas en este estudio pero que serian muy interesantes
tenerlas en cuenta para una investigacin ms amplia en otra
oportunidad.
A continuacin se llevara a cobo la realizacin de un cuadro
comparativo en el que relacionare las metodologas expuestas
anteriormente con las caractersticas ms relevantes de los
tipos de proyectos de desarrollo de software.
Luego profundizare en las tecnologas ms relevantes
utilizadas en el desarrollo del cuadro comparativo.
A. Cuadro comparativo:
Para la realizacin del cuadro comparativo entre las cuatro
metodologas elegidas, opte por diferentes caractersticas de
los proyectos de software, cada una de estas caractersticas
contienen una clasificacin especfica para poder ser aplicada
en el cuadro con mayor claridad.

A.1. Recursos:
El equipo de proyecto se compone de todos aquellos que
tienen un rol y responsabilidad para completar el proyecto. La
clasificacin por cantidad de personas en un proyecto se
realizara de hasta quince personas la clase ms baja, de quince
a cincuenta personas la clase media y ms de cincuenta la
clase alta.
A.2. Requerimientos:
El nmero detallado de servicios y restricciones del sistema en
base a la cantidad de Casos de uso. La importancia de los
casos de uso es significativa no solo porque proporcionan una
descripcin detallada de la funcionalidad de un sistema, sino
tambin para porque permiten expresar la arquitectura del
mismo. El rango ser pequeo de 0 a 30, mediano de 30 a 100
y mayor a 100 casos de usos grande.
Scrum

TDD

AUP

Kanban

Recursos

BAJA

BAJA

BAJA

BAJA
-MEDIA

Requerimientos

ADAPTABLE

GRANDE

ADAPTABLE

GRANDE

Duracin

LARGOS

LARGOS

LARGOS

ADAPTABLE

Complejidad

ADAPTABLE

ADAPTABLE
UTILIZA
Fitnesse
Concordion
Cucumber

ADAPTABLE

ADAPTABLE

NO UTILIZA

NO UTILIZA

Tecnologa

UTILIZA *
Scrumdesk
Scrumworks

A.3. Duracin:
La duracin del proyecto es el nmero de unidades de tiempo
necesarias para llevar a cabo el proyecto. Hasta 6 meses es
corto, de 6 a 18 mediano y mayor a 18 largos.
A.4. Complejidad:
El grado en el cual el diseo o implementacin de un sistema,
incluyen el nivel de integracin de la tecnologa, necesidades
de seguridad, estabilidad del hardware/software.
A.5. Tecnologa:
Programa de software, utilizado para desarrollar una actividad
para producir un producto o resultado.
El momento de elegir la metodologa a utilizar es uno de los
puntos ms crticos en todo proyecto y del que depender el
xito o no del mismo.
No existe un mtodo universal para desarrollar con xitos los
proyectos de software, toda metodologa tiene que ser
ajustada al contexto del proyecto. Si podemos hacer puntos en
comn como por ejemplo que la mayora de las metodologas
se adaptan a equipos pequeos, as como tambin que la
dificultad del proyectos no influye a la hora de la eleccin
[TABLA I].

En cuanto a la duracin, las metodologas agiles son aplicadas

con ms frecuencia en proyectos largos debido al nivel
econmico que est en juego en proyectos de gran
envergadura, de manera de asegurar el fin con xito del
proyecto y no naufragar en el intento. Del mismo modo sucede
en la cantidad de requerimientos que si bien se podran adaptar
a proyectos de baja cantidad de exigencias, las metodologas
se aplican cuando existe gran cantidad o en su defecto se
adaptan a ella.
Por ltimo, en lo que respecta a la tecnologa utilizada en las
metodologas, aqu se nota un uso diverso sobre este punto en
particular, estn las que tienen una independencia tecnolgica
como es el caso de Kanban o Agile Unified Process, estn las
que se tienen que apoyar en alguna tecnologa como es el caso
de Kanban, o simplemente las que tienen algunas herramientas
pero solo a modo de complemento de esta metodologa como
es el caso de Scrum.
El objetivo de esta comparacin de metodologas no es elegir
una tomndola como la mejor, la intencin es identificar las
diferencias de las cuatro metodologas elegidas, las
caractersticas de cada una y as establecer una mirada crtica
que nos ayude a la hora de la eleccin de una metodologa
para la realizacin de un proyecto de software.
TABLA I
CUADRO COMPARATIVO ENTRE METODOLOGAS AGILES Y CARACTERSTICAS
DE PROYECTOS DE SOFTWARE

10

B. Tecnologas Utilizadas:
En esta seccin hare un estudio a las soluciones ms populares
existentes en el mercado y que puedan ser interesantes en el
campo que estoy estudiando, estudio del desarrollo de
software sobre diferentes versiones de un mismo producto.
Nos centraremos en las herramientas ScrumDesk y
Scrumworks que dan soporte a metodologas de desarrollo
gil, a la metodologa Scrum y luego en las herramientas
FitNesse, Concordion y Cucumber de la metodologa Test
Driven Development.

Fitnesse est basado en Framework for Integrated Test

(FIT), el cual apoya la generacin de cdigo y la
automatizacin.
Sirve para cdigo Java, Python, C++, .NET y Smalltalk. Tiene
su propio control de versiones.
No requiere ninguna configuracin o instalacin.
Simplemente ejecuta y luego dirigir su navegador a la
mquina donde se est ejecutando.
Desde otra perspectiva, FitNesse es un framework de cdigo
abierto que hace que sea fcil para los equipos de software.

a) ScrumDesk:
Es una herramienta que nos ayuda en la administracin de
proyectos a travs de SCRUM, proporciona una visin
intuitiva en las tareas con vista de tarjetas y permitir la
colaboracin en la gestin de proyectos. ScrumDesk conecta
los equipos de proyecto, miembros del equipo con los clientes
y de gestin.
Esta herramienta es una Aplicacin .NET. Que se caracteriza
por ser muy visual y muy buena en la gestin de tareas como
tabln de "post-it".
ScrumDesk est disponible para iPhone, iPod e iPad.

d) Concordion:
Es un framework Java de Software Libre que admite convertir
especificaciones en texto comn sobre requerimientos en
pruebas automatizadas.
Esencialmente se escribe una especificacin en un HTML, con
comandos internos que delimitan la conducta de las pruebas.
Esta especificacin se realiza por medio de una clase Java
relacionada a cada especificacin y funciona como mediador
entre la especificacin y el sistema bajo prueba.
Concordion colorear con ayuda de la hoja de estilos,
subrayando en verde o en rojo segn funcione el software.
Un test de cliente o de aceptacin con estos frameworks, a
nivel de cdigo, es un enlace entre el ejemplo y el cdigo
fuente que lo implementa.
El propio framework se encarga de hacer la pregunta de si las
armaciones son ciertas o no. Por tanto, su aspecto dista
mucho de un test unitario o de integracin con un framework
xUnit.
En lneas generales podemos decir que es una extensin de
JUnit. Corre perfectamente en conjunto con IDEs.
Es amigable e intuitivo para desarrolladores.
Se encuentran versiones para Python.NET y Ruby.

b) Scrumworks:
Es una herramienta de automatizacin de procesos giles, una
aplicacin Web que permite compartir la informacin entre
todo el equipo.
Manejar dinmicamente el Backlog, definir las tareas y
arrastrarlas al Sprint, observar grficos por cada Sprint,
llamados burndown, que no slo permiten observar el estado
de avance del proyecto, sino tambin analizar sus
comportamientos e ir aprendiendo para mejorar los Sprints
que restan.
Es una aplicacin en java que no requiere instalacin.
Contiene una limitada versin web. Cubre todas las fases de
Scrum, incluyendo informes. Es una muy completa, sin
embargo
es
un
poco
rgida
en
su
manejo.
Pasando a Test Driven Development, cualquier lista de
herramientas que hagamos se desactualizar da a da. Sin
embargo, resulta ilustrativo ver algunas de las ms relevantes.
Hoy en da el desarrollo moderno se realiza a partir de pruebas
de aceptacin, es decir, se establecen una serie de pruebas con
la funcionalidad que debe cumplir la aplicacin y el cliente las
acepta, o de lo contrario lo haremos con algn framework
xUnit.
Existen varias herramientas open source en el mercado, tales
como
FitNesse,
Concordion,
Cucumber.
c) FitNesse:
Es una herramienta colaborativa para el desarrollo de
software. Permite a los clientes, testers, y programadores
aprender lo que su software debera hacer, y automticamente
compara lo que realmente hace. Compara las expectativas de
los clientes a los resultados reales.

e) Cucumber:
Es un framework de desarrollo de pruebas de aceptacin.
Utiliza Gherkin para hacer match entre los pasos escritos en
lenguaje natural y los pasos definidos por el usuario.
Permite a los equipos de desarrollo de software detallar de qu
manera debe funcionar el software que estn desarrollando en
un texto plano. El texto est escrito en un lenguaje especfico
de dominio (DSL) enfocado al negocio y sirve como
documentacin, pruebas automatizadas y de ayuda al
desarrollo.
Cucumber puede ser considerado como un instrumento ms de
testing, su amplitud llega al paradigma del Desarrollo Basado
en Comportamientos (BDD). Esto significa que los tests, el
texto plano descriptivo son escritos antes que puedan ser
verificados.
Cucumber est escrito en Ruby, pero puede ser utilizado para
testear cdigo en cualquier otro lenguaje

VI. CONCLUSIN

11

Las metodologas agiles hacen ms flexibles los procesos de

desarrollo, esto es muy provechoso en proyectos donde el
entorno es muy cambiante y se desconoce los requisitos con
precisin al iniciar el proyecto. Adems, permiten disminuir
costos y generar valor para el cliente en las fases ms
adelantadas que cualquier otra metodologa no gil.
Es muy recomendable que un equipo cuente con una
experiencia previa en el desarrollo de proyectos utilizando
metodologas agiles, ya que implica una responsabilidad muy
alta de todos los integrantes del equipo.

VII. LNEA FUTURA DE INVESTIGACIN

Las Metodologas:

Diversas metodologas se ajustan bajo la bandera de lo gil.

Mientras todas ellas comparten numerosas caractersticas,
tambin existen algunas diferencias significativas. No se
pueden distinguir todos los puntos en este paper, pero por lo
menos se puede asentar algunos sitios donde buscar.
-

Crystal Methodologies

En varias ocasiones se utilizan tcnicas de varias

metodologas, y se van adaptando segn el proyecto, inclusive
muchos de los que utilizan metodologa Scrum la combinan
con Kanban, llamndolo Scrumban.

Adaptive Software Development

Feature Driven Development

Lean Software Development

Se podra decir que se van adaptando a las necesidades del

cliente o al proyecto que se est llevando a cabo. Creo que se
lo debera tomar como un conjunto de herramientas
disponibles para su uso en determinadas situaciones en el cual
se justifique y no como mtodo aplicable en todas las
situaciones.

Extreme Programming

Dynamic Systems Development Method

Scrum

Test Driven Development

Agile Unified Process

Kanban

En este caso particular considero que la metodologa ms

adecuada para el escenario planteado es Scrum, ya que el
equipo cumple con el perfil apropiado considerando que se
pueden adecuar a esta forma de trabajo. Se puede apoyar en
herramientas para el seguimiento y administracin del
proyecto para marcarle un camino ordenado que lo conduzca
al xito. A medida que van obteniendo experiencia se lo podra
emplear con prcticas de otra metodologas agiles como por
ejemplo TDD para errores en el software.
Es por estos razonamientos que considero Scrum la
metodologa ms adecuada para el problema planteado.

VIII. REFERENCIAS
[1] Scrum, http://groups.yahoo.com/group/scrumdevelopment.
Metodologas de Desarrollo de Software giles
[2] http://www.proyectosagiles.org/que-es-scrum
[3]
http://www.mastersoft.com.ar/MsWeb/otros_archivos/NotaScrumPCU
sers.pdf
[4]
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:sg07.p02.
scrum.pdf
[5]http://www.dirigidoportests.com/wp-content/uploads/2009/12/disenoAgil
ConTDD.pdf
[6]http://osl2.uca.es/wikiCE/index.php/Test_Driven_Development
[7]
http://blog.lordudun.es/2011/04/introduccion-a-tdd-test-driven-develop
ment/
[8] Ingenieria del Software: Metodologias y ciclos de vida
[9] http://www.ingenieriadesoftware.mex.tl/63758_AUP.html
[10] Proyecto de consultoria externa, sistema de software de venta
[11] http://www.adolfo.mex.tl/images/18149/METODOLOG%C3%8DAS%
20%C3%81GILES%20(AUP).ppt.
[12] http://www.javiergarzas.com/2011/11/kanban.html
[13] http://es.scribd.com/doc/86666351/Kanban-y-ERP-II
[14] http://teodorabozheva.blogspot.com.ar/

12

IX. CURRICULUM VITAE

Pablo Luciano Cneo, nac en Buenos Aires, Argentina, el 22 de
noviembre de 1986.
En la actualidad estoy cursando la licenciatura
en sistemas en la Universidad de Palermo.
Mi experiencia laboral fue desempeada como

analista funcional en las empresas de telecomunicaciones Telecom

Argentina y luego en Telecom Personal.
Actualmente trabajo como Programador Java Jr en un proyecto de
Edenor customizando un producto de Oracle (CC&B).