• sábado, diciembre 15, 2018

Entornos y metodologías de desarrollo en el software de gestión

Parte del dimensionamiento de un proyecto de software de gestión se basa en la elección adecuada de los necesarios entornos de desarrollo, así como de las metodologías de desarrollo usadas.

En cuanto a la elección de los entornos de desarrollo, desde el punto de vista de la imprescindibilidad, podríamos ordenarlos (de mayor a menor) en: entorno de producción y entorno de preproducción en el cliente; entorno de desarrollo, entorno de integración y entorno de pruebas en el fabricante. El uso de éstos se aconseja en función de las características y volumen del proyecto.

Hacemos prescindibles ciertos entornos si…

  • Entorno de desarrollo: el alcance funcional del proyecto no implica nuevos desarrollos o éstos son mínimos. Si bien es cierto que entornos de desarrollo siempre habrán, no tiene porqué haberlos específicamente para un proyecto.
  • Entorno integración: solo hay un desarrollador (o ninguno) en el proyecto.
  • Entorno de pruebas: el developer y/o tester realiza una amplia batería de pruebas y éstas no son de elevada complejidad y criticidad.
  • Entorno preproducción: el entorno de pruebas fuese suficientemente parecido al entorno real y los desarrolladores y tester hiciesen las verificaciones y validaciones en profundidad.
  • Entorno de producción: NUNCA.

El entorno de producción es el imprescindible por una cuestión obvia, es aquel donde se realizan todas las transacciones reales de la organización. El resto de entornos cobran mayor relevancia cuanto más desarrollo requiere el proyecto o cuanto más exigente o necesidad de garantías requiere.

En cuanto a la metodologías de desarrollo, profesionalmente he pasado por el modelo de desarrollo en cascada, sobre todo cuando hacíamos proyectos muy importantes de desarrollo a medida. Aunque no tiene porqué ser así, éste es un modelo más orientado a este tipo de proyectos donde la funcionalidad de los nuevos desarrollos ha de entregarse prácticamente de forma íntegra, o por lo menos un número discreto de veces. El inconveniente principal es que el cliente no es consciente del trabajo realizado, siendo el momento de la entrega situaciones altamente críticas debido a que no siempre resultaba ser lo esperado por el cliente.

Sin embargo, hoy me encuentro en una situación de gran verticalización y especialización de las soluciones, y aun cuando existen proyectos donde se hacen amplios desarrollos (que normalmente quedan para el estándar), se hace siguiendo una metodología de desarrollo iterativa y con una gran interacción con el cliente. La realidad es que la verticalización te permite un gran conocimiento del sector, frente a clientes que solo en muy raras ocasiones son capaces de definir los requerimientos, así que normalmente nuestra percepción no suele ir muy desencaminada. Si a eso añadimos múltiples entregas y refinamientos, la integración de los nuevos desarrollos y la nueva funcionalidad requerida por el cliente suelen ir parejos.

La metodología ágil estrictamente hablando no la usamos, aunque de alguna forma, diariamente usamos ciertos conceptos en nuestra metodología iterativa. Así por ejemplo usamos una lista de tareas (backlog) y una asignación de prioridades.

De momento, la opción más viable para mi modelo de negocio es una metodología iterativa e incremental. Ahora bien, ello requiere una correcta promoción de los desarrollos a los entornos cliente.

Una correcta promoción de los desarrollos puede ser la “delgada línea roja” que separa el éxito del fracaso de un proyecto. Veamos qué efectos puede producir una inadecuada promoción:

  • Promoción al entorno de integración: paralización del resto del equipo, desconfianza de los compañeros y pérdidas para la empresa desarrolladora.
  • Promoción al entorno de pruebas: múltiples retornos al entorno de desarrollo, deterioro del ambiente laboral y frustración del tester.
  • Promoción al entorno de preproducción: desconfianza hacia el sistema por parte del cliente y deterioro imagen.
  • Promoción al entorno de producción: desconfianza mayor hacia el sistema, pérdida mayor de imagen e incluso pérdidas económicas.
