La Nueva Metodología

Varias metodolog�as encajan bajo el estandarte de �gil. Mientras todas ellas comparten muchas caracter�sticas, tambi�n hay algunas diferencias significativas. No puedo resaltar todos los puntos en este estudio breve, pero por lo menos puedo apuntar a algunos lugares donde buscar. Tampoco puedo hablar con experiencia significativa sobre la mayor�a de ellas. He trabajado bastante en XP, y he visto el RUP en muchas capas, pero para la mayor�a de los otros mi conocimiento no es el m�s adecuado.

.�XP (Programaci�n Extrema)

De todas las metodolog�as �giles, �sta es la que ha recibido m�s atenci�n. Esto se debe en parte a la notable habilidad de los l�deres XP, en particular Kent Beck, para llamar la atenci�n. Tambi�n se debe a la habilidad de Kent Beck de atraer a las personas a este acercamiento, y tomar un papel principal en �l. De algunas maneras, sin embargo, la popularidad de XP se ha vuelto un problema, pues ha acaparado la atenci�n fuera de las otras metodolog�as y sus valiosas ideas.

Las ra�ces de la XP yacen en la comunidad de Smalltalk, y en particular la colaboraci�n cercana de Kent Beck y Ward Cunningham a finales de los 1980s. Ambos refinaron sus pr�cticas en numerosos proyectos a principios de los 90s, extendiendo sus ideas de un desarrollo de software adaptable y orientado a la gente.

El paso crucial de la pr�ctica informal a una metodolog�a ocurri� en la primavera de 1996. A Kent se le pidi� revisar el progreso del proyecto de n�mina C3 para Chrysler. El proyecto estaba siendo llevado en Smalltalk por una compa��a contratista, y estaba en problemas. Debido a la baja calidad de la base del c�digo, Kent recomend� tirar la base del c�digo en su totalidad y empezar desde el principio. El proyecto entonces reinici� bajo su direcci�n y subsecuentemente se volvi� el buque insignia temprano y el campo de entrenamiento de la XP.

La primera fase del C3 fue muy exitosa y comenz� a principios de 1997. El proyecto continu� desde entonces y despu�s se encontr� con dificultades, lo que result� en la cancelaci�n del desarrollo en 1999. (Lo cual prueba, si ninguna otra cosa, que la XP no es garant�a de �xito.)

La XP empieza con cuatro valores: Comunicaci�n, Retroalimentaci�n, Simplicidad y Coraje. Construye sobre ellos una docena de pr�cticas que los proyectos XP deben seguir. Muchas de estas pr�cticas son t�cnicas antiguas, tratadas y probadas, aunque a menudo olvidadas por muchos, incluyendo la mayor�a de los procesos planeados. Adem�s de resucitar estas t�cnicas, la XP las teje en un todo sin�rgico d�nde cada una refuerza a las dem�s.

Una de las m�s llamativas, as� como inicialmente atractiva para m�, es su fuerte �nfasis en las pruebas. Mientras todos los procesos mencionan la comprobaci�n, la mayor�a lo hace con muy poco �nfasis. Sin embargo la XP pone la comprobaci�n como el fundamento del desarrollo, con cada programador escribiendo pruebas cuando escriben su c�digo de producci�n. Las pruebas se integran en el proceso de integraci�n continua y construcci�n lo que rinde una plataforma altamente estable para el desarrollo futuro.

En esta plataforma XP construye un proceso de dise�o evolutivo que se basa en refactorizar un sistema simple en cada iteraci�n. Todo el dise�o se centra en la iteraci�n actual y no se hace nada anticipadamente para necesidades futuras. El resultado es un proceso de dise�o disciplinado, lo que es m�s, combina la disciplina con la adaptabilidad de una manera que indiscutiblemente la hace la m�s desarrollada de entre todas las metodolog�as adaptables.

XP ha desarrollado un liderazgo amplio, muchos de ellos provenientes del proyecto fundamental C3. Como resultado hay muchas fuentes para m�s informaci�n. Kent Beck escribi� Extreme Programming Explained, el manifiesto clave de la XP que explica las razones detr�s de la metodolog�a y bastante explicaci�n como para que la gente pueda saber si se interesan en seguirla. En el �ltimo par de a�os ha habido una epidemia de libros sobre XP brillantemente coloreados la mayor�a de los cuales son bastante similares en que describen el proceso entero desde el punto de vista de varios seguidores tempranos.

