Realizando la idealidad

Probar un sistema implica simular ese sistema, asegurarnos de que tal sistema hace lo que debe y no hace lo que no debe. Implica un análisis con el propósito de encontrar problemas y errores, medir la funcionalidad y la calidad, capacidades, etc.

Una cuestión muy importante a considerar es que no se puede probar todo. No existe el producto perfecto, siempre tenemos que hablar en términos relativos o porcentuales, como por ejemplo, tasas de error. El proceso de pruebas es un proceso creativo y difícil; es importante planificar qué se va a probar, definir qué escenarios se va a probar. Finalmente, es importante dedicar tiempo y recursos suficientes a dicha tarea.

Diez buenas prácticas:

1.- Haz de la autoevaluación del trabajo de cada uno una responsabilidad de equipo. Insiste en que Test y Evaluación (T&E) forme parte del trabajo diario de cada uno (utiliza smoke tests para apoyarte en ello). Es necesario garantizar la producción de trabajo de calidad todo el tiempo.

2.- Establece cuanto antes un plan integral de pruebas y evaluación. Establece pautas, objetivos y entregables de cada tipo de test. Puede establecerse en sesiones RAD (Rapid Application Development) al comienzo o en sesiones de tormenta de ideas.

3.- Realiza un parte preventivo de pruebas de todo el trabajo especificado. No dejes nada sin cubrir; haz escenarios de todo; esto también te ayudará a entender mejor los requisitos. Inspecciona periódicamente los test y su adecuación al comento de desarrollo actual. Desarrollo y pruebas van de la mano: crea los casos de prueba antes de desarrollar.

4.- Utiliza las pruebas como indicadores de progreso. Que las pruebas te sirvan como indicador seguro de que algo está hecho y funciona.

5.- Haz un inventario de los objetivos de las pruebas y diseña para “testabilidad“. Diseña una lista de qué debe ser probado antes de diseñar o implementar otra cosa.

6.- Prueba desde el principio y a menudo. Así retroalimentas el desarrollo y detectas problemas en el momento en que ocurren.

7.- Diseña y desarrolla test como si fueran entregables. Con la misma disciplina y método. Desarrolla test en paralelo con el código, actualiza los test cuando el producto cambia. Si escribes los test demasiado pronto, luego habrá que redefinirlos, así que tampoco es bueno adelantarse demasiado. La ingeniería de desarrollo de test es igual que la ingeniería de cualquier producto software.

8.- Provee herramientas y soporte adecuados para el testing.

9.- Mide costes, cobertura, resultados y efectividad de los test. Así entenderás mejor el proceso de testing y podrás controlarlo y gestionarlo.

10.- Entrena y gestiona al equipo. Así se tomarán el testing como algo serio y conocerán qué se espera obtener de dicha tarea. El gestor indica guías, la dirección a seguir, qué pasos dar, etc.

The Little Book of Testing, Vol I, varios autores.

Por parte del producto como objetivo final nos encontramos con los siguientes problemas:

- Requisitos de “placa dorada”. Requisitos no tan importantes para el usuario como nosotros pensamos, obsesión por el desempeño y otros factores que como informáticos puedan parecernos clave pero que un usuario no valorará tanto. Alargan la calendarización, y si les damos demasiada importancia, restaremos valor a otros requerimientos clave para el cliente.

- Inestabilidad de los requisitos. Algo presente siempre, por lo tanto es fundamental vigilar y controlar los cambios en los requisitos. Alarga la calendarización.

- Desarrolladores de “placa dorada”. Los programadores suelen estar ansiosos por utilizar una nueva tecnología, herramienta o técnica que ha aparecido en el mercado, aunque no sea necesaria para el proyecto. La investigación en nuevos campos conlleva gran incertidumbre, y esto alarga la calendarización, además de aumentar riesgos.

- Negociaciones de tira y afloja. Es extraño que cuando se negocia un deslizamiento en la estimación de un producto automáticamente alguien añade nuevas funcionalidades, lo cual invalida la nueva estimación…

- Desarrollo orientado a investigación. Si quieres desarrollar proyectos, no te sumerjas demasiado en investigar nuevos algoritmos, técnicas, etc. El riesgo de fracasar o ralentizar el proyecto es muy elevado. Desde luego que, si no te queda más remedio hazlo, pero cuenta con el riesgo que ello conlleva y desde luego no esperes terminar el proyecto en un tiempo récord, precisamente.

Finalmente, en cuanto al factor tecnológico:

- Síndrome de la bala de plata. No dejes que los equipos confíen demasiado en una nueva técnica, herramienta, etc. como si fuera la solución de todos los problemas. Las balas de plata no existen en informática; no creas lo que te venden los comerciales…

