Reflexiones metodologías ágiles

Los modelos de desarrollo de software, no dejan de ser eso, modelos. Cada organización tiene sus características y vicisitudes.

Actualmente, para que una organización tenga éxito, esta claro que han de aceptar las bondades de las metodologías agiles, sobre todo SCRUM y XP. Aportan agilidad al desarrollo y menos inconvenientes ante cambios solicitados por parte del cliente, seguros de que se van a producir.

Cada institución, dependiendo de sus cualidades empresariales y laborales, intenta adoptar singularidades de estas metodologías. Fundamentalmente técnicas como las de plantear hitos o sprint que invaliden al cliente de solicitar modificaciones durante ese periodo de tiempo.

Durante el desarrollo de estos periodos de tiempo, en parte debido al desconocimiento de la metodología y, sobre todo, a la corta plantilla laboral; se abstienen de realizar el proceso de reuniones periódicas. Se limitan a realizar una semanal. Minimizando así el tiempo dedicado a estas fases de las metodologías.

La labor cambia en organizaciones de tamaño medio/grande. En éstas, sí suelen tener departamentos especializados y equipos de desarrollo subdividos que han adoptado profundamente el empleo de estas metodologías en el desarrollo de software.

Personalmente sostenemos que es básica la implantación de estas metodologías en una empresa propia de desarrollo de software. Aportan agilidad y satisfacción por parte del cliente al entregar una demo totalmente funcional en cada una de las etapas planificadas. El cliente ve su “programa” a menudo.

Quizá, el método ideal sería una mezcla de SCRUM y XP. Ya que es básico dedicarle una parte mas importante al diseño del producto como así contempla XP. Y la planificación en el desarrollo propuesta por SCRUM.

No cabe duda que estas metodologías involucran mas al empleado, aunque a su vez, le cargan de mas presión; pero ve su trabajo mas satisfactorio al realizar tareas multidisciplinares.

Ayudando si cabe, a su propia formación y currículum, al tener que estar al día de muchas novedades tecnológicas. en varias áreas.

Recomendaciones en el desarrollo de software

Basándonos en la entrevista realizada y las características obtenidas en cuanto al desarrollo de software, varias son las recomendaciones que indicaremos a la empresa:

        I.         Planificación previa de entrevistas, visitas y duración de hitos

Se han de planear entrevistas con las personas que utilizarán el software y visitarlos durante varias veces al mes. Fundamentalmente para identificar el conocimiento que tienen las personas que utilizarán el software.

Debiéndose identificar el tipo de usuario que es: común, avanzado o especialista. Además del sistema operativo del que tienen conocimiento.

Esto aclarará bastante las ideas a la hora del desarrollo del proyecto.

Conocer al cliente para satisfacer sus necesidades informáticas.

      II.         No planificar cambio de sistema operativo para el cliente únicamente por el software a desarrollar.

Para no tener que hacerte cargo de la migración de tu cliente a un nuevo sistema operativo deberían ser capaces de realizar el desarrollo del software dentro de las “comodidades” del usuario.

Si irremediablemente ha de ser así, se ha de asumir y planificar, la formación del cliente al 100% en este nuevo entorno.

     III.         Utilización de herramientas de desarrollo y Frameworks consolidados y “cómodos”.

En la medida de los posible no utilizar lenguajes o entornos de desarrollo desfasados. Esto incluye una formación continua por parte del equipo de desarrollo.

Se ha de ser práctico y tener el conocimiento necesario de herramientas que hagan la vida mas fácil a la hora del desarrollo.

Esto incluye a todos los miembros del equipo pertenecientes al desarrollo. Incluyendo el conocimiento de productos básicos para el testeo de las aplicaciones, controles de versiones, … que permiten la agilidad en el desarrollo.

   IV.         Planificar el desarrollo del producto en base únicamente a lo acordado con el cliente

No inventarse funcionalidades del producto que no ha sido acordadas y que para el cliente pueden no ser funcionales. No intentar ponerte en el lugar del cliente para estimar qué le puede servir de ayuda.

Si no te lo han pedido y no ha sido acordado simplemente NO debes hacerlo.

Si constantemente inviertes el tiempo en incluir este tipo de funcionalidades acarrearán dos consecuencias inmediatas: retardos temporales en entregas y disconformidad por parte del cliente en el software solicitado.

     V.         Busca la sencillez en el producto.

Deberíais ser capaces de desarrollar un producto accesible y con una interfaz clara y sencilla.

Busca referencias claras a la hora de aplicar la accesibilidad de tu producto. Y tener siempre en cuenta que tú No eres el que va a utilizar el software.

No caer en casos como en el de la imagen mostrada:

   VI.         Utiliza y construye librerías y controles propios.

Para buscar una mayor agilidad en el desarrollo de productos de características similares construye una serie de librerías/controles personales que puedan ser reutilizados de forma independiente en diferentes proyectos.

Invierte tiempo en madurar como profesional, mejorando la legibilidad y el estilo de tú código para que pueda ser entendido sobre todo por tus propios compañeros de equipo.

En resumen, abandonar el “egoísmo” que todo programador implícitamente atesora.

  VII.         Asignación de tareas.

Para la asignación de tareas, todo el equipo debería ser capaz de hacer de todo. Para ellos lo ideal es que el equipo sea multidisciplinar, para no incurrir en graves problemas con el cliente en caso de inconvenientes laborales en el personal del equipo de desarrollo.

Pudiendo definir, si así lo estima oportuno, una política de asignación de tareas en base a la carga de trabajo del equipo.

VIII.         No reinventar la rueda.

Por último y no por ello mas importante. Si ya dispone de la tecnología, componentes, librerías,… para hacer una determinada tarea, no pierdas el tiempo en intentar realizarlo a tú manera. Si te va a suponer inversión de tiempo, inviértelo en ampliar el conocimiento sobre ese producto ya existente.