Texto original: The New Methodology
Traducción: Alejandro Sierra, marzo/abril de 2003.
Ultima actualización significativa: Abril 2003.
Desde hace unos pocos años ha habido un interés creciente en las metodologías ágiles (léase "livianas"). Caracterizadas alternativamente como antídoto a la burocracia o licencia para hackear han suscitado interés en el panorama del software. En este ensayo exploro las razones de los métodos ágiles, enfatizando no tanto su peso sino su naturaleza adaptativa y su orientación a la gente. También doy un resumen y referencias a los procesos en esta escuela y considero los factores que deberían influir en su decisión de seguir o no por esta nueva ruta.
Con mucho el desarrollo de software es una actividad caótica, frecuentemente caracterizada por la frase "codifica y corrige". El software se escribe con un mínimo un plan subyacente, y el diseño del sistema se adoquina con muchas decisiones a corto plazo. Esto realmente funciona muy bien si el sistema es pequeño, pero conforme el sistema crece llega a ser cada vez más difícil agregar nuevos aspectos al mismo. Además los bugs llegan a ser cada vez más frecuentes y más difíciles de corregir. La seña típica de tal sistema es una larga fase de pruebas después de que el sistema ha sido "completado". Tal fase larga de pruebas hace estragos con los planes de pruebas y depurado llegando a ser imposible de poner en el programa de trabajo.
Hemos vivido con este estilo de desarrollo por mucho tiempo, pero también hemos tenido una alternativa desde hace mucho: Metodología. Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería.
Las metodologías ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. Aún menos por su popularidad. La crítica más frecuente a estas metodologías es que son burocráticas. Hay tanto que hacer para seguir la metodología que el ritmo entero del desarrollo se retarda.
Como una reacción a estas metodologías, un nuevo grupo de metodologías ha surgido en los últimos años. Durante algún tiempo se conocían como las metodologías ligeras, pero el término aceptado ahora es metodologías ágiles. Para mucha gente el encanto de estas metodologías ágiles es su reacción a la burocracia de las metodologías monumentales. Estos nuevos métodos buscan un justo medio entre ningún proceso y demasiado proceso, proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena.
El resultado de todos esto es que los métodos ágiles cambian significativamente algunos de los énfasis de los métodos ingenieriles. La diferencia inmediata es que son menos orientados al documento, exigiendo una cantidad más pequeña de documentación para una tarea dada. En muchas maneras son más bien orientados al código: siguiendo un camino que dice que la parte importante de la documentación es el código fuente.
Sin embargo yo no creo que éste sea el punto importante sobre los métodos ágiles. La falta de documentación es un síntoma de diferencias mucho más profundas:
En las secciones siguientes exploraré estas diferencias más a detalle, para que usted pueda entender lo que es un proceso adaptable y centrado en la gente, sus beneficios y desventajas, y si es algo que debería usar: sea como desarrollador o como cliente de software.
La inspiración usual para las metodologías han sido disciplinas como las ingenierías civil o mecánica. Tales disciplinas enfatizan que hay que planear antes de construir. Los ingenieros trabajan sobre una serie de esquemas que indican precisamente qué hay que construir y como deben juntarse estas cosas. Muchas decisiones de diseño, como la manera de controlar la carga sobre un puente, se toman conforme los dibujos se producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una compañía diferente, para ser construidos. Se supone que el proceso de la construcción seguirá los dibujos. En la práctica los constructores se encuentran con algunos problemas, pero éstos son normalmente poco importantes.
Como los dibujos especifican las piezas y cómo deben unirse, actúan como los fundamentos de un plan de construcción detallado. Dicho plan define las tareas que necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un plan de trabajo y un presupuesto de construcción razonablemente predecibles. También dice en detalle cómo deben hacer su trabajo las personas que participan en la construcción. Esto permite que la construcción requiera menos pericia intelectual, aunque se necesita a menudo mucha habilidad manual.
Así que lo que vemos aquí son dos actividades fundamentalmente diferentes. El diseño, qué es difícil de predecir y requiere personal caro y creativo, y la construcción que es más fácil de predecir. Una vez que tenemos el diseño, podemos planear la construcción. Una vez que tenemos el plan de construcción, podemos ocuparnos de la construcción de una manera más predecible. En ingeniería civil la construcción es mucho más costosa y tardada que el diseño y la planeación.
Así el acercamiento de muchas metodologías es: queremos un plan de trabajo predecible que pueda usar gente del más bajo nivel. Para hacerlo debemos separar el plan de la construcción. Por consiguiente necesitamos entender cómo hacer el diseño de software de modo que la construcción pueda ser sencilla una vez que el plan esté hecho.
¿Qué forma toma este plan? Para muchos, éste es el papel de notaciones de diseño como el UML. Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construcción y entonces podemos dar planes a los programadores como una actividad de construcción.
Pero aquí surgen preguntas cruciales. ¿Es posible armar un plan que sea capaz de convertir el código en una actividad de construcción predecible? Y en tal caso, ¿es la construcción suficientemente grande en costo y tiempo para hacer valer la pena este enfoque?
Todos esto trae a la mente más preguntas. La primera es la cuestión de cuán difícil es conseguir un diseño UML en un estado que pueda entregarse a los programadores. El problema con un diseño tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programación. Los modelos que los ingenieros civiles usan está basado en muchos años de práctica guardados en códigos ingenieriles. Además los problemas importantes, como el modo en que juegan las fuerzas, son dóciles al análisis matemático. La única verificación que podemos hacer con los diagramas UML es la revisión cuidadosa. Mientras esto es útil trae errores al diseño que sólo se descubren durante la codificación y pruebas. Incluso los diseñadores experimentados, como me considero a mí mismo, nos sorprendemos a menudo cuando convertimos dichos diseños en software.
Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construcción. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. McConnell sugiere que para un proyecto grande, sólo 15% del proyecto son código y pruebas unitarias, una inversión casi perfecta de las proporciones de la construcción del puente. Aun cuando se consideren las pruebas parte de la construcción, el plan es todavía 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseño en software comparado con su papel en otras ramas de la ingeniería.
Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho el código fuente es un documento de diseño y que la fase de construcción está en realidad en la compilación y el ligado. De hecho cualquier cosa que pueda tratar como construcción puede y debe automatizarse.
Estas ideas llevan a algunas conclusiones importantes:
Hay un dicho que oigo en cada proyecto problemático con que me he encontrado. Los desarrolladores vienen y me dicen "el problema con este proyecto es que los requisitos cambian todo el tiempo". Lo que yo encuentro sorprendente sobre esta situación es que sorprenda a cualquiera. En el negocio de construcción de software los cambios en los requisitos son la norma, la pregunta es qué hacemos al respecto.
Una forma es tratar los requisitos cambiantes como el resultado de una pobre ingeniería de requisitos. La idea detrás de la ingeniería de requisitos es conseguir un cuadro totalmente entendido de los requisitos antes de empezar a construir el software, conseguir la firma del cliente sobre estos requisitos, y entonces preparar procedimientos que limiten los cambios de requisitos después de la firma.
Un problema con esto es que simplemente tratar de entender las opciones para los requisitos es duro. Es aun más duro porque la organización del desarrollo normalmente no proporciona la información del costo en los requisitos. Usted termina en la situación dónde quisiera tener un quemacocos en su automóvil, pero el vendedor no puede decirle si agrega 10 al costo del automóvil, o 10,000. Sin una buena idea del costo, ¿cómo puede usted decidir si quiere pagar por ese quemacocos?
La estimación es difícil por muchas razones. En parte porque el desarrollo de software es una actividad de diseño, difícil de planear y costar. En parte porque los materiales básicos cambian rápidamente. En parte por lo mucho que depende de los individuos involucrados, y los individuos son difíciles de predecir y cuantificar.
La naturaleza intangible del software también afecta. Es muy difícil saber qué valor aporta un rasgo de software hasta que se usa en realidad. Sólo cuando se usa realmente una versión temprana de algún software se empieza a entender qué rasgos son valiosos y cuales no.
Esto lleva al punto irónico de que es de esperarse que los requisitos sean cambiables. Después de todo se supone que el software es "suave". Así no sólo son cambiables los requisitos, sino que deben de serlo. Toma mucha energía conseguir que los clientes de software corrijan los requisitos. Es aun peor si ellos han estando alguna vez en desarrollo de software, porque entonces "saben" que el software es fácil de cambiar.
Pero aun cuando se pudiera controlar todo esto y realmente se pudiera conseguir un conjunto exacto y estable de requisitos, probablemente aún no estamos a salvo. En la economía de hoy las fuerzas de negocios fundamentales cambian el valor de los rasgos de software demasiado rápidamente. El que podría ser un buen conjunto de requisitos ahora, no será tan bueno en seis meses. Aun cuando el cliente pueda corregir sus requisitos, el mundo de negocios no va a detenerse por él. Y muchos cambios en el mundo de negocios son completamente imprevisibles: cualquiera que diga otra cosa o está mintiendo, o ya ha hecho mil millones en la bolsa de valores.
Casi todo en el desarrollo de software depende de los requisitos. Si no se pueden obtener requisitos estables no se puede obtener un plan predecible.
En general, no. Hay algunos desarrollos de software dónde la previsibilidad es posible. Organizaciones como el grupo de software del transbordador espacial de la NASA son un ejemplo selecto donde el desarrollo de software puede ser predecible. Requiere mucha ceremonia, mucho tiempo, un equipo grande y requisitos estables. Hay proyectos por ahí que son transbordadores espaciales. Sin embargo no creo que el software comercial encaje en esa categoría. Para éste se necesita un tipo diferente de proceso.
Uno de los grandes peligros es pretender que se puede seguir un proceso predecible cuando no se puede. La gente que trabaja en metodologías no es buena en identificar condiciones límite: los lugares dónde la metodología pasa de apropiada en inapropiada. La mayoría de los metodologistas quieren que sus metodologías sean usadas por todos, de modo que no entienden ni publican sus condiciones límite. Esto lleva a la gente a usar una metodología en malas circunstancias, como usar una metodología predecible en una situación imprevisible.
Hay una tentación fuerte para hacer eso. La previsibilidad es una propiedad muy deseable. No obstante creer que se puede ser predecible cuando no se puede, lleva a situaciones en donde las personas construyen un plan temprano, y entonces no pueden manejar la situación cuando el plan se cae en pedazos. Usted acaba viendo el plan y la realidad flotando aparte. Durante algún tiempo usted podrá pretender que el plan es válido. Pero en algún punto la deriva es demasiada y el plan se cae en pedazos. Normalmente la caída es dolorosa.
Así si usted está en una situación impredecible no puede usar una metodología predictiva. Ése es un golpe duro. Significa que tantos modelos para controlar proyectos, y muchos de los modelos para llevar la relación con el cliente, no son ciertos más. Los beneficios de la previsibilidad son tan grandes, que es difícil dejarlos ir. Como en tantos problemas la parte más difícil está simplemente en comprender que el problema existe.
De cualquier modo dejar ir la previsibilidad no significa que hay que volver al caos ingobernable. Más bien hace falta un proceso que pueda dar control sobre la imprevisibilidad. De eso se trata la adaptabilidad.
¿Así que cómo nos controlamos en un mundo imprevisible? La parte más importante y difícil, es saber con precisión dónde estamos. Necesitamos un mecanismo honesto de retroalimentación que pueda decirnos con precisión cual es la situación a intervalos frecuentes.
La llave para obtener esta retroalimentación es el desarrollo iterativo. Esta no es una idea nueva. El desarrollo iterativo ha estado durante algún tiempo bajo muchos nombres: incremental, evolutivo, escenificado, espiral... muchos nombres. La clave del desarrollo iterativo es producir frecuentemente versiones que funcionen del sistema final que tengan un subconjunto de los rasgos requeridos. Éstos sistemas son cortos en funcionalidad, pero por otra parte deben ser fieles a las demandas del sistema final. Deben ser totalmente integrados y tan cuidadosamente probados como una entrega final.
El punto es que no hay nada como un sistema probado, integrado para traer una dosis poderosa de realidad en cualquier proyecto. Los documentos pueden esconder toda clase de fallas. El código no probado puede esconder bastantes defectos. Pero cuando las personas realmente se sientan delante de un sistema y trabajan con él, entonces las fallas se vuelven aparentes: tanto las relativas a bugs como las relativas a los requisitos mal entendidos.
El desarrollo iterativo también tiene sentido en los procesos predecibles. Pero es esencial en los procesos adaptables porque un proceso adaptable necesita poder tratar con los cambios en los rasgos requeridos. Esto lleva a un estilo de planear donde los planes a largo plazo son muy fluidos, y los únicos planes estables son a corto plazo hechos para una sola iteración. El desarrollo iterativo da un fundamento firme en cada iteración que puede usarse para basar los planes posteriores.
Una pregunta importante es cuánto debe durar una iteración. Diferentes personas dan respuestas diferentes. XP sugiere iteraciones de entre una y tres semanas. SCRUM sugiere un mes. Cristal estira aun más. La tendencia, de cualquier modo, es hacer cada iteración tan corta como se pueda manejar. Esto proporciona la retroalimentación más frecuente, así que usted sabe más a menudo donde se encuentra.
Este tipo de proceso adaptable requiere un tipo diferente de relación con el cliente que las que se consideran a menudo, particularmente cuando el desarrollo es hecho por otra empresa. Cuando contrate una empresa separada para hacer el desarrollo del software, la mayoría de los clientes preferirán un contrato a precio fijo. Dígale a los desarrolladores lo que quieren, negocie, acepte una oferta, y entonces la carga queda en la empresa de desarrollo para construir el software.
Un contrato a precio fijo requiere requisitos estables y por tanto procesos predictivos. Los procesos adaptables y los requisitos inestables implican que no se puede trabajar con la noción usual de precio fijo. Tratar de encajar un modelo de precio fijo a un proceso adaptable acaba en una explosión muy dolorosa. La parte sucia de esta explosión es que el cliente queda herido tanto como la compañía de desarrollo de software. Después de todo el cliente no querría un software a menos que su negocio lo necesitara. Si no lo consigue su negocio sufre. Así aun cuando no pague nada a la compañía de desarrollo, todavía pierde. De hecho pierde más de lo que pagaría por el software (¿por qué habría de pagar el software si el valor comercial de ese software fuera menor?).
De modo que hay peligro para ambos lados al firmar un contrato a precio fijo en condiciones dónde un proceso predictivo no puede usarse. Esto significa que el cliente tiene que trabajar de otro modo.
Esto no significa que no se pueda fijar un presupuesto para software por adelantado. Lo que significa es que no se puede fijar el tiempo, precio y alcance. La manera ágil usual es fijar tiempo y precio y permitir que el alcance varie de manera controlada.
En un proceso adaptable el cliente tiene mucho control a escala fina sobre el proceso de desarrollo de software. A cada iteración puede tanto verificar el progreso como alterar la dirección del desarrollo de software. Esto lleva a una relación mucho más íntima con los desarrolladores de software, una verdadera sociedad de trabajo. Este nivel de compromiso no es para cualquier organización cliente, ni para cualquier desarrollador de software; pero es esencial para lograr que un proceso adaptable funcione apropiadamente.
El beneficio importante para el cliente es un desarrollo de software mucho más sensible. Un sistema usable, aunque mínimo, puede entrar en producción pronto. El cliente puede cambiar sus capacidades de acuerdo a los cambios en el negocio, y también aprender cómo se usa el sistema en realidad.
Una pieza tan importante como ésta es una visibilidad mayor sobre el verdadero estado del proyecto. El problema con los procesos predictivos es que la calidad del proyecto se mide por la conformidad con el plan. Esto dificulta a la gente señalar cuando la realidad y el plan divergen. El resultado común es un gran resbalón más tarde en el calendario del proyecto. En un proyecto ágil hay un constante rehacer del plan con cada iteración. Si las malas noticias están al acecho, tienden a aparecer más temprano, cuando aun se puede hacer algo al respecto. De hecho este control del riesgo es una ventaja clave del desarrollo iterativo. Los métodos ágiles van más allá manteniendo corta la duración de la iteración, pero también viendo estas variaciones como oportunidades.
Hay un aspecto importante en lo que constituye un proyecto exitoso. Un proyecto predictivo se mide a menudo por lo bien que coincide con el plan. Un proyecto que está a tiempo y en costo es un éxito. Esta medida no tiene sentido en un ambiente ágil. Para el agilista la cuestión es el valor de negocio - si el cliente consigue un software más valioso que el costo que puso en él. Un buen proyecto predictivo irá de acuerdo al plan, un buen proyecto ágil construirá algo diferente y mejor que lo que se esperaba en el plan original.
No es fácil ejecutar un proceso adaptable. En particular requiere un equipo muy eficaz de desarrolladores. El equipo necesita ser eficaz tanto en la calidad de los individuos como en la manera en que funcionan juntos en equipo. Hay también una sinergia interesante: no sólo la adaptabilidad requiere un equipo fuerte, la mayoría de los buenos desarrolladores prefieren un proceso adaptable.
Uno de los objetivos de las metodologías tradicionales es desarrollar un proceso donde las personas involucradas sean partes reemplazables. Con tal proceso se puede tratar a las personas como recursos que están disponibles en varios tipos. Se tienen un analista, algunos programadores, algunos verificadores, un gerente. Los individuos no son tan importantes, sólo los papeles lo son. De esa manera si usted planea un proyecto no importa qué analista y qué verificadores consiga, sólo hay que saber cuántos son para saber cómo afecta su plan el número de recursos.
Pero esto plantea una pregunta clave: ¿son las personas involucradas en el desarrollo de software partes reemplazables? Uno de los rasgos importantes de los métodos ágiles es el rechazo a esta afirmación.
Quizás el rechazo más explícito a las personas como recursos lo hace Alistair Cockburn. En su artículo Caracterización de las Personas como Componentes No Lineales de Primer Orden en el Desarrollo de Software, apunta a que los procesos predecibles requieren componentes que se comporten de manera predecible. Sin embargo las personas no son componentes predecibles. Además sus estudios de proyectos de software lo han llevado a concluir que la gente es el factor más importante en el desarrollo de software.
En el título, [de su artículo] me refiero a las personas como "componentes". Así es como se trata a la gente en la literatura de diseño de procesos / metodologías. El error de este enfoque es que las "personas" son altamente inconstantes y no lineales, con modos únicos de éxito y fracaso. Esos factores son de primer orden, factores no despreciables. El fracaso de los diseñadores de procesos y metodologías para responder a esto contribuye a la clase de trayectorias de proyectos no planeados que vemos a menudo.
- [Cockburn, non-linear]
Uno se pregunta si no la naturaleza del desarrollo de software funciona contra uno aquí. Cuando programamos una computadora, controlamos un dispositivo inherentemente predecible. Como estamos en este negocio porque somos buenos en hacerlo, estamos idealmente hechos para disturbarnos cuando nos enfrentamos con seres humanos.
Aunque Cockburn es el más explícito en su visión centrada en la gente del desarrollo de software, la noción de que la gente es primero es un tema común para muchos pensadores del software. El problema, demasiado a menudo, es que la metodología se ha opuesto a la noción de las personas como el factor de primer orden en el éxito del proyecto.
Esto crea un fuerte efecto de retroalimentación positiva. Si usted espera que todos sus desarrolladores se junten en unidades de programación compatibles, no intentará tratarlos como individuos. Esto baja la moral (y la productividad). Las personas capaces se buscarán un lugar mejor donde estar, y usted acabará con lo que usted deseaba: unidades de programación compatibles.
Decidir que las personas son primero es una decisión grande, que requiere mucha determinación. La noción de la gente como recursos es profundamente inculcado en el pensamiento de negocios, teniendo sus raíces en el impacto del enfoque de La Dirección Científica de Frederick Taylor. En la administración de una fábrica, este enfoque Taylorista tiene sentido. Pero para un trabajo altamente creativo y profesional, como creo es el desarrollo de software, esto no se sostiene. (Y de hecho la fabricación moderna también se está saliendo del modelo Taylorista.)
Una parte clave de la noción Taylorista es que la gente que hace el trabajo no es la mejor gente para entender la mejor manera de hacer el trabajo. En una fábrica esto puede ser verdad por varias razones. En parte porque la mayoría de los obreros no son las personas más inteligentes o creativas, en parte porque hay una tensión entre la gerencia y los obreros en que la gerencia gana más dinero y los obreros menos.
La historia reciente nos demuestra cada vez más lo falso que es esto para el desarrollo de software. A las personas brillantes y capaces les atrae cada vez más el desarrollo de software, tanto por su ostentación como por ganancias potencialmente mayores. (Ambas razones me tentaron a salir de la ingeniería electrónica.) Cosas tales como opciones accionarias afirman el interés de los programadores en la compañía.
(Aquí bien puede haber un efecto generacional. Una evidencia anecdótica me hace preguntarme si más gente brillante se han aventurado en el desarrollo de software en los últimos diez años. En ese caso ésta sería una razón para ese culto a la juventud en el negocio de la computación, como en la mayoría de los cultos se necesita un grano de verdad en él.)
Cuando se quiere contratar y retener a gente capaz, hay que reconocer que son profesionales competentes. Como tales son los mejores para decidir cómo dirigir su trabajo técnico. La noción Taylorista de un departamento de planificación separado que decide cómo hacer las cosas sólo funciona si los planificadores entienden mejor cómo hacer bien el trabajo que aquéllos que lo hacen. Si usted tiene personas brillantes, motivadas que hacen bien el trabajo entonces eso no se sostiene.
La orientación a la gente se manifiesta de varias maneras diferentes en los procesos ágiles, lo que lleva a efectos diferentes, no todos consistentes.
Uno de los elementos clave es la aceptación de un proceso en lugar de la imposición de un proceso. A menudo los procesos de software se imponen desde la gerencia. Como tales se les resiste a menudo, particularmente cuando la gerencia ha estado fuera del desarrollo activo un buen tiempo. Aceptar un proceso requiere compromiso, y como tal se necesita el involucramiento activo de todo el equipo.
Esto termina con el resultado interesante de que sólo los desarrolladores puede escoger seguir un proceso adaptable. Esto es particularmente cierto para la XP, que requiere mucha disciplina para ejecutarse. Aquí es donde Cristal es un complemento efectivo ya que apunta a una disciplina mínima.
Otro punto es que los desarrolladores deben poder tomar todas las decisiones técnicas. XP llega al corazón de esto cuando en su proceso de planeación establece que sólo los desarrolladores pueden estimar cuánto tiempo tomará hacer un trabajo.
Tal liderazgo técnico es un gran cambio para muchas personas en posiciones gerenciales. Tal acercamiento requiere compartir una responsabilidad donde desarrolladores y gerencia tienen un mismo lugar en la dirección del proyecto. Nótese que dije igual. La gerencia aun juega un papel, pero reconoce la pericia de los desarrolladores.
Una razón importante para esto es el ritmo del cambio de tecnología en nuestra industria. Después de unos años el conocimiento técnico se vuelve obsoleto. Esta vida media de habilidades técnicas no tiene parangón en cualquier otra industria. Incluso los técnicos tienen que reconocer que entrar a la gerencia significa que sus habilidades técnicas se marchitarán rápidamente. Los exdesarrolladores necesitan reconocer que sus habilidades técnicas desaparecerán rápidamente y necesitan confiar y depender en los desarrolladores actuales.
Si usted tiene un proceso dónde las personas que dicen cómo hacer el trabajo son distintas de las personas que realmente lo hacen, los líderes necesitan alguna manera de medir cuán eficaces son los que lo hacen. En la Dirección Científica había un impulso fuerte a desarrollar formas objectivas de medir el rendimiento de las personas.
This es particularmente pertinente al software debido a la dificultad de aplicar medidas al software. A pesar de nuestros mejores esfuerzos somos incapaces de medir las cosas más simples sobre el software, como la productividad. Sin buenas medidas para estas cosas, cualquier clase de control externo está condenado.
La introducción de gestión medida sin buenas medidas tiene sus propios problemas. Robert Austin hizo una discusión excelente de esto. Él señala que cuando se mide el rendimiento usted tienen que conseguir todos los factores importantes bajo medida. Cualquier cosa que se olvide tiene el resultado inevitable que los hacedores alterarán lo que hacen para producir las mejores medidas, incluso si eso claramente reduce la verdadera efectividad de lo que hacen. Este trastorno de la medida es el talón de Aquiles de la gestión basada en medidas.
La conclusión de Austin es que usted tiene que escoger entre la gestión basada en métricas y la gestión delegatoria (donde los hacedores deciden cómo hacer el trabajo). La gestión basada en métricas es más adecuada para el trabajo simple repetitivo, con bajos requisitos de conocimiento y rendimientos fácilmente medibles - exactamente lo contrario al desarrollo de software.
El punto de todo esto es que los métodos tradicionales han operado bajo la asunción de que la gestión basada en métricas es la manera más eficaz de administrar. La comunidad ágil reconoce que las características del desarrollo de software son tales que la gestión basada en métricas lleva el trastorno de la medida a niveles muy altos. Es realmente más eficaz usar un estilo delegatorio de administración que es el tipo de acercamiento que está en el centro del punto de vista agilista.
Pero los técnicos no pueden hacer el proceso entero ellos solos. Necesitan una guía en las necesidades comerciales. Esto lleva a otro aspecto importante de los procesos adaptables: necesitan un contacto muy íntimo con los expertos del negocio.
Esto va más allá del compromiso de negocios en la mayoría de los proyectos. Los equipos ágiles no pueden existir con una comunicación ocasional. Necesitan un acceso continuo a los expertos del negocio. Además este acceso no es algo que se maneja a nivel gerencial, es algo que está presente para cada desarrollador. Como los desarrolladores son profesionales capaces en su propia disciplina, necesitan poder trabajar como iguales con otros profesionales de otras disciplinas.
Gran parte de esto, claro está, se debe a la naturaleza del desarrollo adaptable. Como la premisa entera del desarrollo adaptable es que las cosas cambian rápidamente, se necesita un contacto constante para avisar a todos de los cambios.
No hay nada más frustrante para un desarrollador que ver desperdiciarse su trabajo duro. Así que es importante asegurar que hay pericia de negocios de buena calidad que está disponible al desarrollador y de calidad suficiente para que el desarrollador pueda confiar en ella.
Hasta ahora he hablado sobre la adaptabilidad en el contexto de un proyecto adaptando frecuentemente su software para enfrentarse a los requisitos cambiantes de sus clientes. No obstante hay otro ángulo de la adaptabilidad: el del proceso que cambia con el tiempo. Un proyecto que empieza usando un proceso adaptable no tendrá el mismo proceso un año después. Con el tiempo, el equipo encontrará lo que funciona mejor para ellos, y alterará el proceso a su medida.
La primera parte de la auto adaptabilidad son las revisiones regulares del proceso. Normalmente se hacen con cada iteración. Al final de cada iteración, haga una reunión corta y hágase las siguientes preguntas (escogidas de Norm Kerth)
Estas preguntas traerán ideas para cambiar el proceso en la siguiente iteración. De esta manera un proceso que empieza con problemas puede mejorar conforme el proyecto avanza, adaptándose mejor al equipo que lo usa.
Si la auto adaptabilidad ocurre dentro de un proyecto, es aun más marcada en una organización. Para ahondar el proceso de la auto adaptabilidad sugiero que los equipos hagan una revisión más formal e hitos del proyecto mayores siguiendo las sesiones retrospectivas del proyecto esbozadas por Norm Kerth. Estas retrospectivas involucran reuniones de 2-3 días y un facilitador entrenado. Ellas no solo dan aprendizaje al equipo, también dan aprendizaje a la organización entera.
Una consecuencia de la auto adaptabilidad es que nunca se debe esperar encontrar una metodología corporativa única. En cambio cada equipo debe no simplemente escoger su propio proceso, debe también afinar activamente su proceso conforme avanza el proyecto. Mientras que tanto los procesos publicados como la experiencia de otros proyectos pueden actuar como una inspiración y una línea de fondo, la responsabilidad profesional de los desarrolladores es adaptar el proceso a la tarea en mano.
Esta auto adaptabilidad es muy marcada en ASD y Cristal. Las reglas rígidas de la XP parecen desaprobarla, pero ésa es sólo una impresión superficial ya que la XP anima a la gente a afinar el proceso. La diferencia principal de la XP es que sus promotores sugieren hacer XP al pie de la letra por varias iteraciones antes de adaptarlo. Además las revisiones no son enfatizadas, ni parte del proceso, aunque hay sugerencias de que las revisiones deberían ser una de las prácticas de la XP.
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.
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 refactorar 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 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 esta traducción, que es también wiki http://www.programacionextrema.org/ y un grupo de discusión en yahoo. N. del T.]
Alistair Cockburn ha estado trabajando en metodologías desde que la IBM le encargó escribir sobre metodologías a inicios de los 90. Su acercamiento no es como la mayoría de los metodologistas, no obstante. 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 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.
Los Cristales comparten 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.
Usted puede sorprenderse por 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 haciendo 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 se engrana a equipos físicamente distribuidos, lo qué 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. El mantenedor así 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 bug 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 escribe bien. La referencia más famosa es el artículo de Eric Raymond The Catedral and the 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 hacer una actualización cvs.
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 el ambiente adaptable, sin embargo, 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 asunciones y usar los resultados de cada ciclo de desarrollo para adaptar el siguiente.
-[Highsmith]
El aprendizaje como tal es un rasgo continuo e importante, uno 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 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 agiles 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 SCRUM. 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.
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.
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.
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.
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 el mismo cuarto, 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.
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 se aclara eso, varias personas en la comunidad de verificadores han estado cuestionando mucho de la corriente principal del pensamiento en comprobación por un tiempo ya. Esto ha llevado a un grupo conocido como la comprobación conducida por el contexto. La mejor descripción de esto 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.
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 se 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 (voltear dX al revés 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.
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.
El uso de un método ágil no es para todos. Hay que tener en cuenta varias cosas si se decide a seguir por este camino. Sin embargo yo ciertamente creo que estas nuevas metodologías son extensamente aplicables y deben ser usadas por más personas de las que actualmente lo consideran.
En el ambiente actual, la metodología más común es codifica y corrige. Aplicar más disciplina que caos casi seguramente ayudará, y el acercamiento ágil tiene la ventaja de que es mucho menos de un paso que un método pesado. Mucha de la ventaja de los métodos ágiles es de hecho su peso ligero. Los procesos más simples son más probables de ser seguidos cuando uno no está acostumbrado a ningún proceso en absoluto.
Una de las limitaciones más grandes de estas nuevas metodologías es cómo manejan equipos más grandes. Como muchas nuevas tendencias, ellos tienden a ser usados primero a escala pequeña antes que a gran escala. También a menudo se han creado con énfasis en equipos pequeños. La XP explícitamente dice que está diseñada para equipos de no más de veinte personas. Hay que recordar que muchos equipos de software pueden reducirse en tamaño sin reducir su productividad total.
Otras tendencias ágiles están destinadas a equipos más grandes. La FDD fue diseñada originalmente para un proyecto de cincuenta personas. ThoughtWorks ha usado proyectos influidos por la XP con equipos de cerca de 100 en tres continentes. Scrum se ha usado para manejar tamaños similares.
Esperanzadoramente un mensaje que queda claro en este artículo es que los acercamientos adaptables son buenos cuando sus requisitos son inciertos o volátiles. Si usted no tiene requisitos estables, entonces no está en la posición tener un plan estable y seguir un proceso planeado. En éstas situaciones un proceso adaptable puede ser menos cómodo, pero será más eficaz. A menudo la barrera más grande aquí es el cliente. Como yo lo veo es importante para el cliente entender que seguir un proceso predictivo cuando los requisitos cambian es arriesgado tanto para ellos como para el desarrollo.
Si usted va a tomar la ruta adaptable, necesita confiar en sus desarrolladores e involucrarlos en la decisión. Los procesos adaptables cuentan en que usted confía en sus desarrolladores, de modo que si usted considera a sus desarrolladores de baja calidad y motivación, usted debe usar un acercamiento predictivo.
Para resumir. Los siguientes factores sugieren un proceso adaptable
Estos factores sugieren un proceso predictivo
He tomado muchas ideas de otras personas para este artículo, más de las que puedo listar. Para sugerencias concretas me gustaría agradecer a Marc Balcer, Kent Beck, Alistair Cockburn, Ward Cunningham, Bill Kimmel y Frank Westphal.
Recuerde que éste es un artículo web en evolución y es probable que cambie cuando se me ocurra. Agregaré un registro de cambios significativos, sin embargo los cambios menores ocurrirán sin ningún comentario.
Aquí esta una lista de las actualizaciones mayores a este artículo
© Derechos reservados de la traducción Alejandro Aguilar Sierra.
Si desea comentar sobre el artículo o la traducción, oprima aquí.