- Ahorros sobreestimados de nuevas herramientas o métodos. Las organizaciones no mejoran su productividad a grandes saltos, sino en pequeños avances; entre los inconvenientes de utilizar nuevas tecnologías están: riesgos de utilizar algo tan novedoso que pueda no tener soporte para el cliente, adecuación, curva de aprendizaje, etc. Otro ejemplo de esto podría considerarse el reutilizar software. Nuevamente, el ahorro no es tan grande como se podría prever en un primer momento.

- Cambiar las herramientas a mitad de proyecto. Casi nunca funciona bien. La curva de aprendizaje, rehacer el trabajo ya hecho, errores inevitables cometidos por el desconocimiento de la herramienta… ralentizan el proyecto.

- Falta de control automático del código fuente. Expone al proyecto a riesgos innecesarios. Es fundamental utilizar un buen software de control de versiones, junto con una buena política de gestión de configuraciones. Muchas empresas se conforman con adquirir buenas herramientas de control, pero se olvidan de que sin una buena política de gestión de configuraciones la herramienta no es más que un soporte, algo que puede considerarse incluso como un elemento lelo si se utiliza sin cabeza.

Es posible que redacte en próximas entregas lo que bajo mi punto de vista sería una solución a todos estos problemas. No quiero decir con ello que tenga la solución a todos los problemas, que sea un gran consultor ni nada parecido; simplemente reflejaré lo que los autores aconsejan sobre esto y expondré qué cosas se podrían hacer para paliar estas situaciones. Y desde luego que exponer una solución no es el final de todo. No existen balas de plata, recordemos, y la aplicación de tales soluciones será unas veces más sencillo y otras más complicado, requiriendo en algunos casos de la implicacion de todo el equipo para alcanzar el éxito. Tampoco existen garantías absolutas, pero sí podemos aumentar nuestras posibilidades, y  por esto bien puede merecer la pena el esfuerzo.

- Actividades fundamentales acortadas. En cierto modo, una consecuencia del error anterior. Cuando hay prisa, se recortan las tareas que no producen código directamente. Habitualmente las candidatas son: análisis de requisitos, diseño y elección de la arquitectura, curiosamente las fases con mayor riesgo y más claves del proyecto.

- Diseño inadecuado. Viene un poco en consonancia con lo que acabamos de anotar: diseños realizados con prisa, no atendiendo debidamente al tiempo requerido conducen a malos productos. Un diseño completo requiere varios ciclos.

- Acortar tareas de calidad. Cuando hay prisa, tratan de acortarse tareas de revisión de código y testing. Eliminar un sólo día de tareas de calidad puede alargar el proyecto entre 3 y 10 días más.

- Controles de gestión insuficientes. Antes de tratar de mantener un proyecto en el buen camino, pregúntate si el proyecto está en dicho momento en el buen camino.

- Convergencia prematura o demasiado frecuente. Cuando se acercan fechas de entrega del producto, es necesario realizar tareas de mejora de desempeño, documentación, preparación de la instalación del producto, etc. Se suele tender a converger demasiado pronto en el sentido de empezar a preparar la release demasiado pronto, lo cual es contraproducente porque luego habrá que volver a converger alguna vez más con nuevas mejoras producidas y además condiciona negativamente al proyecto. Realmente es complicado cómo decidir cuándo converger: no puede ser demasiado tarde porque hay un buen número de tareas propias de fase de release, como las que hemos apuntado antes, que deben ser realizadas, pero si se trata de integrar el trabajo demasiado pronto luego habrá que integrar nuevas funcionalidades y bug fixing realizado.

- Omitir tareas necesarias de las estimaciones. Es fácil olvidar tareas menos visibles pero necesarias, que luego añaden tiempo a la calendarización. Una buena medida sería guardar información histórica de anteriores proyectos para tener algo más de información acerca de qué se necesitó realizar y poder estimar con más conocimiento de causa.

- Planear ponerse al día más adelante. Si una estimación resulta no ser adecuada en la realidad, las estimaciones de las tareas dependientes de ella deben ser reajustadas en consonancia, y no esperar que el proyecto avance más deprisa a partir de tal momento. Es razonable fallar una estimación: uno aprende del proyecto a medida que éste avanza. Es necesario reajustar estimaciones también cuando cambian los requisitos.

- Programar a lo loco. Olvidarse de realizar un diseño bien trabajado. Sin razonar. Al más puro estilo ensayo y error. Esto conduce a tirar mucho trabajo que no vale, a perder mucho tiempo en experimentación poco productiva. Esto, que parece un error de novato, es a lo que conducen las calendarizaciones ambiciosas, cosa que está a la orden del día en muchas empresas.

Steve McConnell: Rapid Development, Taming Wild Schedules

- Expectativas irreales. Incapacidad para comprender el significado de la palabra “estimación”. Esta mala praxis puede presentarse de dos formas:  bien mediante estimaciones optimistas, bien mediante una selección para desarrollo de un conjunto de funcionalidades demasiado ambiciosas.

