Defectos a Producción, hasta donde se puede estudiar actualmente con las diversas herramientas y metodologías que se usan, llegarán. De hecho, hay «evidencias» irrefutables de «fallos» que han aparecido en producción y que son noticia en medios gráficos, televisivos y digitales, afectando en muchos de los casos, a miles y/o millones de usuarios finales y terminando por ofrecer la empresa afectada, bonificaciones y/o beneficios para subsanar los inconvenientes sucedidos.
Ya sea modelo waterfall o agile, los defectos existen y los fallos se dan.
Ya sean aplicaciones de escritorio, web y para dispositivos móviles, los defectos existen y los fallos se dan.
O sea, seguiremos conviviendo con los defectos y fallos, pero lo importante es «pensarlos» y «tratarlos» inteligentemente para aprender de los «errores» y de «nuestros errores».
A continuación me pareció muy interesante citar parte de un debate que trata el tema ya que del mismo se puede extraer otras ideas:
Consulta principal del debate:
«Imagina que estás en un proyecto Scrum y resulta que en mitad del sprint llegan con bastante frecuencia bugs críticos de producción que el equipo debe corregir en prioridad. Esto hace que miembros del equipo tengan que dejar lo que estaban haciendo, cambiar de contexto y ocuparse de tareas nuevas lo que hace que pierdan en eficacia y sean menos productivos. Tenéis alguna idea de cómo haríais para gestionar esta situación mejor ?»
Comentario 1:
1. Cuando se entregue el código debe estar, dentro de lo posible, libre de bugs. Para ello hay que mejorar la parte técnica del equipo (CI, Tests, Refactorización) y tener una buena Definition of Done.
2. Tener en cuenta que lo que se entrega tiene que tener business value, y si está lleno de flaws probablemente no lo tenga.
3. Ajustar vuestra velocidad real al trabajo que realizáis. Si este sprint realizáis 30 puntos de historia pero el siguiente no llegáis a 10 porque tenéis que arreglar el desbarajuste del primero, vuestra velocidad en el primero no ha sido 30, ha sido 20, sólo que habéis entregado antes sacrificando la calidad.
4. Si los miembros del equipo tiene que cambiar de contexto perdiendo eficacia y siendo menos productivos es porque tienen que lidiar con los errores que no han lidiado antes.
Ahora bien, si lo que tienen que solucionar es bugs de producción de código que no es suyo, entonces eso se llama deuda técnica y tres factores están implicados en su solución: habilidades técnicas, que el equipo tenga ownership del producto y un tiempo que, en mi experiencia va de 3 a 24 meses para resolverla.
Ten en cuenta que puede existir un stakeholder que diga: «Scrum no funciona». Ahí hay que estar fino para decir: «Scrum es disfuncional desde el momento en que no se provee al equipo de responsabilidad para ejecutar sus funciones adecuadamente, es decir, para refactorizar el producto y que sea sólido».
Comentario 2:
Sería importante trabajar en la causa origen de esos bugs para minimizarlos o erradicarlos.
Hay suficientes Tests? los tenéis automatizados?
Las historias de usuario están suficientemente definidas? así como los criterios de aceptación?
Luego también sería importante tratar la «criticidad» de dichos bugs.
Todo es realmente tan importante como para no poder planificarse para el siguiente Sprint?
Por último, si la frecuencia de entrada de bugs es tan alta, siempe puedes reducir tu compromiso planificado (Scrum) y darle mayor amplitud a tu capacidad no planificada (Kanban).
O sea, juega con tus margenes de capacidad usando Scrumban.
Sobretodo, a mi me gustaría medir esa parte no planificada para hacer explícito si las medidas correctoras surgen efecto:
Lead Time de Bugs
El volumen de peticiones/bugs que entran por Sprint.
El volumen de peticiones/bugs que se resuelven por Sprint.
Comentario 3:
* Tener SLA
Los bugs de producción, lo primero es ver que efectivamente son críticos. Es importante clasificar bien su criticidad e intentar ser estrictos con el SLA.
Si el SLA dice que
– crítical: 1 día
– normal: 3 días
– low: 6 días
Ser conscientes que NO todo es crítico ayuda a planificarse y no cambiar de contexto inmediatamente.
– Dejar un horario fijo (de 10 a 12) para resolución de bugs
– Unos días de la semana
– Una sola persona, no todo el equipo
Puede ayudar.
* Respecto a la planificación de capacidad:
La solución fácil es reservar un % del tiempo del sprint para resolución de bugs, y así la velocidad se adecua sola.
Pero esto no lo veo bien, porque puede hacer que el equipo pierda calidad y vea la posibilidad de entregar código con bugs, sabiendo que en el siguiente sprint puede arreglarlo.
Así que me centraría en lo que dijo Jerónimo, mejorar la calidad y no aprender a vivir con bugs.
Comentario 4:
A nivel de SLA podriamos aclarar que
– Critical – Site down or with a very important feature down: Login error, send message
– High – A very important feature with errors: I can’t follow new people
– Normal – A middle feature with errors: I can’t send notifications by email, I can’t change my profile photo
– Low – Some minor error: bad messages translations
Comentario 5:
En mi opinión, lo primero sería clasificar un poco el trabajo y esto afecta tanto a problemas/bugs como a cambios de prioridad, en plan: cosas que no pueden esperar y hay que parar para hacerlas ya, cosas que pueden esperar a que acabemos la tarea que tenemos a medias (no sprint), y cosas que pueden esperar un poco más, al siguiente sprint.
Si tienes un contrato con un tercero o crees que es bueno, igual un SLA te vendría bien, con sus tiempos de respuesta y tal. Es decir, Sev 1: system is down 1h, Sev 2: afecta a los clientes/usuarios 4h, Sev 3: afecta a mi empresa (comerciales?) 1d, Sev 4: resto, posiblemente priorizable en el backlog.
En un entorno kanban, probablemente, lo puedas hacer de otra manera, todo al backlog y service classes o con colas con prioridad… Pero eso ya es otra historia.
Dicho esto, antes de hacer ningún cambio, si en un sprint *entran* muchos imprevistos y NO sois capaces de terminar con garantías o con los objetivos o lo que sea, es el momento de reflexionar. Sí, no hay receta mágica, el camino es la retrospectiva, analizar las causas, que pueden ser múltiples y variopintas y actuar.
Aún estando deacuerdo con que la calidad es irrenunciable, como siempre, las recetas no son buenas y, EMHO, preferiría que el equipo tomase la decisión de qué necesita: formación, apoyo, incorporar herramientas de CI, recategorizar la *severity* porque no tenga sentido, contratar gente porque tienen demasiada carga y el negocio más demanda… En fin, hacer algo. No todos los problemas son por mala calidad del código 🙂
Mi único tip: asegurarte como SM que el equipo no tira balones fuera y toma responsabilidad.
Comentario 6:
Como complemento de todo lo anterior, si el equipo se ve desbordado por la gestión de bugs también podéis plantearos sacrificar a un miembro del equipo para que gestione lo máximo posible de estos bugs de manera que el resto del equipo pueda aislarse y trabajar en nueva funcionalidad, o trabajar arreglando bugs con las mínimas interferencias externas.
Comentario 7:
yo he probado este escenario a propuesta del equipo y haciéndolo rotativo para no crear la división «Product Team» y «Bug Team» pero la desaconsejo totalmente.
Esta «solución» no elimina el problema de raíz que ya se ha comentado, el equipo no puede permitirse entregar producto con Bugs, y poner ese equipo o persona responsable de resolver Bugs al final de la cadena es una red de seguridad ficticia a la vez que waterfallera. Es lo mismo que colocar un equipo de Testers tras el equipo de Desarrollo. PELIGROSO!!!
Anyway, cada equipo, empresa y proyecto es un mundo aparte por lo que siempre me reservo nuestra mejor respuesta: Depende!
Comentario 7:
Sea cual sea la propuesta entiendo que nadie debería perder los nervios ante la entrada de una petición crítica.
En cualquier caso mi propuesta es mantener el equipo con el objetivo común de entrega de valor = producto sin bugs!
Eso no quita que haya alguien en el equipo que sea quien realice un primer análisis de la petición para determinar criticidad/severidad y si se tiene de la info necesaria para reproducirlo y resolverlo.
Sobre el tema scrumban, no acostumbro a utilizar el «ban» para meter historias, sino justo lo contrario, tareas de poco calado, bugs, etc.
Las historias se proponen para el siguiente sprint ya que es preferible haber tenido tiempo para refinarlas adecuadamente y que no sean motivo de mayores males.
Cierto es que cada vez mas los equipos con los que colaboro tienden a sentirse cómodos trabajando con ciclos semanales por lo que las historias «postergadas» al siguiente sprint lo hacen sólo durante unos pocos días.
Comentario 8:
En mi opinión:
se debería trabajar orientado a cero bugs; ahora bien, la realidad es que siempre aparecen algunos bugs. En nuestro caso, la mayoría de las veces se debe a falta de pruebas exploratorias (sí pasamos UAT) y a ‘roturas por integración’ con otras funcionalidades.
tras oíros, me sumo a la reflexión de que no es bueno un ‘bug/test team’, porque invita a los desarrolladores a bajar la guardia
es bueno que los desarrolladores dediquen tiempo dentro del sprint a asegurar la calidad de las funcionalidades/user stories entregadas; en corto parece que vas más lento, pero a la larga lo recuperas con creces
si aparecen ‘pequeños’ bugs en funcionalidades en las que estás trabajando o has trabajado hace poco (2 sprints vista), tratamos de resolverlos en el sprint (te arriesgas a no cumplir alcance pero refuerzas la calidad de lo ya entregado); si se detectan bugs de otras funcionalidades que no sean críticos, se planifican para próximos sprints; si se detectan bugs que afectan a varias funcionalidades o que pueden requerir complejidad en análisis, incertidumbre técnica, mucho refactoring, etc tratamos de planificarlo para próximos sprints para evitar ruido y gran desvío en el sprint en curso
en caso de que tu realidad conlleve un goteo más o menos constante de bugs, es bueno medir el tiempo que se dedica a resolver bugs en cada sprint, y planificar un slot de tiempo a esto, al igual que para tareas de testing e integración; scrum tiene mucho que ver con ‘medir medias’ y ajustar la planificación de capacidad de los sprints a estas medias
por último, decir que no siempre todo lo que entra son bugs, ni todos son críticos; sobre todo en fase de desarrollo o fases tempranas post-puesta en producción, es habitual que el cliente reporte bugs que en realidad son ampliación de requerimientos o incluso nuevas funcionalidades ‘encubiertas’. (Idealmente esto se resolvería haciendo partícipe al cliente de la definición y validación de user stories y UAT asociadas). Yo recomiendo identificar claramente y pactar con el cliente los criterios de clasificación de bugs (e incluso SLA); los bugs criticos se resuelven en el sprint; otros bugs y mejoras se planifican para futuros sprints en función de su prioridad.
Comentario 9:
Quería comentar al respecto de la práctica que mencionaba Javier (JJG) de sacrificar temporalmente a un miembro del equipo para resolver bugs. Decías que no habías encontrado referencias.
Esta práctica se llama «Batman» y puedes encontrar una referencia en la web de James Shore http://www.jamesshore.com/Agile-Book/iteration_planning.html (es una página larguísima, busca Batman). Comenta que el «Batman» es un término militar usado para describir al soldado que se encarga de las tareas rutinarias para permitir que el resto de la unidad haga el trabajo necesario. Este batman sería el encargado de atender el bat-teléfono y atender cualquier bat-emergencia. Tendría que ser algo rotativo porque será muy pesado, y tiene que ser un práctica a seguir durante un periodo corto de tiempo. La idea es que es un rollazo, y no quieres que te toque así que vamos a hacer todo lo posible para que no haga falta el batman.
Lecciones aprendidas
- Aunque el proyecto vaya mal en tiempo o en costes, nunca hay que recortar el tiempo de pruebas. Nos tenemos que asegurar siempre que el proyecto que entreguemos esté libre de errores, si recortamos en pruebas y además vamos apurados estaremos cometiendo muchos más errores de los habituales.
- Lo más importante que tenemos que probar son los requisitos funcionales que definen el alcance del proyecto. En definitiva, esto es lo que conforma la parte del negocio que fijamos con el cliente y los usuarios como entregable y tiene que satisface sus necesidades.
- No debemos olvidar las pruebas de carga, es la única forma de que probemos al 100% que toda la parte técnica funciona correctamente.
- La gestión de configuraciones y versiones es un apartado fundamental del alcance y la gestión de cambios. No debemos descuidar este apartado ya que nos podrá acarrear problemas a corto/medio plazo.
- Siempre que corrijamos un error debemos volver a testear todo. Es fundamental asegurarnos que no se haya roto nada por otro lado.
- Aunque parezca obvio, nunca hagas pruebas en el entorno de producción. Invierte lo que haga falta en un entorno de pre-producción sólido y lo más parecido posible. Es una inversión que te salvará de muchos apuros y te permitirá asegurar que no habrá diferencias entre las pruebas y cuando se suba definitivamente a producción.
- Es recomendable tener especialistas en testing o un equipo dedicado al QA en tu empresa. Testear no se debe tomar a la ligera ni ser un mero tramite burocrático para declarar la tarea como finalizada. Es fundamental que se haga un trabajo completo probando cada funcionalidad. Si no es posible tener un equipo sólo dedicado a eso, es conveniente que los encargados en ese momento de testear sólo se dediquen a probar y reportar errores.
- Es muy recomendable involucrar a los usuarios claves que han participado en la definición de los requisitos de la aplicación. Mientras se prueba pueden obtenerse un importante feedback de usabilidad.
- Antes de comprar un producto comercial para nuestro proyecto, es importante testearlo.
- Nunca hagas pruebas en producción. Por si no había quedado claro.
Indudablemente, hay mucha «mas tela por cortar» y por tal motivo, lo estaremos tratando en próximos artículos.
Fuentes de inspiración
http://wp.me/ppBOQ-42o
https://groups.google.com/forum/#!topic/agile-spain/QrRMyL3HGQk
http://www.genbetadev.com/trabajar-como-desarrollador/lecciones-aprendidas-del-testing-de-aplicaciones-software
