400410303. Ya está bien de procesos: Hagamos prácticas

En esta última parte, examinamos las innovaciones necesarias para hacer que funcione un método basado en las prácticas, y cómo EssWork aporta estas innovaciones.

Una nueva experiencia de usuario

Para cambiar la forma en que la gente usa las descripciones de procesos, hemos usado una “metáfora de cartas y tarjetas” (como en las tarjetas de indexado de 12,7x 7,6 cm.) para presentar las cuestiones que merecen ser reseñadas en una práctica. Las tarjetas, de las que se enseñan muestras en la Figura 1, hacen que la práctica cobre inmediatamente vida. Presentan un resumen sucinto de las cuestiones más importantes que hay que recordar sobre las prácticas.

Por sí mismas, ofrecen información suficiente para que podamos aplicar la práctica – incluida información del tipo de en dónde estamos, cuándo podemos parar, cuándo hemos terminado. En la mayoría de los casos, lo único que necesitamos para aplicar una práctica es el conjunto de tarjetas.

Las tarjetas nos ayudan también a adaptar la práctica. Podemos garabatear en las tarjetas para hacerlas más específicas a las necesidades del proyecto que estamos realizando. Ello nos ofrece una forma exclusiva de afinar la práctica sobre la marcha y capturar lo que se ha ido aprendiendo al usarla. Podemos incluso escribir tarjetas adicionales para ampliar la práctica conforme se nos ocurren nuevas maneras de hacer las cosas.

Cada tarjeta tiene unas directrices que nos presentan el siguiente nivel de información esencial para ayudarnos a aplicar la práctica. Las directrices son breves (entre dos y cuatro páginas) y van al grano. De esta forma tienen más detalles – pero no demasiados. En un equipo, se espera que los miembros tengan distintos bagajes y competencias.

Los miembros más competentes usan las tarjetas para guiar su trabajo, mientras que las directrices ponen a los miembros con menor experiencia en la misma página. Si los miembros del equipo son novatos, no hay cantidad de descripciones textuales que pueda ayudar. Por lo tanto, recomendamos que reciban preparación de un miembro del equipo con más experiencia, o que usen una práctica activa, o que hagan algún tipo de curso de formación, o que lean un libro.

De esta forma, las descripciones de las prácticas se han mantenido deliberadamente sucintas y ligeras. Lo cual es bueno, porque el objetivo de las tarjetas es centrarse en lo fundamental que, por definición, es un subconjunto de todo el sector de prácticas.

Lo que es más, no hay necesidad de repetir información que ya existe (en libros o documentos, por ejemplo) sobre la práctica. La intención no es suplantar o reemplazar el material de referencia ya existente, sino complementarlo con una sencilla descripción de la práctica, de forma que pueda ser usada diariamente cuando se está desarrollando software.

Las directrices se refieren a materiales de apoyo adicionales. Citan referencias estándar y fuentes de información, en vez de intentar reescribirlas o reemplazarlas. Esto es particularmente útil cuando presentamos las prácticas que ya tenemos en este nuevo formato, puesto que sólo necesitaremos destilar lo esencial para nuestras tarjetas y directrices en vez de tener que reformatear/reescribir la información existente.

Las prácticas pueden ser presentadas ahora como un conjunto de tarjetas y directrices impresas (y usadas de la forma en que los proyectos XP usan las Tarjetas de Historias de Usuarios), y electrónicamente como parte de una forma de trabajar integrada y activa.

La manipulación y el acceso a materiales tanto de forma física como electrónica les permite a los equipos trabajar como mejor les convenga. La mayoría de los equipos tenderán a usar una mezcla de tarjetas físicas (para facilitar la comunicación entre los miembros del equipo y los eventos de grupo) y un entorno electrónico (para ofrecer ayuda online y acceso al método de trabajo)

Ensamblaje de un método de trabajo

Una vez que se han separado las prácticas, se necesita algún mecanismo que componga las prácticas para formar un método de trabajo.

Para permitir la composición de prácticas, necesitamos un punto de inicio – algo que, aunque sea independiente de las prácticas, nos ofrezca la base para la definición y composición de las mismas.

Hemos denominado a este punto de inicio el “núcleo de desarrollo del software” o, al usar las tarjetas – palabra que en inglés puede ser también carta- y la metáfora de las cartas, el “tablero de juego para el desarrollo del software.” El núcleo es un proceso de desarrollo de software ligero que, debido a la ausencia de cualquier práctica concreta, es casi totalmente tácito. Muchos de los conceptos subyacentes que guían las prácticas modernas en el desarrollo de software están representados en el núcleo.

Esto no es sorprendente, puesto que todos los equipos de desarrollo de software manejan los mismos conceptos y comparten la misma misión – desarrollar buen software. Hacer que las prácticas compartan estos conceptos comunes es clave para permitir que sean definidos de forma separada y que, no obstante, puedan ser compuestos todos juntos sin ninguna fisura.

