Balanceo de metodologías orientadas al plan y agiles. Herramientas para la selección y adaptación

Balancing agile and plan-oriented methodologies. Tools for selection and adaptation.

Resumen.

La experiencia acumulada a lo largo de años de ejecutar proyectos, indica que los proyectos exitosos son aquéllos que son administrados siguiendo una serie de procesos que permiten organizar y luego controlar al proyecto. Por otro lado, en los últimos años, ha surgido una corriente en la industria del software que considera que las necesidades de los clientes son muy cambiantes, y que si no nos adaptamos rápidamente, corremos el riesgo de estar resolviendo el problema equivocado. Estas dos visiones parecen opuestas, pero las metodologías que reflejan a esas visiones pueden considerarse como herramientas diseñadas para ser usadas en contextos específicos. En este trabajo se describe un Modelo para categorizar los proyectos en los que el software es una parte fundamental, y en función de esa categorización, seleccionar el ciclo de vida ágil con el que mejor se ejecutará el proyecto: ágil, orientado al plan, o una combinación. Por último, se comentan las limitaciones de la propuesta.

Introducción

El Problema

La experiencia acumulada a lo largo de años de ejecutar proyectos, indica que los proyectos exitosos son aquéllos que son administrados siguiendo una serie de procesos que permiten organizar y luego controlar al proyecto. Según esta visión, los proyectos que no sigan estos lineamientos corren un alto riesgo de fracasar.

Por otro lado, en los últimos años, ha surgido una corriente en la industria del software que considera que las necesidades de los clientes son muy cambiantes, y que si no nos adaptamos rápidamente, corremos el riesgo de estar resolviendo el problema equivocado. En pos de esto se proponen metodologías que parecen contradecir la visión tradicional de los proyectos.

Estas dos visiones parecen opuestas, y la discusión sobre ellas se ve oscurecida por la profusión de nombres con respecto a las clasificaciones de las metodologías: livianas vs pesadas, ágiles vs orientadas al plan, etc.

El profesional se ve envuelto en esta discusión, en la que muchos proponentes plantean sus opiniones como verdades indiscutibles, y en la que la decisión sobre qué metodología utilizar parece ser un acto de fe, antes que una evaluación de alternativas técnicas, con sus costos, beneficios y riesgos asociados.

Antecedentes

Las metodologías Orientadas al Plan están reflejadas, por ejemplo, en el PMBOK (PMI, 2000). En el área de proyectos de software, esto se refleja en metodologías como RUP y en modelos de madurez como SW-CMM.

Los proponentes de las metodologías ágiles han propuesto el Manifiesto Ágil (Beck, Beedle & otros, 2001), y ejemplos de este tipo de metodología son XP y Scrum, entre otras.

El problema planteado es reconocido, y existen diferentes iniciativas intentando lograr una síntesis. Por ejemplo, en el modelos de madurez, CMMI incorpora más flexibilidad, en las metodologías utilizadas por las principales empresas del sector, por ejemplo UP/RUP (Fowler, 2003) y (Larman, 2001) y MSF v4 (Microsoft, 2004). Otra forma, basada en la Teoría de las Restricciones, de buscar la selección de las prácticas más efectivas y lograr una síntesis de metodologías es presentada en (Anderson, 2004).

El presente trabajo se basa en el ciclo de vida espiral controlado por riesgo, y los trabajos relacionados presentados en (Boehm, 2002) y (Boehm&Turner, 2004).

Definiciones y Mitos

Para unificar proponemos definiciones para los dos enfoques analizados (ágil y orientado al plan). Se debe tener en cuenta que son generalizaciones, tratando de extraer los puntos en común de varias metodologías.

Además aclaramos algunos mitos, relacionados tanto con las expectativas excesivas como, por el contrario, con el mal uso de las metodologías. Para cada mito, se comentará la realidad subyacente.

Características de las metodologías orientadas al plan

Estas metodologías son desarrollos a partir de la Ingeniería de Sistemas y de los métodos para mejoras de procesos, lo que requiere Procesos definidos, Planificación predictiva, Definición de tareas e hitos y Documentación como producto intermedio entre las etapas. Esto tiende a permitir controlar, medir y mejorar el proceso.

Históricamente, las metodologías de este tipo surgieron de grandes proyectos de defensa y aeroespaciales. Es por eso que soportan naturalmente los proyectos en los que el software se desarrolla conjuntamente con el hardware, y las formas de contratos son de Precio Fijo.

Mitos de las metodologías orientadas al plan

Implica un modelo de cascada: a pesar que muchas veces en la práctica se intenta implementar como un ciclo de vida en cascada por la simplicidad en la administración, tanto la literatura como las buenas prácticas aconsejan utilizar ciclos de vida iterativos, en los que el sistema crece incrementalmente. Cada iteración debería estar guiada por el análisis de riesgos y las prioridades fijadas por el cliente.

Con alto nivel de madurez, un proceso bueno y documentado, el éxito está asegurado: el proyecto se puede controlar mejor y se puede realizar con menos personas talentosas, pero no está asegurado el éxito.

Los métodos orientados al plan son burocráticos: las organizaciones burocráticas aplican en forma uniforme los métodos, sin evaluar qué partes es conveniente aplicar, exigiendo usar artefactos o prácticas ineficientemente. Adicionalmente, las personas con menor experiencia pueden no conocer las razones por las que se utilizan determinadas prácticas, por lo tanto no pueden justificar el no realizarlas. Ante la duda, se generan artefactos quizás innecesarios.

Siempre está justificado dedicar tiempo en el inicio para planificación detallada: esto implica diseño temprano y estimaciones de tareas que pueden ser poco conocidas en el inicio del proyecto, sobre todo en ambientes muy cambiantes o novedosos.

Impide adaptarse a los cambios: los cambios se pueden realizar, pero en forma controlada, que implica un costo en la evaluación y manejo de los mismos.

Características de las metodologías ágiles

Usaremos la definición provista por el Manifiesto Ágil (Beck, Beedle & otros, 2001):

img Personas e interacciones sobre procesos y herramientas

img Software sobre documentación comprensible

img Colaboración con clientes sobre negociación de contratos

img Responder a los cambios sobre seguir un plan

El lema utilizado es “Abrazar el cambio”, y esto lleva a utilizar Desarrollo iterativo e incremental, Iteraciones cortas y TimeBoxed, Planificación adaptativa y Entrega evolutiva. Se busca lograr que el cambio sea menos costoso, permitiendo que sea incorporado más fácilmente.

Mitos de las metodologías ágiles

No se planifica: es común tener una lista de tareas o funcionalidad que se desea implementar, pero no se estima ni se calendariza en detalle más allá de la próxima iteración. Fuera de las listas tareas y funcionalidades, la comunicación de lo planificado es a través del conocimiento tácito, siempre que sea posible (aplicación del concepto de apenas lo suficiente).

Se requiere que cada integrante del grupo sea excepcional: los métodos ágiles funcionan con una masa crítica de gente talentosa.

Costo de los cambios se mantiene uniforme: la aplicación de los métodos ágiles disminuye el crecimiento de costo por cambio, pero la simplificación de considerarlo constante implica un riesgo que debe ser reevaluado a lo largo del proyecto.

Modelo para categorizar los Proyectos

El análisis que haremos parte de la premisa que la aplicabilidad de las metodologías depende de las circunstancias. Pero también se debe considerar que algunas decisiones que se toman en cuanto a la forma de encarar el proyecto facilitan o no a alguno de los enfoques. Para distinguir estas dos formas de análisis, denominamos Territorios al análisis tomando características de los métodos y Factores a las características del problema a resolver.

Territorios

Condiciones bajo las cuales cada metodología tiene más probabilidad de éxito; cuanto más se aleja el caso en estudio de las características de dicha condición, más riesgo hay en aplicar tal metodología (Ver Tabla 1). Los territorios son rangos de valores de las características. Por ejemplo, para la característica Tamaño, valores de menos de 10 personas es territorio ágil, mientras que más de 50 es territorio orientado al plan. Los valores entre 10 y 50 no son claramente territorio de alguna de las metodologías.

Las características pueden considerarse desde dos puntos de vista. Por ejemplo, Tamaño puede ser impuesto por el tipo de problema a resolver, o puede modificarse para acercarlo a un territorio, buscando minimizar riesgos. Se puede reducir el tamaño por medio del versionado del producto o ampliar agrupando cambios pequeños (McConnell, 1996, p. 319) y (De Feo, 2002).

Características y Territorios

Tabla 1 – Características y Territorios

Factores

Los factores permiten clasificar tomando las restricciones o características impuestas por el problema a resolver y los medios disponibles para hacerlo: consideran al proyecto, al producto, a las organizaciones y personas que ejecutan o están relacionadas y el contexto de negocio (Ver Tabla 2). La definición y cantidad de factores son arbitrarias, y existen otras propuestas. Ver por ejemplo (Cockburn, 2000).

Tamaño: Del proyecto. Se mide en número de personas involucradas. Se busca evaluar con este factor la escala del problema, que afecta en varios sentidos, por ejemplo el nivel de complejidad en la comunicación y los costos de cambio que puedan esperarse. Diferencias de escala provocan que algunas prácticas, como la dependencia del conocimiento explícito, no sean aplicables. En este sentido, hay que considerar que el tamaño del producto o la duración del proyecto (medir los meses/hombre) también se deben tomar en cuenta.

Criticidad: Naturaleza del daño ocasionado por defectos no detectados. Una posible clasificación cualitativa es pérdida de confort, pérdida de dinero discrecional, pérdida de dinero fundamental para la compañía, daños a la salud, pérdida de vidas. (Cockburn, 2000)

Dinamismo: Velocidad con la que se producen cambios en los requerimientos. Los cambios de contexto, tanto sea de negocios, de la organización, técnicos, etc., los consideramos desde el punto de vista de cambios de requerimientos. Este factor no afecta negativamente a los métodos ágiles, que pueden ser efectivos tanto con velocidad de cambio alta como con baja.

Personal: Proporción de personal Senior, Semi-senior y Junior. Este factor no afecta negativamente a los métodos orientados al plan, que pueden ser efectivos tanto con alto como con bajo nivel de seniority.

Cultura: Las organizaciones y las personas intervinientes pueden depender de la confianza, o en la relación contractual. Esto se refleja en el nivel de ceremonia necesario y aceptado: documentación, control, formalismo en las comunicaciones. Por otro lado, ¿cómo suele ser la estructura de los grupos de proyectos, jerárquica o grupos de pares?

Factores y Territorios

Tabla 2 – Factores y Territorios

Relación entre características, territorios y factores

La tabla 3 muestra algunas de las relaciones. Por ejemplo, en un Entorno de negocios cambiantes o en el caso de un producto nuevo, el factor Dinamismo será alto, mientras que en un Entorno operativo correspondiente a un equipo médico de monitoreo de signos vitales la Criticidad es elevada, incluso para una aplicación que en sí misma no sería crítica.

La relación entre los territorios y los factores es compleja e involucra toda la flexibilidad en el manejo de riesgos que provee el diseño de la metodología. Por ejemplo, en el caso de un nuevo producto, para disminuir el Dinamismo del proyecto se puede realizar un proyecto previo, mucho más reducido, que desarrolle un prototipo que llegue a manos de un grupo reducido de usuarios, y permita estabilizar los requerimientos (Ver Imagen 1). Consideramos que si el problema analizado está dentro del área punteada interna, estaríamos en territorio ágiles.

Relación Características y Factores

Tabla 3 – Relación Características y Factores

Principalmente Orientado al Plan

Imagen 1 – Principalmente Orientado al Plan

Balanceo de Metodologías

