Necesito definir los KPI que me ayudarán a decir si el software que sale del proyecto es bueno o malo. Me refiero a si cumple con los KPI de calidad que se apuntaron o no. La pregunta, por supuesto, es qué KPI se pueden definir para el proyecto de desarrollo de software. ¿Qué KPIs de calidad utiliza en sus proyectos de desarrollo de software? ¿Cómo los interpretas? ¡Gracias a todos de antemano por la ayuda!
Para la gestión de cambios en mi proyecto, usamos MS Team Foundation Server 2010. Todos los procesos se basan en términos generales en CMMI. El proyecto es similar a SAP. Tenemos módulos que son el núcleo del sistema, los niveles más bajos son comunes para partes más pequeñas de las partes interesadas o se personalizan. Estamos trabajando en un modo de soporte de las versiones actuales del sistema (corrección de errores, adición de usuarios, etc.) y también creando nuevos futuros. El proyecto es una aplicación web.
Trabajamos para cliente interno.
En realidad, estoy usando solo dos KPI:
número de usuarios/clientes : como objetivo, definimos cuántos usuarios o clientes nos gustaría tener durante un período determinado. Por ejemplo, queremos 30.000 nuevos clientes en este año.
el tiempo que necesitamos para entregar una nueva característica : en otras palabras, el tiempo de entrega . Verificamos nuestro tiempo de entrega real y verificamos si este tiempo es suficiente para permanecer en el mercado. Por ejemplo, queremos reducir nuestro plazo de entrega actual de 10 días a 9 días este año, porque la competencia se volvió más rápida que nosotros.
Como puede ver, estos KPI/objetivos se refieren a las tendencias: " más " clientes y " menos " tiempo dedicado. Además, los números establecidos no son alcanzables con nuestra forma actual de trabajar, por lo que la organización tiene que trabajar y mejorar para lograrlos.
Contamos con herramientas automatizadas para obtener los datos anteriores y verificamos regularmente nuestros indicadores para ver si estamos en el camino correcto o no. Si no, cambiamos nuestra forma de trabajar, probamos cosas nuevas, etc.
Ya no uso KPI como número de defectos, líneas de códigos o cobertura de prueba, porque
Te doy un ejemplo. En la organización de mi amigo, uno de los principales KPI es la cantidad de defectos en el sistema. Por lo que recuerdo, el objetivo es tener un máximo de 10 defectos. Mantienen este número, incluso si no es necesario. Su cliente puede vivir con 20 o 30 defectos, quiere tener un sistema con un tiempo de reacción rápido, pero los desarrolladores dedican tiempo a corregir los defectos y no a hacer que el sistema sea más rápido. Existe la posibilidad de que pierdan este cliente por esto. Si tuvieran el KPI " número de clientes ", cada equipo podría establecer su propio objetivo/acción para ver qué hacer a favor de este KPI y mantener al cliente.
Hay varios KPI, lo que llamamos un modelo de calidad, que puede usar para medir la calidad de un producto de software. Un enfoque, y un buen punto de partida, es la norma ISO 9126 que recomienda medir la calidad interna, la calidad externa y la calidad en uso de su producto y, en función de las diferentes métricas que puede recopilar, inferir los diferentes aspectos de la calidad: mantenibilidad, funcionalidad, usabilidad, portabilidad, eficiencia y confiabilidad de su software.
Existen productos comerciales y no comerciales que pueden ayudarlo a calcular los aspectos mediante el análisis de código estático y la integración con plataformas de prueba, por ejemplo.
Algunas de las métricas subyacentes incluyen el nivel de cumplimiento de las reglas de codificación predefinidas y las mejores prácticas, métricas intrínsecas como la complejidad ciclomática, métricas de tamaño como líneas de código o puntos de función, etc. no piense medir la calidad real de su producto. A lo sumo pueden ayudar a calcular algunos de los aspectos, como la usabilidad, pero la visión que dan es muy limitada. Necesita una visión más holística y para eso necesita más datos.
Quiero mencionar que vale la pena medir la calidad real de su producto a lo largo del ciclo de vida del desarrollo. Tendrás menos defectos en la producción y tus ciclos de mantenimiento serán más cortos. Esto está probado.
Para los informes de progreso, soy un gran admirador del valor ganado. Este es el método más honesto para realizar un seguimiento de la programación y el presupuesto, pero es posible que no alcance la métrica de calidad que está buscando.
Alejándome del valor ganado, para sistemas personalizados y empresariales, trato de trabajar desde el caso comercial. Si el caso de negocios es "Ahorre 15 minutos por usuario por día", entonces hago un seguimiento de cuánto de esto he demostrado completar. "Hemos eliminado 5 minutos, hemos logrado 1/3 del caso de negocios" (Esto puede sonar como Valor ganado, pero en realidad es diferente)
Entre el caso comercial y el cronograma hay otras métricas de calidad. Me gusta saber dónde se encuentran los defectos por versión, ordenados por gravedad. ¿Los usuarios finales los están encontrando? ¿Los estamos obteniendo en la prueba del sistema? ¿Prueba de unidad? ¿Están centrados en ciertas partes de la aplicación? Las métricas por sí solas no son perfectas, pero pueden ayudarlo a buscar.
Tiago Cardoso