You are on page 1of 18

LECCIN 0

Introduccin al curso

Objetivos del curso


Los objetivos del curso son que el alumno conozca la gestin gil de proyectos tecnolgicos para gestionar con xito el da a da de los proyectos.

Prcticas y tecnologas que aborda el curso:


SCRUM, HISTORIAS DE USUARIO, PRODUCT OWNER, ESTIMACIN GIL, PUNTOS HISTORIA, PRODUCT BACKLOG, CICLOS DE VIDA GILES, LEAN, KANBAN, etc.

Desglose de objetivos
Conocer las bases de las metodologas giles y su diferencia con las metodologas tradicionales. Conocer las prcticas giles propias de Scrum, sus particularidades e importancia actual de dicha metodologa gil en el sector. Conocer LEAN Y Kanban. Presentar cules son los mtodos de estimacin ms eficientes en el rea de las metodologas giles. Veremos cmo funciona el Planning Poker y los puntos historia otros aspectos relacionados, como la relacin de las metodologas giles, como Scrum, con modelos de procesos como CMMI o ISO/IEC 15504.

Dirigido a
Estudiantes de carreras tecnolgicas Profesionales de informtica en general Directivos, Jefes de proyecto, responsables de calidad Consultores Personal de gerencia media y tcnica del rea de TI.

Modalidad de evaluacin

El curso est compuesto de 5 lecciones de contenido audiovisual, textual y presentaciones. No est previsto restringir los horarios de acceso por lo que el estudiante podr acceder a las lecciones a partir del momento en que se habiliten y hasta la finalizacin del curso. Al finalizar cada leccin, el usuario obtendr una nota con su calificacin despus de realizar el test correspondiente, siendo todos estos obligatorios. Esa nota no tendr ningn valor sobre la calificacin final del curso. Solo se utilizar para que el estudiante conozca cmo ha realizado esa leccin. Cada test podr realizarse una nica vez, y es obligatoria su realizacin para pasar al siguiente mdulo. Las lecciones han de realizarse en orden secuencial, es decir, para acceder a una leccin es necesario haber completado la leccin anterior. Para obtener el certificado que indica que se ha superado el curso, es necesario obtener una calificacin del 50% en el examen final. Este examen estar disponible para su realizacin tras la publicacin de todas las lecciones del curso. Utiliza el "Foro" para cualquier tipo de duda que te surja sobre el curso o su contenido. En este foro sers respondido por otros alumnos o por los profesores del curso.

Normas de los foros


Para que la participacin en los foros del curso sea satisfactoria para todos los alumnos, se deben seguir las reglas que se detallan a continuacin. Debe mantener una conducta apropiada con el resto de miembros. Escriba en la seccin o foro adecuado (foro general o foro especfico de lecciones). Trate temas que no estn relacionados con la temtica del curso. No publique contenido indebido o censurable. No incluya anuncios con fines comerciales o publicitarios. No publique contenido que infrinja cualquiera de los derechos legales de terceros, como pueden ser derechos de propiedad intelectual. El foro podr ser abierto algunos das antes del comienzo del curso, y ser cerrado al finalizar el mismo (aunque el examen final del curso contine abierto), por lo que si deseas realizar comentarios en el foro podrs hacerlo hasta el ltimo da del curso. En caso de incumplimiento de alguna de las reglas especificadas, los administradores y/o moderadores podrn tomar las acciones que consideren oportunas.

LECCIN 1

Entendiendo qu es un proyecto gil


1.1-Introduccin

La predictibilidad, ciclo de vida en cascada o desarrollo tradicional


