Modelos de procesos giles

Los modelos de procesos giles como parte del proceso del software, son metodologas
basadas en el desarrollo iterativo e incremental de productos finales, adaptadas a los tiempos
actuales. Es decir, donde el producto final es una versin funcional (sin defectos) y el proceso para
que esto suceda est adaptado a los requisitos actuales del mercado: entregas tempranas y de
calidad, preocupacin por el qu y no por el cmo (importa ms el resultado que cmo se lleg a
l) y con directrices y ciclos que son auto adaptables, orientados a la toma de decisiones en corto
plazo.
La banda estadounidense Dave Matthews Band tiene una frase muy popular que indica
parte de la filosofa que en parcialmente dicta las caractersticas de los modelos de procesos giles.
Dice as: Llego hasta aqu, y slo el maana gua mi camino. Entonces, se podra hablar de la
primera y la segunda caracterstica, donde los equipos tienen mucha libertad debido a la
incertidumbre y dnde las fases del desarrollo se encuentran solapadas. Lo que esto quiere decir
es que, debido a las necesidades cambiantes del proyecto, las fases quedan a un lado y se ven
priorizadas las actividades y tareas para una necesidad en un momento dado.
Esto a su vez le da libertad estratgica al equipo de trabajo para abordar distintos
problemas, lo que al mismo tiempo da con la tercera caracterstica: no existen roles especializados.
Es decir, diversos integrantes realizan diversas tareas y tienen poder de decisin sobre las mismas
sin esperar que otro les diga qu hacer ni cmo hacerlo, discutiendo el camino a seguir, lo que
termina favoreciendo la transferencia de conocimiento en el equipo.
En este orden de ideas Pressman, R (2006), establece que un equipo con organizacin
propia controla el trabajo que desarrolla. El equipo establece sus propios compromisos y define
los planes para cumplirlos, destacando as la importancia de la colaboracin entre los
participantes del equipo.
De igual manera, sobre esto ltimo, se podra tomar una caracterstica interesante sobre el
equilibrio entre la libertad y la disciplina en estos modelos. Blanco-Cuaresma, S (2008), define
este rasgo como control sutil mientras que Pressman, R (2006) habla de este como organizacin
propia. Los autores aqu establecen que, en el contexto del desarrollo gil, los integrantes deben
de organizarse entre ellos y establecer puntos de control para poder realizar un debido seguimiento,
adaptndose a sus propios requisitos; todo esto sin limitar la libertad ni la creatividad del equipo.
Por consiguiente, se podra hablar de caractersticas asociadas al personal humano, donde
los integrantes adaptan el proceso a sus necesidades y no al revs. Para que esto suceda debe haber
claramente difusin del conocimiento, debido a que, si todos los individuos del grupo tienen xito
en sus respectivas tareas y actividades, lo ms probable es que el grupo logre que la entrega final
sea exitosa.

Para entender claramente la diferencia de concepto entre los modelos de desarrollo gil y
los modelos clsicos, se podra realizar una analoga con la planificacin de una fiesta familiar.
Donde la planificacin clsica correspondera a saber exactamente qu se va a comprar, dnde se
va a comprar, quienes van a asistir, y qu se har en la fiesta con sus lapsos de tiempo establecidos.
Mientras que, en una fiesta con plan gil, se sabe que se har una fiesta, que hay que
comprar cosas bsicas, pero cuando los invitados llegan es que se evalan los escenarios y se
decide qu actividades se harn en la fiesta.
En este mismo orden de ideas, se aprecia otra diferencia: en los modelos clsicos el lder
del proyecto puede no tener conocimiento tcnico sobre lo que se hace, mientras que esto no es
posible en los giles. En la analoga, una fiesta con plan gil debe ser planificada por personas
asiduas de las fiestas para poder decidir qu actividades corresponden a los escenarios.
Adems, en una fiesta siguiendo un plan clsico se piensa ms en los procesos, en lo que
se compra o en las actividades planteadas, mientras que siguiendo un plan gil se valora ms las
habilidades humanas pensando en la creatividad y autonoma de los participantes. Sin embargo,
ambos modelos planteados siguen el mismo marco de proceso, de tal manera que ambos modelos
se podran combinar para lograr un proceso eficaz y eficiente.
De hecho, se podra decir que los modelos giles estn basados en los modelos clsicos
evolutivos, ya que buscan resolver problemas parecidos, aunque de manera distinta. Adems,
existen varios modelos de procesos giles que a su vez podran relacionarse con otros modelos
clsicos debido a que se orientan a proyectos distintos, entre ellos tenemos:
Modelo Lean:
Este modelo proviene de un modelo de manufactura desarrollado por Toyota, tambin
conocido como el modelo justo a tiempo. De acuerdo con Kelly Waters (2010) ha sido
ampliamente aceptado por la comunidad de desarrollo gil y es una adaptacin de este proceso de
construccin de vehculos al proceso de desarrollo de software.
Este modelo tiene claves principales, la primera de ellas es eliminar la incertidumbre,
donde se sugiere validar el producto y los requisitos usando prototipos y gestionando la lista de
requisitos. Lo que esto quiere decir es que gestionar el riesgo en etapas tempranas del desarrollo
es fundamental para evitar errores al final. Esto segn el portal web de la revisa mprende.co (2014)
en este artculo se expresa que la siguiente clave es el aprendizaje validado.
En este sentido se habla de la comunicacin constante con el cliente en iteraciones cortas
para ir adecuando el producto a los cambios constantes, respetando un alcance definido desde el
principio para ponerle un lmite al proceso, dando lugar a una estructuracin del modelo de
Construir Medir Aprender. En esta estructura se deben establecer metas alcanzables y medir el
progreso en trminos de estas metas (en forma de entregable y/o tangibles). Adems, se debe hacer
una matriz de requerimientos para darle prioridad y hacerles seguimiento.
Finalmente se debe asegurar un producto mnimo viable para que ste sea validado por el
cliente, de esta manera el cliente podr ver lo que el producto es capaz de hacer. Sin embargo, este