- Falta de apoyo efectivo al proyecto. Aquí la principal responsable es la parte directiva: planificación, control de cambios, introducción de nuevas prácticas de desarrollo… Sin esto surgirán compromisos irreales o cambios que dañarán el desarrollo del proyecto.

- Falta de implicación de los stakeholders (personas implicadas e interesadas en el desarrollo del producto: clientes y usuarios). Toda persona relacionada de algún modo con el proyecto debe implicarse. Cuando todas estas personas se coordinan es más probable lograr un desarrollo rápido y satisfactorio.

- Falta de involucración por parte del usuario. Conduce a una mala interpretación de los requisitos.

- Políticas por delante del objetivo. Anteponer políticas a resultados es fatal para un buen desarrollo. El objetivo siempre es lo primero, y todo lo que ayude a alcanzar ese objetivo se cuidará y se aprovechará al máximo; todo aquello que sea un factor negativo para la consecución del objetivo se descartará.

- Pensamientos pretenciosos. Las suposiciones optimistas no tienen razón de ser, conducen a la desesperación y a la sensación de fracaso. Es cerrar los ojos y esperar que todo funcione bien, sin ninguna base lógica que lo apoye. Esto es especialmente peligroso en las primeras estimaciones del proyecto, que es donde más se presenta este error.

En cuanto al factor productivo:

- Estimaciones excesivamente optimistas. Mala percepción del proyecto, minimización de tareas de análisis y diseño, daño al plan, excesiva presión en los desarrolladores… todo esto daña la productividad a largo plazo. Es uno de los condicionantes más frecuentes y más graves.

- Gestión de riesgos insuficiente. Riesgo es un error no común. Basta con que ocurra un riesgo no previsto de antemano para ralentizar e incluso cancelar el proyecto. Más claro y más simple imposible.

- Fallo de subcontratación. Si se utilizan COTS (Components Of The Shelf, utilidades desarrolladas por terceros) y el diálogo con este personal no es fluido, podemos encontrarnos con componentes de baja calidad o que no se ajustan a lo que pretendíamos. La paradoja surge cuando vemos que siendo el objetivo de subcontratar el acelerar, lo que hemos conseguido es ralentizar.

- Planificación insuficiente. La planificación debe ser apropiada para un desarrollo rápido.

- Abandono del plan en situaciones de presión. Los equipos hacen planes y de forma habitual los abandonan cuando empiezan a tener problemas de calendarización. Otro de los habituales. El raíz del problema aquí yo creo que está en la percepción de que el plan es algo estático, que se hace al principio de forma muy estudiada y que si luego no se cumple, surge la alarma y el caos.
El plan es siempre dinámico, y la mejor cualidad de un plan debe ser su capacidad de adaptación y flexibilidad a todo tipo de situaciones más o menos esperadas (una vez más, aquí tiene mucho que decir una buena gestión de riesgos).

- Tiempo perdido en fases “ante-proyecto”. Es decir: tiempo durante el cual se estudia el presupuesto, la viabilidad… Muchos proyectos pierden aquí demasiado tiempo y luego vienen las prisas en etapas más críticas y que precisamente necesitan más cuidado en su desarrollo por su riesgo inherente (ej.: diseño).

Steve McConnell: Rapid Development, Taming Wild Schedules

Ya iba para largo que no escribía, he tenido una semana bastante ajetreada, aunque las cosas al final no han acabado muy bien y es un tanto irónico que precisamente yo hable de lo que voy a tratar hoy, pero bueno, mejor dejemos estos temas de lado ya que no me gusta hablar de mis problemas por aquí, el enfoque de este blog siempre fue bien distinto.

Introducción

Steve McConnell, y ya con esta serie dejo en paz a este caballero, qué pesado me pongo con él, divide el desarrollo software en cuatro pilares básicos. La metáfora de pilar nos viene muy bien para entender que si uno de estos pilares falla, la estructura (el producto) se viene abajo, por tanto es fundamental cuidar todos con especial atención. Estos cuatro pilares, sin embargo, son independientes. Éstos son:

- Personas: Tienen un efecto muy importante sobre la productividad y la calidad. Es fundamental, por ello, mejorar el potencial humano. Probablemente sea éste el factor más importante de todos.

- Proceso: Visto desde el punto de vista técnico y de gestión. Un buen proceso evita tener que rehacer trabajo por no haber realizado anteriores tareas correctamente (ejemplo: rediseñar un producto por no haber captado correctamente los requisitos). Asegura, además, la calidad desde dos frentes: por uno garantiza la entrega de un producto satisfactorio para el cliente; por otro permite detectar problemas y errores lo antes posible. Conceptos fundamentales aquí son la gestión de riesgos, el aprovechamiento de los recursos disponibles, el aprendizaje de técnicas y modelos de desarrollo…

