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
Caras nuevas, viejas caras Abril 20, 2009
Posted by ravelus in Crítica social.add a comment
La historia del afortunado José Blanco, o Radiografía de un hombre feliz
Tras un año y pico de las últimas elecciones, y muy probablemente debido a la negativa influencia de la crisis y sus consecuencias, Zapatero ha decidido cambiar algunas caras en su gobierno. O administración, qué coño, que es una palabra muy americana, muy estupenda y muy de moda en estos últimos tiempos. Y claro, los periodistas, que viven de estas cosas (ojo, que no lo digo en tono peyorativo; al fin y al cabo no afirmo más que una verdad como un templo), se frotan las manos.
Para unos, el gobierno sufre el desgaste de la crisis; para otros, Zapatero reacciona positiva e inteligentemente; para unos terceros, el cambio era necesario pero los personajes no son en absoluto adecuados; para unos cuartos, que si muchos son socialistas; para unos quintos, que si el PP también metió a un buen rebaño de afiliados a su partido cuando gobernaban, para unos sextos… De verdad que no exagero; que todo esto lo he oído en las últimas semanas en la SER y en la Cope…
Jo, parece mentira que con lo mal que me caen tanto unos tipos como otros los siga escuchando, pero es que Francino es ameno, y en la Linterna sale un señor con voz de abuelo cascarrabias que estoy convencido que un día le dará un síncope y presenciaré una muerte en directo en la radio por atragantamiento con su propia saliva; pobre señor, ojalá me equivoque, pero es que parece que se le salen los higadillos por la boca cuando habla, qué abuelito más encantador.
Personalmente, me parece una reacción el cambio de algunas caras. Por aquello de la acción-reacción. Sin más. Todo intento siempre es positivo, por qué no decirlo. Ahora bien, que hayan metido a mi querido Pepiño Blanco de ministro dice mucho de nuestro país de pandereta, sevillana y olé. Que un señor que apenas tiene el bachiller llegue a ser Ministro de Fomento, da que pensar. Para que luego digan que EE.UU. es el país de las oportunidades. Para cojones los nuestros, sí señor. Luego está la de economía, que se lució con una ley del tabaco que estaba bien fundada pero mal implementada (cómo nos gusta esta palabra a los informáticos), y que después casi nos quita el vino, aunque dio marcha atrás a tiempo. Reconocer nuestros errores es de sabios, si señora; pero a mí no me toque mis Toros, mis Riberas y Cigales… que la tenemos. Vaya si la tenemos.
Para terminar está la de Cultura. Sinde-mocracia, sinde-scargas… ¿han visto qué fácil es crear chistes fáciles? Esta tipa me da miedo, viendo su trayectoria, su amor por la SGAE y por el colectivo tan idolatrado por mí al que pertenece… Tengo la sensación de que, muy a mi pesar, voy a dedicarle muchas líneas en este blog, seguro.
Hoy también ha salido hablando el de siempre, Aznar, que si no calla revienta, y como no nos quiere dar ese placer, pues tiene que desahogarse, el hombre. Y nuevamente ha sido para soltar gruñidos, rebuznos y demás sonidos inarticulados y sin sentido. También ha abierto el pico Monseñor Rouco, para decir que la Iglesia no está politizada. Qué va, no. ¿Quién ha dicho semejante blasfemia? ¡Rásguese las vestiduras y a la hoguera con él! ¡Por discípulo de Satán! ¡O por ser de izquierdas, que es lo mismo!
Bueno, como ven tengo para todos. Ah, sí, se me olvida IU, pero creo que estos están apagados o fuera de cobertura. Y los sindicatos, que se manifestaron contra doña Espe, la pizpireta. De mayor quiero ser como estos: cogerme horas sindicales a porrillo, ir a manifestaciones a que se me vea bien el jeto, y luego a echar en cara a los que no se afilian que me parto la cara por su culo. Sí que me parto, sí. Inviertan las palabras ‘cara’ y ‘culo’ y cambien alguna preposición más en la oración anterior y entenderán de que se parte la gente que vive de los sindicatos. Para que vean que yo también se hacer chistes fáciles.
Patrones en Gestión de Configuraciones Software (VI y final) Abril 7, 2009
Posted by ravelus in Informática.add a comment
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“