Por ejemplo, el núcleo contiene el concepto del “sistema especificado”. Todo proyecto ha de tener un entendimiento compartido de lo que se supone que el sistema tiene que hacer – los requisitos del sistema, o su especificación, por así decirlo. Este entendimiento puede tomar muchas formas y puede comunicarse de muchas maneras, y al núcleo no le preocupa cómo se hace – simplemente nos recuerda que tiene que hacerse.

Hay muchas prácticas que se podrían utilizar para especificar el sistema, cualquier cosa desde una rápida conversación con los clientes hasta producir una especificación formal de requisitos del sistema. Es el equipo el encargado de seleccionar la mejor práctica que responda a sus necesidades – y a las de sus clientes.

El núcleo contiene además el concepto de “trabajo acumulado”, o lo que en inglés se denomina “backlog”, un concepto central en Scrum y otros métodos de gestión. Al ponerse a trabajar con el trabajo acumulado y estableciendo prioridades en el mismo se garantiza que no se pierde nada. La presencia del “backlog” en el núcleo permite que éste sea utilizado para guiar el desarrollo de nuestro software, incluso cuando no se han seleccionado las prácticas.

Una vez más, lo mismo que al especificar el sistema, la forma en que abordemos el trabajo del backlog no está definida y se verá limitada sólo por nuestra creatividad. Indudablemente hay prácticas que nos ayudan a ello. El núcleo proporciona el mecanismo para vincular estas prácticas entre sí y para que el equipo se centre en la producción de software que funcione.

El núcleo es el punto de partida para ensamblar el método de trabajo de un equipo. Se pueden añadir después prácticas al núcleo para ensamblar el método de trabajo del equipo y hacerlo explícito.

Cada práctica trae consigo su propio método para resolver uno de los problemas del desarrollo del software. Por ejemplo, hay muchas formas de especificar el sistema a construir: Podríamos usar Historias de Usuarios, Casos de usos, o Requisitos Declarativos. Cada uno de estos enfoques vendría expresado como una práctica distinta y definiría cosas distintas a producir y cosas distintas a hacer.

Esto viene ilustrado en la Figura 2 que muestra cómo una serie de practicas distintas puede rellenar los mismos “agujeros” en el núcleo (en este caso, los elementos del núcleo son “sistema especificado” y “especificar el sistema”).

En cualquier momento, el equipo puede seleccionar una práctica y componerla en su método de trabajo. Ello da como resultado que las tarjetas y directrices aumenten con las nuevas prácticas seleccionadas. La infraestructura entonces ajusta las herramientas y el entorno para reflejar y soportar el nuevo conjunto de prácticas.

El uso de tarjetas para ayudar a ensamblar y personalizar el método de trabajo es eficaz. Las tarjetas procedentes de prácticas distintas pueden ser comparadas, organizadas y anotadas para que ofrezcan una instantánea del método de trabajo del equipo.

Para componer el proceso a partir de tarjetas físicas, primero tenemos que identificar el agujero que queremos rellenar en el núcleo, y a continuación añadimos una o más prácticas para rellenar el agujero. La Figura 3 muestra cómo distintas prácticas para requisitos pueden ser mezcladas y conjuntadas para definir una forma específica de especificar el sistema.

Una vez completados el razonamiento y la negociación, las prácticas seleccionadas pueden ser ensambladas dentro del entorno electrónico para capturar el método de trabajo resultante, y ayudar al equipo a aplicar las prácticas seleccionadas.

Las prácticas locales se pueden integrar con facilidad en el método de trabajo, mediante la creación de tarjetas adicionales que representen sus productos. Esto nos permite alinear el método real de trabajo del equipo con el conjunto de tarjetas en uso, y mantener actualizado dicho conjunto de tarjetas. Lo que nos proporciona un mecanismo fácil de usar para evitar que el proyecto y el proceso se salgan de la sincronización.

Una nueva forma de usar las prácticas

Para que las prácticas sean útiles, tienen que ser algo más que meras cosas que uno lee para recordar o entender un concepto abstracto (como las iteraciones). Tienen además que ayudarnos a entender nuestro proyecto y a avanzar en él de forma más eficaz.

Esto lo conseguimos con un mayor refinamiento de la metáfora de las tarjetas. De igual manera que tenemos tarjetas CRC (Class Responsibility and Collaborators) para identificar y diseñar clases, usamos tarjetas para facilitar casi cualquier faceta en el desarrollo del software.

Esto permite que las tarjetas desempeñen un papel a lo largo de todo el proyecto, en vez de que sólo se utilicen cuando el equipo está aprendiendo o preparándose para iniciar el trabajo. Con esto en mente, quisiéramos destacar dos formas de usar las tarjetas.

