Errores comunes en desarrollo software (III) Julio 4, 2009
Posted by ravelus in Informática.add a comment
- 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.
Referencias:
Steve McConnell: Rapid Development, Taming Wild Schedules
Turismo rural en Aliste (Zamora) Junio 27, 2009
Posted by ravelus in Cultura, Experiencias.add a comment
Hace ya unas cuantas semanas estuvimos mi novia y yo haciendo turismo rural por la región de Aliste, al oeste de Zamora, una zona muy bella en cuanto a paisajes y tranquilidad que recomiendo a todo el mundo.
Aliste es una región húmeda, contrastando con la zona del este de Zamora (Tierra de Campos), mucho más seca. Mientras que el oeste es zona de pastos y vegetación abundante, que bien nos puede recordar al norte de España, la zona oeste es más típica de la meseta castellana, con campos de cereal y llanuras interminables. Cubre desde la sierra de la Culebra al norte hasta la zona de Sayago al sur de Zamora, por el oeste con la frontera de Portugal y con el este aproximadamente con la Vía de la Plata, antigua calzada romana utilizada para transportar plata desde las minas asturianas a los puertos de Cádiz, aunque probablemente se empezó a utilizar antes por otros pueblos. Hoy, carretera nacional y vía del peregrino del sur hacia Santiago de Compostela.
Estuvimos en un pueblecito llamado Ceadea, a pocos kilómetros de Alcañices, cabecera de comarca de la región. Es un pueblo tranquilo, típico de la región, donde las linderas de las tierras se separan con lo que ellos llaman cortinas, que no es más que un muro de piedra de unos 80 cm. de altura.
Vista del pueblo de Ceadea
Lamentablemente para mí, no es una buena zona de senderismo, debido a que no hay rutas bien trazadas y hay poca información al respecto. No hay una buena coordinación entre los distintos concejos para tratar de establecer un conjunto turístico regional importante, lo cual es una verdadera pena. En Muelas de Pan, por ejemplo, existe un pequeño museo de alfarería típica de la región, pero poca gente sabe cuándo está disponible.
De modo que los mejores conjuntos paisajísticos serán visitados en coche. Posiblemente desde el punto de llegada se pueda, posteriormente, hacer alguna ruta. Los lugares más interesantes son:
- La Sierra de la Culebra, a la que se puede acceder en coche, pasando por el pueblo de Villardeciervos, cuyas casas de piedra y madera son curiosas de ver; otro pueblo, éste semi-abandonado, sería Sta Cruz de los Cuérragos, un pueblo muy bello de calles y casas empedradas y tejados de pizarra. Desde allí se puede hacer una pequeña ruta a pie, de una media hora, descendiendo al Valle de los Infiernos, que cae a la derecha del pueblo, en un aparcamiento gratuito que hay.
Una casa típica de Villardeciervos, pueblo que prosperó gracias al contrabando con Portugal de diversas materias
Santa Cruz del Cuérrago
- Los Arribes del Duero, con varios pueblos para recorrer. El principal atractivo turístico de la zona probablemente sea el Puente Pino, en Pino del Oro, un puente de cien años de antigüedad, el primero de hierro que se construyó en España. Se accede por una carretera serpenteante por la cual no conviene correr mucho.
Puente Pino. Impresiona verlo en vivo y en directo 
- Miranda de Duero, en Portugal. Cruzando la frontera, está este bonito pueblo (más bien ciudad) portuguesa, típicamente conocida por sus baratas toallas. Personalmente me quedo con sus bares, sus cafés bien cargados y aromáticos a 50 céntimos, sus bacalaos a la dorada y sus vistas del río Duero.
Catedral de Miranda do Douro, en Portugal
- La propia región de Aliste, con sus paisajes, sus vacas y su ternera de Aliste con denominación de origen, que tuve la oportunidad de degustar en la casa rural donde nos hospedamos y es una auténtica delicia. En horno de leña y chimenea tradicional. De la brasa al plato. Una gozada.
A la parrilla, sabe mejor 
- Embalse de Ricobayo y región circundante. Es un embalse que se construyó hace varias decenas de años. En esa zona, más soleada y seca, existen algunas rutas de senderismo y escalada.
Otros pueblos interesantes son Tábara, Alcañices (donde hay una pequeña ruta muy agradable que discurre a lo largo de un arroyo, pasando la Torre del Reloj), Fornillos de Aliste… Como curiosidad sepan que en esta región la Casa de Alba tiene importantes extensiones terrenos…
Torre del Reloj de Alcañices. En el Medievo este pueblo estaba amurallado.
El visitante también podrá hacer alguna ruta a caballo y practicar deportes acuáticos.
Si pueden hacer una escapadita de fin de semana o un pequeño puente, no lo duden, visiten Castilla y León. No hace falta ir más lejos cuando lo bueno lo tenemos aquí.
Errores comunes en desarrollo software (II) Junio 20, 2009
Posted by ravelus in Informática.add a comment
- 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).
Referencias:
Steve McConnell: Rapid Development, Taming Wild Schedules
Errores comunes en desarrollo software (I) Junio 12, 2009
Posted by ravelus in Informática.9 comments
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.
Referencias:
Steve McConnell: Rapid Development, Taming Wild Schedules
Un año “Realizando la idealidad” Junio 2, 2009
Posted by ravelus in Experiencias.add a comment
Vale, no he realizado ninguna idealidad, pero el título quedaba chulo, no me dirán que no.
Hace algo más de un año que abrimos las puertas por primera vez, nos trasladamos a WordPress, montamos el chiringuito, nuestro púlpito y ale, a disertar estupideces. Y si el tío de Kriptópolis, los de Microsiervos, el otro y el otro (vean más abajo la sección de Enlaces) hacen autopropaganda y falsa modestia publicando cada poco sus cientos de miles de visitas recibidas, vendiéndolas como un “gracias” cuando en realidad es un “cómo molo, molo muchísimo, si llegara a chupármela me la metería hasta el esófago, oiga”, pues yo no voy a ser menos. A partir de aquí toda comparación sería absurda, pues las visitas que he recibido en un año son menos de las que estos sitios reciben en un día, y su mérito tienen, sin duda alguna. Pero desde el punto de vista personal estoy más que satisfecho que cada día me siguan más de 40 personas, a pesar de las divagaciones y de las estupideces; hace que me sienta “alguien” en el inmenso mundo de Internet el tener 70 comentarios, que aunque las cifras son ridículas bien merecen mis más sincero agradecimiento. No espero más, no aporto nada original ni rompedor, simplemente escribo palabras, no nos equivoquemos.
Esto no es falsa modestia, es lo que hay. Es cierto que me gusta escribir y que probablemente aunque tuviera cinco visitas o ninguna lo seguiría haciendo, pero saber que probablemente hay unas veinte o treinta personas (como mínimo, calculo yo) que no conozco y que me siguen al menos una vez a la semana (se notan los picos a comienzo de semana), aparte de las que me conocen y me siguen, que unas veces me critican por tiquismiquis, cutre, sabelotodo y prepotente y otras veces me dicen que soy gracioso, sincero, o que están de acuerdo conmigo, eso para mí es mucho. Eso anima a seguir escribiendo. No soy nadie, no espero cientos de miles de seguidores; sólo espero que alguien, por pura casualidad, y buscando quién sabe el qué, se deje caer por aquí y le guste lo que vea, o que le disguste, y lo comente. Muchas gracias, de verdad. Estos son los números, y estoy muy orgulloso de ellos:
Tipos de equipos según su organización (II y final) Mayo 19, 2009
Posted by ravelus in Informática.add a comment
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?
Referencias:
Rapid Development: Taming Wild Schedules, Steve McConnell
Tipos de equipos según su organización (I) Mayo 6, 2009
Posted by ravelus in Informática.1 comment so far
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.
Referencias:
Rapid Development: Taming Wild Schedules, Steve McConnell
JAD (Joint Application Development) Abril 27, 2009
Posted by ravelus in Informática.add a comment
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.
Fuentes bibliográficas:
Rapid Development: Taming Wild Schedules, Steve McConnell