- Producto: El tamaño y las características pueden reducir considerablemente el tiempo de entrega, si puedes elegir qué funcionalidad entregar antes.

- Tecnología: Utilizar tecnologías más cómodas y avanzadas, teniendo en cuenta los riesgos que estas mismas conllevan.

Cuando se atienden debidamente las 4 dimensiones en su justa medida, podemos alcanzar sinergia.

Errores comunes en desarrollo software

A partir de la clasificación anteriormente explicada, se identifican los siguientes errores comunes a la hora de desarrollar software; todos ellos tienen que ver con alguno de los cuatro pilares:

En cuanto al factor humano,

1.- Baja motivación. Probablemente sea el factor más influyente de todos, en cuanto a productividad se refiere.

2.- Personal escasamente cualificado. Las capacidades individuales, así como la relación con el resto del equipo, influyen en la productividad casi tanto como el error anterior.

3.- Problemas entre los miembros del equipo no controlados. Escucha los problemas del equipo y atiéndelos debidamente; no hagas caso omiso a cualquier situación que pueda perjudicar el objetivo común.

4.- Heroicidades. Es mejor basarse en estimaciones realistas que en compromisos (commitments) imposibles de cumplir que a la hora de la verdad conllevan más riesgo.

5.- Añadir personal a un proyecto ya empezado. Si alguien piensa que agregar  gente  simplemente va a aumentar la productividad, está equivocado. Puede ser como echar gasolina al fuego. Añadir personal requiere una etapa de formación y aprendizaje más o menos larga, que al principio conlleva más gasto que beneficio y que solamente con el tiempo se logra un retorno de la inversión (ROI, Return Of Investment, que dicen los anglosajones).

6.- Oficinas ruidosas y abarrotadas. Afectan negativamente a la productividad.

7.- Tensiones entre programadores y clientes. Pobre comunicación, pobre entendimiento de los requerimientos del cliente, pobre diseño de la interfaz de usuario. Como consecuencia más catastrófica: no aceptación del producto.

Basta por hoy. Continuaremos en otra ocasión. Nos vemos, pues.

Steve McConnell: Rapid Development, Taming Wild Schedules

Feature Team

Consiste en pequeños equipos encargados de un área específica: desarrollo, calidad, documentación, gestión, interfaz de usuario… Cada grupo tiene un responsable que funciona como portavoz e interfaz de comunicación con los otros grupos. Las responsabilidades están claras y bien definidas. Funciona bien en proyectos tipo resolución de problemas (ver artículo anterior) porque tales problemas pueden ser divididos y focalizados en un grupo. También puede funcionar bien en proyectos de creatividad (ver artículo anterior), al enfocar cada grupo mejoras de calidad desde un punto de vista diferente. Proyectos de ejecución táctica (ver artículo anterior) no se ven favorecidos por este tipo de organización.

Search and Rescue Team

Actúa como un equipo de salvamento de montaña. Los miembros se centran en resolver problemas muy específicos. Requiere un profundo conocimiento del entorno y del modelo de negocio. Requiere una buena previsión de imprevistos (riesgos: planificación y resolución). Claramente favorable para proyectos tipo resolución de problemas. No es buena opción en otro caso.

SWAT Team

“Special Weapons And Tactics” se transforma en el mundo software en “Skilled With Advanced Tools“. Cada miembro es experto en el manejo de una herramienta o técnica específica, y la suma de todos ellos es sinérgica y hace que el equipo actúe como uno sólo. Debido a sus características son equipos permanentes, inamovibles. Especialmente útil en proyectos de ejecución táctica. Buena idea para proyectos de resolución de problemas.

Professional Athletic Team

Los miembros del equipo son seleccionados muy cuidadosamente. Son las estrellas. El gestor hace trabajo de “trastienda”, pues los fans no quieren verlo a él, quieren al equipo. El gestor hace posible que el equipo sea eficiente. El proyecto puede salir adelante sin el gestor, pero no sin el equipo. Cada miembro tiene un rol específico, el cual maneja perfectamente. El gestor está para dar soporte. Por si a alguien no se le ha ocurrido aún, esto es igual que un deporte de equipo. Útil en productos de interés general, y no de cliente.

Particularmente me parece que incentiva la creatividad y la resolución de problemas.

Theather Team

Fuerte dirección y mucha negociación acerca de los roles en el proyecto. El “director” manda: su opinión prevalece sobre la del resto. Cada rol no debe salirse demasiado de su cometido o papel. Los papeles son intercambiables entre proyectos, de manera que no hay especialistas en este sentido, pero en un proyecto dado el papel no cambia. El gestor hace trabajo de gestión puro: mucha gestión, poca técnica. Útil en proyectos multimedia.

