Entrevista con Scott Ambler

Scott W. Ambler dirige la práctica de Desarrollo Ágil en IBM. Es considerado como uno de los principales “agilistas” en el mundo, y ha creado varias metodologías entre las que destacan Agile Modeling (AM), Agile Data (AD), Agile Unified Process (AUP), y Enterprise Unified Process (EUP). Scott será uno de los conferencistas magistrales en SG ’07, así que aprovechamos la oportunidad para publicar esta pequeña entrevista donde nos comparte su perspectiva sobre Ágil y otros temas que tratará durante SG ’07.

¿Cómo describirías el estátus actual de Ágil?
Hace unos años, Ágil era visto como un movimiento, una revolución. Sin embargo, creo que actualmente Ágil ya es parte de la “corriente principal” (mainstream) de los métodos de software. Justamente en marzo de este año realicé una encuesta sobre el grado de adopción de ágil, y de las 781 personas que contestaron, el 69% contestó que su organización aplica técnicas derivadas de Ágil. Esto no quiere decir que todo mundo ya esté usando algo como XP como su proceso default, pero si nos indica que la mayoría ya está usando (o considerando usar) una o más técnicas de Ágil.

¿Cuáles consideras que son los principales retos de Ágil en los próximos años?
Creo que el principal reto para Ágil al corto plazo es demostrar que es escalable a proyectos grandes. Precisamente el trabajo que hago con IBM consiste en ayudar a clientes a aplicar técnicas ágiles en proyectos grandes y complejos donde se tienen muchas restricciones de regulación, y el equipo de desarrollo es grande, distribuido geográficamente, y formado por distintos proveedores. Estas organizaciones están interesadas en adoptar Ágil, precisamente porque están interesadas en maximizar su eficiencia. En www.ibm.com/rational/agile tenemos varios documentos y videos al respecto.

¿Crees que Ágil evoluciona? ¿Cómo?
Sin duda, las metodologías ágiles están evolucionando. Por ejemplo, en los últimos años yo he hecho varios ajustes a Agile Modeling; Kent Beck liberó la segunda versión de su libro “Extreme Programming Explained”, donde presenta cambios significativos a la versión original de XP; Enterprise Scrum justo acaba de salir, y básicamente es una extensión de Scrum que toma ideas del Rational Unified Process (RUP). También está el Open Unified Process (OpenUP), que es un método ágil open source que está disponible en www.eclipse.org/epf.
Así que en el espacio de las metodologías, claramente hay una evolución y actualización.

Por otro lado, es interesante ver que el Manifiesto Ágil parece resistir la prueba del tiempo. Los valores y principios en que se basa no han sufrido cambios, y parecen no necesitarlos. Sin embargo, también está el trabajo del Agile Project Leadership Network (APLN), www.apln.org, el cual en cierta forma puede ser considerado una extensión al Manifiesto Ágil.

Al parecer, la gestión de datos (Data Management) también está siendo impactada por Ágil, ¿podrías explicarnos algo sobre esto?
Introducir agilidad al mundo de la gestión de datos es una tarea ciertamente complicada. Desafortunadamente, la gestión de datos se mantenido relativamente estática en cuanto a métodos y procesos, y muchos de los profesionistas de esa comunidad se siguen aferrando a concepciones erróneas sobre como funciona el desarrollo de software en realidad. Por ejemplo, muchos DBAs creen que es difícil evolucionar o refactorizar un esquema de base de datos existente. Esto es algo que Pramod Sadalage y yo demostramos que se puede hacer fácilmente a través de las técnicas documentadas en nuestro libro “Refactoring Databases”. Sin embargo, los DBAs que no comprenden esto se enfocan en hacer demasiado modelado muy temprano en el ciclo de vida, lo cual en el libro “Agile Database Techniques” demuestro que es una forma de trabajo altamente ineficiente. El Data Warehouse Institute estima que tan solo en Estados Unidos, los problemas de calidad de datos generan un costo de $600 mil millones de dólares anualmente. A pesar de esto, la comunidad de profesionistas de datos ofrece muy pocas recomendaciones prácticas sobre lo que se puede hacer para resolver esto.

