lunes, 8 de noviembre de 2010

VI Jornadas de Software Libre en Junín



El sábado estuve en Junín, invitado por los organizadores, la Rama Estudiantil del IEEE de la UNNOBA. El evento, ya en su sexta edición estuvo muy bueno (lamentablemente solo estuve en una parte del mismo)

Una buena noticia, los videos de las sesiones van a estar disponibles. Además, se difundieron en vivo!

Aún así, va un breve resumen de lo que escuché.

El amigo Andés Riancho presentó una visión de la seguridad en ambientes web de una manera muy entretenida.

Planteó un escenario (acceso pago a Internet en un hotel), y nos mostró como cuatro perfiles de atacantes distintos se comportarían, y en todo loos casos lograría acceso.

El primero, alguien que conoce mucho de sistemas operativos y networking (Charly García)
Usa un CD (BackTrack), una distro basada en Ubuntu, con herramietas de seguridad. Booteando desde el CD se tienen todas las herramientas para el ataque, ya configuradas (listas para usar)
En este caso, el ataque fue tcpdump y luego fakeo de la mac (ifconfig) de algún usuario con acceso.

El segundo, sabe de todo (Sheldon Cooper)
El objetivo es tomar control del servidor que tiene el proxy
- Nmap: info de los puertos abierto
- OpenVas: scanner de vulnerabilidades
- MSF: permite hacer exploits
En el ejemplo se encontro una vulnerabilidad, y se pudo usar un exploit que permite correr comandos en el servidor. Luego hay que trabajar para lograr un usuario de mayor nivel, ya que se entró por un servicio, cuyo usario tenía pocos privilegios.

El tercero sabe mucho seguridad informática (Paris Hilton)
Utiliza la herramienta de la que Andrés es creador (w3af), no encuentra nada obvio inicialmente, pero luego aplica una estrategia de Man in the Middle (MITM proxy provisto por la herramienta), y con eso falsea un post y consigue acceso gratuito.

El cuarto no sabe nada de Internet ni servidores ni seguridad informática (Chaqueño Palavecino)
¡Pero no es ningún tonto! Mira la página, y encuentra un fallo en el procedimiento. ¡Hace que le carguen el costo a otro huesped del hotel!

Esperen el video, un maestro Andrés!, como hacer que una charla de seguridad sea divertida.

Python y las aplicaciones extensibles, por Roberto Alsina

Roberto usó Qt (GUI multiplataforma), como una manera de hacer una aplicación rápidamente, para luego dedicarse a hacerla extensible.

Usó Qt Designer para hacer en 15 min un buscador de twitter (kwrite como editor, creo que lo usó solo para zoomerar)
Luego de tener la aplicación andando, la hizo extensible usando un framework (yapsy) para manejo de plugin. En poco tiempo tuvo una aplicación extensible!. Las extensiones son clases
Python con un método actual (un patrón command) y un pequeño archivo de configuración. Muy elegante.

Juan Pedro Fisanotti y Django

Fisa presentó Django y implemento un sitio sencillo.
Entre algunas de las cosas que resaltó estuvierno:
- Aplicaciones desacopladas (reusables), un plus de Django
- MVC: la forma de programar Web en estos días
- ORM: el mejor amigo del programador que usa datos en DB relacionales
- Plantillas: simplicidad (y posibilidad de no usarlo si uno no quiere!)
- Admin: el argumento de venta de Django, no vuelvas a escribir este código, chabón.


lunes, 1 de noviembre de 2010

¿Existe la “mejor” forma de probar?

¿La prueba manual de software es necesaria? ¿Es suficiente? ¿Y la prueba automatizada?
Es tentador pensar que si estudiamos el problema (prueba de software) lo suficiente y somos buenos profesionales, podremos encontrar “la mejor manera” de hacerlo. Si conocemos “la mejor manera”, los que realizan la prueba de otra manera están equivocados.
Alguna vez pensé conocer cual era “la mejor manera”. Luego, aprendí o cambié de contexto, y “la mejor manera” cambió.
A partir de estas experiencias soy algo escéptico cada vez que escucho (de otros, o de mí!) afirmaciones en este sentido. Esta nueva “mejor manera”, ¿que problemas viejos resuelve? ¿que problemas nuevos crea? ¿en que contexto está siendo usada?
Voy a comentar mi experiencia personal con diferentes formas y contextos de prueba. En cada contexto, analizaré los problemas comunes y cultura, y también si ese contexto es un estado final o sólo un paso hacia otro estado. Este texto se basa en la presentación que realicé en Ágiles 2010 – Lima.
No trato el problema más general de la calidad de software, sino solamente sobre la prueba.
El modelo