¿Y vosotros? ¿En qué tipo de equipo trabajáis?

Rapid Development: Taming Wild Schedules, Steve McConnell

Introducción

En este artículo trataremos las diferentes formas que existen para organizar los miembros que conforman un equipo de desarrollo software y en qué consisten, qué rol desempeña cada miembro, etc.

Para entrar en calor, digamos que según sus objetivos existen tres formas de organizar un equipo según el tipo de proyecto a desarrollar:

- Resolución de problemas: casos en los que los requisitos son confusos, proyectos de investigación, etc.

- Creatividad: proyectos en los cuales es necesario explorar alternativas y evaluar distintas posibilidades.

- Ejecución táctica: proyectos que constan de un plan bien definido y conocido, con menor incertidumbre.

La elección de uno u otro enfoque dependerá del objetivo fundamental del proyecto. Es por esto que la definición de tal objetivo u objetivos es primordial, ya que seleccionar un enfoque no adecuado puede dañar en cierta medida la consecución de dicho objetivo.

Por otro lado, algunos aspectos a tener en cuenta a la hora de mantener equipos productivos son: roles claros (¿qué papel desempeña cada uno?), monitorización del desempeño individual (qué tareas tiene asignadas, qué tal lo hace, qué dificultades tiene cada miembro en la consecución de sus tareas, etc), comunicación efectiva (¿qué problemas tiene el desarrollo del proyecto en este preciso momento?) y toma de decisiones basada en hechos (conociendo el estado actual del desarrollo, ¿qué acciones tomar? ¿qué camino se seguirá a partir de ahora?).

Tipos de equipos

Business Team

Entre pares, cada miembro se especializa en un tema concreto. El equipo es dirigido por un líder técnico, que será un “par” con experiencia. Lo de par significa que existirá una serie de miembros que serán pares entre sí, en el sentido de iguales en cuanto a su liderazgo, experiencia y capacidades técnicas. Cada equipo será liderado por uno de estos  “pares”. Este líder tomará decisiones finales en temas técnicos. Este rol no tiene por qué ser desempeñado por el propio gestor del proyecto. Funciona bien con equipos pequeños y/o estables. Es lo suficientemente adaptable como para funcionar bien en todo tipo de proyectos (ver introducción). Esta versatilidad es precisamente su principal debilidad, pues no ofrece un rendimiento neto excepcionalmente bueno en ningún tipo de proyecto específico.

Chief-Programmer Team

El equipo se comporta como el equipo de médicos de un quirófano: uno, el más productivo, es el cirujano jefe, el que desarrolla la mayoría del proyecto; el resto están para dar soporte y descongestionar al jefe de las tareas más sencillas. Estas tareas, de muy diversa índole, pueden ser desarrolladas por personal no informático. El jefe debe ser excepcionalmente bueno en lo que hace (lo cual restringe mucho el número de personas que pueden desempeñar este papel). Puede funcionar bien en proyectos creativos y de ejecución táctica.

Skunkworks Team

Consiste en aislar un grupo de desarrolladores con talento y creatividad en una sala donde nadie los moleste y darles libertad para trabajar e innovar. Desde el punto de vista de la gestión, el equipo se comporta como una caja negra:  el gestor no conoce los detalles del estado del proyecto, y de eso se trata precisamente: el equipo trabaja y no es molestado ni coaccionado. Eventualmente surgirá un líder técnico en un cierto aspecto, tarea o tema a tratar; éste será elegido por el equipo. Esta organización maximiza la motivación, la responsabilidad y hace que los miembros se involucren en lo que hacen al máximo. Por otra parte, la falta de visibilidad externa puede ser un problema a tener en cuenta (véase como riesgo). Por todo ello, es fácil entender que este modelo es apropiado para proyectos de creatividad y muy desaconsejable para aquellos de ejecución táctica.

Rapid Development: Taming Wild Schedules, Steve McConnell

No, no. No se trata de JASP, aquel famoso eslógan publicitario de principios de los 90. Aquí voy a hablar de JAD, que es otra cosa bien diferente, si bien todo parecido sería pura casualidad a la par que absurdo. JAD es uno de esos inventos que hacen los americanos, que no tiene nada del otro jueves pero que le ponen unas siglas chulas, para que suene guay y la gente se quede con cara de papagallo cuando les dices que haces JAD, escribas libros y ganes dinero a chorretones. Y aunque yo no voy a ver un puto duro por hablar aquí de esto, escribo porque es una técnica más, interesante, y me gustaría que el lector se quedara con lo que le gustara, desechara lo que no, y de todo ello extrajera algo positivo, aunque sólo sea hacer tiempo hasta que termina de descargar algo en el eMule o en lo que carga un vídeo en YouTube.

¿Qué es JAD?

