Aprendiendo de Toyota

Observar los errores y aciertos de otras industrias es una técnica muy utilizada para mejorar el estado actual del desarrollo de software como disciplina, y pienso que aprovechar años de madurez de industrias como la automotriz puede ser beneficioso siempre que se haga observando con atención hasta donde cada práctica, técnica o principio es adecuado para el nuevo ámbito donde se lo desea aplicar.

Bien, ahora el punto es, ¿a quién observamos para aprender? Muchas empresas en el pasado han aprendido del fenómeno japonés y de Toyota en particular. ¿Observar a Toyota puede aportar algo al desarrollo de software? Podemos pensar que si.

Taiichi Ohno fue contratado por Toyota para instalar un sistema de producción para producir automóviles de alta calidad. Durante 3 décadas, Ohno desarrollo el Toyota Production System, conocido ahora como Lean Manufacturing.

Los valores básicos de Lean Manufacturing son:

* Agregar sólo valor
* Centrarse en las personas que agregan valor
* Generar valor por demanda
* Optimizar a traves de organizaciones

Hay varias factores llamativos en Lean Manufacturing: su aplicación representó un mejoramiento notable de la calidad y productividad, requería un cambio de paradigma porque contradecía buenas prácticas aceptadas hasta su aparición y sus principios han sido exitosamente aplicados en negocios de todo tipo.

Seguramente, estos factores han sido elementos importantes que llevaron a Mary Poppendieck ha escribir un conjunto de artículos y un libro trasladando las enseñanzas de Lean Manufacturing al desarrollo de software. Es un material que merece ser leido.

Algunos extractos de sus artículos para tener una primera aproximación al tema:

“El 'Lean Thinking' observa la cadena de valor y se pregunta: ¿cómo se pueden estructurar las cosas para que la empresa no haga nada además de agregar valor, y que lo haga lo más rápido posible? Todos los pasos intermedios, todos los tiempos intermedios y todas las personas intermedias son eliminadas. Sólo se deja el tiempo, las personas y las actividades que agregan valor para el cliente”

“La medida de madurez de una organización es la velocidad con la cual puede responder repetida y confiablemente a solicitudes de sus clientes.
Si, escucho bien. La madurez no es medida por la amplitud de la documentación de un proceso o la habilidad de hacer planes detallados y ejecutarlos. Es medida por la excelencia operacional, y el principal indicador de la excelencia operacional es la velocidad con la cual la organización puede repetida y confiablemente servir a sus clientes.”

“Por lo tanto, si el cliente quiere algo, ¿qué pasos debe cumplir la solicitud para que el resultado sea entregado al cliente? ¿ Qué tan rápido fluye ese proceso? Si la solicitud de un cliente espera en una cola para aprobación, una cola para diseño, una cola para desarrollo, una cola para testing, y una cola para despliegue, el trabajo no fluye muy rápido. La idea es crear celdas(o equipos) de personas encargadas de tomar cada solicitud desde la cuna hasta la tumba, rapidamente y sin interrumpciones. Entonces el valor fluye.”

“Los documentos, diagramas y modelos producidos como parte de un proyecto de desarrollo de software son productos perecederos, ayudas utilizadas para producir el sistema, pero no necesariamente parte de un producto final. Una vez que un sistema completo es entregado, al usuario le puede importar muy poco estos productos intermedios. Los principios del Lean Thinking sugieren que cada producto intermedio es candidato a escrutinio. La carga sobre cada producto intermedio no es sólo probar que agrega valor para el producto final, sino tambien que es la manera más eficiente de alcanzar este valor.”

“Cuando se observan detalladamente, la mayoría de las teorías sobre como administrar proyectos de software son basadas en la teoría de descomposición: separe el todo en partes individuales y optimice cada una. El Lean Thinking sugiere que optimizar parte individuales casi siempre lleva a sub-optimizar el sistema completo.
Por ejemplo, optimizar el uso de recursos de testing decrementa la aptitud de todo el sistema de producir rapidamente código testeado y funcionando. Medir la habilidad individual de producir código sin defectos ignora la hecho bien conocido que el 80 % de los defectos son causados por la manera en que el sistema funciona, y por lo tanto problemas de management.”

Los artículos: Lean Software Development, Principles of Lean Thinking, Lean Programming , Mary Poppendieck
El libro: Lean Software Development: An Agile Toolkit for Software Development Managers, Mary Poppendieck y Tom Poppendieck.

Craig Larman en Argentina

