En su artículo “The New Metodology”, Martin Fowler hace una exposición de estos métodos, llamados métodos ágiles. Voy a hacer un pequeño repaso a este artículo a través de la traducción al castellano realizada por Alejandro Sierra.
Según Martin Fowler, la forma más habitual de trabajar en un proyecto de desarrollo de software es a través de la prueba y error con un mínimo plan inicial, y completando el diseño con decisiones a corto plazo. Esto funciona bien para proyectos pequeños pero no para proyectos más grandes, que necesitan de largas fases de prueba a posteriores que desbordan toda planificación.
Para remediar esta situación se dispone de metodologías de desarrollo, que imponen un proceso disciplinado que trata de convertir el desarrollo de software en algo predecible y eficiente, similar a otras ingerierías. Sin embargo, estos métodos introducen mucha burocracia en los proyectos, retrasando su avance.
En opocición a estas metodologías, surgen los métodos ágiles, que se sitúan en medio de las metodologías tradicionales y la falta de metodología. Están más orientados a producir código que documentación debido a sus dos características principales:
- Son adaptables en lugar de predictivos. En vez de planear todos los aspectos del proyecto tratan de adaptarse en los cambios que se producen durante la ejecución del proyecto.
- Son orientados a la gente en lugar de al proceso. Tratan de apoyar el equipo de desarrollo en su trabajo, en vez de forzar al equipo a trabajar de una forma estricta.
Las ingenierías tradicionales enfatizan en que hay que planear antes de construir. En ellas, el plan define de forma exacta cómo se llevará a cabo la construcción. La realización del plan es una actividad mucho más exigente que la ejecución, y requiere de personal especializado. La ejecución es algo más mecánico que puede ser llevado a cabo por personal de nivel bajo.
Sin embargo, en desarrollo de software, no es fácil diseñar un plan que convierta el desarrollo en una actividad de construcción predecible. Un diseño en UML no suele ser todo lo completo que sería necesario y suele variar con respecto a la implementación. En estos casos el costo del esfuerzo del plan es mucho mas cercano a la implementación que en proyectos de ingenierías tradicionales.
Por tanto, se observa que en el desarrollo de software la construcción es barata ya que casi todo el esfuerzo está en el diseño, que es un proceso creativo. Como los procesos creativos no se planean fácilmente, la previsibilidad es una meta difícil de alcanzar.
Además, en los proyectos de desarrollo de software, los cambios en los requisitos son habituales, debido a las condiciones cambiantes en las que se dearrollan los proyectos. Además, ya que el desarrollo de software es una actividad de diseño, esta es difícil de planear y cuantificar, por lo que la estimación de los requisitos es difícil, y con ello la posibilidad de obtener un plan predecible.
Es por ello que en desarrollo de software es necesario un proceso que controle esta imprevisibilidad mediante adaptabilidad. Esto se logra mediante el desarrollo iterativo, que permite obtener retralimentación sobre la situación del proyecto en intervalos frecuentes.
De esta forma, se hace evidente tanto la situación actual del proyecto como posibles fallos de entendimiento del mismo o bugs.
Sin embargo, este tipo de desarrollo necesita un tipo de cliente distinto al tradicional. El cliente debe estar involucrado con el equipo, revisando el resultado de las iteraciones y proporcionando información sobre el proyecto de forma constante. Además, el contrato de precio fijo deja de tener sentido.
Ya que no se puede fijar tiempo, precio y alcance, lo normal es fijar precio y tiempo y permitir que el alcance varie de manera controlada. Gracias a las iteraciones, el cliente tiene control a escala fina sobre la evolución del proyecto, pudiendo fijar la dirección del proyecto de acuerdo a sus prioridades. Esta visibilidad sobre el proyecto que otorgan las iteraciones permite controlar también el riesgo.
En un proceso de este tipo se requiere de un equipo eficaz de desarrolladores. Las personas involucradas en un proyecto ya no son recursos reemplazables, debido a que el trabajo que se realiza es algo creativo y en este tipo de trabajo hay grandes diferencias entre las personas. Además, si las personas trabajan en equipo, se establecen sinergias que hacen que el equipo sea más que la suma de sus miembros.
También hay que reconocer a los profesionales de software como profesionales competentes capaces de dirigir su trabajo técnico. La labor de la gerencia será favorecer este trabajo con la menor interferencia posible.
Las metodologías ágiles tambien rechazan las métricas como herramienta de control del rendimiento de las personas, puesto que no se han encontrado métricas fiables en este sentido. Por ello favorecen la gestión delegatoria, donde los que finalmente hacen el trabajo deciden sobre cómo hacerlo.
Pero para llevar esto a cabo no se puede confiar sólo en la parte técnica. Es necesario que los expertos de negocio estén accesibles y pueden resolver las dudas que surjan a medida que el proyecto avanza. Se favorece la comunicación interdisciplinar.
Además, el propio proceso de desarrollo debe evaluarse y someterse a modificaciones que permitan mejorarlo.
Varias metodologías comparten estas bases. Entre ellas, podemos citar:
- XP.
- Scrum.
- Crystal.
- FDD (Feature Driven Development).
- DSDM (Dynamic System Development Method).
- Lean.
- Etc.
A pesar de todo, es importante resaltar que el uso de estas metodologías no es apropiado para todos los casos. Hay que considerar la naturaleza de cada proyecto y evaluar si encajaría con estos principios o no.
Factores que sugieren un proceso adaptable:
- Requisitos inciertos.
- Desarrolladores responsables.
- Clientes implicados.
Factores que sugieren un proceso predictivo:
- Equipos grandes.
- Contratos con alcance y precio fijo.
Sin embargo, no todo son parabienes para estos métodos y su aparición ha suscitado amplios debates entre sus defensores y los defensores de las metodologías tradicionales. Como ejemplo, este artículo de Miguel Ángel Abián y el debate que suscitó dentro de la comunidad JavaHispano.
Referencias:
The New Metodology por Martin Fowler
Traducción al castellano del artículo The New Metodology por Martin Fowler realizada por Alejandro Sierra
Artículo de Miguel Ángel Abián sobre las Metodologías Agiles
Discusión en JavaHispano en torno al artículo de Miguel Ángel Abián
La Falacia de la Ingeniería del Software por Samuel Zarza
Waterfall vs. Agile: Can they be Friends?
