[Software Factories] Introducción (Parte 2)

Ok. Esta es la parte dos de la introducción.

Realmente no quería caer en el mismo ejemplo de libro pero lo voy a hacer. La manera en que hoy desarrollamos software es exactamente igual a como se hacian los automóviles antes de Mr. Ford. Como era esto? Bueno igual que lo que hacemos hoy, venia un cliente y decía: quiero una auto así, así y así con madera de pino de Groenlandia, cuero de jaguareté y pedales de tutú carreta, entonces se diseñaba el auto de cero, a alguno se le ocurria que lo mejor era un rodado de marfil y aluminio de 23,67 pulgadas, etc. Una vez listo el diseño se ponian con los cerruchos, martillos, un tornito y otras herramientas y en 6 o 7 meses estaba listo. Salian mas o menos bien y costaban caro. Hoy en cambio todos los autos comparten un gran número de componentes comunes entre otras cosas gracias a los estandares. Son estos lo que me permiten enchufar mi televisor en cualquier parte del pais y que siga funcionando o cambiar el cuerito de la grifería sin tener que averiguar medidas.

Esta forma de trabajo se caracteriza por:

• Uso intensivo de la mano de obra,
• Uso de herramientas demasiado genéricas,
• Mínimo reuso y, 
• Procesos genéricos

De esta manera se producen demoras en los tiempos de entrega, defectos, agujeros de seguridad y retrabajos. Además de imposibilitar la introducción de calidad desde el primer momento en cuanto a aquellos detalles diferenciadores como seguridad, usabilidad, desempeño, mantenibilidad y escalabilidad de los productos (sin causar fatigas por falencias en la arquitectura) entre otros.

Antes de continuar analizando los por qué del surgimiento de este paradigma vamos a definir algunos términos que son muy necesarios como por ejemplo el de Software Factory y luego voy a aclarar algunas cosas que me quedaron en el tintero del post anterior.

Definiciones

Software Factory

Si se le hubiese llamado de otra manera nos habriamos visto forzados a realizar un esfuerzo mental para averiguar y tratar de entender de que se trata este concepto pero desgraciadamente esta palabrita "Factory" nos habilita a pensar cualquier cosa. Las analogías que encontramos por todos lados con fabricas de zapatos o electrodomésticos terminan de confirmar nuestras fantasias mal fundadas. No son pocos los que creen que se trata de hacer software como si de automoviles se tratara, simplemente ensamblando algunas partes hechas en una linea de montaje y automatizando, robots mediantes, los detalles como el color de la pintura y otros. Bueno, no es así. La figura que adorna este post también confunde pero está muy buena para reflejar el estado actual del arte

Distingamos entre Software Factory como paradigma y como instancia. Como paradigma, es una alternativa a los métodos actuales de construcción que intenta resolver los 5 problemas planteados en el post anterior cuando las aplicaciones a construir comparten características comunes. Como instancia (SCSF por ejemplo), un Software Factory es un conjunto de herramientas, procesos tailorizados, frameworks, patrones y modelos (por lo general embebidos en los frameworks y/o herramientas integradas del IDE) y otros contenidos que usan para trabajar sobre una Linea de Productos. O mejor dicho, un SF es una linea de producto que utiliza un SF Template basado en un SF Schema.

Linea de Productos

Una linea de productos se refiere a un tipo de aplicación que puede agruparse o identificarse como perteneciente a una familia de productos como por ejemplo sistemas de CRM, software de seguros, software para entidades bancarias, de control aereo y cualquier otro. Es decir, pueden agruparse de distintas maneras, por segmento de negocios, tipo de soluciones, plataforma, etc. Lo importante es poder identificar aquellas características comunes. Tres aspectos claves de una linea de productos son: los alcances, la variabilidad y la extensibilidad. Los alcances determinan que tipo de soluciones pueden construirse a partir de la linea de productos y define por lo general la arcitectura base para la familia de aplicaciones, la variabilidad hace referencia a las parte comunes definidas en los alcances y aquellas que son variables por medio de configuración de la linea y la extensibilidad determina los puntos en los que es posible añadir funcionalidades.

Software Factory Schema

Un Software Factory Schema es un modelo general que por lo general utiliza grillas, gráficos o cualquier otro artefacto para describir cuales son los productos de trabajo, los pasos a seguir para construirlos, las relaciones existentes entre ellos. Esta es una herramienta para entender y posiblemente automatizar el funcionamiento del SF. Por ejemplo, un SF Schema puede describir los paquetes que se utilizan, la distribución f’isica de los componentes y como los distintos miembros de los equipos se relacionan con cada uno de estos aspectos. Un SF Schema se compone de Viewpoints que no son otra cosa que la descripción de todos los assets que intervienen en la generación de un aspecto del software que se desea desarrollar. Por ejemplo, un view point para la creación de un smart client podría ser la generación de la UI, en este caso el view point especificaría el conjunto de cosas necesarias para realizarlas, desde una clase base Form, diseñadores, DSL para especificar la navegabilidad entre formularios, herramientas de generación de algunos aspectos o plantillas, guias necesarias que intervienen es este punto, etc. Podría decirse que es la colección de todos los puntos de vista de un SF o el plano conceptual de este. Este plano tiene forma de arbol y cada rama trata un aspecto particular de la solución que a su vez se divide en otras ramas que los analizan desde otros puntos de vista. La definición de Viewpoint de la IEEE está en IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.

Software Factory Template

Una vez que tenemos los planos conceptuales del Software Factory que queremos construir debemos…. construirlo!! Es decir, ya sabemos que assets necesitaremos, como serán, donde intervendrán, como se relacionarán, etc. Ok, ahora hay que hacerlos. Esto es, crear los frameworks, las guias, los asistentes, los DSLs, procesos y todos los demás asstes descritos en el esquema he integrarlos (en lo posible) al IDE. Cada vez que se construye un nuevo producto, cada desarrollador puede (y debería) contribuir con el SF añadiendo sus plantillas, snippets, instructivos, frameworksy cualquier otro asset. Para más información acerca de estos últimos dos temas les recomiendo la edición número 9 de la revista The Architecture Journal y en especial el artículo de Tom Fuller "Fundamentos para los pilares de las Fábricas de Software".

Lo que me quedó en el tintero

Algo que me quedó en el tintero es el tema de las metodologias cuyo problema resumia como "o (son) muy formales o (son) uy ágiles". Greenfield  y Short  plantean (lo que a muchos nos parece obvio) que existen dos tendencias extremas con sus pros y contras. A diferencia de lo que uno podría esperar, Greenfield  y Short no creen que una metodología más formal sea más MADURA, por el contrario, entienden que son inmaduras por extremistas.

En cuanto a los desarrolladores

Luego vamos a ver como distinguen entre "tipos" de desarrolladores (este "tipos" es mio, en realidad habla del valor de los desarrolladores y distingue entre ellos a aquellos que pueden construir los Software Factories y aquellos que los utilizan) y que importancia tienen estos dentro del proceso de desarrollo. Continuo planteando este tema porque cuantas veces hemos escuchado a gerentes de sistemas/Producers/Produc Manager/Team Leadres decir cosas como "Yo quiero/necesito poder sacar a uno (desarrollador) y poner a otro y que los proyectos continuen en marcha"?. La verdad creo que estas palabras (quiero/necesito) expresan un deseo. Sí, es una expresión de deseo! pero es un deseo genuino y entendible. Yo, en el lugar de esas personas querria exactamente lo mismo pero también entiendo que eso es un intento un poco necio de negar la realidad.

Como por ahí nombro los libros o cito los autores y no quiero poner palabras mias en sus bocas les recomiendo que los lean. Aunque en este punto es coveniente citarlos de manera textual.

"Unfortunately, the industry has a tendency to become overly prescriptive, assuming that developers are naive and uninformed, and attempting to use formal processes to prevent them from making mistakes by telling them what to build, how to build, and what skills are required to perform certain tasks."

El problema mayor que describe esta frase no es sobre lo de "ingenuos" o "ignorantes" sino que producen una infrautilización de las capacidades de las personas. Esto a veces constrasta con lo que se busca en un aspirante para un puesto como desarrollor, que esté muy capacitado, que pueda demostrar logros, que pueda plantear soluciones innovativas, que sea proactivo, etc.

Steve Jobs, fundador de Apple Computer, dice en una frase célebre:

"No tiene sentido contratar a personas inteligentes y después decirles lo que tienen que hacer. Nosotros contratamos a personas inteligentes para que nos digan qué tenemos que hacer."

Por otro lado, las metodologías ágiles no son la solución tampoco porque tienen sus problemas y no son aplicables a todas las realidades o mejor dicho, se aplican a un esquema muy particular de trabajo, gente, clientes, proyectos y demás.

Que solución se plantea? Ahí viene:

 

Process Framework

La solución planteada no sorprende a nadie. La clave es preservar la agilidad mientras se mantiene la posibilidad de escalar la complejidad introducida por el tamaño y la distribución geográfica de los proyectos. Lo verdaderamente importantes es como esta posibilidad va tomando forma real mediante la implementación del paradigma de Software Factories.

Los autores siguen diciendo que el problema de las metodologias formales es que son demasiado abstractas en el sentido que para poder utilizarse deben ser tailorizadas a cada proyecto o necesidad particular. La idea detrás de esta crítica, que no lo es tal, es tailorizar los procesos a una familia de productos concreta.

Es decir, enfocar los procesos hacia las tareas puntuales de todo el ciclo de vida de una familia de productos (o product line -este concepto es importantísimo y lo explicaré mas aelante). Así, por ejemplo, debería por cada actividad facilitarse los recursos necesarios como wikis, links a documentación importante (pero facilmente accesible y no en un archivo de Word o Excel que sabe dios donde está o que se tarda más en abrirse que en buscarlo por otros medios), información de contactos, guias específicas (instructivos) sobre como realizar tarea, checklists aplicables a la tarea, estilos de codificación, detalles de cual/es es/son el/los próximo/s paso/s en el desarrollo, herramientas, políticas, etc. Todo esto debería estar integrado al IDE y en lo posible automatizado.

Como hecho un tanto anecdótico debo resaltar que Microsoft provée el MSF for CMMI Process Improvement Guidance el cual abarca las prácticas relacionadas a las areas claves cubiertas por CMMI nivel 3.

Los Procces Frameworks se componen de dos conceptos: Constraint-Based Scheduling y Active Guidance.

Constraint-Based Scheduling se refiere a dividir (o abordar) un proceso en mini procesos para la construcción de artefactos o tangibles particulares. Cada uno de estos mini procesos define: los requerimientos para producir la salida, los recursos, los pasos a seguir y las decisiones claves que pueden requerirse en cada momento. Lo de Constraint hace referencia a que entre cada uno de los mini procesos existen precondiciones y postcondiciones que deben matchaer entre ellas y a las restricciones propias del scheduling del proyecto.

Active Guidance se refiere en parte a lo que ya mencioné arriba, que en cada paso de una actividad se brinde la información necesaria para realizarla. Esto debe ser estar facilmente accesible, facilmente entendible y en tiempo real, apoyado en asistentes, plantillas autodescriptivas y que asistan al desarrollador, recomendandole acciones, documentación y ejemplos a la vez que monitorizan el cumplimento de los constraints establecidos.