En la entrada del hotel se podía leer un cartel que decía: "Craig Larman, UML y Patrones".
Esa frase es prometedora. Escuchar hablar sobre patrones y UML a un consultor reconocido mundialmente y autor de uno de los libros más vendidos sobre diseño de software, es una oportunidad muy valorable. pero es indudable que las personas que asistimos al evento no obtuvimos lo que esperabamos, pero más importante, no esperabamos lo que obtuvimos. El nombre completo del seminario era "Modelado Agil con UML y Patrones". Agil. Esa palabra puede marcar una gran diferencia.

Algunos temas que pude rescatar de mis notas:

Coraje

En la presentación de los valores de Agile Modeling comenzó a evidenciarse cual sería el tono que se mantendría en toda la charla. "Uno de los valores de AM es coraje. Coraje para decir no sé, coraje para aceptarlo". Aquí comenzo su cuestionamiento al enfoque predictivo (¿o adivinatorio?) aplicado comunmente donde se responden a las preguntas "¿Cuánto costará?" y "¿Cuánto tiempo tomará?" antes de iniciar un proyecto, momento en el cual las únicas respuestas sinceras y racionales serían: "No sé."

El desarrollo de software es desarrollo de un nuevo producto

Este fue un concepto enfatizado constantemente. Se trata de entender el desarrollo de software como el desarrollo de un nuevo producto donde son necesarias grandes cuotas de creatividad, investigación, descubrimiento y retroalimentación, y donde no son aplicables procesos repetibles de manufactura.

Siguiendo esta línea de pensamiento, Larman dijo que lo peor que uno puede hacer al iniciar un proyecto es armar un plan detallado lleno de tareas, definiendo su duración, sus responsables, sus precedencias, etc, especificando cual será la realidad del proyecto de aquí a seis meses y luego seguirlo. "Es lo peor que un administrador de proyecto puede hacer. Si lo hace, no está administrando un proyecto".

Presentó la alternativa de un plan compuesto por varias iteraciones sin mucho detalle, donde existe una planificación sobre las fechas y los objetivos mayores a cumplir, y donde se conoce el detalle de lo que se hará sólo para las siguientes 2 iteraciones a lo sumo, hablando de iteraciones de 2 o 3 semanas. El plan va evolucionando a medida que pasa el tiempo y se va adaptando a las necesidades que se manifiesten, haciendo uso de lo aprendido en las iteraciones ya terminadas.

Tambien mencionó la madurez de otras industrias, como la farmacéutica y la petrolera, para entender las características de su negocio y aceptar que no se pueden hacer estimaciones y planes útiles, es decir con márgenes de error aceptables, sin una etapa de investigación.

CMM

En la ronda de preguntas surgió una inquietud previsible: ¿Cómo se relacionan estas prácticas agiles con frameworks de madurez como CMM?
Larman contestó: "No sé cual es la realidad que se vive en la Argentina, pero por mi experiencia puedo decir que la sensación que tengo es que CMM está muerto...
Subirse a la ola de CMM es subirse a la ola de los años '90, es subirse a una ola que está comenzando a decaer...
Hoy el interés de las empresas, en vez de pasar por certificar un nivel de CMM, reside en responder a cambios de manera rápida. Por eso se están interesando en las metodologías agiles."

Waterfall thinking

Mencionó que uno de los errores que ha observado con mayor frecuencia es la superposición de los principios de un ciclo de vida en cascada sobre cualquier proceso o metodología que se utilice. "Una y otra vez visito empresas donde escucho: 'Estamos comenzando a usar RUP en un nuevo proyecto. Cuando terminemos de definir todos los casos de uso, podremos definir la arquitectura, y luego comenzar a desarrollar.'"

No esperabamos lo que obtuvimos, pero en lo personal el balance resulto muy positivo. Creo que el valor mayor del seminario estuvo en poner en contacto con ideas nuevas e importantes en el mundo de desarrollo de software a una comunidad que por lo general participa de este tipo de movimientos con años de retraso.

El desarrollo agil es una alternativa demasiado importante para desconocerla.

YAGNI

Hace unos años, cuando cursaba cuarto año de la facultad, participe en un proyecto de desarrollo con unos compañeros.
En aquella época gran parte de mi atención estaba centrada en el diseño orientado a objetos. Probablemente Bertrand Meyer fue el responsable mayoritario de esto. Para ser sincero, en aquel tiempo pensaba que la orientación a objetos podía resolver gran parte de los problemas que aquejaban al desarrollo de software. Me parecía fantástico conceptualmente y me provocaba sorpresa que no toda la gente lo viera como yo.

En aquel entonces programaba en Borland Delphi y era muy entretenido ver en acción la herencia, el polimorfismo y usar la RTTI (run-time type library, similar al concepto de Reflection en Java). Dado este interés, en este proyecto decidimos hacer uso de objetos para modelar las entidades del negocio (clientes, proveedores, facturas).

