Reporte de defectos (bugs) en Scrum

Una pregunta muy frecuente en los equipos que están implementando Scrum es si tienen que seguir usando una herramienta de seguimiento de defectos, y si lo uso que deberían registrar en la misma.

Veamos primero la respuesta revolucionaria y después una respuesta evolutiva. 

Y luego el análisis en cuanto al momento en que se detecta.

Nota: en todos los casos que comentamos, la importancia o prioridad de los bugs se debe acordar en el Scrum Team (Dev Team + Product Owner + Scrum Master), teniendo la última palabra el PO basado en el impacto en el negocio.

Revolución: Hay una sola lista de pendientes

El backlog contiene todo lo que hay que construir. No hacemos diferencia entre bug y funcionalidad nueva.

Un bug que provoca que las pruebas automáticas estén en rojo (falla alguna de las pruebas) debe corregirse en el momento o esa funcionalidad debe quitarse (o desactivarse).

Si encontramos un bug durante la prueba exploratoria que es crítico, agregamos una prueba automática que lo evidencie. 

Todo otro bug se considera un cambio a una funcionalidad existente y se prioriza junto con otras funcionalidades.

Evolución (orgánico): Lista de bugs

El Product Owner dispone de varias fuentes: pedidos de los clientes, ideas propias de nueva funcionalidad, y un lista de los bugs que persisten en el producto. Cuando se planifica el sprint, se consideran los bugs más complejos como nuevos requerimientos, y los chicos se agrupan en paquetes de corrección. En ocasiones se define un tiempo fijo que se dedicará a corrección de todos los bugs que se puedan.

Caso bug detectado en una historia que se está desarrollando

• Primera opción, corregirlo dentro del sprint como parte del desarrollo de la historia
• ¿Y qué pasa si no llegamos con todo lo comprometido? 
• Recortar la funcionalidad para que ese bug no sea relevante y agregar una historia con esa funcionalidad recortada. 
• Si es muy grave, quitar la funcionalidad correspondiente y la historia queda sin hacer. Quizás pueda resolverse e el próximo sprint.
• El bug es poco importante como para hacer alguna de las anteriores: si no es importante ahora, ¿cuándo lo será? Podemos registrarlo en una herramienta o tiralo a la basura, si aparece alguien a quien le importe, lo pedirá. Esta última es la forma más realista en el largo plazo. Las listas interminables acumuladas de bugs son un consumo de tiempo y esfuerzo de todo el equipo.

Caso bug detectado luego de liberada una historia

Hay varias alternativas:

• Se maneja como una historia de usuario (si es grande)
• Se agrega a las lista de ideas a revisar en el refinamiento de backlog, tanto para estimar como para evaluar la prioridad. Luego del análisis, se carga en el backlog / lista de bug si se quiere corregir en los próximos sprints, o se descarta.
• Se corrige a medida que aparecen. El equipo debe manejar el impacto en cuanto a cambio de alcance. Por ejemplo: tener un tiempo fijo dedicado en el sprint para corrección de bugs. O poner un límite de bugs abiertos (por ejemplo 10) y se debe detener el desarrollo de nueva funcionalidad hasta tanto se corrijan los bugs que hay en exceso. 

¡Espero este breve recorrido te ayude!

Innovación en Educación: Gente que hace Scrum sin saber que existe Scrum

Como parte de una serie de post que estoy haciendo sobre innovación en educación, voy a tomar el rol de escriba y difusor de lo que comentó Juan José Zapico (juanjzapico  en yahoo com) en un mail personal.
En este caso, es la detección de características de Scrum en la forma en la que se organiza una materia de creación de arte audiovisual.
A partir de acá habla Juan José, con sólo algunos cambios de formato. ¡Gracias por compartir, Juan José!

La charla la di en el Scrum Gathering Bs As 2012 ->  http://sg2012.agiles.org/programa/dia-1/
y en Ágiles 2012  -> http://agiles2012.agiles.org/programa/dia-2/gente-que-hace-scrum-sin-saber-que-existe-scrum/

La charla fue la misma, la segunda vez con el feedback de ya haberla puesto una vez en contacto con la gente, pero básicamente es la misma presentación y los slides son casi iguales.

La experiencia que yo comento tiene que ver con un colectivo docente donde colaboro, en una cátedra de una materia llamada Realización I, en la carrera de cine de la Facultad de Bellas Artes de la Universidad Nacional de La Plata . Ahora no estoy en aula porque estoy terminando mis estudios de informática, pero estoy en contacto permanente con ellos de manera virtual y cada tanto me junto de manera personal.

En mi charla lo que cuento es que he encontrado analogías entre las propuestas de las metodologías ágiles y la forma en la que trabajamos en la cátedra de Realización I de manera intuitiva desde años, una forma de trabajo que ha dado excelentes resultados y es reconocida por el alumnado de la facultad como una experiencia movilizadora. Tengo como objetivo para cuando regrese al aula (seguramente el año próximo) potenciar esas cosas intuitivas con las experiencias que he ido asimilando por el lado de la vinculación con la comunidad ágil.

Si bien los slides sólo son un ayuda memoria de lo que cuento y no suplen la presencia en la charla, creo que hay bastante como para dar una idea de cuáles son mis ideas y los paralelos que he hallado.

Los slides de ambas charlas están en Slideshare:

versión del SG: 
http://www.slideshare.net/JJZapico/gente-que-hace-scrum-sin-saber-que-existe-scrum
versión de Ágiles 2012: 
http://www.slideshare.net/JJZapico/gente-que-hace-scrum-sin-saber-que-existe-scrum-giles-2012

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!

Relación entre la frecuencia de entrega y los procesos

Recientemente vi un video de Kent Beck, Software G Forces: The Effects of Acceleration, comentado por Mary Poppendieck en How Cadence Predicts Process.

Kent analiza como cambian los procesos y buenas prácticas según aumenta la frecuencia de entregas (Anual, Trimestral, Mensual, Semanal, Diaria, Horas). Comenta como algunas prácticas son buenas con cierta frecuencia de entrega y son malas en otras.
Plantea la relevancia de este análisis debido a que, según su percepción, la frecuencia de entrega de los equipos de software tiene a acelerarse.

Mi intensión es hacer un resumen, pero recomiendo ver el video que, aunque dura 90 min, es mucho más rico que este post.

Entregas anuales → trimestrales

Prácticas que se agregan: Test de aceptación automatizados, refactoring, Integración continua
Justificación: No se puede solo reducir los tiempos, hay que cambiar los procesos. No puedo tener un mes de integración y corrección de bug, con una o dos semanas de pruebas manuales para hacer regresiones. Entonces aparece Integración continua, y Pruebas de Aceptación Automatizada. No puedo tener uno o dos meses de diseño, aparece la necesidad de avanzar aún sin tener todo el diseño hecho o cerrado. Estoy seguro que tendré que cambiar el diseño, por lo tanto, tengo la necesidad de refactoring.

Cambios en el negocio: Suscripción.
Justificación: No se pueden vender 4 versiones por año. Necesito bajar el costo de transacción (tanto para la empresa como para los clientes).

Entregas trimestrales → mensuales

Prácticas que se agregan: prueba por parte de los desarrolladores, reuniones diarias, tarjetas en las paredes.
Prácticas que se quitan: Departamente de QA, soporte a múltiples versiones, Documento de diseño, Control de cabios, equipo de análisis, equipo de build.
Justificación: no hay tiempo para el ida y vuelta con un grupo separado de QA. La mayoría del testing y la reducción del defectos deben ser hechos por el mismo grupo, y probablemente por la misma personas (testers en el equipo y pruebas por los programadores), en el plazo de horas, no de días. La comunicación debe ser mucho más rápida, no podemos sincronizarnos y detectar problemas una vez por semana o mensualmente. Tenemos que estar al tanto cada día, solo tenemos 20 días para entregar (reuniones diarias), tenemos que planificar y re-planificar en forma barata y rápida (tarjetas en las paredes, dejar de usar control de cambios formales). No podemos dedicar mucho tiempo para escribir las decisiones detalladas de diseño antes de usarlas (Documentos de diseño).
Al aumenta la cantidad de entregas, el costo de soporte de muchas versiones se vuelve prohibitivo, y debemos mantener una o pocas versiones del producto (soporte de múltiples versiones). Necesitamos iniciar el diseño y el desarrollo, no podemos esperar una fase de análisis o el ida y vuelta en paralelo con un grupo de análisis (mismo problema que con QA).

Cambios en el negocio: Pagar por el uso.
Justificación: la suscripción no nos da suficiente feedback. Con pagar por el uso, sabemos realmente que funcionalidad que estamos desarrollando les interesa a los clientes.

Entregas mensual → semanales

Prácticas que se agregan: migración de datos en vivo, cero defecto, ramas temporarias, dovela clave (keystoning), kanban.
Prácticas que se quitan: equipos de test, migración en un sólo sentido, ramas de release, parches, diseño de usabilidad al inicio, venture capitals
Justificación: para poder cambiar las estructuras de datos en sitios con grandes volúmenes de datos y cantidad de usuarios, se debe hacer procesos de migración en dos o tres fases, de manera de cambiar la estructura sin nunca dejar de dar el servicio (migración de datos en vivo).
Como los tiempos son cortos, algunas funcionalidades se comienzan a agregar sin hacerlas visibles. Solo cuando está todo dispobible, se agrega la última parte (como la dovela clave de un arco de medio punto), y queda dispobible para los usuarios. Siendo que las entregas son tan rápidas, cualquier cambio, por más urgente que sea, puede incluirse en la próxima entrega. Se elimina la necesidad de procesos de emergencia (parches).

Cambios en el negocio: Bootstrap financing.
Justificación: La financiación de Venture Capitals necesita mayor predecibilidad en los planes, e impone restricciones a desarrollo de productos (a esta velocidad).

Entregas semanal → diarias

Prácticas que se agregan: inmunización, A/B testing
Prácticas que se quitan: staging, equipo de operaciones, reuniones diarias.
Justificación: algunos de los releases van a ser malos. Tenemos que tener formas muy sencillas de volver atrás o formas muy rápidas de corregir y continuar. No hay mucho tiempo para discusciones sobre diseño de interfase, se pude simplemente dar las alternativas y ver como lo usan los usuarios (A/B testing). Para hacer entregas rápidas, no podemos pasar por tantos pasos (ambientes) intermedios. Simplemente no hay tiempo para usarlos (staging), lo que se puede hacer es hacer instalaciones en distintos servidores de producción, que se va midiendo y obteniendo feedback. Todo esto lleva a que la operación debe ser parte de la responsabilidad del equipo (equipo de operaciones). La comunicación en el grupo tiene que ser tan continua y rápida, que no tiene mucho sentido para las reuniones diarias.

Mis conclusiones

Esta visión me hizo repensar mis ideas sobre La mejor manera de probar, reinterpretando parte de mis observaciones desde esta nueva perspectiva. La corelación entre ambas visiones es muy fuerte, pero no completa. Es interesante que la visión de Kent está muy asociada a situaciones en las que el software es el componente principal de los productos.

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

Libertad vs estándares

Como parte de la Scrum week @ Bs As, unas 15 personas nos encontramos en las oficinas de Southworks para pensar sobre los problemas y soluciones sobre el Escalamiento en Implementaciones de Scrum (Scaling Scrum). La consigna inicial era hacer una actividad guiada por Tobias, pero lamentablemente no pudo venir, y lo re-definimos como un open space.
Comento una de las sesiones (50 min) que hicimos.

Libertad vs Estándares

Pensamos que los estándar pueden un surgir como una imposición desde fuera del equipo, o como un aprendizaje compartido.
La primera elección debería ser que los estándar sean el resultado de compartir experiencias.
En los casos de imposición, la pregunta es quien impone. Eso nos llevó a hablar sobre quien es el dueño de los estándar (ownership).
En el caso del aprendizaje compartido, la pregunta nos llevó a como compartir el conocimiento.

¿Quién crea y mantienen los estándar? (ownership)

Los personas que están realizando las tareas son las mejor posicionadas para definir estándar sobre como hacer esas tareas. Pero solo lo harán si tienen motivación y liderazgo.
Grupos como las PMO y grupos de Arquitectura suelen ser los que hacen los estándar en muchas empresas. Pero tienen el problema que muchas veces fueron formados con personas que tienen experiencia, pero que luego quedan aislados del día a día de los proyectos. Aún así, sería bueno tener en cuenta toda la experiencia (libros, implementaciones) sobre PMO y grupos de Arquitectura.

Responsabilidad: algunos de los estándar requieren el uso de algún recurso compartido, o sincronización entre equipos. Por ejemplo, los repositorios de fuentes y los ambientes de integración continua. Sin un responsable, se produce una degradación que atenta contra la utilidad del estándar. Tiene que haber una clara responsabilidad. Una persona, un grupo de personas o un equipo.

Disciplina: los estándar deben cumplirse (mientras tenga sentido, ver más abajo). Si el estándar es una restricción auto-impuesta, entonces necesitamos auto-disciplina (auto en este caso es primero individual y luego grupal). Sin auto-disciplina, aparecen los mecanismos para imponer disciplina desde afuera (registros, auditorias) que nos llevan a algo inefectivo.

¿Cómo difundimos los estándar?

No profundizamos mucho en esto. Las formas de comunicación que surgieron son: Wiki y reuniones. Con respecto a las reuniones, el consenso es que debe ir uno o dos miembros de cada equipo. No necesariamente la misma persona, y debe ser la persona que sepa del tema a tratar. Por ejemplo, no tiene sentido que el SM vaya a una reunión sobre estándar de arquitectura. Esta reunión sirve tanto para definir como para comunicar. Luego cada asistente comunica los resultados en cada grupo. Los asistentes pueden ser rotativos, para evitar que surja el “rol de arquitecto”.

¿Qué significa tener un estándar?

Una sugerencia: nos pusimos de acuerdo con una forma de hacer las cosas que nos parece apropiada en muchos de los casos que analizamos. Pero la decisión final sobre aplicar o no es del equipo. Esto está muy ligado con la Disciplina que comentamos antes. Si no hay disciplina, va a haber muchas excepciones. No debería pasar que las excepciones sean comunes, ya que esto indicaría que el estándar no es bueno. Las excepciones son una oportunidad para revisar el estándar, pero no necesitamos un estándar que responda todas las preguntas. Sería demasiado complejo.

La representación del conocimiento actual de equipo extendido: es la forma en que comunicamos las decisiones de arquitectura/diseño, organización, etc. Deben evolucionar a medida que el equipo aprende.

Alineado con los objetivos de la empresa: lo que hacen los equipos debe contribuir a lograr los objetivos de la empresa (*). Mientras se desarrollan y revisan los estándar, es bueno tener esto presente, lo que nos ayuda a traducir los objetivos (alto nivel) con nuestras prácticas (bajo nivel).

En el cierre de esta sesión quedó inconclusa una discusión sobre Scrum y Auto-organización. Hasta donde entiendo: lo que hablamos en la sesión, aplica a Scrum o a cualquier Auto-organización. Implícita está la discusión: Scrum incluye toda forma de auto-organización, o auto-organización incluye toda forma de Scrum, o ninguna de estas.

(*) Mientras escribo este resumen, me encuentro tentado a agregar comentarios propios, no dichos durante la sesion (de la que fui moderador, por lo tanto traté de no participar opinando... mucho). En el caso de los objetivos de la empresa, por ejemplo, sería importante que los principios de Scrum (y/o auto-organización :D) se apliquen a todos los niveles. Por lo tanto, esos objetivos deberían ser un emergente de todos las personas de la organización.

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

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

Intro al testing de software en Rosario

El pasado viernes y sábado di un curso en Rosario, organizado por el Centro de Calidad e Innovación del Polo Tecnológico de Rosario, similar al que había dado hace unos meses en SADIO.
Con Fabián Longhitano estuvimos trabajando para armar el curso, balanceando horario, duración, costo y contenido, hasta lograr un producto que tuvo buena aceptación. Asistieron 26 personas.
¿Cuáles fueron los cambios? Lo más importante desde el punto de vista de contenido es que redujimos la duración a 10 hs, para que sea fuera de horario laboral. Esto implicó muchos cambios al contenido (originalmente el curso es de 16hs)

• Decidí mantener el material (tiene cambios menores con respecto al anterior), para que pueda servir de guía sobre como ampliar los temas.
• Cambié el ejercicio del Pajarraco ya que requiere al menos 90 min. Es una gran pérdida, porque este juego es muy bueno para entender el manejo de requerimientos y aceptación en ambientes ágiles, así como la dinámica de grupo y el desarrollo incrementar.
  
• Sumé el juego de los 99 globos, que también es muy bueno para ver temas de aceptación, y también conceptos de calidad desde el punto de vista de Lean, y tiene la ventaja que puede ser realizado en 30 min (aunque no es una analogía tan buena de Scrum y XP, que tuve que explicarlos, pero no practicarlos).
• Hicimos también el Origami (igual que los 99 globos, lo estuve haciendo últimamente en varios entornos). Usé principal mente para explicar el pair programing y como sirve para que los testers participen en sesiones de TDD.
  

Origami

• Quité la mayoría de los recorridos por herramientas, solamente las nombré y mostré Fitnesse. No hice una mini sesion de TDD con jUnit, ni mostré Findbugs, Hudson, SVN/Tortoise, FIT, Selenium y Marathon como hice en el curso anterior.

Aún no tengo el resultado de las encuestas, pero creo que a la gente le resultó útil.

Veremos como seguimos!

Scrum en el INTI - Sept

Hoy tuvimos el primer día de curso, similar a los anteriores. Sin embargo, algo cambié en la presentación.
Además agregué algunas actividades:

• 99 globos: funcionó bien. Sirvió también para descontracturar un poco a la gente.
  
• Origami: no anduvo bien. Las instrucciones fueron muy difíciles, y no hubo éxitos (origamis armados), por lo que la conclusiones fueron menos obvias.