−Javier, mira, es que yo tengo un QA [un tester] por cada 40 desarrolladores, no automatizamos prácticamente ningún tipo de prueba, ni unitarias ni nada, no hay tiempo, ni conocimiento, y tenemos muchos errores en producción. Tampoco podemos fichar a más QAs y claro eso de meter un QA en cada equipo “multifuncional” es inviable, no podemos dejar ese tiempo para testing y resulta que las aplicaciones nos petan, entonces Javier la pregunta que yo te hago y por lo que estoy aquí es ¿cuéntame cómo soluciona esto la agilidad?
-Es que eso no lo soluciona ni la agilidad, ni Scrum, ni nada.
-Pues vaya, yo creía que la agilidad solucionaba esos temas, me ha defraudado.
—
−Javier, mira, verás, es que nosotros tenemos unos clientes, uf, es imposible con ellos, eso de que estén con relativa frecuencia en contacto con los desarrolladores, imposible, solo quieren venir a vernos cada 3 o 4 meses, nos cierran requisitos, es un pdf que se firma con centenares de requisitos, y antes de comenzar hay que darles sí o sí un precio cerrado y una temporalidad cerrada, y claro luego todo es un desastre, los tiempos no se cumplen, los requisitos no eran realmente lo que querían, todos son discusiones, pero es imposible, e inviable, de cambiar el modelo de trabajo con el cliente, entonces Javier la pregunta que yo te hago y por lo que estoy aquí es ¿cuéntame cómo soluciona esto la agilidad?-“
-Es que eso no lo soluciona ni la agilidad, ni Scrum, ni nada.
-Pues vaya, yo creía que la agilidad solucionaba esos temas, me ha defraudado.
—
Queridos amigos, más con el aprecio y especial cariño que os tengo, me duele especialmente tener que ser yo el que os lo diga: la magia no existe.
Lo sé, creer en la Magia, en el Agil Magic, en el Agil Magia Borras o el Magic Model de turno, es bonito, nos hace tener una ilusión, evadir nuestros problemas en ella, salir de la desesperación, de la rutina, pensar que hay una varita mágica que puede resolverlo todo… y sin esfuerzo. Pero lo siento, la magia es sólo una ilusión, no existe.
No es cuestión de volver a repetir lo de que “no existen silver bullets” (la historia te va a gustar), ni lo de El crece pelo universal, la dieta milagro, inglés con 10 palabras y el Ágil método repara todo , eso ya lo hemos hablado muchas veces.
Ya si lo sé, lo sé, sé que hay quien vende magia como algo real y has podido caer en el engaño, pero bueno, el pasado no se puede cambiar, trabajemos en el presente y el futuro sin olvidar que no hay mejora sin cambio, que el cambio cuesta y es difícil y que no hay mejora sin esfuerzo, constancia y mucho conocimiento para ir en la dirección correcta.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Para mí el error fundamental es prometer que algo se va a hacer en dos meses porque te están presionando, cuando debes ser muy claro y decir que no, explicar todo el trabajo que tienes que hacer y contar con un espacio extra de tiempo para cubrir las sorpresas, fallos, cambios de última hora, etc.
Si prometes algo con el tiempo justo seguro que te pilla el toro.
Tambien creo que si tienen tantos fallos es porque la plantilla no se preocupa de ir comprobando que todo funciona bien y tirar adelante que así nos tiene 2 meses más contratados resolviendo problemas porque no repasamos lo que vamos haciendo.
Hola Javier,
Bueno, los ejemplos que pones me parecen críticos y espero que no sean reales y no haya por ahí ninguna empresa que tenga un ratio de QA sobre desarrolladores de 1:40 porque esa empresa tendría que comprobar si su CTO está en coma o si trabaja en realidad para la competencia.
Poniéndome en el caso de que las cifras solo son una pequeña exageración para resaltar un concepto especifico, realmente sí que hay una forma de optimizar el proceso de QA en el caso de que el departamento de QA no tenga la capacidad de automatizar o los desarrolladores no puedan o no tengan el conocimiento para crear test unitarios.
Es tan sencillo como invertir que es un verbo que a veces escuece, sobre todo aquí en España, pero el producto es al final lo que va a definir tú marca y no puedes bajo ningún concepto sacarlo al público sin que funcione mínimamente bien.
Invertir en QA y programadores senior que posean el conocimiento que a ti te hace falta y te solucionen el problema. También existe la opción de que tengas gente cualificada que por no haberlo necesitado nunca no tengan ese conocimiento y al menos, en la mayoría de empresas que conozco, se dispone de un fondo anual para formación que se puede aprovechar perfectamente para dotar de ese conocimiento a tu equipo.
Yo soy programador desde hace 10 años y estoy cansado de ver cometer a decenas de empresas estos mismos errores por el afán de intentar rascar mínimamente en la inversión de su producto y es esa precisamente la actitud que se tiene que intentar cambiar.
Al menos, es lo que creo en mi humilde opinión. Saludos.
1:40 de calidad y sus desarrolladores no saben hacer test unitarios? El problema no esta en hacer agile, el problema es otro 🙂
De todas maneras esto es bastante común en pequeñas agencias digitales, que les gusta el «quick and dirty» pero lo barato al final siempre sale caro.
En mi opinión, lo único que le va a solucionar una metodología Agile es la comunicación, los fallos los seguirán teniendo.
hola, estoy leyendo tus post sobre todo para encontrar información para trasformarmame en un tester competente en automatización (soy tester manual), bueno al grano, has escrito varita con B.
Donde puedo encontrar información sobre como cambiar a tester automatización? aprendiendo poco a poco a programar claro.