Disculpa no haberte respondido antes sobre tu petición. Resulta que el "otro" artículo que te comentaba, no era tal, es el mismo que te mandé.
Por lo que leo, veo que has logrado estructurar bastante tus horizontes y veo mucho la palabra "proceso". Lo cual me parece bien.
Actualmente yo estoy participando en un proceso similar aunque vamos diréctamente respondiendo los requisitos de la norma ISO 9000:2001, que es basada en procesos precisamente. No olvides tratar tambien con los procesos que no son diréctamente relacionados con el desarrollo del SW, por ejemplo la gestión administrativa y la participación de la alta dirección. Te acuerdas que en el artículo se menciona que al menos debe haber un sponsor o un director o gerente altamente comprometido con las mejoras?
Respecto a las métricas, te recomendaría que analices las entradas y salidas de los procesos y busques indicadores que te midan: eficiencia y eficacia.
No se qué tan avanzado estás. Me gustaría seguir comentando las experiencias.
Suerte!
Rolando.-
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
Sent: Wednesday, October 31, 2007 10:02 AMSubject: [calidaddelsoftware] RE: Implantar sistema de calidadHola 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?
>
--
Rolando.-