Pero nos encontramos con el problema de la impedancia entre el modelo relacional y el orientado a objetos; básicamente el problema de traducir los objetos, sus atributos y sus relaciones en tablas y campos. En búsqueda de una manera optima de resolver este problema, leímos todo artículo relacionado con el tema que pudimos encontrar en Internet. Llegamos a la conclusión que debíamos construir una capa de persistencia, un conjunto de clases mediante el cual uno podría manipular objetos, guardarlos y consultarlos sin necesidad de conocer nada acerca de la base de datos. Algo similar a lo presentado por Scott Ambler en The Design of a Robust Persistence Layer For Relational Databases. Recuerdo que desarrollar una capa de persistencia era un problema que me resultaba muy motivante para resolver. Hay muchas dificultades para sortear, muchas decisiones para tomar, muchas características para agregar.

* ¿Cómo manejamos las colecciones dentro de un objeto?
* ¿Qué pasa cuando traemos a memoria 100 objetos desde la base de datos?
* ¿También traemos los objetos relacionados?
* ¿O sólo los construimos por demanda?
* ¿Cómo controlamos la concurrencia?
* ¿Cómo hacemos con los generadores de reportes y otros componentes que generalmente requieren un conjunto de datos con filas y columnas?
* ¿Cómo diseñamos la capa de persistencia para que sea independiente de RDBMS?
* ¿Permitimos uso de transacciones anidadas?

Si, definitivamente era divertido.

Pero estábamos en la universidad. Y las disquisiciones de valor académico que son válidas en ese entorno no lo son cuando salimos de él. El tiempo invertido en aquel proyecto de desarrollo para construir ese framework celestial para guardar objetos representaría un uso ineficiente de recursos para un proyecto real. No contábamos con elementos significativos de retroalimentación (¿qué le importa a un cliente si mapeo una jerarquía de herencia con una tabla o dos tablas?) e invertimos trabajo en funcionalidad que nunca se utilizó.

He observado que en un proyecto de desarrollo se presentan muchas oportunidades para invertir recursos en funcionalidad que no se necesita, aunque estas aparecen de manera sutil, como funcionalidad completamente razonable.

Por ejemplo, pensemos en una aplicación donde se emite un formulario impreso que puede tener dos formatos distintos según la categoría del cliente al que se le envía, "mayorista" o "minorista". Es algo simple de hacer, seria algo así:

if (Cliente = "mayorista") ImprimirFormulario(Formato1)
else ImprimirFormulario(Formato2)

No, mejor guardamos en una tabla con parámetros las categorías de cliente y los diseños de formulario que le corresponden. Al momento de imprimir consultamos la tabla de parámetros y aplicamos el diseño adecuado. Es más, podríamos guardar un template que represente el diseño del formulario en algún formato. Ya sé, ¡en XML! Y podríamos hacer un diseñador de templates donde el usuario podría hacer sus propios formularios y asignarlos a nuevas categorías de clientes si estas surgen en el futuro...

¡¡¡ Y A G N I !!!

Eso gritaría un practicante de Extreme Programming. YAGNI es un acrónimo que significa "You Aren't Gonna Need It" (No lo necesitarás). YAGNI representa la idea: siempre implemente algo cuando realmente lo necesite, nunca cuando supone que lo necesitará.

Ron Jeffries, reconocido desarrollador y pionero en el campo de las metodologías ágiles, lo explica claramente con un ejemplo:

Usted está trabajando en alguna clase. Sólo agrega la funcionalidad que necesita. Supone que va a necesitar algo de funcionalidad adicional. Si no la necesita ahora, no la agregue ahora.

Por qué no?

"OK, Sam, ¿por qué quieres agregarla ahora?"

"Bueno, Ron, nos ahorrará tiempo más adelante."

A menos que tu universo sea muy distinto al mío, no puedes ahorrar tiempo. Sólo puedes hacer menos. Entonces me estas diciendo:

"Vamos a poder hacer menos más adelante (a costo de hacer más ahora)."

A menos que tu proyecto sea muy distinto al mío, ya tienes mucho por hacer ahora. Hacer *más* ahora es algo muy malo cuando ya se tiene mucho por hacer. A menos que tu mente sea muy distinta a la mía, tienes una probabilidad distinta de cero de no necesitar esa funcionalidad después de todo, o de tener que retocarla aún antes de necesitarla cuando modifiques la clase por alguna razón.
Si algo de esto pasa, has desperdiciado tu tiempo completamente, además de asignarte más cosas para hacer ahora, cuando difícilmente necesitas más para hacer.

"Pero Ron, si lo hago ahora sabré como hacerlo, y más adelante tal vez no lo sepa."

"Entonces, Sam, me estás diciendo que la clase que estás escribiendo es tan compleja que ni tú serás capaz de mantenerla?"

Mantenla simple. Si necesitas la nueva funcionalidad, la puedes agregar más adelante. Si no la necesitas, no tendrás que hacer nada de ese trabajo. Tomate el día libre.

Por supuesto, no basta con decir YAGNI para que un elegante diseño evolutivo emerja espontáneamente. Hay dos técnicas fundamentales que hacen posible este diseño evolutivo: refactoring y TDD, temas lo suficientemente interesantes como para dedicarle un espacio en el futuro.

Cada vez que escribo, termino con más preguntas que respuestas. Esta vez no será la excepción.
¿Por qué nos cuesta tanto hacer sólo lo que realmente necesitamos?

Fábricas de software

Imaginemos, por un momento, como sería la empresa de desarrollo de software ideal. Como sería el trabajo en un proyecto en esa empresa. Visualicemos el día a día, los roles, la manera de trabajar...

He notado que muchas personas tienen una visión coincidente sobre la empresa de desarrollo ideal. Piensan que idealmente una empresa de desarrollo debería ser como una fábrica.

Una fabrica de software donde exista un proceso definido y repetible. Las actividades son planificadas y se desarrollan de manera predecible. Un plan inicial es trazado y día a día, los desarrolladores ingresan datos en un sistema que reflejan el avance al minuto. El tiempo es aprovechado al máximo porque se conoce con certeza la precedencia de las actividades, la disposición de recursos, las fechas de entrega. El conocimiento necesario para realizar las actividades esta formalizado explícitamente en documentos y cualquier nuevo componente incorporado al proceso productivo puede contar con esa información para hacer su trabajo. Existen los elementos que permiten medir la productividad de cada uno de los componentes de la fábrica y hacer ajustes donde sea necesario. Se tiene control sobre la calidad de los resultados y la productividad. Control, predecibilidad, certidumbre, calidad.

Una verdadera fábrica industrial de software.

Pero...

Hay otras personas que no creen que la fábrica de software sea posible. Y van más allá, opinan que muchos de los problemas que afronta nuestra actividad surgen del enfoque que pretende estructurar empresas de desarrollo de software como fábricas. Mike Beedle es una de esas personas y dice al respecto:

"Durante 30 años el mundo del software ha sido influenciado por las ideas de la manufactura. Todo esto comenzó cuando gerentes de manufactura tomaron empleos en compañías de desarrollo de software y se le solicito a pensadores de manufactura que pensaran sobre software. Desafortunadamente ellos llegaron con un montón de equipaje de manufactura y tratamos de aplicar las mismas técnicas usadas en manufactura en ese tiempo:

* Procesos estandarizados definidos y repetibles
* Técnicas de TQM[Total Quality Management]
* Gestión voluminosa, donde las entradas y salidas son sólo observadas como hitos de fases.

Desgraciadamente, este paradigma de fabricación no se acomoda demasiado bien al desarrollo de software. En cambio, el software requiere un enfoque mucho más parecido a un proceso de desarrollo de un PRODUCTO NUEVO , porque el software siempre es una combinación de 1) crear nuevos componentes o 2) ensamblar viejos componentes de formas nuevas.
Crear nuevos productos requiere investigación, creatividad y enfoques de prueba/error. Y esto se adapta muy bien al software porque:

detectar requerimientos,
diseñar una solución,
implementarla, y
testearla

requiere investigación, creatividad e implementaciones de prueba/error.
Por otro lado, la mayoría de las veces, estas actividades no llegan en secuencias lineales repetibles -- ellas son simplemente el resultado de inspecciones y pruebas constantes, donde cualquier actividad puede disparar cualquier otra.
Tal así, el software requieren de un nuevo conjunto de practicas y actitud, que permita que el software sea desarrollado en una manera mucho más dinámica, adaptable y auto-organizada."

También se cuestiona la idea de la fabrica de software porque no considera características de las personas, factores principales en el proceso de desarrollo. Alistair Cockburn, en su artículo Characterizing People As Non-Linear, First Order Components In Software Development expresa:

"Quizás más interesante y menos obvio ... es la manera no lineal en que las personas trabajan. Ellos no siguen un secuencia predecible para ir del problema a la solución. Esto es sabido para matemáticos y programadores, quienes se ganan la vida resolviendo problemas. Esto ha mantenido siendo un secreto para gerentes y especialistas en metodologías quienes aún tratan de hacer un proceso de desarrollo de software que sea lineal."

Mas allá de esto, la discusión sobre si se pueden aplicar principios de fabricación industrial al desarrollo de software no es la cuestión central. Pienso que la cuestión central es que queremos mejores resultados, queremos ser más productivos, queremos productos de más calidad.

Un camino de alcanzar esto ha sido observar otras actividades y detectar si hay algo que podamos aplicar en la nuestra. Otro camino posible es observar los proyectos exitosos de nuestra actividad y ver que características tienen para repetirlas en nuevos proyectos. Esto es lo que ha hecho James Coplien.

Analizando un proyecto exitoso

James Coplien escribió el famoso paper Borland Software Craftsmanship: A New Look at Process, Quality and Productivity donde documenta las conclusiones de su estudio del admirable proyecto de desarrollo de Borland Quattro Pro® for Windows (QPW).

"El desarrollo de Borland Quattro Pro for Windows (QPW) es una de las más notables organizaciones, procesos y culturas de desarrollo que hemos encontrado en el proyecto de investigación de procesos Pasteur de AT&T Bell Laboratories. El proyecto asimiló requerimientos, completó el diseño y la implementación de 1 millón de líneas de código, y completó el testing en 31 meses. La programación fue hecha por no más de ocho personas a la vez, lo que significa que la productividad individual fue mayor que 1.000 líneas de código por persona por semana."
"El producto QPW ingresó al mercado con gran aclamación. PC Sources dijo, 'Quattro Pro hace el mejor uso de la interfaz de usuario de Windows que ningún otra planilla de cálculo actual." PC User dijo que 'Quattro Pro for Windows es la mejor planilla de cálculo del mundo' Computer Shopper dijo sarcástico 'Quattro Pro for Windows supera al campeón actual de planillas de cálculo Microsoft Excel 4.0' "

Productividad y calidad impresionantes. Veamos algunos puntos que caracterizaron este proyecto:

* Alta comunicación entre los integrantes del equipo.

"El proceso de QPW tiene una comunicación superior que el 89% de los procesos que hemos observado... Es una organización pequeña e intensamente interactiva"
"El equipo de arquitectura se juntaba diariamente para elaborar las interfaces de las clases en C++, para discutir algoritmos y enfoques globales y para desarrollar los mecanismos fundamentales sobre los cuales el sistema sería construido"

* Equipo pequeño y estable con profesionales expertos en su campo.

"El equipo de desarrollo de QPW tiene una membresía cronológicamente madura para los estándares de la industria... Las personas son incluidas en el equipo por su reconocida experticia en dominios de importancia central para el proyecto: motores de planillas de cálculo, gráficos, bases de datos, y así sucesivamente... Cada uno trae un talento especial para el logro."
"QPW tuvo un equipo principal pequeño --cuatro personas-- quienes interactuaron intensamente durante 2 años para producir la parte principal del producto."

* Desarrollo iterativo.

"El desarrollo de QPW fue altamente iterativo"

* Sin proceso formalmente definido.

"Borland no está sujeto a estándares de proceso ISO 9000, no tiene noción de su valuación SEI CMM, y no es entendido en la jerga de procesos de desarrollo de software siendo usada cada vez más en grandes organizaciones de software...
Aún cuando la organización no tiene un sistema codificado de proceso, es agudamente conciente de lo que hace, como lo hace, y que funciona. Ven el desarrollo de software como algo fundamentalmente conducido por casos especiales (al menos para desarrollo inicial genérico) y la repetibilidad no es una parte importante de su sistema de valores. No obstante los miembros de la organización fueron capaces de articular con gran detalle aspectos de su proceso que demostraron para mi satisfacción que ellos compartían un único modelo, tal vez basado en reglas de desarrollo, de como el desarrollo debe ser realizado."

Un conjunto de personas conformaron un equipo de desarrollo asombroso basados en alta comunicación, retroalimentación constante, idoneidad de sus integrantes y valores compartidos. No eran una fábrica de software.

Conclusión

Pienso en este proyecto y me tomo la libertad de sacar algunas conclusiones rápidas casi imprudentes:
Tal vez no nos hace falta un proceso formalmente definido.
Tal vez no nos hace falta un proceso repetible.
Tal vez no nos hacen falta actividades predecibles.
Tal vez no nos hace falta control absoluto.
Tal vez no hace falta parecernos a una fábrica.
Tal vez simplemente deseamos empresas donde proyectos como el QPW sean posibles, y contar con las personas que lo hagan posible.

¿Es CMM la solución a nuestros problemas?

CMM es un estándar, no tan aplicado como conocido, que juega un rol fundamental en los esfuerzos actuales para la mejora de procesos aplicada al desarrollo de software. Conocer algo de su historia es útil para empezar a hablar sobre el modelo en sí.
En 1982 el Departamento de Defensa de EE.UU. formó un grupo para analizar los problemas relacionados con el software y su desarrollo. Esto derivó en el establecimiento, en 1984, del Software Engineering Institute(SEI) en la Universidad de Carnegie Mellon. A inicios de 1986, el SEI y la Mitre Corporation, liderada por Watts Humphrey, comenzaron a desarrollar un esquema de madurez de procesos, CMM. "Un modelo para juzgar la madurez de los procesos de software de una organización y para identificar las prácticas claves que son requeridas para incrementar la madurez de esos procesos.", según el sitio web del SEI.
En resumen, consiste de un grupo de prácticas claves, que son divididas en 5 niveles representando las etapas que las organizaciones deben cumplir para ser "maduras". Los niveles son:

1. Inicial (caótico, ad hoc, heroico)
2. Repetible (gestión de proyectos, disciplina de procesos)
3. Definido (institucionalizado)
4. Gestionado (cuantificado)
5. Optimizado (mejora de proceso)

La idea que CMM es "el" camino a seguir para salir del code and fix está bastante difundida y aceptada. Aunque muchos no tienen en sus planes obtener una certificación CMM o aplicar las prácticas recomendadas por este modelo, siempre existe una sensación de culpa por no hacerlo. Sobretodo cuando uno ve tan bien retratada la actualidad de su organización en la descripción del nivel 1 del modelo.
Creo que esta buena recepción de CMM tiene que ver con la relación que se establece entre su aplicación y la obtención de predecibilidad, control y eficiencia en el proceso de desarrollo. Esta asociación a veces es tan fuerte que se entienden como incuestionables las bondades del modelo y como innecesario el análisis sobre la conveniencia de seguirlo.
De todas formas, existen personas que no comparten esta visión de CMM y su impacto en el proceso de desarrollo.


Opiniones sobre CMM

James Bach

. . . CMM es una mitología particular de evolución de procesos de software que no puede alegar legítimamente ser una representación natural o esencial de los procesos de desarrollo de software.

"CMM fue entendido originalmente como una herramienta para evaluar la aptitud de los proveedores del gobierno [de EE.UU] para llevar adelante un proyecto de software contratado. Tal vez sea adecuado para este propósito; no lo sé. Mi preocupación es que también es pregonado como un modelo general para la mejora de procesos de desarrollo de software. En esa aplicación, CMM tiene serias falencias. Entre las empresas de desarrollo de software empaquetado, se encuentran Borland, Claris, Apple, Symantec, Microsoft, y Lotus, entre otras. Muchas empresas de este tipo raramente, por no decir nunca, administran sus documentos de requerimientos tan formalmente como describe CMM. Este es un requerimiento para alcanzar el nivel 2, por lo que todas estas empresas probablemente entrarían en el nivel 1 del modelo."

"CMM venera los procesos, pero ignora las personas... Humphrey y CMM mencionan las personas brevemente, pero también las condenan como no fiables y asumen que los procesos definidos pueden de alguna manera convertir la excelencia individual en algo menos importante. La idea que los procesos pueden compensar la mediocridad es un pilar de CMM, en donde las personas son aparentemente subordinadas a procesos definidos . . .
Para convertir la excelencia en algo menos importante las tareas para resolver problemas deberían de alguna manera estar contenidas en el proceso en sí. Nunca he visto un proceso de estas características, pero si existiera uno, sería extremadamente complejo."

The Immaturity of CMM, James Bach

James Bach es fundador y consultor principal de Satisfice, Inc. Ha sido desarrollador, tester y SQA manager en Apple, Borland y otras empresas. Ha sido investigador principal en STLabs, un laboratorio independiente de pruebas de software. Tambien fue parte del equipo que definió el cuerpo de conocimiento cubierto por el programa de certificación de Ingeniero en Calidad de Software para la Sociedad Americada para la Calidad.


Tom DeMarco

Una de las justificaciones más fuertes de CMM es que permite aumentar la calidad y productividad mientras disminuye el riesgo...sugiere que el mismo trabajo puede ser emprendido con menos riesgo en los niveles más altos. Pero existe otra interpretación que nos parece más probable: las organizaciones se convierten cada vez más adversas al riesgo mientras 'maduran'.
Una organización presionada para demostrar un incremento en su nivel CMM no buscará desafíos reales.

Mientras usted se convence más de la significación de la evaluación [positiva], más se siente inclinado a afrontar trabajo más complicado. Sube la apuesta. Puede poner a trabajar su gente en software que otras empresas de más bajo nivel no podrían construir. Si tiene la organización de desarrollo de software más refinada conocida hasta el momento por el genero humano, no tiene el más mínimo sentido darle a su gente el mismo trabajo que cualquier empresa mediocre puede hacer. Mucho mejor es torturar a la competencia tomando sólo grandes desafíos...
Subir la apuesta significa que el riesgo aumentará. Mientras usted es más competente, más riesgos toma. Estaría loco si no lo hiciera...

Si usted ya tiene una organización de nivel 2 o mayor de CMM recuerde esto: Los proyectos que más valen la pena son aquellos que lo hacen BAJAR un nivel completo en su escala de proceso. Tal vez esos sean los únicos que usted se puede permitir hacer.

Peopleware: Productive Projects And Teams, Tom DeMarco y Timothy Lister

Tom DeMarco es uno de los directores de Atlantic Systems Guild, un grupo de especialistas sobre sistemas con oficinas en EE.UU. y Gran Bretaña. En 1986, ganó el premio Warnier por la contribución durante su carrera al campo de la computación.
La carrera de DeMarco comenzó en Bell Telephone Laboratories donde formó parte del ahora legendario proyecto ESS-1. Años despues gestionó proyectos real-time para La CEGOS Informatique en Francia, y fue responsable de sistemas bancarios en línea distribuidos en Suecia, Holanda, Francia y Finlandia.
Ha dictado conferencias y consultorias en America, Europa, Africa, Australia y Medio Oriente, y ha escrito varios libros reconocidos, entre ellos Why does software cost so much? y Peopleware.

James Highsmith

"En el mundo del desarrollo de software, parece que el Capability Maturity Model del Software Engineering Institute es el Santo Grial. Aún los incredulos se preguntan si no hay algo mágico que se están perdiendo ... ¿Qué les da animo a los defensores de CMM para aplicar el modelo a todo el desarrollo de software?
Si yo estuviese caminando hacia un cohete a punto de ser lanzado al espacio, el hecho de que el equipo de software Orbiter Avionics de Lockheed Martin fue calificado con el nivel 5 de CMM calmaría algo de mi ansiedad. Un defecto trivial en 420.000 líneas de código es un alcance Monumental.
Sin embargo, si yo fuese un gerente en Netscape o Microsoft, y el equipo Orbiter Avionics anunciara que comienza a participar en la competencia de los navegadores web, el anuncio me causaría gracia. Un grupo en el nivel 5 de CMM no sobreviviría mucho tiempo en el agitado y cambiante mundo de la velocidad de Internet. En este mundo, la optimización es necesaria, pero insuficiente para el éxito."

"Hay practicantes de iniciativas de mejora de procesos cuya filosofia fundamental parece ser, 'si mejoramos el proceso, obtendremos mejores resultados automáticamente'. Por ejemplo, CMM mide los procesos establecidos, no los resultados. La 'madurez' de una organización es evaluada verificando una lista de procesos requeridos para cada nivel... Desde la perspectiva de CMM, el nivel 5 es mejor que el nivel 4 - más procesos significan más madurez. No obstante, no parece existir una evaluación sobre si un nivel especifico es apropiado para el desarrollo de un tipo particular de producto o si las empresas en el nivel 5 producen mejores resultados (según los clientes) que las empresas en el nivel 3 o 4."

Adaptive Software Development: A Collaborative Approach To Managing Complex Systems , James Highsmith

James Highsmith comenzó su carrera trabajando en el desarrollo del software para el programa espacial Apollo y desde entonces se ha desenvuelto como programador, project manager, consultor, y escritor.
Como director de Information Architects, Inc., Highsmith enseña y brinda consultoria sobre mejora de procesos para la calidad del software, gestión de proyectos y técnicas de desarrollo acelerado.
Es un destacado conferencista conocido a nivel internacional y en los últimos diez años ha trabajado en organizaciones de IT y de desarrollo de software en EE.UU, Europa, Australia y Nueva Zelanda.

CMM no es la "bala de plata"

Más allá de compartir o no las opiniones de estos autores, creo que el valor de conocerlas reside en desterrar la visión de CMM como "bala de plata" y comenzar a aceptar la necesidad de un analisis más profundo del modelo y la filosofía subyacente para decidir si representa el camino optimo para mejorar nuestra manera de trabajar.
Como personas relacionadas al desarrollo de software y conocedores de las dificultades existentes en esta actividad, siempre albergamos consciente o inconscientemente la ilusión que en algun lugar existe una definición detallada de la solución a nuestros problemas, una receta mágica infalible que otros conocen y que es aplicable a nuestro contexto.
De todos modos, las mejores decisiones para mejorar los resultados de nuestro trabajo no pueden basarse sólo en esa ilusión.

Peopleware, productividad en serio

