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.
