Comunidad Ágil y Lean de Chile
Amigos(as):
Les confirmo que el proximo AgileDay (ex-XP Day) es el 12 de Diciembre de 2008, en la sala de Auditorium del Departamento de Ciencias de la Computación de la Universidad de Chile (Blanco Encalada 2120 Segundo Piso). El horario será de 9:00 a 13:30 y de 15:00 a 17:45.
Mayor información aquí
Aqui su reportero agil les cuenta lo que va sucediendo en Agiles2008.
Mi primera duda era cuanta gente iba a venir, y quedé impresionado por la respuesta, porque conté más de un centenar de aistentes entre entre argentinos, uruguayos, brasileros, bolivianos, venezolanos, los expositores norteamericanos y un sólo chileno (su servidor).
Cajita Feliz
Para ser una conferencia gratuita, estoy absolutamente impresionado con la calidad de la producción de este evento. Para muestra un botón. En toda conferencia que se precie de tal, le entregan a uno una bolsita o carpeta que yo llamo “cajita felix”. Además del cuaderno de notas y el lápiz de rigor, me encontré con dos sorpresas:
Continue reading ‘Reporte de campo: 22 de Octubre, Primer día de Agiles2008 en Buenos Aires’
Si les cuento que la estadística de éxito en la industria del software (entendido como aquellos proyectos que logran productos funcionales, de valor para el cliente con los recursos y tiempos establecidos) no supera el 35% (segun The Chaos Report del año 2006), ¿qué me dirían de una experiencia que desde el 2005 ha desarrollado 26 proyectos, con 22 de ellos exitosos? (84% de éxito)
Desde el año 1998 en la Universidad de Chile se realiza una experiencia en donde los alumnos del la carrera de Ingeniería Civil en Computación realizan proyectos de 3 meses para organizaciones del mundo real. En sus principios los resultados eran similares a los de la industria, pero desde el 2005 comenzamos aplicar conceptos ágiles y la realidad cambió.
El pasado martes 8 de Julio de 2008 realizamos el cierre de la más reciente versión del curso, en donde se presentaron 4 proyectos:
Lo interesante, además de la variedad de temas abordados, es que en todos los casos se logro un software funcional y útil para el cliente.
Ahora bien, ¿en donde está el secreto?. No hay un sólo elemento, sino que podemos nombrar entre otros:
Lo que fue una novedad es que esta generación logro entender muy bien los fundamentos de gestión de la incertidumbre de las metodologías ágiles, logrando explicar convincentemente cuales fueron sus estrategias para generar valor al mismo tiempo que se reducían los riesgos tecnológicos y de requerimientos del proyecto. Y no quiero dejar de mencionar el entusiasmo y motivación con que se enfrentó cada uno de los proyectos.
Quizás lo anterior quede mejor explicado en un video con mis palabras finales, en donde se resume muy bien el sentido de esta experiencia y como la filosofía ágil se impregna en ella.
Desde la última semana de julio se vuelve a realizar en el la Universidad de Chile el curso CC62V “Taller de Metodologías Ágiles de Desarrollo de Software”, experiencia que se realiza desde el 2002 que ha formado a unos 60 ingenieros en Extreme Programming y metodos afines, y en cuya experiencia base mi tesis de magister publicada en un articulo anterior
La idea de este curso es que los alumnos vivan una experiencia “miniaturizada” de XP, es decir: realizan un proyecto de desarrollo de software real pero acotado a las 3 horas semanales del taller. Esto quiere decir que se planifica con le Planning Game, se programa en pares y guiando el desarrollo por tests, hay un cliente in situ,… en fin, se aplican las prácticas valores y principios de XP
Como profesor de este ramo fue que me inicie como coach de XP, experiencia que después de muchos años he podido comenzar a aplicar en mi vida profesional en la empresa Microsystem.
Espero que haya una buena cantidad de alumnos que inscriban el curso (es opcional) y que se entusiasmen con la agilidad como forma de hacer mejor software de forma más agradable para clientes y desarrolladores.
Después de mucho luchar pude convertir mi tesis a formato PDF manteniendo en su mayoría la calidad de las imágenes explicativas.
Esta es mi tesis de magister, en donde analizo al metodlogóa que aplico en mi curso de la Universidad de Chile desde el 2002 en el curso “Taller de metodologías Ágiles de desarrollo de Software”, para decubrir las razones del entusiasmo que ha provocado en los alumnos y clientes de los proyectos realizados.
Espero en el futuro generar algunos artículos que resuman los tópicos descubiertos en esta tesis. Por mientras, esta disponible en la URL http://chileagil.comopapel.com/publicaciones/1/
Aprovecho de avisar que este espacio se abre para todo aquel que quiera compartir sus trabajos sobre metodología ágiles, sean estos académicos o no.
Saludos
Agustín Villena
Este es el Abstract de la Tesis:
Las metodologías ágiles de desarrollo de software, y en particular Extreme Programming (XP), constituyen una de las tendencias de mayor impacto en la industria del desarrollo de software en la última década, gracias a su enfoque centrado en la generación temprana de valor y en su acento en el aspecto humano del desarrollo de software. Su adopción sin embargo ha demostrado ser bastante compleja debido a los cambios de paradigma que ellas plantean.
Desde los inicios de estas metodologías surgió el interés de incorporar esta nueva mirada como una forma de enriquecer la formación de los futuros ingenieros de software. En este trabajo se plantea que un buen aprendizaje de las metodologías ágiles de desarrollo de software puede ser logrado por los alumnos a través de una experiencia educativa teórico-práctica basada en la aplicación de dichas metodologías en proyectos reales. Este enfoque ha sido aplicado desde el año 2002 en el curso CC62V “Taller de metodologías ágiles de desarrollo de software” del Departamento de Ciencias de la Computación de la Universidad de Chile, y en esta investigación se pone a prueba esta hipótesis, a partir del análisis de una de las instancias del curso realizada entre los meses de agosto y noviembre del año 2005.
Para realizar este análisis se construyó un modelo evaluativo de aprendizaje basado en cómo las metodologías ágiles, y en particular Extreme Programming (XP), organizan el entorno de un proyecto de desarrollo de software para mantener la sincronía entre los cambiantes elementos que allí están en juego. Dichos elementos son el problema de negocios, la tecnología, la experiencia y destrezas del equipo de desarrollo, y el producto en desarrollo.
El modelo de evaluación fue aplicado sobre los trabajos generados por los alumnos de la versión del curso usado como experimento de esta investigación, complementados con las observaciones realizadas por el profesor en la sala de clases, y otras evidencias tales como las opiniones de los clientes y una encuesta de evaluación de impacto hecha a los alumnos aproximadamente 6 meses después de finalizado el curso.
Con respecto al impacto en el aprendizaje de los alumnos, se observó una comprensión y aplicación generalizada del marco de prácticas de XP, aunque el nivel de logro estuvo muy relacionado al entorno de trabajo logrado por cada uno de los proyectos realizados. En particular se encontró que algunos elementos no considerados en la hipótesis original, tales como la complejidad del problema a resolver y la relación con el cliente, tenían también un impacto relevante sobre el éxito de los proyectos, y no sólo los aspectos pedagógicos. Se comprobó la eficacia de este modelo pedagógico que promueve el equilibro entre teoría y práctica, el ambiente humano de equipo y de colaboración con el cliente y las destrezas entrenadas. Por su parte, la práctica de XP más destacada por los alumnos es la “programación en parejas”, que presenta la mejor evaluación durante el curso y es la más aplicada a posteriori. Otra práctica que causa mucho interés es el “desarrollo guiado por test”, pero se indican problemas de tiempo y experiencia para poder aplicarla después del curso.
En lo que se refiere al modelo pedagógico aplicado para que los alumnos conozcan e internalicen las prácticas de XP, se determina que las claves de su éxito se encuentran en:
Durante mis primeros años de profesión siempre estuve involucrado en proyectos de software con pocos desarrolladores, en donde cada uno tenía labores separadas y con muy poca interacción entre sí, lo que parece ser la norma generalizada en los desarrollos de software locales. La influencia de esta forma de trabajar llega obviamente a los espacios de trabajo que ocupan los desarrolladores, en donde también es común encontrar ubicaciones que aislan al desarrollador, y que haya equipos que a pesar de trabajar juntos en el mismo piso, están dispersos físicamente. Es así que no es extraño encontrar puestos de trabajo de desarrolladores aislados por cubículos, o bien ubicados en esquinas, lo que ambos casos dificulta que se pueda trabajar con otra persona – lo que probablemente está diseñado así a propósito, para evitar “distracciones”.
Cuando comencé a interiorizarme en Extreme Programming el 2002, me llamó la atención el énfasis que XP pone en cómo organizar los espacios físicos de trabajo, algo que logre entender posteriormente cuando comprendí la perspectiva ágil sobre el desarrollo de software acerca de que éste último es una actividad primariamente basada en las personas para un continuo compartir y generar conocimiento. Prácticas claves de XP afectan el cómo se debe organizar un ambiente de trabajo, tales como:
Cuando llegué el 2005 a mi trabajo actual a ser parte de una nueva área de Investigación y Desarrollo en la empresa Microsystem, se definió como uno de mis roles el liderar la renovación metodológica, un arduo trabajo para una organización que cumple este año 30 años en el tema informático.
Una de mis aspiraciones desde el inicio fue (¡por fin!) poder tener un espacio de trabajo “ágil”. Sin embargo, mi primer lugar de trabajo era una oficina muy pequeña, sin luz natural, y mi labor en la práctica era en solitario. Unos meses después logré que se agregara un nuevo ingeniero a mi área (Philippe Camacho), pero quedamos trabajando separados por dos salas de distancia, todo esto debido a la falta de lugar disponible. Intentábamos hacer Pair Programming, pero esto era coartado por el poco espacio y un escritorio de trabajo con cajones que hacían muy incómodo que dos personas se colocasen frente a al mismo PC. Así que tuvimos que usar el chat como medio de coordinación y colaboración, a modo de “parche”.
Nuestro primer logro fue cuando pudimos derribar una pared, e instalar en el nuevo espacio un tablón a modo de escritorio compartido sobre el cual instalar los equipos de trabajo, y poder programar en parejas fácilmente. La colaboración mejoró ostensiblemente.
Unos meses después mi jefe nos pidió cambiarnos de piso al lado de la gerencia, a lo que pusimos una condición: tener un espacio de trabajo común similar al actual, dado que lo que habíamos ganado nos había costado casi dos años de gestión, lo que no se pudo cumplir antes de que otras necesidades cambiaran el rumbo de trabajo. A mediados del 2007, surgió un proyecto de renovación tecnológica que nos llevó a agrandar el equipo a 6 ingenieros, y a derribar más paredes. Cuando llegó el momento de instalar los nuevos muebles, optamos por módulos construidos en base a tablones similares al primero, pero esta vez móviles, para poder reconfigurar la oficina fácilmente si era necesario. De esta manera el Pair Programming se puedo generalizar al equipo completo.
Al poco andar, vi a necesidad de implementar un Informative Workspace para llevar la gestión de avance del equipo. Como modelo usé el kanban de Toyota a partir del artículo Naked Planning Explained – Kanban in the Small lo que podemos observar en la foto siguiente:
Dentro de las curiosidades que hemos implementado, les presento nuestra zona de diseño colaborativo, que es una mesa redonda en donde una pizarra sirve de borrador comunitario de ideas, y mi “Pair Station” , que es un PC con dos mouses y dos teclados para hacer más simple el Pair Programming
.
Bueno, este es mi deseado y primer “Software Studio”, nombre con que bauticé esta nueva oficina y que plagié flagrantemente de la empresa Role Model Software , aunque ellos aplican el término en un sentido más amplio que el que nosotros hemos logrado. Nos queda mucho por mejorar, pero podemos decir que nuestra oficina sirve para colaborar y hacer nuestro trabajo más entretenido y colaborar mejor.
Más información:
Roy Osherove escribe en su blog un interesante artículo acerca de los diversos tipos de “Unit Testing” y su evolución.
“The semantics of how you write a unit test, the basic syntax, or Domain Specific language of how we write them, has been relatively stale for quite some years now. But under the covers, the syntax revolution seems to be brewing, as people try to come up with newer, hopefully better and more readable syntaxes for tests and specifications that become more and more complex as the current Agile community struggles to accept best practices in this arena.
I’m guilty of that too, but a recent post by Jeremy Miller prompted me to try and list all the different syntax variations I’ve come across in the .net and some in java world (not necessarily in chronological order). Most ofthese didn’t necessarily catch on as de facto standards, but are real world attempts to make a better world or explore new horizons.”
Continuar Leyendo: “The evolution of Unit Testing Syntax and Semantics”
Recent Comments