En resumen, creo que hay problemas serios en la gestión de datos, sin embargo la mayoría de los profesionistas se aferran a los métodos que generaron estos problemas en primer lugar. Afortunadamente, la comunidad Ágil está involucrándose y desarrollando alternativas para resolver estos problemas. Yo he escrito varios artículos al respecto que están disponibles en www.agiledata.org y que pueden ser de gran ayuda para los profesionistas de datos.

¿Es cierto que un desarrollador de un equipo que utiliza Ágil necesita mayor habilidad y experiencia que en el desarrollo tradicional, o simplemente es cuestión de una mentalidad diferente?
El aspecto fundamental es la mentalidad. Los desarrolladores ágiles buscan colaborar estrechamente con otros, aprender de cada uno, y desarrollar nuevas habilidades. También tienen un fuerte enfoque a la calidad, típicamente utilizando una estrategia “test-first” (probar primero). El hecho es que ser un desarrollador ágil requiere mayor disciplina que uno tradicional, así que tal vez no sea para todos.

Últimamente has escrito sobre “lean development governance”, ¿de qué se trata esto?
La gobernabilidad tradicional se enfoca en estrategias de comando y control, que buscan administrar y dirigir a los equipos de proyecto de forma explícita. Aunque ésta es una estrategia válida en algunas situaciones, en la mayoría de los casos es semejante a arrear gatos –se aplica un gran esfuerzo pero se obtienen pocos resultados. En cambio, “lean governance” se enfoca en estrategias de colaboración que buscan habilitar y motivar a los miembros del equipo implícitamente.

Por ejemplo, la forma tradicional de hacer que un equipo siga lineamientos de programación es definirlos y luego realizar inspecciones formales para asegurar que se estén siguiendo. En cambio, lo que se haría en un enfoque “lean”, sería escribir los lineamientos en colaboración con los programadores, explicando la importancia de que todos los sigan, y luego proporcionando herramientas que faciliten la adopción y seguimiento de los lineamientos. El enfoque “lean” es semejante a guiar gatos, si tomas un pedazo de pescado, ellos te seguirán a donde vayas.

¿Consideras que el desarrollo dirigido por modelos (MDD) alguna vez será el común denominador de cómo desarrollar software?
Eso depende de qué entiendas por MDD. La versión Ágil de MDD ha sido el común denominador desde hace años, ya que es muy común que los desarrolladores ágiles usen herramientas sencillas como pizarrones y rotafolios para modelar. Lo que no es tan común es el enfoque que promueven los profesionistas de modelado, donde todo se debe hacer en una herramienta CASE. En teoría, esta estrategia es muy buena. Sin embargo, en la práctica muy pocas organizaciones tienen suficiente gente con las habilidades necesarias para lograr esto. Las organizaciones que llegan a tener buenos modeladores, con buenas herramientas, logran muy buenos resultados. Sin embargo, este es un porcentaje pequeño de todas las organizaciones de software, y dudo que eso cambie en el futuro cercano.

¿Qué opinas sobre la programación orientada a aspectos (AOP)?
Creo que AOP es una solución muy interesante que todavía está buscando un problema que resolver, y no veo que eso vaya a cambiar.

¿Qué está sucediendo en cuanto al Eclipse Process Framework (EPF)?
Este es un proyecto muy interesante. El EPF composer permite que las personas puedan definir, personalizar y publicar procesos de software, e incluirlos en la herramienta de desarrollo Eclipse. Hay mucho material disponible, incluyendo el OpenUP y la definición de Extreme Programming para EPF. Últimamente no he estado muy involucrado en este proyecto, pero espero poder hacerlo pronto, para agregar más material sobre modelado de datos ágil.

¿Algunas palabras para nuestros lectores?
Estoy muy entusiasmado de visitar México. Nos vemos en SG ’07.