miércoles, 23 de junio de 2010
Material curso Scrum
lunes, 14 de junio de 2010
Referencias del curso de Scrum
Grupos y sitios
Eventos
Libros y otro material
lunes, 7 de junio de 2010
Notas de facilitación de Open Space
Estuve en la organización y luego facilité el Agile Open Buenos Aires 2010 – ¡Programando!. Voy a comentar algunas cosas que hicimos e ideas sobre mejoras, que quizás puedan servir para otros que quieran organizar eventos similares.
Preparación
Luego del evento anterior en Buenos Aires (Agile Open Buenos Aires 2010 – Calidad), a varios de nosotros nos quedó la idea que hacer eventos más focalizados podría servir para tener conversaciones más interesantes para los más avanzados. Por otro lado, la idea de hacer los eventos más y más livianos en cuanto a la organización me llevó a consultar en uno de mis trabajos, sobre la posibilidad de hacerlo en Exactas.
Poner en marcha en evento fue impresionantemente sencillo:
Hablar con el responsable de la Secretaría de Extensión, Graduados y Bienestar (Diego Quesada-Allue), y gracias a él, con el responsable del comedor de Pabellón II de Ciudad Universitaria. Resultado: el lugar y la comida, resuelto. El único costo, la posibilidad de tener que pagar 100-200$ por uso de más luces.
Crear la página y el formulario de inscripción. Copiando de los eventos anteriores, un trabajo de un hora.
Difundir en la lista agiles-argentina y en la lista interna de Exactas, y acá :)
Crear el grupo de organización. ¡Gracias a los organizadores! Martín Alaimo, Diego Fontdevila, Marcelo Belnicoff y Francisco Tufró.
Con respecto a los sponsors, la duda era si buscar o no. Por un lado, el bar es barato, por lo que no es gran esfuerzo económico para los asistentes. Y entonces, no buscar sponsors simplifica la organización.
Por otro lado, siempre es simpático tener la comida esté paga, y dar lugar para que las empresas que apoyan estos temas logren visibilidad.
Decisión de compromiso, sponsors según la cantidad de inscriptos (un sponsor cada 30 inscriptos) y sólo sponsors que nos hicieran la vida sencilla.
A medida que avanzaban las inscripciones, aparecieron algunos 'problemas' (al menos en mi visión de lo que podría pasar):
Había temáticas dispares, y me imaginaba que ser atomizarían mucho las charlas.
Por otro lado, los temas eran interesantes, pero quizás con poca gente especialista en ellos. La gente ser vería obligada a elegir entre muchas sesiones interesantes para escuchar, aunque quizás no pudiera aportar.
Como respuesta a estas situaciones, propuse un cambio en el formato:
Lightning talks: dedicar un tiempo (55 min) inicialmente a comentar una idea a todos los asistentes
Facilitar la realización de un gran número de sesiones en paralelo, de tamaño y duración variable: la agenda se arma sin indicar cuantas sesiones simultáneas puede haber. Los responsables de las sesiones deben realizar un cartel que deben poner en la mesa en la que están, de esta manera el que se quiere sumar, busca la mesa con el correspondiente cartel.
Reforzar la idea de libertad de tiempos: Las sesiones se planifican cada hora, pero se hace un aviso (cuenco japonés mediante) al cumplirse 45 min. Una señal para la gente que quiere hacer un break. Suena nuevamente el cuenco cuando empieza la siguiente hora, pero nada obliga a la gente que está en una mesa a cortar lo que está haciendo. Las nuevas sesiones sólo tienen que buscar una mesa libre.
Realización
Se lograron alto porcentaje de personas técnicas (más del 50%), y alto porcentaje de personas con experiencia en ágil (más de 50% con más de un año de experiencia).
Asistimos 34 personas. Se mantiene el promedio de aproximadamente el 50% de los inscriptos. Vinieron los amigos Julian Arocena y Esteban Roasio de Tandil y una persona de Córdoba.
Los lightning talks se usaron para presentar ideas de sesión en forma más amplia.
Como hubo menos de 11 propuestas de lightning talks, adelantamos la preparación de la agenda, que terminó relativamente rápido. Había bastante experiencia con Open Space, la gente propuso las sesiones en poco tiempo.
Quedó un tiempo entre apertura y la primera sesión, que se usó como un break y para socializar. Creo que se aprovechó.
La dinámica de las sesiones se apartó de lo que pensaba. Se dieron sesiones generalmente multitudinarias, normalmente había dos sesiones con más de diez personas cada una, y una o dos con menos personas.
Se crearon un par de sesiones nuevas a lo largo del día.
La energía del evento se mantuvo hasta el final, que fue a las 16hs cuando el bar cerró.
Resultados
Una demostración más de la robustez de los Open Space, y de la futilidad de tratar de prever como será el contenido.
Los lightning talks no funcionaron como me imaginaba, pero sirvieron. Muchas de las sesiones fueron habladas, sin usar computadoras, pero era lo que la gente quería. Ocurrieron, de todas formas, los intercambios mostrando ideas y herramientas directamente en la máquinas.
| From 100605 AO Bs As 2010 Programando |
El manejo de sesiones funcionó muy bien para el tipo de espacio en que hicimos esto.
El manejo de sponsors no fue tan transparente como pensábamos. Hay que dedicarle más tiempo.
Nos faltó proactividad para ayudar a que vengan personas de otros lugares del país. Por enfatizar el objetivo “hacer el evento lo más liviano posible”, perdimos la oportunidad de ser buenos anfitriones.
Realmente los eventos de este tipo son fáciles de organizar, pero a la pregunta, cuando es el próximo, no tenemos respuesta. Quizás sea bueno buscar ritmo (¿una vez cada 3 meses?). Y que tan no hacerlo siempre los sábados, para no dejar afuera a los que por diferentes razones no pueden el fin de semana?
Información de contacto y para sumarse a la comunidad
Sitio de la comunidad argentina: www.agiles.org/argentina
Lista de anuncios y organización de eventos: http://tech.groups.yahoo.com/group/agiles-argentina/
Lista de intercambio de experiencias hispanolatinoamericana: http://tech.groups.yahoo.com/group/foro-agiles
Y a mí, Juan Gabardini, me pueden contactar en twitter (jgabardini) o por mail, con el mismo nombre de usuario en computer.org
¡Espero recibir comentarios de los asistentes y verlos en otros eventos!
miércoles, 2 de junio de 2010
Agile Open Buenos Aires 2010 - ¡Programando!
SEGB(*), junto con Ágiles Argentina, organiza este evento orientado a la difusión e intercambio de experiencias sobre metodologías ágiles. En este caso el tema es la faceta más técnica.
Los eventos Agile Open se originan en Bélgica en el 2005 pero se realizan en todo el mundo. El primero en Latinoamérica se realizó en Buenos Aires en marzo del 2009. En el país ya se han realizado 9 eventos, en 7 ciudades (Buenos Aires, Córdoba, Tandil, La Plata, Bahía Blanca, Mar del Plata y Rosario). Agile Open se organizan y realizan usando Open Space Technology.
En este evento en particular el foco será en las prácticas y herramientas que utilizan los equipos que realizan desarrollo ágil de software, por ejemplo Pair Programming, B/TDD, Integración continua, Coding Katas, Coding Dojos, y las distintas herramientas que utilizan los asistentes, como por ejemplo Ruby y Rails, Groovy y Grails, PHPUnit, PHPCodeSniffer, Project Mess Detection, jXMLCoverage, JUnit, Mockito, NoSQL.
Sumate a los más de 60 inscriptos!
Dónde: Bar del Pabellón II – Ciudad Universitaria
Cuándo: 5 de junio, 9:00hs – 16:00hs
Registrate: http://bit.ly/AOBsAsProg (también podes ver las sesiones propuestas)
(*) SEGB: Secretaría de Extensión, Graduados y Bienestar de la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires.
Open Space Technology
Esta forma de organización de eventos permite realizar, con poca preparación previa, eventos de alta calidad en forma auto-organizada. Funciona para reuniones desde 5 personas hasta reuniones de varios miles de personas.
Es particularmente apto para encuentros en los que se deben resolver problemas complejos y en los que los asistentes tienen interés y pasión por tratar. En los Agile Open se utilizan como forma de difundir conocimiento e intercambiar experiencias.
El interés y la pasión se logra por un proceso de autoselección en la registración: una vez definido el Tema de la conferencia, los asistentes a los que les interesa el tema se anotarán, y al ser en un día no laboral, no dependen tanto del interés de las empresas en las que trabajan como en su deseo personal de participar. A su vez, los temas a tratar en cada sesión son propuestos y votados por los asistentes.
La dinámica durante el evento es:
Se explica el formato y sus pocas reglas
Los asistentes proponen sesiones (presentaciones, paneles, workshops, ...)
Votación de sesiones (todos los asistentes votan)
Armado de agenda (se asignan las sesiones votadas a los horarios y aulas)
Se realizan las sesiones.
Cierre
lunes, 3 de mayo de 2010
Curso introducción al testing en SADIO
Dejo disponible el material aquí.
Si usan el material, dos consideraciones:
- Tiene más contenido que el que se puede incluir en dos días. Decidí dejar el material como referencia para los asistentes.
- La idea de "Introducción" es relativa, asumo que no hay duda sobre la necesidad de probar, y asumo que se trata de hacer desarrollo iterativo e incremental. Espero postear más sobre esto en breve.
- Han quedado algunas partes de la presentación en inglés. Espero terminar de pasar a español en el futuro.
lunes, 1 de marzo de 2010
Agile Open Buenos Aires 2010
viernes, 26 de febrero de 2010
jXmlCoverage
La cobertura ayuda a saber lo que no estamos probando. Nos ayuda poco a saber si estamos probando bien lo que estamos probando.
Hay discusión sobre la utilidad de la mediciones de cobertura. Por ejemplo ver el resumen de una discusión sobre el tema, de donde tomo la idea que lo único seguro sobre la cobertura es que nos indica que partes no hemos probado.
Por mi parte, hice un rant sobre el uso del % de cobertura como métrica, sobre todo por parte de personas que aprendieron el concepto sólo como un subproducto de TDD.
Pero si entendemos las características de la cobertura, puede ser una ayuda importante para la actividad de prueba (sea quien sea que haga esa actividad).
Hay muchos tipos de cobertura. Por ejemplo, podemos comprobar si estamos probando que se cumplan los objetivos de negocio, o los requerimientos, si hemos probado todos los riesgos identificados, todo el código o las entradas y salidas del programa.
La cobertura de código es la más común de las métricas de cobertura, quizás porque es la más fácil de medir. Incluso dentro de las cobertura de código, hay muchas posibles coberturas: de clase, de método, de linea, de instrucción, condicionales, de camino, etc.
En toda métrica de cobertura, se define el universo de los puntos posibles, y luego se mide cuantos de estos puntos están siendo cubiertos por algún caso de prueba.
Por ejemplo, en una cobertura de líneas de código, cada línea es un punto. Si esa linea es ejecutada al correr alguna prueba, se dice que ese punto está cubierto.
Se puede tomar el porcentaje de cobertura como la cantidad de puntos cubiertos sobre la cantidad total de puntos.
Pero como dijimos anteriormente, es más valioso conocer los puntos no cubiertos.
La herramienta
La herramienta que estoy por comentar, jXmlCoverage, mide cobertura basada en los XML utilizados por el Sistema bajo Prueba (en inglés, SUT).
En muchos SUT se utiliza XML, como entrada, salida o configuración. Por ejemplos, los Web Service. En estos SUT, se dispone, o se puede crear, un XSD que corresponda al contrato que daebe cumplir los XML correspondientes.
Nos interesa el grado en que nuestras pruebas ejercitan las diferentes posibilidades de valores en los XML, y sobre todo, saber que valores no estamos probando.
Para esto, debemos definir el universo que queremos medir. Lo que hacemos es, para cada elemento definido en el XSD, decidir las particiones de equivalencia que son interesantes tomar. Por ejemplo, para un entero, podrían ser los enteros positivos, el cero, los negativos y un valor fuera de rango. A esto lo llamamos subdominio. Cada subdominio es un punto sobre el que se medirá cobertura.
Pasada la etapa de definición y configuración del universo de prueba, medimos la cobertura.
Para medir la cobertura se toma el conjunto de los XML usados y se evalúan contra los subdominios, contando cuantas veces un subdominio es utilizado (cubierto) por los casos de prueba.
Como resultado, podemos obtener los subdominios que no fueron cubiertos.
Como en todas las mediciones de cobertura, se debe evitar caer en la tentación de considerar un sub-dominio cubierto como un sub-dominio bien probado.