En su nacimiento, la gestin de proyectos software intent imitar la gestin de proyectos de otras disciplinas, como la arquitectura, las industria o la ingeniera civil, hasta el punto de heredar y adaptar al mundo del software muchos de sus roles (p.e. arquitectos software) y tipos de organizaciones (p.e. fbricas de software). Hoy en da una de las prcticas ms discutidas y polmicas de las que se han querido heredar desde otras disciplinas es la llamada predictibilidad, tambin conocida como gestin de proyectos dirigida por la planificacin, desarrollo tradicional o incluso tambin conocida como desarrollo pesado. La predictibilidad se basa en dividir un proyecto en fases, por ejemplo, de manera simplificada, requisitos, diseo y construccin, y que cada una de estas fases no comience hasta que termine con xito la anterior. Se le llama predictibilidad porque cada fase intenta predecir lo que pasar en la siguiente; por ejemplo, la fase de diseo intenta predecir qu pasar en la programacin, y esos diseos intentarn ser muy precisos y detallados, para ser cumplidos sin variacin por los programadores. Adems, en este tipo de gestin, cada una de estas fases se realiza una nica vez (no hay dos fases de requisitos). Y las fases estn claramente diferenciadas (en teora, est claro cundo termina el diseo y comienza la programacin), hasta el punto de tener profesionales claramente diferenciados y especializados en cada una de ellas: analistas de requisitos, arquitectos de diseo software, programadores, personas para pruebas, etc. Normalmente cada fase concluye con un entregable documental que sirve de entrada a la siguiente fase, la especificacin de requisitos software es la entrada al diseo, el documento de diseo la entrada a la construccin, etc.

La gestin de proyectos predictiva es tpica en disciplinas como la arquitectura. Y desde sus orgenes, la ingeniera del software intent perseverantemente emular a las ingenieras clsicas. Tener una fase de diseo muy claramente separada de la programacin (hasta el punto de intentar tener una organizacin cliente que detalle los diseos y otra organizacin, normalmente llamada fbrica de software, que los implemente). Que la programacin no comenzase hasta que terminase el diseo. Que el diseo concluya con unos planos precisos que guen totalmente la construccin. Que una vez que se hace un diseo ste no se modifique; de hecho, notaciones como UML (UnifiedModelingLanguage es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema) se concibieron para construir los planos detallados del software. Al anterior tipo de gestin de proyectos predictiva, en el mundo del software se le conoce como ciclo de vida en cascada (ver Figura 1).

Figura 1.1. Ejemplo de ciclo de vida predictivo o en cascada

1.2 - gil vs. Tradicional


Construir software no es como construir coches o casas
En software, la experiencia nos dice que es muy difcil especificar los requisitos en una nica y primera fase. Por la complejidad de muchas de las reglas de negocio que automatizamos cuando construimos software, es muy difcil saber qu software se quiere hasta que se trabaja en su implementacin y se ven las primeras versiones o prototipos 1. Tambin es muy difcil documentar de una nica vez, a la primera, antes de la codificacin, un diseo que especifique de manera realista y sin variacin todas las cuestiones a implementar en la programacin. Las ingenieras clsicas o la arquitectura necesitan seguir este tipo de ciclos de vida en cascada o predictivos porque precisan mucho de un diseo previo a la construccin, exhaustivo e inamovible: disponer de los planos del arquitecto siempre antes de empezar el edificio. Nadie se imagina que una vez realizados los cimientos de un edificio se vuelva a redisear el plano y se cambie lo ya construido. Adems, los planos para construir son precisos y pocas veces varan, ya que la mayora de los diseos de las ingenieras clsicas, arquitecturas, etc., pueden hacer un mayor uso de las matemticas o la fsica. En software no es as. Y aunque se pretenda emular ese modo de fabricacin, en software no funciona bien, y debemos tener muy claro que es casi imposible cerrar un diseo a la primera para pasarlo a programacin sin tener que modificarlo posteriormente.

La evolucin en la fabricacin del software


Dr. Javier Garzs
ybele onsulting

@jgarzas

Por lo general, realizar un cambio en el producto final que construyen las ingenieras clsicas o la arquitectura es muy costoso. Cambiar, por ejemplo, la posicin de una columna en un edificio o realizar modificaciones a la estructura de un puente ya construido tiene un alto coste. Y de ah que la arquitectura o las ingenieras clsicas pretendan lograr a toda costa diseos o planos de un alto
1

En este caso se utiliza la palabra prototipo como sinnimo de un producto software con caractersticas que pueden ser utilizadas por el cliente

nivel de detalle, para que una vez que comience la fase de construccin no tengan que ser modificados. Adems, normalmente, en la arquitectura o en las ingenieras clsicas los costes de construir son muy elevados en comparacin con los de disear. El coste del equipo de diseadores es sustancialmente inferior al de la realizacin de la obra, del puente, edificio, etc. La anterior relacin de costes no se comporta igual en el caso del software. Por un lado, el software, por su naturaleza (y si se construye mnimamente bien), es ms fcil de modificar. Cambiar lneas de cdigo tiene menos impacto que cambiar los pilares de un edificio ya construido. De ah que existan numerosas propuestas que recomiendan construir rpido una versin software y modificarla evolutivamente (la tcnica de la refactorizacin trabaja sobre esta idea). En software no existe esa divisin tan clara entre los costes del diseo y los de la construccin. Tambin en las ingenieras clsicas o la arquitectura los roles y especializacin necesaria en cada fase son diferentes. Los planos o diseos los realizan arquitectos que no suelen participar en la fase de construccin. La construccin tiene poco componente intelectual y mucho manual, al contrario que el diseo. Y todo apoya a que existan dos actividades claramente diferenciadas: el diseo y la construccin. En nuestro caso, el producto final, el software, tiene diferencias muy sustanciales con estos productos fsicos. Estas diferencias hacen que el proceso de construccin sea diferente. Durante muchos aos, quizs por la juventud de la ingeniera del software, se han obviado estas diferencias, e incluso se han intentado encontrar metodologas que imitasen y replicasen los procesos de construccin tradicional al software. Ejemplo de ello son las primeras versiones y usos de lenguajes de diseo como UML, o metodologas como RUP 2 o Mtrica v3 3 . Sin embargo en muchas ocasiones, estos intentos de emular la construccin de software a productos fsicos han creado importantes problemas y algunos de los mayores errores a la hora de gestionar proyectos software. Diferenciar el cmo se construye software del cmo se construyen los productos fsicos es uno de los pilares de las metodologas giles (M. Fowler, 2005) 4. De hecho es un tema del que se ha escrito mucho .Y tambin se ha debatido bastante, desde hace muchos aos, con posturas a favor y en contra. Y es que en software, es frecuente que diseo y construccin muchas veces se solapen, y por ello se recomiende construir por iteraciones, por partes, y el uso de prototipos incrementales.

RUP, por sus siglas en ingls que significan RationalUnifiedProcess es un proceso de desarrollo de software utilizado junto con UML y que constituye una metodologa para el anlisis, diseo, implementacin y documentacin de proyectos software orientados a objetos. 3 Mtrica v3 es una metodologa de planificacin, desarrollo y mantenimiento de sistemas de informacin, mayormente promovida y utilizada en el mbito de las administraciones pblicas. 4 Fowler, M. (2005). The new methology.
2

1.3-Frente a la prediccin adaptacin, o el ciclo de vida iterativo e incremental


Es curioso ver como el concepto ciclo de vida, una de las piezas ms fundamentales, y transcendentales, de la gestin de un proyecto software produce tanta confusin. En parte, tampoco es de extraar, debido a que no existe una nica terminologa al respecto, existen muchas definiciones, conceptos confusos, etc. Por eso vamos a aclarar los distintos tipos de ciclos de vida:

Cascada
Las fases del ciclo de vida (requisitos, anlisis, diseo, etc.) se realizan (en teora) de manera lineal, una nica vez, y el inicio de una fase no comienza hasta que termina la fase anterior. Su naturaleza es lineal, tpica de la construccin de productos fsicos y su principal problema viene de que no deja claro cmo responder cundo el resultado de una fase no es el esperado. El ciclo de vida ms criticado en los ltimos aos. En muchos proyectos su implantacin ha sido un fracaso, mientras que hay otros proyectos que trabajan perfectamente de esta manera.

El ciclo de vida incremental


Cada iteracin (una iteracin es un periodo de tiempo, no confundir con el ciclo de vida iterativo, que veremos luego, siendo este punto confuso, por las definiciones) contiene las fases del cascada estndar, pero cada iteracin trabaja sobre un sub conjunto de funcionalidad. La entrega total del proyecto se divide en subsistemas priorizados. Desarrollar por partes el producto software, para despus integrarlas a medida que se completan. Un ejemplo de un desarrollo puramente incremental puede ser la agregacin de mdulos en diferentes fases. El agregar cada vez ms funcionalidad al sistema.

El ciclo de vida iterativo


En cada ciclo, iteracin, se revisa y mejora el producto. Un ejemplo de desarrollo iterativo es aquel basado en refactorizaciones, en el que cada ciclo mejora ms la calidad del producto. Este ciclo no implica aadir funcionalidades en el producto, pero si la revisin y la mejora.