La comparación de los contextos está organizada utilizando el modelo de prueba comentado en el libro “Agile testing”, de Lisa Crispin y Janet Gregory, a su vez basado en las propuestas Mike Cohn y Brian Marick. En este modelo, tenemos 4 tipos de prueba (de arriba hacia abajo):
  • Pruebas Manuales
  • Pruebas de Interfase Usuaria (automatizada)
  • Pruebas de Aceptación o API (automatizada)
  • Pruebas técnicas o unitarias y de componentes (automatizada)
El costo de ejecución es menor en las Pruebas técnicas y va creciendo hasta el máximo costo, que es la ejecución de pruebas manuales. El costo de mantenimiento de las pruebas automáticas también es creciente, desde el mínimo en las pruebas técnicas, hasta el máximo en las pruebas de Interfase Usuaria. El mantenimiento de las pruebas manuales es equivalente o menor que el caso de pruebas técnicas automatizadas. En todos los casos, el costo y mantenimiento de las pruebas automatizadas requiere una inversión importante en experiencia e infraestructura. Pero esa inversión se puede llevar en muchos casos de un proyecto a otro. Los costos consideran esa inversión amortizada o distribuida en gran cantidad de pruebas.
La relación entre los costos lleva a sugerir que la forma más eficiente de dedicar esfuerzo tiene la forma de una pirámide, con las pruebas técnicas (unitarias y de componentes) en la base, las de aceptación (o API) luego, y finalmente las pruebas de UI en el vértice de la pirámide.
Contexto: Prueba Ad hoc
Durante los primeros 10 años de mi carrera, trabajé en grupos de 5 personas o menos, trabajando en desarrollo de software en áreas tan variadas como aplicaciones administrativas (ERP), adquisición y procesamiento de imágenes médicas (de medicina nuclear), y sitios de Internet que brindan información bursátil en tiempo real.
En estos equipos, no había separación de roles, todos hacíamos un poco de todo. En particular, las pruebas las hacíamos entre todos, intercambiábamos roles, probando la funcionalidad realizada por otro. La prueba final la hacían los jefes, usuarios o, si existían, las personas de servicio a cliente.
Al no haber responsables definidos la prueba solía quedar huérfana, sin mejora. En este contexto es un problema realizar pruebas de regresión, una tarea poco atractiva y compleja.
La evolución de este contexto suele ser incorporar un tester o área de testing para Prueba Manual (camino tradicional) o que los programadores empiecen a desarrollar Pruebas Técnicas o incluso TDD (camino del desarrollo ágil).
Cualquier camino de evolución pasar por un cambio cultural, ya que en estos grupos la prueba no suele ser valorada lo suficiente. Se suele escuchar “si los programadores hacen bien su trabajo, ¿por qué senecesitaría probar?”
Los problemas se hacen más notorios cuando el grupo debe crecer, tiene mucha rotación o debe mantener muchos productos.
Caso: en una importante compañía de fondos de pensión y seguros de retiro pidieron presupuesto para mantenimiento de muchas aplicaciones existentes (legacy: sin pruebas automatizadas). El cliente no aceptó una propuesta de equipo con cuatro personas, en la que una cumplía el rol de tester; sin embargo, aceptó un equipo de 4 personas con 3 programadores. Internamente el equipo se manejó con uno de los 'programadores' actuando como tester, con buenos resultados.
Motto: ¡No vale la pena probar!
Problemas: baja calidad, baja previsibilidad, regresiones
Cobertura: no hay métricas.

