Lectura # 6
De Procesos y de Humanos
“Hay ciertos privilegios comunes a un escritor cuyos beneficios, espero, no haya razón para dudar; particularmente, que si no se me entiende, se debería concluir que algo muy útil y profundo se esconde debajo; y también, que si cualquier palabra o frase es impresa en un carácter diferente, debería pensarse que contiene algo extraordinario o ingeniosamente sublime.”
Jonathan Swift, A Tale of a Tub, Prefacio (1704)
Jochen Krebs dice en un artículo reciente: “Seguir un proceso de ingeniería de software implica un compromiso con la consistencia y estandarización.”1 Y más adelante expone: “Desde una perspectiva organizacional, emplear especialistas certificados en RUP crea un ambiente consistente para la comunicación y la colaboración entre los miembros del equipo del proyecto y los demás involucrados, lo cual es la base para la eficiencia y la productividad.”2
Esta misma convicción me acompañó desde el instante en que la irreparable voluntad del destino me condujo a usar RUP por primera vez hace ya unos seis años que, convertidos a “años TI”, bien podrían ser treinta o cuarenta. Pero también desde entonces me inquieta férreamente, como una espina clavada en el cerebro, el motivo por el cual en una cultura como la nuestra no hayamos logrado la madurez suficiente y necesaria para enfrentar todos y cada uno de nuestros proyectos con el éxito debido. Pues bien, este es un nuevo intento por remediar esta situación. Hablemos de Procesos.
Definición 13: Un proceso es un conjunto de pasos o acciones parcialmente ordenadas mediante las cuales se busca un objetivo. Un proceso define quién hace qué, cuándo hacerlo y cómo alcanzar ese objetivo.
Lo primero que se me ocurre agregar a esta definición sistémica es que no tiene nada que ver con artefactos documentarios o el puro acto de documentar. Lo aclaro porque en mis continuas asesorías todavía me encuentro con la excusa de “es que nosotros no seguimos ningún proceso porque no hay tiempo para documentar.” Ahora bien, en este contexto, “parcialmente ordenadas” significa que no siempre tenemos que seguir caminos iguales. Es otra aclaración importante porque tendemos a creer que un proceso es una receta o una fórmula que siempre debe llevar los mismos ingredientes y prepararse de idéntica forma y no es así: un proceso se configura o se adapta, no solo para cada empresa, sino para cada proyecto. Y para el caso de la TI, el objetivo del proceso es desarrollar un producto de software nuevo (y estoy usando un término bastante general al decir “producto de software” porque soy de los que consideran al software como un medio y el verdadero producto es el conocimiento contenido en el software), o hacer el mantenimiento de uno existente. Justamente, otro error común es creer que no podemos dar soporte a un sistema de software usando un proceso si este sistema no fue desarrollado originalmente usando ese proceso.
En la segunda parte de la definición, Quién se refiere a los practicantes, actuarios (no actores) en el sentido de actuar, o a los ejecutantes de las acciones. Normalmente es un equipo de personas y, hoy más que nunca, de máquinas y herramientas a nuestra disposición. Entre tanto el Qué da cuenta precisamente de las acciones o pasos que se ejecutan o llevan a cabo por esas personas o herramientas. Son funciones que se suceden en el tiempo, pero que se repiten continuamente una y otra vez (de forma iterativa) hasta alcanzar el resultado esperado. Se trata de tareas más o menos simples, muchas de ellas mecánicas, que se pueden hacer en días o en horas. Esta sucesión de momentos redundantes señalan el Cuándo del enunciado; son instantes que se multiplican durante un proyecto y en muchos proyectos, de tal forma que con el paso del tiempo podemos llegar a predecir con gran exactitud cuando pasarán y cuanto tardará su ejecución; al menos esa es la presunción al usar un proceso: estimaciones más precisas y la conversión del mal llamado “arte” de la programación de computadores en Ingeniería, en ciencia numérica que pueda ser cuantificada. Y finalmente, el Cómo, constituido por los medios, las herramientas (y no me refiero siempre a maquinaria) y las técnicas proporcionadas por el proceso, que no son más que una suma de prácticas documentadas que han funcionado al menos una vez para al menos una persona en al menos un entorno.
Esto último es muy importante asimilarlo con cuidado, porque también tenemos la tendencia a asumir que todo lo que está por escrito sirve para cualquier ocasión cuando una buena práctica es medir distintas variables relacionadas con el hábitat, con los miembros del equipo, con la economía, con la cultura y hasta con la idiosincrasia de las personas para decidir cual es la mejor trayectoria a seguir.
Un proceso se documenta: esto mejora su difusión en cada una de las dimensiones de la compañía que lo adopta, clarifica conceptos y estandariza el uso del mismo. También permite la medición del mejoramiento del proceso. Con esto en mente, un proceso se sigue: lo que pasa es que el seguimiento no es del tipo “receta de cocina”, es decir, no siempre tenemos que participar de acciones semejantes, construir artefactos semejantes, ni actuar tipo “robot” sistemático. Eso ocurre esencialmente porque los actuantes del proceso medimos además variables del ambiente en el que nos transportamos a través del ciclo de vida del desarrollo del software. Variables como el tiempo disponible, la criticidad y complejidad del software, el equipo del proyecto (aspectos como experiencia técnica, conocimiento del negocio y del proceso usado influyen), herramientas de apoyo, modo de utilización del proceso, entre muchas otras, se usan para adaptar el proceso al proyecto que está iniciando.
En ese orden de ideas, un proceso puede ser pequeño al comienzo: y es una buena práctica que sea pequeño para empezar a usarlo. De hecho, es posible emplear sólo una pequeña parte del proceso: la fase de inicio, por ejemplo, o solamente una disciplina como la Gerencia del Proyecto a lo largo de todo el ciclo de vida. De esta forma, luego de aplicar esa porción del proceso, medimos los resultados, mejoramos esa parte del proceso, de ser posible, y la divulgamos al interior de la empresa. Más adelante usamos otra fracción del proceso, quizás junto con la anterior, y vamos creciendo con el.
Y algo muy importante: un proceso no tiene que ser perfecto. Es más, ninguno lo es. Y hay más: un proceso nos indica que hacer bajo ciertas condiciones, que bien podríamos llamar “ideales”. Por ejemplo, un proceso no dice que hacer si al equipo de desarrollo le faltan dos personas intempestivamente o si hay problemas técnicos que no son solucionables a corto o mediano plazo. Lo que sí hace es dar ideas (prácticas documentadas) de qué hacer en casos como esos. En resumen: un proceso no dice que hacer en tiempos de crisis. Es en esos momentos cuando toda nuestra razón, nuestros conocimientos, nuestra praxis (hablo de los seres humanos actuarios del proceso) y nuestra pragmática se debe poner de manifiesto para superar el trance.
Importante es que un proceso vaya de la mano con un programa de entrenamiento para el manejo de las habilidades de las personas que usan el proceso. El proceso no hace nada por sí solo, ni las herramientas, son las personas las que, con cierto grado de conocimiento del proceso y de experiencia en el rito procesal, lo siguen, lo ejecutan. Lo que no debe ocurrir es que el proceso de pie a interpretaciones diversas. El proceso debe ser claro, no ambiguo, preciso, sin que ello quiera decir inflexible. Al final, el proceso debe contar con unas bases para el mejoramiento continuo de la calidad y he aquí la primera premisa de lo que se ha llamado Mejora de Procesos: “La calidad de un producto es determinada en gran medida por la calidad del proceso que es usado para desarrollarlo y mantenerlo”3.
Y para finalizar esta disertación sobre Procesos y Personas, me resta decirles que un proceso debe usar las mejores prácticas probadas en la industria, no sólo la última moda en materia de guías o actividades. Un proceso debe estar bien establecido en el medio donde se utilizará, ser familiar a los miembros del equipo de desarrollo, a los clientes, a los usuarios (de alguna forma), a los socios de negocios y a todos los involucrados en el proyecto. No podemos forzar el uso de tal o cual práctica que aprendimos en un libro de aparición reciente o que escuchamos en la conferencia de la noche anterior.
Y más aún, un proceso debe ser práctico, esto es, entregar la información que se necesita, cuando se necesita y en un formato y medio usable. Y con el temor de ser incisivo: el proceso debe adaptarse a las necesidades de quien lo usa, es decir, un proceso debe proporcionar los mecanismos para que sea configurable de acuerdo al proyecto.
¿Y todo esto qué tiene que ver con RUP? Pues bien, RUP es un proceso pensado en principio para desarrollar software. RUP posee todas esas características a las que me acabo de referir. La entrada de RUP son los requisitos, nuevos o cambiados; la salida de RUP es el sistema, nuevo o cambiado. Pero lo más importante, es un sistema de alta calidad, como lo exigen los estándares de la industria.
Pero para hablar de RUP tendremos todo un volumen, a partir de la próxima lectura fundamental. Por ahora quiero dejarlos con estas tres leyes del proceso de software, algo como para tener siempre presente:4
La Primera Ley del Proceso de Software
Los procesos solamente nos permiten hacer cosas que ya sabemos hacer.
El Corolario a La Primera Ley del Proceso de Software
No puedes tener un proceso para algo que no hayas hecho nunca ni que sepas como hacer.
La Creación Reflexiva de Sistemas y Procesos
1. La única forma de crear sistemas efectivos es a través de la aplicación de procesos efectivos.
2. La única forma de crear procesos efectivos es a través de la construcción de sistemas efectivos.
El Lema de la Tardanza Eterna
Los únicos procesos que podemos usar en el proyecto actual fueron definidos en proyectos previos, que son diferentes de éste.
La Segunda Ley del Proceso de Software
Solamente podemos definir procesos de software a dos niveles: uno demasiado vago o uno demasiado limitante.
La Regla de la Bifurcación del Proceso
Las reglas de los procesos de software muchas veces se dictan en términos de dos niveles: una sentencia general de la regla y un ejemplo detallado específico (valga el ejemplo: La Segunda Ley del Proceso de Software).
La Hipótesis Dual del Descubrimiento del Conocimiento
· Hipótesis Uno: Solamente podemos “descubrir” el conocimiento en un entorno que contiene el conocimiento.
· Hipótesis Dos: La única forma de declarar la validez de cualquier conocimiento es compararlo con otra fuente de conocimiento.
La Observación de Armour sobre el Proceso de Software
Lo que todo desarrollador de software realmente quiere es un conjunto de reglas riguroso, hermético, concreto, universal, absoluto, total, definitivo y completo que se puedan romper.
La Tercera Ley del Proceso de Software
El último tipo de conocimiento a ser considerado como candidato para la implementación en un sistema de software ejecutable es el conocimiento de cómo implementar el conocimiento en un sistema de software ejecutable.
Las Metas Gemelas de la Terminación Óptima
1. La única meta natural de un grupo de procesos de software debería ser alejada del negocio tan pronto como sea posible.
2. El resultado final del desarrollo y aplicación continuos de un proceso efectivo será que nadie realmente tiene que usarlo.
Quizás el único comentario que me queda por hacer es que los procesos y los modelos no pueden separarse de la forma como pensamos los seres humanos. Más que cualquier otra cosa, el desarrollo de software es una actividad pensante. Como humanos, sólo pensamos en términos de modelos. Las restricciones de estos modelos nos asisten en la actividad pensante, pero también nos restringen y pueden aún conducir el resultado de nuestro pensamiento forzando una respuesta sobre nosotros. Todos estos elementos, los procesos que usamos y los modelos de nuestro entendimiento que nosotros mismos creamos, incluyendo el modelo del código, deben conformar con los requisitos de la mente.
Referencias
1. The value of RUP certification, by Jochen Krebs. The Rational Edge, Enero 2007.
2. The value of RUP certification, by Jochen Krebs. The Rational Edge, Enero 2007.
3. Basado en principios de Administración Total de la Calidad enseñados por Shewhart, Juran, Deming y Humphrey.
4. The Laws of Software Process: A New Model for the Production and Management of Software by Philip G. Armour
No hay comentarios.:
Publicar un comentario