Dicho esto, comenzamos. JAD es una técnica de definición de requisitos y de diseño de la interfaz de usuario, basada en reuniones participativas entre clientes, directiva y desarrolladores. En dicha reunión los temas a tratar se centran más en el negocio que en el asunto técnico. Lógicamente está más orientado a proyectos de cliente (o bien sistemas a medida, como también se los conoce), y permite recolectar requisitos eficientemente.

Hay que tener cuidado porque estas reuniones pueden hacer ver a los clientes una falsa realidad en cuanto al progreso del proyecto o la productividad. Además, hay que prestar especial cuidado con las estimaciones tempranas, aquellas que entrañan un mayor riesgo por el mayor desconocimiento del sistema y que deben ofrecer una amplitud de rango mayor entre mejor estimación y estimación pesimista.

Esta técnica sale beneficiada si se utiliza en modelos incrementales, ya que permite pulir poco a poco el sistema en función de las necesidades del cliente. Para su buen funcionamiento es fundamental que cada grupo o rol que participa en las reuniones se implique al máximo. Bien utilizada, esta técnica permite ver conflictos entre requisitos y eliminar aquellos menos útiles (costosos, poco beneficio o rendimiento logrado, etc.).

Estructura de la técnica

JAD consta de dos fases: planificación y diseño. Ambas tratan los requisitos, pero a distinto nivel de abstracción. Si bien en planificación se tratan los requisitos a un nivel más alto, estudiando sobre todo la utilidad y la viabilidad de los mismos, en la fase de diseño se realiza un uso intensivo de prototipos y se diseña la interfaz de usuario, el presupuesto, la calendarización y el esquema de la base de datos (en caso de que esto último sea aplicable al sistema a tratar). Cada una de estas fases llevaría en torno a entre uno y diez días. No confundir la fase diseño-JAD con la fase de diseño del proyecto; JAD es una técnica que se aplicaría en fase de planificación y análisis.

Cada fase, además, consta de tres partes: preparación (decidir quién asistirá a cada reunión), sesión o reunión propiamente dicha y conclusión, donde se extraen los principales puntos consensuados durante la sesión y se plasman en algún soporte permanente. El papel está bien, no caigamos ya en la tecnofilia, siempre que sea un soporte permanente, accesible por todos y, sobre todo, refleje un consenso aceptado por todas las partes. Algo así como un contrato.

Una vez terminado el proceso de JAD, se sigue con el modelo de desarrollo elegido. Es decir, JAD es independiente del modelo de desarrollo, con lo cual es aplicable siempre.

Las sesiones

Las sesiones tendrán lugar en lugares apartados, neutrales (sí, esto es la guerra: tú junta clientes, directivos y desarrolladores y no dejes a mano armas de fuego ni blancas o presenciarás una cutre película gore). Además se facilitará todo lo necesario para centrarse en el trabajo: piscolabis, refrescos, nolotiles, aspirinas, etc.

Los roles son los siguientes: moderador, ejecutivo cliente, usuario final, desarrollador, secretario y especialistas en determinados campos de interés para el producto. Estos últimos son los únicos personajes que no necesitan estar presentes todo el tiempo que dure la sesión. Es importante recalcar que cada rol debe ser desempeñado por gente clave, y no debería asistir más de ocho personas (como número orientativo).

Temas a tratar en las sesiones

En el JAD de planificación, que dura entre 1 y 5 días, se trata lo siguiente:

1.- Conducir la orientación. Introducción.

2.- Definir los requisitos de alto nivel.

3.- Limitar el alcance del sistema.

4.- Identificar y estimar las fases del diseño JAD.

5.- Identificar los participantes del diseño JAD.

6.- Planificar la sesión de diseño JAD.

7.- Documentar las decisiones tomadas.

8.- Conclusión.

En la reunión llevada a cabo durante la fase de diseño JAD se tratarán los siguientes puntos:

1.- Conducir la orientación. Introducción.

2.- Refiniar y limitar los requisitos de alto nivel identificados en la fase de plan JAD.

3.- Desarrollar un flujo de trabajo (workflow).

4.- Desarrollar la descripción de dicho workflow.

5.- Diseñar la interfaz de usuario.

6.- Especificar requisitos de procesamiento.

7.- Definir interfaces.

8.- Identificar grupos de datos y funciones.

9.- Documentar las decisiones consensuadas.

10.- Conclusión.

Para terminar…

Como hemos podido ver, tras las siglas JAD se esconde un conjunto de directrices, técnicas y consejos que no son nada nuevas. Aquél que esperaba oír hablar de filostros y forlayos (véase Memorias de un Ingeniero, de Alfredo de Hoces) se ha llevado un chasco. Sin embargo no nos confundamos: JAD reúne un compendio de buenas técnicas de demostrada utilidad, que pueden mejorar el tiempo de desarrollo y aumentar la visibilidad del proyecto. Además utilizada de forma regular, esta técnica puede aportar una mejora en el desarrollo de proyectos en general que la puede hacer muy útil. Finalmente señalar que, utilizada con inteligencia, puede hacer que la satisfacción de los clientes se vea incrementada.

