Al Diablo con los Procesos, Hagamos Prácticas

“Al diablo con los procesos, hagamos prácticas”, es lo que está diciendo Ivar Jacobson por medio de la nueva iniciativa SEMAT que está impulsando.

Seguramente muchos de ustedes conocen a Ivar Jacobson. Un sueco, que algunos viejitos como yo, conocimos como "el padre de casos de uso" gracias a su libro Object-Oriented Software Engineering (1992). Los más jóvenes deberían de reconocerlo como el co-autor, con Booch y Rumbaugh, de UML y del Proceso Unificado, cuando todos fueron socios en Rational. Hoy tiene su propia consultoría y no se queda quieto. En 2007 escribió un artículo titulado: Enough of Processes – Lets do Practices, que en mi traducción libre sirvió del título a esta columna. En él hace una crítica del mal uso actual de procesos y propone redescubrirlos a través de prácticas.

Según Jacobson, el término “proceso” es una descripción explícita de la manera de trabajar. Todos los equipos tienen una forma de trabajar juntos, sea explícita o tácita. Las maneras de trabajar de los equipos de desarrollo de software, por lo general, están inspiradas en las ideas de los expertos externos o locales. Los expertos tienen su manera preferida de trabajar, y a veces, deciden presentarla en forma publicada (libros) tratando de que sea lo más único e individual posible. Esto ha ocasionado varios problemas.

Problemas con los procesos de hoy

• Negación de cosas comunes. Cada proceso tiene muchas cosas comunes y pocas diferencias con otros. Lo que pasa es que los autores tratan de usar distinta terminología para ocultar lo común. Yo agregaría que, en muchas ocasiones siento que es “la misma gata pero revolcada”.
• Problema de completitud. Todos los procesos pretenden ser completos y esto nunca va a ser posible. Las definiciones de procesos se vuelven extensas y es difícil de encontrar en ellas lo que hace falta en un contexto dado. Yo agregaría, que la frontera entre el “qué” y el “cómo”, en el detalle de la descripción de los procesos, depende del conocimiento previo de los lectores. Por lo que nunca será posible tener una definición completa para todos.
• Problema de la adopción de procesos nuevos completos. Al tomar la decisión de implementar los procesos nuevos completos, se pueden perder buenas prácticas que han servido a los equipos. Muchos cambios a la vez difícilmente serán aceptados. Yo agregaría, que la situación se vuelve más difícil si las nuevas prácticas no resuelven los problemas reales de la organización.
• Problema de la brecha entre los procesos que se tienen y los que se necesitan. La verdad es que los equipos difícilmente siguen los procesos oficiales de su organización. Usan una mezcla de lo que se sugiere y lo que sienten que se tiene que hacer. No se lo digan a nadie, así debe de ser (digo yo).
• Problema de acceso al conocimiento. La ley de la naturaleza humana dice que la gente no lee manuales (¡ni de procesos!). La presentación actual de procesos es aburrida. Se necesita una forma más útil de presentarlos y de tenerlos disponibles cuando se requieran. Yes, yes, yes!!! Ya es hora a que usemos nuestra propia tecnología para lograrlo (digo yo).
• Problema de procesos “estúpidos”. Los procesos, que se pide que sigan los equipos, no les sirven para hacer su trabajo. Para seguir los procesos se depende de expertos, mentores o coaches. Ni hablar (digo yo).

En consecuencia, dice Jacobson:

• Las empresas tienen dificultades en establecer formas efectivas de trabajar.
• La adopción de procesos es una barrera y no una forma de establecer maneras efectivas de trabajar.
• Los métodos ágiles surgieron para dar la solución a estos problemas, pero sus gurús siguen escribiendo libros.

Entonces ¿qué se puede hacer?

La paradoja es que aunque a los desarrolladores no les gustan los procesos, ¡necesitan prácticas!

Una práctica proporciona una manera sistemática y verificable de atacar un aspecto particular de un problema, dice Jacobson. Una práctica es como una unidad que puede ser identificada, aprendida y adoptada por separado. Una práctica puede ser utilizada en conjunto con otras prácticas para crear una forma de trabajo coherente. ¿De dónde vamos a secar las prácticas? La respuesta de Jacobson es, ¿qué creen? - de los libros de Ingeniería de Software, de Modelos de procesos y de Métodos Ágiles.

En el mismo artículo hace referencia a Prácticas Esenciales de Proceso Unificado cuyo sitio encontrarán en referencias.

¿Y qué onda con los procesos? Según Jacobson, un proceso puede ser considerado como una colección de prácticas relacionadas y altamente acopladas. De esta manera el proceso se vuelve como una guía de prácticas cuya adopción es un punto de partida para cambiar la forma de trabajar. Se puede adoptar una práctica a la vez, dejando sin cambio las prácticas que ya se siguen.

Para documentar las prácticas, propone metáfora de “tarjetas” (electrónicas e impresas). Una tarjeta contiene el resumen de la práctica, el cual está acompañado de una guía que contiene los detalles.

Esta propuesta no se quedó en el tintero. En marzo de 2010 Ivar Jacobson, Bertrand Meyer and Richard Soley convocaron a los mejores gurús de Ingeniería de Software a un taller en Zurich, en el cual constataron que la Ingeniería de software está “gravemente obstaculizada por las prácticas inmaduras”. Todos estuvieron de acuerdo que los problemas específicos son:

• Prevalencia de las modas.
• Falta de una base teórica.
• Gran número de métodos.
• Falta de validación experimental creíble.
• División entre la práctica de la industria y la investigación académica.

Decidieron constituir una iniciativa bajo el nombre Software Engineering Method and Theory (SEMAT) cuyo objetivo principal es: “Apoyar un proceso de re-fundamentar la Ingeniería de Software basado en una teoría sólida, principios probados y las mejores prácticas.”

Al inicio de 2011 la iniciativa fue transferida a Object Management Group para darle mayor respaldo institucional. Todos estamos invitados para participar.

Para finalizar, quiero agradecer a Praxis por invitarme cada año a su evento de Calidad. Este hecho me obliga a explorar temas nuevos, que luego convierto en columnas. Este caso no es la excepción.

Referencias:
[1] Ivar Jacobson, Pan Wei Ng, Ian Spence: “Enough Process - Let’s Do Practices”, in Journal of Object Technology, vol. 6, no. 6, July-August 2007, pp. 41-66. http://www.jot.fm/issues/issue_2007_07/column5
[2] ESSWORK: http://www.esswork.com
[3] Software Engineering Method and Theory (SEMAT): http://www.semat.org