Desarrollo aplicativo formal

Relacionar la idea de la formalidad con el desarrollo aplicativo de software puede significar algo muy positivo en tanto signifique exactitud, puntualidad y consecuencia en las acciones durante dicha actividad (sin mencionar las apasionantes facetas que tiene la idea de formalidad al estudiar algo por su objeto formal en los tratados de lógica). La seriedad y compostura juegan de lado del valor de negocio en contraposición al desorden y la insensatez; como ejemplo, al ignorar por completo —una y otra vez— los rasgos que caracterizan a la creación de soluciones de negocio basadas en software como lo es el concepto de emergencia (acción y efecto de emerger) por el cual es propicio para un negocio estar consciente del modelo co-evolutivo solución/problema.

Por otro lado, una connotación popular de la palabra formal es simplemente otra manera de decir tradicional, lo ya conocido, lo ya establecido. Es en este insípido significado que se usa ocasionalmente —en la parte de la realidad que alcanzo a advertir y aplicado a proyectos de desarrollo de software aplicativo— como queriendo decir que es de gente adulta y profesional el tener, por ejemplo, un diagrama de Gantt debidamente detallado por el cual se guía todo el esfuerzo definido por un contrato, también tradicional.

Sin embargo, el problema perenne en el desarrollo aplicativo tradicional, es decir "formal", es:

¿Satisfacemos la emergente necesidad de negocio del usuario/cliente o satisfacemos los ya anacrónicos contrato y gráfica de Gantt?

Si es el contrato y el Gantt, ¿a costa de que el esfuerzo derive en algo que no le servirá al usuario/cliente y no resulte en retorno de inversión?

Si es la emergente necesidad de negocio, ¿a costa de arriesgarse a sufrir penalizaciones por incumplimiento de contrato?

¿No hay más opciones? ¿No hay acaso una diversidad de planteamientos del estado del arte en desarrollo de software para conducir la relación cliente y proveedor hacia el valor de negocio real? ¿En qué están tan distraídos quienes venden y pactan proyectos de desarrollo aplicativo de software como para estar dándose el lujo de perder oportunidades para elevar el estado de la práctica en esta área? ¿Será que en realidad no tienen ningún interés genuino en elevar el estado de la práctica?

Por ejemplo, las siguientes obras contienen tanto ideas novedosas como ideas que ya han sido propuestas desde hace tiempo. Se trata de perspectivas útiles que demuestran un entendimiento cabal de nuestro problema perenne así como de las alternativas de solución. La información ahí ha estado ¿cuál es la excusa? ¿Qué pasa con la educación del liderazgo en esta industria, es decir, con el cambio de su mentalidad?

(1) Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results

(2) Lean-Agile Software Development: Achieving Enterprise Agility