Metodologías ágiles y entregas frecuentes.

En la metodologías ágiles, Scrum por ejemplo, es típico que se hable de entregas al cliente frecuentes, con algo que les sea útil y donde puedan ir viendo los progresos. Últimamente, estoy pensando si eso es o no posible en todos los proyectos. ¿Por qué? Porque en el proyecto que estoy ahora es claramente posible y así lo estoy haciendo, pero eso me ha hecho darme cuenta que en los proyectos anteriores no solo no es tan fácil, sino que posiblemente es poco menos que imposible.

Los proyectos en los que ando actualmente, ya casi desde hace dos años, son proyectos web. Y cada proyecto lleva dos o como mucho tres desarrolladores y se hacen en unos meses, menos de un año, cada uno de ellos. En estas condiciones es fácil hacer entregas frecuentes. Tu proyecto solo lleva software y está público en internet. Así que haces un pequeño desarrollo de un par de semanas, aunque sólo sea el login, o la página principal con un poco de funcionalidad, la subes al servidor, se lo dices al cliente y ellos prueban y dan su opinión. Y repites el proceso cada 15 días o así añadiendo cada vez un poco más de funcionalidad, siguiendo las indicaciones de tu cliente.

¿Y cómo eran los proyectos de antes?. Pues bien, el proyecto más gordo en el que estaba metido era un proyecto en el que había varios departamentos implicados, de software, de hardware, de montaje (hierros, tornillos y cables), etc, etc. En unos camiones suministrados por el ciiente (unos 10 camiones), se montan varios equipos hardware, unos comprados como GPSs, estaciones solaris, PCs con Windows, receptores de radio, .. otros diseñados y fabricados específicamente para el proyecto, bien a otras empresas, bien a otro departamento, como radiogoniómetros o exploradores de frecuencia, … y se hace mucho, pero que mucho software, para controlar todo eso y presentar datos decentes a los usuarios en cada camión. Desgraciadamente, en semejante entorno, el software es lo que menos se nota. Por mucho software en varios lenguajes (Ada, Java y C++ sobre Windows y Solaris) que lleve el sistema, siempre llama más la atención 10 camiones, repletitos de equipos en su interior y con varias antenas gigantes en su exterior.

¿Cómo hacer entregas frecuentes y funcionales al cliente en este entorno?. Teniendo en cuenta que el hardware tarda lo que tarda en llegar, que los camiones no se nos entregan hasta que hay suficiente hardware como para empezar el montaje físico y que la mayor parte importante del software no se puede integrar hasta que están los equipos físicos…. la única opción es hacer simuladores de todo y hacer "demos" más o menos frecuentemente, que el cliente vea la interfaz de usuario, la pinta que tiene, qué datos va a presentar y cómo, como se va a manejar, …. pero todo con datos simulados. Y cuando llega el tiempo de integrar realmente con los equipos hardware verdaderos y ver cómo los ejecutables que corren en los diferentes camiones se comunican entre ellos, os aseguro que es un verdadero infierno, cualquier bug puede ser debido a cualquier cosa, desde un cable mal conectado, pasando por un equipo que no funciona correctamente hasta, por supuesto, un bug en el software.

¿Y cómo haces test automáticos de todo esto? Sí, se pueden hacer test automáticos de las "chorradas", como que si un usuario introduce mal su password no se le deja entrar en el sistema, típico ejemplo de cualquier manual ágil, pero no se puede probar de forma automática y fácilmente que si dos radiogoniómetros en camiones distintos detectan un emisor de radio y se triangula su posición, aparece dibujado en el mapa de  un tercer camión (de hecho, tiene que aparecer dibujado en el mapa de todos los demás camiones). Un test automático de todo esto, eliminado el hardware y sustituyéndolo por simuladores, implica arrancar al menos tres ejecutables (uno por camión), más los simuladores si son ejecutables sueltos ya que simulan un equipo hardware, y verficar que en un mapa (o en la base de datos que hay detrás del mapa) aparece el emisor de radio detectado en la posición correcta.

