Está en la página 1de 25

1

Explicando Scrum a mi abuela


Introduccin
El otro da me encontraba hablando con un compaero de trabajo a travs del telfono mvil, cuando mi abuela me escuch nombrar
palabras raras en la conversacin.
Una de esas palabras era Scrum, y por la forma en la que hablaba fue lo que ms atencin la llam, as que cuando colgu, lo primero
que me pregunt fue con quin hablaba, de qu hablaba, y que era eso de Scrum.
Imaginaros la cara que se me qued, porque... cmo explicar Scrum a mi abuela?.
Aunque mi abuela es muy avanzada para la mayora de la gente de su edad, la verdad es que no es fcil explicarla muchos de los
aspectos tecnolgicos emergentes, pero bueno, es mi abuela y tena que intentar explicrselo de forma convincente.
Aqu, os transcribo aquella inverosmil conversacin.
Este modelo fue definido por Ikujiro Nonaka e Hirotaka Takeuchi a principio de los 80s.
La conversacin y sus explicaciones
De que hablabas?, pareca interesante eso que decas de Scrum. Qu es exactamente?
Ah s! Scrum es una metodologa.
Y para que se utiliza?
Se utiliza en mi profesin, en el desarrollo del Software concretamente, aunque hay gente por ah que la usa o la quiere usar en otras
profesiones y reas.
Y para eso del desarrollo del Software tenis que usar ese tal Scrum?
En realidad no. No es estrictamente necesario. Scrum por sus caractersticas no es vlido para cualquier proyecto ni para cualquier
persona o equipo de personas. Es ms, Scrum segn muchos especialistas de esta metodologa, es ptima para equipos de trabajo de
hasta 8 personas, aunque hay empresas que han utilizado Scrum con xito con equipos ms grandes.
Yo dira que para el 90% de los proyectos y empresas, es una metodologa vlida, pero no es una metodologa vlida al 100%. Es ms,
no hay metodologa mejor que otra ni vlida al 100% para todas las personas y empresas.
Scrum es por lo tanto, una metodologa ms de las muchas que hay, y sta en concreto, se basa en la filosofa del desarrollo gil que fue
expuesto por dos japoneses alrededor del ao 1986.
Siempre estos japoneses... has dicho desarrollo gil varias veces... que es eso exactamente?, a m eso s que me suena a
japons o a chino
El desarrollo gil pone de manifiesto bsicamente lo siguiente:
El mercado actual es altamente competitivo y la tecnologa es muy cambiante. En el desarrollo del Software se pide bsicamente
rapidez, calidad y reduccin de costes, pero para asumir estos retos, es necesario tener agilidad y flexibilidad.
Los ciclos de desarrollo por otro lado, acostumbran a ser largos, y lo que se exige por otra parte, es que esos ciclos sean lo ms
cortos posibles.
El desarrollo gil aboga por estas premisas principalmente.
Hay ms detalles, pero no los voy a abordar ahora para no marearte con informacin que nos desve la atencin de la propia explicacin
de Scrum.
Informacin adicional
Empiezo a entender algo ms esto...pero... en qu consiste exactamente eso de Scrum?
Scrum es como deca antes, una metodologa gil.
Obedece a las necesidades anteriormente citadas, y no responde a ninguna moda, sino a una necesidad realmente demandada en el
desarrollo del Software.
Scrum no es ni la mejor metodologa ni la nica, antes te deca que hay muchas, pero s, es una metodologa que est empujando muy
2

fuerte por la facilidad de implantacin y por su agilidad en cuanto a cambios y lo que propiamente aporta en comparacin con otras
metodologas.
Por un lado, Scrum evita la burocracia y la generacin documental. No es que con Scrum no se deba o no se pueda documentar, si no
que con Scrum no se exige documentar nada para iniciar un proyecto, algo que en otras metodologas es impensable.
Con Scrum por otro lado, la idea principal es la de ponerse a trabajar prcticamente desde el primer momento y empezar a sacar frutos de
ese trabajo para que el cliente vaya viendo los avances y se quede satisfecho con lo que se est haciendo y cmo se est haciendo.
S s, vale... pero cmo muestras al cliente esos progresos en el trabajo?.
Bien bien, no te he contado an mucho sobre Scrum, slo el cascarn que lo envuelve, pero ya que preguntas y te veo realmente
interesada, te voy a contar todo lo que hay con ms detalle.
De forma resumida y global, en Scrum vamos a diferenciar dos aspectos importantes, los actores y las acciones.
Vaya, esto se pone interesante, sigue sigue que me est empezando a gustar esto del Scrum.
Ja!, pues espera a que te cuente, que esto no ha hecho nada ms que comenzar.
Te deca que hay dos aspectos fundamentales a diferenciar, los actores y las acciones.
Los actores son los que ejecutarn obviamente las acciones.
Estos de forma general, sern:
Product Owner
Scrum Master
Scrum Team
Usuarios o Clientes
Algo que no te he dicho an, es que para que un proyecto Software tenga xito, el Usuario o Cliente, debe involucrarse s o S.
Esto vale para todos TODOS los proyectos, aunque no todos los Usuarios y Clientes lo entienden as, pero nuestra misin es tambin
hacrselo ver.
Prosigo.
El Product Owner conoce y marca las prioridades del proyecto o producto.
El Scrum Master es la persona que asegura el seguimiento de la metodologa guiando las reuniones y ayudando al equipo ante
cualquier problema que pueda aparecer. Su responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas.
El Scrum Team son las personas responsables de implementar la funcionalidad o funcionalidades elegidas por el Product
Owner.
Los Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes viendo los progresos, pueden aportar ideas,
sugerencias o necesidades.
Y lo de las acciones?
Te veo con hambre de conocimiento, eso est bien.
Las acciones tienen relacin directa con los actores. Sin ellas, todo sera un caos.
En Scrum se indican claramente las acciones a acometer y como acometerlas. Nuestra responsabilidad es hacerlo siempre de una forma
adecuada y algo rgida para impedir que se aplique errneamente esta metodologa.
Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que el mecanismo y forma de trabajar que a continuacin se
indica, tiene como objetivo minimizar el esfuerzo y maximizar el rendimiento en el desarrollo.
Las acciones fundamentales de Scrum son:
Product Backlog
Sprint Backlog
Daily Scrum Meeting
El Product Backlog corresponde con todas las tareas, funcionalidades o requerimientos a realizar. Antes deca que el Product Owner es
la persona que se encarga de marcar las prioridades, y es al fin y al cabo, la persona que mantiene y actualiza dado el caso, la lista de
tareas.
El Sprint Backlog corresponde con una o ms tareas que provienen del Product Backlog. Es decir, del Product Backlog se saca una o
ms tareas que van a formar parte del Sprint Backlog. Las tareas del Sprint Backlog se deben acometer (recomendado) en unas 2
semanas 4 semanas. Hay Sprint Backlogs de 2 semanas y hay Sprint Backlogs de 4 semanas. Eso debe de ser marcado antes de
iniciar el Sprint Backlog, de hecho, del Product Backlog se sacar la tarea o tareas realistas para acometer el Sprint Backlog. Una norma
3

fundamental es que mientras un Sprint Backlog se inicia, ste NO puede ser alterado o modificado. Hay que esperar a que concluya el
Sprint Backlog para realizar la correspondiente modificacin o alteracin cuya tarea, formara parte de otro Sprint Backlog.

El Daily Scrum Meeting es una tarea iterativa que se realiza todos los das que dure el Sprint Backlog con el equipo de desarrollo o de
trabajo. Se trata de una reunin operativa, informal y gil, de un mximo de 30 minutos, en la que se le hace 3 preguntas a cada
integrante del equipo.
Qu tareas ha realizado desde la ltima reunin (que he hecho).
Sobre qu va a trabajar en el da actual (que voy a hacer hoy).
Identificacin de obstculos o riesgos que impiden o pueden impedir el normal avance (que ayuda necesito). El Scrum Master,
debe eliminar aqu cualquier obstculo que encuentre.
Una pregunta ms... has dicho que del Product Backlog se sacan tareas que van al Sprint Backlog, pero entiendo que no todas
las tareas del Product Backlog van a la vez al Sprint Backlog, as que... que se hace cuando una tarea del Sprint Backlog se
finaliza?
Bien, esta es una pregunta tpica.
Quizs no me he explicado bien, pero el Sprint Backlog, una vez que se inicia, ni se toca.
Es decir, que una tarea se acaba, y punto.
Se contina con otra tarea del Sprint Backlog y as hasta que se acaben.
Lo que debemos tener claro, es que al finalizar un Sprint Backlog (ya sea de 2 semanas de 4 semanas), debemos haber acabado las
tareas del Sprint Backlog.
Reitero que las tareas del Sprint Backlog deben de ser realistas.
As que cuando se ha finalizado un Sprint Backlog, deberamos tener algo, un entregable o algo que se pueda mostrar y que ensee los
avances acometidos en el Sprint.
En el Product Backlog tendremos ms tareas, y es posible incluso que hayan salido nuevas tareas o que otras hayan desaparecido, por lo
que es cuando se acaba el Sprint Backlog, cuando debemos hacer varias cosas importantes y que te indico a continuacin.
Esto me est gustando muchsimo...
Me alegro, a m me parece interesantsimo, y es ms, Scrum es de sentido comn, tanto, que yo sin saberlo ya lo utilizaba hace algunos
aos sin saber que era realmente Scrum.
Bueno, prosigo con esta explicacin.
Como te deca, adicionalmente a las acciones anteriormente comentadas encontramos otras acciones ms.
Antes para no saturarte, no te dije que entre el Product Backlog y el Sprint Backlog, hay algo, una reunin concretamente, que se
denomina Sprint Planning Meeting.
El Sprint Planning Meeting es una reunin que tiene por objetivo, planificar el Sprint a partir del Product Backlog. El objetivo de
esta reunin es la de mover las tareas del Product Backlog al Sprint Backlog. En esta reunin, suelen participar el Product Owner
que es como te dije antes quien prioriza las tareas, el Scrum Master y el Scrum Team.
Del Sprint Planning Meeting, sale tambin el Sprint Goal, que es un pequeo documento o una breve descripcin que indica lo
que el Sprint intetar alcanzar.
En el Sprint Review se revisa en unas 2 horas como mximo el Sprint finalizado. Al llegar a este punto, debemos tener "algo"
que el Cliente o el Usuario pueda ver y tocar. En esta reunin, suelen asistir el Product Owner, el Scrum Master, el Scrum Team
y personas que podran estar involucradas en el proyecto. El Scrum Team es quin muestra los avances realizados en el Sprint.
Al finalizar un Sprint Backlog y el Sprint Review, se inicia el Sprint Retrospective. El Product Owner revisar con el equipo los
objetivos marcados inicialmente en el Sprint Backlog concluido, se aplicarn los cambios y ajustes si son necesarios, y se
marcarn los aspectos positivos (para repetirlos) y los aspectos negativos (para evitar que se repitan) del Sprint.
Mira, te pintar un diagrama que espero te ayude a entender todas las acciones de Scrum.








4


Y porque es eso de las 2 4 semanas?. No sera ms fcil que cada equipo pusiera su franja de tiempo?
S claro, cada equipo, cada empresa, cada proyecto, puede poner la franja horaria y frecuencia temporal que considere oportuno as como
cambiar aspectos de Scrum, pero te voy a poner un sencillo ejemplo con el cul entenders que es mejor hacer esto as que de otra
forma.
Supongamos el caso de la construccin de un rascacielos o de un edificio.
Si con el fin de controlar el proyecto y que no se te escape nada ni metamos la pata en algo, me preguntas cada da en varias ocasiones
como estoy haciendo las cosas, como lo llevo y cuales son mis avances, te aseguro que no terminaremos la construccin del edificio en el
tiempo planificado ni de broma. Adems, seguro que querrs cambiar o modificar algo cada da o incluso varias veces en el mismo da.
Si me preguntas cada 6 meses por ejemplo, avanzar mucho sin interrupciones, pero a buen seguro que el riesgo de desviaciones es
mucho mayor y seguramente si ocurren, reajustar esas desviaciones al proyecto tendr costes elevados asociados.
Un trmino medio es el ajuste temporal de 2 4 semanas que est basado en la experiencia de muchas personas en muchos proyectos.
No es lo mismo reconducir el proyecto perdiendo 2 4 semanas, que reconducirlo perdiendo 6 meses por ejemplo.
La idea de la metodologa gil es fundamentalmente que adopte los cambios, que se pueda reconducir el proyecto en un momento dado,
y que afecte lo menos posible a los costes, los tiempos y al equipo de trabajo.
No es la metodologa ideal. Yo siempre digo que si hubiera algo ideal, todo el mundo lo usara, pero s te digo, que Scrum se acerca
bastante a esa idea general de la gestin ideal de proyectos.
A m personalmente es la que ms me gusta y la que por experiencia, mayor satisfaccin suele dar, tanto al cliente o al usuario final como
al equipo de trabajo.
Y no te creas que hay mucho ms que saber de Scrum, esta es la filosofa o idea general que espero te haya quedado clara y te haya
servido para entender lo que hablaba con mi compaero de trabajo.

El jardn (un ejemplo de Scrum fabulado)
Por: Xavier Albaladejo
La nueva propietaria de la casa de campo se dio un paseo por los jardines. Algunas partes estaban en muy mal estado. Llam a
su capataz y le dijo lo preocupada que estaba: se haba comprometido con su circulo de negocios a dar una recepcin en un mes, y tena
serias dudas de si eso sera posible.
Esa misma maana, el capataz hizo unas cuantas llamadas a otros colegas suyos. Le confirmaron que, aunque contratase a la
mejor empresa de jardinera de la provincia, tenerlo todo listo le llevara como mnimo dos meses. Tan slo la elaboracin del plano del
nuevo jardn, con el detalle de las diferentes zonas, tipos de plantas y ornamentos, le llevara casi tres semanas, contando con que la
propietaria pudiese dedicar suficiente tiempo a la revisin y aprobacin del estudio.
El capataz se diriga al despacho de la propietaria cuando el telfono son. Uno de sus colegas haba recordado que un amigo
suyo haba pasado por un problema similar y que se lo haba resuelto una nueva empresa de jardinera que trabajaba de una manera
bastante diferente a las dems. El capataz se hizo con el telfono y los llam.
El planteamiento que esa empresa le ofreca era el siguiente: vendra un equipo de 7 personas, cada una especializada en reas
concretas de creacin de jardines. Se entrevistaran con la propietaria durante una maana entera para entender qu era lo que
necesitaba y conocer mejor cmo era el jardn. Como resultado, redactaran una lista con las cosas que la seora necesitaba. En este
punto, sera muy importante lo siguiente:
Explicaran a la propietaria cuantos das de trabajo seran necesarios para hacer cada elemento del jardn. Con esta
informacin, y conociendo el servicio que cada uno de estos elementos ofrecera, la seora debera elegir en qu orden se
debera arreglar el jardn, concentrndose sobre todo en tener el mximo de cosas importantes en la fecha de la recepcin.
5

Cada 15 das el equipo enseara a la propietaria los elementos del jardn que habra podido completar. Viendo el progreso real
del trabajo, la seora no se llevara a engaos. Adems podra realizar ajustes de lo que le enseasen (de hecho, ella todava no
se vea capaz de imaginar cmo quedara todo el jardn) y, lo que era mejor, podra cambiar sus ideas sobre las siguientes
zonas, tipos de plantas y ornamentos, dado que todava no se habra empezado a trabajar en ellos. nicamente necesitaran una
maana para ensearle el estado del jardn y entender (tanto ella como el equipo) cules deberan ser los objetivos de la
siguiente quincena. Durante este tiempo tambin sera necesario poder contactar con ella para preguntas puntuales.
Por otro lado, el equipo no conoca bien los problemas con que podra encontrarse en una vez en el jardn: canalizaciones de
agua en peor estado del que esperaban, aptitud de las tierras y orientacin respecto a los nuevos tipos de plantas deseados,
bsqueda de herramientas especficas en las que todava no podan pensar, etc. Por esto, al principio de cada quincena sera el
propio equipo quien decidira cuntas cosas se vera capaz de completar. Durante este tiempo, y para poder respetar el
compromiso adquirido, sera muy importante que la propietaria no realizase cambios sobre lo que se acord hacer. Es decir,
antes de cada quincena la seora debera tener claro qu sera lo ms importante para ella. El propio equipo la ayudara, si fuese
necesario.
El capataz pens que estas reglas eran bastante razonables y que, con esa manera de trabajar, su jefa podra tener el mejor jardn
posible para la recepcin que tena que dar en un mes, con lo que contrat a la empresa.
El equipo se reuni con la seora durante toda una maana. A partir de las necesidades de la propietaria se elabor una lista de
50 puntos con los elementos de jardn y tareas que las cubran. Para estimar rpidamente cuantos das de trabajo seran necesarios para
completar cada punto, su jefe los iba leyendo en voz alta y ellos indicaban con las manos el nmero de das de trabajo. Si haba una
diferencia importante entre lo que decan dos personas, cada uno de ellos explicaba en qu se haba basado su estimacin. Finalmente,
se vio que para arreglar todo el jardn seran necesarios dos meses y medio aproximadamente.
La seora escogi qu puntos necesitaba que estuviesen listos en la fecha de la recepcin, es decir, en un mes. Deban incluir
arreglar las partes ms importantes de los jardines de la entrada principal, el acceso hasta la casa y la parte de detrs de la casa. En los
laterales apenas se hara nada: all donde tuviese que pasar un nmero alto de invitados se hara un arreglo rpido para dar un aspecto
ms regular, siempre que ese arreglo fuese el mximo de compatible con el trabajo a realizar en esa zona en la siguiente quincena .
El equipo pregunt y acord con la seora los detalles necesarios para empezar el trabajo de los primeros quince das (los
jardines de la entrada principal y la parte de detrs de la casa, donde se hara el convite, cosas que representaban los primeros 10 puntos
de la lista). El equipo despus realiz un plan de trabajo: detall la lista de tareas necesarias para poder completar cada uno de los
elementos que haban escogido con la propietaria, se repartieron las tareas y se pusieron a trabajar.
Cada da por la maana, nada ms llegar, el equipo se juntaba 10 minutos. De pie, se explicaban en qu cosas haban estado
trabajando el da anterior, en qu iban a trabajar ese da y qu problemas tenan. Tras esa mini reunin, algunos seguan pensando sobre
cmo resolver alguna situacin concreta, mientras que su jefe llamaba por telfono a su empresa, proveedores de maquinaria o
herramientas, o iba directamente a hablar con el capataz para conseguir algo que su equipo necesitaba.
El equipo decidi rehacer las canalizaciones de slo esas primeras zonas y de la bomba de riego que conectaba directamente
con ellas. No rehizo las canalizaciones circundantes, sino que hizo lo mnimo necesario para que siguiesen funcionando y que no fuese
difcil poner las nuevas cuando la seora decidiese la quincena en qu trabajar en esas zonas no prioritarias.
Tras los primeros 15 das, recorrieron el jardn con la seora ensendole lo que haban completado. Slo haba quedado por
terminar 1 punto de los 10 primeros acordados. La seora pens que en la siguiente quincena (en la que el jardn debera estar listo para
la recepcin) era ms importante no hacer el punto pendiente y escoger bien los siguientes. El equipo consensu con ella hacer slo 9
puntos de la lista y as asegurar ms la calidad de cara a la recepcin. Despus de hablar con la propietaria, los miembros del equipo
dedicaron un par de horas a analizar cmo haban estado trabajando esa quincena, qu problemas eran los ms importantes que se
estaban encontrando de manera repetitiva (y que habra que resolver en la siguiente quincena) y qu nuevas tcnicas o alternativas
queran probar.
6

