(Tesis) Guía para la Adopción de Metodologías Agiles en el Sector Publico

A continuación presentamos el aporte de nuestro amigo Jorge Aguilera, en un resumen de su tesis para obtener el Magister en Tecnologías de la Información en la  UTFSM

---

Un poco de historia

Hace aproximadamente quince años, tuve mi primera oportunidad de trabajar como desarrollador en una empresa de software. Recuerdo que venía de estudiar y de aprender mucho sobre los denominados métodos tradicionales, diagramas y especificaciones. En el fondo, mucha documentación. La curiosidad estaba en que para desarrollar y escribir código nos basábamos en una pizarra, cuadernos, acuerdos verbales y nuestra propia conversación. Debo  reconocer que pensaba que el trabajo que estábamos haciendo no estaba del todo correcto, ya que desde el punto de vista del diseño y construcción del producto, no se relacionaba directamente con la teoría aprendida. Complementariamente, los informes a la gerencia presentaban estados de avance que sin mayores esfuerzo de análisis no reflejaban lo que en verdad sucedía y se construía.

Posteriormente, dejé esa empresa y llegué a trabajar a un servicio público, donde se estaba recién implementando la unidad regional de informática. Como dato teníamos sólo 8 equipos en red y hoy tenemos 250, claramente se podían vislumbrar dos áreas de trabajo, desarrollo y redes. En aquel momento concentré el esfuerzo en el desarrollo, me dediqué a realizar entrevistas, elaborar informes, presenté documentación y de desarrollo, poco. Con el tiempo, para poder desarrollar concentraba mis esfuerzos en sólo dos cosas, en el modelo relacional y en definir fielmente lo que quería el usuario y para ello, utilizaba un cuaderno y una pizarra. Así, trabajé durante aproximadamente cinco años y fue en el Magister en Tecnologías de Información de la Universidad Técnica Federico Santa María, donde conocí sobre el desarrollo ágil.  En base a mi experiencia, pude comprobar que para hacer buen software hay que omitir parte de la documentación y entender realmente lo que quieren las personas, en el fondo, sin querer, había trabajado y presentado algunos síntomas de Agilismo.

Adoptar Agilismo

Por aquel entonces me dediqué a investigar en qué consistía  el manifiesto ágil, sus postulados y principios. Como así también proponernos en el tiempo ser ágiles, la pregunta del momento era ¿cómo?. Para ello, la literatura siempre hablaba de casos exitosos.  Pero había poca documentación para entender cómo se podía adoptar el Agilismo. Se tenía clara la teoría y los resultados obtenidos, pero como lo hacíamos, volvía a ser la pregunta. Para ello, centré mis esfuerzos  en elaborar una Guía para la adopción de las metodologías ágiles, la base de la guía es entender que para ser ágiles tenemos que pasar por un proceso e identificar una serie de factores que pueden influir en  cada una de las etapas. El proceso como tal consta de tres etapas, la investigación, la aplicación y la evaluación. Los factores que influyen en cada una de ellas son las personas, la organización y la tecnología. La investigación se centra en la idea fundamental de conocer en qué consiste la metodología, su definición, teoría, alcance, ámbito, etc., en el fondo, empaparse del Agilismo. La segunda etapa aplicación, consiste en llevar a la práctica lo aprendido pero teniendo en cuenta el descubrir si existen síntomas de Agilismo y que el equipo  pueda en si re-estudiar y aplicar  mejores y buenas prácticas para el desarrollo. Como es práctica, se debe utilizar un proyecto idealmente de tamaño pequeño o medio, para realmente aplicar Agilismo y no caer en la ansiedad de ser agiles sin practicar. Finalmente la última fase corresponde a la evaluación formal de decidir si el Agilismo como metodología es aplicable al equipo de trabajo. Complementariamente, hay tres factores que definitivamente influyen en cada etapa y son:  las personas que deben enfrentar un cambio de paradigma, la organización que tiene que estar preparada para los cambios y ser partícipe de él y finalmente, la tecnología que se emplea como el medio para articular y dominar el ambiente del Agilismo.

Espíritu de la Guía

La guía no representa una  aplicación lineal a implementar, como así tampoco garantiza el éxito. No es un símil de una guía telefónica o una guía caminera, por ello para ser ágil tenemos que pensar en shuhari. Shuhari es la forma de cómo se deben enseñar las artes marciales desde el maestro al aprendiz, en Shuhari inicialmente el Shu representa  una fase de exploración,  entender cómo funciona la técnica, en la segunda fase Ha se analiza lo que se hace, se entienden los movimientos, para finalmente el RI es la fase de independencia, los movimientos son naturales, cada etapa propuesta en la guía está asociada a Shuhari.

Aplicación

Básicamente la aplicación de la guía en nuestro ambiente de trabajo, nos permitió ordenarnos y aplicar muchas cosas de Agilismo. Principalmente, en mejorar la comunicación al interior del equipo y utilizar Kanban. Los ambientes de desarrollo y producción se mejoraron a nivel de versionamiento, entregas y funcionalidades. Desarrollamos un framework propio, básico pero poderoso para mejorar nuestros trabajos. A modo de ejemplos,  obtuvimos ahorros en los tiempos de desarrollo para proyectos importantes, los usuarios se hicieron partícipes de los proyectos, los resultados estaban disponibles y en uso y, con el usuario, hablábamos en su propio lenguaje.

Conclusiones

Cuando empecé a elaborar esta guía, tomé como base de motivación disponer de un medio que guiara a un equipo de desarrollo a mejorar sus prácticas de desarrollo utilizando la metodología ágil. Ser ágil, en mi opinión, es un proceso y como tal está asociado entre otras muchas cosas al conocimiento, compromiso y talento de las personas y del mismo grupo. La motivación por hacer buen software debe ser permanente, donde cada línea de código debe reflejar un buen argumento y un objetivo por cual se escribe. La experiencia es una guía, los resultados  mejoras. Ahora, como  se garantiza el éxito en cada equipo de desarrollo, simplemente este va  a depender del mismo equipo.

---

El documento lo pueden encontrar aqui: Tesina Jorge Aguilera