¿Cómo hacer que los equipos de desarrollo sean más rápidos?
- Haciendo que gasten menos tiempo reparando
- Haciendo que construyan un código mantenible
- Y sobretodo asegurando que construyen aquello que le intereasa a negocio
La teoría nos dice que cuanto antes se descubra el problema más barato será resolverlo, pero qué sucede cuando las metodologías son ágiles y los tiempos de desarrollo se miden en semanas en vez de en meses? ¿Qué sucede cuando compactamos todas esas fases?
Fase 1: ¿está el desarrollo alineado con el negocio?
Un programador tiene que ser un experto técnico, modelar las clases de forma eficiente, construir código fiable, escalable y sin problemas de rendimiento. Ahora bien, un programador difícilmente va a estar orientado a la usabilidad, a comprender los fines del negocio y a interesarse por el resto de elementos del ecosistema del producto.
¿Vamos a esperar a completar un sprint de dos semanas para descubrir que el trabajo de todo el equipo de desarrollo no sirve o no encaja 100% con lo esperado?
--> Un buen validador define y/o corrobora los criterios de aceptación en primera instancia. Para la definición es necesario contar con Producto y denpendiendo de la organización no necesitarmos que intervengan más que en las demos del ciclo. QA tiene además un conocimiento muy práctico del producto y del equipo y va a poder expresarlo en su idioma y conseguir resultados.
Fase 2: ¿está el desarrollo libre de issues críticos?¿están definidos todos los textos como para gestionarlo por traductores?¿Está el flujo normal del programa completo?
Un buen programador seguirá la documentación y la guía de estilo y realizará los tests unitarios y de componente según crea necesario.
Un buen coordinador tras verificar el flujo se pondrá en contacto con los traductores para darles soporte sobre la aplicación y darle el contexto tras haber verificado que se han seguido las guías de estilo. Para conseguir introducir todos los textos críticos antes de que se termine el sprint.
Fase 3: ¿Sigue la UI las guías y políticas definidas por la orgazación?
El programador puede controlar muy bien la tecnología web, por ejemplo, pero no conoce exáctamente el público objetivo de la aplicación completa ni definir la estrategia de testing de productos multilenguajge.
Un buen verificador tendrá en cuenta el público objetivo, si las nuevas traducciones rompen el interfaz gráfico, si la experiencia de usuario es suficientemente buena y si la funcionalidad tiene aún issues graves pendenetes por resolver.
Fase 4: Sacar el nuevo código a producción
Un
programador tras terminar un proyecto ya está empapándose en el siguiente, leyendo especificaciones, etc
Un buen
analista analizará los riesgos del código nuevo junto con el resto de código de la release y realizará el análisis de riesgos. Identificará los casos de prueba críticos que hay que asegurar de forma automática y para asegurar que la funcionalidad no se rompe por nuevos cambios.
Fase 5: Paso a producción
.... Ahí está el papel de
coordinación final: mitigación de los riesgos, mínimo subconjunto de pruebas, orientado a exploratory testing y a la automatización de casos felices.
Mas?
In order to classify a defect, or an incident severity and priority parameters are critical, and are not critical because they are defect and can impact our KPIs :) , but to be effective and more efficient. The noise around the issues that impacts our users but are never fixed, the feeling of our customers that must contact user support to fix their problems continuously are the consequences or a "bad triage" or of the no understanding of these parameters.
