En las ultimas semanas he leído algunos artículos y presentaciones que capturaron mi atención, los cuales coinciden en un aspecto: se animan a criticar prácticas o modelos muy aceptados.
Estos son los links:
- Are We There Yet? de Johana Rothman. Desaconseja el uso de la técnica de valor ganado en proyectos de software.
"No he trabajado en ningún proyecto donde fuese posible calcular el valor ganado (earned value). En mi experiencia, el valor ganado es demasiado frecuentemente una medida difusa para proyectos de software."
- Questioning Earned Value Management (EVM) on IT projects de Scott Ambler. Desaconseja el uso de EVM en proyectos de IT.
"En teoría, EVM suena como una gran cosa. Estas ganando valor de todos modos, y ¿quién puede discutir eso? Sin embargo, en la práctica en el mejor de los casos es un eufemismo para controlar los costos presupuestados gastados y en el peor de los casos es simplemente una justificación para buracracia." - Could the Software Engineering Institute be Wrong About Statistical Process Control? de Bob Raczynski. Presentación realizada en Systems & Software Technology Conference (SSTC) 2007.
En este caso el título es muy descriptivo. El autor se pregunta si el control estadístico de procesos (CEP) es apropiado para organizaciones de desarrollo de software. Su respuesta es no.
El CEP tiene gran importancia en el modelo CMMI y es algo que personalmente me intriga. Hace mas de dos años gestiono proyectos en una organización CMM (y luego CMMI) nivel 5, y debo ser sincero. No veo el valor de aplicar CEP en nuestros proyectos. Puede ser que aún no lo comprenda, pero si mañana debo dejar de aplicarlo, no lo voy a extrañar.
"Bueno, si usted aplica CEP a procesos de desarrollo de software, puede que ocasionalmente tenga suerte e identifique una variación con causa asignable a pesar de los amplios limites de sus gráficos de control, areas desiguales de oportunidades, y procesos constantemente cambiantes.
De las variaciones de causas asignables que logre detectar, ocasionalmente puede tener suerte y realmente peda identificar una de las causas de esa variación.
De las muy pocas causas de variación que usted pueda identificar, una de ellas podría ocasionalmente ser de una naturaleza que puede realmente ser removida con cierta persistencia.
Aún así, su sistema en general difícilmente será más predecible.
¿Es ese el mejor uso de sus recursos limitados?" - Software Data Violate SPC’s Underlying Assumptions de Bob Raczynski and Bill Curtis. (requiere subscripción de IEEE). Aquí los autores cuestionan el uso de gráficos de control para realizar control estadístico sobre procesos de software.
"Nosotros pensamos que los supuestos detrás de los gráficos de control son tan fuertemente violados en los datos de software que su valor para entender y gestionar la variación es severamente disminuida...
Desafortunadamente, el foco desproporcionado para controlar estadisticamente procesos y calidad de software ha desviado la atención de otros métodos estadísticos que podrían proveer mucho mejor entendimiento y predecibilidad de las causas de variación afectando al proceso de software." - Can a Manufacturing Quality Model Work for Software? de Shari Lawrence Pfleeger (requiere subscripción de IEEE).
"¿Debe ser el modelo de manufactura Six Sigma aplicado al software? En una palabra, no. Aunque el software de alta calidad es algo bueno, hay al menos tres razones por las cuales el modelo Six Sigma no tiene sentido para el software."
Como cierre, incluyo unas palabras de Alistair Cockburn en el grupo de Yahoo scrumdevelopment:
"En mis 30 años en el negocio, industria, investigación y algo de gobierno, nunca vi una matriz de trazabilidad redituable."
Cuando algo es generalmente aceptado, el camino más fácil es tomar por sentado sus beneficios y defender sus aspectos positivos.
En lo personal no me agrada ese camino.
Valoro cuestionar y escrudiñar cada práctica, analizar y entender cada concepto, pensar y aprender, no simplemente repetir.