En el da previo a la recepcin apenas hubo que hacer unos retoques finales del trabajo realizado en la segunda quincena.
La recepcin fue todo un xito. Los invitados felicitaron repetidas veces a la propietaria por los hermosos y acogedores jardines
de su casa, cosa que la hizo sentir especialmente bien.
Cada quincena el equipo repiti el mismo proceso: daban una vuelta por el jardn con la seora, le enseaban cmo haban
resuelto cada punto de la lista, consensuaban cuales seran las cosas ms importantes a hacer en la siguiente quincena y preguntaban el
detalle necesario. Cada vez el equipo conoca mejor el jardn, con lo que su velocidad de trabajo (y el nmero de elementos que
completaba) era mayor.
Lleg la ltima quincena de trabajo. Los puntos que quedaban en la lista apenas tenan importancia. La propietaria pens que no
vala la pena perder tiempo y dinero en detalles que apenas nadie tendra en cuenta. Por el contrario, le convena ms hacer un gran
cambio en una zona del jardn en la que ya se haba trabajado: necesitaba darle un aspecto un poco ms oriental, ya que tras la recepcin
haba empezado a hacer negocios con personas de China y Corea, y sera muy distendido tener conversaciones con ellas en aquel la
parte del jardn.
La propietaria haba entendido que la flexibilidad para hacer cambios y el hecho de tener un jardn siempre preparado para
nuevas recepciones era lo que ms se adaptaba a sus necesidades, con lo que convoc al equipo para contratar y planificar los siguientes
meses de trabajo.
El proyecto
El pasado mes de mayo comenzamos el desarrollo de un nuevo proyecto que ha terminado recientemente, al menos la primera
fase del mismo. Partimos casi de cero, los requisitos eran muy bsicos y poco documentados, pero parte del equipo tenamos en la
cabeza exactamente lo que tenamos que hacer. De hecho era plasmar en una nica aplicacin todo nuestro trabajo de los ltimos cuatro
aos.
En el proyecto participaron dos equipos de desarrollo en localizaciones diferentes: uno en Valencia, de 6 personas, y otro en
Madrid, en el que llegaron a trabajar ms de 30. Ninguna de estas casi 40 personas tena disponibilidad completa para este proyecto sino
que hubo que redistribuir toda la carga de trabajo para, con el mismo equipo, asumir un nuevo proyecto de cinco meses de duracin. Sali
bastante bien.
En la parte tecnolgica tenamos otro grave problema: desde Madrid desarrollaban en .NET y desde Valencia en PHP.
Scrum
Desde el principio nadie tuvo dudas: Scrum era la mejor metodologa posible para cumplir los plazos que nos haban impuesto.
Planteamos sprints de dos semanas y reuniones diarias de sincronizacin ("dailys") a las 10 de la maana de alrededor de 10
minutos. Como Scrum Master se qued uno de nuestros project managers y como product owner otro del departamento de operaciones.
La mayora nos habamos ledo ya el Scrum desde las trincheras, pero una cosa es la teora y otra muy diferente la prctica, y ah casi
nadie tenamos experiencia.
No tratar en este artculo de ensearos Scrum, no soy un experto, como mucho un poco evangelizador , simplemente tratar
de explicar mis sensaciones tras cinco meses de Scrum intensivo.
El Equipo
Los dailys se hacan va conferencia entre una sala de reuniones en Madrid y otra en Valencia.
7

Se hicieron, adems, infinidad de reuniones a dos bandas entre los dos equipos para decidir funcionalidades, discutir los puntos
donde no haba acuerdo y resolver dudas. No slo participaban desarrolladores sino tambin jefes de equipo, project managers,
diseadores, expertos en usabilidad, gente de testing y calidad, documentalistas, gente de sistemas, de datawarehouse
La tecnologa
Como he comentado, en la parte tecnolgica tenamos otro grave problema: desde Madrid desarrollaban en .NET y desde
Valencia en PHP. Cual es el problema? . Se dise la arquitectura de manera que la aplicacin trabajase indistintamente en uno u otro
lenguaje.
Dentro de un mismo entorno web, unos mdulos se cargan de un lado y los otros del otro de forma completamente transparente
al usuario. Se dise un sistema de single sign on que pudiesen compartir y consultar ambas tecnologas y, asociado a ste, todo un
mecanismo de seguridad de acceso a distintos mens y opciones de la aplicacin.
El resultado fue formidable, todo funciona perfectamente de una manera integrada, robusta, eficiente y segura.

La Pila de Producto (product backlog)
Con la poca documentacin que se tena al principio se elabor una pequea pila de producto que fue creciendo a medida que
las tareas de anlisis evolucionaban. A esto debemos sumar requisitos que iban llegando por parte de los departamentos comerciales y
de operaciones. Al final el product backlog era considerable. En agosto hubo que decidir quitar algunas historias de usuario ya que era
imposible acometer todo lo que se quera, de hecho los requisitos a estas alturas eran infinitamente superiores a los que se haban
supuesto en mayo. An as, eliminando cosas, se hizo un producto mucho ms ambicioso de lo esperado. Las historias de usuario
eliminadas no se olvidaron, simplemente se trasladaron a una segunda versin.
Para el seguimiento del proyecto, en vez del clsico tablero de tareas, y dada la dispersin de los equipos, decidimos utilizar una
herramienta software. Comenzamos con un sencillo Excel y a mitad del proyecto incorporamos ScrumWorks. No creo que sea el
programa ideal pero cumple su funcin.

Los Sprints
Los tres primeros sprints fueron prcticamente de anlisis. Se hicieron documentos funcionales y orgnicos de todos los mdulos
requeridos y se perdi bastante tiempo definiendo la arquitectura de la aplicacin, en realidad de las dos aplicaciones (.NET y PHP). Todo
esto nos llev a plantarnos a mediados de junio, tras 3 sprints, con muy poco que mostrar en las demos, y nos condujo a la consabida
reprimenda de los que mandan, puesto que nos estbamos desviando (tericamente) de la planificacin estipulada. Sin embargo el
tiempo nos dara la razn: el tiempo perdido en el diseo de la arquitectura se recuper con creces en sprints siguientes y l legamos a la
fecha con el proyecto terminado. Bueno, en realidad dejamos para el final un pequeo detalle, el rendimiento, que se solucion en un
sprint adicional.
A todo esto hemos de aadir, como ya he dicho, que el equipo no estaba dedicado al proyecto, cada da variaba la gente que
entraba al daily ya que no todos estaban trabajando en el proyecto en ese momento. A eso hay que sumarle lo que llamo contingencias
del trabajo diario, es decir, nuevos proyectos que van surgiendo durante todo ese tiempo y que implican dedicarle tiempo que tienes que
quitarle a lo verdaderamente importante. Por si eso no fuera poco, a finales de junio se nos informa que una parte de la aplicacin, un
mdulo de reporting, tiene que estar operativa a finales de julio puesto que se necesita para dar servicio en otros proyectos. Esto, que de
palabra suena sencillo, nos oblig a modificar la planificacin, la pila de producto y la pila de sprint ya que el funcionamiento de este
mdulo implicaba a otros (login, seguridad, diseo). Y an as cumplimos todos los plazos, increble. Eso s, otros proyectos tuvo que
decidirse entre descartarlos o aprobar una desviacin de una o dos semanas en el proyecto del que hablamos, con lo que de igual manera
fueron descartados.
8

