Categoría: agile

Fail Fast en Agiles Colombia

El martes pasado participé virtualmente de este evento, por invitación de Luis Mulato. La idea era compartir algunas experiencias del uso de Scrum y de la práctica de Integración Continua. El otro invitado fue Lácides Guzmán.

Creo que nos complementamos muy bien, pues mientras la experiencia Lácides es principalmente en el desarrollo de producto, la mía es en desarrollo de proyectos. O sea Lácides trabaja en un empresa que desarrolla un producto que luego comercializa. Por mi parte, casi siempre he trabajado en empresas dedicadas al  desarrollo de software para terceros.

Toda la actividad estuvo facilitada por Luis, quien con algunas preguntas orientadoras guió muy bien el desarrollo de la sesión y supo manejar de forma apropiada las preguntas de la audiencia, aportando algún bocadillo de su experiencia en algunas de respuestas.

La experiencia me gustó mucho y algunas de las preguntas me hicieron reflexionar sobre cuestiones que nunca me había puesto a pensar explícitamente.

¡Gracias Luis y Agiles Colombia por la invitación!

El dilema del conocimiento pasado

Gran parte de mi desarrollo profesional lo hice trabajando con tecnología Microsoft (C#, Asp.Net, Sql Server, SharePoint, Biztalk, etc, etc) pero desde hace unos dos/tres años di un giro y comencé a trabajar con tecnologías «abiertas» (por llamarlas de alguna forma genética), principalmente Ruby, Smalltalk y últimamente Grails.

Hoy por hoy soy más «feliz» trabajando con tecnologías abiertas que con tecnología Microsoft, pero paradójicamente conozco mucho más de tecnología Microsoft que del resto. Al mismo tiempo me parece una picardía «tirar por la borda» todo ese conocimiento y experiencia acumulado durante años.

En fin, ya puse a descargar Visual Studio 2012.

Charla: Estrategias para la adopción de Continuous Delivery

El próximo Jueves 19 de Septiembre, en el contexto del encuentro de la comunidad ágil de Buenos Aires, estaré dando la charla de referencia.

La cita es a partir de las 18.30 en las instalaciones del MUG, como siempre la entrada es gratuita pero requiere registración.

Algunos detalles más sobre la charla los pueden encontrar en la página de registración.

Interesante experiencia en el curso de Scrum Developer

La semana pasada participé junto a MartínS en el dictado del curso de Scrum Developer avalado por la Scrum Alliance. Si bien no era la primera vez que participaba de un curso así, esta ocasión tuvo como desafio el tamaño de la audiencia: 20 personas. En general el curso solemos dictarlo para un máximo de 16 personas, pero dado que en este caso fuimos dos instructores, pudimos estirarnos un poco más.

El curso está divido en 3 módulos, los dos primeros enfocados en cuestiones de organización y planificación  y el tercero en cuestiones de desarrollo. En este tercer módulo que dura 24 horas (generalmente en 3 días), trabajamos con Ruby dada la facilidad de uso/aprendizaje de sus herramientas (aunque también tenemos chances de hacerlo con otros lenguajes). Durante el curso se hace un simulacro de proyecto donde trabajamos en iteraciones de 2 horas, utilizando Scrum, BDD, TDD e integración continua para construir una aplicación.

Una vez más me sorprendió durante el curso, la gran influencia en la forma de pensar/diseñar que ejercen los lenguajes de programación. Al ver el código escrito por los asistentes del curso, saltaba a la vista que eran programadores Java. Lo mismo me pasaba a mi cuando comencé a trabajar en Ruby, recuerdo algunos colegas que miraban mi código y me decían cosas del estilo «¡Estas programando C# con Ruby!».

Les dejo la foto de cierre del curso.

csd

Workshop de Extreme Programming, segunda edición

Hace un tiempo escribí sobre el workshop de Extreme Programming que dicté en conjunto con mi colega Carlos Peix. Luego de haber incorporado el feedback de los asistentes, agendamos para hacer una segunda edición a mediados de Septiembre, concretamente 23 y 24 de septiembre.

A diferencia de la edición anterior, esta vez el workshop será abierto al público en general, pero con una restricción: gente de perfil técnico. Esto se debe a que el curso está enfocado en cuestiones técnicas, con lo cual esperamos que sea gente que pasa parte de su día programando. Asimismo se espera que los asistentes esten familiarizados con métodos ágiles, en particular con Scrum. El curso está planteando como una continuación del curso CSD, con lo cual cualquier persona que haya tomado dicho curso está en condiciones de tomar este curso. Pero ojo, el CSD no es un requisito, el requisito es, como mencioné previamente, estar familiarizado con Scrum y métodos ágiles en general.

tools2-xpwDado que el curso es muy técnico y con una alta carga práctica, los asistentes deberán asistir con sus computadoras y previo al curso deberán resolver una prueba de técnica. Dicha prueba consiste en implementar una user story muy muy simple, pero que obligará a los asistentes a hacer el setup del ambiente que utilizarán en el curso.

Durante el curso utilizaremos un rico conjunto de herramientas que incluye: Git, Ruby, Jenkins, Bootstrap, Heroku y Padrino, entre otras. Para simplificar el setup del ambiente de trabajo hemos preparado detallados instructivos muy fáciles de seguir y para aquellos no quieran invertir tiempo en esto, también hemos preparado una máquina virtual con el ambiente ya listo. tools-xpw

No es necesario que los asistentes conozcan todas estas herramientas, pues el foco no del curso no está en las herramientas sino en los conceptos y prácticas. Por ello, desde el punto de vista técnico, basta con que los asistentes sepan programar utilizando el paradigma orientado a objetos.

El curso está estructurado como una simulación de un proyecto de desarrollo de una aplicación tipo «enterprise» que utiliza base de datos e interactúa con otros sistemas como Twitter, Gmail, etc.

Este curso permite a los asistentes conocer y entender las prácticas de Extreme Programming a partir de su puesta en práctica en un contexto típico de una aplicación enterprise, utilizando varias herramientas muy difundidas en la actualidad.

Para más detalles y consultas pueden consultar la página de registración del curso.

tools3-xpwAplicación de ejemplo utilizada durante el curso

Continuous Delivery, aplicaciones legacy, TestNG y SeleniumIDE

Una cuestión clave en todo contexto de continuous delivery son las pruebas automatizadas. De poco sirve pasar «rápido» entre ambientes, si no podemos garantizar cierta calidad de lo que estamos poniendo en cada ambiente.

Cuando uno construye aplicaciones desde cero, es relativamente fácil generar pruebas automatizadas. El uso de técnicas como BDD y TDD junto con algunos patrones de diseño permiten generar aplicaciones testeables y con alto nivel de cobertura.

Pero no siempre trabajamos sobre aplicaciones nuevas. En ocasiones nos toca trabajar con aplicaciones ya existentes, que muchas veces no cuentan con pruebas y que han sido desarrolladas sin tener en cuenta la testeabilidad. En los contextos ágiles a este tipo de aplicaciones se les suele llamar aplicaciones legacy.

Por suerte son pocos los proyectos, en los que trabajando como programador, he tenido aplicaciones legacy. Sin embargo, trabajando como consultor, me he cruzado bastante a menudo con clientes llenos de este tipo.

Mi estrategia para trabajar con aplicaciones legacy es comenzar haciendo algunas pruebas funcionales que cubran los principales flujos de la aplicación. Y luego a gradualmente comenzar a modificar la aplicación haciendola testeable y agregando distintos tipos de tests según sea posible.

Una combinación de herramientas que me ha resultado interesante para hacer pruebas funcionales es SeleniumIDE + TestNG.

Selenium IDE es una herramienta de automatización de pruebas del tipo Record & Play que funciona integrada con el explorador FireFox y permite que uno vaya recorriendo la aplicación y poniendo aserciones en determinados puntos. Luego la misma herramienta permite reproducir la prueba grabada. Si bien a primera vista la estrategia puede parecer muy interesante, la realidad es que no es tan simple. De hecho este tipo de herramientas de automatización de pruebas ha tenido varias críticas (algunas de las cuales comparto), por diversos motivos que han sido tratados, entre otros, por George Meszaros.

Por su parte TestNG, es una herramienta al estilo JUnit, pero a diferencia de esta, tiene un foco más amplio que la prueba unitaria y por ello provee algunas funcionalidades muy útiles para hacer pruebas funcionales.

A partir de estas dos herramientas, mi estrategia es:

  1. Diseñar la prueba y crear la «cáscara» de la prueba con TestNG
  2. Grabar la prueba con Selenium IDE
  3. Exportar el script resultante a Java
  4. Tomar el código del script Java generado y usarlo para completar la cáscara creada con TestNG
  5. Ajustar la configuración del driver de test (pues si bien por default viene FireFox, uno podría querer/necesitar probar con otro browser)
  6. Ajustando el código de prueba en TestNG tomando en cuenta la particularidades de la prueba
  7. Ejecutar las pruebas con TestNG

Dos cuestiones importantes a considerar para utilizar este enfoque y que son las que abarca el punto 5 son:

  1. Es posible que para ejecutar las pruebas sea necesario contar con un estado particular de la aplicación que puede no ser trivial de generar
  2. Es muy común que los datos de tests requieran cierto grado de «dinamismo». Aquí puede resultar muy útil la funcionalidad de TestNG que permite definir sets de datos de prueba.

Bien, esto es todo por el momento.

Como siempre, si tienen alguna consulta/inquietud, no duden en escribirme.

Impresiones del Agile Open Buenos Aires Educación 2013

Hace dos semanas participé de este evento comunitario y me llevé un montón de cuestiones para profundizar y experimentar.

Una de las particularidades del evento fue la presencia de una importante cantidad de gente no relacionada al desarrollo de software, lo cual resultó muy enriquecedor.

Yo propuse dos sesiones: una para compartir experiencias de Aula Extendida y otra para debatir sobre los trabajos finales de las carreras de sistemas. Sólo la primera tuvo apoyo y se realizó, pero de todas formas hablé sobre el segundo tema en los pasillos, con algunos asistentes que estaban interesados. En la sesión de Aula Extendida, comenté mi experiencia en las materias que dicto en UBA y UNQ. Uno de los participantes planteó si es mejor utilizar las herramientas provistas por redes sociales que los sistemas típicos de los ambientes académicos (listas, foros, Moodle. etc).

Una de las sesiones que más me gustó fue la propuesta por la gente de EDEA, una organización que trabaja en cuestiones de diseño sustentable. Nos contaron sobre su organización, la forma en que trabajan e hicimos un par de dinámicas corporales muy interesantes.

También participé de una sesión facilitada por Alan Cyment, en la que compartió algunas técnicas «from the back» que suele utilizar en sus cursos.

Ya por la tarde participé de una sesión cuyo nombre no recuerdo, pero que trató sobre el impacto que tiene la tecnología en la educación. Bastante polémica e interesante. En cierto modo en la sesión de aula extendida hablamos principalmente sobre el efecto positivo, pero en este caso también tratamos algunos aspectos negativos y cómo lidiar con ellos.

En resumen, me resultó muy enriquecedor.

Workshop de Extreme Programming

Los últimos días he estado ausente porque estuve trabajando en la preparación y el dictado de un workshop de Extreme Programming junto a mi colega @carlospeix.

Como era la primera vez que lo dictábamos, hicimos una invitación cerrada a algunos conocidos y ex-alumnos que gentilmente aceptaron ser nuestros «conejillos de indias».

El workshop salió un poco distinto a como lo habíamos planeado, pero a pesar de eso quedamos muy contentos con el resultado y los alumnos también se manifestaron positivamente.

Estimamos volver a dictarlo hacia mediados/fines de septiembre, pero de forma abierta al público.

xpw

Sobre las pruebas de integración

Continuando con el tema pruebas, es hora de hablar de las pruebas no-unitarias.

Pruebas de integración de componentes

Estas pruebas buscan probar componentes en forma NO aislada. Pero no son necesariamente pruebas de usuario. Hay ciertos casos donde es muy costoso aislar un componente para su prueba o que incluso, puede que no tengas sentido ese aislamiento pues la parte crítica radica justamente en la integración.

Un caso donde estas pruebas tiene sentido es cuando tengo que testar la funcionalidad de búsqueda de mi capa de acceso a datos. Si bien puede que tenga un ORM, puntualmente para las cuestiones de búsqueda «avanza» puede que el ORM termine bastante acoplado a la base.
Estas pruebas también suelen usarse para testear la aplicación desde los controller hasta la base, pasando por alto las vistas (que suelen ser muy frágiles/cambiantes/difíciles de testear)
Estas pruebas suelen codearse usando una herramienta de prueba unitaria, aunque conceptualmente no son unitarias.

Pruebas de aceptación funcionales (o aceptación de stories)

Son las pruebas que definirán si hemos completado o no una story dada. Son naturalmente pruebas de integración, ya que no prueban un componente aislado sino también la interacción de varios componentes (son no-unitarias).

Estas pruebas sí son de la incumbencia del usuario, por eso es que intentamos hacerlas con alguna herramienta que le resulte cómoda al usuario (que en general no es una persona técnica).

En nuestro caso usaremos Cucumber. Cuando hacemos BDD estamos haciendo este tipo de pruebas.

Nuestro foco con estas pruebas es asegurarnos que entendimos bien la story y que el código que escribimos hace lo que tiene que hacer. Como consecuencia de esto no debería ser relevante donde ejecuto las pruebas. O sea, no es necesario instalar la aplicación en un ambiente particular para ejecutar estas pruebas. Al mismo tiempo, podría en algunos casos escribir steps de cucumber que manipulen directamente los objetos de mi modelo.

Pruebas de aceptación del sistema

Estas pruebas son similares a la anteriores, pero adicionalmente también queremos asegurarnos que la aplicación fue correctamente configurada y que todo su ecosistema está perfectamente funcional. Esto implica que sí es relevante el lugar donde pruebo la aplicación. Debería ser un ambiente similar al de producción.

Aquí ya no estamos hablando de hacer BDD. Respecto de las herramientas, puedo usar un robot tipo Selenium o VSTest o incluso Rspec. Es más, mucha gente hace estas pruebas en forma manual.

También puedo utilizar cucumber, pero con algunas restricciones:

  • Seguramente me interese utilizar un driver de cucumber que levante el navegador
  • No podré manipular objetos del modelo en mis steps de cucumber.

Muchas veces estas pruebas se hacen en forma manual. El equipo termina el desarrollo, instala la app en un ambiente de test y un equipo de testers ejecutar pruebas a modo «caja» negra.

Continuará….