Iterativo e incremental
Incremental = aadir, iterativo = retrabajo Se va liberando partes del producto (prototipos) peridicamente, en cada iteracin, y cada nueva versin, normalmente, aumenta la funcionalidad y mejora en calidad respecto a la anterior. Aqu hay un post (p1.1) con ms informacin. Adems, el ciclo de vida iterativo e incremental es una de las bases de un proyecto gil, ms concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente ms de dos

P1.1 EL CICLO DE VIDA ITERATIVO E INCREMENTAL Y EL RIESGO DE OLVIDARSE DEL ITERATIVO Y QUEDARSE SOLO CON EL INCREMENTAL
Si en un ciclo de vida en cascada las fases del ciclo de vida (requisitos, anlisis, diseo, etc.) se realizan (en teora) una nica vez, y el inicio de una fase no comienza hasta que termina la fase que le precede, en un ciclo de vida iterativo e incremental se va liberando partes del producto (prototipos) peridicamente, en cada iteracin, y cada nueva versin, normalmente, aumenta la funcionalidad y mejora en calidad respecto a la anterior. El ciclo de vida iterativo e incremental es una de las buenas prcticas de ingeniera del software ms antiguas, su primer uso en el software se data en los 50 (pincha aqu, te dejo este post donde hablamos del tema) (P1.2). Adems, el ciclo de vida iterativo e incremental es una de las bases de un proyecto gil, ms concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente ms de dos. Normalmente se habla, se lee, etc., el ciclo de vida iterativo e incremental (o incluso por defecto slo el el ciclo de vida iterativo). Pero ello no quiere decir que iterativo e incremental sea lo mismo. De hecho, el desarrollo iterativo no implica, ni presupone el uso del incremental, y viceversa. El problema es que muchas veces se olvida la parte iterativa, del ciclo de vida iterativo e incremental. Pero veamos antes qu implica incremental y qu iterativo. El ciclo de vida incremental Desarrollar por partes el producto software, para despus integrarlas a medida que se completan. Un ejemplo de un desarrollo puramente incremental puede ser la agregacin de mdulos en diferentes fases. El agregar cada vez ms funcionalidad al sistema. El ciclo de vida iterativo En cada ciclo, iteracin, se revisa y mejora el producto. Un ejemplo de desarrollo iterativo es aquel basado en refactorizaciones (te dejo el post de introduccin a la refactorizacin), en el que cada ciclo mejora ms la calidad del producto. Es importante sealar que este ciclo no implica aadir funcionalidades en el producto, pero si revisin y mejora. No olvides la parte iterativa, del ciclo de vida iterativo e incremental De la unin del ciclo de vida iterativo y el incremental al final de cada iteracin se consigue una versin ms estable del software, de ms calidad, y aadiendo adems nuevas funcionalidades respecto a versiones anteriores. Pero en la prctica, muchas veces nos encontramos con que los equipos olvidan la parte iterativa, olvidan que cada prototipo debe mejorar en calidad al anterior, y se centran solo en aadir funcionalidad. El problema de esto es que pasadas unas cuantas iteraciones, el producto se hace inmantenible, por su baja calidad, y por ello es muy difcil aadir nueva funcionalidad, alargndose las iteraciones, los ciclos, y muriendo la esencia de todo esto.

P1.2 Veterano ciclo de vida iterativo e incremental


