Ya no estamos en testing Kansas

Nota: El título hace referencia a "We're not in Kansas anymore", del Mago de OZ.

¿Dónde estamos?

La agilidad surgió como una revolución de una clase oprimida; la de los programadores que lucharon para liberarse de los Project Managers.

Han pasado 15 años desde el Agile Manifesto. La revolución ha cumplido su objetivo. Los programadores lograron ser reconocidos como miembros igual de importantes dentro de los equipos de desarrollo. Pero, ¿Qué pasó con los testers?

En el primer proyecto ágil en el que participó uno de los autores, el grupo estaba cambiando su forma tradicional de desarrollo de software a una dinámica ágil. Era inicialmente un grupo compuesto por tres equipos de programación y uno de testing.

Durante el cambio, algunas personas del equipo de testing se sumaron a los programadores para formar equipos de desarrollo que incorporen la calidad desde el inicio. Pero el cambio no fue completo, los testers se ocuparon en acercarse a los programadores automatizando pruebas. Pero en los últimos dos días de cada sprint, cuando se corrían las pruebas finales (automáticas y manuales) antes de liberar el producto, algunos miembros del equipo no tenían respiro (los testers), mientras otros miembros del equipo se dedicaban a jugar al Counter Strike. Eso sí, con auriculares para no molestar. En este contexto, donde la calidad esperaríamos que fuera interés de todos, las tareas de testing no las toman los programadores.

La historia que contamos muestra una implementación incompleta del enfoque Whole Team o equipo completo. Pero ¿qué pasa si logramos una buena implementación? Si todos los miembros del equipo se ocupan de la calidad, entonces ¿el tester desaparece?

El rol de tester en un equipo ágil

Si definimos lo que somos por lo que hacemos (testeo, por lo tanto soy tester) no sólo nos auto-limitamos en nuestro crecimiento personal sino que además limitamos la capacidad de nuestro equipo para encarar desafíos.  

El equipo debe tener los conocimientos y capacidad para testear, los cuales no necesariamente deben estar centralizados en una persona, sino que pueden ser parte de un rol y ese rol puede estar distribuido en varios miembros del equipo. De esta manera todo el equipo es responsable de la calidad.

El rol de testing ágil tiene algunas diferencias con el testing tradicional. En lugar de una persona exclusivamente preocupada por el detalle, el rol de testing ágil ajusta el nivel de detalle según el análisis que se esté realizando. En lugar de enfocarse en probar el producto, se ocupa en que el producto se construya con calidad.

En el testing ágil además de ser importante probar que hicimos lo que nos pidieron, resulta central considerar las razones y el contexto en el que nos lo pidieron. De esta manera, puede detectarse si estamos logrando el objetivo original, si tenemos la oportunidad de lograr un producto que exceda las expectativas y en general, sí mantenemos la mirada en la visión y los pies en la tierra. Luego, podemos distinguir el grado de importancia de los distintos temas identificados y tomar decisiones considerando esa guía: ¿Qué nos acerca a la visión? ¿Qué nos dificulta avanzar?

En resumen, consideramos que las siguientes características resultan centrales para el rol de testing ágil:

• Comprender la visión de negocio: ¿Que proceso de negocio es el prioritario? ¿Cuáles son los objetivos y sus métricas relevantes que cierta funcionalidad intenta mejorar?
  