Con los modelos descriptos anteriormente podemos identificar si estamos en territorio ágil u orientado al plan, en cuyo caso podemos seleccionar uno u otro enfoque metodológico. Pero, ¿qué pasa en el caso que la situación no sea tan clara?

Se propone ejecutar el proyecto con un ciclo de vida espiral controlado por riesgos. El siguiente es el proceso utilizado para definir el detalle de la metodología a utilizar.

Proceso

  1. Evaluar los factores para ver en que territorio están: ágil u orientado a plan. Si hay incertidumbre importante, conseguir más información con prototipos, búsqueda de datos y análisis.
  2. ¿Domina alguno de los métodos? Si es así, seguir en 4, utilizando el método dominante: Ágil u Orientado al plan (Ver Imagen 1).
  3. Si no domina ninguno de los métodos, diseñar la aplicación (y el proyecto) para encapsular la parte ágil.
  4. Establecer una estrategia de proyecto integrando las distintas mitigaciones de riesgos.
  5. Monitorear los riesgos (amenazas/oportunidades) y reajustar correspondientemente.

Diferentes partes de la aplicación o del proyecto pueden tener diferencias grandes en sus características, por lo que pueden corresponder a distintos territorios. En este caso es importante analizar los riesgos involucrados (Boehm&Turner, 2004, p. 102). El análisis de riesgos debe considerar el balance entre hacer demasiado y hacer muy poco, por ejemplo: ¿Cuánto prototipado es suficiente?, ¿Cuánta especificación de requerimientos es suficiente?, ¿Cuánto testing es suficiente?, ¿Cuánta planificación y desarrollo de arquitectura inicial es suficiente?

Considerando los riesgos, seleccionar las prácticas que permitan disminuir la exposición, considerando el impacto en otras prácticas.

¿Con qué criterio balanceamos?

Considerando el ejemplo de la Imagen 1, si realizamos un prototipo estamos disminuyendo el riesgo de retrabajo que provocarían los cambios en requerimientos pero, por otro lado, es probable que si nos excedemos en el tiempo dedicado a fijar los requerimientos, perdamos ventas o participación de mercado. Incluso en algunos casos esto puede provocar que el resultado del proyecto sea inútil, por ejemplo cuando se tienen fechas fijas de presentaciones. Por lo tanto, debemos balancear la exposición al riesgo producido por requerimientos cambiantes contra la exposición al riesgo de pérdida de mercado. El punto óptimo de balanceo dependerá de otros factores del problema, por ejemplo, del tamaño, la disponibilidad de personal con seniority, etc.

Limitaciones e hipótesis

Los factores son arbitrariamente cinco, algunos con escalas cualitativas, con doble escala o con una escala cuantitativa, que en la práctica representan varios subfactores con escalas diferentes. Por lo que debe considerarse que los valores son órdenes de magnitud, y serán utilizados como herramientas de análisis y comparación, más que en sus valores absolutos.

Para poder aplicar este proceso se requiere que en el grupo existan personas con comprensión clara de los factores del problema. También el grupo debe tener conocimientos profundos, tanto de metodologías ágiles como orientadas al plan, de manera de poder seleccionar y aplicar las técnicas apropiadas para mitigar los riesgos.

Los métodos ágiles se concentran en mejorar el desarrollo de software, por lo que el proceso planteado debe aplicarse con doble precaución cuando el problema tiene componentes importantes no ligados al software, como por ejemplo compra e instalación de hardware, campañas de promoción y venta, modificación en los procesos operacionales de los clientes, capacitaciones, o diseño integrado de hardware y software.

El factor cultural es quizás el que más inercia presenta. Por lo tanto, debe considerarse que dentro de los plazos de un proyecto, los cambios culturales que se podrán realizar son acotados y lentos, comparados con otros. El ejecutar los proyectos guiados por riesgos puede ser en si mismo un cambio cultural, y la implementación de esto debe ser manejada con el cuidado que requiere un cambio cultural. La organización que ejecuta el proyecto impone restricciones en cuanto a: estructuras de control, estructura de costos, incentivos y plan de carrera. Por ejemplo, en proyectos ágiles se deben evitar la relación guiada por un contrato rígido, algo que puede lograrse buscando formas de asociación entre el cliente y el proveedor. Sin embargo, esto puede ser explícitamente prohibido por las políticas de contratación tanto de la organización del cliente como la del proveedor.

