CMMI.... suena lindo...pero en la practica no lo es tanto...
Si yo le digo a mi cliente que me demoro 3 meses en un proyecto pero...con documentación y estándares CMMI me demoro 6 meses, se borrara la sonrisa en mas de una cara.
Debe haber otra manera de llevar toda esa estructura y desarrollar privilegiando los objetivos y la comunicacion sobre la documentacion y los roles.... Fue en ese momento que me puse a buscar..... y encontré lo siguiente....
"
Individuos e interacciones sobre procesos y herramientas
Software que funciona sobre documentación exhaustiva
Colaboración con el cliente sobre negociación de contratos
Responder ante el cambio sobre seguimiento de un plan
"
Esos son los fundamentos del las Normas Ágiles de programacion que ahora están en proceso de incorporarse en CMMI... y parece que es lo que se viene....
Tu eres ágil?
Entradas
6 comentarios:
yo como cliente me importa un nabo que uses herramientas CMMI. Me interesa la cuestion funcionando sin errores lo antes posible o a la fecha programada.
si le tenis que meter palos a tus programadores para que hagan toda esas buenas practicas, es drama tuyo..
En las normas a veces los chilenos se preocupan de hacer su trabajo y luego de rellenar los registros e informes que pide los procesos que ellos mismos diseñan..... por eso el doble de tiempo.
Buen tema
Generalizando, creo que existen dos opiniones en el contexto de la relación Cliente y Proveedor de sistemas respecto al modelo CMMI.
La opinión ejecutiva:
En este segmento se encuentran el cliente ejecutivo informático y el ejecutivo comercial cuya fuente de conocimientos es mayormente obtenida de la academia.
Su opinión al respecto es que el modelo CMMI garantiza un resultado ajustado a los requerimientos (calidad), en los plazos prometidos (costo) y una visualización exhaustiva del control de la ejecución del proyecto (seguridad).
Con este argumento, el ejecutivo probablemente se decide por CMMI cuando los otros factores (tiempo, precio) no son significativos respecto a un desarrollo sin CMMI.
La opinión objetiva:
Es la opinión que plantea Pablo. Solo se requiere un contrato solido entre cliente y proveedor donde se establece claramente los requerimientos, y el proveedor sabrá como cumple con el resultado esperado.
Esta es mi vision sobre el sistema Cliente-Proveedor. Me gustaria plantear mi vision sobre el contexto "procesos de desarrollo", esa si que es cueca.
Ya don Vladi...aver si le hago una entreviasta de estos porcesos de desarrollo de software para que pongamos algun doc en el blog!
yo opino
es importante como una empresa en tu caso de programacion creara valor para el cliente a partir de esos procesos de desarrollo.
digamos mis tiempos de respuesta para updates o solicitudes del cliente mejoran por tener todo documentadito y bien hecho, el cliente evaluara esta caracteristica frente a la competencia (suponemos que estamos mejor que la competencia)
o por el hecho de tener procesos definidos para el desarrollo, internalizados por tus empleados y que se transforman en una rutina, como el cliente evaluara eso?
una forma logica de reflejar tus buenas practicas seria el contrato y el apoyo post venta que le das a ese cliente.
El contrato con plazos definidos (no a la chilena de tipin 3 meses tirando pa 5), calidad definida claramente antes de iniciar el desarrollo (tomese por calidad la definicion de todas las caracteristicas que espera el cliente obtener en su producto y que son las que le sugieren tomar el contrato contigo)
o sea el cliente en ningun momento pensara "o diablos, ellos son unos campeones con las buenas practicas del negocio".... sino evaluara comunicacion, cumplir plazos y promesas, etc....
y para poder tu ofrecer esas cosas debes tener un proceso standarizado a tu realidad y a la realidad del medio (que saco con poner un standar de clase mundial año 2009 si en el medio recien vamos en normas un tanto mas antiguas pero mas maduras)
eso es mi opinion.....
Hi, nosotros stamos usando SCRUM para la gestion interna y externa del proyecto, todo siempre acompañado de su clásica gantt para que el cliente no se pierda, pero ha resultado ser una metodología que mejor enormemente la comunicación y sin generar gran cantidad de documentación. el punto más critico es claramente la definición de los requerimientos, pero tbn inculcando un modelo de mejora evolutiva usando scrum hemos sacado ya un par de wenos proyectos con clientes satisfechos (aunque no se termianro en el tiempo incial, pero todos sabian por ke y antes de que pasara), genial no?
Publicar un comentario