Un día, un gerente está disconforme con el avance de un proyecto. Vocifera un rato, "¡Esto no puede ser! ¡Tenemos que ser más productivos! ¡Son todos unos vagos! Hay que hacer algo para mejorar..."

Generalmente, lo que se hace en estas situaciones es tomar un par de medidas absurdas como cortar el acceso a Internet, establecer una jornada de trabajo de 12 horas u obligar a los desarrolladores a tomar clases de mecanografía para que escriban más rápido. Otras opciones requieren más trabajo. Por ejemplo, hablar y actuar sobre productividad con conocimiento de causa. Si esa es la opción que uno desea tomar, un buen comienzo es comenzar a leer sobre el tema.

Tom DeMarco y Timothy Lister han estudiado durante años los factores que afectan la productividad en nuestra industria y han escrito un libro con los resultados de su investigación y sus conclusiones: Peopleware: Productive Projects and Teams.
Los temas tratados son variados pero todos muy presentes en nuestra realidad. Por ejemplo, las horas extra.

Nuestra actividad parece estar marcada a fuego por el trabajo en horas extra. Nos cuesta pensar en un proyecto sin ellas. Muy a menudo estas vienen acompañadas de la falta de una justificación convincente y de un gerente de pocas luces que piensa que este coctel infalible para derrumbar la moral de cualquier equipo de desarrollo puede de alguna manera aumentar la productividad. DeMarco y Lister escriben al respecto:

"Las horas extra son una fantasía de la imaginación del gerente ingenuo. Oh, puede existir cierto beneficio en horas extra trabajadas el sábado para cumplir con la entrega del lunes, pero esto es casi siempre seguido por un periodo igual de horas menos compensatorias mientras los empleados se ponen al día con sus vidas... Realmente nadie puede trabajar mucho más de cuarenta horas [semanales], al menos no de manera continua y con el nivel de intensidad requerida para el trabajo creativo"

Una característica remarcable del libro son la cantidad de datos empíricos que forman la base de las conclusiones expuestas. Muchos de estos datos surgen de los Coding War Games, una serie de competencias para completar tareas de programación y testing en un tiempo mínimo y con defectos mínimos que DeMarco y Lister organizaron durante años. Estos juegos demostraron consistentemente algunos cuestiones importantes relacionadas con la productividad. Por ejemplo, que los mejores programadores son 10 veces más productivos que los peores.

Pero demostraron algo más interesante: las variaciones de productividad están más relacionadas con las características del espacio físico de trabajo que con lenguajes de programación utilizados, años de experiencia, salario u otro factor.
Por ejemplo, los desarrolladores más productivos en las Coding Wars contaban en su lugar habitual de trabajo con un espacio físico promedio de 7,25 m2. Los peores contaban con sólo 4,25 m2.

En relación a este tópico DeMarco y Lister cuentan:

"Antes de diseñar los planes iniciales para sus nuevas oficinas en Santa Teresa, IBM violó todos los estandares de la industria estudiando cuidadosamente los habitos de trabajo de las personas que ocuparían ese espacio... "

El arquitecto que se encargó de estos estudios determinó que las características mínimas del espacio eran las siguientes:

- 9,3 m2 de espacio dedicado a cada trabajador.
- 2,8 m2 de superficie de trabajo (escritorios) por cada trabajador.
- Protección de ruido en forma de oficinas cerradas o particiones de 1,80 m de alto.

DeMarco y Lister concluyen:

"De hecho IBM siguió las recomendaciones y construyó un lugar de trabajo donde las personas pueden trabajar. (Predecimos que esta compañía llegará lejos)"

Resumiendo, la experiencia de los autores indica que los aspectos físicos y sociales de un grupo de desarrollo de software de primera linea debe incluir varios de los siguientes factores:

* Adecuado espacio silencioso y privado para cada desarrollador con un escritorio amplio.
* Areas comunes de fácil acceso para discusiones espontaneas de pequeños grupos sin que estas molesten a los demás desarrolladores
* Un entorno que posibilite minimizar las interrupciones a los desarrolladores cuando lo deseen.
* Planificaciones que permitan a los miembros de un proyecto "tener una vida" fuera del trabajo.
* Posibilidad de los desarrolladores para configurar y reconfigurar su entorno físico para adaptarlos a sus necesidades actuales.

Por supuesto, hablamos de un grupo de desarrollo de software de primera línea. No todos son capaces de aspirar a tener uno en su empresa.

Si alguien se presenta a hacer planteos y sugerencias sobre la productividad de un equipo de desarrollo de software, se puede saber si sólo busca a alguien a quien cargarle la culpa de sus males o si le interesa seriamente el tema, haciendo una simple pregunta: ¿has leído Peopleware?