mtodo debe estar bien claro y orientado a resultados de calidad. El trmino de metas alcanzables
es difcil de estimar con certeza, lo que puede al final generar inconvenientes (restringir la
capacidad al plan y/o no tener capacidad para alcanzar dicha meta). Para que el equipo no se vea
afectado es que se recomiendan las iteraciones ms cortas posibles.
Este modelo se podra comparar fcilmente con el modelo en espiral en algunos puntos.
Ambos repiten los procesos para eliminar la incertidumbre, modificando el plan y las acciones y
entregan lo ms pronto posible algo mnimo. Sin embargo, en la espiral el mnimo puede ser la
entrega de un plan, mientras que en Lean el mnimo debe ser un programa que muestre todas sus
capacidades para enamorar al cliente y ser validado.
Modelo Kanban:
El modelo Kanban, de acuerdo con los colaboradores de Wikipedia (2016) es un mtodo
para gestionar el trabajo intelectual, con nfasis en la entrega justo a tiempo Este mtodo al igual
que el anterior se remonta a un mtodo de gestin de procesos usado en las fbricas de Toyota.
Este Modelo busca centrar o enfocarse en el trabajo que se est realizando actualmente para no
sobrecargar al personal y a su vez optimizar los recursos.
Esa sera su primera caracterstica: flexibilidad planificada. Los trabajadores se enfocan en
un solo elemento de trabajo y cuando este es finalizado saca el siguiente del principio del backlog.
El propietario puede modificar este llamado backlog pero esta accin no afectara el trabajo del
equipo ya que estn focalizados en otro elemento. La planificacin entra en el nivel de poner los
elementos ms importantes al principio siempre, para que el proyecto pueda sacar provecho al
trabajo focalizado.
Adems, esto proporciona otra ventaja: menos cuellos de botella. La multitarea puede ser
buena, pero generalmente presenta conflictos. En el modelo Kanban adems de centrarse en el
trabajo en curso, limita la concurrencia del mismo. As se evita que los trabajadores pierdan el
foco ante continuos cambios, adems resalta los cuellos de botella que pudiesen aparecer. A simple
vista pudiese verse como algo poco eficiente, pero es al revs. La multitarea excesiva puede caer
en falta de calidad por la complejidad de unir elementos del trabajo que en un principio estn
separados.
Sin embargo, cuando se limita de esta manera, hace que los miembros del equipo tengan
ms cuidado con lo que hacen tanto en la codificacin como en la revisin, lo que podra evitar en
nuevas iteraciones cambios brucos y prdida de tiempo. Estas iteraciones de por s ya son reducidas
en tiempo, debido a que en Kanban se aplica el compartimiento de aptitudes. Es decir, cuando una
sola persona tiene muchos conocimientos que otros no, entonces sta es un obstculo para el flujo
de trabajo.
Lo que esto significa es que, para reducir los tiempos, todos los miembros deben de poder
realizar todos los trabajos, de esta manera, si uno de ellos falla, cualquiera puede complementar.
El flujo de trabajo es prioritario para Kanban, y el equipo de trabajo es el responsable de que este
no se vea afectado.

Otra caracterstica que se aprecia es el acompaamiento de todo este proceso con mtricas
visuales, las cuales son pblicas. Estas grficas, tal y como lo expresa el portal web Atlassian, son
de gran utilidad cuando el equipo puede ver los datos, es ms fcil detectar obstculos en el
proceso (y eliminarlos) En este portal se aprecia a su vez que existen dos tipos de grficas que
son las ms usadas al emplear este modelo, los grficos de control y el diagrama de flujo
acumulado.
ste mtodo se puede comparar con el clsico modelo concurrente, debido a que el
flujo de trabajo es constante y cada actividad tiene otra asociada. Sin embargo, Kanban maneja
este flujo de una manera interesante: los miembros pueden realizar distintas tareas asociadas,
evitando as los cuellos de botella que pudiesen formarse por modificaciones en el desarrollo
concurrente.
Programacin extrema.
La programacin extrema es definida como una metodologa del proceso de desarrollo de
software, la cual es pensada para aumentar la productividad de sus participantes y a la vez
adaptarlos al cambio constante de los clientes. La programacin extrema en s parte del marco
bsico de los modelos clsicos: planificacin, diseo, prueba y codificacin. Pero la forma en la
que lo hace se adapta a los nuevos tiempos y a diversos tipos de proyectos; todos ellos basados
preferiblemente en la programacin orientada a objetos.
La primera fase, explica Pressman S (2006) que es la planificacin, el autor indica que:
los usuarios describen las caractersticas y las funcionalidades requeridas para el software que se
contruir. Cada historia la escribe el cliente y se coloca en una carta ndice. El cliente le asigna un
valor Ac se aprecia lo parecido de la fase de recoleccin de requerimientos, pero en este caso
funciona basado en historias con valoraciones.
Entonces, el equipo de desarrollo agrupa y ordena las historias de manera que puedan ser
desarrolladas; trabajando primero con las de ms valor o las ms riesgosas, y las historias que se
seleccionen sern trabajadas en un lapso corto de tiempo. Todo esto con el fin de realizar una
versin con los requerimientos ms importantes de la aplicacin.
Por consiguiente, sigue el diseo como herramienta que transforma la historia en una gua
de implementacin, est implementacin se recomienda sea realizada por parejas, que trabajen en
una historia determinada. Pero antes se deben realizar pruebas unitarias para que el programador
se pueda centrar en lo que debe realizar para pasar las pruebas, sin adornos.
Finalmente se realizan las pruebas, que preferiblemente deben ser realizadas
automticamente, para que luego el cliente verifique si los elementos y funcionalidades
corresponden a lo esperado.
Jim Lynch, desarrollador para HBO comenta en el portal web Linkedin sobre las
caractersticas de los procesos de programacin extrema que son exitosos. Entre ellas se tienen las
reuniones cortas pero productivas, donde en vez de reunirse para planificar, las reuniones se hacen
para revisar el proceso.

Adems, se expresa sobre los feedbacks errneos. En este proceso, el programador debe
pensar como el usuario, cumpliendo con las historias del cliente, pero pensando realmente en los
que lo van a utilizar. Igualmente, este modelo permite que los incrementos sean entregados
rpidamente para obtener mejor feedback.
Por otro lado, la caracterstica principal e innovadora es el hecho de la programacin en
pareja, debido a que, al realizarse bien, ofrece resultados increbles. Es el tpico caso de sinergia
donde la pareja como tal es superior a ellas evaluadas por separado. Finalmente, la otra
caracterstica que termina siendo distintiva es la realizada por los programadores como si ellos
fuesen los clientes, probando las unidades en produccin y velando que cumplan con las historias.
Finalmente, se observa que este esta comparado con el modelo incremental, y podramos llamarlo
la versin gil del mismo, donde esta vez el xito depende del trabajo de la pareja y de la
organizacin de las historias ms que de los lineamientos del proceso en s.
Scrum o Mel.
Segn Pressman (2006) Es un modelo gil de proceso que desarrollaron Jeff Sutherland
y su equipo a principios de la dcada de 1990 El proceso consta de sprints, donde se producen
incrementos, con reuniones diarias. Este modelo es uno de los ms usados actualmente.
El autor tambin establece que el proceso debe adaptarse a los cambios tcnicos y que se
debe realizar la documentacin constante conforme se realicen las pruebas e incrementos. Una
caracterstica de Scrum es que busca minimizar el riesgo, con tareas cortas, evitando as cuellos de
botella y verificando en todo momento el estado del proceso. Otra, es que el cliente debe formar
parte de las reuniones, siendo un beneficio porque podra darse cuenta rpidamente de que sus
requisitos principales no fueron adecuados.
La caracterstica clave del Scrum es la velocidad, si todo es veloz y controlado se puede
verificar la calidad y adems que se cumplan los tiempos esperados. Si hay lentitud el modelo
Scrum fallar y los entregables finales careceran de muchas funcionalidades.
Este modelo podra ser comparado igualmente con el modelo clsico incremental, sin
embargo, se muestra que los incrementos son logrados de manera distinta. Adems, con tareas ms
cortas. En el modelo clsico no consta de reuniones diarias ni el cliente forma parte del proceso
hasta que el incremento es entregado para recibir feedback.

Elaborado por: Joan Gil, C.I: 25.933.185

Fuentes usadas:
Roger S, Pressman. Ingeniera del software, un enfoque prctico, 6ta edicin.
Wikipedia la enciclopedia libre.
Otros portales web como Linkedin, mprende.co, Atlassian.