Responsable: todos y ninguno. Pruebas por el usuario.
Organización: generalmente chicas y con poca estructura
Contexto: Prueba Manual
En mi siguiente reencarnación, estuve 8 años en una compañía que trataba de convencer y ayudar a empresas de contexto Ad hoc a que la prueba es algo útil y necesario.
Este cambio cultural es difícil, y con riesgo de involuciones. Por eso se busca separar en un grupo autónomo a los responsables de probar. La separación y la función de probar, que a veces se desvirtúa como prueba de la persona en vez de prueba del producto, provoca enfrentamientos y fricciones con los programadores.
El diseño de las pruebas es divertido, pero ejecutarlas una y otra vez es terriblemente aburrido, lo que lleva a que pocas personas quieran quedarse mucho tiempo haciendo esto. Resultado: muchas personas capaces se van a otras áreas, más divertidas (como desarrollo), y por el recambio hay mayoría de novatos en los roles de prueba. Los que se mantienen en el rol suelen ser personas con poca inclinación a lo técnico. Para crecer profesionalmente, los testers se dedican a tareas de QA (procesos) o de Analistas de negocio, que son más valoradas en el mercado.
En este contexto, los problemas son que la prueba de regresión de productos medianos y grandes se hace muy costosa, lo que lleva a ciclos de desarrollo muy largos (para ejecutar pocas veces las pruebas de regresión) o disminución de las pruebas realizadas durante la regresión (lo que lleva a baja calidad).
La salida parece ser la automatización, pero lamentablemente no es una salida fácil, ya que las personas que están en el grupo de prueba no tienen conocimientos técnicos, y la relación con el grupo de programación, que puede aportar el conocimiento técnico, no es la mejor.
En algunos casos se pasa a Prueba Manual Optimizada.
Motto: ¡No vale la pena automatizar las pruebas!
Problemas: costo de ejecución, que a su vez lleva a seleccionar las pruebas, que baja la confianza y lleva a pocos releases
Cobertura: requerimientos, casos de uso
Responsable: Testers / QA.