Una es cuando estamos trabajando en el proyecto con las prácticas. Las tarjetas hacen que sea más fácil aplicar las prácticas y crear tareas a acometer por el equipo. Entre las cuestiones más importantes presentadas en las tarjetas están los ciclos de vida de las cuestiones tratadas en la práctica.

Dichas cuestiones permiten que las tarjetas se utilicen para visualizar el estado actual del proyecto y para determinar el paso o los pasos siguientes. Podemos hacerlo como parte de la planificación del proyecto, o sobre la marcha, según decide el equipo lo que hacer a continuación.

Como andamos siempre mirando cual va a ser nuestro paso siguiente, siempre sabremos qué partes aplicar de las prácticas seleccionadas. Si ya se ha hecho algo o está donde tiene que estar, no se necesitan prácticas para conseguir esos resultados y por tanto se pueden ignorar.

Se pueden ensamblar colecciones de tarjetas que representen el trabajo a realizar. Al escribir en las tarjetas, podemos ver exactamente lo que está pasando: Estimaciones, progreso hasta la fecha, y quién está haciendo qué. Podemos usar las tarjetas para compilar el trabajo acumulado, la lista de tareas, y los planes de iteración.

Al relacionar de esta forma el trabajo con las prácticas, la información de las prácticas está siempre disponible inmediatamente y está claro qué prácticas se tienen que utilizar en qué momento. Se puede incluso rastrear su pista ordenando y escribiendo en las tarjetas, o introduciendo los elementos de trabajo que representan en una hoja de cálculo o herramienta de gestión de tareas.

Una segunda forma de usar las tarjetas es cuando el equipo aplica una sola práctica. Una de las cuestiones más atrayentes de este método es la capacidad de aplicar una sola práctica sin cambiar el resto de las cosas que se están haciendo en el proyecto o de tener que volver a elaborar las cosas ya producidas.

Al utilizar el núcleo para conducir el proyecto hacia delante desde su estado actual al deseado, podemos aplicar las prácticas que necesitamos en el momento en que las necesitamos. Eso significa que los equipos pueden seleccionar y experimentar con prácticas nuevas sin acometer largos y antieconómicos ejercicios de ingeniería de procesos o de documentación.

Las tarjetas pueden ser también útiles cuando planificamos y analizamos el proyecto de forma retrospectiva, y cuando mejoramos nuestro método de trabajo.

EssWork

Aunque las tarjetas físicas ofrecen un buen mecanismo para entender y aplicar las prácticas, no ascienden gradualmente para que puedan ser usadas en proyectos grandes o por equipos distribuidos – y pueden ser una desconexión para los equipos que no son muy entusiastas de las tarjetas o de los métodos Agile en general.

Se necesita un entorno electrónico que realmente nos permita componer las prácticas, generar las tarjetas y las directrices adecuadas, gestionar las tarjetas y hacer que las prácticas estén visibles en el entorno colaborador de desarrollo de software elegido por el equipo. Hemos denominado a este entorno “EssWork”, forma abreviada de “Essential Work”, y lo hemos implementado para que soporte la versión electrónica de Essential Unified Process.

EssWork proporciona una infraestructura centrada en prácticas en la que podemos cargar cualquier práctica que necesitemos (Figura 4). Por defecto, la infraestructura incluye la nueva experiencia de usuario basada en tarjetas, la persistencia de prácticas necesaria para almacenar el método de trabajo del equipo, y las interfaces para el desarrollo de adaptadores de prácticas para integrar EssWork en el entorno de desarrollo del equipo. Puede complementarse también con tecnología de activación de prácticas (como Waypointer) para que las prácticas cobren vida.

EssWork (www.esswork.com) no es un proceso de marca. Es una plataforma independiente de prácticas que ofrece la infraestructura y la base para que los equipos puedan componer sus propios métodos de trabajo. Los desarrolladores del software no van a aprender, adoptar o seguir EssWork. Aprenderán, adoptarán y seguirán las prácticas que lo dan vida.

No se dirá que se está usando EssWork cuando se está desarrollando software de la misma forma que no se dice que se está usando el correo electrónico o los procesadores de texto. Sencillamente será un parte natural de la infraestructura del equipo, permitiéndoles beneficiarse de la adopción y aplicación de prácticas de forma ágil y disciplinada.

El Núcleo EssWork está disponible para todo el mundo y de forma gratuita (www.ivarjacobson.com), y va a ser donado, junto con las prácticas técnicas del Essential Unified Process, a Eclipse Process Framework (www.eclipse.org/epf), en donde se alojará la comunidad de EssWork. El Núcleo EssWork soporta el uso de prácticas en un abundante conjunto de plataformas con acceso de clientes y entornos de desarrollo colaborador, entre los que se incluye Microsoft Visual Studio y Eclipse, y almacenes de datos del lado del servidor tales como Microsoft Team Foundation Server y JIRA. DDJ