El motivo de este post viene a raz de una reunin en la que se debata el mejor ciclo de vida para un proyecto, y en la que alguien dijo: el ciclo de vida iterativo e incremental es un riesgo ya que es algo nuevo, y no hay mucha experiencia. Y como esto de que el ciclo de vida iterativo e incremental es nuevo ya lo haba escuchado muchas veces, me dije, voy a dejar en el blog testimonio escrito de la longevidad de dicho ciclo de vida, as hago mi pequea contribucin en google a evitar que quieran seguir hacindole liftings. Un ciclo de vida iterativo e incremental es aquel en que se va liberando parte del producto peridicamente, iterativamente, poco a poco, y cada entrega es un incremento respecto a la anterior; cada fase (requisitos, anlisis, diseo, etc.) se realiza varias veces. Lo cual difiere del desarrollo en cascada, donde las fases del ciclo de vida (requisitos, anlisis, diseo, etc.) se realizan (en teora) una nica vez, y el inicio de una fase no comienza hasta que termina la fase que le precede. Con la creciente popularidad de los mtodos giles en muchas ocasiones se cree que el ciclo de vida iterativo e incremental es una prctica moderna, nueva frente al antiguo ciclo de vida en cascada, pero su aplicacin data de mitad de los aos 50, y desde entonces ha sido ampliamente usado y se ha escrito mucho sobre l. En 1950 la construccin del avin cohete X-15 supuso un hito en la aplicacin del ciclo de vida iterativo e incremental, hasta el punto de que dicho ciclo de vida supuso una de las principales contribuciones al xito del proyecto. Aunque el proyecto X-15 no era un proyecto esencialmente de software, es importante mencionarlo porque algunos de los participantes en el mismo (con su correspondiente experiencia en dicho ciclo de vida) comenzaron a utilizarlo en la NASA en 1960 para el desarrollo software, en un proyecto llamado Mercury, del que a su vez algunos participantes en el mismo trabajaran despus en IBM Federal Systems Division, donde tambin se aplic el ciclo de vida iterativo en incremental al desarrollo software. El proyecto Mercury (1960) trabaj con iteraciones diarias, aplic revisiones tcnicas a los cambios, y aplic la tcnica de planificar y escribir las pruebas antes de cada micro incremento (a alguien le recuerda esto a Extreme Programming?) La primera referencia documental que describe y recomienda el desarrollo iterativo es de 1968, un informe de Brian Randell and F.W. Zurcher que trabajaban en el IBM T.J. Watson Research Center, y que se puede encontrar aqu. Pues eso, ante todo veterano, el ciclo de vida iterativo e incremental.

Sobre estos dos ciclos de vida te dejo un artculo de Cockburn especialmente aclaratorio.

Incremental versus iterative development


Ive noticed people lately yet again getting wrapped around the axle of incremental development versus iterative development. RUP and the OMG didnt help matters any by calling everything iterations and iterative development. Theyre different, have to be managed differently, have to be thought of differently. It happens that most project teams do both at the same time, usually without thinking about it. Then someone starts thinking about it, gets clever, and does one without the other. Bad things ensue.

Incremental development defined


By incremental development, I specifically mean a staging and scheduling strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed. It neither implies, requires nor precludes iterative development or waterfall development both of those are rework strategies. The alternative to incremental development is to develop the entire system with a big bang integration. Incremental development helps you improve your process. Each time around the process, you get to change and improve your work habits.

Iterative development defined


By iterative development, I specifically wish to mean a rework scheduling strategy in which time is set aside to revise and improve parts of the system. It does not presuppose incremental development, but works very well with it. As shown in the figures, the difference is that an increment may actually ship, whereas an iteration is examined for modification. Iterative development helps you improve your product. Each time around the process you get to change and improve the product itself (and maybe some of your work habits) These definitions were written back in 1992, when they were still separate terms and people wanted to know their meanings. Then, as above, RUP and the OMG people mushed the two together and weve been having trouble ever since. Those definitions are still pretty good, 15 years later. Sit on them, hatch them, think about what it means to do them separately and together. Think about how your project strategies might vary as you needed to manage more of one, and then more of the other. Good things should happen inside your brain.

10

How did we go wrong?


Back in 1992, we were still fighting waterfall development (as if we arent still today!). I came in from the outside, into application development from IBM Research, and was told to investigate modern (1990s style) software development. I noticed these two things, asked people what they meant by them, and wrote down those definitions. What I noticed, and you will of course notice, is that in waterfall development, you do requirements only once; then you do design only once; then you do programming only once (ha! ha! fooled you of course you do the programming over and over and over, but dont tell your PM that!); you test only once (ha! ha! of course not! but thats the theory); you integrate only once; you deliver only once (that part may be true). in incremental development, you do each of those activities multiple times that is, you go around the requirements design programming testing integration delivery cycle multiple times. You iterate through that cycle multiple times. (iterate get it? sigh) in iterative development, you also do each of those activities multiple times you go around the requirements design programming testing integration delivery cycle multiple times. You iterate through that cycle multiple times. By Gummy! Both of those are iterative development! Of course, the $200,000 question is, do you repeat the cycle on the same part of the system you just got done with or on a new part of the system???

