Aquí estoy con “CMMI - Guidelines for process Integration and Product Improvement” en frente de mí, y acabo de leer el excelente post de Willi sobre PMBOK y ágil. (Recuerdo ahora que yo estaba impresionado con la estructuración de este libro. Cada referencia es hecha con una precisión quirúrgica. Cada cosa tiene un código, cuidadosamente atribuido y utilizado para referirse a los temas mencionados).
El Debate
El debate sobre si "es posible aplicar PMBok/RUP/CMMI/MPS.Br con Ágil" no tiene mucho sentido, final de cuentas. Todas estas siglas de la época de los métodos tradicionales, son sólo diferentes visiones sobre el proceso de desarrollo. Estas son maneras de entender un "mundo" específico: los proyectos de desarrollo de software (lo sé, no se aplica sólo a desarrollo de software, pero eso no es importante ahora).
Análisis del proceso
A mi modo de entender también específico, digase de pasada. Son visiones esencialmente analíticas, que tratan de clarificar las cosas "deshilachando" o "separando" sus elementos, en una estrategia de "divide y vencerás". Lo contrario sería la comprensión sintética, donde se parte de diversos elementos y se compone un todo, como lo hacemos al concluir un texto: juntamos todo lo que se dijo para reconstruir la idea general nuevamente.
Sobre ese punto de vista, los conjuntos de conocimientos como CMMI y PMBOK serían muy bien presentados en una Mapa Mental.
(contenido tomado de la wikipedia)
Acá para nosotros, se trata de un bello análisis de todos los elementos necesarios para la gran mayoría de los proyectos de software. Algunos van a desacordar con mi "necesario". Muchas de estas cosas pueden no ser realmente necesariar ... ¿Será? Tomemos algunos elementos, como ejemplo.
Control de cambios en el alcance
"Pero, en mi proyecto ágil yo no preciso hacer control de los cambios de alcance".
¿Cómo no? ¿Y qué es lo que estamos haciendo cuando no permitimos, de hecho ningún, cambio en el backlog del sprint durante el mismo? Solamente permitimos que nuevas tareas entren en la planificación a partir de una reunión con todo el equipo. ¿Para qué? Lo que podamos controlar los cambios en el alcance. Si el equipo no tuviera control sobre los cambios en la planificación, no podría tratar con ellos.
Gestión de Riesgo
"No tengo un plan de riesgos en mi proyecto ágil."
Podría ser. Pero decir que no hay gestión de riesgos ya es demasiado. Los riesgos son gestionados en todo momento. El propietario del producto al elegir historias durante la planificación; por el equipo al estimar; por el coach al cultivar la disciplina en si escrbir pruebas automáticas. Todos evaluan los riesgos en cada uno de los pasos a lo largo del proyecto.
Análisis detallado, ¿para qué?
Echa un vistazo a la estructura de los temas de estos libros. Son análisis extremadamente detallados, completos y estructurados. Este es un trabajo de maestro. Identificar, describir y estructurar cada uno de estos elementos es sin duda un trabajo notable y de gran valorpara nuestra industria. Gracias.
El problema no es precisamente el análisis que hacen estos abordajes. El análisis es espectacular. El problema es que en el día a día de un proyecto, esos análisis son inútiles.
Es como comprar un manual de manejo de automóviles que hace un análisis detallado de todas las técnicas para apretar el embrague, el momento adecuado para pasar los cambios, y así sucesivamente. Por mas detallado y acertado que sea el manual, no ayuda nada llevarlo en el cuello a la hora de manejar. Ni siquiera estudiar cada detalle y tratar de hacer frente a todo a la vez.
En el momento de manejar, lo que importa no son los detalles, si el todo o el conjunto. Intentar visualizar, entender y controlar cada uno de los elementos envueltos es al mismo tienpo inútil y agotador. Es algo de mas.
¿Y otra forma?
Esto nos lleva directamente al argumento de Willi. Nadie dice que usted necesita aplicar todo lo que está en los libros. Por el contrario, el los capítulos iniciales de todos ellos dicen categóricamente que todo debe ser adaptado, seleccionado, filtrado. El problema es que ninguno de ellos explica cómo las cosas deben ser elegidas, ni adaptadas. Las prácticas debe ser modificadas para su proyecto específicamente. Pero, ¿cómo? Problema suyo. Por lo tanto, la lectura subliminal que se hace es que los proyectos deben ser gerenciados en todos los aspectos. Cuando más detalle se consigue visualizar y documentar más maduro es su proceso. Sobre esto se craa una escala de méritos totalmente distorsionada, sobre la base de inspecciones, evaluaciones, pruebas, exámenes y otras atrocidades. Elementos artificiales, que sólo contribuyen a seguir sesgando aún mas el proceso de mejora, cuya principal preocupación se convierte en el certificado que usted gana al final. (No parace mucho un signo maduración...)
XP y Scrum, en cambio, no hacen lecturas analíticas. Se refieren a cuestiones prácticas que se sustentan a través de una cadena de valores explícita y coherente, que refleja las necesidades reales de proyectos reales. Te encantan los cálculos geométricos complicados y herramientas de precisión. Bien, pero para elevar el muro recto el albañil necesita de la plomada.
Análisis del pensamiento
Para ser honesto, en el libro más importante de sobre XP (en mi opnión), Kent Beck hace también una lectura analítica: XP se divide en valores, principios y prácticas. Pero podes ver que en este caso no se trata de un análisis del propio proceso de desarrollo en sí. El análisis hecho se refiere al tipo de pensamiento utilizado para sustentar las prácticas.
Esto si es análisis relevante. Este no privilegia una visión específica de cómo se debe hacer software, sino una estructura de decisión que nos ayuda a definir cómo las cosas deben adaptarse en cada caso. A diferencia de los libros antes mencionados, aquí la forma en que las cosas deben adaptarse es clara y coherente.
El propio Kent Beck señala que los principios presentados en su libro no son los únicos posibles. Las organizaciones particulares pueden cultivar otros valores, otros principios. ¡Y deben hacerlo! Lo que se necesita es que se debe utilizar una cadena de razonamiento análoga para definir como debe ser el día a día en los proyectos. Entienda sus valores, exprese sus principios y de ellos derive las prácticas que deben seguirse.
Ejemplo
"Para conducir, usar ambas manos en el volante." Eso expresa el principio del manejo defensivo, que se basa en el valor de la Seguridad. Ahora, si prefiere cultivar el valor de la Comodidad, a continuación, deje el brazo izquierdo en la ventanilla, es mucho mejor. ¿Cuál de los dos valores es más importante ahora? Es un marco (framework) para la toma de decisiones realmente útil.
Así que, resumiendo, el problema de la PMBOK/RUP/CMMI/MPS.Br no es precisamente el análisis que se hace, sino en la lectura (¿a propósito?) inducida de que se trata de manuales de dirección. No lo son. Son herramientas teóricas maravillosas. Pero si estás interesado en dirigir bien, dejalos en casa y mirá las cosas de la manera ágil.
