Documentación – recibiendo un feedback

Un feedback de un amigo Ingeniero en Software, me hace pensar en las formas que en las empresas documentan para llegar a certificaciones de alto nivel de maduración de software o CMMI.

Para comprender un poco más de CMMI(Captability Maturity Model Integration) son colecciones de buenas prácticas que ayudan a las organizaciones a mejorar sus procesos.

Fue desarrollado por la Software Enginnering Institute(SEI).

Este modelo, denominado CMMI para el desarrollo (CMMI-DEV) proporciona un conjunto completo e integrado de guías para desarrollar productos y servicios.

Las empresas gastan mucho dinero para certificar en CMMI, ISO o alguna certificación que le permita vender, no solo dentro del País sino también fuera de la misma o también para demostrar que en se cumplieron todas las normas a nivel de maduración de Software, el problema está en que toda la inversión hecha en esa documentación para llegar a la certificación se quedó en algún lugar olvidado por el mundo, porque la finalidad tal vez no era la “MEJORA EN LOS PROCESOS “, tal vez era otra.

Además, no se utiliza para la mejora continua sino, que solo está para que cuando auditoria venga a revisar y ver las documentaciones, pruebas, puntos de control, esta todo en su lugar, fantástico.

Ahora meto Calidad (cuando un software es medianamente medible en calidad, cuando cumple los requisitos de la historia de usuario, se puede decir que tiene calidad, porque cumple un criterio de aceptación).

Lo normal es que se cumpla con los requerimientos de usuario, que es lo que en verdad necesita el software, pero lo más difícil y lo dice #ITIL dentro de lo que es Servicio la expectativa del Cliente es lo más difícil de cumplir o sea casi imposible.

Dentro de mi experiencia en la parte de Análisis Funcional la documentación ingresa por las Historia de Usuario dentro de un esquema de #Agiles #Scrum, esa historia de usuario no da la a nosotros el requerimiento del usuario (en este caso el Usuario es el Dueño del Producto o Propietario de datos si quieren llamarlo así).

Después se trabaja con los casos de uso y en los diagramas de estados y actividades y si no comprendes un caso de uso verifícalo con un diagrama de colaboración (Pero eso es trabajo de Análisis)….ATENCION SEGUIMOS DOCUMENTANDO….

Si documentamos dentro de Iteraciones como nos da a entender #Scrum es posible un mantenimiento porque después de que se pueda terminar un Sprint dentro de la Retrospectiva se puede evaluar algunos puntos sobre documentación.

Ahora, es mejor tener todas la mejores prácticas a mano y poder concluir uno mismo un ciclo de vida de desarrollo de software, no todos tiene ISO o CMMI , la mayoría maneja sus propios procesos o documentaciones, porque así le va bien y además su producto con esa documentación que puede ser pobre o no le da resultados fantásticos.

“No tengas miedo de inventar tu propio ciclo de vida del software que se adecue a tu realidad. El ciclo de vida _perfecto_, es un modelo, tu vive en el mundo real.” (Gracias @johannarothman)” – gracias Ale.

Anuncios

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s