¿Cuál es el algoritmo del éxito?

En SG #48, algunos puntos para discutir sobre el ejercicio metodológico en creación de software: ¿Cuál es el algoritmo del éxito?

Scrum Nexus

Recién Ken Schwaber comentó sobre Nexus. al parecer, el uso y demanda de Scrum ha aumentado de unos años para acá. Quizá Scrum es ahora el más popular entre los métodos ágiles de aquella época en que se publicó el Manifiesto Ágil. Una de las preguntas frecuentes hacia los creadores de Scrum, según observo en algunas comunidades de desarrollo, es: ¿cómo aplicamos Scrum en proyectos cada vez más grandes y con múltiples grupos de desarrollo?, i.e., ¿cómo escalar Scrum?

Suele ocurrir algo con lo popular, sin embargo. Gerald M. Weinberg lo describe en su Ley de la mermelada de frambuesa: entre más se esparce un poco de mermelada en la superficie de un pan, menos mermelada le toca a cada parte de ese pan. Es decir, entre más popular se hace Scrum, tanto su teoría como su práctica se diluyen cada vez más hasta que se convierte en algo casi irreconciliable con Scrum. Por ejemplo, desde las primeras etapas del desarrollo del esquema conceptual de Scrum, por la década de los noventas, se consideró al control empírico como guía durante el ciclo de vida del software; en contraste, en donde Scrum se ha hecho popular hoy suele pasarse por alto ese simple hecho de la historia de lo que se dice practicar.

Mi sugerencia –también aquí– es regresar a los básicos de Scrum, e intentar no caer en la tentación de “escalarlo”. Por ejemplo, regresar a los básicos de Scrum significa preguntar e indagar: ¿qué es controlar empíricamente?

De cualquier forma, el regreso a los básicos incluye analizar y comprender las perspectivas de su evolución. Por eso tiene mucho sentido indagar sobre Nexus, y sobre otros esfuerzos y análisis sobre las condiciones en que “escalar” métodos ágiles no ha terminado en desastre. Un par de ejemplos de esos análisis es este y este.

La miseria de la univocidad

En desarrollo de software, como profesión, hay, por supuesto, diversidad de perspectivas sobre qué es calidad y cómo lograrla en la realidad. También aquí, como en política o en religión, tal diversidad se distribuye a lo largo de una amplia gama de posiciones agrupadas en múltiples dimensiones de la creación de software; por ejemplo, la dimensión de la administración de un proyecto o un conjunto de proyectos (también llamado portafolio de proyectos), o la dimensión financiera de inversión y su retorno, o la dimensión de operación sustentable y niveles de servicio, o la dimensión de arquitectura y diseño a lo largo de múltiples niveles de abstracción, etc.

En administración de proyectos hay desde el extremo fanático del estricto comando y control jerárquico del «taylorismo posindustrial», hasta el otro extremo fanático en el jardín hippie del subjetivismo radical donde el «cowboy coding» reina supremo.

La creación de software puede ser una fascinante aventura intelectual para el profesional que se interesa por la historia de su profesión. Se requiere investigar el contexto de una posición histórica y sus razones de fondo para luego contrastarla con el contexto y razones de otra posición. Esta clase de reflexión histórica es para mí esa aventura intelectual y profesional. Pero se requiere mantener la curiosidad y las ganas de entender qué es crear software como profesión. Además, se requiere valorar la otredad, la heterodoxia y la inclusión de perspectivas diferentes a la propia. De otro modo –es decir, desde la ortodoxia–, se corre el riesgo de interpretar toda otra perspectiva desde la premisa de que es inferior en todos los casos.

Un enfoque inclusivo permite un desarrollo profesional amplio y diverso, un desarrollo que agrega cada vez más herramientas de pensamiento y práctica. Así, la cantidad de opciones a disposición de ese practicante reflexivo a la hora de tomar decisiones de diseño, o de arquitectura, o de administración, no queda restringida a las opciones que ofrece la miseria de la univocidad.