Esta vez me gustaría pensar un poco sobre personas, aprendizaje y procesos de desarrollo. Comencemos...
Alistair Cockburn, en su libro Agile Software Development, hace mención de las tres etapas de aprendizaje, las cuales que me resultaron especialmente reveladoras. Se trata de lo siguiente:
La gente que está aprendiendo nuevas habilidades pasa por tres etapas de comportamiento bien definidas: following, detaching y fluent.La gente en la etapa following busca un procedimiento que funcione. Aún cuando 10 procedimientos distintos puedan funcionar, ellos no pueden aprender 10 al mismo tiempo. Ellos necesitan uno para aprender primero, uno que funcione. Ellos lo copian y lo aprenden. Necesitan instrucciones explícitas, una receta.
En la etapa detaching la gente localiza las limitaciones de su procedimiento y busca reglas para saber cuando el procedimiento no sirve. En esta etapa la persona aprende a adaptar el procedimiento a varias circunstancias. Ahora está más interesado en aprender los 10 procedimientos alternativos, en aprender cuando aplicar cada uno y cuando no funcionan.
En la tercer etapa, fluent, se torna irrelevante para la persona si está siguiendo una técnica específica o no. Su conocimiento se ha integrado entre cientos de acciones y pensamientos. Si se le pregunta si está siguiendo un procedimiento particular seguramente levantara sus hombros: no es importante para él si está siguiendo un procedimiento, improvisando uno alrededor de uno existente, o creando uno nuevo. Entiende el efecto final deseado y simplemente se conduce hacia él.
Conocer esta evolución me ha aclarado gran cantidad de situaciones.
He vivido esta evolución más de una vez.
Recuerdo clases de Diseño de Sistemas en la universidad, cuando el paradigma orientado a objetos era algo relativamente nuevo para mí y me iniciaba en la tarea de encontrar objetos a partir de requerimientos. Allí estaba yo, algo desconcertado, conociendo una manera distinta de pensar los problemas y sus soluciones. Sin duda transitaba la primer etapa que menciona Cockburn, y necesitaba una receta que pudiera seguir. La receta clásica para encontrar objetos es extraer los sustantivos que forman parte de los requerimientos. Así, si en alguna parte de la especificación de requerimientos dice:
Mensualmente cada empleado recibe su sueldo según las horas trabajadas
yo detectaba los objetos empleado, sueldo y hora. Es una técnica bastante simple (y directamente inútil para algunos[1])
No hizo falta que pasara mucho tiempo para que me diera cuenta de las limitaciones de esta receta y que la utilizara sólo como un punto de partida para agregar luego otras abstracciones que me parecieran necesarias y quitar las prescindibles. Ya estaba en la etapa 2.
Hoy no uso concientemente una técnica particular para detectar abstracciones en los requerimientos, simplemente lo hago. Me resultaría molesto que alguien me obligue a aplicar una técnica como la extracción de sustantivos para detectar objetos. Haría mi trabajo más lento, los resultados serían peores y encima estaría de mal humor. Pero esa receta tuvo su utilidad en algún momento.
Etapas de aprendizaje y procesos de desarrollo
Ahora me gustaría establecer una relación entre estas tres etapas y la definición de procesos de desarrollo de software.
Me parece lógico que el nivel de definición de un proceso de desarrollo sea acorde al nivel de aprendizaje de las personas que lo utilizarán.
Supongamos un escenario extremo: no hay proceso de desarrollo definido (¡huy, qué extremo!). En este contexto, hay personas a las que se les puede dar un proyecto de desarrollo y lo hacen. Y pueden tener éxito repetidamente. Porque saben lo que necesitan para hacerlo y lo que no saben lo aprenden. Punto.
Tal vez comiencen registrando requerimientos en un documento casi sin formato y pasarán a algo más sofisticado si hace falta.
Seguramente acordarán un conjunto de directivas de codificación que respetarán uniformemente, y no les tomará demasiado tiempo porque saben que lo importante de las directivas de codificación es respetarlas, no definirlas.
Estableceran algúna política para el manejo de versiones y desarrollarán todo el código utilizando pruebas unitarias. Integrarán diariamente el código y no permitirán que código que no pase las pruebas unitarias esté presente en el repositorio. Se organizarán asignado tareas para cada uno considerando las dependencias y las fechas de entrega, y no será gran problema si alguna tarea tarda un poco más o menos sabrán resolverlo. Posiblemente hagan el seguimiento del proyecto en una simple planilla de cálculo. Si hay problemas de sincronización de cambios en la base de datos definirán un procedimiento para realizar estos cambios y tal vez hasta desarrollen una pequeña heramienta para hacerlo. Si faltan datos en la especificación de requerimientos, modificarán los documentos para que se incluyan. Tambien es muy probable que hagan revisiones de pares para partes críticas o, ¿quien sabe?, tal vez hasta apliquen pair programming.
El hecho es que no les importa si lo que hacen es parte de un proceso definido previamente o una nueva técnica digna de un premio Turing. Lo hacen. Funciona. Punto.
Un proceso simple con herramientas simples son suficientes para que ellos sean eficientes. Ellos piensan: "Desarrollar software no es rocket science". Simplemente lo saben hacer.
Tambien existen otras personas que necesitan recetas, guías paso a paso para poder sentirse seguras que están haciendo las cosas tal como deberían. Prefieren contar con grandes plantillas para definir requerimientos y no las modificarán aunque en la mitad de los datos solicitados siempre escriban "No aplica". Necesitan revisar listas de verificación de varias páginas en cada paso del proyecto para saber que lo hicieron bien y valoran una planificación detallada de actividades de horas de duración para saber quien hace cada cosa y que se debe hacer despues. La programación se les torna demasiado complicada sin un documento de diseño con diagramas de clases que les indique que métodos deben programar, como se relacionan los objetos y hasta que tipo de colección conviene utilizar para guardar los items de una factura.
No son malas personas, no son menos inteligentes, sólo estan en una etapa temprana de aprendizaje.
Un equipo de desarrollo de software compuesto por personas en este estado inicial de aprendizaje por más proceso de definido que tengan dificilmente pueda nivelar sus resultados con un equipo formado por personas en la tercera etapa, de la misma manera que un principiante en diseño orientado a objetos no puede alcanzar los diseños de Kent Beck identificando sustantivos en una frase. Esto es así y no hay nada que pueda cambiarlo. Además las recetas detalladas apropiadas para determinadas personas pueden ser contraproducentes para otras.
Esta idea de adaptación de un proceso a las personas que lo utilizan parece brillar por su ausencia, porque muchas veces pensamos que podemos resolver la mayoría de los problemas definiendo con más detalle nuestro proceso de desarrollo, agregando más documentos, más actividades, más listas de verificación. Dejando menos margen para el error. Mitigando más riesgos. Y estamos dispuestos a invertir dinero en este refinamiento del proceso porque parece que con esto ganamos en certidumbre, en predecibilidad.
Si observamos que agregar más detalle a un proceso que será utilizado por personas que saben desarrollar software no es necesario porque en realidad no representa una mejora, entonces es posible que exista una alternativa: invertir dinero en el aprendizaje de las personas para formar equipos que sepan adaptar las prácticas a su proyecto, que completen su proceso, que sepan desarrollar software. Priorizar las personas y sus interacciones sobre los procesos y las herramientas.
[1] Bertrand Meyer, en su libro Construcción de Software Orientado a Objetos, habla sobre la técnica de identificación de objetos mediante sustantivos:
"Si la vida fuera tan sencilla uno podría llevarse a casa por la noche los documentos de requisitos y jugar al Object Pursuit en la mesa del comedor. Esta podría ser una buena forma de mantener a los niños alejados de la TV y hacer que revisen sus nociones de gramática mientras ayudan a mamá y papá en su trabajo de ingeniería de software"