Rapid Development: Taming Wild Schedules, Steve McConnell

Release-Prep Codeline

Este patrón trata de estabilizar un baseline para un release inminente, permitiendo paralelamente el desarrollo del proyecto sin afectar a tal release. Preparar un release implica pasar un buen número de pruebas, solucionar errores, preparar instaladores, documentación, etc. Si se realizan cambios importantes en este periodo crítico, pueden aparecer, de forma accidental, nuevos errores. Por otra parte, si congelamos el desarrollo por pulir el release, perdemos productividad.

Una posibilidad es crear una rama para tal release (al lector avispado que ha llegado hasta aquí leyendo los anteriores post seguramente ya se le había ocurrido tal solución antes de empezar a leer este párrafo), pero si bifurcamos demasiado pronto tal rama se pueden encontrar luego muchos errores en desarrollo que corregir en la release. Por consiguiente habrá que realizar muchas operaciones de fusión o merge, y tales operaciones sabemos bien que son complicadas. Aun así, es una buena solución, y es la que hemos ido adelantando en anteriores patrones.

¿Cómo solventar, entonces, los problemas de dicha solución? Crea la rama cuando el código se aproxime a la mayor estabilidad posible. De este modo el número de errores detectados (y consiguientes merges) será menor. Pero ojo: no esperes demasiado a crear tal rama de release o congelaras el desarrollo paralelo… en resumen: control, visibilidad máxima del progreso, y ojo al dato.

Task Branch

De este patrón podría hablar largo y tendido, y todo serían alabanzas; no en vano es el que usamos en la empresa donde trabajo y los resultados no pueden ser mejores: facilita el control de los cambios, la localización de dichos cambios y a qué afecta, facilita además la integración de dichos cambios en la rama principal, y favorece la productividad, junto con un software de control de tareas competente (Jira, OnTime, y en menor medida Bugzilla, Mantis…).

¿Cómo podría el equipo realizar múltiples cambios a largo plazo y que se solapan en una línea base sin comprometer la consistencia ni la integridad? No vale renunciar al uso de un control de versiones común, por descontado. El problema ya se propuso en otra ocasión: cómo controlar una tarea grande sin interferir en el trabajo de los demás.

La solución, una vez más: ramificar. Y es que el uso de ramas es tremendamente positivo, siempre que se usen con sentido, claro. Utiliza una rama diferente para cada actividad que represente cambios significativos en la línea base. Por tanto este patrón ya necesita un elevado soporte de políticas de desarrollo: definir tareas, asignar tareas, con un determinado tamaño, etc.

De este modo, disminuímos los riesgos (sus efectos, su probabilidad de ocurrencia). Una vez terminada tal tarea, la uniremos, junto con las demás, a la línea de desarrollo principal. Este merge deberá realizarse cuidadosamente para no romper nada que ya estuviera hecho (el lector ya debe estar pensando en otros patrones, como test unitarios, de smoke o de regresión…).

Este enfoque es muy útil cuando hay varias personas compartiendo un trabajo que debe integrarse en un todo. Por tanto, como hemos dicho, este patrón facilita la integración (si algún compañero lee esto se reíra de mí, pero tendrá que reconocer que si integrar es complejo y doloroso, sin este patrón sería una tarea bastante infernal…). Es importante integrar cada cierto tiempo cada rama (que representa a cada tarea) en la rama principal, sino la operación de fusión al final será muy trabajosa. Sin olvidar los riesgos que conlleva trabajar durante mucho tiempo con código desactualizado, lo cual ocurriría en ramas que se bifurcaron hace mucho y que han tardado mucho en integrarse. Solución: tareas cortas. ¿A alguien se le ha ocurrido ya que este patrón funciona de maravilla con metodologías ágiles, como Scrum?

Named Stable Bases

¿Con qué frecuencia integrar? Es importante estabilizar interfaces cuanto antes y que el resto de cambios, más frecuentes, tengan que ver con el cuerpo del código. Etiqueta claramente y de forma coherente aquellos puntos del desarrollo más estables. Son un seguro de vida…

Daily Build & Smoke Test

Control sobre los cambios: contener el potencial de errores en cada compilación del código. Solución: al menos una vez cada día, construir el proyecto (compilarlo) y ejecutar una ristra de Smoke Test. Sobre este patrón Steve Mc Connell sabe mucho, así que si desea obtener más información, el lector puede consultar Code Complete, donde se habla del asunto de forma somera, y Rapid Development: Taming Wild Schedules, donde se trata esta estrategia con mayor profundidad.