How you answer that question yields very different results on what happens next on your project. I have always kept them separate, with good results. What stunned me, back in around 1994, was that the pundits and authors at the time seem to have gotten so excited at the thought of repeating the cycle at all that they lumped the two together and never saw the difference in what happened on the project based on whether you were revising old stuff or getting onto new stuff! Indeed I did, and so did a lot of projects. I visited a 200-person project team, where, as one manager put it when he finally saw the difference, Were iterating when we should be incrementing!! You can imagine the feeling of helplessness on that project as the developers saw the same requirements coming at them over and over again in slightly different forms, and no plan for making progress through the requirements set. At that time, the lesson was: be sure to increment; yes you will iterate anyway. More recently, on XP/agile projects, we see them incrementing like wildfire, but never putting time into the schedule to iterate (see the article ). Now the quality suffers. Note Iterative development was a particularly bad choice of words, and remains a troublesome phrase. Any sponsor hearing, Were going to do iterative development immediately hears, Were going to do a lot of rework! (Ouch, my wallet!) At least with incremental development they get to think, Were going to do step-wise growth. Their funding reflexes twitch differently (much more scared ((and rightfully so)) with iterative). Remember, Incremental fundamentally means add onto. Incremental development helps you improve your process. Iterative fundamentally means re-do. Iterative development helps you improve your product. Both need improvement. Create your staging, integration and rework strategies accordingly.

11

1.4-El proyecto gil

Comentaba Ambler 5, que un proyecto gil se podra definir como una manera de enfocar el desarrollo software mediante un ciclo iterativo e incremental, con equipos que trabajan de manera altamente colaborativa y autoorganizados. Es decir, un proyecto gil es un desarrollo iterativo ms la segunda gran caracterstica implicada directamente por la iteracin extrema: equipos colaborativos y autoorganizados. A diferencia de ciclos de vida iterativos e incrementales ms relajados, en un proyecto gil cada iteracin no es un mini cascada. Esto no es as, porque el objetivo de acortar al mximo las iteraciones (normalmente entre 1 y 4 semanas) lo hace casi imposible. Cuanto menor es el tiempo de iteracin ms se solapan las tareas. Hasta el punto que implicar que de manera no secuencial, muchas veces solapada, y repetitivamente, durante una iteracin se est casi a la vez diseando, programando y probando. Lo que implicar mxima colaboracin e interaccin de los miembros del equipo. Implicar equipos multidisciplinares, es decir, que no hay roles que slo diseen o programen todos pueden disear y programar. E implica auto-organizacin, es decir, que en la mayora de los proyectos giles no hay, por ejemplo, un nico jefe de proyecto responsable de asignar tareas. Frente a un ciclo de vida en cascada, o frente a un ciclo iterativo de iteraciones largas compuestas por pequeas cascadas, en un ciclo de vida gil:

Ambler, S. (2008). Acceleration: An agile productivity measure.

12

El diseo en el desarrollo y las pruebas se realizan de manera continua. En un ciclo de vida en cascada se realizan de manera secuencial. Las personas que integran un equipo de desarrollo realizarn diferentes tareas. No existen equipos o roles especializados, que sin embargo s existan en el ciclo de vida en cascada.

La duracin de una iteracin es fija, incluso si no se han podido desarrollar todas las actividades planificadas para la misma. En cambio en los ciclos de vida en cascada generalmente se supera el tiempo planificado.

Un proyecto gil lleva la iteracin al extremo: 1. Se busca dividir las tareas del proyecto software en incrementos con una planificacin mnima y de una corta duracin (segn la metodologa gil, tpicamente entre 1 y 4 semanas). 2. Cada iteracin suele concluir con un prototipo operativo. Al final de cada incremento se obtiene un producto entregable que es revisado junto con el cliente, posibilitando la aparicin de nuevos requisitos o la perfeccin de los existentes, reduciendo riesgos globales y permitiendo la adaptacin rpida a los cambios. Normalmente un proceso gil se basa en un ciclo de vida iterativo e incremental pero no todo proceso iterativo e incremental es un proceso gil. Adems, estn la colaboracin y los equipos auto organizados, entonces, qu caracteriza un proyecto gil? en el siguiente captulo veremos que derivado de todo lo anterior se debe cumplir adems otros valores y principios.

13

1.5-El Manifiesto gil


El 12 de febrero de 2001,17 destacados y conocidos profesionales de la ingeniera del software escriban en Utah el Manifiesto gil. Entre ellos estaban los creadores de algunas de las metodologas 6 giles ms conocidas en la actualidad: XP, Scrum, DSDM, Crystal, etc. Su objetivo fue establecer los valores y principios que permitiran a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas. De esta forma se establecieron cuatro valores giles: Valorar a los individuos y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. Se tendrn en cuenta las buenas prcticas de desarrollo y gestin de los participantes del proyecto (siempre dentro del marco de la metodologa elegida). Esto facilita el trabajo en equipo y disminuir los impedimentos para que realicen su trabajo. Asimismo compromete al equipo de desarrollo y a los individuos que lo componen. Desarrollar software que funciona ms que conseguir una documentacin exhaustiva. No es necesario producir documentos a menos que sean necesarios de forma inmediata para tomar una decisin importante. Los documentos deben ser cortos y centrarse en lo fundamental. La variacin de la cantidad y tipo de documentacin puede ser amplia dependiendo el tipo de cliente o de proyecto. El hecho de decir que la documentacin es el cdigo fuente y seguir esa idea sin flexibilidad puede originar un caos. El problema no es la documentacin sino su utilidad. La colaboracin con el cliente ms que la negociacin de un contrato. Es necesaria una interaccin constante entre el cliente y el equipo de desarrollo. De esta colaboracin depende el xito del proyecto. Este es uno de los puntos ms complicados de llevar a cabo, debido a que muchas veces el cliente no est disponible. En ese caso desde dentro de la empresa existir una persona que represente al cliente, haciendo de interlocutor y participando en las reuniones del equipo. Responder a los cambios ms que seguir estrictamente un plan. Pasamos de la anticipacin y la planificacin estricta sin poder volver hacia atrs a la adaptacin. La flexibilidad no es total, pero existen muchos puntos (todos ellos controlados) donde se pueden adaptar las actividades.

El trmino metodologa es utilizado de manera coloquial, siendo rigurosos las metodologas son ms bien marcos de trabajo o frameworks

14

LO QUE NO DICE
Ausencia total de documentacin. Ausencia total de planificacin: planificar y ser flexible es diferente a improvisar. El cliente debe hacer todo el trabajo y ser el Jefe de Proyecto. El equipo puede modificar la metodologa sin justificacin. De estos cuatro valores surgen los doce principios del manifiesto. Estos principios son caractersticas que diferencian un proceso gil de uno tradicional. Los principios son los siguientes: 1. La prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software que le aporten valor. 2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. 7. El software que funciona es la medida fundamental de progreso. 8. Los procesos giles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberan ser capaces de mantener una paz constante. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. 12. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

15

A modo de resumen, esta son las principales diferencias entre las metodologas giles y tradicionales:

16

1.6-Unin los modelos de procesos y metodologas giles

En ocasiones existe la percepcin de que es incompatible unir modelos como CMMI o ISO/IEC 15504 ISO/IEC 12207 con metodologas giles. Sin embargo, esta concepcin no es correcta, ya que los modelos y las metodologas se encuentran en distintos niveles de abstraccin. Los modelos de procesos establecen qu es lo que espera encontrarse en los procesos, pero son las metodologas las que indicarn cmo deben realizarse. Es por esto que el uso de modelos de procesos y metodologas giles no debe considerarse un aspecto contradictorio si no complementario.

17

1.7-Enlaces y lecturas recomendadas


1. Gestin gil de Proyectos Software. Javier Garzs, Juan Enrquez de S, Emanuel Irrazbal

2. 3. 4. 5. 6. 7. 8. 9.

Video muy interesante y dinmico de la reunin en el Dcimo Aniversario del Manifiesto gil Desarrollo gil o tradicional: existe el punto intermedio? Una metodologa por cada proyecto Ciclo de vida iterativo e incremental Manifiesto gil CMMI o Mtodos giles? Guia Prctica de Supervivencia en una Auditora CMMI Procesos software

18

You might also like