• Conocer el proceso de desarrollo: Dentro del rol de testing ágil está trabajar continuamente para que la calidad esté incorporada al proceso de desarrollo. Si detectamos un problema en el ambiente de aceptación, tratemos de agregar un test para que la próxima vez se detecte en el ambiente de desarrollo. Optimizar el proceso muchas veces implica automatizar la prueba de regresión. Y avanzando por este camino, vemos que la calidad desde temprano nos permite más velocidad, como puede verse en Continuous delivery.
• Saber cómo diseñar experimentos: Esto nos sirve para validar hipótesis del negocio (Lean Startup), para probar que estamos haciendo el producto correcto y bueno para nuestros clientes, como para mejorar nuestro proceso de desarrollo. También tenemos hipótesis sobre aspectos que afectan la calidad y hacemos experimentos probando el producto.
• Conocer sobre testing en sí mismo: Es más fácil conseguir capacitación sobre programación o gestión de proyectos que sobre testing. Hay poca bibliografía y poco tiempo dedicado a la mejora del testing (katas, dojos, craftsmanship). Sin embargo hay mucho para aprender: evaluar las dimensiones de variación del sistema, identificar dimensiones válidas para probar, definir si es posible probarlas de forma independiente, etc. También resulta necesario conocer las diferentes heurísticas de prueba, los problemas comunes que dependen de la tecnología usada e identificar el conjunto que es posible probar en cada momento del desarrollo.
• Riesgos: ¿Cuál es nuestra peor pesadilla? ¿Cuáles son las formas en que se puede romper el producto?¿Qué podemos perder, vidas, dinero, clientes? Las respuestas a estas preguntas nos orientan tanto en la definición de alcance de las pruebas como para su priorización. Conociendo los riesgos podemos elegimos cómo manejarlos. Tomar riesgos en forma controlada nos permite ir más lejos más rápido y ser más innovadores, que si quisiéramos evitar todos los riesgos. Ver mi post anterior sobre el tema.

¡Cómo que en la lista no está ...!

Algunas dudas surgen de esta enumeración: ¿qué pasa con la automatización de la prueba, la usabilidad, la seguridad?

En un equipo de desarrollo ágil es bueno que todos se ocupen en aprender sobre programación, testing, usabilidad, seguridad y probablemente otras cosas también. 
Automatizar, automatizar, automatizar: Es el mantra de todos los miembros del equipo. Es parte de lo que llamamos Conocer el proceso de desarrollo. Para ello es útil que todas las personas de equipo puedan escribir scripts al respecto, pero no necesariamente ser todos expertos en herramientas. Como testers, podemos trabajar de a pares con los expertos.
Pero no todos tienen que ser expertos en todo. Nos parece útil, por lo tanto, dejar esos temas en otros roles. Cada persona desarrolla su especialidad, profundizando y participando de comunidades de práctica. Además, aprende de sus compañeros de equipo sobre otras áreas. Entonces una persona que cubre principalmente el rol de testing, puede además conocer sobre programación lo suficiente como para automatizar situaciones normales y pedir ayuda ante problemas técnicos complejos.

¿Pero es tan distinto el testing en ambientes ágiles del testing tradicional?
Una pregunta que naturalmente surge es: ¿Cuáles de estas características no están en el rol tradicional?¿Son exclusivas del rol del testing en un ámbito ágil?

Consideramos que ninguna de las actividades es demasiado novedosa, por lo que podríamos identificar actividades equivalentes en el marco del testing tradicional. Y encontramos dos diferencias: 

No hay en el equipo una persona cuya única tarea sea probar y que concentre toda la prueba necesaria. Sí se encuentra definido un rol, que cubierto por diferentes personas, con distinto grado de involucramiento. Así es posible compartir más tiempo con otros y esto da lugar a más oportunidades de aprender, crear e innovar.

¿Y ahora qué?
Considerando la diversidad de conocimientos necesarios para cubrir de manera completa el rol del testing, es posible identificar quienes son los miembros del equipo más adecuados para cubrir esas necesidades y que ellos se interesen, no sólo por profundizar el conocimiento sobre esos temas, sino además compartirlos con los compañeros de equipo.

Una forma es a través de lecturas. Mi lista personal de libros: Agile Testing, More Agile Testing, Explore It!, How Google Tests Software, The Domain Testing Workbook, Continuous Delivery.

Además, junto con Natty y Ángel realizamos cursos on line de Agile Testing.

Origen del post y agradecimientos

Este post es uno más, dentro de mi búsqueda sobre el testing (ver lo que opinaba en 2009). Entre 2014 y 2015 presenté algunas de estas idea en JAIIO 43, Ágiles 2014 (en Open Space con Juan Diego Vasco Moncada), CAS2014 (ver la presentación más abajo) y Agile 2015.

Gracias a Natty Davidovich (@nattydavidovich), Ángel Nuñez Salazar (@Snahider) y Nico Paez (@inicopaez) por las discusiones, revisiones y aportes a este post y a mi comprensión del testing.

