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!

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

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.

Testers, el Sombrero Negro y los riesgos

Varias veces en mi carrera he tomado el rol de tester, ya sea como miembro de equipo o como consultor, y con ese rol me ha tocado participar en reuniones en las que se analizaban las estrategias de pruebas y la relación con los riesgos.

En algunas de las reuniones en las que participé sentí que mis preguntas y comentarios generaban incomodidad, incredulidad o incluso enojo. De alguna manera, la forma en que estaba planteada la reunión o la forma en la que yo participaba de la misma, no facilitaban la exploración de ideas o caminos alternativos.

Origen de la incomodidad

En mi última retrospectiva personal (hansei) estuve pensando en el origen de esta situación, y que podría hacer para cambiarla la próxima vez que estuviera en esa situación.

Posibles fuentes de incomodidad

• Mezclar en la reunión diferentes momento del proceso creativo que lleva a un plan de prueba:
• La instancia de identificación y exploración de los riesgos 
• La evaluación del impacto y probabilidad de los riesgos
• La ideación de mitigaciones
• La evaluación de riesgos secundarios.
• Percepción de que alguna persona en la reunión está evaluando el trabajo pasado en vez de estar trabajando en los próximos pasos.
• Falta de práctica de los asistentes con técnicas de innovación. Por ejemplo criticando las ideas desde el mismo momento en que se plantean, y no aplicar resonancia (utilizar si... pero, en vez de si... y además).

Mi lista de accionables

• Validar al inicio de la reunión el objetivo, dinámica y agenda. Marcar a lo largo de la reunión donde estamos, y si nos apartamos reevaluar si volvemos a la agenda original o la modificamos.
• Siendo que últimamente participo como consultor, explicitar que tengo poco contexto, y que por favor tomen mis intervenciones como disparadores de ideas.
• Facilitar gráficamente la charla, para ayudar a que todos estemos en la misma página.
• Ser el primero en seguir las recomendaciones: no juzgar las ideas cuando las generamos, construir sobre las ideas de los demás (resonancia), manter en foco en las seleccionadas.

Riesgos secundarios

No todas las reuniones tienen las estructura "generar ideas y luego converger a solución". 
En algunas grupos o reuniones se espera que el experto diga "cómo deben hacer las cosas" y por más que yo crea que sea mejor construir entre todos, debo escuchar lo que se espera de mí, y al menos explicitar la tensión. Muy ligado a Cynefin, sólo sirve buscar "la mejor forma" de hacer las cosas cuando estamos en un contexto Simple (algo de eso en mi post sobre La mejor forma de Probar).
En otros grupos, "no hay tiempo" para analizar las alternativas, debemos pasar directamente a definir la acción. Lo mejor es detectar esto antes de la reunión, hablando con los participantes para entender las expectativas y, como último momento responsable, se puede aclarar en el inicio de la reunión, cuando se plantea la agenda.

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

Ágiles 2013: Desarrollo Ágil en las Universidades de Medellín

RutaN Medellín es una organización de la ciudad de Medellín, en Colombia, que impulsa la innovación y la competividad de la ciudad, tanto empresas, academia y comunidad en general.

A fines del 2012 convocaron a Kleer para organizar un programa para incorporar el Desarrollo Ágil (y en particular Scrum) en el ADN de la ciudad. Para ello se empezó con un programa para empresas (Fase I) en la que participaron 10 empresas de Medellín, durante enero y febrero del 2013.
Luego se realizó la Fase II, durante marzo y abril del 2013, para Universidades e Instituto de enseñanza superior, en los que inicialmente participaron 6 Universidades e Institutos, y luego se agregaron 3 más (gracias a la gestión Carlos Mario Zapata de la Universidad Nacional).

Tuve la suerte de participar en la Fase II, en la que tuvimos el desafío de trabajar con docentes y universidades que ya habían iniciado hacia un año la incorporación de Desarrollo Ágil, junto con otras que recién empezaban.

Junto con María Clara Gómez preparamos la Presentación para Ágiles 2013. María Clara organizó la filmación y edición de los videos que se ven allí. Lamentablemente no pudo participar del evento. Gracias a Pablo Tortorella (fue uno de los ideadores del proyecto junto con Rocío Arango) que me acompaño en la presentación en Ágiles 2013.


Para cerrar, les dejo referencias a actividades que las universidades hicieron luego de este proyecto:
1. Taller de legos de SCRUM  
2. Presentación de principios de SCRUM con facilitación gráfica.

Historia de Ágiles 2008

En la última Ágiles surgió la necesidad de contar la historia, para entender las raíces y construir la visión comunitaria sobre lo ya hecho.
Con esta idea en mente, comienzo lo que espero será la serie completa, desde un punto de vista muy particular (el mío) y esperando que el resto de los participantes en estos eventos puedan aportar. Pido disculpas desde ya por las omisiones que seguramente cometeré.

Empiezo hablando de Ágiles 2008

Inicio

