Desinformación y Verdades a Medias de Metodologías Ágiles

Timothy Fitz escribe en su blog una nota acerca de la definición real de una metodología ágil.

Inicia diciendo que está cansado de la desinformación:

• Agile means writing software without writing documentation.
• Agile means not caring about the long term.
• Agile means engineers get to decide the project’s features.
• Agile means not having strict practices.

También de las verdades a medias derivadas de ciertas prácticas:

• Agile means pairing.
• Agile means Test Driven Development.
• Agile means scrum.

Ingeniero vs Arquitecto

El énfasis de la solución del ingeniero de software se encuentra en los aspectos técnicos. La del arquitecto en el contexto del negocio.
La razón principal de la Arquitectura de Software reside en el que el análisis y diseño no son suficientes para resolver el problema. En la mayoría de los sistemas empresariales es muy importante tomar en cuenta los requerimientos no funcionales (conocidos también como Atributos de Calidad). En la presentación de Arquitectura de Software (SG 2007) se encuentra mayor información – láminas 6 – 49.

Alan Cooper resume muy bien esta idea:

Architects synthesize people, purpose, and technology. If you just take people and technology, you have art and entertainment. If you just take technology and purpose, it’s engineering. And people and purpose without technology is psychology. Architects have to synthesize all this, to create a vision of a solution. People must get something practical achieved.

Software Entropía

La entropía es un término de termodinámica que significa la cantidad de desorden en un sistema.

En el desarrollo de software, algunas veces está ligada a la forma de ver las cosas por las personas. No creo que sea solamente de una cultura en el trabajo, si no que es una forma de vida. Por ejemplo, pareciera ser que a algunas personas les gusta dejar su desorden por todos lados, para ellas son solo detalles insignificantes, sin embargo no son conscientes de que estas “pequeñeces” generan un gran desastre y afectan a otras personas e inclusive a la institución para la que trabajan – un efecto sistémico.

La lección es que hay que atender los problemas cuando son pequeños antes de que el problema sea mayor, o de plano no tenga solución.

Hay dos muy buenas alegorías respecto a esto:

1. Efecto de la rana hervida (Boiled Frog Effect). Cuando ponemos una rana en una olla de agua sobre la estufa, y subimos la flama poco a poco, la rana no puede detectar el cambio de temperatura hasta que muere.
2. Reparar las Ventanas Rotas (Fixing Broken Windows). Considerar la posibilidad de un edificio con algunas ventanas rotas. Si las ventanas no se reparan, la tendencia es que los vándalos rompan los vidrios de más ventanas. A la larga, pueden incluso entrar en el edificio, y si está desocupado, tal vez convertirse en ocupantes ilegales. Este es el fundamento de la más reciente campaña del Consejo de la Comunicación, “No te calles, ¡¡alza la voz!!” – Un delito grande empieza por uno pequeño.

Acerca de las Metodologías de Software

Una metodología de software es un conjunto de procedimientos documentados y organizados para la realización de una o varias fases del ciclo de desarrollo de software. Muchas de estas metodologías incluyen una notación (generalmente en forma de diagramas) utilizados para documentar los resultados, una guía paso a paso para la elaboración de los procedimientos y un conjunto de criterios para determinar que los resultados son de una calidad aceptable.

En el blog de Gavin King leí una nota acerca de sus reflexiones sobre metodologias de software:

• methodology is important in an environment where developers are viewed as interchangeable resources
• methodology is important in an environment where developers have heterogeneous ability/experience levels
• methodology helps achieve predictability, but gets in the way of innovation

Desde mi punto de vista, es completamente diferente el desarrollo de productos de software en un ambiente opensource que en uno empresarial.