¿Automatizamos las pruebas de regresión?

Trabajo en una aplicación en la que cada vez que mis usuarios piden un cambio, el costo de hacer el cambio es mucho menor que el costo de probar. La aplicación no tiene automatizada la prueba y no es modular.

Esta situación la he escuchado y vivido muchas veces en mi carrera. Ante esa situación, hay varias acciones posibles:

1. Tenemos que hacer de nuevo el sistema, y esta vez lo haremos bien.
2. Redefinamos el sistema para que sea más fácil probar.
3. Automaticemos la prueba.
4. Contratemos más testers.
5. Sigamos sin cambiar durante algún tiempo.

No puedo en este post analizar todas las alternativas, pero voy a seguir una linea de razonamiento posible, asumiendo algunas creencias, básicamente que las prácticas de desarrollo ágil me pueden ayudar en este caso (Más información sobre estrategias en Working Effectively with Legacy Code). 

Entonces, la secuencia de pensamientos sería:

• Me gustaría hacerlo bien, pero no puedo tirarlo y empezar de nuevo, el negocio debe seguir operando y la aplicación se debe seguir adaptando. Entonces, trabajaremos en hacerlo bien, pero en forma incremental. 
• Para redefinir el sistema sin romperlo, y dado que trabajaremos incrementalmente (muchos pequeños cambios) necesitamos pruebas automatizadas, al menos de nivel funcional. Esto permitirá que probemos a bajo costo cada versión del sistema con un nivel aceptable de calidad. No reemplazamos las pruebas manuales, pero al menos distribuimos las pruebas entre dos ciclos: uno automatizado, rápido y frecuente, otro manual, costoso y que corremos antes de liberar versiones.
• Hacer bien la aplicación implica modularizar, tener pruebas automatizadas unitarias y calidad interna. Estas importantes ideas y prácticas no las estoy tratando en este post, pero suelen tener como precondición las pruebas funcionales automatizadas a las que me refierno en este post.

Vemos muchas equipos y empresas que siguen esta linea de pensamiento. Entonces el problema se puede reeplantear.

Quiero automatizar las pruebas de regresión, ¿cómo lo hago?

Quiero automatizar las pruebas de regresión, ¿cómo lo hago? ¿Qué herramientas uso? ¿lo hago con personas del equipo o contrato fuera? ¿cómo cambian los roles, que tenemos que aprender? ¿qué y cuánto tengo que probar para lograr confianza?

La respuesta a estas preguntas: Depende. 

Bien, pero ¿de qué depende?

El equipo ¿tiene cultura de calidad?

Algunos miembros del equipo se ocupan de la calidad, dedican tiempo a pensar como probar y manejar los riesgos. Ya se hacen pruebas, y el problema es como automatizarlas.

¿Cómo es la estructura y cuales son los conocimiento del equipo?

La prueba manual la realiza un grupo externo, o los testers del equipo (hay personas cuyo puesto o posición es Tester), o las pruebas las realizan varias personas que cubren el rol de tester, pero también otros roles (analistas, programadores, diseñadores gráficos).

Los que cumplen rol de tester, ¿tienen conocimientos sobre programación o les interesa adquirirlos?
Funciona el equipo como un Whole Team en el que todos toman responsabilidad sobre el resultado conjunto y no sobre un subconjunto ("yo pruebo, no programo" o viceversa)

¿Cómo es la tecnológicamente la aplicación?

Para disminuir la curva de aprendizaje y mejorar la aceptación de las nuevas herramientas, es conveniente que la tecnología de la prueba automática sea cercana a la utilizada para la aplicación. ¿El equipo trabaja con .Net, Java, Ruby, Python?

Nuestra respuesta

Cada equipo debe explorar qué organización, herramientas y conocimientos les servirán para su caso.

Lo que encontramos desde Kleer (en este caso Nicolás Páez, Juan Gabardini, Carlos Peix), es que solemos repetir, al inicio de las consultoría de estos temas, una mínima nivelación de conocimientos y del abanico de posibilidades en cuanto a prácticas y herramientas, para facilitar a los equipos tomar decisiones. Pensamos que sería útil extraer esto en una serie de talleres cortos (medio día cada uno):