Organización: testing separado
Prácticas: casos de prueba manuales, checklist
Contexto: Prueba Manual Optimizada
Luego de 6 años en Prueba Manual, reencarné en Prueba Manual Optimizada. Algo bueno habré hecho en mi vida anterior, porque un cliente exigió en un proyecto que automaticemos.
¿Por qué automatizar? Por criticidad del negocio o cuando se logra volumen suficiente en el área de prueba como para justificar la inversión.
¿Cómo hacerlo? Se suele incorporando programadores al grupo de prueba con el rol de Automatizadores de la Prueba.
Con gran esfuerzo se mantiene un conjunto de pruebas automatizadas, que permiten hacer pruebas de regresión en forma rápida, lo que permite mejorar la calidad, confianza y tiempo de respuesta. Pero por otro lado, debido a la separación entre los grupos de programación y los de prueba, es frecuente que cambios realizados en forma inconsulta en el producto rompan las pruebas automatizadas. Ysi sumamos el hecho que estas pruebas suelen ser de caja negra a través de la UI, el costo de mantenimiento de las pruebas automatizadas es alto.
Es una situación extraña, ya que en muchos casos nos damos cuenta que podríamos ser mucho más eficiente si algunas pruebas fueran de caja blanca y las hicieran los programadores, o si los testers pudieran participar en la toma de decisiones sobre cambios al producto. Pero no podemos influir en la forma en que se programa, es otro grupo.
Esta tensión puede resolverse cuando los grupos de programación y prueba empiezan a trabajar juntos y se pasa al contexto Técnico++ o al Nirvana.
Motto: No podemos mejorar la producción del código.
Problemas: mantenimiento de las pruebas
Cobertura: requerimientos, riesgos
Responsable: Testers, Testers automatizadores, QA.
Organización: organizaciones grandes, grupos de homologación separado
Prácticas: pruebas automatizadas de interfase de usuario
Contexto: Prueba Técnicas
Algunos equipos en los que trabajé (entre 2 y 40 desarrolladores) tenían la cultura de calidad incorporada con fuerte influencia de XP, por ejemplo con prácticas de Integración Continua, TDD y Pair programming incorporadas.
En estos equipos la calidad es alta comparada con los contextos de Prueba Manual. Se suele utilizar cobertura de código como métrica relevante. Los problemas que suelen presentarse son: mantener el tiempo total de ejecución de las pruebas bajo (<10 min)
La evolución natural es hacia Pruebas Técnicas++, ya que en este contexto ante los problemas la primera solución que se piensa es agregar pruebas automatizadas.
Caso: en un proyecto Ruby on Rails comenzamos con una funcionalidad de CMS sencillo para seguir luego con funcionalidad más compleja. Se trabajaba con coberturas de código por arriba del 80%. A los dos meses del proyecto, el usuario vuelve a utilizar la funcionalidad de CMS sólo para encontrarla rota, debido a un cambio en las vistas que pasó desapercibida por mucho tiempo. El análisis del problema llevó al equipo a agregar pruebas automatizadas con Cucumber y Selenium (API y UI).
Motto: Sólo vale la pena las pruebas automatizadas
Problemas: usabilidad, cumplimiento de requerimientos y regresiones en cuanto a requerimientos
Cobertura: líneas de código
Responsable: programador
Organización: equipo de programadores
Prácticas: TDD, CI
Contexto: Prueba Técnicas++
Los equipos en este contexto vienen de la Prueba Técnica, agregando prueba de APIs y quizás de UI, o de la Prueba Manual Optimizada, agregando prueba unitaria y quizás de API. En ambos casos, tienen des-balanceada la pirámide de prueba. En el caso de los que vienen desde Prueba Manual Optimizada, puede ocurrir que pierdan la prueba manual o la prueba de UI automatizada, dado que el esfuerzo por incorporar pruebas unitarias es grande, y se detecta duplicación de esfuerzo entre las pruebas existentes (manuales o automáticas a nivel UI).
Luego de lograr el balance en la pruebas automatizadas, el problema remanente son las pruebas de difícil automatización (¡ningún programador las quiere hacer!) y la falta de prueba exploratoria. Esto último puede llevar a productos que son correctos desde el punto de vista funcional y de robustez, pero que no son sobresalientes, ya que no se detectaron puntos a mejorar en forma temprana.
Motto: Sólo vale la pena las pruebas en automatizadas
Problemas: usabilidad, cumplimiento de requerimientos
Cobertura: líneas de código y requerimientos
Responsable: usuario y programador
Organización: equipo de programadores
Prácticas: ATDD, BDD, TDD, CI
Contexto: Nirvana
Aunque no he llegado aún al Nirvana. Pero estoy atento a los reporte de gente que estuvo, como Lisa Crispin.
Estos equipos han incorporado todas las prácticas de XP. Están en continuo aprendizaje sobre como complementar los distintos tipos de pruebas, la automatización a diferentes niveles y la exploración, para lograr la combinación óptima. Están en un equilibrio dinámico, siempre cambiante, atentos a cambios en el negocio, la organización, el producto y nuevos desarrollos de prácticas en el equipo y la comunidad. Se preocupan por la cadena de valor completa.
Motto: Optimizamos el todo
Problemas: buscar el balance óptimo
Cobertura: líneas de código y requerimientos, riesgos
Responsable: equipo completo (whole team)
Organización: Lean
Prácticas: ATDD, BDD, TDD, CI
Re-visitando
Las descripciones dadas en cada contexto plantean la visión que tenía de lo 'correcto' cuando estuve en ellos, aunque algunas cosas me hacían ruido. Mirando ahora hacia atrás, tengo una visión distinta, que comento a continuación.
Re-visitando: Nirvana
Hay quienes quieren ir más allá de las prácticas de XP.
Los usuarios se equivocan tanto como los desarrolladores, ¿podemos hacer algo para ayudarlos? Hace 5 años Sebastián Elbaum nos comentaba sobre las pruebas para los usuarios finales. Actualmente Excel indica (subraya) las fórmulas que considera “raras” y co posibles errores del usuario, como el caso de una columna con fórmulas que totalizan filas, excepto en una celda que tiene un valor (no una fórmula).
Soporte a la prueba exploratoria: Brian Marick nos comentaba el año pasado sobre experimentos que estaba haciendo para potenciar el mecanismo de UNDO de una aplicación, de manera de poder volver atrás en una prueba para tomar otro camino en la exploración de la misma.
Re-visitando: Ad hoc
¿Qué pasa cuando la solución implica poco o nada de programación en el sentido estricto, sino más bien configurar soluciones existentes o crear contenido?
Caso: hace un año, poniendo en marcha nuestro primer evento usando Open Space (Agile Open Bs As 2009), teníamos que decidir como hacer la registración de los participantes. Luego de evaluar un par de alternativas, incluyendo desarrollar, decidimos realizar la registración utilizando la funcionalidad de Formularios que brinda Google Docs. Una de las personas se quejó del formulario de registración, la pregunta “¿Le interesaría un evento de dos días?”, tenía sólo alternativas de dos días (dos días de semana, viernes y sábado, sábado y domingo) y era obligatoria. Hasta ahí, entendible. Pero la sugerencia que nos hacia era que deberíamos tener pruebas automatizadas. Probablemente esta persona se imaginaba que eramos un equipo de desarrollo en el contexto de Prueba Manual o Ad hoc, y nos sugería que deberíamos estar en Prueba Manual Optimizada o Técnica. ¡Pero la realidad fue que una sola persona configuró el formulario en media hora! Y el problema no tenía que ver con funcionalidad implementada, sino con la semántica del texto y la consistencia del mismo con el tipo de control utilizando. Este problema semántico pasó desapercibido por los revisores. Automatizar la prueba del formulario no hubiera encontrado el problema, y hubiera sido más costosa que el 'desarrollo'.
En algunas situaciones, la prueba Ad hoc podría ser lo mejor: desarrollo de sitios sencillos usando CMS, creando contenido y configuración.

