Reseña de libro
Use Case Modelling
By Kurt Bittner and Ian Spence
Este libro ese un clásico, publicado por primera vez en 2003, que vale la pena leer. Hasta donde pude encontrar no hay una traducción al castellano, y en parte considero la facilidad de leer este libro para alguien que tiene el ingles como segundo lenguaje.
También es un libro que es difícil de reseñar. Por un lado es un excelente tratado del proceso de la definición de requisitos en organizaciones que siguen un método RUP hecho a medida*. El libre cubre el proceso entero de la definición y documentación de requisitos, y lo describe bien. Conozco mas de una empresa que sigue este método al pie de la letra. Así que no hay forma de evitar leerlo si quieres saber si estas siguiendo una metodología bien definida, o si te estas preparando para un nuevo proyecto y quieres prepararte para asumir el trabajo con una metodología y un proceso consistente.
Por el otro lado el libro genera mas sueño que energía, aun si estas profundamente metido en el tema. Es el tipo de libro que se pone como lectura obligatoria en las listas de colegios y universidades, al parecer tan solo para probar el aguante y resiliencia de los alumnos. Si eres capaz de leer el texto de principio a fin y reproducir algunos de los temas sobresalientes pasas la prueba.
Hay dos razones por las cuales creo que es tan difícil de leer. Por un lado el estilo en el cual esta escrito, y por el otro lado el orden en el cual se presentan los capítulos.
Los autores usan un prosa que normalmente se reserva para artículos académicos donde este estilo ayuda a sobrepasar barreras de lenguaje. Pero para este libro, el uso regular de verbos como “to elicit” y frases como “Functional Requirements are those actions that a system must be able to perform, without taking physical constraints into consideration” o “Non-functional requirements are best described using declarative requirements”, simplemente ofusca el placer tema el tema hubiera podido brindar.
Muchos lectores hispanohablantes y no-técnicos se perderán con regularidad en el texto. Y si tu líder de grupo empezó con un grado en artes … bueno, escoje mas bien por darle un resumen verbal del tema y usa el libro solo para mostrar las figuras. La desventaja de esto es que muy pocos gestores que no están directamente involucrados en temas de tecnología no van a ser capaces de leer y disfrutar el libro. Aun si lo leen de caratula a fin, no se puede esperar que hayan asimilado el proceso después de dejar el libro a un lado. Y me puedo imaginar a mas de un gestor que piense “si de esto se trata la documentación de systemas, mas bien me ahorro el esfuerzo y los costes”**. Y obviamente, lo que queremos es la respuesta opuesta.
El libro comienza con la explicación y precisación de definiciones de Casos de Uso y Modelación de Casos de Uso. Y esto es un lastima, porque pierden el chance de seguir la secuencia del proceso que ellos mismos describen, lo que hubiera mejorado la accesibilidad del libro. Si doy la sinopsis del libro en el orden en que tomamos los pasos en la practica se dejaría leer así:
1. Establece la visión y une a los involucrados al proceso
Asegurate de que los involucrados están incluidos en el proyecto, y empieza documentando los requisitos en su propio lenguaje. La descripción de la forma en hacer esto con workshops es muy detallada (casi hasta el papel y lapicero) y preciso. Si no lo has hecho antes, entonces este libro de verdad es un buen sitio para empezar. La mejor forma de ser efectivo durante reuniones de definición de requisitos es reunir una buena selección de involucrados en un mismo espacio físico.
2. Identifica los actores y casos de uso y documentalos
Con base en tus notas de los workshops y entrevistas con involucrados, sintetiza los requisitos en actores y casos de uso que pueden ser reseñados por los mismos involucrados y ofrece una descripción de sistema bajo discusión para los desarrolladores. Este es el puente entre tecnología y negocio que se necesita establecer para que las expectativas se dejen manejar en ambos lados de la división.
3. Repite los pasos arriba hasta que el sistema quedó claro y los documentos han sido aceptados por los dueños de proyecto a través de un proceso de reseña transparente. En la practica eso significa tomar en cuenta. Y en la practica eso significa muchas veces que tenemos que cuidarnos de no usar un lenguaje demasiado técnico, o basado en el color local del lenguaje que se usa dentro de los departamentos de los involucrados. Cualquier persona en la organización debería poder leer los documentos.
Si los capítulos hubieran sido organizados a lo largo de estas lineas, el nivel de entrada seria mas general, y yo prefiero recomendar un libro de referencia a un nuevo gestor de proyecto que no sea capaz de terminar de leer, a un libro donde la probabilidad de que vaya a llegar mas allá del primer capitulo es baja.
Creo que a pesar de que este proceso existe en casi todas las organizaciones todavía hay campo para un libro definitivo sobre la definición de requisitos, que sea realmente accesible y bien escrito. Hay demasiados malentendidos y expectativas infladas sobre el método Rational que no son necesarios. Y lo mismo vale para alternativas como Agile. Una revisión y corrección de este libro podria llenar ese vacío. Hasta entonce este libro seguirá siendo un libro que haz-de-leer, y tendrás-que-aguantar para analistas de información, gestores de tecnología de información y personas interesadas en el proceso de definición de requisitos.
La mayor ventaja de este libro es que los autores toman los aspectos claves del proceso Rational y aconsejan hacerlo bien y de forma eficaz, sin adherir celosamente a la metodología completa.
Notas
*RUP es el Proceso Unificado de Rational <a http://wikipedia>Rational Unified Process<a> para el desarrollo de programas, que se usa en casi todas las empresas grandes.
** El o ella podría tener razón, ya que RUP por lo general se hace a medida por temor al riesgo de sobrecarga de documentación (googlea RUP vs Agile y veras), pero esto no es el sujeto del libro o de esta reseña.