• Taller de pruebas automatizadas: conceptos de prueba automatizada, estrategias y herramientas (lenguajes de scripting, Fitnesse, Cucumber, Selenium)

• Taller de Integración Contínua: conceptos de integración continua y automatización de builds, y herramientas (Jenkins, TeamCity y Travis).

Scrum en Asunción - Paraguay

Hace uno mes (31 de Agosto) hice mi primera visita laboral a Paraguay. 
El Centro de Calidad de Software organizó un curso de "Gestión ágil de proyectos de software", de 16hs, que dimos en dos días (viernes y sábado).
Aprovechando la visita también organizamos, junto con AgilePy lo que creo fue el primer Coding Dojo de Paraguay.

Paso a contar cada actividad, no sin antes agradecer al Centro de Calidad, y en particular a Marcelo De Filippis, por la organización, el empuje y soporte en todo momento y a Cristhian Cardozo que además de dar soporte durante el curso, sacó fotos y se quedó al Dojo para recibir a los asistentes.

Gestión ágil de proyectos de software

En lo que entiendo fue el primer curso abierto de Scrum en Paraguay, asistieron 18 personas, haciendo un gran esfuerzo, ya que lo hicimos un viernes a partir del mediodía, y el sábado. Hacer 16hs de curso en esas condiciones fue cansador, pero terminamos contentos.

Sigo con mi intensión de dar los cursos con soportes visuales en afiches, y ejercitando mi capacidad de transmitir ideas visualmente. Esto fue muy valorado por los asistentes, y genera un efecto ¡WOW!, ya que es muy distinto a lo que están acostumbrados. 

También el uso de técnicas de Training from the Back of the room (ver resumen) hacen el aprendizaje es más divertido y profundo. 

 La asistencia fue variada, lo que enriqueció las discuciones. Había profesores universitarios, personas que trabajan en empresas grandes y chicas, emprendedores, programadores y personas de testing y calidad.
¡Muchas gracias a todos, y espero que volvamos a vernos!

Yoseki Coding Dojo

Este dojo fue claramente inmoral, y hasta diría inhumano. Lo organizamos el sábado, de 19 a 21hs. ¡Había que tener muchas ganas para estar! Doble puntaje para los asistentes :D
Hicimos el kata del Juego de la Vida, con Python. Los asistentes eran programadores de Action Script y PHP, no tenían conocimiento previo de Python, pero no fue un problema. Comentamos TDD, Integración Continua, algunos de los principios de SOLID y mocking.

Pasamos un buen rato, para la próxima, ¡vale traer cerveza!

Como organicé un curso de Scrum de dos días

Les cuento como organicé el último curso de Scrum que dí este lunes y martes en Córdoba. Experimenté con forma de manejar la agenda que funcionó bien.

La evolución de mis cursos, y origen de las ideas

En los últimos 3 años realicé más de 20 entrenamientos de Scrum. Inicialmente eran cursos introductorios de un día, con presentaciones con proyector intercaladas con actividades, como el folleto del spa para perros (similar a Resort brochure), o el ejercicio del nudo.
Luego, gracias a la insistencia de Jorge Ferndández, del Programa de Software del INTI, me animé a dar cursos de Scrum de dos días. En esos cursos tuve oportunidad de ampliar algunos temas, como las estimaciones o los problemas de implementación, que exceden la descripción básica de Scrum, pero que son necesarios para llevar Scrum a la práctica. Las presentaciones pasaron tener más diapositivas, al punto que imprimir todas las diapositivas del curso se volvió engorroso.
¿Por qué no hacer el curso de dos días como el que hice como asistente? Una presentación de medio día, y luego una simulación de día y medio (diseñar un juego que enseñe Scrum). Me encantó, pero no me sentía con capacidad para hacerlo (¡no al menos como lo facilitó Tobias Mayer!)
Por suerte, puede participar como co-entrenador junto con Alan Cyment y en otros cursos y actividades con Tobias y Diana Larsen. De ellos tomé las ganas y ejemplos de armar los cursos con cada vez menos proyector y más pizarrón, rotafolio y actividades.
También tomamos ideas de la experiencia de Fernando Waisman y Natalia Davidovich de organización de un curso cuatrimestral usando Scrum. Lo aplicamos en en la materia en la que participo (junto con Leonardo Fernández, Ezquiel Kahan, e invitados) en la Facultad de Ingeniería.