As� como los libros, hay un n�mero considerable de recursos en la web. Para encontrar un acercamiento m�s estructurado a la XP, es mejor empezar con dos sitios de ex alumnos del C3: Ron Jeffries xProgramming.com y Don Wells extremeProgramming.org. Mucha de la promoci�n temprana y desarrollo de ideas de la XP ocurrieron en el ambiente de escritura colaborativa en la p�gina wiki de Ward Cunningham. El wiki sigue siendo un lugar fascinante para descubrir, aunque su naturaleza divagante lo absorbe a uno. Hay un activo y a menudo interesante grupo de discusi�n XP. Una de las vistas externas m�s interesantes sobre la XP es la de Mark Paulk que es uno de los l�deres de la comunidad CMM - su art�culo mira a la XP desde la perspectiva del CMM.

[Tambi�n hay referencias en espa�ol, como el sitio donde se hospeda originalmente esta traducci�n, que es tambi�n wiki http://www.programacionextrema.org/ y un grupo de discusi�n en yahoo. N. del T.]

.�La Familia de Cristal de Cockburn

Alistair Cockburn ha estado trabajando en metodolog�as desde que la IBM le encarg� escribir sobre metodolog�as a inicios de los 90. No obstante, su acercamiento no es como la mayor�a de los metodologistas. En lugar de partir solamente de su experiencia personal para construir una teor�a de c�mo deben hacerse las cosas, �l complementa su experiencia directa con la b�squeda activa de proyectos y ver c�mo trabajan. Adem�s �l no teme alterar sus puntos de vista con base en sus descubrimientos: todo lo cual lo hace mi metodologista favorito.

Su libro, Sobreviviendo Proyectos Orientados a Objetos, fue su primer consejo en proyectos corrientes, y sigue siendo mi primera recomendaci�n de libro para ejecutar proyectos iterativos. M�s recientemente Alistair escribi� un libro de apreciaci�n de desarrollo de software �gil que mira los principios subyacentes de este tipo de metodolog�as.

Desde ese libro �l ha explorado m�s los m�todos �giles, viniendo con la familia de metodolog�as Crystal. Es una familia porque �l cree que los tipos diferentes de proyectos requieren tipos diferentes de metodolog�as. �l mira esta variaci�n a lo largo de dos ejes: el n�mero de personas en el proyecto, y las consecuencias de los errores. Cada metodolog�a encaja en una parte diferente de la reja, de modo que para un proyecto de 40 personas que puede perder dinero discrecionalmente tiene una metodolog�a diferente a la de un proyecto vital de seis personas.

Cristal comparte con la XP una orientaci�n humana, pero esta centralizaci�n en la gente se hace de una manera diferente. Alistair considera que las personas encuentran dif�cil seguir un proceso disciplinado, as� que m�s que seguir la alta disciplina de la XP, Alistair explora la metodolog�a menos disciplinada que aun podr�a tener �xito, intercambiando conscientemente productividad por facilidad de ejecuci�n. �l considera que aunque Cristal es menos productivo que la XP, m�s personas ser�n capaces de seguirlo.

Alistair tambi�n pone mucho peso en las revisiones al final de la iteraci�n, animando al proceso a ser auto mejorante. Su aserci�n es que el desarrollo iterativo est� para encontrar los problemas temprano, y entonces permitir corregirlos. Esto pone m�s �nfasis en la gente supervisando su proceso y afin�ndolo conforme desarrollan.

.�C�digo Abierto

A usted podr�a sorprenderle este t�tulo. Despu�s de todo el c�digo abierto es un estilo de software, no tanto un proceso. Sin embargo hay una manera definida de hacer las cosas en la comunidad de c�digo abierto, y mucho de su acercamiento es tan aplicable a los proyectos de c�digo cerrado como a los de c�digo abierto. En particular su proceso engrana equipos f�sicamente distribuidos, lo que es importante porque la mayor�a de los procesos adaptables exigen equipos locales.

La mayor�a de los proyectos de c�digo abierto tienen uno o m�s mantenedores. Un mantenedor es la �nica persona a la que se le permite integrar un cambio en el almac�n de c�digo fuente. Sin embargo otras personas pueden hacer cambios a la base del c�digo. La diferencia importante es que estas otras personas necesitan enviar su cambio al mantenedor que entonces lo revisa y lo aplica a la base del c�digo. Normalmente estos cambios son hechos en forma de archivos de parches que hacen este proceso m�s f�cil. As�, el mantenedor es responsable de coordinar los parches y mantener la cohesi�n en el dise�o del software.

Proyectos diferentes manejan el papel del mantenedor de diferentes maneras. Algunos tienen un mantenedor para el proyecto entero, algunos lo dividen en m�dulos y tiene un mantenedor por m�dulo, algunos rolan el mantenedor, algunos tienen m�ltiples mantenedores sobre el mismo c�digo, otros tienen una combinaci�n de estas ideas. La mayor parte de la gente de c�digo abierto son de tiempo parcial, as� que hay una duda en qu� tan bien se coordina un equipo as� para un proyecto de tiempo completo.

Un rasgo particular del desarrollo de c�digo abierto es que la depuraci�n es altamente paralelizable. Muchas personas pueden involucrarse en el depurado. Cuando encuentran un defecto pueden enviar el parche al mantenedor. Esto es un buen papel para los no mantenedores ya que la mayor parte del tiempo se gasta en encontrar bugs. Tambi�n es bueno para gente sin mucha destreza en programaci�n.

El proceso para el c�digo abierto aun no se ha documentado bien. La referencia m�s famosa es el art�culo de Eric Raymond La catedral y el bazar, que aunque es una descripci�n excelente tambi�n es bastante informal. El libro de Karl Fogel sobre el almac�n de c�digo CVS tambi�n contiene varios buenos cap�tulos sobre el proceso de c�digo abierto que incluso ser�an interesantes para aqu�llos que no quieren usar el cvs.

.�El Desarrollo de Software Adaptable de Highsmith

Jim Highsmith ha pasado muchos a�os trabajando con metodolog�as predictivas. �l las desarroll�, instal�, ense��, y concluy� que son profundamente defectuosas: particularmente para los negocios modernos.

Su reciente libro se enfoca en la naturaleza adaptable de las nuevas metodolog�as, con un �nfasis particular en aplicar las ideas que se originaron en el mundo de los sistemas complejos adaptables (normalmente conocida como teor�a del caos). No proporciona el tipo de pr�cticas detalladas como lo hace la XP, pero proporciona la base fundamental de por qu� el desarrollo adaptable es importante y las consecuencias a los m�s profundos niveles de la organizaci�n y la gerencia.

En el coraz�n del ASD hay tres fases solapadas, no lineales: especulaci�n, colaboraci�n, y aprendizaje.

Highsmith ve la planificaci�n como una paradoja en un ambiente adaptable, ya que los resultados son naturalmente imprevisibles. En la planificaci�n tradicional, las desviaciones del plan son errores que deben corregirse. En un ambiente adaptable, en cambio, las desviaciones nos gu�an hacia la soluci�n correcta.

En este ambiente imprevisible se necesita que las personas colaboren de la mejor manera para tratar con la incertidumbre. La atenci�n de la gerencia es menor en lo que tiene que hacer la gente, y mayor sobre la comunicaci�n alentadora para que las personas puedan proponer las respuestas creativas ellos mismos.

En ambientes predictivos, el aprendizaje se desalienta a menudo. Las cosas se ponen de antemano y entonces se sigue ese dise�o.

En un ambiente adaptable, aprender desaf�a a todos - desarrolladores y sus clientes - a examinar sus presunciones y usar los resultados de cada ciclo de desarrollo para adaptar el siguiente.
[Highsmith]

El aprendizaje como tal es un rasgo continuo e importante, que asume que los planes y los dise�os deben cambiar conforme avanza el desarrollo.

El beneficio atropellado, poderoso, indivisible y predominante del Ciclo de Vida de Desarrollo Adaptable es que nos obliga a confrontar los modelos mentales que est�n en la ra�z de nuestro autoenga�o. Nos obliga a estimar con realismo nuestra habilidad.
[Highsmith]

Con este �nfasis, el trabajo de Highsmith se enfoca directamente en fomentar las partes dif�ciles del desarrollo adaptable, en particular c�mo fomentar la colaboraci�n y el aprendizaje dentro del proyecto. Como tal su libro ayuda a dar ideas para fomentar estas �reas "suaves" que hacen un buen complemento a los acercamientos basados en una pr�ctica aterrizada como XP, FDD y Cristal.

.�Scrum

Scrum ha estado durante alg�n tiempo en los c�rculos orientados a objetos, aunque confesar� que yo no estoy muy al tanto de su historia o desarrollo. De nuevo se enfoca en el hecho de que procesos definidos y repetibles s�lo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles.

Scrum divide un proyecto en iteraciones (que ellos llaman carreras cortas) de 30 d�as. Antes de que comience una carrera se define la funcionalidad requerida para esa carrera y entonces se deja al equipo para que la entregue. El punto es estabilizar los requisitos durante la carrera.

Sin embargo la gerencia no se desentiende durante la carrera corta. Todos los d�as el equipo sostiene una junta corta (quince minutos), llamada scrum, d�nde el equipo discurre lo que har� al d�a siguiente. En particular muestran a los bloques de la gerencia: los impedimentos para progresar que se atraviesan y que la gerencia debe resolver. Tambi�n informan lo que se ha hecho para que la gerencia tenga una actualizaci�n diaria de d�nde va el proyecto.

La literatura de Scrum se enfoca principalmente en la planeaci�n iterativa y el seguimiento del proceso. Es muy cercana a las otras metodolog�as �giles en muchos aspectos y debe funcionar bien con las pr�cticas de c�digo de la XP.

Despu�s de mucho tiempo sin un libro, finalmente Ken Schwaber y Mike Beedle escribieron el primer libro de scrum. Ken Schwaber tambi�n aloja controlChaos.com qu� probablemente es la mejor apreciaci�n global sobre SCRUM. Jeff Sutherland siempre ha tenido un sitio web activo sobre temas de tecnolog�as de objetos e incluye una secci�n sobre CRUM. Hay tambi�n una buena apreciaci�n global de las pr�cticas de Scrum en el libro PLoPD 4. Scrum tiene una lista de discusi�n en Yahoo.

.�Desarrollo Manejado por Rasgos

El Desarrollo Manejado por Rasgos (FDD por sus siglas en ingl�s) fue desarrollado por Jeff De Luca y el viejo gur� de la OO Peter Coad. Como las otras metodolog�as adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. En el caso del FDD las iteraciones duran dos semanas.

El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.

  • Desarrollar un Modelo Global
  • Construir una Lista de los Rasgos
  • Planear por Rasgo
  • Dise�ar por Rasgo
  • Construir por Rasgo

Los �ltimos dos se hacen en cada iteraci�n. Cada proceso se divide en tareas y se da un criterio de comprobaci�n.

Los desarrolladores entran en dos tipos: due�os de clases y programadores jefe. Los programadores jefe son los desarrolladores m�s experimentados. A ellos se les asignan rasgos a construir. Sin embargo ellos no los construyen solos. Solo identifican qu� clases se involucran en la implantaci�n de un rasgo y juntan a los due�os de dichas clases para que formen un equipo para desarrollar ese rasgo. El programador jefe act�a como el coordinador, dise�ador l�der y mentor mientras los due�os de clases hacen gran parte de la codificaci�n del rasgo.

Hasta recientemente, la documentaci�n sobre FDD era muy escasa. Finalmente hay un libro completo sobre FDD. Jeff De Luca, el inventor primario, ya tiene un portal FDD con art�culos, blogs y foros de discusi�n. La descripci�n original estaba en el libro UML in Color de Peter Coad et al. Su compa��a, TogetherSoft, tambi�n da consultor�a y entrenamiento en FDD.

.�DSDM (M�todo de Desarrollo de Sistema Din�mico)

El DSDM empez� en Gran Breta�a en 1994 como un consorcio de compa��as del Reino Unido que quer�an construir sobre RAD [N. del T. Desarrollo R�pido de Aplicaciones] y desarrollo iterativo. Habiendo empezado con 17 fundadores ahora tiene m�s de mil miembros y ha crecido fuera de sus ra�ces brit�nicas. Siendo desarrollado por un consorcio, tiene un sabor diferente a muchos de los otros m�todos �giles. Tiene una organizaci�n de tiempo completo que lo apoya con manuales, cursos de entrenamiento, programas de certificaci�n y dem�s. Tambi�n lleva una etiqueta de precio, lo qu� ha limitado mi investigaci�n sobre su metodolog�a. Sin embargo Jennifer Stapleton ha escrito un libro que da una apreciaci�n global de la metodolog�a.

El m�todo empieza con un estudio de viabilidad y negocio. El estudio de viabilidad considera si DSDM es apropiado para el proyecto. El estudio de negocio es una serie corta de talleres para entender el �rea de negocio d�nde tiene lugar el desarrollo. Tambi�n propone arquitecturas de esbozos del sistema y un plan del proyecto.

El resto del proceso forma tres ciclos entretejidos: el ciclo del modelo funcional produce documentaci�n de an�lisis y prototipos, el ciclo de dise�o del modelo dise�a el sistema para uso operacional, y el ciclo de implantaci�n se ocupa del despliegue al uso operacional.

DSDM tiene principios subyacentes que incluyen una interacci�n activa del usuario, entregas frecuentes, equipos autorizados, pruebas a lo largo del ciclo. Como otros m�todos �giles usan ciclos de plazos cortos de entre dos y seis semanas. Hay un �nfasis en la alta calidad y adaptabilidad hacia requisitos cambiantes.

No he visto mucha evidencia de su uso fuera del Reino Unido, pero DSDM es notable por tener mucha de la infraestructura de las metodolog�as tradicionales m�s maduras, al mismo tiempo que sigue los principios de los m�todos �giles. Parece haber una pregunta en si sus materiales animan m�s de una orientaci�n al proceso y m�s ceremonia de lo que me gustar�a.

.�Manifiesto para el Desarrollo de Software �gil

Con tanta similitud entre estos m�todos, ser�a justo un poco de inter�s en alguna forma de trabajo colaborativo. Los representantes de cada una de estas metodolog�as fueron invitados a un taller de dos d�as en Snowbird, Utah en febrero de 2001. Yo asist� sin muchas expectativas. Despu�s de todo cuando se pone un manojo de metodologistas en la misma habitaci�n, lo mejor que se puede esperar es algo de civismo.

Lo que result� me sorprendi�. Todos est�bamos conscientes del hecho de que hab�a mucho en com�n, y este reconocimiento era mucho mayor que las diferencias entre los procesos. Adem�s de un contacto �til entre los l�deres de procesos, hab�a tambi�n la idea de emitir una declaraci�n conjunta - una llamada a las armas en favor de m�s procesos de software �giles. (Tambi�n est�bamos de acuerdo en usar el t�rmino "�gil" para referirnos a nuestras ideas com�nes.)

El resultado es un Manifiesto para el Desarrollo de Software �gil, una declaraci�n de los principios y valores comunes de los procesos �giles. Hay tambi�n un deseo de colaborar m�s en el futuro, para animar m�s tanto a tecn�logos como a gente de negocios para usar y requerir acercamientos �giles al desarrollo de software. Hay un art�culo en una revista de desarrollo de software que es un comentario y una explicaci�n del manifiesto.

El manifiesto fue s�lo eso, una publicaci�n que actu� como un punto de partida para aquellos que compart�an estas ideas b�sicas. Uno de los frutos del esfuerzo fue la creaci�n de un cuerpo m�s longevo, la Alianza Agil. La Alianza Agil es una organizaci�n sin fines de lucro que busca promover el conocimiento y la discusi�n de todos los m�todos �giles. Muchos l�deres agilistas que he mencionado aqu� son miembros y l�deres de la Alianza �gil.

.�Comprobaci�n Dirigida por el Contexto

Desde el principio han sido los desarrolladores de software quienes han conducido a la comunidad �gil. Sin embargo muchas otras personas envueltas en el desarrollo de software son afectadas por este nuevo movimiento. Un grupo obvio es el de los verificadores que a menudo viven en un mundo dominado por el pensamiento de cascada. Con pautas com�nes que declaran que el papel de la comprobaci�n es asegurar la conformidad del software con las especificaciones escritas de antemano, el papel de los verificadores en el mundo �gil esta lejos de ser claro.

En lo que esto se aclara, varias personas en la comunidad de verificadores han estado cuestionando mucho de la corriente principal del pensamiento en comprobaci�n desde hace un tiempo. Esto ha llevado a un grupo conocido como la comprobaci�n conducida por el contexto. La mejor descripci�n es el libro Lecciones aprendidas en Comprobaci�n de Software. Esta comunidad es tambi�n muy activa en la web, eche una mirada a sitios organizados por Brian Marick (uno de los autores del manifiesto �gil), Brett Pettichord, James Bach, y Cem Kaner.

.��Es RUP un m�todo �gil?

Siempre que empezamos discutiendo m�todos en la arena OO, inevitablemente salimos con el papel del Rational Unified Process. El Proceso Unificado fue desarrollado por Philippe Kruchten, Ivar Jacobson y otros de la Rational como el proceso complementario al UML. El RUP es un armaz�n de proceso y como tal puede acomodar una gran variedad de procesos. De hecho �sta es mi cr�tica principal al RUP - como puede ser cualquier cosa acaba siendo nada. Yo prefiero un proceso que dice qu� hacer en lugar de dar opciones infinitas.

Como resultado de esta mentalidad de armaz�n de procesos, el RUP puede usarse en un estilo muy tradicional de cascada o de una manera �gil. Como resultado usted puede usar el RUP como un proceso �gil, o como un proceso pesado - todo depende de c�mo lo adapte a su ambiente.

Craig Larman es un fuerte defensor de usar el RUP de una manera �gil. Su excelente libro introductorio sobre desarrollo OO contiene un proceso que est� muy basado en su pensamiento ligero del RUP. Su visi�n es que mucho del reciente empuj�n hacia los m�todos �giles no es nada m�s que aceptar desarrollo OO de la corriente principal que ha sido capturada como RUP. Una de las cosas que hace Craig es pasarse los primeros dos o tres d�as de una iteraci�n mensual con todo el equipo usando el UML para perfilar el dise�o del trabajo a hacerse durante la iteraci�n. Esto no es un cianotipo del que no pueda desviarse, sino un boceto que da una perspectiva sobre c�mo pueden hacerse las cosas en la iteraci�n.

Otra tachuela en el RUP �gil es el proceso dX de Robert Martin. El proceso dX es una versi�n totalmente d�cil del RUP que simplemente es id�ntico a la XP (girar dX ciento ochenta grados para ver la broma). El dX est� dise�ado para gente que tiene que usar el RUP pero quiere usar XP. Como tal es a la vez XP y RUP y por tanto un buen ejemplo del uso �gil del RUP.

Para m�, una de las cosas clave que necesita el RUP es que los l�deres del RUP en la industria enfaticen su acercamiento al desarrollo de software. M�s de una vez he o�do a la gente que usa el RUP que est�n usando un proceso de desarrollo estilo cascada. Gracias a mis contactos en la industria, s� que Philippe Kruchten y su equipo son firmes creyentes en el desarrollo iterativo. Clarificando estos principios y animando las versiones �giles del RUP tales como los trabajos de Craig y de Robert tendr� un efecto importante.

.�Otras Fuentes

Recientemente hemos visto aparecer dos buenos libros qu� miran al amplio tema de los m�todos �giles de Alistair Cockburn y Jim Highsmith.

Hay muchos otros art�culos y discusiones sobre este tema de los m�todos �giles. Mientras �stas pueden no ser metodolog�as completas, ofrecen luz sobre este campo creciente.

El congreso Patterns Language of Programming ha incluido a menudo material que menciona este asunto, tan solo porque muchos de los interesados en patrones tambi�n se interesan en los m�todos adaptables y humanos. Un art�culo temprano sobresaliente fue el de Jim Coplien en el PLoP1. El lenguaje de Episodios de Ward Cunningham apareci� el en PLoP2. Jim Coplein ahora mantiene el sitio OrgPatterns, un wiki que colecciona patrones organizacionales.

Dirk Riehle envi� un art�culo al XP2000 que compara los sistemas de valor de la XP y el Desarrollo de Software Adaptable. La edici�n de julio del Bolet�n de Coad compara la XP al FDD. La edici�n de julio de IEEE Software incluye varios art�culos sobre "diversidad de procesos" que alude a estas metodolog�as.

Mary Poppendieck escribi� un art�culo fascinante que compara las metodolog�as �giles con la fabricaci�n magra.

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
ARTÍCULO ANTERIOR