¿Se puede controlar un proceso creativo?

Muchas de las críticas que se le hacen a CMMI -y que se le hicieron en su momento a SW-CMM- han tenido que ver con la viabilidad de aplicar las técnicas del control estadístico a procesos de desarrollo de software, una disciplina conocimiento-intensiva que gira en torno al diseño y a la creatividad y no alrededor de la fabricación repetitiva de un mismo tipo de producto [Curtis-2008a].
Uno de los principales críticos, por ésta y otras razones, ha sido el movimiento Ágil. Para sus proponentes, no tiene sentido controlar un proceso que, por su naturaleza, se ubica al borde del caos (ver [Anderson, pág.9] y [Schwaber, pág.102]). Según ellos, debido a la natural complejidad del desarrollo de software, se impone la aplicación de otro tipo de control de procesos, llamado control empírico. La idea principal detrás de este punto de vista es que no hay una teoría que explique el fenómeno observado: la única opción posible es observar y adaptar los procesos en función de los resultados obtenidos. En esta visión, no hay procesos definidos (al menos, con el nivel de detalle esperable de una organización madura) ni predecibles.
Sin embargo, no todos en la comunidad ágil piensan lo mismo. David Anderson, uno de los creadores del método FDD (Feature Driven Development) y autor de Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results [Anderson], asegura que un proceso empírico puede arrojar resultados de una precisión similar a la esperada en un proceso definido.
Para Anderson, no siempre el desarrollo de software está al borde del caos: siempre es posible la planificación y la predicción de los resultados dentro de ciertos límites de incertidumbre. Un proceso convergente -ya sea éste empírico o definido- mostrará con el tiempo un comportamiento predecible. En cambio, un proceso divergente se comportará en forma caótica y será imposible de controlar.
Anderson concluye asegurando que es necesario controlar a los procesos para que las organizaciones puedan obtener resultados económicos superiores. De ninguna manera, según su punto de vista, puede confiarse únicamente en los controles reactivos tan populares en los métodos ágiles [Anderson, cap.32].
Ideológicamente más cerca de CMMI, Bill Curtis -co-autor de SW-CMM, People CMM y del reciente Business Process Maturity Model [OMG]- ha cuestionado la aplicabilidad de los grafos de control -una de las herramientas que está en el mismo corazón de la gestión cuantitativa- a los procesos de desarrollo de software [Curtis-2008b], ya que en general las fuentes de datos empleadas son de naturaleza heterogénea.
Curtis plantea que un sistema compuesto por una persona produciendo piezas de código de similares características y bajo las mismas circunstancias tendrá un comportamiento similar a un proceso con causas comunes de variación. Sin embargo, la situación sería otra si las piezas que se le asignaran a esta persona fueran de diferente dificultad. En este caso se estaría introduciendo en el proceso una fuente de variación que alteraría su desempeño, sus límites de control y su predictibilidad. La única solución viable sería desagregar los datos de manera tal de poder construir un grafo de control para cada una de las diferentes complejidades de los componentes.
La situación se tornaría más complicada en el caso de involucrar a más personas en el proceso, ya que aparecerían nuevas fuentes de variación (la productividad y la capacidad de trabajo podrían no ser las mismas en todos). Esto implicaría construir más grafos de control para mantener la homogeneidad de datos, lo cuál sería claramente impracticable.
Curtis y su coautor concluyen afirmando que son otras las herramientas estadísticas que deberían usarse en estos casos, caracterizados por múltiples fuentes de variación. El grafo de control no sería el más aplicable en dichas situaciones.
Esta conclusión es sumamente relevante, ya que las raíces de CMMI en la industria manufacturera son muy profundas. En ella, los supuestos de Walter Shewhart se cumplen y el grafo de control es la herramienta más adecuada. La situación sería completamente diferente en la industria del software.
Buscando el equilibrio
Claramente, el debate está lejos de finalizar. La comunidad informática debe encontrar el punto medio que le permita equilibrar la necesidad de predecir resultados -un imperativo del management de cualquier organización- con la de disponer de procesos ágiles y adaptables.
Varios trabajos ([Dutton], [Fritzsche], [Paulk-1], [Glazer]) puntualizan que en realidad hay más similitudes que diferencias entre los métodos ágiles y CMMI. De hecho, muchas de las prácticas propuestas por el movimiento ágil son una reinterpretación de prácticas existentes en la ingeniería de software y en otras industrias desde hace años y no necesariamente son incompatibles con CMMI.
Probablemente, los puntos más conflictivos sean los relacionados con las áreas de proceso de los niveles 4 y 5. La afirmación de que debe aplicarse un control empírico sobre los procesos contradice el precepto básico de CMMI de que los procesos deben ser controlados estadísticamente. Sin embargo, la recomendación del modelo de seleccionar cuidadosamente cuáles subprocesos controlar pareciera no entrar en conflicto con los preceptos del movimiento ágil.
De todas maneras, el debate continúa y probablemente continuará por bastante tiempo más. Lo que está claro por el momento es que de la discusión surgirá un nuevo enfoque para gestionar el desarrollo de software, basado con seguridad en las mejores ideas de las diferentes escuelas.

Referencias

[Anderson]
David J. Anderson
Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results
Prentice Hall, 2004

[Curtis-2008b]
Bill Curtis, Bob Raczynski
Software Data Violate SPC’s Underlying Assumptions
IEEE Software, Mayo/Junio 2008

[Dutton]
Jeffrey L. Dutton, Richard S. McCabe
Agile/Lean Development and CMMI®
Systems & Software Consortium
Presentación en la SEPG Conference 2006
http://www.sei.cmu.edu/cmmi/adoption/pdf/dutton.pdf

[Fritzsche]
Martin Fritzsche, Patrick Keil
Agile Methods and CMMI: Compatibility or Conflict?
e-Informatica Software Engineering Journal, Volume 1, Issue 1, 2007
http://www.e-informatyka.pl/e-Informatica/attach/Issue1/Vol1Iss1Art1eInformatica.pdf

[Glazer]
Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum
CMMI® or Agile: Why Not Embrace Both!
CMU/SEI-2009-TN-003
http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html

[OMG]
Object Management Group
Business Process Maturity Model - Version 1.0
OMG, 2008

[Paulk-1]
Mark Paulk
Extreme Programming From a CMM Perspective
IEEE Software, Vol.18, Nro.6; noviembre/diciembre 2001
[Schwaber] Ken Schwaber
The Enterprise and Scrum
Microsoft Press, 2007

Los famosos 14 puntos de Deming

Es sorprendente ver cuán vigentes se mantienen hoy las ideas de Deming. Las dejo en inglés:

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.
2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
4. End the practice of awarding business on the basis of price tag. Instead, minimise total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
6. Institute training on the job.
7. Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of an overhaul, as well as supervision of production workers.
8. Drive out fear, so that everyone may work effectively for the company.
9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
10. Eliminate slogans, exhortations, and targets for the workforce asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
11. a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
    b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
12. a. Remove barriers that rob the hourly paid worker of his right to pride in workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
    b. Remove barriers that rob people in management and engineering of their right to pride in workmanship. This means, inter alia, abolishment of the annual or merit rating and management by objective.
13. Institute a vigorous program of education and self-improvement.
14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.