Las Estimaciones
Uno de los mayores problemas es, sin duda, estimar las horas de las tareas. Comenzamos quedndonos cortsimos y
terminamos quedndonos cortos tambin. Creo que rara vez se hizo una estimacin cercana a la realidad. Sin duda, es muy complicado.
Las tareas de anlisis se sobrestimaron en su mayora y las de desarrollo (la mayora) se quedaron cortas. Para planificar los
primeros sprints utilizamos Planning Poker, pero acabamos hacindolo directamente de viva voz ya que decidimos que no aportaba nada.
En los primeros sprints hubo que arrastrar bastantes tareas de uno a otro porque se haban estimado muy a la baja. Sin embargo, hacia el
final se recuper el tiempo perdido y las estimaciones no eran tan malas.
Las Demostraciones
Las demostraciones al cliente (interno en nuestro caso) eran el peor momento del sprint. No pocos das nos toc quedarnos
hasta altas horas de la noche para llegar a la demo del da siguiente con el trabajo terminado o, al menos, visible. Si esto lo hacamos
cada dos semanas, imaginaos que hubiese pasado si utilizsemos metodologas tradicionales: hubisemos llegado al final del tiempo de
desarrollo sin hacer ninguna demo, sin haber probado las cosas de una manera real. Habra sido imposible. De hecho, es lo que ocurre
habitualmente.
En nuestro caso nos sirvieron no slo para ver la reaccin del cliente ante el avance del producto sino tambin para ver las
fortalezas y debilidades del trabajo que estbamos desarrollando y reorientar los siguientes sprints.
Las demos estn para que el cliente vea el avance del producto que se le est desarrollando. El cliente en nuestro caso era una
persona en representacin de uno o varios departamentos internos de la organizacin. Qu utilidad tienen las demos si slo asiste el
product owner? Digo esto porque de vez en cuando apareca por all algn despistado que se dedicaba a criticar el producto, en concreto
partes del mismo que llevaban dos o tres meses terminadas y validadas por el product owner. Por qu esa actitud revienta-demos? O
mejor an, por qu no le prestas el debido inters a un producto en el que se basar todo tu trabajo los prximos aos? Ah, ya, es ms
fcil dejar la responsabilidad al product owner y despus quejarse. Sin la implicacin de toda la organizacin da igual qu metodologa se
utilice, ninguna conseguir triunfar. Estamos hablando de media hora cada quince das, slo eso.
Otro punto importante a tener en cuenta es la opinin. La gente que asiste a la demo debera estar obligada a decir algo y no
quedarse callados como si no fuera con ellos porque al final ocurre lo mismo, cuando tienen que opinar no opinan y despus, cuando ya
no se puede hacer nada, es cuando hablan.
Las retrospectivas
Las reuniones de retrospectiva fueron bastante interesantes. Por un lado comentbamos la indiferencia de los asistentes a las
demos y por otro discutamos sobre los problemas que se haban presentado durante el sprint, unas veces con ms energa y otras con
menos. En realidad casi podramos decir que servan como vlvula de escape al pasotismo de los asistentes a la demo. Las
retrospectivas son necesarias, sirven precisamente para evaluar no slo lo que ha ocurrido sino tambin los nimos del equipo.
La planificacin
Tras la retrospectiva llega la reunin de planificacin de sprint. Tal como indicaba ms arriba, las estimaciones se hicieron muy
complicadas: muchsimas tareas por historia de usuario, muchsimas dependencias entre ellas y no siempre tenemos todos en la cabeza
las implicaciones que pueden tener unas con otras, lo que termina en estimaciones muy poco aproximadas por no decir aleatorias. An
as poco a poco se fueron afinando bastante. En las reuniones de planificacin se ponan sobre la mesa tambin nuevos requisitos que
haban ido surgiendo y modificaciones sobre los ya terminados que obligaban a modificar las prioridades de la pila de producto ajustando
el calendario a las nuevas necesidades y objetivos hasta llegar a la siguiente pila de sprint.

Conclusiones y lecciones aprendidas
9

Sin duda la experiencia de utilizar Scrum ha sido muy positiva. En otras ocasiones habamos hecho intentos de aplicar Scrum a
determinados proyectos que resultaron en utilizar solamente algunos conceptos de Scrum, pero la falta de implicacin del cliente (casi
siempre interno) restaba utilidad a la metodologa. En esta ocasin se hizo una aplicacin completa de todas las prcticas, real y efectiva,
implicando a todos los elementos de la organizacin que tuviesen algo que decir dentro del proyecto y, aunque siempre se pueden hacer
crticas a la implicacin de algunos, podemos afirmar que, en general, todos cumplieron con su parte.

Una de las cosas de Scrum que todos alabamos cinco meses despus son, sin duda, los dailys. Nos sirvieron a todos los
partcipes del proyecto para conocer de buena mano qu estaban haciendo los dems, qu problemas haba, cundo se iban a resolver,
etc. Creo que cualquier equipo de desarrollo, independientemente de la metodologa que utilice, debera realizar reuniones diarias para
compartir ideas y problemas.
La idea de tener demostraciones del producto cada dos semanas obliga a todo el equipo a pensar ms en hacer cosas que
funcionen que en ir avanzando en tareas: es ms importante terminar dos historias de usuario para presentar al final del sprint que
comenzar 20 tareas que no se terminen.
Uno de los puntos que nos desviaron del objetivo en cada sprint fue el proceso de integracin y preparacin para la demo.
Cometamos el error de no tener en cuenta estas horas, que al final implicaban bastante tiempo de todo el equipo ya que al realizar la
integracin siempre haba cosas que no funcionaban bien. El ltimo da estaba dedicado casi ntegramente a estas labores que nunca
estaban planificadas en la pila del sprint.
Los que me conocen saben que llevo ya unos aos defendiendo Scrum como metodologa adecuada para el desarrollo de
software. Esta experiencia no ha hecho ms que confirmar esta opinin: la adaptacin del producto al cliente que se consigue no se
podra lograr con metodologas clsicas en las que la ms mnima modificacin de las tareas a realizar puede provocar una desviacin
enorme.
Supongo que nosotros pagamos algo cara la falta de experiencia, sobre todo al principio, pero an as logramos el objetivo.
Seguramente con un poco ms de experiencia el resultado habra sido an mejor.
Por cierto, no hemos dejado Scrum: el proyecto sigue y ya trabajamos en la siguiente release, as que seguimos liados con
dailys, sprints, estimaciones

RUP
Mucha gente acostumbrada a RUP, cuando comienza a aprender acerca de Scrum y mtodos giles, se hace preguntas
similares a la siguiente:
"Para hacer el diseo de un software en RUP se hacer realizacin de casos de uso (diagramas de secuencia, colaboracion, etc),
diagramas de clases, componentes y otros. Se pueden utilizar estos entregables de RUP adicionalmente a los usuales de Scrum
(Product Backlog, Sprint Backlog, Impediment List, Burndown chart)?"
Mi respuesta es la siguiente:
En vista de que Scrum es un framework mnimo para crear un proceso de desarrollo de software, no prohibe la creacin de
artefactos o documentos adicionales a los que indica como obligatorios. Lo nico que dice Scrum al respecto es que juzgues la necesidad,
la utilidad y el costo (vs. el beneficio) de cada uno de los artefactos que decides agregar. Mi opinin es que siempre es necesario realizar
ciertas actividades de modelamiento antes de iniciar un desarrollo.
10

Lo importante es que los modelos producidos sean como una luz que gue el resto del proyecto, no una camisa de fuerza, y dejar
que evolucionen junto con el cdigo producido. Ms an, es crucial comunicar estos modelos al resto del equipo, por lo que muchos
equipos giles prefieren utilizar pizarras (vs. herramientas CASE) para realizar sesiones de modelamiento en conjunto.
Esto es lo que se conoce como Agile Modeling.
Una buena fuente de informacin sobre cmo combinar Scrum y RUP, es el site del OpenUP.