Re-visitando: Prueba Manual
¿Podemos siempre tener un equipo integrado? ¿Podemos siempre confiar en el equipo?
Homologación de plataformas: cuando debemos proteger una plataforma, como en el caso de Microsoft, Apple o el entorno de producción de un banco, nos interesa validar algunos puntos mínimos, y simplemente no podemos confiar en que el equipo que realizó el producto (en muchos casos un tercero), haya realizado bien su trabajo. Pero por otro lado, aunque automaticemos algunas partes de la prueba (preparación de ambientes, comparaciones de antes y después), hay una buena parte de la prueba que es exploratoria, y que no tiene mucho sentido automatizar, ya que es de única vez.
Alto riesgo: aunque podamos ser un sólo equipo, cuando hay en juego mucho dinero o vidas, queremos redundancia. Podemos pagar pruebas manuales para lograr independencia (dos grupos, con dos técnicas distintas)
Productos que no controlamos, open source o no: cuando construimos sobre otros productos, la ecuación que justifica las pruebas automáticas nos juega una trampa, si el dueño del producto decide cambiar la aplicación, él solo evalúa sus costos, pero puede romper nuestras pruebas automáticas. (ej. en los que trabajé: Outlook y Liferay)
En algunas situaciones, la Prueba Manual podría ser lo mejor, buscando el mejor punto en el continuo que hay entre prueba manual totalmente definida y la prueba exploratoria. También debe considerarse tener ayudas automatizadas.
Re-visitando: Prueba Manual Optimizada
Cuando el producto no es sólo software, puede ser factible automatizar parte de la prueba (correspondiente al software) y realizar el resto en forma manual.
Algunos casos de esta situación podrían ser
  • CMS complejos, en los que no sólo se desarrolla contenido, sino también extensiones o aplicaciones.
  • Productos en los que el software acompaña al texto, y probablemente el texto sea lo más importante, como tutoriales
  • Soluciones que incluyan procesos: probar que los procesos se realicen correctamente (por ejemplo que las personas estén entrenadas y sepan qué hacer) es algo que debe probarse con las mismas personas.

Re-visitando: Prueba Técnica/ Técnica++
No encontré situaciones en las que convenga quedarse en estos contextos, siempre me parecieron pasos hacia el Nirvana. ¡Pero creo que es sólo cuestión de tiempo!
Conclusiones
Las metodologías ágiles han logrado una mejora muy importante en la calidad lograda en los desarrollos. Es tentador aplicar siempre las técnicas y prácticas que han permitido estas mejoras, y es tentador pensar que nuestros problemas se resuelven con más y mejor aplicación de las mismas.
Por otro lado, he escrito críticas a algunas prácticas (como el (ab)uso de métricas de cobertura de código), para luego encontrar que personas a las que respeto encuentran estas críticas inconvenientes, ya que se interpretan como un ataque a las técnicas de automatización de la prueba.
Estos contextos me han ayudado a aclarar las discusiones sobre la conveniencia de la utilización o no de las distintas prácticas. Espero que pueda ayudar a otros. ¿Tu que opinas?

viernes, 30 de julio de 2010

Visita al PILP

Estuve hace unas semanas en el PILP, dando un curso de un día sobre Scrum, como parte de una serie de presentaciones y charlas que estamos haciendo junto con Ricardo Colusso y Carlos Peix.
Pueden ver el resumen de una entrevista que me hicieron. Yo hubiera hecho otro resumen :D














Como siempre me pasa, una de las resultados que más valoro de dar cursos es encontrarme con gente que hace cosas interentes:
  • La gente del PILP está haciendo actividades de difusión de tecnología entre chicos de primaria y secundaria junto con Lego (First Lego League) y Microsoft (Gaming.NET). ¡Muy interesante! Yo había pensado ofrecerles hacer algo de TISP, pero con lo que están haciendo me parece que no es necesario.
  • ¡Usá un telescopio de 40cm! La Universidad de La Punta pone disponible un telescopio para la comunidad de internet, gracias al desarrollo hecho por Moisés Rivas y otras personas del grupo dirigido por Mariano Terranova (Autopista de la Información).

miércoles, 23 de junio de 2010

Material curso Scrum

