 Nuestro próximo oponente es Javier Motos, es Front Lead Engineer desde hace ocho años y es también docente del Master de Desarrollo Full Stack de la Escuela de Negocios y EM. Hoy nos va a presentar una perspectiva sobre la gestión de proyectos para evitar caer en el caos. Se abordarán conceptos clave de la metodología agile de Scrum para gestionar recursos y tiempo de manera más eficaz y eficiente. ¿Habéis pensado alguna vez la fama que tenemos los informáticos? Y no me refiero a la fama que sabemos formatear ordenadores, que sabemos hackear cuentas del banco o incluso que sabemos arreglar algunos electrodomésticos. Me refiero a la fama mala, a la fama de que entregamos los proyectos tarde, entregamos los proyectos mal, entregamos los proyectos con un montón de errores. Me refiero a esa fama. Cuando empecé en esto de la informática, me acuerdo que me lo comentaron, los informáticos tenéis fama de enterar los proyectos tarde. Y dentro de mí pensaba, a mí esto no me va a pasar, a mí esto no me va a pasar. ¿Y sabéis qué? Me pasó. Me pasó, pero ahora ya no me pasa. Y no me pasa porque utilizo metodologías ágiles. Lo primero de todo, quiero dar las gracias a Work on Valencia, IEM y Asector, la empresa donde trabajo, por haberme permitido estar este rato con vosotros. Mi nombre es Javier Motos, como os he dicho, y vamos a hablar hoy un poco sobre metodologías ágiles y vamos a centrarnos en Scrum. Aquí tenemos un pequeño índice, primero vamos a hablar de metodologías ágiles, porque surgen. Vamos a ver un poco la metodología Scrum, y luego vamos a ir a Historias de Suario. Vamos a empezar primero con las metodologías ágiles. ¿Qué son las metodologías ágiles? Son las metodologías que utilizamos para adaptarnos a los cambios. Vamos a imaginarnos que estamos en nuestra oficina y llega un cliente y nos dice, oye, quiero ir a la Plaza del Ayuntamiento, para los que no la conozcáis, es la plaza donde hacen las masquetas. Y quiero ir en coche, y nosotros le decimos, vale, pues vamos a desarrollarte un coche. Empezamos desarrollando el coche, creamos nuestras ruedas, tenemos ahí cuatro ruedas. ¿Para qué nos sirven? Para absolutamente nada. Seguimos desarrollando, ponemos la plataforma, ya tenemos nuestra plataforma contra nuestras cuatro ruedas. ¿Y para qué nos sirve? Para absolutamente nada, porque el cliente no puede ir a la Plaza del Ayuntamiento. Seguimos desarrollando, seis meses de desarrollo, montamos el chasis. ¿Y para qué nos sirve? Para que si llueve, se pueda meter dentro y no se moje, porque para ir al Ayuntamiento aún no nos sirve. Seguimos desarrollando, creamos todos los asientos, el volante, lo tenemos ya todo perfecto, falta de motor, nueve meses de desarrollo, llega al cliente y aún no le sirve para absolutamente nada. Seguimos desarrollando, acabamos el motor, lo metemos, todo funciona de maravilla, se va a la Plaza del Ayuntamiento con su coche y resulta que hay una señal y pone prohibido acceder. ¿Qué ha pasado que la Plaza del Ayuntamiento ha cambiado? Y nosotros no hemos sido capaces en este año de adaptarnos al cambio. ¿Cómo funcionan las metodologías ágiles? Llega el mismo cliente a nuestra oficina y nos dice que quiere ir a la Plaza del Ayuntamiento y que quiere ir en coche. Y nosotros le decimos, ¿vale? Vas a ir en coche. Pero primero vamos a ver cómo vamos a evolucionarlo. Cogemos, hacemos cuatro ruedas, ponemos una tabla y hacemos un monopatín. Llega a nuestro cliente y le decimos, oye, aquí tienes tu monopatín, tu primer coche, pruébalo. Llega al cliente, lo prueba, se va hacia la Plaza del Ayuntamiento y dice, ¿vale? He llegado. Atentos, desde el primer momento estamos entregando algo que aporta valor y encima ha conseguido llegar a la Plaza del Ayuntamiento, pero me cuesta mucho girar. No me gusta cómo gira. Así que nosotros lo evolucionamos, le ponemos un maniard y ya tenemos un patinete, en vez de un monopatín. Lo prueba el cliente y dice, ¡ostra, esto me gusta más! Lo que pasa es que se me hace un poco pesado darle con el pie. Decimos, ¿vale? Perfecto, tenemos tu feedback, vamos a por la siguiente iteración. Hacemos la siguiente iteración y creamos una bicicleta. Le damos la bicicleta al cliente, seguimos aportando el valor, prueba la bicicleta y dice, ¡ostra, esto va mucho mejor! Lo que pasa es que sudo. En Valencia hace mucho cador y llegó a la Plaza del Ayuntamiento subado y no me gusta llegar sudado. Le ponemos un motor y tiene una moto y ya no llega sudado. Aquí pueden ocurrir muchas cosas. Fijaros toda la evolución que hemos tenido. Quizá la moto le sea suficiente para llegar a la Plaza del Ayuntamiento. Quizá nos demos cuenta que la idea de tener un coche no era la correcta y tengamos que pivotar. Estamos trabajando, adaptándonos al cambio y al feedback del cliente. Así es como proponen trabajar las metodologías ágiles. ¿Cómo surgen las metodologías ágiles? Pues surgen en Utah, en Estados Unidos. 17 personas, bastante importantes, desarrolladores, CEOs de empresas y demás, deciden irse a una cabaña en mitad del monte y empiezan a hablar sobre los problemas que tienen a la hora de desarrollar software. Los problemas que hemos hablado al principio, que entregan más los proyectos, que los entregan tarde, que los entregan con errores y deciden firmar el Manifesto Ayay. En el Manifesto Ayay hablan sobre cuatro valores y doce principios, que vamos a ver a continuación. Primero valor, procesos y herramientas son menos importantes que las personas. No nos sirve de nada tener procesos hipercomplejos si no se adaptan a las personas que tenemos. No sé si está claro. Segundo punto, documentación extensiva. ¿Para qué sirve? Para absolutamente nada. Para tener la metida en el drive o para tener la impresa y poder pintar, pero no sirve para nada. Queremos tener desde el principio un producto funcionando, un producto que se pueda tocar, que el cliente lo pueda ver, que pueda tener feedback. Tercer valor, colaboración con el cliente. No podemos sentarnos el primer día y firmar un contrato, que indique todo lo que va a tener el software, porque es imposible. Eso no va a ningún sitio. Tenemos que colaborar con él, negociar con él, que esté en el proceso de desarrollo, que esté en el proceso de decisiones. Y el cuarto valor, respuesta al cambio. Para mí el más importante. Tenemos que ser capaces de adaptarnos al cambio, ver las necesidades, ver cómo evoluciona el mercado y nosotros cambiar. Bien sea al principio o al final, sea cuando sea. Luego tenemos los 12 principios, que aquí no quiero leeros los 12 principios, porque no tiene mucho sentido, pero al final se resumen en lo siguiente. Lo primero es, tenemos que aportar valor al cliente desde el primer momento. Queremos tener confianza con el cliente y el cliente con nosotros. Y queremos tener mucha comunicación entre todos. Estos son los principios muy resumidos de AII. AII, hay muchas metodologías que siguen AII. Está SCRAM, está CAMBAN, hay muchas XP, hay muchas. Nosotros vamos a centrarnos en SCRAM. Vamos a empezar primero con los roles. Hay tres principales roles en SCRAM. El primero, el Product Owner. ¿Quién es el Product Owner? El responsable de que todo se cumpla. Es el que va a coger las historias de usuario, va a coger las necesidades y las va a meter en el Product Backload. Atentos a Product Backload, luego hablaremos de él. Otra responsabilidad que tiene el Product Owner, coger y planificar los sprints, además de priorizarlos. Sprint, otro concepto que luego hablaremos de él. Segundo rol, Scrum Master. ¿Qué hace el Scrum Master? Facilitar. Se le llama comúnmente el facilitador. Vela por que todas las ceremonias que luego hablaremos de ellas se cumplan, que la gente no tenga bloqueos. Que todo vaya bien. Perdona. Yo personalmente nunca he trabajado con un Scrum Master. Siempre ha sido o el Product Owner, o entre el Product Owner y el equipo de desarrollo los que han hecho ese rol. Me imagino que empresas muy grandes pues sí que tendrán este perfil. Y luego el equipo de desarrollo. Que al final lo que hace es transformar las historias de usuario a software. Sigamos. Primero concepto que hemos dicho que vamos a hablar del Product Backload. ¿Qué es el Product Backload? Es una lista priorizada donde tenemos todas las tareas, todos los errores, todas las mejoras que vamos a hacer en nuestro software a lo largo del tiempo. Primera pregunta, todo lo que esté dentro del Product Backload se va a realizar, ¿qué pensáis? No, habrán algunas cosas que se realicen y habrán otras cosas que no se realicen. Las cosas cambian y nosotros tenemos que cambiar con él. Segunda pregunta, es un poco más difícil. ¿Quién escribe cosas dentro del Product Backload? Aquí hay muchas respuestas válidas. Nosotros, por ejemplo, bajo la experiencia, al final lo que hemos decidido es, vamos a escribir todos. Por lo menos lo que es introducir la ISO o introducir la FITUR. Luego, ya en una reunión que hablaremos después, veremos, la refinaremos y iremos mejorándola. Es decir, primer concepto Product Backload. Lista priorizada con todas las tareas que se van a posible se hagan en el futuro. Siguiente concepto, Sprint. ¿Qué es un Sprint? Es un bloque de tiempo donde vamos a trabajar centrados en unos objetivos. Vamos a basarlo en cinco principios o cinco puntos clave. Primero punto clave, duración fija. Normalmente entre una y cuatro semanas. Yo recomiendo hacerlo de dos semanas. Yo más de dos semanas no he hecho, pero pienso ya que es demasiado largo. Dos semanas me parece que es ideal. Cuando digo duración fija, no quiero decir que a lo largo del proyecto se pueda cambiar, sí que puede cambiar. Lo que me refiero es, si hemos decidido que este Sprint actual es de dos semanas, es de dos semanas. El siguiente intentaremos que sea de dos semanas y siempre trabajar de dos semanas en dos semanas. Pero si por cualquier motivo tenemos que hacerlo un poco más largo o un poco más corto, se puede modificar. Siempre en un Sprint posterior, no en el que estás. Segundo punto, objetivos definidos. Tenemos que saber por qué y para qué estamos trabajando en este Sprint. Tenemos que tener claro el focus para conseguirlo. Tercer punto, este es el mejor. No sufrir cambios. No sé cuántos Sprints habrá hecho ya en mi vida. Os aseguro que muchos muchos. Creo que no ha habido ninguno que me haya sufrido cambios. Si alguno de vosotros consigue un Sprint que no sufre a cambios, por favor, avisarme porque yo no he sido capaz. ¿Qué ocurre cuando sufre cambios? Al final nos tenemos que adaptar. Y lo que hacemos es ver las cosas que consideramos que son menos prioridades. Cuarto punto, aportar valor. Al final de cada Sprint, tenemos que aportar valor. Si hemos hecho un Sprint que no aportamos valor al cliente, eso no vale para absolutamente nada. Y además, tenemos que hacer público todo lo que hemos hecho durante el Sprint. Toda la empresa o todo el mundo tiene que ser capaz de verlo. Y el último punto, realizar las ceremonias. Ahora vamos a hablar sobre las ceremonias. Primera ceremonia. Sprint planning. ¿En qué consiste el Sprint planning? Pues antes de empezar un Sprint, nos juntamos bien el Product Owner y nos dice, oye chicos he pensado que este Sprint vamos a trabajar sobre pagos con tarjetas. Nos explica todas las tareas que tenemos de pagos con tarjetas y decimos equipo de desarrollo no dice ostras, esto es un poco ambicioso, esto no llegamos. ¿Qué podemos quitar? Esto está de lujo, estás muy bien. Pues lo hacemos todo, o esto es poco. Vamos a meter algo más porque esto lo hacemos seguro. Aquí es muy importante tener en cuenta que el equipo de desarrollo tiene mucha voz porque al final nos comprometemos a que al final del Sprint va a estar todo resuelto. Empezamos el Sprint, hemos hecho el Sprint planning, empezamos el Sprint y no hablamos durante el Sprint. Si hemos dicho que una de las cosas más importantes es la comunicación, tenemos que hablar. Todos los días hacemos el Day Limiting. Es una reunión diaria muy cortita que se trata normalmente tres temas. ¿Qué hicimos ayer? ¿Qué vamos a hacer hoy? ¿Qué vamos a hacer mañana? Voy a dar un poco mi experiencia. ¿Qué hicimos ayer? Nos da igual, entre gomillas. Nos da igual, me refiero, si nosotros hoy decimos lo que vamos a hacer hoy mañana sabremos que hemos hecho lo que dijimos el día anterior. Así evitamos que no se hagan muy pesadas. Punto más importante de los tres los bloqueos que tenemos. Ese es lo más importante de todo. Porque si yo cuento mis bloqueos seguramente algunos de vosotros haya pasado por ahí y podamos trabajar en ello para solucionarlo lo más rápido posible. Otro truque que me ha dado la vida, hacerlas de pie o de forma incómoda porque así hacemos que sean mucho más pesadas y que vayan más rápido. Y el último truco que os quiero contar es cuando dos personas o tres empiezan a debatir sobre algo lo mejor es decir, oye, esto es el daily sacaros una reunión y lo habláis, ¿vale? No utilicemos el daily para hablar de cosas que no son del daily porque si no es cuando se hacen muy largas y la gente empieza a decir es que las reuniones son muy pesadas es que las reuniones son muy largas, etc. Entonces tenemos sprint planning. Al principio del sprint, es daily meeting todos los días y acabamos el sprint y hacemos el sprint review. Nos sentamos y vemos todas las tareas que teníamos que hacer que habíamos dicho en el sprint planning y vemos cuáles hemos hecho y cuáles no hemos hecho, ¿vale? Ya tenemos las tres partes, inicio, durante y fin. Pero nos quedan dos ceremonias que para mí son las más importantes y que quiero hablaros un poco más de ellas. La primera es el PBR, ¿vale? Product Backload Refinement. Ahora luego os contaré sobre ella y la retrospectiva, ¿vale? ¿En qué consiste una retrospectiva? Pues consiste, nos sentamos el equipo todo el equipo, Product Owner, Product Master, todo el equipo de desarrollo y hablamos sobre principalmente tres cosas. ¿Qué cosas hacemos bien? Porque si las hacemos bien, queremos seguir haciéndolas bien, estamos orgullosos. ¿Qué cosas queremos mejorar de las que hacemos y qué cosas hacemos mal, ¿vale? Empieza la retro. Cosas muy importantes a tener en cuenta. Hay que ser constructivos, ¿vale? Al final estamos hablando de cosas negativas. La gente puede sentirse atacada pero no, ni hay que tomárselo como algo personal, ni hay que ser no constructivo, ¿vale? Tenemos que aportar. Otra cosa muy importante. Tenemos que buscar un responsable de que la cosa que digamos que vamos a hacer, que la acción de mejora, se cumpla. Esto no quiere decir que si decimos, por ejemplo, hoy es que las reuniones se nos hacen muy largas, en marco de tiempo. La persona responsable tenga que ser la que acote las reuniones. Simplemente el responsable tiene que hacer que eso se cumpla. No tiene por qué ser el que lo haga. Simplemente tienes que decir que dijimos tal cosa. Siguiente punto importante. Todos los miembros del equipo tenemos el mismo nivel de experiencia y nuestras opiniones valen exactamente lo mismo. De igual que sea una persona que acaba de entrar en una empresa de 300 años, da lo mismo todos, tenemos la misma opinión. Y lo más importante cosa es que nosotros tengamos palanca de acción. No sirve de nada quejarse del departamento de tal cosa, que nosotros no tenemos ninguna palanca de acción. Siempre que nosotros podamos accionar. Vamos a la última ceremonia, al PBR, product bag loss refinement. ¿En qué consiste esto? Llega el Product Owner, igual que en the Spring Planning y nos presenta la tarea. Nos dice que quiero hacer pagos con tarjeta. Él ha creado unas historias de usuario y nos la muestra que el usuario puede pagar con tarjeta, que el usuario puede hacer tal, el usuario puede hacer pascual. El equipo de desarrollo empieza a debatirlas. Esto lo vamos a hacer así. ¿Qué puede ocurrir? ¿Encontremos una solución técnica? Perfecto, ya sabemos todos cómo la vamos a hacer. Lo apuntamos y la estimamos y la pasamos a después. ¿Puede ocurrir? Bueno, ahí lo he puesto. Encuentra la solución técnica, la ponemos y la pasamos. Es muy importante apuntar la solución que vamos a adquirir. Y con apuntar la solución no me refiero a poner el código exacto que vamos a desarrollar. Pero si decimos que vamos a poner un campo en base atos que hace tal cosa, ponerlo, que la persona que haga la tarea no haga luego lo que quiera. Otra cosa es que, haciendo la nerdemos cuenta que no hemos planeado bien, entonces cogemos, reunimos al equipo bien y lo hablamos. ¿Qué nos puede pasar que venga el Product Owner y nos diga que esta tarea es muy grande? O sea, que venga el Product Owner y nos presente la tarea y el equipo de desarrollo y diga, esto es muy grande. ¿Qué es una tarea grande? Una tarea grande depende del equipo. Cada equipo tiene que determinar para él lo que es una tarea grande. Para un equipo será de una tarea que dure dos días, para otro equipo una semana, para otro equipo lo que determine. ¿Vale? ¿Qué puede pasar? Dos cosas más. Una es que lleguemos y la tarea no cumpla el definición al reddit. ¿Vale? No os preocupéis, si no sabéis que es el definición al reddit porque lo vamos a ver a continuación. Si no cumpla el definición al reddit, no puede pasar el sprint. Y la otra cosa que nos puede pasar es que nos diga, oye, quiero hacer pagos con tarjeta y ninguno del equipo diga, tenga experiencia en pagos con tarjeta y digamos, no sabemos hacer pagos con tarjeta. ¿Vale? Entonces surge la tarea de la investigación, que luego hablaremos de ella porque es muy interesante. Vamos a ver los acuerdos. Tenemos dos acuerdos, ¿vale? El primero, definición al reddit. ¿Qué es el definición al reddit? Es el documento pactado entre el equipo donde indicamos que necesitamos para poder empezar la tarea. ¿Vale? Ejemplo de definición al reddit que he tenido yo, por ejemplo, que los diseños lo tengamos en mobile, en tablet nos ha pasado mil veces a todos, estoy seguro, empezar a maquinar una pantalla, acabamos el mobile y le decimos ostras, y el desktop, ¿dónde está? Bloqueados, no queremos bloqueos. Otro tema que he tenido, por ejemplo, traducciones. Si hay textos y están varios idiomas necesitamos que todas las traducciones estén desde el principio claras. ¿Vale? Es decir, definición al reddit. El acuerdo que hemos decidido entre todos para que la tarea pueda pasar a iniciarse en un sprint. Y el siguiente acuerdo es el definition of don. ¿En qué consiste el definition of don? Es el acuerdo entre todo el equipo igual que dice que una tarea está hecha. ¿Vale? No puede ser que para mí una tarea sea que esté en producción hecha, para otra persona sea que esté en steye. ¿Vale? Para todos tiene que ser lo mismo. Ejemplo de definition of don que he tenido, que la tarea esté en producción, que la tarea haya sido validada por el cliente en producción, que la tarea se haya comprobado que funciona en ciertos navegadores. Aquí ya cada equipo tiene que negociar las cosas que consideran que son necesarias para el definition of don. Muy importante, se puede ir modificando. Esto no está grabado al fuego. Si tú durante la experiencia detectas cosas pues las vas añadiendo. Y vamos a hablar del último concepto, spike. Si os acordáis, hemos hablado que llega el Product Owner y nos dice que quiero hacer pagos con tarjeta. Y nadie sabe hacer pagos con tarjeta. ¿Vale? No sabemos hacer pagos con tarjeta en el equipo. ¿Qué hacemos? Un spike, que es una tarea propia de investigación sobre el tema que vamos a hablar. Y son tres puntos, muy importantes. El primero, como vamos a hacer una investigación, lo que hacemos es bloquear un tiempo. Y nos vamos a invertir tantas horas, tantos puntos, cada uno como estimes y estimáis. Vamos a dedicar X tiempo en investigar. Que esto nunca superes la duración que no tiene sentido. Vale, ya tenemos la duración. ¿Qué pasa si en esa duración no hemos sido capaces de encontrar una solución? Se habla con el equipo y se vuelve a ampliar el tiempo que necesitemos. Siguiente punto. La persona que realiza el spike no tiene por qué solucionar la tarea. Simplemente es la encargada de recopilar la información. La recopila, la apunta en la tarea o como cada uno lo gestione el equipo, súper importante. Porque la decisión no la va a tomar el que ha hecho el spike, la decisión la va a tomar todo el equipo, siempre las decisiones en equipo. Y el último punto, antes de hacer un spike, tenemos que saber qué queremos encontrar en el spike. Siguiendo con el ejemplo del pago con tarjeta, pues queremos saber si vamos a admitir pagos nacionales, pagos internacionales, qué comisión se lleva a cada plataforma, las cosas que sean necesarias para el negocio. Aquí tenemos un gráfico resumen del spring, empezamos con el product backlog primera reunión spring planning seguimos con el daily que sólo lo hacemos cada día. Ahí está un poco metido el backlog refinement aunque no se hace cada día, aquí ya cada equipo decide. A mí personalmente la forma que me ha gustado ha sido dos reuniones por semana de una hora. Siempre estás estimando tareas que vas a hacer después de los springs. Spring review, retro y soltas una release. Yo, por ejemplo, a mí también me gusta más es, o sea, conforme tienes cosas hechas ir deployando, no esperarte al final del spring para soltarlo. Y ahora vamos a hablar de las historias de usuario. A quién no le ha pasado que está trabajando, llega quién nos dé las tareas en una servilleta como aquel que diga y pone quiero hacer pagos con tarjetas y te las suelte y dice, toma aquí tienes tu próxima tarea y tú te quedas así y dices vale, pues voy a hacer pagos con tarjeta haces pagos con tarjeta como a ti te parece lo haces, le enseñas y te dice, no, es que yo no lo quería así es que no has hecho si está bloqueada, es que no has hecho si no sé qué pero es que tú todo esto no me lo has especificado entonces para evitar que esto no pasa, están las historias de usuario que son las historias de usuario pues son los criterios de aceptación que tenemos que cumplir para dar por válida una historia de usuario y aquí hay una cosa muy guay que es gerkin que es un lenguaje especifico de dominio qué ventajas tiene usar gerkin pues tiene principalmente tres ventajas la primera es que lo entiende todo el mundo bueno, luego lo vamos a ver, cuando veis el caso de ejemplo, todo el mundo que estamos aquí sea técnico, sea no técnico o sea quien sea, lo va a entender y eso está muy guay segundo punto hay un list en softwares que están orientados a mediante gerkin crear automatizaciones, crear pruebas automáticas aquí ya entra pues por vdv, etc y el último está orientado al comportamiento del usuario todas las historias de usuario están orientadas o están escritas desde el punto de vista del usuario sabemos perfectamente cómo va a actuar vamos a hablar un poco del funcionamiento de gerkin, cómo funciona tenemos varias palabras clave que nos van a definir ciertas cosas la primera, the feature que describe el aspecto que vamos a probar en nuestro ejemplo que estamos utilizando todo el rato el pago con tarjetas nuestra feature sería pago con tarjetas de crédito segunda palabra, escenario se explica qué va a pasar en un momento clave por ejemplo el usuario va a pagar con tarjeta y no tiene saldo ese sería el escenario otro escenario, el usuario va a pagar con tarjeta y no tiene saldo otro el usuario va a pagar con tarjeta pero la tiene bloqueada así todos los escenarios que se nos ocurran siguiente palabra clave, given que es el given, el contexto desde dónde partimos dado un usuario que está en la página de pagos dado un usuario que ha completado el carrito y quiere pagar dónde esté cada usuario dónde esté todas las acciones que va a realizar el usuario por ejemplo, hemos dicho que estamos en la página de pagos cuando clicos a when clicos sobre el botón de pagar cuando navego a la página, no sé qué lo que sea entonces llegamos al den, qué es el den los resultados, qué esperamos cuando pulsamos el botón de pagar cuando completamos los campos de los tarjetas de crédito entonces den se realizará la compra si mostraremos un mensaje de confirmación o lo que necesitemos luego tenemos dos palabras, que son bastante importantes, que son el am y el bad, que lo que hace es concatenar acciones o quitar acciones, por ejemplo cuando estamos en la página de pagos y ahí podemos concatenar, y la tarjeta tiene saldo, y ha completado los campos de la tarjeta y ha completado el campo de la tarjeta del vc, luego podemos añadir también por ejemplo el bad, pero el cvc no es válido, pues aparece tan mensaje de error pero la fecha de validez es inferior al día de hoy, aparece tal error aquí tenemos un ejemplo real que es el que hemos estado hablando de unos criterios de aceptación escritos con Gherkins y nada ahora se da yo un poco la paliza, y ahora me gustaría que me la dierais vosotros a mí os toca a vosotros preguntarme cositas que queráis saber o situaciones que os hayáis encontrado, y os puedo contar un poco mi experiencia como encaja dentro de una empresa que no ha utilizado esto asambleario porque estamos acostumbrados a hacer esto en este plazo a ver, aquí hay varias cosas importantes que estaría bien hablar lo primero, escravo al final es un framework de trabajo, vale, no quiere decir que tengamos que hacer todas las ceremonias, que tengamos que utilizar todo que hemos hablado, por ejemplo si en una empresa hacer el sprint planning no nos resulta útil, pues no lo hacemos si en una empresa no nos resulta útil hacer la retro, pues no lo hacemos como encajaría, pues aquí hay que cambiar la cultura de la empresa al final hay que empezar a trabajar sobre utilizar metodologías ágiles va a estar todo el equipo más contento y va a ser todo mejor y yo recomendaría poco a poco primero haciendo el daily después ir introduciendo poco a poco acciones y acercándonos a metodologías ágiles, porque seguramente si quisieramos, o sea, si queremos cambiar de no usarlo, usarlo todo fracasemos, y eso es lo que no queremos ¿y peros? porque he escuchado esto de Scrum o sea, que todos son maravillas no, no son todo maravillas, yo voy a contar las cosas que me han pasado a mí a lo largo del tiempo usando esto lo primero es que las reuniones hacen superlargas al final una reunión, cuando pasan 45-50 minutos la gente empieza a caer la gente ya no presta atención la gente ya no está igual de enchufada entonces, cosa que hicimos bloquear las reuniones, dijimos más de una hora no hay de reunión si tenemos que hacer varias veces, hacemos varias veces eso por ejemplo ha sido uno de los peros que más me ha afectado a mí a lo largo de esto otra cosa que también pasa que muchas personas que son proactivas, que les gusta colaborar y hay otras personas que son más me gusta que me manden yo no quiero colaborar en esto, dime lo que tengo que hacer yo te lo hago, pero yo no quiero colaborar también es las personas que ya en la empresa pues te ayudarán a poder utilizarlo eso es otro pero, que si la gente que trabaja no es proactiva esto no va a funcionar otro pero, por ejemplo los clientes, no todos los clientes están dispuestos a trabajar hay muchos clientes que dicen no, a mí no me cuentes rollo, yo te pedí un coche a mí me das un coche yo no quiero el patinete ni quiero el rollo, quiero el coche apañate como tú quieras pero quiero el coche y lo quiero tal día es un poco también educar al cliente, que el cliente quiera aceptarlo que hay muchas cosas pero, yo te diría eso reuniones demasiado largas si no se toman medidas que a lo mejor hay gente que no se adapta a ser tan proactivo, a buscar soluciones a tantas reuniones y sobre todo el cliente ahora, aquí si la empresa es de producto y somos nosotros los que decidimos como hacerlo pues aquí ya, así que no tenemos problema pero, claro muchas gracias hola, gracias por la charla cuando eres el Product Owner a ti te toca la responsabilidad de crear la historia del usuario recomiendas crearlas en conjunto con el equipo desarrollador entre todos te cuento, aquí Gherkin ha hablado de una cosa que es la reunión de los tres amigos que consiste en Product Owner equipo de desarrollo pero, cuando hablamos de equipo de desarrollo no es solo los que programan no, aquí entra QA, entra diseño, entra todo el mundo incluso gente de fuera o sea no el equipo de desarrollo, pero en la reunión sí que gente de fuera que puede participar en cómo desarrollarlas sí que es interesante que haya gente de varios ámbitos si que está guay que haya uno de desarrollo que haya uno de diseño que esté el Product Owner ¿por qué? porque al final el Product Owner lo va a resolver, o sea lo va a escribir pero si hay una persona de desarrollo te puede decir oye cuidado que esta forma que lo estás planteando no es la correcta o esto nos va a costar mucho trabajo, es mejor si le damos esta vuelta entonces siempre es mejor colaborar a la hora de escribir las historias de usuario entre varios roles de diferentes departamentos y los datos del testeo, que cuando ya viene el release tiene que estar disponible ahí ya por ejemplo nosotros lo que hemos hecho muchas veces es al Definition of Dawn tenía que estar testeada por CUA por ejemplo si no ha pasado CUA ahí ya por ejemplo cada uno otro punto del Definition of Dawn que tenga los tests unitarios hechos, que tenga los tests automáticos ahí ya es que cada equipo pero si el testeo entra dentro de un sprint y hay que reservar tiempo de testeo cuando estimamos una tarea sí han llegado que llegan al release sin testeo eso no sirve llegan al staging pero ahí lo malo viene del sprint planning que hemos sido demasiado ambiciosos que eso es muy típico también porque tú cuando empiezas a ver las tareas tú dices, esto lo tengo yo seguro esto lo tengo seguro y luego empieza la realidad y empiezas a verlo y dices, ostras que igual no llego, que igual no llego y después van a hacer el release solo bots pero ahí está el daily para ir diciendo eso para ir alineándonos que aquí estoy teniendo bloqueos que aquí esto no va como pensaba y poder rectificarlo lo antes posible más preguntas por aquí, hola muy buenas muy didáctica la charla, muy interesante también así un comentario rápido al compañero en plan... Scram es muy bonita pero hay muchas metodologías y hay algunas incluso en combinación con Scram, Scramban y demás y tal que es lo que ha recalcado él al principio una pregunta trabajo en equipos, también manejo Scram dependiendo del caso ¿Cómo solucionas el tema de que tengas desarrolladores que quieran cogerse vacaciones en medio de un sprint? a ver a ver, al final sí, sí, es una cosa que pasa al final por suerte yo no soy el que lo hace eso, pero te cuento cómo lo hacemos porque lo sé intentamos siempre, o sea tenemos mucha confianza entonces a no ser que pase algo grave que tengas que cogerte vacaciones que en ese caso las coges tenemos a mucho tiempo o sea ya cuando intentamos tener las vacaciones planificadas con tiempo que no sea de hoy para mañana decir oye que mañana no estoy o sea que mañana no voy a estar durante una semana antes de empezar el sprint sepamos que tal persona no va a estar tantos días lo digo más en el sentido de que tiene a lo mejor cinco desarrolladores en el equipo de desarrollo que no es a la vez entonces tiene cinco sprints donde vas a tener al menos uno que no está eso pasa por ejemplo en los meses de julio agosto septiembre pasa mucho nunca somos todos en otras empresas lo que hacen o han comentado también es intentar planificar que las vacaciones se las cojan a la vez y esos días que se queda el equipo muy de reducido se utiliza para spikes o por ejemplo para hacer tareas de mejora que hay muchas veces que tenemos deuda técnica es el sitio para resolver la deuda técnica y ahí por ejemplo es un buen momento para nosotros siempre intentamos que como mínimo haya uno o sea nunca intentamos que estemos todos de vacaciones porque siempre puede pasar cualquier cosa yo que sé siempre preguntita rapidísima y yo dejo aplicación de scrum dura o flexible personalmente yo soy más de utilizar las partes de scrum que nos interesen vale por ejemplo lo que he comentado antes no nos interesa hacer daily pues no lo hagamos a mí por ejemplo para mí el daily es lo más importante que no nos interesa hacer pbr pues no lo hagamos pero luego no nos quejemos cuando empezamos a hacer las tareas y no estén definidas yo soy más de elegir lo que queramos pero lo que queramos o sea lo que elijamos hagámoslo bien y lo más importante combinar o sea por ejemplo canvan con varias ceremonas de sprint funciona de scrum funciona muy bien no la buena por la charla y bueno yo quería preguntar sobre los tres problemas que has comentado antes que te encuentras más no como cuando se lo cuentas a un cliente por ejemplo esta metodología y le parece muy bonito todo y todo muy es perfecto no pero luego en la realidad supongo que te habrá pasado también que a veces el cliente pues tiene que cumplir algunas cosas y no lo hace su tiempo y te lo desbarata todo entonces ahí como depende del caso actuaras de una manera pero con tu experiencia como lo has solucionado eso que has hecho pasa mucho más habitualmente de lo que podáis imaginar por ejemplo esta semana me ha pasado estábamos trabajando en un desarrollo y me han parado porque el día 14 tenía que enseñar una funcionalidad que no teníamos y tenía que estar que hemos hecho pues como os he dicho antes con ningún sprint que no haya sufrido cambios y hemos hecho pues para el desarrollo se ha hablado con el cliente y se ha dicho si seguimos el viernes lo tienes si no lo tendrás el martes no no me da igual lo tendré el martes quiero esto hemos parado lo hemos sacado y hemos metido la funcionalidad nueva que es un poco malo sí pero al final hay que adaptarse al cambio o sea no podemos estar diciendo nos adaptamos al cambio somos súper flexibles y luego que vengan y cerrarnos en banda que no se debería no se debería pero hay que ser consecuente con lo que se vende muy bien gracias hola qué tal me sumo a las felicitaciones por la charla y es un tema que además me ha tocado a mí muy de cerca yo llevo bastantes años en equipos de desarrollo y quería preguntarte tu opinión personal porque has descrito muy bien los roles desde el producto el owner del producto hasta la Scrum Master mi pregunta es los roles intermediarios como los project managers o TPM que lo llaman en otros lugares tú lo recomiendas crees que son necesarios crees que al mejor debe haber una interacción directa entre la unidad de negocio y el equipo de desarrollo pero el desarrollador propio o estos roles son muy convenientes porque realmente pueden coger un documento funcional crearte las historias de usuario hacer de Scrum Master también etcétera quería preguntarte qué tal te cuento un poco mi opinión para mí lo mejor es que se dirijan directamente al Product Owner y el Product Owner sea ya el que reaccione con el equipo de desarrollo hay muchas veces que eso no es posible porque hay muchas veces que por ejemplo tenemos jefes o tenemos gente que se mete ¿qué hacemos en ese caso? pues tenemos que saber con quién trabajamos lo escuchamos, lo apuntamos como desarrollador vamos al Product Owner le decimos que nos ha pasado esto, ¿qué hacemos? y el Product Owner pues te dice vamos a hacerlo, no vamos a hacerlo así es como lo hemos hecho nosotros intentamos no tomar cuando vio en el Product Manager y nos dice hay que hacer esto intentamos no tomar decisiones uno solo porque nos lo haya dicho él porque si no al final ahí estás creando que vuelva a venir y lo vuelva a hacer y eso es lo que no queremos no queremos dar pie a que eso ocurra habitualmente porque en el momento venga no tienes capacidad de decirle no, esto no te lo voy a hacer entonces vamos, hablamos y decimos mira nos ha pasado esto, ¿qué hacemos? y ya pues decidimos entre todos por si lo hacemos, no, espera voy a hablar con él mejor va el Product Owner, habla con él y lo convence y no se hace o al revés, se habla con él y no ha sido capaz hay que hacerlo, vamos a quitar tal cosa pero al final es que cada caso es un mundo y hay que saber lidiar con todo y es muy complicado lo que voy a hacer es que es muy difícil es que viene y te dice lo tienes que hacer y te toca callarte y te toca hacerlo aunque sepas que lo que estás haciendo es malo o no está bien ejecutado hay que hacerlo una pregunta que este tipo de metodología estas sillas que son similares ¿qué forma hay de aplicarlas en empresas de desarrolladores web por ejemplo que salen una persona o dos personas o sea qué tipo de cómo se pueden aplicar o como algo similar te cuento porque esto sí que lo he vivido en este caso, nosotros lo que nos funcionó muy bien fue en vez de usar Scrum con tantas reuniones y tal lo que utilizamos fue Kanban que al final teníamos tres pasos, digamos que teníamos las cosas que teníamos por hacer las cosas que estábamos haciendo para probar y demás y eso nos funcionó muy bien y de ahí cogimos varias ceremonias no hacíamos Spring Planning porque no trabajábamos por Spring trabajábamos de una forma más continua no hacíamos Spring Review porque como no hacíamos Spring no tenía sentido lo que hacíamos era tener un Product Baglock mucho más largo bueno ya lo teníamos refinado teníamos ahí el Baglock y lo que vamos haciendo era coger tareas de forma continua no hacíamos ni el Spring Planning ni el Spring Review sí que hacíamos el Product Baglock Refinement para poder definir mejor las tareas sí que hacíamos el Daily porque para mí es súper importante y sí que hacíamos las Retros vasas que en lugar de hacerlas al final de cada Spring por las teníamos periódicas cada dos, tres semanas y otra cosa importante que ahora que hemos hablado de las Retros nosotros por ejemplo todos los Spring no hacemos Retros sí que decimos, oye alguien quiere comentar algo y si nadie tiene nada que comentar la hacemos cada dos porque hay veces que cada dos semanas no tenemos fuerza suficiente para realizar una Retro más preguntas no sé, el micrófono se me olvidaba la última y está muy específica Gherkin es la primera, osea soy desarrollador pero es la primera vez que lo escucha eso, osea has dicho que automatiza la generación de gérkin no automatiza existen herramientas que si tú tienes los criterios de aceptación en Gherkin puedes escribir test de comportamiento pero no las automatizas pero si pasas eso y lo hace lo tienes que programar estaría muy guay lo que pasa es lo que sí que pasa es que tú puedes programar ciertas sentencias entonces luego es muy fácil automatizarlas osea lleva faena no te pienses que sos meterlo ahí se automatiza todo estaría guay pero no es así por desgracia muchas gracias ya no tenemos tiempo para más pues en nombre con Valencia te queremos dejar este pequeño regalito muchas gracias por escucharla