[Software Factories] Software factory (la historia sin fin)

Software FactoryHace una año comencé la serie Introducción a los Software Factory con 4 entradas: [Software Factories] Introducción (Parte 1), [Software Factories] Introducción (Parte 2), [Software Factories] Introducción (Parte 3) y [Software Factories] Introducción (Parte 4)

Hoy quiero exponer los desafios que plantea la implantación de una software factory en el mundo real.

Veamos….

  1. Al hablar hoy de software factories uno puede revivir el sentimiento de frustración que sentia 15 años atras cuando hablaba de programación orientada a objetos. Nadie sabe muy bien de que se trata pero en lugar de interiorizarse y comprarse un buen libro, prefieren dejar volar su imaginación y crear sus propias definiciones. Recuerdo a una profesora de la universidad inventando toda una teoría paralela mientras que alumnos atormentados se preguntaban si un caso de herencia múltiple entre una clase Hombre y otra Lobo daba por resultado un Hombre-Lobo o algún otro ser mitológico. Con los conceptos de SF hoy sucede exactamente lo mismo. 

    Otros confunden las clases con los objetos en el sentido de que piensan que los software factories son SCSF, WSSF, WCSF o simplemente «cosas que se hacen con VS». Es decir, no diferencian entre un conjunto particular de instancias de SFs horizontales, en este caso hechas por MS como son SCSF y WCSF, y los conceptos en los que se sustentan.

    Esto trae aparejado el siguiente pensamiento:

    1. ¡Nooo, pero para eso falta muchísimo!. (visión developer) Esta es con total seguridad la más común y se compone de dos facciones, los que están en lo cierto (hay avances pero estamos en veremos) y los que piensan que desarrollar software con una SF es algo parecido a «tomo un módulo de ventas, se lo incrusto a este otro de stock… lo pego con dos piecitas de biztalk, lo envuelvo en este estandard y listo!!», esto es producto de las desafortunadas analogías con industrias como la automotríz o la aeronáutica las cuales son de producción y no de desarrollo.
    2. ¡Es muy riesgozo y nosotros ya tenemos un proceso de producción de software!. (visión PL/PM) Esta es la misma pero con una diferencia importante: aquí es posible hablar de reducción de costos, tailorización de procesos, beneficios en el time-to-market, es decir, es mucho más sencillo traducir los conceptos al idioma de un PL que habla en $$$ al de los desarrolladores que hablan en C++. También es posible interesarlos con los casos de éxito de HP, IBM, Nokia y otros, o alinearlo con objetivos de negocios o con las iniciativas de mejora de la calidad y de reuso de software o alguna otra.
       
  2. Si los manager entienden del tema todavia es muy dificil por cuanto se trata de una «inversión» que posiblemente no se alcance a recuperar por lo que querran estudiar el tema (lógico!). Si después de que los números los convenzan, si logran ignorar a los miedosos, deben esponsorear el proyecto de cambio que, piloto de por medio, movilizará a referentes de todas partes a tomar acciones como:
    1. Tailorizar el o los procesos para adecuarlos a la manera de trabajar que se lleva en los proyectos de esa familia de productos.
    2. Gestionar la comunicación interna para informar a todos los involucrados sobre la nueva manera de pensar y hacer software. Estos cambios siempre despiertan curiosidad y motivación en la gente por lo que abre las puestas para que se los involucre en las nuevas tareas. Además todo el mundo tendrá preguntas y sugerencias. Si esto no se hace lo que se generará será alguna variante del temor.
    3. Seleccionar al equipo de desarrolladores que construirá  el SF. Aquí el arquitecto es pieza clave y debe tener ante todo un conocimiento muy profundo sobre el dominio.
    4. etc. Digo etc. porque estos puntos y otros ya los traté en las introducción (parte 2)

 

En una lista de consideraciones tan escueta podemos ver que existen varias condiciones que probablemente al principio no se tenian en cuenta como que llevan tiempo y dinero y que la fase de codificación es solo una pequeña parte de la cuestión, que involucran a roles de administración de proyectos, gestión de la configuración, especialistas de testing, ingenieros de campo, desarrolladores obviamente y otros, que habrá que mantener la SF, que tendrá que capacitarse a la gente que la utilizará, que debe verse como una inversión a recuperar y que esto sucederá a medida que se vayan entregando proyectos en los cuales se hayan reducido los costos gracias a la utilización del SF, que es una apuesta a largo plazo, y otras cuantas más, pero la síntesis seria algo así como: «Creiste que era más facil ¿no?»

 

Existen pruebas de que esto no es facil, solo hay que ver como los distintos elementos que conforman el sistema de una SF se han ido utilizando como quick fixs que de a uno logran verdaderamente muy poco. Hay quienes todo lo pretenden resolver con un framework, otros intentan sin exito entender para qué sirven los DSLs y cual es la diferencia con los frameworks, otros utilizan VS (GAT/GAX) para verdaderas nimiedades, los procesos apenas si se alteran en algo.Pero ayer me he dado con una prueba curiosa pero contundente de que esto no es facil, al toparme con este paper de M. L. Griss del año 1993 en el que se plantea la necesidad de crear SFs, y los llama así: Software Factories. Griss comenta los casos de éxito en las iniciativas de SF de distintos monstruos de la economia. Hoy seguimos hablando de los mismos temas.

 

Lucas Ontivero

Sin categoría

