Mis discusiones últimamente han sido, dice María Emilia, un desarrollador dice, pero no está en la historia de usuario. Yo, pero es obvio, y se cabrea. El dev, pero eso es una mejora. Y yo, no, es un bug. El contexto es que sí está especificado en una use story asociada.
Pero igual considero que hay casos en los que es obvio y evitar hacerlo por flojera dice mucho de la calidad de su desarrollo. Por ejemplo, si tienes dos inputs, fecha desde y fecha hasta, y no validas que no se pueda ingresar una fecha hasta anterior a fecha desde, y eso genera errores, pero no lo hiciste porque no está escrito en el criterio de aceptación, permíteme cuestionarte.
¿Qué opináis de esto? Hay muchas opiniones, leeremos ahora algunas opiniones ahí. Los bugs de ahora son features, total. Estoy algo de acuerdo con ella por el tweet que da contexto. Hay cosas que son algo evidentes de hacer. Si no está en la historia de usuario, no se hace. El desarrollador no toma las decisiones de hacerlo.
Este es interesante. Tienes razón. Bueno, hay gente que dice que tienes razón, tienes sentido común, un mínimo criterio. Es trabajo del dev ir más allá de lo que te piden para marcar la diferencia.
No especifico bien sus criterios de aceptación, ¿vale? Yo la funo, anda. El desarrollador debe preguntar. La verdad es que también, ¿verdad? Que podría haber preguntado, ¿no? O sea, si tenía dudas y tal.
Hay que ser agile para este tipo de temas y negociar. Hay que hacer las cosas a prueba de tontos. De acuerdo parcialmente. Son cosas que si están por escrito, sabes que no pasarás por alto.
Pero si el desarrollador está hasta arriba, dice D-Link, hay cosas que puedes pasar por alto aunque sean obvias. Yo estoy algo de acuerdo. Yo tengo que decir que estoy algo de acuerdo porque hay cosas que pueden ser obvias, aunque no estén especificadas.
Pero, claro, lo obvio es subjetivo. Lo obvio es un poco subjetivo. No es tan obvio a veces. Entonces, hay veces que te pueden decir, hombre, es obvio. Y te pueden poner un ejemplo que dices, ah, sí es obvio.
Pero luego no ser tan obvio. No ser tan obvio como crees. Por ejemplo, el tema de las validaciones. El tema de las validaciones es un tema bastante importante y complicado, ¿no?
Si era obvio, escríbelo en la story. Ya. Si no está en la story, no se hace. Muchas cosas las quieren para allá. Pero también tengo que decir, si no la escriban en una story, una cosa que me preocupa es que la gente, que tengamos esta mentalidad de, si no lo hago, o sea, si no está escrito, no lo hago.
¿Sabes? Si no está escrito, no lo hago. Porque eso es mentalidad de inteligencia artificial, ¿eh? Que muchas veces me decís que tenéis miedo que os quite trabajo de inteligencia artificial, pero luego bien que os gusta trabajar como inteligencia artificial, ¿sabes?
No, no. Si no me lo ponen en el prompt, no lo hago. Entonces, ¡ostras! También necesitamos como desarrolladores tener vida, tener criterio, tener autocrítica y aportar también.
Y a veces no hace falta que sea con código, sino que podemos acercarnos y decir, oye, tengo dudas de si hay que validar esto, hay que hacerlo otro.
A lo mejor antes de escribirlo se puede hablar, se puede conversar, ¿no? Para justamente hacer esto. Pero es verdad que yo os recomiendo que lo habléis antes de hacerlo, porque si no luego os pueden decir,
no, no, pero esto no lo queríamos y tal. Y entonces eso es mucho peor. Pero al menos hablarlo y valorarlo y ver si se requiere, hombre, yo creo que sí que puede ser interesante.
Antes de considerar, decir, bueno, como no lo han puesto, no lo hago, ¿no? O sea, yo creo que al menos, pues tener una conversación que muchas veces a los desarrolladores les da un poco de miedo
de tener estas conversaciones con el Product Owner de, oye, no veo claro esto, o te propongo esto, o creo que podríamos hacer la tarea más rápido si hiciéramos esto, ¿sabes?
Este tipo de cosas, yo creo que muchas veces es interesante porque el desarrollador tiene un contexto muy importante del producto.
Así que yo creo que os lo recomiendo. Procedo a dar aportes y me despiden. Joder, pues tío, menuda mierda de empresa. De verdad te digo, ¿eh?
Un desarrollador que te proponga cosas siempre con respeto y que no esté ahí, creo que puede estar súper bien las cosas como son.
Entonces, puedo entender el contexto, pero sí que es verdad que muchas veces me he encontrado, claro, no entiendo, no sé exactamente, no sé si lo explica en algún sitio,
pero aquí Daniela le dice, mi amorcito hermosa, tal vez es tu primer trabajo o algo así, pero nunca se debe asumir nada que no esté escrito
y los requerimientos deben ser lo más específicos posible. Si no está escrito, no se hace, aunque tenga relación con otro y hay cosas obvias.
No, mi reina, nada es obvio. Te quiero mucho. Me encanta porque le ha dado ahí un feedback con mucho amor y cariño, ¿eh?
Yo apoyo al dev, si no está escrito no cuenta, son mejoras. A mí a veces me parece esto del blanco o negro, ¿sabes? Blanco o negro, no.
O sí o no, o sí o no. Y creo que es lo que digo también, oye, no pasa nada que a veces se pueda hablar las cosas, ¿eh?
Que no se pueden hacer. Hay mucho PM que solo hizo un cursito y no saben nada, están ahí solo por la moda.
Bueno, y porque da platita también, ¿eh? Cuando lo haces está bien porque es obvio, pero cuando por la presión del tiempo se te pasa, ya es un problema.
También, para mí sería en ese caso que el dev añadiera a la historia de usuario tareas para no olvidarse.
Bueno, pero eso lo puede hablar con el productor, justamente, ¿no? Le puede comentar que no pasa nada.
Me gusta mucho la frase que dijo Paul Graham. Los mejores trabajos son en los que te recompensan por los clientes que haces felices.
Hombre, sí, sí, total, ¿no? Pero también necesitas saber exactamente lo que necesitas.
Las validaciones de cualquier input van implícitas al desarrollador.
Sí, sí, pero ¿qué pasa con esto?
Sí, pero las validaciones son más complejas a veces de lo que parece.
Las validaciones, esto es muy polémico lo que voy a decir, aunque es un poco técnico, pero yo creo que las validaciones son lógica de negocio.
Y por lo tanto, las validaciones sí que tienen que estar bien especificadas porque seguramente ahora hablamos de validaciones y estamos pensando cosas básicas como,
Hombre, pero como no vas a validar un correo electrónico, sí es obvio. Vale, un correo electrónico.
Pero, ¿y un precio? ¿Un precio? ¿Sabes? Vale, un precio. Hombre, es obvio que no puede poner un precio cero.
Pero es que resulta que sí puedes poner un precio cero si la categoría es no sé qué, no sé cuánto.
O sea, las validaciones son mucho más complejas de lo que pensamos y a veces tiene lógica de negocio porque depende del propio negocio.
No son tan generales como un correo electrónico.
Y por ejemplo aquí, que dice esto de las fechas, que sí, puede parecer bastante obvio.
Por ejemplo, si tienes dos inputs y no validas que no se pueda ingresar una fecha anterior y tal, sí, lo puedes validar.
Pero, el cómo se comporta la validación, eso también puede ser debate.
El hecho de decir, no, es que hay en sitios que cuando tú haces que la fecha posterior sea anterior, se borra automáticamente.
¿Cómo se hace la validación? ¿Es que lo evitas? ¿No se puede hacer nada?
¿O es que si pones la fecha posterior, la modificas, entonces se resetea la anterior?
Entonces ya tiene un poquito más de cómo se tiene que comportar y por lo tanto, si no lo especificas, queda criterio del desarrollador.
Y ahí es donde otra vez empiezan los problemas, ¿sabes?
Entonces, yo creo que a veces sí que puede estar bien el tener esta información.
Por ejemplo, si un proceso es para España, la validación de teléfonos es distinta para Reino Unido.
No es obvio, claro, exacto, sí, sí, sí.
Totalmente, es que ese tipo de cosas a veces tiene problemas.
Y cuando entra la subjetividad, ¿no? Entonces ya empezamos a tener problemas.
Lo que se puede hacer es deshabilitar las fechas que no pueden ser.
Claro, pero eso es una opción.
Al DERT se puede hacer, pero se pueden hacer más cosas.
Y al final, como se pueden hacer más cosas, hay que tener un poco cuidado con esto.
Me ha parecido interesante porque yo creo que muchas veces el problema, la base del problema de esto, muchas veces es la comunicación.
La comunicación de Product Owner, desarrollador, desarrollador Product Owner.
Y es que no hay nada más Agile, y esto lo voy a decir.
Y de hecho, es que no sé dónde he visto un comentario que hablaba de Agile.
De, es que no sé qué, esto es Agile, que no sé qué, no sé cuánto.
Y este es el problema, amigos.
Que todo esto, todo esto es anti-Agile.
Porque fijaos que se está poniendo por delante, ¿veis?
Los procesos y las herramientas por encima de los individuos y las interacciones.
Pues eso, que muchas veces hablamos de Agile, de User Stories, no sé qué, no sé cuánto.
Y me da la sensación, viendo estas cosas, que olvidamos esto, individuos e interacciones sobre procesos y herramientas.
Que tenemos la herramienta, que es el Jira, tenemos ahí el proceso, la User Story, no sé qué, no sé cuánto.
Y luego la gente nos habla entre ella y hace estas cosas.
Me parece que el problema ahí es el clima laboral.
Porque si hay buena onda, se soluciona fácil.
No te creas, ¿eh?
Yo he trabajado en sitios que hay buena onda, pero como al final, pues, va todo sobre el proceso.
Todo va guiado con el proceso, el proceso, el proceso.
Todo es proceso.
Si no está en el proceso, hay gente, y gente que se caía bien, que si no era en una meeting que estaba estipulada, que no sé qué, que no sé cuánto.
Si no había una tarea que estaba hecha así, haciendo esto, entonces, ¿sabes?
No lo seguían.
Y es porque te enfocas tanto en el proceso que ya se te olvida todo lo demás.
¿Ves?
Así que, no sé.
Yo creo que hay que tener un poquito de cuidado con estas cosas.