Material (apenas) actualizado (ppt)

Algunas preguntas interesantes que surgieron hasta ahora:
¿Que necesito saber para ser un buen ScrumMaster?
mmm, difícil. ¿Práctica? parece razonable. ¿Cursos? espero que este ayude en algo, y hay otros (CSM/CSPO/CSD/Retrospectivas/...). ¿Libros? Aparte de los indicados aquí, me parece interesante el nuevo de Lyssa Adkins

¿Hay un checklist para las reglas que puede usar un equipo?
No que conozca. Las reglas las crean los equipos.
Algunas ideas en los libros de Schwaber. Algunas otras en otros libros. Y está la técnica de Pomodoro (y su crítica).


lunes, 14 de junio de 2010

Referencias del curso de Scrum

En los últimos tiempos fui disminuyendo la cantidad de transparencias en los cursos, para dar más lugar a las actividades interactivas y a la adaptación del nivel de detalle según el interés de los asistentes.

En el último curso, me basé completamente en la dinámica que no requiere proyector. En lineas generales me pareció que la dinámica fue buena, pero una pérdida fue que las referencias a libros, sitios y eventos quedaron repartidos a todo lo largo de los dos días de curso.

Trataré de cubrir aquí esa falencia. Si quieren pueden ver la presentación previa del curso.

Grupos y sitios

Foro ágiles: lista de correo de intercambio de ideas y experiencias, preguntas y anuncios de la comunidad hispanoparlante (Latam y España)
Ágiles: uno de los sitios comunitarios de metodologías ágiles en español.
Ágiles Argentina: lista de correo de la comunidad argentina para anuncios locales, organización de eventos
Blog de Juan Gabardini: ¡Este blog! Desarrollo ágil de software, con cierta inclinación hacia el testing
Scrum Development: lista de mails 'oficial' de Scrum.
Scrum Alliance: sitio 'oficial' de Scrum. Por ejemplo tiene la lista de capacitaciones de CSM.
Agile Alliance: sitio 'oficial' sobre el desarrollo ágil. Son los organizadores del mayor evento anual, Agile 20xx.

Eventos

Ágiles 2010 – Oct – Lima: Evento anual de la comunidad latinoamericana sobre metodologías ágiles.
Agile Open Tour: Serie de eventos argentinos realizados con el formato Open Space. Se han hecho 6 durante 2009 y hay planeados 8 eventos en el 2010.

Libros y otro material

Ken Schwaber: Agile Project Management with Scrum / The Enterprise and Scrum
Libros de referencia. El primero con foco en scrum dentro de un equipo, el segundo con la implementación en toda la organización. Ver mis comentarios previos.

Rob Austin y Lee Davin: Artful Making
Una visión novedosa sobre el desarrollo de software y otras actividades (teatro, planificación estratégica), que explica la secuencia desde el trabajo hecho artezanalmente, la producción industrial y la artística, con las motivaciones económicas y implicancias en cuanto a las condiciones necesarias y la forma de trabajo resultante. Ver mis comentarios previos.

Henrik Kniberg: Scrum and XP from the Trenches
Conjunto de experiencias en todos los temas enfrentados al usar Scrum, con referencias a libros y material adicional. Disponible en forma electrónica gratuita y en español.
Mike Cohn: User Stories Applied / Agile Estimating and Planning
Libros de referencia obligada para temas los temas del título. Además Mike tiene muchos recursos disponibles gratuitamente.

Craig Larman: Agile & Iterative Development: A Managers Guide
Buena introdoción a la idea general y sumario de los distintas 'metodologías'. Tiene varios libros interesantes y algunos documentos gratuitos muy interesantes, como Lean Primer

Kent Beck: Extreme Programming Explained: Embrace Change
Uno de los primeros libros sobre Desarrollo Ágil, con contenido relacionado con las pácticas técnicas, que no están cubiertas en los libros mensionados anteriormente.

Mary & Tom Poppendieck: Implementing Lean Software Development
Los conceptos de Lean están atrás de muchas de las buenas prácticas Ágiles. Uno de los tres libros de los Poppendieck (todos recomendables).

David Anderson: Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results / KANBAN, Successful Evolutionary Change For Your Technology Business
En el primer caso, David toma los conceptos de TOC aplicados al Software. El segundo es un libro de próxima publicación (con traducción a español) con la aplicación de Lean que el inició y nombró.


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

Hace un par de semanas realicé una reedición del curso de Introdución al Testing de Software en SADIO (ver curso previo).

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.