Siento contestarte tan tarde, pero es que he estado más liada que la
pata de un romano....

No te puedo dar una visión completa de lo que supuso la implantación
de del CMMI II, ya que me tocó colaborar sólo en una parte de la
implantación.

Sin saberlo, llegué a la misma conclusión que, después, me
explicaron en un curso de CMMI.

La parte en la que colaboré para la implantación ha sido la Gestión
de la Configuración. Casi nos costó sangre sudor y lágrimas.

En el curso, el profesor (ex- compi de trabajo) me confirmó que una
de las parte más arduas en la implantación del CMMI es la Gestión de
la Configuración o CM.

¿por qué?

Muy fácil... Pero a ver como lo explico.

Imaginate que tienes que crearte un sistema con el que tirando sólo
de un hilo, logras que te salga todo el material con el que has
trabajado en una cosa (planes, analisis funcionales vb del cliente,
objetos que tocas en el sw, etc). Y que todo el mundo tiene que
utilizar los mismos nudos y en el mismo orden, para atar los EC que
te has definido.

Ahí te cuesta un rato ponerte a pensar. En nuestro caso teníamos
mecanismos que nos facilitaron esta tarea. Ejemplo: una herramienta
que clasifica los diferentes tipos de servicios y que genera un
código único para cada petición de cada tipo de servicio.

Otro de los problemas fue saber como trabajaba la gente. En el área
en la que lo implantamos hay varias tecnologías. Menos mal que
existian algunos procedimientos en la forma de trabajar. Parte de
esto es gracias a la herramienta de la que hablaba antes. (Cada
petición debe pasar por unos estados). Y, dentro de lo que cabe, no
tuvimos que modificar mucho su forma de trabajar.

Pero intentar conceptualizar y desglosar esas formas de trabajo es
un trabajo que requiere un esfuerzo mental, en mi caso, un poco
grande.

Pero lo más duro es "incrustar" los procedimientos definitivos a la
parte de Desarrollo. Digo incrustar porque no vale intentar
convencerlos en los primeros meses. Se lo tienes que incrustar...

Trabajar con la Herramienta de control de cambios y "oficializar"
los procedimientos establecidos, les costó "un poco".

Ármate de paciencia por las protestas de la gente. Primero es
desconfianza. Luego se pasa a un estadio de "¿Pero me está tomando
el pelo?".

Cuando lo empiezan a hacer, pasan a un estadio de "eso no lo hago ni
loco".

Cuando ya no les queda más remedio de hacerlo (Punto crucial para
CM: el aseguramento de la calidad, para que lo que has definido en
la CM se implante e institucionalice), se van amansando y llega un
día (te lo prometo, que llega) en el que te llaman y te piden que
les ayudes a recuperar una versión anterior, ya que alguien ha
metido la gamba y, en el entorno de desarrollo, ha subido un fichero
que no compila (ese día casi te pones a llorar de la alegría que te
dan).

O que cuando se incorpora una persona nueva, le dan la guía de CM,
basta que le expliquen un par de veces donde y como puede encontrar
la documentación o como se etiqueta los docs, siguiendo el cuadro
correspondiente y empieza a funcionar.

Que, en caso de que alguien no esté o se haya ido de la empresa, no
hace falta ir a rebuscar en su PC la documentación o el fichero de
sw, perdiendo un tiempo que a veces no sirve apra nada porque no se
encuentra.

Entonces es cuando ya no gruñen tanto. Es cuando se dan cuenta que
el curro que les suponen algunas cosas se ve recompensado.

Lo que si te insisto es que intentes respetar lo más posible los
posibles procedimientos que ya haya.

Que no dejes decaer la tarea del aseguramiento de la calidad, porque
entonces todo lo que implantas, se va al garete. Tiene que ser
periódica, constante e inflexible.

Piensa o pregunta si vais a querer pasar a un nivel III porque en
ese caso tendreis que pensar en herramientas o sistemas que te
faciliten métricas.

Pregunta o piensa que métricas son las que te va a poder interesar.

En fin, no se me ocurre más por el momento. En caso de que tengas
cualquier duda, dime e intentaré contestar antes....

Un saludo,

Elena

--- En calidaddelsoftware@yahoogroups.com, "Dani" <dsanchezg@...>
escribió:
>
>
> Ante todo, muchas gracias a todos por vuestras respuestas. Las
tendré en consideración para mis futuras acciones. Decir que me ha
resultado particularmente interesante este correo tuyo, Elena. En el
área de trabajo de la empresa en la que estoy queremos implantar el
nivel II de CMMI también. Me encantaría que me comentaras cómo fue
el proceso, problemas que tuvísteis, etc.
>
> Ahora mismo estoy arrancando, pero creo que se podría pasar por
una serie de fases que podrían ser:
>
>
>
> 1) Análisis de la situación inicial de partida: Habría que recabar
toda la información posible de los procedimientos, reglas
improvisadas o ausencia de las mismas para entender de dónde se parte
>
>
>
> 2) Detectar necesidades de procesos: Se trataría de definir qué
procesos son los que se deben incluir y para qué finalidad. En esta
fase participarían responsables de proyectos / productos,
desarrolladores, etc, los cuáles contarían sus problemas cotidianos,
experiencias, soluciones.
>
>
>
> 3) Formalizar procesos: Seguramente hay procesos que ya se están
utilizando y que son buenos. Es esa frase que indicas en tu
correo "Todo el mundo tenemos un ligero concepto de lo que es la
calidad en SW.". Pienso que los procesos de calidad deben ser
consensuados para que cueste poco trabajo asimilarlos, sean
flexibles y aceptados por todo el equipo. La mejor forma de lograr
esto sería "normalizando" los procesos no escritos que se están
utilizando en la actualidad. En esta fase se fijarían dichos
procesos.
>
>
>
> 4) Definir nuevos procesos: Allí dónde no existan procesos
definidos, será necesario crear nuevos. Para esto se pueden hacer
reuniones con algunos o todos los miembros implicados en la que se
recogerán y ordenaran ideas utilizando técnicas de brainstorming o
similares. Aunque puede ser un proceso más costoso a la hora de
dirigir las reuniones y sacar conclusiones, estas serán más sólidas
una vez definidas las reglas y encontrarán mayor consenso.
>
>
>
> 5) Formación: Se impartirán sesiones formativas cortas para
despejar dudas, afianzar los métodos, etc.
>
>
>
> 6) Definir métricas para los procesos: Estas estarán orientadas a
medir el éxito o fracaso del conjunto de procesos, logros
alcanzados, etc.
>
>
>
> Mi objetivo es que se implante un sistema lo más flexible posible
y que garantice el mínimo de calidad que queremos alcanzar. El
marketing queda en segundo plano (aunque es lógico usar un
certificado de calidad como marketing).
>
>
>
> No se si esta forma de enfocarlo es correcta, o tal vez
demasiado "process pop-up", como dice en el artículo tan interesante
que ha enviado Rolando Pallares (por cierto, si recuerdas ese otro
texto, me encantaría leerlo).
>
>
>
> Saludos,
>
> Daniel Sánchez
>
>
>
>
>
> ----- Original Message -----
> From: Elena Biglino
> To: calidaddelsoftware@yahoogroups.com
> Sent: Wednesday, October 31, 2007 10:02 AM
> Subject: [calidaddelsoftware] RE: Implantar sistema de calidad
>
>
> Hola Dani,
>
> Hace poco, en un área de mi empresa (Indra), hemos implantado el
nivel
> II de CMMI.
>
> Que me corrijan los que tiene más experiencia, pero creo que el
primer
> paso que se tendría que dar es analizar como se trabaja en tu
> departamento.
>
> Todo el mundo tenemos un ligero concepto de lo que es la calidad
en SW.
>
> Lo segundo es ¿hasta que punto se quiere llevar la calidad?. Se
puede
> ser más o menos exigentes. Para esto puede ser útil tener algún
modelo
> en mente y marcar los objetivos a conseguir.
>
> Y ya lo que queda es comparar lo que se tiene con lo que se
quiere y
> pensar que acciones, acordes con la forma de trabajar de tu
> departamento, podrían ser las que permitan obtener los objetivos
> propuestos. De forma coordinada y paulatina.
>
> Si se puede implantar esa calidad en una sección de Dpto, para
ver en
> que se puede mejorar (y, sobre todo, simplificar), sería mejor.
A
> nosotros, esto nos permitió corregir errores de implantar una
forma de
> trabajo que no iba bien. Y cuando ya todo estaba más depurado,
lo
> pasamos a una escala mayor.
>
> Desde mi punto de vista te podría decir que la gestión de la
> configuración y el control de versiones es lo más importante y
sobre
> donde se tendría que hacer más hincapié.
>
> Y que, por supuesto, que no se te ocurra, ni por asomo, dejar de
lado
> un equipo de pruebas funcionales ajeno a la parte de Desarrollo.
> Pero te estaría dando una visión muy parcial de mi forma de
pensar
> sobre la Calidad y, además puede que en tu dpto. esto no sea ni
lo
> prioritario ni lo que le conviene.
>
> Recalco, yo soy semi-nueva en estas cosas. Y repito: que me
corrijan
> los que tiene más años de experiencia en esto...
>
> Un saludo,
>
> Elena
>
> --- En calidaddelsoftware@yahoogroups.com, "Dani" <dsanchezg@>
> escribió:
> >
> > En mi departamento estamos iniciando el proceso de
implantación de un
> > sistema de calidad, pero todo está por definir. ¿Qué
considerais
> importante
> > en un sistema de calidad? ¿Qué líneas generales habría que
tener en
> cuenta?
> >
>