PDF Imprimir Correo electrónico

Llamamos gestión de proyectos tradicional a la gestión que se realiza en los proyectos que tienen las siguientes características:

  • Conjunto de requisitos cerrado
  • Presupuesto cerrado

Este tipo de proyectos tienen un alto grado de fracaso. Las razones para el fracaso son variadas:

  • El conjunto de requisitos no está realmente cerrado. El cliente no es capaz de enumerar en suficiente detalle todas las necesidades que tiene y el proveedor no es capaz de prever correctamente la magnitud del problema a resolver. Esto provoca que las expectativas del cliente no se cumplan, que los plazos y costes se desvíen mucho más de lo razonable, etc. Generalmente el cliente termina teniendo que pagar más o el proveedor perdiendo dinero para conseguir que el cliente acepte lo que se le entrega.
  • El desarrollo de software no es construcción sino diseño. Se han devastado bosques enteros fabricando libros que hablan de la ingeniería del software, de la construcción de software y del software factory. Nombres pomposos para unas teorías formuladas por personas que nunca han desarrollado software en la vida real. El desarrollo de software carece de la repetitividad, medibilidad y predictibilidad que tiene la construcción. No la tiene porque desarrollar software es diseñarlo (equivalente al diseño y planos técnicos de la construcción, sólo que de mucha mayor magnitud), mientras que construir software es compilarlo y/o instalarlo. Programar es diseñar, da igual el detalle de diseño previo que se haya generado. Siempre se están tomando decisiones de diseño cuando se programa algo. Esto implica que el tiempo necesario para realizar un desarrollo es altamente impredecible, sobre todo cuando no se cuentan con unos requisitos detallados, pero incluso cuando se cuentan con éstos, puesto que realizar el análisis suficientemente exhaustivo de los requisitos equivale a diseñar la solución.
  • Se crean expectativas que no se pueden cumplir en el cliente. Siempre le decimos al cliente que vamos a cumplir los plazos y que el sistema va a hacer todo lo que él quiera (¡y además que va a ser muy barato!). Nunca se cumplen los plazos y el sistema nunca hace todo lo que quiere el cliente, porque el cliente según ve la aplicación se le ocurren nuevas cosas que debería hacer. El cliente no tiene un control sobre los costes del proyecto: lo que tiene el cliente es un cheque en blanco, porque ha obtenido una cifra fría, sencilla y clara de lo que le va a costar el proyecto y va a demandar que la aplicación haga lo que él cree que tiene que hacer hasta en el último detalle. El cliente no recibe la información de que un detalle puede ser muy costoso; por el bien de los proyectos, siempre debe ponderarse la funcionalidad frente al coste.
  • Las necesidades del cliente cambian. Las necesidades del cliente han podido cambiar porque la empresa o el entorno han cambiado o porque se han visto otras posibilidades más interesantes.

En Binovo suscribimos el Manifiesto de Desarrollo de Software Ágil, de forma que valoramos:

  • A las personas y sus relaciones frente a los procesos y las herramientas.
  • Software que funciona frente a documentación exhaustiva.
  • Colaboración con los clientes frente a negociación de contratos.
  • Responder al cambio frente a seguir un plan.

Aunque las segundas partes de las sentencias tienen valor, creemos que la primera parte tiene mucho más.
Para ello, seguimos los siguientes principios:

  • La prioridad es satisfacer al cliente mediante la pronta y continua entrega de software valioso para el cliente.
  • Aceptamos cambios en los requisitos, aunque sea al final del desarrollo. Pensamos que los cambios son necesarios para una ventaja competitiva de nuestros clientes.
  • Entrega de software que funciona de forma frecuente, entre 2 semanas y 2 meses, prefiriendo siempre el tiempo más breve.
    Las personas que conocen el negocio y los desarrolladores deben trabajar a diario conjuntamente a lo largo del proyecto.
  • Construimos los proyectos sobre personas motivadas. Damos el ambiente y el apoyo que necesitan y confiamos en que lleven a cabo el trabajo.
  • La forma más eficiente de comunicar información a y dentro de un grupo de desarrollo es la comunicación en persona.
  • La principal métrica de progreso es software que funciona.
  • Los procesos ágiles promueven un desarrollo sostenible.Los promotores, desarrolladores y usuarios deben poder mantener un ritmo constante de forma indefinida.
  • La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.
  • La simplicidad, el arte de maximizar el trabajo no realizado, es esencial.
  • Las mejores arquitecturas, requisitos y diseños surgen de equipos auto-organizados.
  • De forma regular, el equipo refleja cómo convertirse en más efectivo, ajustando su comportamiento de forma consecuente.