Brian Tarbox está convencido de que el enfoque de la calidad adoptado por la mayoría de empresas, es erróneo y se basa en un modelo defectuoso. Este uso del modelo equivocado explica por qué tantas empresas están teniendo tales problemas para aumentar la calidad del software que ofrecen.
Para explorar los distintos modelos disponibles echemos un vistazo a algunos otros negocios y ver cómo se enfrentan a problemas de calidad.
Una ciudad tiene un problema con el mal comportamiento del tráfico, que puede ser visto como una cuestión de calidad, con consecuencias potencialmente peligrosas para la vida. Los métodos disponibles para resolver los problemas de tráfico son básicamente estructurales y la ejecución. Soluciones estructurales son cosas tales como la adición de reductores de velocidad o de carriles de giro. La aplicación es la adición de más patrullas de policía o radares. Las soluciones estructurales son atractivos porque trabajan.
En el mundo del software de soluciones estructurales a la calidad son cosas como la cobertura de código o estilo del código que corre automáticamente como parte de un proceso de construcción. Simplemente no se puede hacer check-in o crear un código que viola la norma estructural. La desventaja de las soluciones estructurales es que no cambian las actitudes subyacentes.
Modelos de software de aplicación son cosas como las inspecciones de código después de los hechos o fracasos. Ambos se centran en determinar por qué se produjo un error en lugar de la prevención de que vuelva a ocurrir.
- Estructuralmente no se puede evitar que una bailarina dance mal.
Entonces que deja la ejecución,
- Para mejorar el performance de un niño en una liga de fútbol ¿se debería contratar más árbitros?
- Cuando un niño toca piano. ¿debería haber alguien que haga ruido con un silbato cada vez que el niño se equivoca?
Pues definitivamente no, es necesario un maestro o instructor.
Esta es una conclusión ridículamente obvia en estos lugares, pero la mayoría de las compañías de software han perdido de vista.
Esperamos que nuestros programadores escriban mejor código, pero por lo general no le damos ningún entrenamiento en cómo hacerlo.
La mayoría de los ingenieros no piden la formación y la mayoría de los gerentes no lo sugieren. Pregúntese: ¿Su compañía se incluyen la educación continua en su valoración de su rendimiento? ¿Su empresa ofrece clases de refactorización, Test Driven Development, Metodología Ágil o Inspección Código? Si no lo hacen, entonces están haciendo una declaración que no valoran la calidad del software.
Fuente: PragPub 20010-09
Comentarios