Conclusiones

Tanto los métodos ágiles como los orientados al plan son aplicables eficientemente dentro de sus territorios. Fuera de ellos, se corren riesgos. Varios autores están trabajando en ampliar los territorios tanto en métodos ágiles como en orientados al plan, manteniéndose dentro de un tipo de metodología. En este sentido, la experiencia indica que es mejor partir de un método sencillo, al cual agregarle lo necesario, antes que partir de uno muy completo, al que se debe recortar lo no necesario, ya que esto último pocas veces se hace en la práctica (Ver Definiciones y Mitos).

Presentamos una forma de ampliar los territorios aún más, para el caso en que el problema tiene factores que impiden considerarlo netamente en territorio ágil o en territorio orientado al plan. En este caso, se selecciona un método base y se manejan los riesgos ocasionados por los factores que no están dentro del método base.

Los valores de los factores son dependientes del evaluador. Un tema a investigar es la sensibilidad que tiene el método ante la obtención de diferentes valores de los factores para el mismo problema. En caso de ser muy sensible, haría necesario explicitar más la forma de medir los factores. Pero puede esperarse que lo importante no sean los valores, sino la comprensión del problema lograda en el proceso de medirlos.

Los métodos son importantes, pero no deberían hacernos perder de vista que el éxito del proyecto depende más de la comunicación efectiva con todos los interesados (stakeholders), el manejo de las expectativas, el valor generado para el negocio y las personas que participan en el proyecto.

Las organizaciones tienen rangos de aplicabilidad de las metodologías que utilizan, y es más sencillo trabajar dentro de ese rango de tipos de proyectos. En el caso de proyectos atípicos, debe replantearse las decisiones metodologías, ya que se corre el riesgo de no responder lo suficientemente rápido y con los costos apropiados en el caso de un problema en territorio más ágil que lo acostumbrado, o por lo contrario, intentar escalar formas de comunicación y prácticas ágiles más allá de lo conveniente, en el caso de problemas en territorio más orientado al plan que lo acostumbrado.

Bibliografía

Anderson A. (2004). Agile Management for Software Engineering. Upper Saddle River, NJ, USA. Prentice Hall.

Beck, K., Beedle, M. & otros (2001). Manifesto for Agile Software Development. Retrieved 16/10/2004 from http://www.agilemanifesto.org

Boehm B. (2002, January). Get Ready for Agile Methods, with Care. IEEE Computer, 35(1). 64-69 Boehm B. & R. Turner (2004). Balancing Agility and Discipline: a Guide for the perplexed., Boston, USA. Addison Wesley.

Cockburn, A. (2000). Just-In-Time Methodology Construction. Retrieved 16/10/2004 from http://alistair.cockburn.us/crystal/articles/jmc/justintimemethodologyconstruction.html

De Feo, G. (2002). Versionado y Entrega Incremental. Retrieved 16/10/2004 from http://www.rmya.com.ar/Download/Paper%20VI.pdf

Fowler M. (2003). The New Methodology. Retrieved 16/10/2004 from http://www.martinfowler.com/articles/newMethodology.html#N10361

Larman C. (2001). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition) Upper Saddle River, NJ, USA. Prentice Hall.

McConnell S. (1996). Rapid Development: taming wild software schedules. Redmond, WA, USA

Microsoft Press. Microsoft Corp. (2004). Visual Studio 2005 Team System: Microsoft Solutions Framework. Retrieved 16/10/2004 from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsent/html/vsts-msf.asp

Project Management Institute (2000). A guide to the project management body of knowledge (PMBOK® Guide) (2000 ed.). Newtown Square, PA, USA. Project Management Institute.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2004, Juan Gabardini, Lucas Campos
Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.