Lo que se quiere decir, lo que se dice, lo que se entiende ...

El tradicional problema de la metodología en cascada.

Cualquier promoción incorrecta tiene por resultado los retrasos y costes económicos importantes, tanto para el cliente como para la empresa desarrolladora, así que hacerlo correctamente no garantizará el éxito de una implantación, pero sí ayudará a lograrlo.

Anécdota

En una ocasión trabajé para un cliente cuyos requerimientos eran “nulos”. Era incapaz de definir ni una sola tarea en condiciones. Sus requisitos se reducían a algo así como “Hay que controlar la sección de embalaje” o “Hay que controlar el almacén”. De hecho una expresión muy típica suya era “Yo sé lo que quiero y no tengo ni idea de informática ni quiero saber, así que dime cómo”. Era una relación absurda, porque se desentendía de todo y solo quería llegar al resultado final sin “sufrir” el proceso. Ni siquiera tenía personal cualificado para trasladarnos sus necesidades, era él el interlocutor.

Como ya nos conocíamos, en una ocasión me comentó que quería que el resultado de una máquina de corte de tela trasladase la información de las tareas realizadas y los consumos al ERP. Por supuesto le comenté las dificultades que eso implicaba y los desarrollos en los que podía incurrir, pero en su miope visión me dijo que solo quería conocer ciertos datos. Se le hizo un análisis del “pequeño” alcance solicitado, y por supuesto le pareció bien (no lo leyó claro), donde aparecía una alcance bastante limitado.

Cuando llegamos a implementar el desarrollo, su necesidad ya era otra, no solo más amplia, sino también distinta. La máquina de corte no era una, sino cuatro de distintas marcas (y por tanto cada una con un software distinto), los modelos que quería controlar ya no eran modelos, sino agrupaciones de modelos, … 

Bueno, un caos, aun así para no deteriorar la relación mi jefe procedió a ceder en la mayoría de aspectos, pero cada día el desarrollo se iba convirtiendo en exponencial. Mi empresa asumió el coste del desarrollo (unas 4 veces lo presupuestado) por un individuo incapaz de ver más allá de su nariz.

Por supuesto, el cliente estaba muy descontento, a pesar del coste que supuso para mi empresa y no para la suya, y finalmente prescindió de nuestros servicios.

(En el Master en Software Libre de Gestión: Open Source & ERP II, estamos analizando situaciones como la que aquí acabamos de mostrar).

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly
Seguir en Feedly
 
VN:F [1.9.22_1171]
Rating: 4.0/5 (1 vote cast)
Entornos y metodologías de desarrollo en el software de gestión, 4.0 out of 5 based on 1 rating

Related Posts

4 Comments

  1. Calidad del software y planes de pruebas Mundo.erp | Tecnologías ERP
    18 enero, 2015 at 20:00 Responder

    […] pesar de todas las pruebas y detección de errores en las distintas fases del desarrollo del software, tras incluso la promoción del código a producción, es inevitable detectar nuevos errores. Cada […]

  2. Luis Enrique
    5 enero, 2015 at 01:41 Responder

    estimado entonces la metodología agiles con SCRUM para un ERP en SAP no se ajusta?

    • Sergio Martínez
      6 enero, 2015 at 17:48 Responder

      Gracias Luis Enrique por tu comentario.

      En mi caso, no soy implementador de SAP, pero estoy seguro que metodologías como SCRUM pueden aplicar a cualquier ERP.

      Saludos.

  3. Entornos implantación y soporte ERP Mundo.erp | Tecnologías ERP
    21 diciembre, 2014 at 20:02 Responder

    […] un poco sobre el artículo de hace unas semanas ‘Entornos y metodologías de desarrollo en el software de gestión’, podríamos decir que si existen dos entornos imprescindibles en una implantación y soporte de un […]

Leave A Comment