Estoy mucho más de acuerdo con la filosofía ágil que con la tradicional, pero no existe la llave inglesa universal que vale para todo tipo de tuercas y  tornillos simultáneamente. Si es posible aplicarla, adelante, y si no es posible, hay que hacer lo que se pueda intentando conseguir lo mejor de ella.

Entradas relacionadas:

Esta entrada ha sido publicada en metodologías y etiquetada como . Guarda el enlace permanente.

7 respuestas a Metodologías ágiles y entregas frecuentes.

  1. Cale Vin dijo:

    Gracias por compartir tus experiencias, siempre es bueno conocer las experiencias reales de otras personas!

  2. churros dijo:

    Muy buen artículo, sí señor.
    ¿ No sabía que el Ada todavía era utilizado ? Me imagino que será alguna evolución de aquel primer Ada.

  3. Chuidiang dijo:

    @churros pues sí, el ada se sigue usando en los sistemas donde un fallo software puede ser catastrófico, como los sistemas de control de tráfico aéreo. En los sistemas de los que hablo en el post ADA era requisito también por su seguridad.

    Este es el compilador ADA gratis más usado http://www.gnu.org/software/gnat/ y hay gente que lo mantiene muy vivo http://libre.adacore.com/

    Se bueno.

  4. luis dijo:

    no soy un experto en el tema pero creo que una solucion es

    que puedes hacer es continuar con las pruebas con «simuladores» con estas pruebas compruebas solo tu software

    luego creas otras pruebas «con fierros» es decir a la mala haciendo llamadas directas al hardware con su propio api y con estas pruebas compruebas compruebas que el hardawre y el fostware están bien conectados

    otra forma es que contrates expertos en «fierros» aparte que comprueben manualmente al estilo pruebas exploratorias «desde el gui» y que ellos tambien

  5. Rodrigo dijo:

    En el caso que comentas con mucho hardware, posiblemente la mejor opción sea crear unos buenos prototipos para mostrarle al cliente y que decida sobre ellos las modificaciones a realizar.

    Recuerdo algún proyecto de aquella época en la que estaba con vosotros, que alguna vez los clientes pedían unos cambios tremendos con el proyecto prácticamente finalizado y que para hacerlos era necesario un gran esfuerzo. Eso se puede solucionar con un buen prototipo creado al inicio del proyecto.

  6. Rodrigo dijo:

    @churros

    Hace tiempo que no programo en Ada, el original es el Ada 83 y después salió el Ada 95 que es orientado a objetos. Aunque tiene algún defecto en la orientación a objetos, el ada tiene cosas muy interesantes desde mucho antes que otros lenguajes de programación.

  7. juan dijo:

    Que yo sepa cuando hablas de desarrollar soft integrado al hard, siempre se usa C o ADA o cliper,etc(depende del contexto)m en un pequeño dispositivo yo usaria cliper o C en algo mas seguro tipo S.O.(mucho control de hard,entender sus apis y demas) si bien C lo usa linux es mas mantenible desde mi punto de vista usar ADA, ver que se genero para la defensa, luego si el desarrollo debe ser reseguro(tipo para un modulo espacial)este soft debe ser verificado(metodos teoricos-practicos)vistos en la licenciatura en informatica de hecho una materia compleja pero utilizado para este tipos de cosas, en lugar de generar un control web seria mas adecuado para este tipo de sistemas generar una aplicacion, porque si fuese web verificarla seria demasiado costoso e imposible dado que si se usan diferentes frameworks en su desarrollo o incluso el mismo sistema operativo no pasarian las verificaciones.Yo usaria un sistema operativo de tiempo real tipo marteSO y un desarrollo con ADA, aunque quizas sea demasiado para lo que busques, a menos que los camiones sean espias de USA.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.