Perversión de MCQ puede destruir la Calidad

Las actuales metodologías ágiles como MSF o Scrum que prescinden de la construcción de artefactos de diseño promoviendo la construcción acelerada de piezas de software, por lo general atómicas, transfieren al desarrollador la pesada responsabilidad de vigilar muchos aspectos de la calidad del código que estarían controlados clásicamente en un proceso de diseño.

sonarA fin de mitigar los riesgos derivados de esta situación, han surgido herramientas de MCQ (Manage Code Quality), como por ejemplo SQSCAST AIPSonarQube, concebidas como mecanismos de apoyo para las líneas técnicas y los equipos de desarrollo y pruebas.

Sin embargo, el poco entendimiento que en algunas líneas gerenciales han logrado las metodologías ágiles ha venido ocasionando algunas perversiones en el uso de las herramientas de MCQ.

Como por ejemplo el planteamiento de utilizar las métricas generadas como un mecanismo de evaluación profesional o de desempeño. Hecho por demás contrario al objetivo propio de la herramienta.

Es fácil darse cuenta que la sola pretensión de querer implantar el uso de las métricas generadas por una herramientas de MCQ como un mecanismo de evaluación lejos de procurar el mejoramiento de la calidad del código, impulsa y promueve la adopción de malas prácticas, como podría darse el caso por ejemplo, de la aplicación de nomenclaturas personalizadas con sufijos o prefijos que ocasionan pérdida del carácter autodocumental que debería prelar en la codificación, a fin de brincar la detección de líneas duplicadas de código, o la inclusión de comentarios vacíos o autogenerados, por decir tan solo un par de las observaciones más elementales que cualquiera que haya trabajado un poco con alguna herramienta de este estilo ha apreciado sirven para brincarse algunas de las reglas de evaluación.

Así pues, al momento de hacer uso de una herramienta de MCQ hay que prestar gran cuidado en observar que el enfoque de la misma sea el de una herramienta de colaboración entre las líneas técnicas: Arquitectura,  Líder Técnico, Equipo de Desarrollo y Tester.

7axes

Y comprometer de manera explícita con ellos que la información de la misma en ningún caso será filtrada o proyectada hacia las líneas gerenciales, mucho menos hacia el cliente.

NoExponer

Ya que, de no hacer de ello una práctica, se corre el riesgo de que el personal técnico preste su atención más a como saltar las evaluaciones (apreciadas como un foco de peligro para ellos), en lugar de dedicar sus esfuerzos en mantener el mayor cuidado de la Calidad y un apego a las buenas prácticas.

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