Metodologa de Desarrollo de Software RUP (Rational Unified Process)
Durante los ltimos aos, una de las metodologas ms populares ha sido el RationalUnified Process (RUP). RUP, desarrollado
por Rational Software Corporation, es unproceso de ingeniera de software que ofrece un enfoque disciplinado para asignar tareasy
responsabilidades dentro de la organizacin del desarrollo. RUP captura algunas delas mejores prcticas de la industria para el desarrollo
de software las cuales son paradesarrollar el software en iteraciones, administrar requerimientos, usar arquitecturasbasadas en
componentes, verificar la calidad del software, controlar los cambios alsoftware y modelar el software visualmente usando el Unified
Modeling Language(UML). "El Unified Modeling Language (UML) es un mtodo orientado a objetos y ellenguaje estndar de la industria
para especificar, visualizar, construir y documentar los artefactos de sistemas de software.".
RUP definitivamente es una metodologa que se adapta exclusivamente para el desarrollo de software de pequea a mediana
escala. Se utiliza para hacer toda la documentacin del desarrollo de un software que incluye los casos de uso, requerimientos
funcionales, diagramas de flujo de toda la informacin que necesita para hacer un software. Contempla los siguientes modelos
Modelo de Dominio
Modelo de Casos de Uso
Modelo de Anlisis y Diseo
Modelo de Implementacin
Modelo de Procesos
Modelo de Seguridad
Modelo de Interfaz de Usuario

RUP necesita de UML para referirse los casos de usos, diagramas de secuencia y otros diagramas los que son estndares y
diagrama de clase, el cual sirven adems para hacer el modelo entidad- relacin
RUP es la metodologa que puedes usar y esta se puede apoyar con UML que un lenguaje de modelado...
RUP te da los pasos que vas a seguir y UML te dice como disearlos

UML es para modelar cualquier negocio o sistema. RUP es una metodologa de desarrollo del Software que se compone por 4
fases y es iterativo para el ciclo de vida del sistema
RUP es Rational Unified Process, es un proceso (conjunto de actividades con una secuencia determinada)
UML es Unified Modeling Language, es un lenguaje (una forma de escribir y de modelar)
Un ejemplo llevado a la realidad seria: Para comprar tomates en la legumbrera debo:
1- Realizar listado de cosas a comprar
2 Ver el camino ms rpido a la legumbrera
11

3 Ir a la legumbrera
. Esto sera el proceso (RUP)
Por otro lado, el modelado seria
1 Listado de elementos a comprar
2 Mapa con el camino mas rpido
. Que son los modelos, los escritos que se utilizan para poder llevar a cabo en forma eficiente el proceso
UML un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a
objetos;
RUP (Proceso Unificado de desarrollo de Software): Es un proceso que de manera ordenada define las tareas y quien de los
miembros del equipo de desarrollo har estas tareas.
El proceso de desarrollo RUP (Rational Unified Process) aplica varias de las mejores prcticas en el desarrollo moderno de
software en una forma que se adapta a un amplio rango de proyectos y de organizaciones.
Provee a cada miembro del equipo, un fcil acceso a una base de conocimiento con guas, plantillas y herramientas para todas
las actividades crticas del desarrollo de software. Esta metodologa permite que todos los integrantes de un equipo de trabajo, conozcan y
compartan el proceso de desarrollo, una base de conocimientos y los distintos modelos de cmo desarrollar el software utilizando un
lenguaje de modelado comn: UML.
El RUP es un proceso de desarrollo de software:
Provee un enfoque estructurado para realizar tareas y responsabilidades en una organizacin de desarrollo. Su principal objetivo
es asegurar la produccin de software de alta calidad, que cumpla las necesidades de sus usuarios finales, que sea realizado en las
fechas acordadas y con el presupuesto disponible.
El RUP es un producto:
IBM comercializa un producto que permite instanciar al RUP segn las caractersticas del proyecto, siendo una referencia en la
metodologa que sirve como repositorio nico de informacin.
El RUP es un marco de trabajo (Framework):
Este marco de trabajo puede ser adoptado y extendido para satisfacer las necesidades de la organizacin que lo utilice
seleccionando las fases e iteraciones, los flujos de trabajo y disciplinas que se van a recorrer y los entregables o productos (artifacts) que
se van a construir. Es importante conocer como est organizado y estructurado el proceso para poder seleccionar del frame work, los
elementos del proceso que ms valor darn al proyecto.
El RUP incorpora muchas de las conocidas como buenas prcticas en el desarrollo de software moderno, las cuales se deben
tener presentes en el desarrollo de aplicaciones empresariales para garantizar el xito del proyecto, tales como: Desarrollo iterativo,
Gestin de Requerimientos, Arquitectura basada en componentes, Modelado visual, Verificacin de la calidad en forma continua y control
de cambios.
El RUP presenta 3 caractersticas que constituyen la esencia de todo el proceso de desarrollo:
1) Dirigido por los Casos de uso
2) Centrado en la arquitectura
12

3) Ciclo de vida iterativo
Otras caractersticas o ventajas de la aplicacin de esta metodologa son las siguientes:
Reconoce que las necesidades del usuario y sus requerimientos no se pueden definir completamente al principio
Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integracin final del sistema
Reduce el costo del riesgo a los costos de un solo incremento
Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan para obtener
resultados claros a corto plazo
Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas las disciplinas colaboran en cada
iteracin.
Facilita la reutilizacin del cdigo teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual
adems permite que se aprecien oportunidades de mejoras en el diseo
El proceso de desarrollo est dividido en Fases a lo largo del tiempo cada una de las cuales tiene objetivos especficos y un
conjunto de artefactos definidos que deben alcanzarse. La duracin de cada fase depende del equipo y del producto a generar.
A su vez, cada fase puede tener una o ms iteraciones y cada iteracin sigue el modelo en cascada pasando por las distintas
disciplinas. Cada iteracin termina con una liberacin del producto.
Las fases son las siguientes:
1) Inicio 2) Elaboracin 3) Construccin 4) Transicin

Este documento presenta los pasos para aplicar correctamente la metodologa RUP en el proceso de desarrollo de software.
RUP es muy amplio y la mayora de proyectos no necesitan seguir todo lo que est en el RUP. Esta gua presenta la variacin hecha en el
RUP denominada RUP/E para su aplicacin en las empresas del Per.
2 ADECUACIN DE LOS WORKFLOWS ESENCIALES DEL RUP
Esta seccin explica cmo leer la adecuacin de los Workflows esenciales del RUP detallados en la seccin 3 de este
documento.
2.1 WORKFLOWS ESENCIALES DEL RUP
Esta gua metodolgica cubre la adecuacin para siete (7) de los nueve (9) workflows: Modelamiento de Negocios,
Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Administracin de Configuracin y Cambios y Despliegue. Esta gua
metodolgica excluye los workflows esenciales del RUP para Administracin de Proyectos y Entorno. Estos workflows, los cuales variarn
de acuerdo a las polticas, procedimientos y operaciones de cada empresa cliente interesada, sern revisados separadamente.
2.2 VISTA GENERAL DEL WORKFLOW DEL RUP
La Seccin 3 da una vista general a cada Workflow esencial del RUP y explica por qu es importante incluir se particular
Workflow esencial del RUP en su ciclo de vida de desarrollo de software.. Se presenta cada Workflow de Detalle dentro del Workflow
esencial del RUP y es explicado al igual que los artefactos clave producidos por cada Workflow de detalle. Cada workflow descrito en la
Seccin 3 contiene las siguientes sub secciones:
13

Configuracin y Notas sobre el Workflow del RUP
Artefactos
Reportes
2.2.1 Configuracin y Notas sobre el Workflow del RUP
Estas sub secciones detallan los cambios aplicados a la estructura de workflows del RUP en la variacin de la metodologa de
RUP/E.

2.2.2 Artefactos
Un artefacto es un pedazo de informacin que es creado, modificado o usado por un proceso tal como un modelo, un caso de
uso, un documento, cdigo fuente o un archivo ejecutable. Estas sub secciones listan los artefactos que deberan ser producidos por cada
Workflow esencial del RUP en un formato de tabla. RUP provee templates, guas y ejemplos para todos los artefactos. Si usted no est
usando RUP, entonces debern desarrollarse los templates que puedan ser usadas en toda su organizacin para lograr consistencia al
capturar el mismo tipo de informacin. La Tabla 2 identifica lascolumnas usadas para definir los artefactos producidos por cada workflow
del RUP; lasentradas en las columnas son explicadas en la Tabla 1.


2.2.2.1 Explicacin de la Tabla Artefacto RUP
La Tabla 2 da una explicacin de las columnas en la Tabla Artefacto RUP mostrada en la Tabla 1.

14


2.2.3 Reportes
Esta sub seccin lista los reportes a ser usados por cada Workflow esencial del RUP. La Tabla 3 muestra el formato que es
usado para definir los reportes producidos por cada Workflow esencial del RUP.

2.3 PROCEDIMIENTOS DE REVISIN
Durante el ciclo de vida de un proyecto, una revisin de un artefacto o conjunto de artefactos es presentada al usuario, cliente u
otras partes interesadas para comentarios y aprobacin. Cuando se hacen estas revisiones, usted debe tener en consideracin quelas
revisiones para el equipo de desarrollo de casa son diferentes a las revisiones para el equipo de desarrollo de un contratista. Si las
revisiones son de casa mayormente son informales. Cuando el trabajo lo hace un contratista normalmente se hace una revisin formal
del trabajo del contratista. RUP/E ha adoptado los niveles de revisin indicados en la Tabla 4.



3 LA VERSIN RUP/E DE LOS WORKFLOWS ESENCIALES DEL RUP
La suite de herramientas de Rational (Rational Rose, RequisitePro, Rational Robot, ClearCase, ClearQuest) y el RUP,
desarrollados por Rational Software, fueron escogidos para demostrar un enfoque iterativo del ciclo de vida de desarrollo de software.
RUP/E us el marco metodolgico del RUP para adecuar los siguientes Workflows esenciales del RUP :
Modelamiento de Negocios Una tcnica de anlisis para modelar los procesos del negocio y entender mejor las complejidades
de ste.
15

Requerimientos Una condicin o capacidad que el sistema debe cumplir.
Anlisis y Diseo - Muestra cmo los casos del uso del sistema se realizarn en la implementacin.
Implementacin Implementar y probar las clases.
Pruebas Integrar y probar el sistema.
Despliegue Asegura una transicin exitosa del sistema desarrollado a sus usuarios.
Administracin de la Configuracin y Cambios Identifica, define y estandariza tems; controla las
modificaciones y releases de tems.
Las organizaciones necesitarn incluir administracin de proyectos con RUP y adecuarse segn sea necesario. Un Plan de
Iteracin es algo que debe ser producido durante la administracin del proyecto.
3.1 MODELAMIENTO DE NEGOCIOS
El Modelamiento de Negocios se efecta para valorar el negocio para el cual el sistema de informacin se est construyendo y
para determinar mejor las necesidades y problemas a ser resueltos por los sistemas de informacin. Los modelos del negocio proveen
una base para la comunicacin entre los analistas de sistemas y los desarrolladores para incrementar su entendimiento del negocio y para
identificar oportunidades de mejorar el negocio. Tambin, los gerentes de proyecto usan los modelos del negocio para ayudarse a estimar
los costos del proyecto. El Modelamiento del Negocio debera hacerse antes del desarrollo de software para obtener un buen
entendimiento de sus procesos del negocio. Sin embargo, el Modelamiento del Negocio slo debe ser efectuado si se est cambiando la
manera en que se hace negocio. Si slo se est aadiendo una nueva caracterstica a un sistema existente, entonces RUP/E no
recomienda que usted empiece con un modelamiento del negocio. En ese caso, RUP/E recomienda que usted empiece con la Seccin
3.2, Requerimientos

3.2 REQUERIMIENTOS
Se debera manejar las generaciones (versiones) de requerimientos y su documentacin. La Administracin de Requerimientos
incorpora la identificacin, organizacin y documentacin de los cambios a los requerimientos en un proyecto. Es una parte integral de la
actividad de desarrollo de software. La Administracin de Requerimientos establece un entendimiento comn y acuerdo entre el cliente y
el equipo del proyecto acerca de los requerimientos del cliente. Una Administracin de Requerimientos efectiva incluye el mantener
requerimientos claros. Mantener atributos acerca de los requerimientos (tales como estado, prioridad), proveer seguimiento a otros
requerimientos y componentes y, proveer de los recursos adecuados y fondos para administrar los requerimientos.

3.2.1 Vista general del Workflow de Requerimientos
El propsito del Workflow de Requerimientos es :
Establecer y mantener acuerdos con los clientes y otros stakeholders acerca de loque el sistema debe hacer
Proveer a los desarrolladores del sistema con un mejor entendimientos de losrequerimientos del sistema
Definir las fronteras del sistema (delimitarlo)
Proveer de una base para planificar el contenido tcnico de la iteraciones
Proveer de una base para estimar el costo y el tiempo para desarrollar el sistema
Definirle al sistema una interfase para el usuario enfocndose en las necesidades yobjetivos de los usuarios

Los artefactos clave a desarrollar son : Visin, Modelo de Casos de Uso, Casos de Uso y Especificaciones Suplementarias. Estos
artefactos describen lo que el sistema debe hacer. El Workflow de Requerimientos est relacionado a otros workflows del RUP:

16

El Workflow de Modelamiento de Negocios (no considerado en la presente gua) provee las reglas del negocio
y un modelo de caso de uso del negocio.
El input principal para el Workflow de Anlisis y Diseo son el Modelo de Casos de Uso y el Glosario creados
durante el Workflow de Requerimientos. Por las fallas que se descubran en el Modelo de Casos de Uso, se
generar requerimientos de cambio.
El Workflow de Pruebas prueba el sistema para verificar el cdigo contra el Modelo de Casos de Uso, los
Casos de Uso y las Especificaciones Suplementarias.
El Workflow de Administracin de la Configuracin y Cambios provee los mecanismos de control de cambios
para los requerimientos. Los workflows de Requerimientos consisten de los siguientes workflows de detalle :
Analizar el Problema
El documento Visin es el principal artefacto en el cual el anlisis del problema es documentado.
Entender las Necesidades del Stakeholder
El artefacto principal es un documento refinado de la Visin. Tambin los requerimientos son discutidos y expresados en trminos
de Casos de Uso y Actores. Los requerimientos no funcionales, que no caen fcilmente en el Modelo de Casos de Uso debern ser
documentados en los documentos de Especificaciones Suplementarias.
Definir el Sistema
En Definir el Sistema, se enfoca en identificar a los actores y los casos de uso ms completamente y expandir los requerimientos
no funcionales definidos en los documentos de especificaciones suplementarias.
Administrar el Alcance del Sistema
El alcance del proyecto es definido por el conjunto de requerimientos definidos para ste. La clave para manejar un proyecto
exitoso es administrar el alcance del proyecto para cumpliendo con los recursos disponibles tales como el tiempo, la gente y el dinero. Los
atributos de requerimientos, tales como prioridad, esfuerzo y riesgo, son una tcnica til para manejar el alcance del proyecto.
Refinar la Definicin del Sistema
El output de este Workflow del RUP es una comprensin ms profunda de la funcionalidad del sistema expresada en Casos de
Uso detallados y documentos de Especificaciones Suplementarias detallados. Si es necesario, una Especificacin de Requerimientos de
Software formal puede ser desarrollado, adems de los documentos detallados de Casos de Uso y Especificaciones Suplementarias.
Administrar los Requerimientos de Cambios
Los cambios a los requerimientos impactan los modelos producidos en el Workflow de Anlisis y Diseo, el modelo de pruebas
creado en el Workflow de Pruebas y el material de soporte al usuario final del Workflow de Despliegue. Las relaciones de rastreabilidad
son establecidas para identificar las relaciones entre los requerimientos y otros artefactos. Las relaciones de rastreabilidad son la clave
para entender el impacto del cambio de los requerimientos.

3.2.2 Configuracin y Notas sobre el Workflow de Requerimientos
Cada actividad en el Workflow de Requerimientos es esencial para una implementacin exitosa. Ninguna actividad debe ser
removida del Workflow de Requerimientos.
3.2.3 Artefactos de Requerimientos
17

Los Artefactos de Requerimientos capturan y presentan informacin usada en definir las capacidades requeridas por el sistema.
La Tabla 7 identifica los artefactos que debe ser desarrollados cuando se captura los requerimientos del sistema.

3.2.4 Reportes de Requerimientos
La variacin metodolgica de RUP/E considera opcionales todos los reportes de requerimientos; sin embargo, si van a usarse, la
Tabla 8 identifica los reportes que deben ser producidos durante el Workflow de Requerimientos. El Panorama del Modelo de Casos de
Uso (Use-Case Model Survey) es muy comprensible y cubre la mayora de la informacin contenida en los reportes de Actores y Casos de
Uso.


3.3 ANLISIS Y DISEO
El propsito del Workflow de Anlisis y Diseo es empezar a realizar los casos de uso desarrollados durante el Workflow de
Requerimientos. Es decir, tomar el Modelo de Casos de Uso, el Glosario y las Especificaciones Suplementarias creadas en el Workflow de
Requerimientos y generar un modelo de diseo que pueda ser usado por los desarrolladores durante el Workflow de Implementacin. El
Anlisis se enfoca en trasladar los requerimientos funcionales a conceptos de software.
3.3.1 Vista General del Workflow de Anlisis y Diseo
El propsito del Workflow de Anlisis y Diseo es:
Transformar los requerimientos en un diseo del sistema a crear
Definir una arquitectura robusta para el sistema
Adaptar el diseo para que funcione en el ambiente de implementacin disendolo para obtener buena
performance
El Workflow de Anlisis y Diseo toma los casos de uso documentados del Workflowde Requerimientos y del Workflow de
Modelamiento de Negocios y los traslada a elementos de diseo que sern usados para construir el sistema. Por medio de usar varias
actividades y modelos el Workflow de Anlisis y Diseo busca destilar la informacin recogida de los stakeholders en informacin que los
programadores podrn usar. Al final, un Modelo de Diseo, el documento de Arquitectura del Software, el Modelo de Despliegue y una
Realizacin de Casos de Uso por cada Caso de Uso describirn el sistema. El Workflow de Anlisis y Diseo est relacionado a otros
workflow del RUP como sigue:
18