Entre el 2006 y el 2007 se hicieron 4 cursos de CSM en Argentina, 3 de Tobias Mayer organizados por Alan Cyment y uno de Jeff Sutherland organizado por Baufest. Eramos aproximadamente 150 personas que teníamos entrenamiento formal en desarrollo ágil.

Gracias a iniciativa de Tobias nos agrupamos en una lista de correo, que tenía algún movimiento (esa lista, luego de un cambio de nombre, es hoy foro-agiles).

Con la idea de hacer un evento con el cual catalizar la movida en una comunidad, Alan y yo nos reunimos a fines del 2007 consultando a todos los conocidos para ver quien quería participar. Desde las primeras reuniones se sumaron Martín Salias, Juan Ladetto, Pablo Tortorella, Ricardo Colusso, Adrián Eidelman, Emilio Gutter y Alejandra Alfonso (organizadores). Desde temprano Tobias y Matt Gelbwaks fueron mentores y consejeros. 
En oficinas de Microsoft y de Epidata empezamos la organización y las discusiones:

• Alcance geográfico: Buenos Aires, Argentina, América Hispano parlante, Latinoamerica, Iberoamérica.
• Idioma usado en la conferencia: Sólo español, Sólo inglés, alguna combinación de español, inglés, portugués.
• gratuito o pago

 Optamos por:

• Latinoamericano: eramos ambiciosos e inconscientes, pero aún en nuestros ideales, no nos imaginábamos una comunidad que incluyera España y Portugal. Costo de viaje demasiado altos.
• Idioma: combinación de inglés, español y portugués. Solo de inglés parecía extraño. Muchas personas no hablan inglés y quedarían fuera, ya que las posibilidad de hacer traducción simultanea era prohibitivamente cara, y no tenemos población bilingüe. 
• En cuanto a cobrar o no la entrada, se decidió que no entraba en la visión, era algo a definir en cuanto a conveniencia.

Realización

Los principales problemas que enfrentamos fueron falta de estructura administrativa, dificultad para conseguir sede, las restricciones financieras y los compromisos con los speakers.

Estructura administrativa: como grupo de independientes, podíamos emitir comprobantes legales hasta ciertos límites, pero no podíamos descargar gastos, lo que creo costos impositivos grandes para algunos de los organizadores. Además no podíamos pasar por los procesos de compras de los sponsors más grandes. Luego de intentar con otras organizaciones, nos contactamos con SADIO que confió en nosotros y nos ayudó cobrando a los sponsors. Los cursos que se organizaron con los speakers se manejaron con facturas de los organizadores.

Sede: tratamos mucho tiempo en conseguir sede universitaria. En dos casos estaba "segura" y luego se cayeron. La última caída fue en julio, a 3 meses del evento. Finalmente logramos reservar el Bauen, y para esa época teníamos ya dinero de los sponsors. Pero implicó que muchos temas de difusión, confirmación de speakers e inscripciones debieran realizarse en muy poco tiempo.

Restricciones financieras: al no tener sede no podíamos difundir, no había inscripciones, los sponsors eran reticentes a pagar sin saber a menos donde se haría el evento, y el poco dinero que teníamos no lo queríamos gastar sin saber si se necesitaría para la sede. Logramos que algunos sponsors pagaran pasajes de los speakers, que es otro impacto de no tener financiamiento inicial.

Compromisos con speakers: se organizaron cursos para pagar los viajes y que quede algo para los speakers. Eso funcionó, pero agregó complejidad tanto en logística como en cobranzas y pagos.

Resultado del evento

Elección de la próxima sede

Al evento asistieron personas de Sao Paulo, Florianópolis y Porto Alegre. Durante el evento se habló de la siguiente sede, y las candidatas eran Sao Paulo, Florianópolis y Buenos Aires.

Buenos Aires se descartó porque estábamos muy cansados y nadie tomó la posta para organizar. Además, parecía apropiado para un evento latinoamericano que cambiara de país. 

Entre Sao Paulo y Florianópolis, la discusión fue más compleja, ya que no conocíamos a ninguno de los que proponían, y la elección fue por mail. Finalmente elegimos Florianópolis por presentar una propuesta con apoyo del gobierno local. Creo que en ese momento también pesó la preocupación que Sao Paulo fuera abierto en cuanto al objetivo latinoamericano, y no se limitara a un gran evento con alcance principalmentente local. 

La elección llevo un mes de discusión en la lista de los organizadores de Ágiles 2008 y con los candidatos.

La Argentina "perdió" el evento latinoamericano, entonces surgió la idea de un evento nacional anual (que nuevamente requeriría viajes), o una serie de eventos regionales. Considerando lo cansados que quedamos los organizadores argentinos, tomamos la sugerencia de Alan y Xavier Quesada Allué, y empezamos a organizar eventos Open Space, muchos más livianos, bajo la marca Agile Open.

Fue una experiencia enriquecedora que nos permitió conocer a personas de Chile, Brasil, Bolivia, Perú, que luego siguieron participando y organizando eventos. 

Por favor me avisan cualquier corrección que deba hacerse, o dudas que quedan por responder.