Este curso, ¿cómo fue?

Un problema de no usar presentaciones es la dificultad de tener contexto sobre que tema estamos dando, cuales ya dimos, cuales faltan.
Por otro lado, busco que la forma de dar el curso sirva como ejemplo de prácticas de Scrum. Esto es bueno ya que es una experiencia compartida con los asistentes.

Presenté en el curso la agenda como un taskbord que representa todo el release plan.

From Curso Scrum en Cordoba

Las columnas son: tema del sprint, ítems planeados, ítems realizados.
Cada ítem tiene un nombre y una estimación de tamaño (T-Shirt size S/M/L).
Los sprint son de medio día, y se estima que un ítem S se realiza en media hora, un ítem M en una hora y un ítem L en dos horas.

En el inicio del curso definimos las reglas (surgieron: uso de celular, horarios de almuerzo, conversaciones simultáneas) y las métricas con las que mediríamos el éxito del curso. Para esto último se usó: brainstorming, agrupamiento por temas y votación. Lo agregamos a nuestro taskboard.
Cuando surgieron consultas, revisámos si correspondia a un tema a tratar en el futuro, en cuyo caso lo agregamos al ítem correspondiente, o al sprint, si no quedaba claro inmediatamente a que ítem correspondia.
El resultado al llegar al primer almuerzo fue este:

From Curso Scrum en Cordoba

Al planear traté que en cada uno de los tres primeros sprint hubiera dos actividades. Esto permitió tener siempre una actividad de inicio del sprint, que sirve para empezar el sprint con energía.
Probé por primera vez la actividad ideada por Carlos Pantelides. Funcionó bien, pero por como la hice (una sola imágen recorriendo entre quince personas), perdió punch. Probablemente debería haber hecho circular simultáneamente dos conjunto de tarjetas.

From Curso Scrum en Cordoba

Al final del primer día hicimos una retrospectiva, en la que se propucieron nuevos ítems. Debido a que no podíamos hacer todos, repasamos el contenido propuesto de cada tema, y se voto cuales sacar (ya que eran menos los que había que sacar que los que quedaban). Entre todos, planificamos el orden del segundo día. Debamos los ítems descartados, por las dudas que nos sobrara el tiempo.

From Curso Scrum en Cordoba

En la mañana del segundo día, la dinámica del curso (consultas) llevaron a incuir algunos ítems que estaban inicialmente planeados para la tarde, por lo que tuvimos que alrerar el orden. El problema fue que la simulación (un ítem de tamaño L) quedó para el final del sprint, y no podíamos dividirlo.

From Curso Scrum en Cordoba

La simulación (el Pajarraco Scrumero, originalmente definido por Alan, y disponible en el blog de Ingrid Astiz) tuvo el éxito que siempre tiene.

!Gracias Hernán por la foto!

Finalmente a la tarde pudimos completar todo lo planificado para el segundo día.

Retrospectiva

En el cierre, hicimos una retrospectiva, que incluyó tres partes:

• Radar del equipo: basandonos en las características seleccionadas al inicio del curso, se votó y llegamos a la conclusión: amplio acuerdo que el contenido es útil (puede ser aplicable en algún lugar), la mayoría cree que puede ser aplicable en la empresa, la mayoría cree que tiene el conocimiento como para iniciar la implementación.


• Histograma de satisfacción con el curso (abajo, en la imágen): todos creen que el curso fue bueno(3) o muy bueno (4).


• Sugerencias de mejora:
  • material adicional disponible antes del curso (el material que hicimos con Ricardo Colusso lo distribuí al final del primer día).
  • Referencias recomendadas para profuncizar los temas (falta bibliografía en el docuemento).
  • Algo de presentaciones no vendría mal: solo use presentación para mostrar fotos de ejemplos de taskboard. Debo pensar como llegar a un equilibrio.
  • Se hacen largas las 8 hs diarias.
  • Tomar un caso de la compañía para mostrar un ejemplo de una histoaria pasando por todos sus estados.
  • La agenda funcionó bien, aunque se podría mejorar indicando qué ítem se está tratando (bandera o nueva columna).