El Workflow de Implementacin usar el Modelo de Diseo, el Modelo de Despliegue, el documento de
Arquitectura del Software y las Realizaciones de Casos de Uso como inputs en la construccin e
implementacin del sistema.
El Workflow de Pruebas usar las realizaciones de casos de Uso y el documento de Arquitectura del Software
para probar la funcionalidad y la compatibilidad de los componentes.
El Modelo de Despliegue y el documento de Arquitectura del Software ser usado por el Workflow de
Despliegue para desplegar el sistema final.
El Workflow de Anlisis y Diseo consiste de los siguiente workflows de detalle:
1) Definir una Arquitectura candidata
2) Refinar la Arquitectura
3) Analizar el Comportamiento
4) Disear la base de Datos (Opcional)

3.3.2 Configuracin y Notas sobre el Workflow de Anlisis y Diseo
El Workflow de detalle Refinar la Arquitectura puede ser saltado si hay relativamente pocos riesgos arquitecturales. Esto es, el
diseo, la implementacin y la distribucin del sistema no producen problemas arquitecturales significativos o el arquitecto de software
tiene suficiente experiencia para manejar tales hechos. El Workflow de detalle Efectuar Sntesis Arquitectural puede ser saltado. Este
Workflow de detalle puede ser efectuado si es que se necesita profundizar los conceptos. Los workflows de detalle Disear Componente
de Tiempo Real y Disear Componente[No Tiempo Real] son similares con la excepcin de que el primero se enfoca en componentes
que son para sistemas en tiempo real y el otro para sistemas reactivos.
3.3.3 Artefactos para Anlisis y Diseo
Los Artefactos para Anlisis y Diseo capturan y presentan informacin relativa a la solucin de los problemas planteados
durante el Workflow de Requerimientos. La Tabla9 identifica los artefactos que debern producirse durante el Workflow de Anlisis y
Diseo



3.3.4 Reportes para Anlisis y Diseo
La variacin metodolgica de RUP/E considera opcionales todos los reportes de requerimientos; sin embargo, si van a usarse, la
Tabla 10 identifica los siguientes reportes opcionales:
19


3.4 IMPLEMENTACIN
La Implementacin es donde empieza el cdigo El Modelo de Diseo del Workflow deAnlisis y Diseo es mapeado con el
Modelo de Implementacin y entonces se escribe el cdigo en un lenguaje de programacin tal como Java, C++ o Visual Basic.
Un Plan de Integracin de Construcciones define el Caso de Uso a ser diseado y las clases a implementar, al igual que el orden
en el que las clases son implementadas.
3.4.1 Vista general del Workflow de Implementacin
El propsito del Workflow de Implementacin es:
Definir la organizacin del cdigo, en trminos de Subsistemas de Implementacin.
Define the organization of the code, in terms of Subsistema de Implementacin. Los Subsistemas de
Implementacin son colecciones de componentes y otros modelos de implementacin usados para estructurar
el modelo de implementacin.
Implementar las clases y objetos definidos en el modelo de diseo en la forma de componentes de software
tales como archivos fuente, binarios o ejecutables
Probar los componentes desarrollados como unidades
Crear un sistema ejecutable El Workflow de Implementacin est relacionado a otros workflows del RUP como
sigue:
Requerimientos: Este workflow del RUP captura los requerimientos que deberan ser cumplidos durante la Implementacin.
Anlisis y Diseo: El modelo de diseo desarrollado durante este workflow representa el intento de la implementacin y es el
input principal para el Workflowde Implementacin.
Pruebas: Este workflow describe cmo probar cada Construccin durante la integracin del sistema.
Para cada iteracin, empezando en la fase de Elaboracin, se efectan los siguientes workflows de detalle:
Estructurar el Modelo de Implementacin: El artefacto principal producido es el Modelo de Implementacin.
Planificar la Integracin: El artefacto principal producido es el Plan de Integracin de Construcciones. Segn la
arquitectura y el diseo evolucionan, el Plan de Integracin de Construcciones es examinado y actualizado para
asegurar que no quede obsoleto debido a los cambios en la arquitectura o en el diseo del nuevo sistema
Implementar los Componentes: La Implementacin debera estar unida muy de cerca al Diseo. El artefacto
principal producido es el Componente.
Integrar cada Subsistema: Los principales artefactos producidos son la Construccin y el Subsistema de
Implementacin.
Integrar el Sistema: La Integracin a menudo envuelve un alto grado de automatizacin, experiencia en
sistemas operativos o lenguajes script y herramientas como 'make' (en Unix). El artefacto principal producido es
la Construccin
3.4.2 Configuracin y Notas sobre el Workflow de Implementacin
20

Cada actividad en el Workflow de Implementacin es esencial para una implementacin exitosa. Ninguna actividad debe
removerse del Workflow de Implementacin.
3.4.3 Artefactos para la Implementacin
Los Artefactos para la Implementacin capturan y presentan la realizacin de la solucin presentada en el Workflow de Anlisis y
Diseo. La Tabla 11 identifica los artefactos que deben producirse durante el Workflow de Implementacin

Por este artefacto se entiende al Prototipo o Producto, segn la fase en que se encuentre el proyecto, resultante de cada
iteracin.
3.4.4 Reportes para la Implementacin
Ningn reporte ser producido durante el Workflow de Implementacin. Sin embargo, se efectuarn revisiones informales del
cdigo.
3.5 PRUEBAS
Rational ofrece su enfoque de pruebas usando el RUP para valorar la calidad del software por medio de:
Encontrar y documentar los defectos en la calidad del software
Aconsejando acerca de la calidad percibida en el software
Proveyendo la validacin de los supuestos hechos en las especificaciones de diseo y los requerimientos a
travs de demostraciones concretas
Validando las funciones del producto de software segn sean diseadas
Validando que los requerimientos hayan sido implementados apropiadamente

3.5.1 Vista General del Workflow de Pruebas
El propsito de este workflow del RUP es:
1) Verificar la interaccin entre objetos
2) Verificar la interaccin apropiada de todos los componentes del software
3) Verificar que todos los requerimientos hayan sido implementados correctamente
4) Identificar y asegurar que los defectos se hayan atendido y resuelto antes del despliegue del software
En el RUP, las pruebas son enfocadas a travs del uso de un proceso iterativo y de herramientas. Un enfoque iterativo para
probar permite a la organizacin tratar las pruebas casi de la misma forma que el desarrollo de software es enfocado. Cada Construccin
de software es un objetivo para las pruebas. Segn se vayan produciendo nuevas Construcciones, el cuerpo de pruebas ser aadido y
refinado. Eventualmente, todas las pruebas en el cuerpo de pruebas sern acumuladas de tal manera que pueden ser usadas para las
posteriores pruebas de regresin en el ciclo de vida del desarrollo de software. Este enfoque permite a una organizacin identificar
posibles riesgos al inicio de un proyecto, reducir el costo de corregir fallas enfocando los recursos cuando y donde tendrn el mayor
impacto, acercarse a los gaps de calidad tempranamente en el proceso de desarrollo y maximizar la efectividad por medio de adaptar el
enfoque, el proceso o el presupuesto segn va progresando el proyecto.
21

Este workflow del RUP est relacionado a otros workflows del RUP como sigue:
El Workflow de Requerimientos captura el input principal para identificar cuales pruebas efectuar en la forma de
requerimientos en un modelo de caso de uso.
El Workflow de Anlisis y Diseo captura el input principal para identificar cuales pruebas efectuar describiendo
cmo desarrollar un diseo.
El Workflow de Implementacin produce las Construcciones de software del modelo de implementacin que es
probado por medio del Workflow de Pruebas. Dentro de una iteracin, hay varias construcciones probadas: la
primera cuando el sistema es integrado y la ltima para probar todo el sistema.
El Workflow de Pruebas consiste de los siguientes Workflows de detalle:
1) Planificar las Pruebas: El principal artefacto producido es el Plan de Pruebas.
2) Disear las Pruebas: Los principales artefactos producidos son el Modelo de Pruebas (Test Model), los Casos
de Prueba (Test Case), los Procedimientos de Prueba (Test Procedures) y el documento de Anlisis de Carga
de Trabajo (Workload Analysis Document).
3) Implementar las Pruebas: Los principales artefactos producidos son el Script de la Prueba y el Componente de
laPrueba.
4) Ejecutar las Pruebas en la etapa de Integracin de Pruebas: El principal artefacto producido es el documento
Resultado de Pruebas.
5) Ejecutar las Pruebas en la etapa de Pruebas del Sistema: El principal artefacto producido es el documento
Resultado de Pruebas.
6) Evaluar las Pruebas: Los principales artefactos producidos son el Sumario de Evaluacin de Pruebas
(TestEvaluation Summary) y los Requerimientos de Cambio (Change Request).
3.5.2 Configuracin y Notas sobre el Workflow de Pruebas
Cada actividad en el Workflow de Pruebas es esencial para probar exitosamente. Ninguna actividad debe ser removida del
Workflow de Pruebas.

3.5.3 Artefactos de Pruebas
Los artefactos presentados en la siguiente tabla son productos finales e intermedio que son producidos y usados durante el
Workflow de Pruebas de un proyecto. Los artefactos de Pruebas capturan y comunican informacin de pruebas y pueden tomar la forma
de un documento, un modelo o un elemento de modelo. La Tabla 12 identifica los artefactos que deben ser desarrollados en el Workflow
de Pruebas.

3.5.4 Reportes para las Pruebas
22

Ningn reporte ser producido durante Workflow de Despliegue. Los artefactos producen la necesaria informacin workflow del
RUP.
3.6 DESPLIEGUE
Una vez que el producto de software ha siso implementado y probado exitosamente, es momento de llevar el producto al cliente.
El propsito de este workflow del RUP es producir releases del producto y llevar el software a los usuarios finales.
3.6.1 Vista General del Workflow de Despliegue
El Workflow de Despliegue implica probar el software en su ambiente operacin al final, empacar el software para la entrega,
distribuir el software, instalar el software ,entrenar a los usuarios finales y convertirlas bases de datos anteriores para la carga de datos.
Hay tres maneras de proveer del producto al usuario final:
1) La instalacin en el cliente
2) Se entrega un instalador (generado con algn producto de compresin e instalacin)
3) Accesar al software por la Internet
Cualquiera que sea el mtodo escogido para entregar al cliente, la prueba del producto ocurre en el site de desarrollo seguido por
la prueba Beta y finalmente liberando el producto al cliente. El Workflow de Despliegue est relacionado a otros workflows del RUP, como
sigue:
Planificar el Despliegue
Desarrollar Material de Soporte: Produce el material de soporte, el cual incluye instrucciones para instalacin,
operacin y mantenimiento para el sistema desplegado. Tambin incluye el material de entrenamiento para las
diversas posiciones requeridas para usar el sistema efectivamente.
Manejar las Pruebas de Aceptacin Producir la Unidad de Despliegue
Empaquetar el Producto Proveer Acceso al Site de Descarga
Producto en Beta

3.6.2 Configuracin y Notas sobre el Workflow de Despliegue
Las organizaciones grandes pueden empacar el producto y dar acceso a un site de descarga; sin embargo, la mayora no
necesita efectuar estos workflows de detalle.
3.6.3 Artefactos para el Despliegue
Los artefactos de Despliegue capturan y presentan informacin relativa a posicionar el sistema, presentado en el Workflow de
Implementacin, dentro del ambiente de produccin. La Tabla 14 identifica los artefactos que deben ser producidos durante el Workflow
de Despliegue.
23


Por Materiales de Entrenamiento, se entender el Manual del Usuario y el ManualTcnico.
3.6.4 Reportes para el Despliegue
Ningn reporte ser producido durante Workflow de Despliegue. Los artefactos producen la necesaria informacin workflow del
RUP.
3.7 ADMINISTRACIN DE CONFIGURACIN Y CAMBIOS
La mayora de equipos de desarrollo de software experimentados reconocen la necesidad del control de versiones de los
artefactos del software. Parcialmente, a causa de que el software es tan fcil de cambiar, un proyecto est continuamente vulnerable ala
introduccin inadvertida de incompatibilidades (errores de regresin) y fallas resultantes de la aplicacin a menos que una disciplina
constante sea aplicada. El control de versiones, sin embargo, es slo un componente de la Administracin de Configuracin y Cambios
(Configuration & Change Management -CCM-). Un buen sentido de ordenamiento es provisto por esta lista de las mejores prcticas de
CCM :
Identificar y almacenar los artefactos en un repositorio seguro
Controlar y auditar loa cambios a los artefactos
Organizar los artefactos en componentes versionados
Crear versiones congeladas (baselines) en los hitos del proyecto
Registrar y rastrear los requerimientos de cambio
Organizar e integrar juegos consistentes de versiones (algunas veces llamados actividades)
Mantener reas de trabajo estables y consistentes (inclusive sobre sites distribuidos geogrficamente)
Soportar cambios concurrentes a los artefactos y componentes
Integrar tempranamente y a menudo
Asegurar que las Construcciones de software sean reproducibles
RUP/E recomienda usar CRM (Change Requeriment Management) en todas las fases del ciclo de vida despus de la Incepcin.
Aunque CRM puede ser hecho manualmente, sus mayores beneficios se obtienen cuando se usa una herramienta automatizado para
hacer uso de una base de datos. Existe un nmero de excelente herramientas de CRM. Clear Quest de Rational es una buena opcin si
planea integrarse con otras herramientas de Rational.
Adems de automatizar, lo que muchos consideran un proceso tedioso, una herramienta CRM manejada con una base de datos
tambin provee otro gran beneficio: la habilidad de extraer informacin fcilmente acerca del progreso del proyecto, especialmente enlas
fases de Construccin y posteriores. Una buena herramienta de CRM permite que sepueda crear consultas ad-hoc fcilmente.
3.7.1 Vista general del Workflow de Administracin de Configuracin y Cambios
1) El propsito de este workflow del RUP es:
2) Soportar mtodos de desarrollo
3) Mantener la integridad del producto
24

4) Asegurar que el producto configurado est completo y correcto
5) Proveer de un ambiente estable dentro del cual se desarrolla el producto
6) Restringir los cambios a los artefactos basados en las polticas del proyecto
7) Proveer pistas de auditoria de cambios a los artefactos registrando por qu, cundo y por quin
El Workflow de Administracin de Configuracin y Cambios est relacionado a otros workflows esenciales del RUPs
(Modelamiento de Negocios, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue) porque sirve como un repositorio
para los artefactos producidos durante esos workflows del RUPs. Los artefactos clave son el Plan de Administracin de Configuracin
(Configuration Management Plan) y los Requerimientos de Cambio (Change Request)
Los siguientes Workflows de detalle de Administracin de Configuracin y Cambios son efectuados:
Planificar la Configuracin del Proyecto y el Control de Cambios: El Plan CM describe todas las actividades a efectuarse durante
el curso del ciclo de vida del proyecto. El Plan CM documenta cmo se planifica, implementa, controla y organiza las actividades relativas
al CM del producto.
Crear un Ambiente CM para el Proyecto: Los desarrolladores e integradores son provistos de espacios de trabajo privados y
compartidos donde puedan construir e integrar el software.
Cambiar y Enviar los Items de la Configuracin
Manejar Versiones Congeladas (Baselines) y Liberacioness
Monitorear y Reportar el estado de la Configuracin
Administrar los Requerimientos de Cambio
3.7.2 Notas sobre el Workflow de Administracin de Configuracin y Cambios
Cada actividad en el Workflow de Administracin de Configuracin y Cambios es esencial para una administracin de
configuracin exitosa. Ninguna actividad debe ser removida del Workflow de Administracin de Configuracin y Cambios.
3.7.3 Artefactos RUP de Administracin de Configuracin y Cambios
Los artefactos e Administracin de Configuracin y Cambios capturan y presentan informacin relativa a las actividades CM. La
Tabla 15 identifica los artefactos que deben ser producidos durante el Workflow de Administracin de Configuracin y Cambios


4 PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE
La Seccin 3 da una versin adecuada genrica del RUP usando la suite de herramientas de Rational; sin embargo, esto puede
no cubrir las necesidades de cada empresa. Las empresas debern hacer lo siguiente:
25

Evaluar sus organizaciones para determinar cmo proveer del ambiente de desarrollo de software necesario
para soportar a su equipo de desarrollo; este ambiente puede incluir las herramientas de la Suite de Rational u
otras herramientas
Comprar nuevo software, si es necesario
Lograr la disponibilidad de usar la metodologa de parte de la Administracin
Obtener el entrenamiento apropiado en el software usado
Decidir si se desarrollar otros artefactos adicionales a los indicados en la Seccin 3
Incluir un enfoque de administracin de proyectos para :
1) manejar riesgos
2) planificar proyectos
3) identificar mtricas
4) monitorear el progreso del proyecto y;
5) manejar recursos, presupuestos y contratos con proveedores y clientes
Revisar el siguiente sitio, y dar su opinin por escrito de ste artculo
http://www.1tech.eu/clients/casestudy_toyota3