¬ŅC√≥mo trabajamos?
Metodología de proyectos TI

Como base de nuestra metodolog√≠a de proyectos TI, en Binovo suscribimos el Manifiesto de Desarrollo de Software √Āgil.

Metodología de proyectos TI

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 o 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 con 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, solo 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 estos, puesto que realizar un 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.

Metodología de proyectos TI | Binovo

Manifiesto de Desarrollo de Software √Āgil

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. Al software que funciona frente a documentaci√≥n exhaustiva, a la colaboraci√≥n con los clientes frente a la negociaci√≥n de contratos, respondiendo 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.