Con esto terminamos los patrones. Espero que hayan disfrutado de la serie tanto como yo.

———————————————————-

Referencias:

Steven Berczuk, Brad Appleton: “Software Configuration Management Patterns, Effective Teamwork, Practical Integration“

Regression Test

En esta ocasión, el problema a plantear es cómo conocer si el código en un momento determinado durante el desarrollo no habrá empeorado desde los últimos cambios mientras se realizaban otras tareas. La solución pasa por utilizar otros test complementarios a los Smoke Test que tengan otras características diferentes. ¿Cómo son estas pruebas a realizar? ¿Qué politica seguir para su utilización?

Un problema que surge una vez podría darse más veces. Esto es lo que llamamos regresión. Con esta premisa construiremos unos test que tratarán de asegurar estabilidad en el desarrollo: antes de cada release, antes de un cambio particularmente arriesgado, realizaremos unas pruebas que nos permitan tener un cierto nivel de seguridad de que no hemos desandado parte del camino. Estos test se generarán a partir de cambios que ocurrieron en el pasado: hitos, funcionalidades especiales, etc. Se trata de unos test de caja negra que pueden no identificar qué es lo que falla, con lo cual necesitaremos apoyarnos en otros tipos de test, como por ejemplo los unitarios. Son de grano grueso porque prueban funcionalidades completas, comprueban la integración entre diferentes partes, etc.

Los casos que componen estos test pueden ser antiguos fallos detectados por estos mismos test, fallos informados por clientes, fallos detectados por otros tipos de pruebas… Al final habrá un gran número de casos, que nos ayudarán a comprobar que el sistema avanza. Si el sistemas no pasa las pruebas habrá ocurrido una regresión. Nunca se eliminan casos de prueba de este tipo, porque los errores pueden volver. Debido a su tamaño, estos test podrían ejecutarse por la noche, que suele ser cuando menos carga de trabajo se da. Si es posible ejecutarlos en cada operación de protección o check-in (lo cual es complicado debido al tamaño que van adquiriendo  estos test) podremos ver exactamente el punto en el cual el sistema retrocede.

Private Versions

¿Cómo evaluar un cambio complejo, beneficiándose del control de versiones, sin hacer ese cambio público? Pongámonos en el caso de querer probar un cambio localmente, sin correr el riesgo de romper el sistema global. Para ello, podemos establecer checkpoints en ciertos períodos del camino de tal cambio. Recordar que cuando se sube un cambio al control de versiones, el resto de ítems asimila tal cambio al actualizar sus propias revisiones para formar nuevas versiones. Por tanto, es necesario proveer un mecanismo para hacer checkpoints de cambios con la granularidad adecuada que el desarrollador estime conveniente. Esto podría proveerlo un área local de control de revisiones. Sólo los cambios estables van a parar al control de versiones público. Este sistema debería proveer también de un modo de integración para esos cambios inestables con el estado actual del proyecto. El funcionamiento de este área local funcionará como el control de versiones: una vez estabilizados los cambios, éstos se integran en la línea principal del proyecto siguiendo las políticas adecuadas.

Puede utilizarse, para esto, un repositorio local, una rama privada para el desarrollador en cuestión, etc. Algunas herramientas software de gestión de configuraciones proveen mecanismos para esto mediante, por ejemplo, sistemas de permisos del estilo de ACLs (Access Control List o listas de control de acceso, que vigilan el acceso a determinado elementos de un todo; en este caso, artefactos generados en un proyecto y gestionados por el control de versiones). Lo importante es que el programador pueda trabajar cómodamente subiendo los cambios cuando él considere apropiado, sin entorpecer el trabajo de los demás.

Release Line

¿Cómo realizar el mantenimiento de versiones publicadas (releases) sin interferir con el trabajo propiamente de desarrollo? Debería aislarse lo uno de lo otro. Una versión de producción o release evoluciona de forma totalmente diferente a una de desarrollo, ya que necesita mejoras y mantenimiento. Los problemas surgen cuando se detecta un problema en la versión de desarrollo que hay que actualizar urgentemente en la versión de producción: las operaciones de fusión (merge) son complejas.

Para evitar estas situaciones, es recomendable mantener cada versión de release en una línea de producción diferente. Esto permite que tal línea avance a medida que se solucionan errores. Para ello,  se podría crear una rama (o repositorio) para cada versión de producción. Posteriormente se actualizarán las mejoras y repararciones realizadas en la rama o repositorio de cada release de forma periódica, mediante una operación de merge. La línea de desarrollo (línea principal) será la guía, la cual recibirá los resultados de los merge fruto de las mejoras realizadas release a release.

———————————————————-

Referencias:

Steven Berczuk, Brad Appleton: “Software Configuration Management Patterns, Effective Teamwork, Practical Integration“