Bueno, esto deberia estar mas del lado del post de Tuzoftwar, pero el tuzo no me invito al club de tobby-tuzos, y menos por que en la final le iba yo al America y solo por el afan de molestarlo
Empecemos con lo que quiero decir
Mucho de lo expuesto aqui en este blog, puede ya ser calificados como antipatterns de integracion, como lo han notado. Y habla de lo que no se debe hacer.
Sin embargo, muchas veces, sea cual sea el tamaño de la organizacion que desarrolla, siempre se acaba en un punto en el cual algo no fue interpretado como se debia
El punto es, y ahora que lo veo; es muy arriesgado aventarse a desarrollar sin tener un modelo de referencia. Sin embargo todos lo hacemos
Normalmente los de sistemas, vemos el punto de programar, tirar codigo, hacer arquitectura, integrar.
Pero se nos olvida facilmente que detras de ese esfuerzo estan grupos de seres humanos y que tienen un ritmo de trabajo cuando trabajan en equipo.
La administracion de proyectos trata de atacar esa problematica, que tiene varias soluciones por ser enfocada a la mas incierta de las variables, el humano y lograr la meta.
El CMMI es un modelo que indica como debe madurar una organizacion que desarrolla software tomando en cuenta los humanos, definiendo un proceso y lograr obtener productos de software
Lo primero que pide es que seas capaz de administrar tus proyectos, que puedas hacer que algo que lograste una vez, vuelva a suceder; y que minimo te dediques a controlar los requerimientos. Este es el nivel 2 de CMMI. No se preocupa por decir como hacer la ingenieria de software. Y tambien pide que controles tus cambios antes de que te ahogues con ellos, que asegures la calidad y tomes medida (lo que no se puede medir no se puede administrar)
El nivel 3 de CMMI basicamente dice, escribe tu proceso indicando la manera como quieres que todos trabajen y de ahi, ajusta tus proyectos a esa vision (no siempre vas a modelar en UML o si?) y coordinate con otros grupos de trabajo. Y hecho eso, empieza a ver la ingenieria de software, analizar, desarrollar e integrar componentes. Y revisa que cada componente cumpla con lo especificado y validar que se pueda usar por el usuario.
El nivel 4 dice, ya que defines procesos, mide cuantitaviamente como los trabajas y empieza a estimar tu desarrollo en base a estadistica, y reducir la incertidumbre
Y el nivel 5 es, si ya haces tu proceso, ya lo mides, ahora preparate para innovar, para meter nueva tecnologia, para aprovechar oportunidades
Si, son cinco niveles , nada sencillos de alcanzar, pero la verdad es lo fundamental para sacar cualquier proyecto de desarrollo
He visto mucha gente desgastarse en poner decenas o centenas de programadores para sacar mas rapido proyectos, he visto muchos gritando y matando gente bajando la calidad de vida, trabajo inutil en sabado y domingo. Y he visto como en muchos proyectos se tienen que admitir resultados tecnicamente mediocres, con que jale mañana esta bien, al otro dia vemos
Y no es mala fe de las personas, creo que cuando todos arrancamos un proyecto, pensamos " acabo en la fecha, siendo amigos de todos los involucrados y me tomo mis vacaciones". Pero es vivir de la ilusion
Sin embargo, esa buena fe de las personas puede ser mejor utilizada si decidieran abrir su mente al modelo que les menciono o similar. Es ser profesional en tu manera de ser, es hacer lo que debe hacerse, quitarte de tu complejo de superprogramador o de mandon
Solo es estudiar, leer y usarlo para servir a los demas en base a tu conocimiento
Asi que yo creo que mucho de lo puesto en este blog, integracion a la mexicana no es para enfatizar el error de alguien. Es para aprender de la experiencia y demostrar que mas vale razonar las cosas que andar de griton o neurastenico con la gente, que al final son humanos como todos.
Asi que, busquen en Google la palabra CMMI. Puede ser que se topen con un documento muy grande del SEI, muy abstracto; pero al entenderlo, se van a perctar que es tan noble como cualquier pieza de ingenieria hecha por los humanos.
Una vez mas, esto no es religion es ingenieria
