enero 22, 2008

La chispa de la vida

Hoy hemos acabado discutiendo si los proyectos de software son como los de construcción o los de hacer tortillas de patatas (sic).
La gestión "clásica" de los proyectos (tipo CMMI, con toda la literatura que eso implica) con todas las técnicas y procesos de gestión de requerimientos, gestion de riesgos, planificaciones,... pueden ser usadas para todos los proyectos que creamos las personas. Pero un nivel 5 de CMMI no implica un éxito garantizado de los proyectos de software.
Tampoco la gestión ágil de los proyectos (XP, o SCRUM,...), como contraposición al modelo anterior garantiza que el desarrollo del proyecto vaya a ser un éxito. Tiene otro enfoque, ni mejor ni peor, depende de la ocasión y el contexto.
Sin duda Juan Palacio lo presentaba acertadamente como la tesis y la antítesis, de la que saldrá una síntesis en gestión de proyectos. Pero ¿puede existir algo que haga exitosos todos los proyectos software? Quizás demasiado complejo para implementarlo, pero ¿podría existir? Unos pasos previos que nos pongan en alerta ante cualquier fallo de software ANTES de que ocurra.
Un arquitecto sabe si se le va a caer el edificio o el puente antes de construirlo, le basta con simularlo. Pero no podemos simular un software, su simulación real requeriría la construcción del propio programa, con lo cual no lo simulamos, si no que lo probamos.
Un cocinero sabe qué queda despues de mezclar los huevos con las patatas, pero un desarrollador no puede estar seguro como va a ser la integración de dos componentes interactuando juntos, si tendrán problemas de integración, hasta que no los prueba.
En definitiva, que sabemos que no existe la "bala de plata", y que esta no va a existir. Esto hace mucho más divertido e interesante nuestro trabajo, o ¿no nos reiríamos más si de vez en cuando se cayese un puente o la tortilla de patatas no cuajase por más que la cociesemos?

3 comentarios:

  1. El cocinero, ha ido a hacer la compra, tiene una cocina y luego debe limpiarla y recoger la basura.
    El ingeniero, hace un proyecto, gana el concurso y luego debe abaratarlo y justificar las desviaciones y reingeniería, para cobrar mas.
    Vosotros, codificadores, necesitáis mas goma de borrar que lápiz y el soporte, lo pone el cliente. No estáis mal.

    Los blogueros, ni goma de borrar y desde la playa, por eso los ingresos no son mas grandes.
    ¡Salud!

    ResponderEliminar
  2. Difícil explicar mi opinión al respecto, más no siendo técnico ni desarrollador, pero si gestor de proyectos, incluso de "tortillas de patatas".
    Mi opinión, y sin entrar a fondo en el tema es que los propios desarrolladores de software son los culpables de que consideren a sus proyectos diferentes al resto.
    Las diferencias que aporta Joserra en cuanto a que dichos desarrollos no se tiene la certeza de que funcionen hasta que se concluye, ocurren también en otras áreas (pongamos el propio ámbito de la construcción a la hora de abortar el diseño del proyecto) ... hay muchas variables por ejemplo subjetivas que afectan al mismo, como los propios gustos del cliente.
    Incluso una vez terminados se hacen pruebas para asegurarse de que dichas construcciones existen (pruebas de peso en los puentes por ejemplo ... ¿Acaso los calculos no estaban bien?) ...y los proyectos, pese a que las especificaciones son las que son y los calculos también, tambien se desvian como cualquier otro proyecto.
    El factor principal en un proyecto de desarrollo de software es que dejamos demasiadas especificaciones en el aire, o dejamos demasiada opción al cambio y por eso esas metodologias ayudan, pero quizas se deberían atajar esos problemas previamente y utilizar estas metodologias para minimizar el error.
    Ayer en la reunión se comentó que un cambio en software, como se puede hacer, se permite ... en la construcción también se puede hacer, otra cosa es que no te lo permiten. ¿Acaso alguien a la entrega de su piso no ha pedido que le tiren algun tabique? Se le permite? ... con una metodología ágil, no se podría haber evitado dicho cambio antes de su construcción? ¿no es esto lo mismo?
    ¿Y si me hacen la tortilla con cebolla y no me gusta? Claro, ya no se puede cambiar, pero ¿en software si? ¿por qué? Ah, es que es complicado tomar especificaciones tan detalladas ... es que no sabemos si la integración va a funcionar ... ¿y si le hecho sal, algo normal y quien la va a comer es hipertenso? ... o si simplemente, ya no le apetece comerla? ... CREO QUE NOSOTROS MISMOS HACEMOS QUE UN PROYECTO DE SOFTWARE SEA DIFERENTE AL RESTO Y NO DEBERÍA.
    la definición de "proyecto" nos dice: "Un proyecto es un esfuerzo temporal emprendido para crear un producto o un servicio único. Así, el resultado final buscado puede diferir con la misión de la organización que la emprende, ya que el proyecto tiene determinado específicamente un plazo y el esfuerzo es temporal." ... ¿que hay de diferente entre unos y otros? ...
    Perdemos de vista otros factores que influyen en el desarrollo del proyecto y que lo determinan (presupuesto, negociación, plazos ...) y no solo el propio desarrollo de software.
    También se habló de que no es lo mismo un proyecto web que un proyecto de una aplicación ... tampoco creo que esto sea cierto.

    Y por último, el CMMI es un "Modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software" ... por algo será que todo el mundo intenta sacarse esta certificación.

    ResponderEliminar
  3. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar