La semana pasada se celebraba en Kotasoft (una fábrica software orientada al desarrollo de productos de alta calidad como estrategia de su negocio y con la que kybele consulting colabora) una de las múltiples reuniones sobre la creación y mejora de la fábrica.
Desde los comienzos, por la particularidad de la organización, de la fuerte preparación de sus profesionales, etc., se definió que por lo general el ciclo de vida de sus proyectos sería iterativo – incremental orientado por casos de uso. Algo más complejo de gestionar que un clásico cascada pero con mayores y destacados beneficios: velocidad, mayor control del acercamiento del producto a los requisitos del usuario, conocimiento progresivo, reducción de riesgos, etc.
Dicha reunión propicio interesantes dudas, debate, enseñanzas, reflexión y motivo para este post, respecto sobre si al utilizar ciclos de vida iterativos – incrementales por casos de uso estábamos por ello enmarcando a la fábrica bajo la metodología UP (unfied process, también conocido como RUP, rational unified process)
En ingeniería del software las metodologías han sido uno de los temas sobre los que más se ha escrito. Desde los primeros métodos estructurados, que suponen la primera generación de metodologías (destacando a Yourdon y Constantine), a la segunda generación, con metodologías muy centradas en el paradigma orientado a objetos (destacando a Booch, OMT, Objectory, RDD, etc.), hasta la tercera, formada por los llamados métodos ágiles o ligeros (destacando a XP).
Las metodologías han propiciado durante años numerosas discusiones sobre su idoneidad, sobre cuál es “la mejor”, etc., discusiones muy pasionales en la mayoría de las ocasiones.
En el desarrollo software actual, fruto de la rápida evolución de la ingeniería del software y del aprendizaje que la disciplina ha recibido de aplicar todas estas metodologías, sabemos que no existe, y probablemente no existirá, una única y gran metodología, mejor que todas las demás. Una gran y única “Big-M” (big methodology) de libro, como denomina Cockburn a aquella que recoge de manera global y para uso general roles, responsabilidades, actividades, cadena de valor, etc., que debe seguir el desarrollo software.
La que podríamos denominar “cuarta generación” asume que hay y debe haber múltiples metodologías, no sólo “de libro” sino por cada empresa, e incluso en ocasiones por cada proyecto y equipo. Si bien las organizaciones muestran rasgos comunes que hacen que muchas partes de estas metodologías sean aplicables en unas y otras.
Todo ello ha propiciado una “componentización” de las metodologías en elementos de menor granularidad, que combinados de la manera más idónea para una organización concreta crean la mejor metodología para la misma. Estos “componentes” de menor nivel son los que algunos autores (quizá el más destacado sea McConnell) denominan “buenas prácticas”. Y entre las que podemos mencionar de manera general aquellas centradas en la medición (criterios, automatización, etc.), integración continua, “smoke” test, gestión de riesgos, diferentes métodos de estimación (puntos caso de uso, puntos función little, etc.), trazabilidad, el énfasis en las personas y el talento, reutilización, etc.
Sin olvidar las “buenas practicas” referentes al ciclo de vida: la construcción incremental, el concepto de iteración y que con consideraciones el modelo cascada es válido.
A un nivel de abstracción mayor lo que en muchas ocasiones define el conjunto de buenas prácticas que definirán la metodología de la fábrica será la estrategia de la misma: líneas de producto, COTS, MDA, etc. Y lo más importante: todo ello siempre en línea y definido por el modelo de negocio de la organización.
Utilizar una buena práctica de una “Big-M” (UP en nuestro caso) no implica tener que seguirla por completo; lo mejor es tomar de cada una de ellas las mejores prácticas, las que más se adapten al tipo de desarrollo de la organización, a su estrategia de desarrollo, definiendo su propia metodología, sin tener la obligatoriedad de usar aquellas cosas que no se le adaptan o que no son necesarias.
Otro aspecto de suma importancia es cómo seleccionar una buena práctica frente a otras, cuales son las existentes, como seleccionar la estrategia de la fábrica en función de su negocio, etc., pero esto lo dejamos para otra conversación.
Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
