He notado que muchas personas tienen una visión coincidente sobre la empresa de desarrollo ideal. Piensan que idealmente una empresa de desarrollo debería ser como una fábrica.
Una fabrica de software donde exista un proceso definido y repetible. Las actividades son planificadas y se desarrollan de manera predecible. Un plan inicial es trazado y día a día, los desarrolladores ingresan datos en un sistema que reflejan el avance al minuto. El tiempo es aprovechado al máximo porque se conoce con certeza la precedencia de las actividades, la disposición de recursos, las fechas de entrega. El conocimiento necesario para realizar las actividades esta formalizado explícitamente en documentos y cualquier nuevo componente incorporado al proceso productivo puede contar con esa información para hacer su trabajo. Existen los elementos que permiten medir la productividad de cada uno de los componentes de la fábrica y hacer ajustes donde sea necesario. Se tiene control sobre la calidad de los resultados y la productividad. Control, predecibilidad, certidumbre, calidad.
Una verdadera fábrica industrial de software.
Pero...
Hay otras personas que no creen que la fábrica de software sea posible. Y van más allá, opinan que muchos de los problemas que afronta nuestra actividad surgen del enfoque que pretende estructurar empresas de desarrollo de software como fábricas. Mike Beedle es una de esas personas y dice al respecto:
"Durante 30 años el mundo del software ha sido influenciado por las ideas de la manufactura. Todo esto comenzó cuando gerentes de manufactura tomaron empleos en compañías de desarrollo de software y se le solicito a pensadores de manufactura que pensaran sobre software. Desafortunadamente ellos llegaron con un montón de equipaje de manufactura y tratamos de aplicar las mismas técnicas usadas en manufactura en ese tiempo:
* Procesos estandarizados definidos y repetibles
* Técnicas de TQM[Total Quality Management]
* Gestión voluminosa, donde las entradas y salidas son sólo observadas como hitos de fases.
Desgraciadamente, este paradigma de fabricación no se acomoda demasiado bien al desarrollo de software. En cambio, el software requiere un enfoque mucho más parecido a un proceso de desarrollo de un PRODUCTO NUEVO , porque el software siempre es una combinación de 1) crear nuevos componentes o 2) ensamblar viejos componentes de formas nuevas.
Crear nuevos productos requiere investigación, creatividad y enfoques de prueba/error. Y esto se adapta muy bien al software porque:
detectar requerimientos,
diseñar una solución,
implementarla, y
testearla
requiere investigación, creatividad e implementaciones de prueba/error.
Por otro lado, la mayoría de las veces, estas actividades no llegan en secuencias lineales repetibles -- ellas son simplemente el resultado de inspecciones y pruebas constantes, donde cualquier actividad puede disparar cualquier otra.
Tal así, el software requieren de un nuevo conjunto de practicas y actitud, que permita que el software sea desarrollado en una manera mucho más dinámica, adaptable y auto-organizada."
También se cuestiona la idea de la fabrica de software porque no considera características de las personas, factores principales en el proceso de desarrollo. Alistair Cockburn, en su artículo Characterizing People As Non-Linear, First Order Components In Software Development expresa:
"Quizás más interesante y menos obvio ... es la manera no lineal en que las personas trabajan. Ellos no siguen un secuencia predecible para ir del problema a la solución. Esto es sabido para matemáticos y programadores, quienes se ganan la vida resolviendo problemas. Esto ha mantenido siendo un secreto para gerentes y especialistas en metodologías quienes aún tratan de hacer un proceso de desarrollo de software que sea lineal."
Mas allá de esto, la discusión sobre si se pueden aplicar principios de fabricación industrial al desarrollo de software no es la cuestión central. Pienso que la cuestión central es que queremos mejores resultados, queremos ser más productivos, queremos productos de más calidad.
Un camino de alcanzar esto ha sido observar otras actividades y detectar si hay algo que podamos aplicar en la nuestra. Otro camino posible es observar los proyectos exitosos de nuestra actividad y ver que características tienen para repetirlas en nuevos proyectos. Esto es lo que ha hecho James Coplien.
Analizando un proyecto exitoso
James Coplien escribió el famoso paper Borland Software Craftsmanship: A New Look at Process, Quality and Productivity donde documenta las conclusiones de su estudio del admirable proyecto de desarrollo de Borland Quattro Pro® for Windows (QPW).
"El desarrollo de Borland Quattro Pro for Windows (QPW) es una de las más notables organizaciones, procesos y culturas de desarrollo que hemos encontrado en el proyecto de investigación de procesos Pasteur de AT&T Bell Laboratories. El proyecto asimiló requerimientos, completó el diseño y la implementación de 1 millón de líneas de código, y completó el testing en 31 meses. La programación fue hecha por no más de ocho personas a la vez, lo que significa que la productividad individual fue mayor que 1.000 líneas de código por persona por semana."
"El producto QPW ingresó al mercado con gran aclamación. PC Sources dijo, 'Quattro Pro hace el mejor uso de la interfaz de usuario de Windows que ningún otra planilla de cálculo actual." PC User dijo que 'Quattro Pro for Windows es la mejor planilla de cálculo del mundo' Computer Shopper dijo sarcástico 'Quattro Pro for Windows supera al campeón actual de planillas de cálculo Microsoft Excel 4.0' "
Productividad y calidad impresionantes. Veamos algunos puntos que caracterizaron este proyecto:
* Alta comunicación entre los integrantes del equipo.
"El proceso de QPW tiene una comunicación superior que el 89% de los procesos que hemos observado... Es una organización pequeña e intensamente interactiva"
"El equipo de arquitectura se juntaba diariamente para elaborar las interfaces de las clases en C++, para discutir algoritmos y enfoques globales y para desarrollar los mecanismos fundamentales sobre los cuales el sistema sería construido"
* Equipo pequeño y estable con profesionales expertos en su campo.
"El equipo de desarrollo de QPW tiene una membresía cronológicamente madura para los estándares de la industria... Las personas son incluidas en el equipo por su reconocida experticia en dominios de importancia central para el proyecto: motores de planillas de cálculo, gráficos, bases de datos, y así sucesivamente... Cada uno trae un talento especial para el logro."
"QPW tuvo un equipo principal pequeño --cuatro personas-- quienes interactuaron intensamente durante 2 años para producir la parte principal del producto."
* Desarrollo iterativo.
"El desarrollo de QPW fue altamente iterativo"
* Sin proceso formalmente definido.
"Borland no está sujeto a estándares de proceso ISO 9000, no tiene noción de su valuación SEI CMM, y no es entendido en la jerga de procesos de desarrollo de software siendo usada cada vez más en grandes organizaciones de software...
Aún cuando la organización no tiene un sistema codificado de proceso, es agudamente conciente de lo que hace, como lo hace, y que funciona. Ven el desarrollo de software como algo fundamentalmente conducido por casos especiales (al menos para desarrollo inicial genérico) y la repetibilidad no es una parte importante de su sistema de valores. No obstante los miembros de la organización fueron capaces de articular con gran detalle aspectos de su proceso que demostraron para mi satisfacción que ellos compartían un único modelo, tal vez basado en reglas de desarrollo, de como el desarrollo debe ser realizado."
Un conjunto de personas conformaron un equipo de desarrollo asombroso basados en alta comunicación, retroalimentación constante, idoneidad de sus integrantes y valores compartidos. No eran una fábrica de software.
Conclusión
Pienso en este proyecto y me tomo la libertad de sacar algunas conclusiones rápidas casi imprudentes:
Tal vez no nos hace falta un proceso formalmente definido.
Tal vez no nos hace falta un proceso repetible.
Tal vez no nos hacen falta actividades predecibles.
Tal vez no nos hace falta control absoluto.
Tal vez no hace falta parecernos a una fábrica.
Tal vez simplemente deseamos empresas donde proyectos como el QPW sean posibles, y contar con las personas que lo hagan posible.
No hay comentarios.:
Publicar un comentario