5 thoughts on “[Software Factories] Software factory (la historia sin fin)

  1. Hey amigo Lucas, como no podía ser de otra manera, sigo tus posts de manera asidua y realmente me gusta que uno de los mensajes que siempre dejas leer entre lineas, es la necesidad de formarse antes de comenzar a hacer algo. (En otros casos mucho más peligrosos, formarse antes de opinar sobre un tema !!!)

    Creo que como dices, muchas personas confunden SF con generadores de código, o con frameworks, o con una metodología super-ultra-mega-hit; pero la idea central detrás de todo esto, que es encontrar la solución a un problema general, no está tan clara.

    Por otra parte, creo que para los Developers, es mucho más simple comprender el concepto de una SF, ya que manejan conceptos de abstracción y pueden llegar a comprender un lenguaje de dominio específico, comprender como ayuda este aislamiento, etc.

    Sin embargo, en el plano gerencial, la apuesta es muy diferente: apostar X cantidad de €€€ por un producto que no da resultados inmediatamente es una fórmula que muy pero muy pocas personas compran. Más aun, cuando la fórmula clásica de castigar a los equipos de desarrollo con horas y horas de trabajo extra, sigue funcionando (o eso parece).

    Para cerrar, del 1993 a esta parte han pasado una pila de años, pero los problemas siguen siendo los mismos; ¿será por eso que la informática no termina de convertirse en ciencia? (joke un tanto o demasiado friki)

    Saludos

  2. No puedo estar mas de acuerdo con lo que comentas. Sé que vos estas muy en el tema bajando los conceptos a tierra por lo que aprecio tus comentarios en este espacio.
    Ya que estamos, conozco de tu trabajo con DSLs, algún día podrías comentar los resultados? eso sería muy interesante.

    Saludos

  3. Yo cada vez que oígo Taylor e ingeniería del software en el mismo escrito siento escalofrios…: http://geeks.ms/blogs/rcorral/archive/2006/09/22/Taylor-se-equivoco_2E002E002E00_.aspx

    Se que muchos no los véis como yo, pero sinceramente, pensar que se puede plantear el desarollo de software con la repetición, la reutilización y el esamblado y configuración de piezas de software me parece repetir la historia: nos lo vendieron con los 4GL, no los vendieron con la orientación a objetos, y con la orientación a componentes y ahora nos lo venden con los DSL y las SF… Todos han sido avances pero ninguno definitivo, ninguno a sido la bala de plata que nos prometian y mirando atrás, la conclusión que saco es que nada nuevo que nos propongan en esa línea será la solución completa.

    La solución viene del lado de las personas y los equipos, no del lado de las herramientas y los procesos. Peopleware lleva 30 años escrito y seguimos ignorandolo…

    Saludos!!!

  4. Yo tampoco pienso que se pueda plantear el desarrollo como la repetición y ensamblado de piezas, por eso mismo traté de dejar bien claro que esas cosas solo estan en el imaginario de las personas que no entienden de que se trata ni quieren tomarse el tiempo necesario para intentar entender. Y es que hay mucha confusión con este tema y por eso le he dedicado tanta lineas (más que a cualquier otra cosa hasta ahora).

    Otra cosa que está clara es que, como bien dices, todos son avances pero no hay balas de plata, no las hay ni las habrá nunca. Esa es una de las cosas de las que estoy mas seguro. Justamente es por esto mismo que refiero a un papel de hace exactamente 15 años en el que, si se le echa una mirada, el señor Griss plantea los mismos problemas a los que nos enfrentamos hoy en dia. ¡Increible! ¿o no?

    Ahora, el tema de taylor y los procesos es mas un diferencia dialéctica que conceptual. La palabra taylorización parece no encajar cuando hablamos de desarrollo de software, lo sé. Otra palabra malsonante podría ser «procesos».

    ¿Por qué digo que son solo diferencia dialéctica y no de fondo?. Porque si en lugar de decir:

    «Taylorizar los procesos» digo: «Adecuar las mejores prácticas a estos productos» queda mucho mejor y a nadie le sonaria mal. Pero es cierto que la solución viene por la gente, en sí una organización solo es un montón de gente trabajando, pero la mala fama de los procesos viene por el exceso de fé que se les supo tener, pensando que sería posible hacer software como juguetes chinos cosa que, está de más aclarar, no es cierto. Este exceso lleva a la burocratización de las operaciones y a las parálisis. Pero no es este el tipo de procesos al que me refiero en el artículo sino a las acciones por medio de las cuales transformamos los requerimientos en software.

    No existe organización que no tenga procesos, lo que sucede a menudo es que no los tiene definidos «en un papelito» o «formalizados» de alguna manera pero, si yo le pago a alguien por un software y al cabo de un tiempo me entrega lo que le pedí entonces hubo un proceso.

  5. Acabo de terminar de leer parte 1 y 2 y, es perder el tiempo seguir leyendo porque el enfoque es confuso y negativo, te explico porque.
    1.-La falta de éxito en los proyectos de desarrollo de sistemas de información o cualquier proyecto, se debe principalmente a razones NO TECNICAS, sino de dirrección, planificación, control y soporte al personal que trabaja, siendo este último el principal problema.
    2.-Las fabricas de software son posibles y son exitosas en empresas cuyo «core» del negocio es eso, fabricar software y puede ser a la medida o estandarizada, al igual que ocurre con los autos.
    3.- Romperte la cabeza o tratar de entender estos concepto desde tu enfoque de desarrollador es una utopia, es como creer que un obrero de la línea de fabricación de Ford, le diga los dueños o gerentes cual es la mejor forma de fabricar (podrian sugerir, pero su chamba es hacer la parte que se les encomendo y bajo acuerdos de niveles de servicios)
    4.- Si quieres usar tu inteligencia de manera libre e innovadora, deja de ser estrucurado, deja de leer libros que solo te confunden y limitan tu visión de lo que realmente es una fabrica de software.
    5.- Finalmente, te sugiero que leas articulos y opiniones sobre Fabricas de Servicios y me entenderas mejor.

    Saludos y espero que lo publiques

Responder a rcorral Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *