martes, 15 de abril de 2014

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!

miércoles, 5 de marzo de 2014

Reunión Agile Peru en Lima el 27 de Febrero

Aprovechando mi estadía en Lima, el jueves pasado fui a la reunión mensual de Agile Perú. Nos reunimos en Avantica, que prestaron la sala y proporcionaron bebida.

Se presentaron temas y luego se votó, en un estilo Open Space. Iniciamos unas 15 personas y hubo unas 25 personas en total. Había un par de personas nuevas en agilidad, y personas con mucha experiencia. Se planteó hacer dos tracks, uno introductorio, pero finalmente se unificó en una sola ronda


Hubo tiempo para 4 temas, y podes ver todas las fotos en el album. Además, facilité gráficamente las charlas.

Mejores prácticas de Estimación

¡Sería mejor hablar de buenas prácticas, no de mejores!
Se partió de la pregunta frecuente del tipo: "como hago para estimar agile mejor que como lo hago ahora". Esto lleva a entender que si hacemos lo mismo que antes no podemos mejorar la estimación, y de ahí pasamos a entrega incremental, formatos alternativos de contratos, confianza, negociación win-win,  y alternativas para estimar al inicio de un proyecto con un equipo nuevo.
   

¿Cómo manejar proyectos llave en mano?

Casualmente (o no tanto :D) la conversación derivó naturalmente en el siguiente tema. ¿Cómo manejamos proyectos llave en mano?
A su vez, la pregunta fue cambiando a "cómo convencemos a nuestros clientes que entrega incremental y colaboración es mejor él? 

¡El rol de Product Owner es una gran mentira!

Esta fue una sesión propuesta por mí. Plantee una discusión, en cuanto a la utilidad y aplicabilidad del rol de Product Owner, usando 3 casos en los que creo que no aplica (Organización de conferencias, Pproducto masivo, Open source), y tres hipótesis que no siempre son ciertas (Product Owner como priorizador de necesidades, Capacidad fija del equipo, Software funcionando como medida del éxito).


Técnicas Retrospectivas (Motivar participación)

Un par de personas expusieron la situación del proyecto en el que estaban (distribuido, largo) y nos dieron una excelente oportunidad para hablar sobre las características de las retrospectivas efectivas, como identificarlas y fomentarlas.



Cierre
Por lo que comentaban, fue una buena reunión. La comunidad limeña viene de un año en el que las reuniones giraban en torno a organización de eventos (sobre todo Ágiles 2014, que exigió mucho trabajo). Y ahora disfrutan de las reuniones de intercambio de ideas y experiencias. La organización es super liviana: El lugar y las bebidas ofrecidos por una empresa, las charlas se definen en el momento. 

Les dejo el link al albúm de fotos

lunes, 27 de enero de 2014

Evaluación y autoevaluación docente: ¡Analízame!

Desde el inicio de Kleer, siempre hubo foco en la mejora y la innovación en los productos y servicios que brindamos. 
En particular, la forma en que facilitamos cursos, talleres y otras instancias de proceso enseñanza- aprendizaje está siempre cambiando, exploramos y compartimos entre nosotros tanto lo que funcionó como lo que no.
A lo largo de los últimos 3 años esto a incluido, entre otras cosas:

  • Salirnos del centro del proceso educativo, dando más lugar a la intaracción entre los asistentes 
  • Facilitar y documentar gráficamente
  • Incorporar música
  • Repensar el componente visual (no usar proyector salvo para ver videos, fotos o software que los asistentes usarán en el curso)
  • Incorporar actividades lúdicas
Aunque no tenemos "la manera correcta" de facilitar el aprendizaje, necesitamos continuo feedback. Una fuente de feedback son los alumnos. Otra son otros compañeros docentes, y nosotros mismos.

 Para estos últimos dos casos, escribimos una lista de lo que no gustaría saber sobre cómo hacemos nuestro trabajo. 
La copio más abajo en su versión actual. La mantendremos actualizada en el libro Educación Participativa, que estamos escribiendo con Pablo Tortorella sobre todos estos temas. 


Sugerencia: en cada punto del cuestionario podés usar Perfection Game (ver capitulo 15 de Software for Your Head ).
NO ES: un checklist sobre la experiencia completa del curso, que implica como el asistente se entera,
el material de difusión, la experiencia de registración, facturación y cobro, la logística organización
del lugar, la calidad o cantidad de comida y bebida, etc.

Cuestionario
Previa / precalentamiento
• ¿Tenés claros lo objetivos del training, lo mínimo que tiene que lograr los asistentes? ¿Cómo
esperas que cambien su comportamiento por lo que aprendieron?
• ¿Enviaste información relevante del curso con suficiente anticipación, distinguiendo las
preparaciones necesarias de las adicionales? ¿Tienen para material variado para elegir (leer,
videos, hacer, hablar con otros, investigar)?
• Lo pedido en el precalentamiento, ¿se usó durante el curso?
Bienvenida
• La primera impresión: música, elementos ordenados con atención en lo visual, actividad para
conectarse desde el primer momento.
• Ambiente seguro y cómodo: bebida / comida / lugar de baños / agenda de la actividad /
temperatura / espacio / luz
Durante
• ¿Cuánto tiempo sos el centro de atención (debe ser menos del 25%)?
• ¿Creaste el ámbito para que se enseñen entre ellos?
• Manejaste bien la participación: participaron todos y ninguno acaparó el tiempo, separaste
bien los temas que eran relevantes para este entrenamiento y los que quedan para charla de
break o para información adicional.
• Actividades Grupales:
– ¿Hubo actividades individuales, de a pares o tríos y grupales?
– ¿Variaron los grupos?
– ¿Variaste los medios? Ej.: presentación con proyector, video, storytelling, facilitación
gráfica, lectura, escritura, movimiento corporal, actuar una situación.
• Actividades:
– ¿Las consignas resultaron claras, ayudaste durante las actividades para amplificar las
oportunidades de aprendizaje y para rescatar temas a comentar en la puesta en común?
– ¿Hubo tiempo para la puesta en común?
– ¿Música en actividades de introspección?
• Material de Soporte:
– ¿El material de soporte (Conceptos y workbooks) fueron usados?
– ¿Fueron útiles?
– ¿Los alumnos se los llevaron luego del curso?
• Material Adicional:
– Referiste durante el curso a material adicional para profundizar?
– ¿Lo dejaste registrado en algún lado para enviarlo en el cierre virtual?
• ¿Referiste durante el curso a experiencias propias y de otros? ¿Comentaste cómo esto se
relaciona con actividades comunitarias y de terceros?
• ¿Documentaste (fotos, videos, material adicional) para el cierre?
Breaks y Almuerzos
• ¿Es claro y cumplible el tiempo dedicado al break? En cursos largos, das tiempo para que los
asistentes revisen rápidamente sus mensajes / mails / llamados?
• ¿Estás presente para consultas y socialización?
Cierre y despedida en el lugar
• ¿Tomaron los alumnos compromisos de acción?. Foto grupal. Feedback del curso.
Cierre y despedida virtual
• Resumen fotográfico, referencias y lecturas adicionales, datos contacto o actividades comu-
nitarias, tus próximas actividades. Todo enviado dentro de las 24 horas posteriores al curso.
Contactos luego del curso.