From Curso Scrum en Cordoba

A la gente de BHP (Ernesto Corona, Diego Nicotra y Laura Castro) que organizaron el curso, ¡Gracias!
Gracias también a los locales Flavia, Carla y Eduardo :D.

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).

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).

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ó.

Semana Scrum en Bs As!

Tobias Mayer ya ha venido varias veces a Argentina, y dio 6 cursos de CSM. Alan Cyment es el único CST hispanoparlante, y dio muchos cursos en Argentina. En enero Tobias nos visita en la semana del 25 al 26 y aprovechamos con varios actividades:

Enero 25: Scaling Scrum (gratuito) (x Tobias)
Enero 26: Consultas CSP (gratuito) (Alan y Tobias)
Enero 27: The Spirit of Scrum - (pago *) (x Tobias)

Enero 28: Improvisation for agile teams - (pago *) (facilitado por Alan Cyment, co-facilitado por Tobias)

(*) En ambos casos, cada día cuesta 220 usd + IVA. Tomando ambos curos el costo es 330 usd + IVA - La facturación la realizará Agilar, que organiza estos eventos.

NOTA: inicialmente planificamos un CSM los días 25 y 26. Por el interés en los talleres avanzados, finalmente suspendimos ese CSM. Para los interesados en CSM, en marzo sr hará uno (Alan)

NOTA: Las actividades con Alan son en español, las actividades con Tobias son en inglés.

CSM en Buenos Aires: Tobias Mayer

Tobias Mayer facilitará un curso de Certified ScrumMaster en Buenos Aires, Argentina.

El curso Certified ScrumMaster Training (CSM) consiste en dos días de presentación, charlas grupales y experiencias y ejercicios interactivos diseñados para enseñar efectivamente los principios y prácticaqs de Scrum.

No hay transparencias y los momentos en que Tobias “da clases” se mantienen al mínimo. El valor de Scrum surge de hacerlo, y el curso se focaliza en la acción. Al finalizar el curso, los participantes tendrán la confianza y comprensión para comenzar la incorporación de Scrum en sus organizaciones y ayudar a los equipos de desarrollo a mejorar sus procesos. Al aprobar, cada uno de los participantes recibirá la designación oficial de “Certified ScrumMaster”, un título otorgado por la Scrum Alliance.

Cuándo: 25-26 de enero de 2010
Dónde: Perú 375, 1^er piso (Southworks)
Costo: usd 700 + IVA
Registración: http://tinyurl.com/tobiasBsAsCSM

Este evento es organizado por Agilar Argentina

Taller Tobias Mayer: The Spirit of Scrum: Road to Joy

Tobias Mayer facilitará un taller de un día en Buenos Aires, Argentina. Está orientado a Scrum Masters y agile coaches.

Se explorarán los principios y valores de Scrum. Este taller no se focaliza en las prácticas (se asume que los participantes tienen familiaridad con ellas) y explora Scrum en un nivel más profundo y humano. A través de una serie de juegos, ejercicios interactivos y conversaciones facilitadas, se adquirirá una comprensión más profunda del nuevo esquema de pensamiento requerido para hacer Scrum. Esto no es sobre metodologías o procesos, es sobre divertirse

Cuándo: 28 de enero 2010
Dónde: Perú 375, 1^er piso (Southworks)
Costo: usd 220 + IVA
Registración: http://tinyurl.com/tobiasBsAsWorkshop

Este evento es organizado por Agiles Argentina y Agilar Argentina

Este evento será dado en inglés. Aunque por el tipo de evento no es imprescindible el hablar y entender perfectamente, ya que el resto de los que asistimos podremos dar una mano.

Más información

Río IV: Adm. Proyectos

Los primeros tres días de la semana estuve, por un acuerdo entre el INTI y la Universidad de Río Cuarto, dando un curso sobre Administración de Proyectos de Software.

No conocía la ciudad, y algunas cosas me sorprendieron. Una ciudad de 160 mil habitantes, con una universidad con 22500 personas (20000 alumnos). El peso de la Univ. en la vida de la ciudad es alto!
En las fotos verán algunos edificios que me gustaron. Una ciudad con historia.

Fuimos unas 20 personas. Por supuesto los puntos altos del curso son las actividades. Verán en las fotos la de negociación, que se puede identificar porque siempre hay personas en movimiento. ¡Increíble la energía que se genera!.

El material no lo subo, está en el Campus virtual de la UNRC, pero salvo algunas correcciones, es lo mismo que pueden encontrar aquí.

091123 Rio IV

Un agradecimiento a Jorge Guazzone, y a toda la gente de de la universidad, que me trataron tan bien.

La semana que viene, me tendrán que soportar nuevamente, esta vez con un curso de Scrum.

Visita a Lima - COREIS Lima y más

La semana pasada estuve 4 días en Lima, Perú, gracias a la invitación de los organizadores del 1er COREIS Lima.
Tratando de aprovechar mi estadía, organizamos una serie de actividades, muy interesantes todas. Ver Videos

Charla de Requerimientos y testing en System Support and Services

En la empresa que trabaja Gustavo Quiroz armamos una charla informal sobre requerimientos y las pruebas de los mismos para las personas que trabajan en equipos de desarrollo (hacen desarrollo ágil) y otras personas relacionadas en la compañía. Entiendo que hubo gente de ventas y algunos directivos.
Hicimos dos actividades: la medición del costo de switch y el origami.
En este caso, el experimento que hice fue tener una descripción narrativa del proceso de armado del origami (vs la descripción con imágenes que generalmente uso). Una persona, que había quedado sin par, trató de realizar el origami, y pudo avanzar menos que cualquiera de los otros pares. Traté de describir lo mejor posible el proceso, y me llevó bastante tiempo. Se puede argumentar que no lo hice bien, pero hice lo mejor posible. Creo que el mensaje es válido: es la peor forma (excepto quizás, no tener ninguna guía?).

Curso de Requerimientos (PUCP y Open Edge Technologies)

Nuevamente Gustavo Quiroz, en este caso como socio de Open Edge Technologies y ex-alumno de PUCP, organizó el curso.
El material puede encontrarse aquí.
El primer día (martes) arrancamos algo lento. No estuvo muy interactivo. Creo que en parte fue porque yo estaba cansado, y por otro lado, el aula era grande, y no me di cuenta de pedir a la gente que se juntara, por lo que estaban bastante dispersos. Tratamos sobre los objetivos de negocios, las estrategias para lograrlos, y el lugar de los los requerimientos dentro de esa jerarquía (Objetivos, Estrategias, Requerimientos). También comentamos que hay un continuo entre requerimientos y diseño, y por lo tanto definir que es un requerimiento y que es diseño es hasta cierto punto arbitrario.
Comentamos la representación de requerimientos con Historias de Usuario (User Stories).
El segundo día (miércoles) comentamos Casos de Uso (Use Cases) y los comparamos con las historias de usuario. Finalizamos el curso con una simulación de 90 minutos de un taller de obtención de requerimientos. Creo que esta última parte fue el punto más alto del curso.
Luego, con los comentarios, me di cuenta que todos los presentes ya conocían Casos de Uso, y podría haber obviado la explicación. Lección aprendida: validar los conocimientos, para usar mejor el tiempo.

Almuerzo sobre Ágiles 2010

Raúl Uribe, Gustavo Quiroz y yo, estuvimos comentando (miércoles) sobre alternativas para Ágiles 2010. El grupo local está buscando lugar, y no quieren fijar fecha hasta tenerlo. Parece haber varias alternativas.
Nos da la impresión que no tenemos una figura de keynote speaker Latam. Comentamos de Ricardo Semler, pero sin más información, quizás haya que hacer un año más con personas del norte. Discutimos algunas alternativas adicionales, pero sin llegar a un nombre que nos convenciera completamente a los presentes.
Comentaron la idea de hacer más incapié en la cultura local, con actividades y obsequios. Me parece buena idea (ver comentario en COREIS).
Quedan dudas sobre como lograr la comunicación y organización entre los locales y los remotos. Claramente hacer reuniones con remotos es "más lento", por problemas de coordinación y formas de comunicación menos eficientes. Pero por otro lado, si el grupo local avanza sólo, se pierde la riqueza de ideas, contactos, integración, participación y trabajo de los remotos.
Mucho para hacer en estos temas.

Charla sobre Prueba en Desarrollo Ágil en GESFOR

En la empresa en la que trabaja Raúl Uribe (GESFOR) armamos una charla informal sobre testing. GESFOR es un grupo con presencia en muchos países hispanoparlantes y USA.
Asistieron principalmente gente que trabaja en testing y QA. GESFOR tiene en Perú unas 200 personas y fueron evaluados CMMI nivel 2, apuntan a ser evaluados como CMMI nivel 3.
Este es el material, que extendí informalmente con otro contenido, ya que no tenían mucho conocimiento previo sobre Scrum, Extreme Programming y Desarrollo Ágil.
Agradezco al Raúl y a la gente de GESFOR por la invitación.

Charla sobre Prueba Exploratoria en Agile Perú

Visité a la comunidad Agile Perú, hicimos una charla en instalaciones de la Universidad de Lima.
Presenté las ideas de la Prueba exploratoria y realizamos una práctica, que fue muy interesante.
!Fue la primera vez que lo hacía y no sabía que esperar!
Estuvo muy bueno, varios de los asistentes tuvieron su primer contacto con la Prueba (exploratoria o no) y se detectaron algunos defectos. Los inicié en el camino al lado oscuro de la fuerza :D

Charla sobre Scrum en COREIS

Viernes a la mañana (9:30) luego de 4 días de evento... no el mejor momento para tener asistentes despiertos.
¡Y dónde! Teatro para 500 personas, con escenario elevado y foso para orquesta. Un entorno en el que tengo poca experiencia, por decirlo suavemente.
En ese contexto, tomé algunos riesgos, presenté este material y hice dos actividades: el costo de la multitarea, y el nudo o spaghetti o Tangled Mess.
El primero funcionó bien, salvo un caso que nunca había visto: alguien que afirmó haber hecho más rápido completando el ejercicio con multitareas.
El segundo, pedí voluntarios (tratando de ocultar el pánico que tenía para el caso en que nadie se ofreciera) y rápidamente subieron suficientes personas como para hacer dos rondas de 8, una con un líder que daba órdenes.
Fue muy instructivo:

• El equipo dirigido no llegó a un resultado en el tiempo disponible
• El equipo autodirigido se bloqueó en un momento. Intervine diciendo "traten de probar alternativas, experimenten". Fue suficiente.
• Al finalizar y evaluar, el equipo dirigido le hechó la culpa al lider.
• El equipo autodirigido la pasó notoriamente mejor. Con risas durante todo la actividad.

Resumen de mi estadía

Como siempre que visito Perú, me sorprende las ganas y el trabajo de las personas, y la cordialidad con la que tratan a los visitantes.

¡Muchas gracias!

Semana en Lima

Entre el 10 y el 13 de Noviembre estaré en Lima. Realizaré varias actividades

I COREIS

El viernes 13 presentaré una charla en el Primer Congreso Regional de Estudiantes de Ingeniería de Sistemas e Informática. Pueden acceder al blog del evento
Mi presentación, ¿Qué es Scrum y como implementarlo? será el viernes de 9:30 a 11:30.
Ya me estoy lamentando perderme la mañana del martes, en las que estarán Grady Booch. El resto del contenido parece interesante, y hay un taller del amigo Raúl Uribe el viernes a la tarde, sobre Scrum in Games.

Curso de requerimientos

La gente de Open Edge Technologies y la Pontificia Universidad Católica de Perú y me invitaron a dictar un curso de Requerimientos en Desarrollos de Software Iterativo y Evolutivo.

Comentaremos y haremos ejercicios sobre requerimientos, sin estar restringido al Desarrollo Ágil, sin negar mi actual inclinación.
Será los días 10 y 11 por la tarde.

Visitas

Aprovecharé para hacer visitas a empresas, e intercambiar ideas y experiencias. También espero interactuar con los organizadores locales de Ágiles 2010, que se hará en Lima! (Raul Uribe, Gustavo Quiroz y Gustavo Veliz, entre otros).