Explicando Scrum a mi abuelaIntroduccin 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 explicacionesDe 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 chinoEl 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 adicionalEmpiezo 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 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 ClientesAlgo 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 MeetingEl 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 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.

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 AlbaladejoLa 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. 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.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 aquella 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 proyectoEl 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.ScrumDesde 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 EquipoLos dailys se hacan va conferencia entre una sala de reuniones en Madrid y otra en Valencia.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 datawarehouseLa tecnologaComo 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 SprintsLos 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 llegamos 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.Las EstimacionesUno 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 DemostracionesLas 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 retrospectivasLas 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 planificacinTras 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 aprendidasSin 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

RUPMucha 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. 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 modelosModelo de DominioModelo de Casos de UsoModelo de Anlisis y DiseoModelo de ImplementacinModelo 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- relacinRUP 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 sistemaRUP 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 comprar2 Ver el camino ms rpido a la legumbrera3 Ir a la legumbrera. Esto sera el proceso (RUP)Por otro lado, el modelado seria1 Listado de elementos a comprar2 Mapa con el camino mas rpido. Que son los modelos, los escritos que se utilizan para poder llevar a cabo en forma eficiente el procesoUML 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 uso2) Centrado en la arquitectura3) Ciclo de vida iterativoOtras 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 diseoEl 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) Elaboracin3) Construccin4) 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 RUPEsta 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 RUPEsta 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 RUPLa 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: Configuracin y Notas sobre el Workflow del RUP Artefactos Reportes2.2.1 Configuracin y Notas sobre el Workflow del RUPEstas 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 ArtefactosUn 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 RUPLa Tabla 2 da una explicacin de las columnas en la Tabla Artefacto RUP mostrada en la Tabla 1.

2.2.3 ReportesEsta 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 REVISINDurante 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 RUPLa 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. 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 NEGOCIOSEl 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 REQUERIMIENTOSSe 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:

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 ProblemaEl 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 SistemaEn 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 SistemaEl 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 CambiosLos 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 RequerimientosCada 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 RequerimientosLos 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 RequerimientosLa 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 DISEOEl 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 performanceEl 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: 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 candidata2) Refinar la Arquitectura3) Analizar el Comportamiento4) Disear la base de Datos (Opcional)

3.3.2 Configuracin y Notas sobre el Workflow de Anlisis y DiseoEl 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 DiseoLos 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 DiseoLa 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:

3.4 IMPLEMENTACINLa 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 Construccin3.4.2 Configuracin y Notas sobre el Workflow de ImplementacinCada 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 ImplementacinLos 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 ImplementacinNingn reporte ser producido durante el Workflow de Implementacin. Sin embargo, se efectuarn revisiones informales del cdigo.3.5 PRUEBASRational 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 PruebasEl propsito de este workflow del RUP es:1) Verificar la interaccin entre objetos2) Verificar la interaccin apropiada de todos los componentes del software3) Verificar que todos los requerimientos hayan sido implementados correctamente4) Identificar y asegurar que los defectos se hayan atendido y resuelto antes del despliegue del softwareEn 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.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 PruebasCada 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 PruebasLos 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 PruebasNingn reporte ser producido durante Workflow de Despliegue. Los artefactos producen la necesaria informacin workflow del RUP.3.6 DESPLIEGUEUna 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 DespliegueEl 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 cliente2) Se entrega un instalador (generado con algn producto de compresin e instalacin)3) Accesar al software por la InternetCualquiera 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 DespliegueLas 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 DespliegueLos 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.

Por Materiales de Entrenamiento, se entender el Manual del Usuario y el ManualTcnico.3.6.4 Reportes para el DespliegueNingn reporte ser producido durante Workflow de Despliegue. Los artefactos producen la necesaria informacin workflow del RUP.3.7 ADMINISTRACIN DE CONFIGURACIN Y CAMBIOSLa 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 reproduciblesRUP/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 Cambios1) El propsito de este workflow del RUP es:2) Soportar mtodos de desarrollo3) Mantener la integridad del producto4) Asegurar que el producto configurado est completo y correcto5) Proveer de un ambiente estable dentro del cual se desarrolla el producto6) Restringir los cambios a los artefactos basados en las polticas del proyecto7) Proveer pistas de auditoria de cambios a los artefactos registrando por qu, cundo y por quinEl 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 ConfiguracinManejar Versiones Congeladas (Baselines) y LiberacionessMonitorear y Reportar el estado de la ConfiguracinAdministrar los Requerimientos de Cambio3.7.2 Notas sobre el Workflow de Administracin de Configuracin y CambiosCada 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 CambiosLos 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 CLIENTELa 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: 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 riesgos2) planificar proyectos3) identificar mtricas4) monitorear el progreso del proyecto y;5) manejar recursos, presupuestos y contratos con proveedores y clientesRevisar el siguiente sitio, y dar su opinin por escrito de ste artculohttp://www.1tech.eu/clients/casestudy_toyota33