Agile y Scrum: de principiante a experto (incluye un proyecto práctico)

1. Introducción y descripción de la curso: Hola a todos y bienvenidos a este curso que se titula masterización pasillo edad y Scrum de principiante a experto. Has tomado una decisión muy inteligente al elegir aprender h l y es miga. Porque ya sabes, el HL es un concepto tan importante en el mundo actual, independientemente del dominio de la industria o la tecnología en la que estés trabajando. Y sus usos en rápido crecimiento. Casi el 71% de las organizaciones utilizan un IG y ese número crece cada día. Entonces por eso es muy importante saber al respecto. Y definitivamente estás en el curso correcto para papá. Se trata de una clase magistral para Agile y Scrum, y aprenderás cada pequeño detalle sobre ellas. Puedes utilizar este Aprendizaje para Mejorar Tu asumiendo o trabajar en un equipo de Scrum o certificarte como maestro de scrum, sea cual sea tu objetivo final. Por lo que estoy muy emocionado chicos por subirme a este viaje de aprendizaje. Y les agradezco por elegir este curso. Empecemos y veamos qué todo vamos a cubrir en este capítulo de introducción. Entonces aquí está el orden del día de este capítulo. Y como pueden ver, sólo estamos conociendo las cosas que es muy importante para marcar el impulso. Veremos principalmente lo que cubre este curso y cómo puedes sacar lo mejor de él. Hablaremos de mí, de su instructor, del contenido del curso, y de las inmensas opciones de portador que siguen una vez que obtenga el conocimiento de AGI. Entonces, ¿qué puedes esperar de este curso? Bueno, este curso es un paquete completo. Nosotros por supuesto, aprenderemos todo sobre Agile y Scrum y lejos Este curso está diseñado. Partimos de los conceptos más básicos para luego pasar al avanzado. Por lo que si eres completamente nuevo en RHH, te sentirás totalmente cómodo en este viaje. O si eres alguien que tiene experiencia en un gel, aún te sugiero que veas todos los capítulos en secuencia porque podría haber algo nuevo para ti o te conseguirás un recapitulación. Aprenderemos sobre los conceptos básicos de HL y Scrum, los roles de Scrum, ceremonias, ¿cómo estimamos las cosas? ¿ Cuáles son los artefactos que reportan que creamos? Y mucho, mucho más. Y vamos a mantener estos aprendizajes interactivos. Por lo que hay un pequeño quiz al final de cada capítulo para refrescar lo que hemos aprendido. Otro punto y muy útil, no basta con conocer la teoría. Tenemos que aplicar nuestro aprendizaje en la práctica también porque es entonces cuando obtenemos el conocimiento real de las cosas. Y por eso tenemos todo un capítulo dedicado a montar un proyecto en Scrum desde cero. A continuación, también hablaremos de certificaciones y entrevistas en este curso. Entonces si tu objetivo es certificarte como maestro de scrum, seguramente te beneficiarás del curso porque tenemos todo un capítulo dedicado a certificaciones y consejos para despejar el examen. Y de igual manera, si tu objetivo es sobresalir en una entrevista, tenemos un capítulo dedicado a los consejos de entrevista y 30 más preguntas de entrevista más comunes. A continuación, si eres miembro de este curso o de alguno de mis otros cursos, obtienes apoyos de consulta de por vida. Entonces usa la Q y una opción en el sitio web o déjame un correo electrónico y obtendrás una respuesta rápida. Y este es el apoyo de por vida chicos. Para que me envíen algo incluso un año después de tomar este curso y esperar de vuelta una respuesta. Y por último, este curso está diseñado para todo tipo de público en mente. Ya sea que seas un desmayado universitario fresco o un participante en TI o un folk experimentado. El contenido de este curso abarca todos los niveles y al final del mismo, tendrías toda la pericia de Agile y Scrum. Por lo que antes de pasar a los chicos, sólo quería dar una breve introducción sobre mí mismo. Tengo diez años más de experiencia en gestión de proyectos y aseguramiento de calidad. He trabajado y dirigido varios proyectos de productos AGL en India y también desde hace varios años en nosotros. Mi dirección de correo electrónico está en la pantalla, así que como mencioné antes, también, si tienes alguna pregunta, por favor siéntete libre de dejarme un email y te responderé proactivamente en un plazo de 24 a 48 horas. También puedes publicar tus dudas a través de la Q y una opción en la página web. Ahora, antes de seguir adelante, una de las cosas que quería mencionar fue que en todos estos años de mi experiencia laboral, más importante que he encontrado que necesitamos en la vida laboral es tener el Arte de up-skilarnos para mantener en aprender cosas nuevas. Por lo tanto, mantén el deseo de aprender, toma cualquier nuevo tema que te interese y sigue construyendo ser aprendiz. Está bien, así que estamos listos para saltar. Caminemos por el contenido del curso ahora para que sepas lo que te espera. Entonces chicos, aquí está el contenido del curso y a medida que lo pasemos, notarán que he llamado a cada capítulo como un sprint. Por sprint es el corazón de Scrum y todo el trabajo pasa en él y lo sabremos más adelante. Por lo que cada capítulo es un sprint para aprender algo nuevo. Dentro de 80 sprints, aprenderemos todo sobre Agile y Scrum. Empezaremos con los conceptos básicos de Hl y Scrum. Después hablaremos de los roles de Scrum, las personas que están en el equipo de scrum, seguido de ceremonias de Scrum, eso son los encuentros. Y luego los Artefactos Scrum. Después aprenderemos sobre la planeación y estimación de sprint, seguido de los informes de Scrum que creamos. Y entonces el capítulo ocho es un ejercicio de práctica completo donde vamos a montar un proyecto desde cero en un scrum y ver su implementación todo el camino desde recolección de requerimientos iniciales hasta la liberación al usuario final. Por último, tenemos el capítulo nueve para conocer las certificaciones, puntas de bits sobre cómo limpiar el examen maestro scrum certificado. Y por último, papel de periódico diez. Te voy a dar un montón de preguntas de entrevista para ayudarte a prepararte para una entrevista y han mantenido la respuesta a estas preguntas lo más simple posible para que no tengas que reventar cosas, tus conceptos o sonido. Entonces chicos, como pueden ver, es una lista bastante exhaustiva y seguiremos este plan en los próximos diez capítulos para hacerte un experto en ágil y scrum. Ahora volviendo al último tema de este capítulo, las oportunidades de portador en AGI, Es muy importante ver el camino por delante y estar motivados. Recuerda, el VIH comenzó en algún lugar hace 20 años. Y en el mundo actual, es la metodología más utilizada. Si hablamos de grandes empresas, Fortune 500s, o incluso de startups más pequeñas, todo el mundo está usando AGI. Se puede recoger cualquiera de su listado de empleos para la gestión de proyectos o desarrollo o pruebas, y se requerirá de un conocimiento infantil. Algunos empleos exigen una certificación también como CSM o CSP Leo y yo sugeriría que persiga estas áreas. Tener una certificación da un reconocimiento a tus conocimientos y es una adición más agradable al currículum. Si ya estás en el rol de gestión de productos, puedes pensar en el rol de propietario del producto u otros roles de gestión. Si eres demasiado apasionado de h l, puedes ser un entrenador Ágil. Las oportunidades y usos del VIH son chicos interminables. En LinkedIn encuestas de los diez trabajos más prometedores es Scrum Master y Product Dueño son una de las entradas. Tan impresionante camino portador. Y por eso dije en un principio que has hecho una gran elección al elegir aprender AGI. De acuerdo, entonces hemos hablado del curso, es contenido y oportunidades en AGI. Comencemos nuestro viaje de aprendizaje y empecemos con el siguiente capítulo para saber qué es ágil y scrum. Gracias. 2. ¿Por qué agilizar? (Problemas con enfoque tradicional): Hola a todos y bienvenidos al segundo capítulo del curso. Ahora vamos a iniciar nuestro viaje hacia los conceptos iniciales de Agile y Scrum. Primero veremos cuál fue el enfoque tradicional, la forma pre ágil de hacer las cosas. Porque esto nos ayudará a entender la razón por que nació un niño y por qué tiene tanto éxito. A continuación, veremos el Manifiesto Ágil y principios que son la base de la HL. Después discutiremos la metodología EGL seguida por Scrum. Utilizamos los términos que cada isla está abarrotada, pero recuerda que hay una diferencia entre ellos y veremos qué es eso. A continuación, echaremos un vistazo al ciclo de vida de scrum. Entonces hasta ahora estábamos en la parte de lo que es. Ahora pasaremos a la forma en que se hace parte. Y por último, hablaremos de MVP y enfoque incremental, que es un concepto importante. Entonces empecemos. Entonces saltemos directamente y empecemos con el mundo Ágil de hacer las cosas, cómo se piensa que se hace antes de la edad Eyal entró en escena. Por lo que la metodología más común que se siguió antes de que se conociera a un niño fue el modelo de cascada. Y así se veía. Entonces chicos, este es el modelo de cascada y como pueden ver, hay una secuencia estricta de fases. Contamos con la fase de requisitos, la fase de diseño, verificación de implementación, y finalmente la fase de mantenimiento. Y las fases anteriores tuvieron que completarse antes de poder empezar con la siguiente. Entonces ahora se ve bastante directo, pero aquí había un gran problema. Y el problema de la deuda ocurrió cuando tuvimos que volver atrás y cambiar las cosas. Entonces vamos a entender esto con un ejemplo. Consideremos un escenario en el que una empresa quiera desarrollar un nuevo producto, digamos un teléfono móvil, hacen la investigación de mercado. Salen con los requerimientos de lo que necesitan y deciden implementarlo utilizando el enfoque de cascada. Ahora tres meses después de comenzar, digamos que la verificación del tinte rojo y fase de prueba ender se dio cuenta en los requisitos han cambiado. Los clientes ya no necesitan lo que enseñaron inicialmente. Y así todo lo que han planeado y hecho hasta ahora se ha ido. Y ahora tenemos que volver a empezar todo desde el principio, la primera fase de requerimiento. Si lo piensan, chicos, esta es la realidad del mundo de hoy. Si hoy ves la mentalidad del cliente, sus necesidades están cambiando tan rápido es estudios han demostrado que en proyectos grandes y complejos, alrededor del 70% de los requisitos iniciales se cambiarán durante el proyecto. Lo que estamos haciendo hoy sería obsoleto y sustituido por algo nuevo en tres a seis meses. Y así cascada no pudo hacer frente a este cambiante mundo requisitos. Entonces esto es lo que también dice la diapositiva. Si lo piensas, incluso el cliente, Así que danos los requisitos para sus proyectos. Podrían no conocer de antemano todos los requisitos. De hecho, es difícil para cualquiera adivinar cómo reaccionarán los mercados y los usuarios ante un producto en los próximos tres a seis meses porque, ya sabes, las cosas están cambiando tan rápido. Y para superar este problema, las cosas tenían que ser curso-correctas en lote intermedio y esto incrementaba el costo, tiempo, esfuerzo, etc. Ahora, otro problema con Bagdad en cascada, el usuario final o cliente no se involucró en el proceso y Dessau software de trabajo o producto bastante tarde en el juego y si se necesitaba algún cambio, bueno, volvamos de nuevo y empiezas a implementar desde la fase inicial. Nuevamente, lo que significa más costos de tiempo, esfuerzo, etc. Así que chicos, este enfoque tradicional de cascada que vimos comienzan a desarrollar grietas. Y de hecho, en EU donde el Departamento de Defensa fue el mayor usuario de cascada, descubrieron que 75% de su proyecto nunca se completó por retrasos y escaló costos debido a frecuentes cambios. Por lo que una vez más, para resumir el problema con el enfoque tradicional, número uno, nadie puede obtener requisito en una sola toma porque las cosas están cambiando tan rápido. Número dos, el usuario final no estuvo involucrado en el proceso. No hubo mecanismo de retroalimentación. Y número tres, el software de trabajo o prototipo llegó bastante tarde al cuadro. Entonces para el momento en que los cambios podrían ser factorizados, ya era bastante tarde. Entonces, en resumen, este enfoque tradicional no era bueno para cambiar continuamente los requisitos. Y así a finales de los noventa, la industria quiso avanzar hacia un modelo iterativo que estuviera abierto a los cambios en evolución. Y tomó en consideración los problemas reales. En primer lugar, nadie puede conocer todos los requisitos. Segundo, hacer cambios es un gran problema. No es manejable seguir cambiando las cosas cada vez que hay un nuevo requisito. Y lo más importante de todo, necesitábamos algo que pueda ser el número uno, hecho en pequeños incrementos. Número dos, la deuda podría ser iterativa. Y número tres, eso implicaba retroalimentación continua. Entonces si alguna vez tuvimos una modificación, podemos encontrar desde el principio. Y chicos, este es el proceso de pensamiento exacto que dio a luz a un niño, desarrollo iterativo e incremental con retroalimentación continua. Y escucharás mucho estas tres palabras, retroalimentación iterativa, incremental y continua en este curso, porque las otras necesidades sobre las que se construye un niño o un Scrum. Muy bien, ahora la industria tenía algo se empieza a adoptar algunos modelos iterativos por los años noventa. Pero lo real llegó en 2001 cuando 17 desarrolladores de software se conocieron en un resort de EE.UU., EE. UU. Y se les ocurrió algo que se llama el manifiesto HL. Entonces hablemos de lo que es este h l manifiesto y cómo forma la visión de un niño en la próxima conferencia. Gracias. 3. El manifesto ágil: Hola a todos. Hablemos ahora del Manifiesto Ágil. Y es importante entender este manifiesto porque es la base y el principio rector detrás de la implementación de HL en todas partes del mundo. Ahora este manifiesto tiene cuatro valores básicos y 12 principios de apoyo. Entonces veamos qué son. Y ya sabes, hay un sitio web dedicado a este manifiesto, así que vamos a echar un vistazo a eso. Entonces chicos, tienen un sitio web llamado HL manifesto.org. Y así es como se ve. Y se pueden ver los cuatro valores centrales enumerados aquí mismo. Y dice que las cosas de la derecha son lo que hemos estado haciendo. Pero en cambio deberíamos valorar más que las cosas de la izquierda y debemos seguirlas. Por lo tanto, número uno, debemos valorar a los individuos y las interacciones sobre los procesos y herramientas. Los procesos son importantes, pero no son flexibles para cambiar las necesidades de los clientes. Por lo que no debemos apegarnos ciegamente a los procesos. Más bien, debemos enfocarnos más en los individuos y sus interacciones. Cuando los individuos colaborarán más, se les ocurrirá una mejor idea y no sólo seguir el proceso. Entonces este fue el punto número uno, pero recuerda que no dice dejar de seguir todo el proceso y hacer lo que quieras. No, solo dice que los individuos deben interactuar más, deben colaborar más y no deben ir ciegamente a lo que dice el proceso. Número dos, software de trabajo sobre documentación integral. Por lo que de vuelta en los días de cascada, Había mucha documentación para cada una de estas etapas y edad. Dije que mantengamos la documentación al mínimo es racionalizar todo y enfocarnos más en conseguir un software que funcione. Por lo que una vez más, no entiendan que cada pasillo dice se deja de hacer todo tipo de documentación. No. En cambio, quiere que nos enfoquemos más en conseguir que funcionen software en lugar de solo obtener documentos. Y el número tres, la colaboración del cliente sobre la negociación del contrato, es decir, el cliente involucrado en todo el viaje. Piensa en lo que quieren en lugar de simplemente tratar de trabajar como un contrato escrito de una vez. Y último número por responder al cambio sobre seguir un plan. Y este es el más importante en mi, mi punto de vista porque la mayoría de la gente piensa en agendas solo a la metodología. Pero recuerda siempre que un niño es más un proceso de pensamiento. Tenemos que ser HI en nuestro pensamiento sólo entonces podremos seguir una metodología de la cárcel con precisión. Y la prueba de VIH nos dice que no sigamos el plan ciegamente. En lugar de ser flexibles, ser receptivos a los cambios para que podamos adaptarnos rápidamente a las cambiantes condiciones del mercado. Por lo que estos son los cuatro valores centrales, centrales. Y como dice, hay valor en los ítems de la derecha. las cosas que hemos hecho en el enfoque tradicional. Pero ahora vamos a valorar más las cosas de la izquierda. Entonces en pocas palabras, esto era lo que parte de un gel. Y aquí mismo enumera el nombre de esas 17 personas que reunieron para formar el manifiesto Agile y se les ocurrió estos cuatro valores centrales. Ahora si te desplazas más abajo, verás un enlace a los 12 principios. Entonces esta es la página a la que se lleva, y se puede leer a través de ellas. Aquí hay algunos puntos clave. En primer lugar, tenemos que proporcionar al cliente una entrega temprana y continua. Entonces si te doy un producto después de 12 meses y digamos que no es bueno. Habría mucho esfuerzo, costo y tiempo en tratar de volver atrás y corregirlo de nuevo. Por lo que no dejes que suceda, entregado al cliente continuamente en incrementos. Y de nuevo, hay 12 principios diferentes. No quiero pasar por todas ellas. Puedes leerlos. Tratemos de entender aquí los conceptos clave. El primero fue la entrega temprana y continua. Y luego si bajas, habla de trabajar juntos. Por lo que la gente de negocios y los desarrolladores deben trabajar juntos. Recuerden individuos e interacciones que vimos en el primer principio básico. Segundo, confíe en las personas, recuerde de nuevo desde los valores centrales no siga proceso y contrato por confiar ciegamente en las personas y que se les ocurra el mejor producto o software. A continuación se presentan las interacciones cara a cara. Entonces otra vez, phi, lo siento, conversación cara a cara. Por lo que nuevamente los individuos y las interacciones. Entonces si te desplazas hacia abajo, tenemos software de trabajo. Entonces como hablamos antes en los valores básicos, menos documentación, más de software de trabajo. Estamos viendo software aquí, pero se puede pensar en productos también. Básicamente significa que los criterios de medición son de trabajar algo no sólo toneladas y toneladas de documentación. Entonces de nuevo, se puede leer esto a fondo línea por línea, pero la idea de un GYE, incluyendo estos principios, proviene de estos cuatro valores centrales, que son individuos e interacciones sobre procesos y herramientas, trabajando sobre documentación integral, colaboración con clientes, sobre negociación de contratos, y por último, respuesta, respondiendo al cambio sobre seguir un plan. Por lo tanto, recuerda estos cuatro valores centrales. Puedes guardarlo en algún lugar. Puedes anotarlo en tu escritorio. De hecho, en nuestros primeros días cuando empezamos a implementar un IG mucho atrás en nuestro proyecto, solíamos tener estos grandes carteles en la deuda de pared enumerando estos valores fundamentales. Y también puedes hacer lo mismo. Puedes colgarlos en un lugar donde, ya sabes, haces reuniones regulares que lo equiparan. Y es importante porque nos ayuda a recordar la importancia de la colaboración, el desarrollo incremental, etc. Y si obtienes estos conceptos, obtendrás la idea completa de wattage Alice. Entonces, bien chicos, así que todo fue por el Manifiesto Ágil. Ahora pasemos a la siguiente conferencia y veamos la definición formal de un gel. Entonces te veré en la próxima conferencia hasta entonces. Gracias. 4. Definición de ágiles: Hola a todos. Por lo que en las pasadas conferencias hablamos del enfoque tradicional de hacer las cosas. Echamos un vistazo al manifiesto de HL. Ahora veamos realmente qué es este ángel. Por lo que en su pantalla verá la definición oficial de AGI y dice, HI EL desarrollo de software se refiere a metodologías de desarrollo de software centradas en torno a la idea de entrega incremental e iterativa de pequeños trozos de funcionalidad. Somos requerimientos y soluciones evolucionadas a través colaboración entre equipos autoorganizativos multifuncionales, lo que permite retroalimentación frecuente de los clientes y corrección del curso según sea necesario. Entonces esa es la definición oficial de un gel, pero demasiado Wurtz, ¿verdad? Entonces dejemos fuera la mayor parte de ella y enfoquémonos en los términos más importantes. Entonces el primero es la entrega incremental e iterativa. Recuerda que hablamos antes los viejos métodos y el problema con ellos fue que entregamos el producto bastante tarde y luego tuvimos que hacer cambios lo cual era costoso y retrasado las cosas. Por lo que la edad ILC está entregando incremento. No tienes que hacer todo en un corto. Hacer la primera versión o MVP del producto, para luego mejorarlo en incrementos y mediante entregas frecuentes o iterativas de un pequeño trozo de funcionalidad. Por lo que diseñando las piezas pequeñas más pequeñas, entregue los incrementos en sus piezas pequeñas más pequeñas, y luego siga repitiendo todo este proceso. Siguiente concepto importante es la colaboración. Entonces como vimos antes, ningún proceso o herramienta individual individual puede adivinar todos los requisitos a la vez. Necesitamos un grupo de personas para colaborar y llegar a soluciones. Y es por eso que un equipo infantil son transversales y autoorganizativos. No hay concepto de gerente de desarrollo o gerente de pruebas dentro del equipo de Scrum. Todos son externos a su equipo. A los individuos del equipo que se sientan juntos, que trabajaron juntos, interactúan entre sí, discuten entre sí, colaboran entre sí. Y el diseño de productos y servicios útiles para el cliente. Y el último aspecto, retroalimentación y corrección del curso. Entonces recuerden, seguramente vendrán cambios. Serían necesarias correcciones. Por lo tanto, mantener una retroalimentación continua con el cliente. No queremos, ya sabes, llegar al cliente después de tres meses o seis meses para recabar sus comentarios. Queremos hacer es más pequeño, pequeños incrementos. Queremos mostrar el producto al cliente. Queremos reunir sus comentarios y hacer correcciones según sea necesario. Entonces estas cinco cosas que ves resaltadas en la pantalla, eso es lo que h l es. Ahora recuerda, no quiero que recuerdes toda esta definición palabra por palabra. Y de hecho, no les pediré que memoricen las cosas palabra por palabra en ninguna parte del curso. Simplemente recuerda las palabras clave que se resaltan en tu pantalla en la definición. Y si acudes a alguna entrevista o a cualquier organización y alguien te pregunta ¿qué es un gel? Puedes contar tu propia versión incluyendo estas palabras clave. Una vez que la otra persona escuche estas palabras clave, sabrán con certeza que usted entiende. Hola. Entonces ese es el enfoque que seguiremos a lo largo de este curso. Me aseguraré de que entiendas las cosas clave y no tengas que memorizar ninguna cosa. Entonces esta fue la definición de un gel chicos. Y básicamente es un ciclo de planear cosas, diseñarlas, tomar retroalimentación, revisar del cliente y lanzar la cosa y luego rehacerla una y otra vez en iteraciones. Entonces dat es todo hl es el diagrama único. De acuerdo, así que estoy seguro que sabes, sabes lo que es HFile, su manifiesto, sus conceptos centrales. Entonces hablemos de la parte de implementación, y hablemos de un Scrum en la próxima conferencia. Gracias. 5. Definición de Scrum y su diferencia de ágil: Hola a todos y bienvenidos de nuevo. Entonces hablemos de nuestro próximo tema, que es un Scrum. Entonces, ¿qué es exactamente este scrum? Ahora hablamos de H L, y muchas veces usamos Scrum y edad IL juntos en el mismo contexto. Pero recuerda que en realidad son dos términos diferentes. Is Scrum es un marco de gestión de proyectos ágil que los equipos utilizaron para desarrollar y entregar productos complejos. Entonces si bien un niño es un conjunto de valores y principios, es Scrum es la forma de implementarlo. Sólo recuerda esta cosa. H L es un conjunto de valores y principios y un Scrum es la forma de implementarlo. Y recuérdalo. Scrum es un enfoque incremental e iterativo. Entonces, recapitulemos sobre estas dos palabras. Incremental significa que estamos construyendo y entregando el producto en sus pequeñas piezas. Y la iteración significa que estamos haciendo algo y después refinándolo aún más. Entonces al igual que hablamos de software, hacemos un producto inicial y luego los refinamos iterativamente. Hacemos ciclos de duración dos semanas o cuatro semanas. Y en cada uno de estos ciclos, agregamos incrementos de nuevas características y detalles al producto inicial. Estos ciclos en realidad se llaman como un Sprints y hablaremos de ellos en detalle más adelante. Pero por ahora, recuerda que el objetivo de Scrum es desarrollar productos en cada pequeños ciclos de dos o cuatro semanas llamados como Sprints. Y en cada sprint agregamos nuevas características, agregamos nuevos incrementos encima de los existentes. Esa es la salida de cada sprint. Ahora hay términos adicionales, personas, proceso, etcétera, que también definió es Scrum. Y no te preocupes, aprenderemos más adelante sobre cada uno de ellos a detalle. Pero en resumen, de esto se trata Chrome. Se trata de un framework H L incremental e iterativo para entregar y desarrollar productos complejos. Eso es todo lo que es Scrum. Ahora un último punto antes de seguir adelante es Scrum se utiliza con mayor frecuencia en el desarrollo de software. Y hablamos de referencia de datos principalmente en este curso. Pero recuerda es Scrum es igualmente utilizable en otras industrias como manufactura u otros negocios también. Entonces si vienes de ese fondo el discurso y el descontento es igualmente significativo para ti. Por lo que espero que quede claro en la definición de un scrum. Ahora, pasando, veamos cómo HI AL y Scrum son diferentes. medida que pases por esta lista, notarás que no hay una diferencia demasiado grande de significado. Esa distinción es más de qué y cómo sentido. Entonces de lo que habla SU es miga hace eso. Ahora ya sabemos la primera y principal diferencia y siempre recordamos que un niño es la metodología para el desarrollo y un Scrum es el marco para implementarlo. Entonces hl es el valor central, h l es el principio básico de hacer cosas de desarrollo y un Scrum es su implementación. En segundo lugar, HL es adecuado para un equipo pequeño y experto, mientras que el Scrum es adecuado para requisitos de cambio rápido debido a su aspecto de control de procesos. Siguiente punto, el liderazgo juega un papel clave en HDL, pero cualquier decisión de Scrum las toma equipo. Entonces como mencioné antes, también, no hay mánager, no hay líder de equipo dentro del equipo Scrum. Hay un dueño de producto, hay un Scrum Master, hay un equipo de desarrollo. Todos se sientan juntos, colaboran, sí discutieron el interactuar, y así resolvieron los problemas. En cuarto lugar, en la misma línea, HI EL promueve la colaboración y la interacción entre equipos. Vimos esto en el valor central. Ahora es miga hace eso a través de algo llamado un stand up meetings diarios. Entonces es un encuentro diario de individuos que trabajan en el Scrum y es un dinero de HL7, hablaremos de ello en el capítulo posterior, pero así es como ocurre la colaboración en esta miga. A continuación, HL habla de entrega y actualizaciones de manera iterativa. Nuevamente, es miga también ¿por qué sprints? Por lo que estas impresiones, como mencioné antes, son el corazón de todas las actividades en su Scrum. Si estás trabajando en algún Scrum o si trabajarás en algún Scrum adelante, oirás cosas como, vale, lo haremos en este sprint, lo haremos en el próximo sprint. Nos llevaremos dos sprints para hacerlo. Porque como dije, estos sprints son donde toda la acción, todo el trabajo pasa en el Scrum. Y último punto, h l promueve retroalimentación continua. Lo vimos antes. Es migaja también hace deuda vía algo llamado demo sprint. Al final de cada sprint. El demo también es una ceremonia de scrum y hablaremos de ello a detalle más adelante. Por ahora, solo debes saber que se hace después de cada sprint para mostrar el producto y recopilar retroalimentación, esa metodología de retroalimentación continua. Entonces chicos, esa es la diferencia clave entre cada isla es Scrum. Y de nuevo, no necesitas recordar todo esto, solo recuerda el número uno, HI, y Scrum son diferentes. Número dos, h L es una metodología. Se guía por un conjunto de valores y principios fundamentales que vimos. Y Scrum es un enfoque basado en HL. Es sólo una implementación de HAL. De acuerdo, entonces en la próxima conferencia, hablemos más de Scrum. Entonces te veré en la próxima conferencia hasta entonces. Gracias. 6. Ciclo de vida de Scrum: Hola a todos. Entonces ahora sabemos lo que es Scrum. Veamos cómo funcionan las cosas ahí dentro. Y lo que se ve en la pantalla son los escenarios que juntos conforman el ciclo de vida de Scrum. Ahora sólo vamos a hablar brevemente de ellos aquí porque tenemos un capítulo dedicado sobre estos más adelante. Entonces vamos a echarles un vistazo rápido. Pero antes de recoger estos, pensemos en cómo trabajamos en nuestra vida diaria. Y si entiendes esto, obtendrás la idea de Scrum también. Entonces queremos hacer muchas cosas en nuestra vida, ¿verdad? Ahí hay como una gran lista de cosas que queremos hacer o tenemos que hacer. De esa gran lista, elegimos cinco cosas que queremos hacer esta semana. Por lo que queremos ir a algún lugar. Queremos comprarnos algo, queremos conocer a alguien, etcétera. Estamos sacando a cinco cosas, ¿verdad? Y luego hacemos esas cinco cosas a lo largo de la semana. Al final de semana, recapitulamos sobre cómo lo hicimos, si podríamos haber hecho algo mejor, etcétera. Y luego volvemos a abrir nuestra gran lista de cosas y escogemos las próximas cinco cosas que tenemos que hacer en la próxima semana. Así es como trabajamos como individuo, y así es exactamente como funciona un scrum. Por lo que tenemos una gran lista de requisitos que llamamos como el rezago del producto. Es sólo una gran lista de cosas que hay que hacer. Hacemos una reunión de planeación y de papá listas grandes elegimos como cinco o diez requisitos dependiendo de la disponibilidad o capacidad de los equipos. Y los llamamos como el rezago del sprint. Ahora trabajamos sobre ellos en el siguiente ciclo de dos o cuatro semanas que se llama como sprint. Si bien estamos en este sprint, cada mañana hacemos una reunión diaria para discutir los avances que se convoca como reunión de stand-up. Y una vez que este es el sprint termina, nosotros la demo número uno, lo que sea que le hicimos a las partes interesadas para obtener su retroalimentación. Y número dos, retrocedemos como equipo lo que fue bueno y lo que pudo haber sido mejor en el último sprint. Y luego repetimos todo esto nuevamente en forma de un nuevo sprint está empezando con una nueva reunión de planeación de sprint. Entonces dijo papá, todo este ciclo es lo que todo es Scrum. No hay forma más sencilla de entenderlo. Ahora aquí es lo mismo en forma de gráfico. Por lo que tenemos el rezago del producto, que aprendimos es una gran lista de requisitos que el equipo se reúne para una reunión de planeación y elige una lista más pequeña de la misma llamada “sprint backlog”. Lo harán en este sprint. Y una vez más, no te preocupes por los detalles más finos de cómo lo hacemos. Veremos esos más adelante en el detalle completo. Pero en esta conferencia sólo estamos arañando la superficie de las cosas. Por lo que elegimos un pequeño subconjunto de requisitos para hacer eso se llama el atraso de sprint. Desarrollamos y probamos esas cosas en el sprint de dos o cuatro semanas. Y luego vamos por una demo con las partes interesadas. Vamos por una retrospectiva con todo el equipo. Y también podemos liberar este incremento a los usuarios finales. Descarga tan bastante simple que se ve aquí es todo el scrum a un alto nivel. Estas otras tareas que se ven aquí, el dueño del producto, el equipo, el scrum master. Estos se llaman como las reglas de Scrum y veremos de ellos más adelante. Y luego hay diferentes reuniones o ceremonias que hacemos en el Scrum para juntar todo esto y vamos a echar un vistazo a los datos también más adelante. Pero esto aquí mismo en tu pantalla es la imagen de alto nivel. Y una vez más, si lo miras, vuelve a bajar a sólo tres palabras. Iterar todo el proceso que estamos haciendo una y otra vez. Entregar incremento al usuario final, tomar retroalimentación e incorporar ese conjunto. Entonces dat era chicos es miga En pocas palabras. Ahora antes de repasar los aspectos que vimos aquí con mucho detalle más adelante, veamos un último tema de este capítulo en la siguiente conferencia. Gracias. 7. MVP y enfoque incremental: Hola a todos. Entonces hablemos un poco de MVP y enfoque incremental en esta conferencia. Ahora seguimos viendo que h l se trata de incrementos. Entonces, ¿cómo funciona ese concepto de incremento? Echemos un vistazo y sabes qué, vamos a entenderlo primero, ¿por qué una imagen? Y luego volveremos a estas diapositivas. Entonces chicos, lo que ven en la imagen es lo que significa MVP o producto mínimo viable. Recuerda no esta parte superior, la inferior, le damos al cliente un mínimo, algo que cumpla con sus requisitos. Dejamos que lo usen. Tomamos su retroalimentación y luego mejoramos en ella en los próximos incrementos. Y seguimos repitiendo todo este ciclo, entregando nuevos incrementos en el proceso. Ahora recuerden la parte superior de la imagen es el enfoque tradicional, como la cascada, donde estamos dando cosa al cliente en incrementos, pero no pueden usarlo como si no pudieran usar solo dos piezas de Tiro. No pueden dar retroalimentación al respecto. Y para cuando el producto final esté listo, habría muchas cosas que querrían cambiar. Y luego terminaríamos con el mismo problema que hablamos antes con el enfoque tradicional. Entonces eso está bien. Hola l Lo que estamos haciendo es que estamos dando al cliente patineta estado para que puedan viajar. Entonces vendrán con la retroalimentación que OK, quiero algo más rápido y con unas opciones de sentado. Por lo que les daremos una bicicleta. Entonces volverán de nuevo con la retroalimentación de que quiero algo que no tome ningún esfuerzo que sea un más rápido, así que les daremos un motociclo o un auto y así sucesivamente. Por lo que en cada incremento, estamos dando a los clientes algo que pueden usar, algo sobre lo que pueden dar retroalimentación. En base a eso, estamos mejorando el producto. Entonces eso son chicos, lo que MVP es el producto mínimo viable. Damos una versión inicial del producto al cliente que pueda utilizar. El obtener su retroalimentación. Lo mejoramos en los próximos incrementos e iteraciones. Por lo que se basa en el enfoque de construir, medir y aprender, lo que significa que estamos construyendo algo. Estamos tomando la retroalimentación y la estamos revisando, mediéndola. Estamos aprendiendo de esa retroalimentación y estamos haciendo cosas nuevas. Y de nuevo, chicos, si lo piensan, este concepto subyacente es de nuevo, iteración e incremento. Construimos el producto, medimos la retroalimentación, aprendemos de él y lo hacemos todo de nuevo. Entonces ese es todo el concepto y es importante entender porque este es el panorama más grande de Hl y es miga. Recuerda que no podemos hacer las cosas en un solo corto. Eso significaría cometer los mismos errores que hicimos con el enfoque tradicional. Por lo que nos reunimos como un equipo colaborativo. Hacemos cosas en iteración. Diseñamos el MVP inicial. Le ponemos mejoras incrementales y de eso se trata. Eso es todo lo que hay que entender. Impresionante. Entonces ahora estamos al final de este capítulo y aprenderemos aquí los conceptos básicos. Aprendimos qué edad tengo l, qué es Scrum es un alto nivel de cómo operan y cómo funciona todo el incremento MVP. Seguiremos estos aprendizajes al siguiente capítulo y veremos todos estos y más concepto en detalle. Entonces va a ser un viaje de aprendizaje muy emocionante. Pero antes de terminar este capítulo, sólo quería dejarlos con dos pensamientos que son más importantes para alguien que trabaja en VIH. Entonces el primer pensamiento es que h L no es sólo un libro de guía. Lo más importante es una mentalidad. Si somos pensamientos altamente numéricos, Si somos edad Eileen, nuestro trabajo, nuestra colaboración con su equipo, sólo entonces podremos implementar con éxito un gel o un Scrum. Entonces piensa en HCI como una mentalidad que es lo más importante. Segundo, SU o un scrum no es un palo mágico que va a resolver todos nuestros problemas. Nos puede mostrar cuáles son los problemas o cuáles han sido los problemas con la industria. Pero nos toca llevar la mentalidad ágil, trabajar juntos en equipo para resolver esos problemas y entregar un producto excepcional al usuario final. Entonces nuevamente, los dos conceptos, mantener una mentalidad infantil y segundo, usar la edad IL-2. Conoce tus problemas. No es un palo mágico que pueda resolver todos tus problemas. Entonces chicos, con este pensamiento, pasemos al siguiente capítulo y aprendamos algo que se conoce como los roles de Scrum, las personas que conforman el Scrum. Entonces te veré en la próxima conferencia hasta entonces. Gracias. 8. Introducción a los rolos de Scrum y los actores de Scrum: Hola a todos y bienvenidos al tercer capítulo del curso. Ahora iniciando este capítulo, vamos a escoger uno por uno, los temas que discutimos en el último capítulo. Y vamos a ir en profundidad a ellos para conocer todos los detalles. Entonces ese tema que vamos a cubrir en este capítulo son las personas que conforman un equipo de Scrum, más comúnmente conocido como los roles de Scrum. Y elijo primero este tema en particular porque como vimos en el último capítulo, el primer valor central de h l dice individuos e interacciones sobre procesos y herramientas. Por lo que los individuos son el componente más importante de un equipo de Scrum. Y así sepamos primero sobre ellos en este capítulo. Y saben qué, vamos a cubrir este capítulo de manera muy interactiva. De hecho, vamos a llamar al pueblo los papeles de Scrum como nuestros amigos y los vamos a conocer uno por uno y saber cuál es su trabajo, cuáles son sus responsabilidades, etcétera. Entonces, empecemos. Y aquí está la agenda de este capítulo. Por lo que hablaremos de los siguientes roles. Ellos estaca titulares, el Dueño del Producto, el equipo de desarrollo, The Scrum Master. Y por último, discutiremos la dinámica del equipo scrum. Entonces, ¿cuál es el vínculo y la relación entre ellos? Entonces, empecemos. Entonces chicos, estos son los diferentes roles de Scrum o la forma en que lo llamamos en este curso, nuestros amigos en el Scrum está empezando desde abajo a la izquierda. Tenemos a los titulares de participaciones que son externos a un equipo de Scrum, pero tienen los requisitos de negocio en los que trabaja 13. Después tenemos al dueño del producto que es como el capitán del equipo. Él o ella decide qué tiene que hacer el equipo y él establece prioridad de las cosas. Después tenemos al equipo de desarrollo que hace el trabajo de codificación o prueba. Y finalmente tenemos al maestro scrum que es como el guardia del equipo. Y él o ella se asegura de que el equipo siga sea miga efectivamente y no estén blogueados en nada. También chicos, en la extrema derecha, tenemos al usuario final para el que se está haciendo todo el trabajo. Entonces aunque no es un rol de Scrum, sigue siendo, es muy importante tener siempre en cuenta al usuario final porque él o ella es el para quien está haciendo todo el trabajo y preocuparse su requerimiento y retroalimentación es muy, muy importante. Entonces empecemos y echemos un vistazo a nuestra primera regla, nuestro primer amigo, yo los titulares de estaca. Entonces, ¿quiénes son los titulares de las participaciones? Bueno, un Stakeholder es en primer lugar alguien que es externo al equipo scrum. Y en segundo lugar, quién tiene un interés o requisito o conocimiento del producto que se está creando. Por lo tanto, piense en el titular de la participación como el equipo de gestión de productos en su empresa que está recibiendo requisitos del usuario final y pasándolo al equipo de scrum. O alguien en ventas, o incluso el director general de la empresa podría ser titular de una participación. Cuando estamos trabajando en la página de términos y condiciones, el chico del departamento legal será titular de la participación porque él o ella proporcionará el texto a escribir. Cuando se está diseñando un flujo promocional, el miembro del equipo de marketing será un Stakeholder porque él o ella utilizará el sistema. Y si el equipo de Scrum está trabajando en algo y toman ayuda de una persona en otro equipo porque él o ella tiene más conocimiento de deuda. Eso también es un Stakeholder. Por lo que todos estos son como diferentes stakeholders y estos titulares de estaca revelan su diseño, producto o software. Y proporcionan la retroalimentación, ya sea viniendo directamente de ellos o del usuario final. Y esto nos ayuda a crear un producto mejor y valioso. Entonces chicos, papás el significado del titular de la estaca. Tan sólo para recapitularlo rápidamente, él o ella es externo al scrum. Tiene un requisito de interés o conocimiento del producto. Y por último, él o ella ayuda a proporcionar insumos para crear un mejor producto para el usuario final. De acuerdo, entonces ahora que sabemos quién es el interesado, veamos el otro rol de Scrum o amigos en la próxima conferencia. Gracias. 9. Propietario de productos: roles y responsabilidades: Hola y bienvenidos de nuevo. Hablemos de nuestro próximo amigo en el Scrum. Entonces los chicos en tu pantalla es Kevin, y Kevin es nuestro dueño del producto. rol de Scrum del que vamos a hablar en esta conferencia es el dueño del producto, o PO En resumen. Ahora el dueño del producto es un papel muy importante en el equipo de scrum porque él o ella es como el líder del equipo y la voz de los clientes necesitan a su equipo. Kevin aquí es responsable de asegurarse de que ese equipo entregue productos valiosos a los usuarios finales o a las partes interesadas. Kevin también tiene que definir metas y visión creativa del producto. Entonces el equipo scrum que está liderando, los desarrolladores finales o probadores, no saben del producto, para qué está destinado, ¿cuál es el requisito a cumplir? Ellos sólo conocen de los aspectos técnicos. Por lo que Kevin tiene que definir esos requisitos de negocio al equipo. Tiene que traducir esos requerimientos de negocio en la forma en que la deuda que el equipo entiende y sabe lo que se tiene que hacer. Además, Kevin tiene que gestionar el rezago del producto. Por lo que vimos en el último capítulo que el Retraso de Productos es como una gran lista de requisitos que hay que hacer. El cometido de administrar esa lista es con el propietario del producto. Tiene que crear requisitos en el rezago conocido ha conocido como historias de usuario, tiene que escribir los requisitos de bajo nivel o criterios de aceptación en ellos. Tiene que modificar los requisitos, eliminarlos, priorizarlos, etc. Y de hecho, esta es una de las responsabilidades más importantes de un propietario de producto. Los datos son para mantener el rezago del producto. Siguiente punto. Siguiente responsabilidad es manejar la prioridad de las cosas en términos de tiempo, el dinero es alcance, etcétera. Tan bastante claro. Listo, Importante tarea otra vez. A continuación, Kevin tiene que supervisar el desarrollo real del producto. Por lo que tiene la configuración de rezago, tiene el presupuesto despejado. Ahora tiene que asegurarse de que el trabajo real de hacer que el producto suceda sea sin problemas. Entonces esto, esto significa trabajar con el equipo de desarrollo, hacer una planeación de sprint para arreglar la agenda del sprint. Contestar cualquier consulta deuda que el equipo tenga apoyo a su trabajo, etcétera. También significa trabajar con los interesados para planificar las próximas adiciones incrementales al producto o a la liberación, etcétera. Quinta tarea, Kevin tiene que anticipar las necesidades de los clientes. Entonces nuevamente, para reiterar, todo el trabajo que estamos haciendo en el equipo es para el cliente, el usuario final, y el dueño del producto tiene que entender lo que necesita el cliente. Muchos requisitos de los usuarios provienen de los titulares de las participaciones, pero estarán en un nivel alto, cómo implementarlo mejor, cómo leer la mente del cliente, cómo predecir cualquier riesgo que puedan tener. Todo el, todo esto es el trabajo diario de un propietario de producto y una tarea muy importante. A continuación, Kevin, el propietario del producto, tiene que actuar como enlace entre las partes interesadas, el equipo de scrum, o incluso los usuarios. Por lo que es el comunicador principal del equipo. Se comunica con los chicos externos. Se comunica con los chicos externos. Es el comunicador del equipo. Y por último, Kevin es responsable de cada iteración e incremento del producto. Por lo que tiene que asegurarse de que haya suficiente mejora, fin de progreso que se está haciendo con cada iteración, la llamada final a la calidad del desempeño del producto, etcétera. Es con el dueño del producto y tiene que decidir si el equipo puede avanzar o necesita volver atrás y rehacer las cosas. Entonces chicos, en tu pantalla, lo que ves son los papeles y responsabilidades primordiales del dueño del producto. Ahora antes de concluir un punto más, recuerda muchas veces podría haber un analista de negocios también en su equipo que descargará parte del trabajo del propietario del producto. Por lo que el analista de negocios y el propietario del producto roles y responsabilidades se superponen un poco. Él o ella puede tomar parte del trabajo que hace el dueño del producto. Está bien, así que como vimos, el dueño del producto es un papel muy importante en el equipo de scrum. Y el dueño del producto es quien tiene que hacer malabares entre muchas responsabilidades. Tan sólo para recapitular aquí es trabajar con las partes interesadas de un lado, el equipo scrum del otro lado. Tiene que conseguir los requisitos, traducirlos. Y él es quien en última instancia tiene que asegurarse de que todo el proceso scrum esté agregando valores incrementales en beneficio del usuario final. Tan papel muy importante, muchas responsabilidades en nuestro amigo Kevin aquí. Genial. Entonces ahora que sabemos del dueño del producto, echemos un vistazo a otro papel en la próxima conferencia. Gracias. 10. Equipo de desarrollo: roles y responsabilidades: Hola a todos y bienvenidos de nuevo. Hablemos de nuestros próximos amigos en Scrum. Entonces saluda a Andrew y Karen. Andrew es desarrollador en el equipo y Karen es la QA o probador. Y a ambos se les conoce como el Equipo de Desarrollo. Entonces sólo una nota rápida aquí, aunque el equipo de scrum contiene diferentes roles, como desarrollador o un probador, o diseñador o desarrollador senior o probador senior es miga no los llama separados. Todos ellos son recién conocidos como equipo de desarrollo porque están desarrollando el producto según las necesidades del Propietario del Producto. Por lo que estas son las personas que se encargan de entregar el producto final. Y esa es su responsabilidad de alto nivel sólo de resumir las cosas en una frase. Pero considerémoslo con más detalle. La primera responsabilidad de Andrew y Karen es entender las historias de los usuarios que son escritas por el propietario del producto. Tienen que implementar estas historias. Por lo que obviamente tienen que saberlo cuando el equipo se reúne para la planeación del sprint o el aseo de atraso. Y veremos estas ceremonias en detalle en capítulo posterior, el equipo de desarrollo tiene que asegurarse de que entiendan plenamente lo que es el usuario. Dice la historia, lo que quiere el Dueño del Producto, cuáles son los requisitos exactos para que las cosas puedan diseñarse de la misma manera. Al día siguiente también proporcionan insumos en la creación de las historias de los usuarios. Y recuerda que estos son solo entradas el equipo de desarrollo generalmente no crea un usuario es historia, Ese es el trabajo del tóner de producto. Pero pueden seguir astillando con insumos o sugerencias, etc. Si se trata de una historia puramente técnicamente, entonces querida entrada probablemente se tome como la llamada final. Pero la responsabilidad principal de crear historias de usuario es con el propietario del producto. El equipo de desarrollo sólo lo apoya. Tercera responsabilidad de nuestro amigo Andrew y Karen es estimar las historias de los usuarios. Por lo que la estimación es un gran tema en un scrum y tenemos un capítulo dedicado sobre eso más adelante. Por ahora, solo debes saber que el equipo de desarrollo proporcionará sus estimaciones para la historia del usuario para que el dueño del producto sepa cuánto trabajo se puede entregar en un sprint. En cuarto lugar, el equipo de desarrollo se comprometerá con las historias de los usuarios que se hagan en un sprint. Y este compromiso viene después de la planeación del sprint. Y es algo que el equipo de desarrollo tiene que ser honesto también, y aseguró que se cumpla ese compromiso. El siguiente punto es el aspecto de trabajo. Entonces escribiendo código o probando las historias de usuario que se tomaron y asegurando que la entrega del producto de calidad al usuario final. De hecho, esta es la mayor parte del trabajo del equipo de desarrollo y aquí es donde su mayor tiempo y esfuerzo irán cada sprint. Por lo que son los que estarían traduciendo los requisitos en un trabajo efectivo. Muy bien, entonces tenemos la responsabilidad de identificar el riesgo. Y siempre que decimos riesgo, tiene que incluir también la mitigación. Entonces si algo no se puede hacer, Algo corre el riesgo de que no se complete. El equipo de desarrollo tiene que elevarlo al maestro de scrum o al dueño del producto para que puedan ayudar a resolverlo. Y la responsabilidad final es empujar los cambios a la producción para que equipo diseñe mejoras de calidad después de que griten es sprint termina o cuando el dueño del producto quiera, el equipo tiene que empujar esos incrementos, esos cambios en el entorno vivo para que el usuario final pueda usarlo y se pueda poner en uso todo su arduo trabajo. Muy bien, chicos. Por lo que estos fueron algunos de los roles y responsabilidades de Andrew y Karen, nuestro equipo de desarrollo. Y solo para resumir una vez más en una frase, el equipo de desarrollo son los que entregan el producto final conforme a los requisitos proporcionados por el propietario del producto. De acuerdo, pasemos al último papel ahora, que es el Scrum Master. Entonces veamos eso en la próxima conferencia. Gracias. 11. Scrum Master - roles y responsabilidades: Hola a todos y bienvenidos de nuevo. Hablemos del papel de Scrum Master. Ahora, cuando pensamos en los roles de Scrum, el primer término que nos viene a la mente es de un Maestro Scrum. Pero ya sabes, guardé esto intencionalmente para el fin de que sepamos cuáles son los otros roles. Y luego podemos ver cómo el Maestro Scrum ayuda a facilitar el trabajo para todos ellos. Entonces chicos, este de aquí es nuestro amigo Bob, quien es el Scrum Master del equipo. Y te diré lo que Bob tiene un papel muy interesante en el equipo porque tiene que apoyar al equipo. Tiene que asegurarse de que ese equipo siga es miga mejores prácticas. Y también hay que asegurarse de que los integrantes del equipo no estén blogueados en nada. Por lo que el primer punto de bala que notarás sobre Bob es que es el líder sirviente para el equipo scrum. Y lo que eso significa es que tiene que seguir un estilo de liderazgo solidario. Tiene que apoyar al equipo, sirviendo los diferentes roles en el equipo. Está sirviendo al Dueño del Producto en muchas cosas. Está sirviendo al equipo de desarrollo y también está sirviendo a la organización adoptando con éxito a un niño. Entonces por eso, como dije, es Scrum Maestro es un líder sirviente. Es uno de los papeles más importantes y amplios en el equipo. El Maestro Scrum ayuda al Dueño del Producto en la planificación del trabajo con el equipo para que se cumplan los objetivos de entrega del Propietario del Producto. Y también ayuda al Dueño del Producto en la gestión del rezago de requisitos. Es efectivo y actualizado. A continuación, el Scrum Master se asegura de que todos en el equipo entiendan los objetivos y alcances de trabajo que se requiere. Por lo que estas son las formas en que el Scrum Master ayuda al propietario del producto. Él lo ayuda con el rezago y ayuda a definir las metas y alcance de la deuda con todos en el equipo. Por lo que todo el mundo está en la misma página y hace el trabajo que el dueño del producto quiere. A continuación, hablemos de las formas en que Bob, el Scrum Master, está ayudando al equipo de desarrollo. Por lo que es responsable de asegurarse de que el equipo no esté bloqueado. No se distraen por interrupciones externas u otras distracciones y que sean capaces de trabajar en los compromisos de sprint. Y este es un trabajo muy importante chicos porque ustedes saben que el equipo se ha comprometido con un conjunto de trabajo para el sprint. Y si están siendo desviados o distraídos que eso, trabajo se verá obstaculizado con seguridad. Entonces es tarea de un Maestro Scrum asegurarse de que eso no suceda. El equipo es capaz de enfocarse en sus compromisos. mismo tiempo es Scrum Master también asegura que el equipo no está sobrecargado. También lo hacen durante una planeación de sprint, el maestro scrum comprueba las estimaciones y planeación de capacidad para asegurarse de que todos tengan suficiente trabajo, pero nadie tenga exceso de trabajo. Por lo que estas son las formas en que el Scrum Master's sirve al equipo de desarrollo. Y por último, el Scrum Master es el HAL Coach de las organizaciones. Por lo que Bob aquí tiene que organizar las diferentes es ceremonias de miga. Al igual que se ponen de pie, se esprint, planeación, retrospectiva, etcétera. Y veremos estas ceremonias a detalle más adelante. Pero por ahora, el Maestro Scrum es el facilitador, el organizador de todas estas ceremonias. Y por último, tiene que asegurarse de que el scrum se siga efectivamente en la organización. Y tiene que asegurarse de que las mejores prácticas sean diploides. Por lo que estos son el aporte del Maestro Scrum hacia la organización. Para resumirlo, todo como dije, es Scrum Master es un papel con un conjunto muy amplio de responsabilidades. Cuando hablamos de trabajar en un scrum o H L y hablamos de sus beneficios. Esos beneficios sólo sucederán cuando se esté siguiendo eficazmente a un niño o a un Scrum, cuando las personas puedan trabajar eficazmente sin distracciones. Cuando la visión del propietario del producto se transfiere al equipo y el trabajo de un Scrum Master para asegurarse de que todo eso suceda. Entonces como puedes entender la importancia de Bob, el Scrum Master es mucho en el equipo. De acuerdo, ahora que conocemos todos los diferentes roles en un equipo de Scrum, hablemos un poco de su unión y de trabajar juntos. Eso se trata de la dinámica del equipo en la próxima conferencia. Gracias. 12. Dinámica de equipo de Scrum: Hola a todos y bienvenidos de nuevo. Entendamos el concepto de la dinámica de equipo Scrum. Por lo que sabemos que un equipo de Scrum tiene un propietario de producto, un analista de negocios Equipo de Desarrollo, Scrum Master. Entonces, ¿cómo se unen estos tipos para trabajar juntos como una sola unidad? ¿ Cuál es la sinergia que los une? La respuesta a todo esto es, nuevo, lo que vimos en el capítulo anterior. El primer valor básico de la deuda son los individuos y las interacciones sobre los procesos y herramientas. Y esto es lo que impulsa la dinámica del equipo. Por lo que vimos antes que es Scrum los equipos son auto organizativos y autogestionados. Eso significa es que los equipos de Scrum no deben regirse por métodos antiguos. No hay gerente de desarrollo o gerente de pruebas dentro del equipo de scrum para controlar los recursos o estimar cosas que equipo efectivamente gerentes en sí mismo. El equipo estima por su trabajo. Le dicen al dueño del producto cuánto tiempo tomará, quién hará la tarea, etcétera, y honran sus compromisos. Siguiente punto, el Maestro Scrum está ahí para actuar como facilitador para organizar las cosas. Y como vimos, esa es una de las responsabilidades de un Maestro Scrum. Pero ya sabes lo que el equipo no debe depender del todo de un maestro scrum. Salvemos el Scrum Master está de licencia, un día sigue siendo entonces el equipo debe reunirse y hacer su stand diario. Porque el concepto, recordar chicos es de autogestión, de interactuar, colaborar entre sí, no al donante de producto o a un Scrum Master no depender de ellos. tercer punto es que los equipos de Scrum triunfan o fallan como todo un equipo. Entonces cuando hablemos de la edad de los informes de la OIT en el capítulo posterior, veremos que los equipos son evaluados en cuanto son storypoints que se entregan, cuántas historias cerraron, cerraron, etc. Entonces es la salida del equipo que reservó el equipo, no los individuos, al igual que tenemos en los deportes. De hecho, la palabra es Scrum en sí viene de los deportes del rugby. El siguiente punto es que los equipos de Scrum son transversales. No van por títulos. Entonces como vimos antes también, hay un solo equipo de desarrollo. No hay desarrollador, arquitecto, probador, diseñador, etc.. No hay categorización si es necesario, el desarrollador también debe hacer esa prueba. El probador puede retomar el trabajo de BA, etcétera. Quinto, y estamos hablando de cultura a partir de aquí. Entonces es algo cultural. I Scrum equipos típicamente R es más pequeño en tamaño, es decir alrededor de nueve a 12 personas es un muy buen número y todo este equipo se sienta juntos. No hay concepto de aislamiento, no hay concepto de cabinas separadas. Ese equipo se sienta juntos. Se sientan cerca el uno del otro, por lo que hay un enlace entre el equipo, un ambiente abierto para la discusión. Y último punto es una cultura de comunicación efectiva en el equipo. Por lo que hay un stand diario por la mañana. Equipo se sientan juntos, discuten sobre cosas que se comunican entre sí es equipos Scrum tienen un nombre de equipo, nuestro manifiesto de equipo, etcétera. Y todo esto ayuda a crear un enlace, una sinergia entre su equipo. Entonces chicos, estos fueron algunos de los puntos para lograr la dinámica de equipo porque recuerden, HI, o es Scrum es todo sobre individuos e interacciones. Por lo que es muy importante que los equipos trabajen juntos y entreguen un producto excepcional al cliente. Está bien, así que esto nos lleva al final del capítulo, pero vamos a aprender algunas cosas geniales aquí. Conocimos a nuestros amigos en el Equipo Scrum. Aprendimos cómo funciona la dinámica del equipo. Ahora en el siguiente capítulo, vamos a hablar de sus encuentros, sus interacciones en lo que se conoce como las ceremonias de Scrum. Entonces los veré en el próximo capítulo. Gracias. 13. Trato de troncos e introducción a las ceremonias de Scrum: Hola a todos, y bienvenidos al cuarto capítulo del curso. Por lo que hasta ahora hemos aprendido las definiciones de Agile y Scrum. Y hemos visto las diferentes reglas, todos los individuos que conforman el equipo scrum. Ahora en este capítulo, hablemos de los diversos encuentros en los que participan estos roles, y eso se conoce como las ceremonias de Scrum. Ahora, antes de seguir adelante, sólo para recapitular una vez más, es Scrum se basa en los conceptos de iteración e incrementos. Entonces un Scrum se trata de repetir iteraciones llamadas sprints, en las que diseñamos incrementos para el usuario final. Y para manejar estos sprints de manera efectiva. Para ejecutar estos sprints de manera eficiente, hay una secuencia de reuniones o ceremonias que suceden. En este capítulo, vamos a hablar estas ceremonias y en el orden en que suceden. Entonces obtienes la secuencia lógica de las cosas. Y al final, los veremos juntos y luego entenderemos todo el ciclo es de migajas. Entonces, empecemos. Entonces chicos, aquí están los contenidos de este capítulo y estos no son más que diferentes son las ceremonias de miga. Ahora en uno de los capítulos anteriores, hablamos un poco sobre el ciclo de vida de Scrum. Y ahí mencioné cómo es muy similar a cómo planeamos las cosas en nuestra vida diaria. Entonces si consigues eso, obtendrás el propósito de estas ceremonias también. Entonces escúchame y mira el puntero del ratón en consecuencia para ver cómo se relaciona con Scrum. Entonces chicos, pensemos en cómo trabajamos en nuestra vida real. ¿ Cómo manejamos las cosas en nuestra vida real? Entonces escribimos una gran lista de cosas que queremos hacer en nuestra vida. Y luego tomamos un pequeño subconjunto de la misma que decidimos lograr en digamos, la próxima semana o dos semanas, etc.. Pensaríamos en todos los días, cuánto hemos logrado en este objetivo, si se necesitan algunas correcciones, si algo nos está bloqueando, etcétera. Y luego cuando termine la semana, tomamos un recapitulación de cómo las cosas cuando hacemos la corrección del curso, y luego repetimos todo de nuevo la próxima semana con una nueva lista. Suena familiar, ¿verdad? Y déjenme decirles chicos lo que hacemos en el Scrum es totalmente similar a esto. Como habrías adivinado. Tomamos un atraso o una gran lista de requisitos, escogemos un pequeño subconjunto del mismo, trabajamos en ello en el sprint. Una vez que termina el sprint, demostramos el trabajo a nuestros grupos de interés para que podamos llegar allí retroalimentación rápida. Después hacemos una retrospectiva de las cosas para mejorar. Y empujamos los cambios al usuario final si es necesario. Y luego repetimos todo esto una y otra vez. Eso es todo lo que es. Ese es todo el ciclo de sus ceremonias Come. Ve lo sencillo que es. Entonces sigamos adelante y revisemos cada una de estas ceremonias con más detalle. Entonces chicos, hablemos de nuestra ceremonia de migajas más rápida, el aseo atrasado. Pero antes de eso, sólo quería mencionar que hablaremos de cada una de las ceremonias en el mismo formato que se ve en la pantalla. Significado cuando se hace. ¿ Quiénes son los asistentes, cuánta duración tiene el bistec de ceremonia, y finalmente, cuál es su propósito? Entonces, empecemos. Entonces, ¿qué es el aseo atrasado? Ahora, como su nombre indica, es un aseo o un refinamiento del atraso. Entonces, para entender esta ceremonia, primero necesitamos entender ¿qué es este rezago? Ahora cuando estamos en desarrollo de productos, tenemos que trabajar en el diseño de nuevos requerimientos, ¿verdad? Por lo que obviamente necesitamos captar esos requisitos en alguna parte. Y DAT ES lo que sea el atraso. El atraso es una lista de nuevas características o cambios en las características existentes, correcciones de errores, todo lo que el equipo tiene que hacer. Entonces piénsalo como una gran lista de requisitos que es creada por el Propietario del Producto en consulta con las partes interesadas, y ese es el trabajo que tiene que hacer el equipo. Ahora esta lista obviamente contendrá toneladas de características, ¿verdad? Por lo que necesitamos revisarlo periódicamente. Tenemos que agregarle detalles, necesitamos priorizarlo, etcétera. Y esto es importante, esto es chicos importantes porque entonces solo tendremos artículos que estén listos para trabajar en las próximas dos semanas sprint la lista priorizada de artículos. Y estos chicos es exactamente lo que hace la ceremonia de preparación atrasada o Refinamiento de rezago. Entonces echemos un vistazo a las otras diapositivas. Es primero, ¿cuándo se hace este aseo? Se hace antes de la planeación del sprint. Y eso tiene sentido, ¿verdad? Porque necesitamos que los temas de máxima prioridad estén listos para su discusión por la planeación del sprint. Además, no hay regla dura y rápida. Cuántos días antes de una planeación de sprint debes hacerlo. Pero como dos a través son de dos a tres días antes de que la planeación sea buena, no queremos hacerlo muy temprano y entonces las cosas podrían cambiar. Entonces, sólo apegémonos a dos o tres días antes de que empiece el sprint. Se inicia el siguiente sprint. Eso debería ser bueno. Siguiente punto, ¿quién participará en el grooming atrasado? Por lo que obviamente necesitamos al dueño del producto porque él o ella es responsable del rezago. ¿Qué se debe hacer? Cuál es la prioridad si el equipo tiene alguna pregunta, él o ella puede responderla. Por lo que definitivamente necesitamos al dueño del producto. Entonces tenemos al maestro scrum apoyándolo a él o a ella. Recuerda, el Scrum Master ayuda al dueño del producto a trabajar indiferente. Por lo que ayudarle a arreglar el atraso, ayudarles a refinar el atraso es una de las tareas del Scrum Master. Por lo que el dueño del producto estaría ahí, el Scrum Master estaría ahí. Y por último, necesitamos al equipo de desarrollo, por lo que no necesitamos todos los eventos del equipo de desarrollo. Algunas personas del equipo de desarrollo también harán el trabajo. Siguiente. Cuánto tiempo se ríe este encuentro. Entonces otra vez, ninguna regla dura y rápida, pero como una hora es buena. Recuerda que hablamos de hacer aseo atrasado hacia tres días antes de la planeación del sprint, ¿verdad? Y eso significa que ese equipo sería fin de la corriente es sprint. Por lo que obviamente equipo tendrá mucho trabajo por terminar y no queremos mantenerlos sentados como cinco horas en una reunión. Por lo que una hora de aseo es suficiente si es necesario. Podemos hacer otra sesión de una hora más tarde, pero eso debería ser suficiente. No queremos mantener a ese equipo detenido durante largas horas antes de que el siguiente al final de la corriente sea sprint porque habrían trabajado para completar. Por lo que haríamos de dos a tres días antes de la planeación del sprint. Y como una hora si fuera necesario, haremos otra sesión de una hora, pero no demasiado larga. Y por último, ¿cuál es el propósito del aseo atrasado? Entonces primero, revisamos historias de usuarios que se tienen que hacer en el próximo sprint. Punto más importante, tenemos que preparar las cosas porque el próximo sprint va a venir en los próximos dos o tres días. Por lo que necesitamos estar listos con el contenido que tenemos que hacer su siguiente, tenemos que resolver hechos desconocidos e inciertos para una correcta estimación. Entonces recuerda que esta es la primera vez que el equipo de desarrollo está viendo las historias de los usuarios. que puedan tener algunas preguntas obviamente, y tenemos que resolverlas en la reunión de aseo. ¿ Quién los resolverá? El propietario del producto los disolverá. Y al resolver es necesario para que el equipo pueda estimar el trabajo correctamente. Tercer punto, identificar dependencias y riesgo de antemano. Por lo que estamos planeando tomar las historias tau de máxima prioridad en el próximo sprint. Entonces, identifiquemos cualquier riesgo o dependencia en ellos ahora solo, para que no estemos atascados más tarde. Siguiente punto, asignar estimaciones a las historias de los usuarios. Entonces esto es como discutir puntos de la historia y veremos estimación con mucho detalle más adelante en un capítulo posterior. Pero por ahora, solo debes saber que la historia de cada usuario tiene que tener un punto de historia para la estimación. Y esto es storypoint se da idealmente en el grooming de atraso. Algunos equipos lo hacen en una planeación de sprint, pero el aseo atrasado es el momento más ideal para hacerlo. En quinto lugar, dividimos las historias de usuarios que son demasiado complejas o son nuestras incógnitas. Entonces si hay mucho trabajo en un usuario es historia y equipo siente que no serían capaces de hacerlo en un sprint, entonces podemos dividirlo en múltiples historias. Entonces esa es también una de las agendas del aseo atrasado. Y último el punto clave de comida para llevar. aseo exitoso lleva a eficaz es la planificación de sprint. Entonces, cuanto más esfuerzo pongamos en el aseo de atraso, más preparados hagamos las cosas durante el grooming de atraso, más efectivo será el sprint que tendremos. ¿ Y eso tenía sentido, chicos? Porque recuerden, nuestros requisitos son claros, nuestros requisitos son descriptivos su estimado correctamente, entonces las cosas serían muy fáciles en el próximo sprint. De acuerdo, así que todo se trataba de aseo atrasado. Hemos concluido la primera ceremonia. Ahora tenemos una lista prioritaria de requisitos. Sabemos en qué cosas tenemos que trabajar en el próximo sprint. Entonces echemos un vistazo a la próxima ceremonia. Ellos sprint planeación en la próxima conferencia. Gracias. 14. Planificación de Sprint: Hola a todos y bienvenidos de nuevo. Hablemos de la próxima ceremonia. Ellos sprint planeación. Por lo que sprint planeación es lo más importante es la ceremonia de migajas, e involucra varios aspectos. Hablaremos de esas cosas aquí a un alto nivel. Y luego en un capítulo posterior, realmente aprenderemos una planeación sprint con más detalle, incluyendo técnicas de importancia y estimación. Entonces, empecemos. Ahora si recapitulamos en la última conferencia, hicimos el grooming atrasado y el equipo finalizamos las historias de usuarios en términos de orden prioritario. El equipo discutió esas historias de usuarios y si tenían alguna consulta o dependencias o riesgos, se plantearon al dueño del producto y ojalá él o ella lo haya resuelto. Por lo que ahora estamos listos para entrar en el próximo sprint y empezar a trabajar en esos requisitos, esas historias de usuarios. Pero antes de eso tenemos que planear cómo hacerlo. Y la actividad de datos se llama como una planeación sprint. Cuando se hace, obviamente al inicio del sprint, no podemos iniciar el sprint a menos que hayamos completado la planeación del sprint. ¿ Quién participa en ella? El dueño del producto, el Scrum Master, y todo el equipo. Por lo que en rezago aseo no se necesitaba todo el equipo. Pero aquí todo el equipo de desarrollo debería asistir porque todos llegarán a continuación. Sprints trabajan desde esta ceremonia sólo a continuación cuánto tiempo debe durar. Entonces otra vez, no hay regla dura y rápida, pero para un sprint de dos semanas a nuestro dice, vale, recuerda si el Sprint Planning está funcionando bastante largo, significa que el equipo no está haciendo el aseo atrasado correctamente porque la mayor parte de relacionada con las historias de los usuarios debería ocurrir en el grooming atrasado solamente y en la planeación, idealmente deberíamos simplemente estar estimando y asignando tareas a las cosas. Y por último, vamos a ver cuáles son los propósitos de una planeación de sprint. Entonces, en primer lugar, revisamos el atraso y decidimos qué artículos tirar al sprint. Significado lo que es usuario, historias, bugs, etc. Los equipos trabajarán en este sprint. Recuerda que las historias del usuario ya están listas después aseo de atraso y ya están dispuestas en el orden de prioridad. Simplemente tenemos que decidir en base a la capacidad del equipo, cuántas pueden tomar en el sprint, como las cinco primeras historias o 80 historias o historias de tenis, etcétera. A continuación se discute la capacidad del equipo. Entonces hablamos de cuánto es la disponibilidad del equipo? ¿ Hay alguien de permiso? ¿ Hay vacaciones? ¿ Alguien tiene algún otro trabajo personal o profesional, etcétera? Por lo que esto es parte de la estimación y hablaremos capacidad con todo detalle en el capítulo posterior sobre es la planeación sprint. En tercer lugar, asignamos tareas a desarrolladores probador. Por lo que esta es una actividad importante de una planeación de sprint. Tenemos que asignar el trabajo, esa tarea a la persona en el equipo para que todos sepan quién está trabajando en qué. Y recuerda en Scrum, esta asignación debe ser mutua. Todos deberían decir por su cuenta en qué quieren trabajar basándose en la habilidad, la experiencia pasada, etcétera. Todo el mundo debe conseguir un trabajo igual y suficiente en la asignación y nadie debe estar sobrecargado. Siguiente propósito estimar plazo para cada tarea. Entonces para cada usuario es historia, creamos tarea como desarrollo, pruebas, UAT, etc. Y el equipo proporciona su insumo como esta tarea en particular tomará cuatro horas, esto tardará cinco horas, etcétera. Y esta es la estimación de trabajo de los equipos. Después lo ejecutamos de nuevo, Las horas disponibles de ese equipo, esa capacidad total. Y en base a dat, decidimos cuántas historias podemos sacar del atraso en el próximo sprint. Entonces nuevamente, más sobre estas capacidades de estimación, etc, en el capítulo posterior. Por ahora, solo sepan que es la planeación de sprint es la ceremonia en la que estimamos marco temporal para cada tarea. Siguiente punto discutimos las dependencias de riesgo conocidas que pueden interrumpir un sprint. Por lo que hablamos de riesgo en el aseo también, si no se atienden, si hay algo más que ha surgido como si no hay suficientes personas disponibles en el sprint. Si hay alguna información que ha surgido nueva y no se atiende plenamente, estas cosas deben plantearse durante la planeación del sprint para que lo sepamos de antemano. Y entonces las cosas no nos golpearían de repente en medio del sprint después de que ya nos hemos comprometido con todo el trabajo. Y último punto es Scrum Master facilita la reunión para asegurar una discusión y un acuerdo efectivos. Este es un punto muy interesante, chicos, y lo vimos antes también que el maestro scrum es el tipo que maneja toda la ceremonia, que dirige todas las ceremonias. Entonces cuando estamos en la planeación del sprint, cuando estamos decidiendo el trabajo a hacer, el Dueño del Producto, obviamente vamos a tratar de empujar por más trabajo porque él o ella tiene la presión de un titular de una estaca para entregar las cosas rápidamente. Escribe el equipo, por otro lado, estimará conservativamente y ellos, y así habría una diferencia viniendo. Podría levantarse, podría haber dependencias, incógnitas. No habría trabajo suficiente para todos. Podría haber exceso de trabajo para todos. Todas estas cosas pueden pasar. Entonces hay proceso de pensamiento múltiple que está pasando. Y es obra de un Maestro Scrum manejar todos estos aspectos. El Maestro Scrum facilita la reunión para asegurarse de que se discutan todos los puntos. El Dueño del Producto responde a todas las preguntas que ha tenido nuestro equipo. El equipo no tiene desconocidos, ese equipo estima las cosas correctamente si hay algún riesgo que se manejan de antemano. Vimos a nuestro querido también hizo el trabajo de un scrum master es obtener la mejor salida posible y de calidad de Team. Y esas habilidades se ponen a usar mejor durante la sesión de planeación de sprint. Muy bien chicos, así que todo esto se trataba de una planeación de sprint. Ahora recuerda que nuevamente tenemos un capítulo más tarde del que hablar es la planeación de sprint incluyendo estimación con mucho detalle. Por ahora, pasemos a la siguiente ceremonia y veamos qué datos hay en la próxima conferencia. Gracias. 15. Sprint Daily Stand Up en día: Hola a todos y bienvenidos a la próxima ceremonia, discreción, el sprint diario standup. Entonces, recapitulemos lo que hemos hecho hasta ahora. Hicimos el aseo atrasado, priorizamos las historias. Hicimos la planeación del sprint. Hemos tomado las historias de los usuarios, hemos creado tareas para todos para que todos sepan en qué tienen que trabajar. Y hemos iniciado la corriente es sprint. Por lo que ahora estamos en el actual sprint. Y mientras este es el sprint se está ejecutando cada mañana, el equipo hará una reunión rápida de 15 minutos que se llama el stand-up para hablar de los avances y los bloqueos carreteros. Entonces hablemos de esta ceremonia a detalle primero, cuando se haga. Por lo que se hace todos los días del sprint. Se hace generalmente por la mañana antes de que todos comiencen su trabajo. Por lo que el equipo tiene la agenda fijada para el día. Ahora, algunos equipos lo hacen dos veces al día en las horas de inicio y finalización de trabajo. Eso está totalmente bien. No hay herramienta dura y rápida. Depende del acuerdo interno del equipo. Pero por lo general una reunión al inicio de la mañana es ideal. A continuación, ¿Quiénes son los asistentes? El Dueño del Producto, el Scrum Master, pero lo más importante, todo el equipo de desarrollo. Por lo que la mayoría de la gente piensa en el stand-up como un ejercicio de denuncia. Somos el equipo le da su estatus al dueño del producto, pero eso no es del todo cierto. El encuentro es para que los integrantes del equipo digan que hay estados entre sí. Por lo que incluso si el dueño del producto o el Scrum Master no está presente en la reunión, el equipo aún debe reunirse para stand-up y deben discutir las cosas. Porque recuerden, se están dando su estatus el uno al otro, no al dueño del producto ni a un maestro scrum. Siguiente punto, ¿cuál es la duración de su stand-up? Por lo que debe ser muy corto, no más de 15 minutos. Recuerda, solo tenemos que discutir tres puntos rápidos que se escriben a continuación. No es un estado de trabajo completo hora por hora. Y así no debe haber conversaciones laterales, ni detalles profundos. Si hay alguna discusión adicional que está saliendo del standup es status. Los individuos o equipo pueden discutir sobre ello después de que todos hayan hablado, pero eso no debe secuestrar la reunión de stand-up. Queremos terminar la reunión de stand-up en idealmente 15 minutos. Y finalmente, ¿cuál es el propósito de esta ceremonia? Entonces, ante todo, responder tres preguntas. ¿ Qué hice ayer? ¿ Qué voy a hacer hoy? ¿ Tengo algún bloqueador? Por lo que este es el formato dorado de los standups en todas partes en Scrum. Y cada miembro del equipo debe atenerse a responder estas tres preguntas. A continuación, comunicamos el progreso y levantamos impedimentos. Por lo que la idea básica del standup es compartir el progreso que está haciendo el equipo a diario. Por lo que sabemos que nos estamos moviendo en la dirección correcta al ritmo correcto. Y para plantear cualquier impedimento o el equipo de datos bloqueadores tiene para que sepamos qué está reteniendo al equipo y quién ayudará a resolver ese bloqueador, el maestro scrum, o el dueño del producto. Último punto, la oportunidad de colaboración puede surgir con base en los estados. Entonces, entremos. Desarrollador a dice que soy blog porque no puedo obtener el código fuente en mi máquina local o desarrollador ser informes en el estándar que estoy atascado porque es algo nuevo para mí y no he trabajado en ello recientemente. Por lo que aquí hay una oportunidad de colaboración. Algún otro desarrollador en el equipo puede decir que, ok, sé cosa de papá, te ayudaré a recordar un scrum habla de colaboración en su equipo y es standups son una gran manera de promover esa colaboración. Sólo una palabra de consejo. No empieces a hablar de los finos detalles en el propio standup. Apenas dicho ante nada de preocupaciones, te puedo ayudar en eso. Y entonces los dos individuos pueden sincronizarse en él después de que todo el mundo haya terminado con el stand-up. Por lo que el stand up es una gran oportunidad para reportar avances, para reportar cualquier bloqueante, e identificar oportunidad de colaboración entre el equipo. Porque recordar la finalización del sprint es responsabilidad del equipo. Completar toda la riqueza con la que se han comprometido es responsabilidad del equipo. Equipo de Soda se está dando un estatus el uno al otro que están contando su progreso. Están diciéndole a su bloqueador, se están ayudando unos a otros. Está bien. Entonces ahora sabemos lo que es la ceremonia de stand-up. Recuerda tres preguntas. ¿ Qué hice ayer? ¿ Qué voy a hacer hoy? ¿ Y tengo algún bloqueador? De acuerdo, vamos a seguir adelante con nuestro impulso de aprendizaje. Y hablemos de la próxima ceremonia en la próxima conferencia. Gracias. 16. Revisión o demostración de Sprint o de demostración: Hola a todos y bienvenidos a la cuarta discusión ceremonia, que es la revisión sprint. Entonces, hasta el momento hicimos el aseo atrasado y priorizamos nuestros requisitos. Hicimos la planeación de sprint y estimamos y tareas esos requisitos. Empezamos el Sprint y en cada día con datos más rápido stand-up para discutir los avances. Ahora estamos en un punto donde sprint se ha completado y vamos a hacer nuestro primer post es actividad impresa, que se llama Sprint Review, o más comúnmente la demo. Pero antes de empezar con los detalles, pensemos por qué necesitamos la ceremonia. Ya tomamos los requisitos, las partes interesadas saben en qué trabajó ese equipo. Entonces, ¿por qué mostrárselo a todos ahora? El respuesta es retroalimentación temprana. Recuerda, SU Scrum es estrés en retroalimentación temprana y continua. Por lo que queremos obtener esa retroalimentación y queremos mejorar el producto en base a la deuda. Y también queremos obtener esa retroalimentación desde el principio. Por eso estamos haciendo esta revisión inmediatamente después del final del sprint. Tiene sentido, ¿verdad? Entonces veamos ahora los finos detalles. En primer lugar, ¿cuándo se hace el sprint review o demo? Entonces obviamente al final del sprint ahora no queremos esperar diez días después del final del sprint. No queremos hacerlo lo antes posible una vez que termine el sprint. Por lo que idealmente los equipos lo hacen en ese día hay sprint termina y luego entran en el sprint planeando para el próximo sprint para que si hay alguna salida proveniente de esta demo sesiones y en nu, mejoras que se necesitan, pueden retomar rápidamente en el próximo sprint también. Entonces otra vez, ¿cuándo se hace la revisión del sprint al final del sprint? ¿ Quiénes son los asistentes? Por lo que es la lista completa, pero lo más importante, necesita la participación del proyecto es Partes interesadas y los equipos de gestión de productos. Porque recuerden del último capítulo, los interesados son los que estamos haciendo todo el trabajo. Por lo que es importante demostrarles las cosas. Siguiente. ¿Cuál es la duración de esta reunión de revisión? Por lo que de 15 a 30 minutos es bueno, tal vez una hora. Nuevamente, no hay regla dura y rápida, pero es una demostración rápida de las nuevas características desarrolladas. Nosotros les vamos a mostrar únicamente flujos mayores. No les vamos a mostrar todos y cada uno de los escenarios de detalle. Por lo que de 15 a 30 minutos o máximo, una hora es un buen límite de tiempo. Y finalmente, ¿cuál es el propósito de hacer esta revisión? Por lo que el primero es exhibir el trabajo que hace el equipo en el pasado es sprint. Por lo que es la primera vez que los partícipes van a ver el trabajo por el que habían dado los requisitos de texto o textos. Por lo que el propietario del producto había ido consiguió los requisitos de las partes interesadas aquí, lo tradujo en criterios de aceptación hábiles. En cuanto al equipo, ese equipo trabajó en ello, lo entregaron. Por lo que ahora es la primera vez que el accionista realmente va a ver esa cosa en acción. Segunda y más importante retroalimentación de las partes interesadas. Entonces como dije, cada pasillo y Scrum depende de retroalimentación temprana y frecuente. Por lo que sprint demo, nos aseguraremos de que eso suceda. A continuación, celebrar el logro y el trabajo en equipo. Por lo que todo el equipo ha puesto en uno es sprints vale la pena de trabajo para crear estas características. Han trabajado duro durante las dos o tres semanas, sea cual sea la duración del sprint en la organización. Y cuando esa característica se muestra a las múltiples personas, los chicos de la dirección, ellos los titulares de estaca, trae una sensación de logro al equipo de scrum. Se les motiva a ver la salida del arduo trabajo que se está degradando a todos. Último punto, idealmente sólo se debe mostrar un trabajo totalmente demostrable y probado. Entonces esto es como un descargo de responsabilidad. No debemos mostrar cosas que estén parcialmente listas o que tengan varios defectos. Recuerde, la salida de cada sprint es lo que llamamos como un producto potencialmente enviable. Por lo que sólo debemos presentar cosas que estén totalmente listas y probadas. ¿ Y quién hace esa llamada? Quién hace la llamada a la calidad del producto, al rendimiento del producto, al propietario del producto. Genial. Por lo que ahora que hemos completado el Sprint y mostrado nuestro trabajo a las partes interesadas, todavía queda un conjunto de dinero que queda. Todavía no hemos terminado. Todavía nos quedan dos ceremonias más por dejar. Entonces hablemos de la siguiente en la siguiente conferencia. Gracias. 17. Retrospectiva: Hola a todos y bienvenidos a la próxima ceremonia de discusión que sprint retrospectiva o también conocido como el retro y corto. Entonces, ¿qué es esta retrospectiva y por qué lo estamos haciendo? Ya nos llevamos un periódico. Nos comprometimos con todo el trabajo que habíamos hecho. Degradamos al titular de la participación del producto. Entonces, ¿cuál es la necesidad de hacer esto? Una ceremonia más Ahora, veamos. Entonces la respuesta es que es miga contiene actividades repetitivas. Eso lo sabemos, ¿verdad? Hacemos el aseo, hacemos la planeación, completamos el sprint, y luego empezamos con otro sprint, ¿verdad? Pero entre todo esto, necesitamos descifrar que lo que todo salió bien y si hay algún margen de mejora, es muy importante hacer este análisis porque así vamos a mejorar en las demás cosas. Será la misma reputación de las cosas con los mismos problemas pasando una y otra vez. Por eso la retrospectiva es muy, muy importante. Desafortunadamente, muchos equipos no lo hacen. A ellos no les importa. Pero es muy importante sacar ese tiempo para hacer retro después de cada sprint. Entonces cuando se hace, obviamente se hace después de que el sprint ha terminado. De nuevo, no queremos esperar demasiado tiempo después de que el sprint haya terminado porque queremos retroalimentación sobre el último sprint y conforme pase Days, la gente se olvidará de ello. Entonces la idea es hacerlo tan pronto como el sprint haya terminado, tal vez el mismo día o al día siguiente después de la demo, etcétera. Para que el sprint esté fresco en la memoria de las personas y puedan dar una retroalimentación correcta. A continuación, ¿quién lo intenta? Por lo que el dueño del producto, el maestro scrum, el equipo de desarrollo, todo el equipo debería atenderlo. No queremos ninguna persona externa. No queremos a los gestores, no queremos a los titulares de participaciones. No, este es el análisis del equipo. Por lo que el equipo debe hacerlo todo. El equipo debe estar presente y honestamente deben hacerlo dentro de sí mismos. A continuación, ¿cuál es la duración? Por lo que esa duración es como de 30 a 60 minutos. Nuevamente, no hay regla fija. La idea es discutir las cosas y asegurarse de que todos tengan tiempo suficiente para hablar. Por último, el propósito de primero y lo más importante, reunir retroalimentación para hacer mejor el proceso y la cultura. Recuerda, tenemos que hacer las mismas cosas, iterar en las mismas cosas una y otra vez en Scrum. Por lo que sprints, seguirán. Vamos a hacer es imprimir de uno a cien, doscientos, pero hay que aprender algo de cada sprint. Debemos saber mejorar las cosas con cada Sprint. Y papá es el objetivo de hacer retrospectiva para conocer los problemas con el sprint, para averiguar cuáles fueron las cosas buenas y cómo podemos mejorar aún más. Y por eso hablamos de dos cosas. En primer lugar, ¿qué salió bien? Y número dos, ¿qué pudo haber sido mejor? Por lo que cualquier cosa de la recién terminada es imprimir entrar equipo las cosas no eran buenas como paso y deberían hacerse de nuevo. O si algo no era bueno y algo que podamos mejorar, no deberíamos hacer. Saquamos todas esas cosas? Todo el mundo habla de ello. Ese es el propósito de la revisión retrospectiva y honesta de la deuda sprint pasó. Siguiente punto, recuerda que la idea es no resaltar defectos o convertirlo en un ejercicio de juego de la culpa. Como dije en el último capítulo de Scrum, los triunfos y fracasos son responsabilidad de todo el equipo. Por lo que la retrospectiva debe hacerse con honestidad. Se debe utilizar para mejorar las cosas. Y lo que es más importante, no se debe enseñar de un ejercicio de juego de la culpa. Estamos, sólo estamos señalando las cosas malas de todos. Es para la mejora de la impresión, es para el mejoramiento de todos. Entonces vamos a mantenerlo honesto. No culparemos a todos. Por último, la práctica de la retrospectiva regular es refuerza el aspecto de mejora continua. Entonces tenemos que aprender del pasado, tenemos que mejorar en las cosas. Y ese es el propósito de la retrospectiva. De acuerdo, así que todo se trataba de chicos retrospectivos o retro, Si ahora sólo nos queda una ceremonia más. Entonces hablemos de ello en la próxima conferencia. Gracias. 18. Planificación de liberación: Hola a todos y bienvenidos de nuevo. Hablemos del último tema de las ceremonias de Scrum conocidas como planeación de liberación. Entonces chicos, planear el estreno es una ceremonia importante en un scrum, aunque verás que la mayoría de los cursos no hablan de éste. Yo lo incluí aquí porque es importante entender estos detalles. Necesitamos saber cuándo entregar el incremento del producto al usuario final para que pueda usarlo. Y todo nuestro arduo trabajo viene a usar. Por lo que la planeación de lanzamientos de chicos es todo sobre decidir qué incrementos de planta queremos empujar hacia fuera al usuario final. ¿ Y cuándo queremos hacerlo? Recuerde que el propósito de cada sprint es diseñar nuevos instrumentos y tenemos que averiguar cuándo liberar esos incrementos al usuario final. Algunas organizaciones lo lanzarán a producción después de cada sprint. Algunas organizaciones lo harán después de dos. El Sprint no es una regla fija para él. Se llama como cadencia de liberación, y depende totalmente del requisito del negocio o de la hoja de ruta del producto, o del costo o el valor que se agrega al producto. Estos son los múltiples factores en los que se basarían nuestros lanzamientos. Y hablaremos de todos esos aspectos durante esta ceremonia de planeación de liberación. Entonces, en primer lugar, cuando se haga, idealmente deberíamos hacer la planificación de liberación a intervalos frecuentes. Entonces deberíamos hacerlo como después de cada sprint. Porque recuerden en base a cuándo y lo que tenemos que liberar, podríamos tener que modificar nuestro atraso. Podríamos tener que volver a priorizar los requisitos, realinear los recursos, etcétera. Por lo que lo mejor es hacerlo a intervalos frecuentes. Siguiente punto, ¿quién asiste a la reunión de planeación de liberación? Por lo que deben ser los interesados, el propietario del producto, y todo el equipo de scrum. Porque recuerda que todo el mundo del equipo de desarrollo podría tener algún papel en el lanzamiento. Los desarrolladores desplegarán el código, los probadores verificarían el código para que todos tengan algo de trabajo. Por lo que es bueno incluir a todo el equipo de scrum o un pequeño subconjunto del mismo. A continuación, ¿cuál es la duración? Nuevamente, ninguna regla dura y rápida. 30 minutos a 60 minutos es una duración suficiente. Y por último, ¿cuáles son los propósitos de esta ceremonia? Entonces primero, como discutimos, la planeación de lanzamientos ayuda a averiguar cuáles son todas las características que podemos entregar al cliente. Y recuerda, las cosas podrían estar guiadas por una lista de características como queremos hacer un lanzamiento una vez que todas estas características estén listas. O podría ser impulsado por una fecha como queremos hacer un estrenado el próximo mes, segundo viernes, así sucesivamente así que cualquiera sea el criterio discutamos sobre esas cosas en la ceremonia de planeación del estreno. A continuación, miramos la hoja de ruta del producto y tomamos la decisión. Por lo que se guía por el requisito del producto, los insumos del interesado, todos estos factores juntos para decidir cuándo queremos liberar el producto. En tercer lugar, también discutimos el equilibrio entre las necesidades del cliente y el alcance. Por lo que el cliente puede querer algo nuevo cada semana, pero hay preocupaciones genuinas de que las cosas no estén listas en ese corto tiempo o para el caso, podría haber preocupaciones sobre el presupuesto también. Entonces hablamos de todas esas cosas. Tratamos de encontrar un equilibrio entre el nuestro costo y liberando frecuentemente para el usuario. Siguiente punto que la frecuencia de lanzamiento variará o cada organización, como dije, algunos equipos liberarán cada sprint. En ocasiones algunos equipos pueden liberarse después de un sprint. No hay regla dura y rápida. Depende de la organización, depende de sus necesidades empresariales. Último punto, el plan de lanzamiento no es un plan estático y puede cambiar en función de una nueva adición al atraso. Por eso es importante revisitar las cosas. Regularmente, discutir las cosas con el interesado y hacer esto, esta ceremonia de planeación de liberación con frecuencia. Muy bien chicos, entonces con esto, llegamos al final de todas nuestras ceremonias de Scrum. Recapitulemos las cosas rápidamente en la secuencia en la que suceden. Entonces hacemos el aseo atrasado antes de que empiece el sprint. Después para iniciar el sprint, hacemos el sprint planeando patear el sprint. Cada día del sprint, se está ejecutando la impresión más salvaje. Haremos ese stand diario. Por último, cuando termine el sprint, haremos la demo y haremos la retrospectiva. También debemos incluir la planeación de liberación en algún lugar aquí, como después de que termine el sprint y en un intervalo frecuente. Entonces chicos, recuerden todas estas ceremonias son fundamentales para el scrum. Están en caja de tiempo y cada uno de ellos sirve un propósito importante, como vimos. Vimos su importancia, vimos su frecuencia. Y puedes recapitular este gráfico muy rápidamente para recapitular cuándo necesitas cuándo ocurre esa ceremonia y cuál es su propósito. Muy bien chicos, así que vimos el diverso es ceremonias de miga. Pasemos al siguiente capítulo y discutamos el siguiente componente de Scrum, que son los Artefactos Scrum. Gracias. 19. Épicos e Introducción a los artefactos: Hola a todos y bienvenidos al quinto capítulo del curso. En lo que va de nuestro viaje, hemos visto lo que es h i y lo que es un Scrum. Hemos visto a las diferentes personas en un equipo de Scrum conocido como los roles de Scrum. Y también hemos visto las diferentes reuniones o es ceremonias de miga que hacen para desarrollar un producto o incremento. todo, tenemos que conocer el quién y el cómo parte de la historia. Ahora en este capítulo, aprendamos algo llamado los Artefactos Scrum y cómo ayuda al equipo en su viaje de Scrum. Entonces, empecemos. Por lo que estos son los temas que estaríamos cubriendo en este capítulo. Pero antes de eso, un descargo de responsabilidad muy importante para evitar cualquier confusión. Recuerda que los Artefactos Scrum son en realidad sólo el rezago del producto, el rezago del sprint y los incrementos. Por lo que el número 456 de nuestra lista. No obstante, para entenderlas, también necesitamos ser aparecidos fuera de epics y usuario es historia, y por eso nos estamos moviendo en un orden lógico. En este capítulo, primero hablaremos de Epics, luego hablaremos de historias de usuarios. Y debido a que las historias de usuarios son la fuente de requerimiento para todo nuestro equipo, veremos las mejores prácticas para escribir buenas historias de usuario. Esto nos ayudará a saber escribirlos correctamente en nuestra organización o a mantener un cheque si alguien más lo está escribiendo, entonces nos moveremos a hablar de nuestros artefactos. El Retraso de Producto es sprint rezago e incremento para que las cosas estén claras para nosotros. Y por último, aprenderemos algo llamado la definición de hecho, que es un concepto y documentación muy interesantes del acuerdo del equipo de Scrum. Entonces por eso lo incluí en este capítulo. Entonces, empecemos nuestro viaje y empecemos con el primer tema. Entonces hablemos primero de cuál es el significado de Scrum Artifacts. Entonces si hablamos en términos generales, la palabra artefacto significa los documentos que creamos. Y el propósito de estos documentos es proporcionarnos información clave y asegurarnos de que todos en el equipo tengan la misma comprensión de las cosas. Ahora cuando decimos que nos proporcionen información clave, ¿cuál es la información que estos artefactos pueden proporcionar? Entonces para entender eso, olvidemos es miga por un momento, y pensemos en trabajar en crear o modificar un producto en general. Entonces, ¿cuál es la diferente información que necesitaríamos si estamos haciendo eso? En primer lugar, necesitaríamos saber cuál es el requisito. Porque esos son los requisitos en los que estaríamos trabajando. A continuación, necesitamos saber el cómo parte, cómo nos estaríamos acercando a ese requisito, cuál es la parte que estaríamos haciendo, etc. Y finalmente, también necesitamos saber el avance, cuánto se hace, cuánto queda, etcétera. Y chicos, este es el mismo concepto que se aplica a un scrum. Además, los artefactos nos ayudan a proporcionar información clave como el número uno, el producto en desarrollo. Entonces estos no son más que el requisito que queremos y se almacenan en forma de historias épicas y de usuarios. ¿ Quién las escribe? El propietario del producto los escribe en consulta con las partes interesadas y con la ayuda de un Scrum Master. ¿ Y dónde guarda el dueño del producto estas historias de usuario? Él o ella los guarda en el Retraso de Productos. Segundo, próximas actividades. Por lo que ya vimos que durante la planeación del sprint, tomamos las historias de los usuarios del rezago del producto. Y en base a la capacidad del equipo, finalizamos un rezago de sprint. Esa es la lista de historias de usuarios en las que estaría trabajando el equipo en el próximo sprint. Y último punto los trabajos concluidos hasta el momento. Por lo que esto se refleja en nuestra cartera de productos o la finalización del atraso de sprint también. Y recuerda que hay múltiples reportes también muestran esta información. Y es por eso que verás a varios autores directamente reportando como gráfico de quemado, etcétera también para ser un artefacto. Pero aquí en este curso nos quedaremos con la lista de artefactos original y trataremos solo el Retraso de Producto es sprint rezago e incrementos en este capítulo. Para otros métodos de reporte como Burndown o gráfico de velocidad, tenemos un capítulo dedicado más adelante cubriendo enteramente lo diferente es informes de migajas. Y finalmente, último punto, ¿cuál es la ventaja de tener artefactos? Por lo que brinda información clave a todos y pone a todos en la misma página en términos de comprensión. Por ejemplo, digamos si no teníamos ningún rezago de producto, cómo van a ser los titulares de las estacas miembros del equipo, saber qué todo lo que tenemos que hacer y cuánto trabajo queda. Todos tendrán una comprensión diferente del trabajo esperado y esto causará confusión en el equipo. Por lo que los artefactos ayudan a resolver este tipo de problemas. De acuerdo, así como mencioné antes, los artefactos clave en el Scrum, nuestro rezago de productos, un rezago de sprint e incrementos, y los vamos a pasar por ellos en este capítulo. Pero para entender claramente las cosas primero necesitamos saber acerca de las epopeyas y las historias de usuarios. Entonces, empecemos con las primeras épicas. Entonces chicos comprados son estas épicas? Si hablamos en términos generales, épicas son básicamente gran requisito. Entonces en este capítulo, gran parte de lo que estamos hablando es sólo en referencia al requisito. Y la pieza más grande documentada de esos requisitos son las épicas. Como dice la definición en pantalla, un Epic es un gran requisito que se puede descomponer en un pequeño trozo de trabajo llamado historias de usuarios. Entonces esa es la definición de épico. Digamos, consideremos un ejemplo. Digamos que queremos hacer un sitio web de comercio electrónico y queremos crear su flujo de caja o colocación de pedidos. Por lo que ese es un requisito muy grande con muchas piezas de trabajo, tendremos que encargarnos de Checkout con tarjeta de crédito, por PayPal, Apple Pay y mucho, mucho más. Por lo que el rediseño de checkout sería un Epic. Y para hacer los siguientes requisitos de pago con tarjeta de crédito, PayPal, pago de Apple Pay, etcétera. Crearemos historias de usuarios, ese es el ejemplo de épicas e historias de usuarios, y esa es la relación entre ellas. Esto lo veremos más claramente cuando hagamos el proyecto práctico más adelante, no te preocupes. Pero por ahora, solo ten en cuenta que el gran requisito es épico y creamos un pequeño requerimientos o historias de usuario a partir de él, tan simple como eso. Entonces leamos para el primero, epopeyas pueden considerarse como el nivel superior del trabajo de desarrollo de productos. Por lo que el desarrollo de productos significa requisitos. Y estos requisitos provienen de Epic, que se desglosan en historias de usuarios. Por lo que las épicas son el nivel superior o nivel superior de requisitos en el desarrollo de productos. En segundo lugar, las épicas pueden extender múltiples equipos, múltiples proyectos, y un tablero de Scrum. Entonces esto suena lógico En nuestro ejemplo, épica del rediseño de Checkout. Uno es el equipo de Scrum se encargará de check out en la página web. Otro equipo se encargará del procesamiento de pedidos de backend. 13 manejará el envío de correos electrónicos cuando se haga el pedido, etc. Así que las épicas son lo suficientemente grandes, pueden incluir múltiples equipos y hay tableros de Scrum. Siguiente punto, las epopeyas se entregan a menudo a través de múltiples sprints. Entonces obviamente porque las épicas son tan grandes que no podemos hacerlas en un solo sprint. Se trata de sprint múltiple fuera del trabajo. Se divide en múltiples historias de usuarios y para múltiples equipos de Scrum. Y último punto, las épicas evolucionaron sobre sprints, consiguiendo más información. Entonces a medida que trabajemos en temas, ya que estaremos trabajando en nuestra épica de rediseño de checkout, aprenderemos más cosas. Obtendremos nuevos requisitos en los que no pensábamos antes. Y así tendremos que crear nuevas historias de usuarios para abordar esos requisitos. Entonces a medida que avanzamos, a medida que avanzamos en nuestro sprint, obtendremos nuevas historias de usuarios atadas a estas épicas. Muy bien chicos, así que dat era todo sobre epics, pero no hay que recordar todas estas cosas. Sólo recuerda dos aspectos clave. Número uno y épico es una gran pieza de trabajo. Y número dos, se desglosa en usuario más pequeño es historias que generalmente involucraron equipo múltiple y un sprint. Papá dijo Eso es todo épico es. Genial. Entonces ahora que sabemos lo que es una épica, hablemos de su manejo en forma de pequeñas piezas llamadas historias de usuario. Hablemos de estas historias de usuarios en la próxima conferencia. Gracias. 20. Historias de los usuarios: Hola a todos, y bienvenidos al tema de historias de usuarios. Ahora esta va a ser una conferencia muy importante porque siempre que estés trabajando en el Scrum, tratarás la mayor parte del tiempo con historias de usuarios. Estas historias de usuario serán la fuente de todos los requisitos y lo referirás si estás citando algo o probando algo o discutiendo con las partes interesadas. Por eso hablaremos con gran detalle sobre historias de usuarios en esta conferencia y la siguiente. Entonces, empecemos. De acuerdo, son antes que nada las historias de usuarios de agua. Ya vimos en la última conferencia que los grandes trozos de requisitos se llaman como epics. Y a partir de estas épicas creamos unos requisitos más pequeños, pequeños llamados historias de usuario. Tomamos estas historias de usuario en un sprint y trabajamos en ello. Por lo que las historias de usuarios son básicamente la unidad de requisito más pequeña en Scrum que se puede entregar en un sprint. Por lo que cuando el equipo se reúne para la planeación sprint, tomarán como cinco o siete o diez usuario es historia basada en su capacidad y se embarcarán en completar todas esas historias de usuario dentro de uno es sprint. Entonces eso es lo que es un usuario. Story es la unidad de trabajo más pequeña que el equipo puede entregar en un sprint. Veamos primero las balas, historias de los usuarios son explicación general de los requisitos expresados en los términos de usuario final. Entonces, ¿qué hay en los requisitos de historias de usuarios y cómo escribimos esos requisitos? Muy importante. Siempre escribimos DEM en la perspectiva de un usuario final. Si hablamos de la caja con tarjeta de crédito en nuestra página web de comercio electrónico historia de usuario, escribiremos como usuario, quiero hacer un pedido con una tarjeta de crédito y luego daremos los detalles adicionales. Nunca lo escribiremos como una persona técnica o una persona de negocios sabe, nuestra historia de usuario siempre se escribe desde la perspectiva de un usuario final. Siguiente punto, ¿cómo escribimos aspectos de requisitos detallados en la historia del usuario? escribiríamos como algo llamado los criterios de aceptación. Por lo que los criterios de aceptación son un conjunto de requisitos predefinidos que explicarán lo que se necesita hacer. Entonces por ejemplo, para nuestra tarjeta de crédito es historia empezaremos con, como usuario, quiero hacer un pedido con una tarjeta de crédito. Y luego mencionaremos el criterio de aceptación es como el número uno, usuario tiene la opción de ingresar una tarjeta de crédito. Número al usuario tiene la opción de ingresar una tarjeta de débito. Número tres, usuario tiene la opción de ver su lista de guardia segura y así. Entonces esa es la estructura de una historia de usuario. Y no te preocupes, veremos un ejemplo también más adelante en la conferencia. Pero sólo para recapitular rápidamente, la estructura va como usuario, yo quiero así y así, y entonces tenemos ese detalle criterios de aceptación tiene tercero, que escriben el usuario es historia, así que ya lo vimos. Es el dueño del producto. El Dueño del Producto es responsable de escribir historias de usuario. Él o ella puede tomar ayuda del equipo si es necesario. Él o ella puede tomar ayuda del Scrum Master dos facilitado, pero la responsabilidad última de crear historias de usuario , modificarlas, actualizarlas, priorizarlas, etcétera. Todo está con el dueño del producto. Como vimos en la última conferencia, es una de sus responsabilidades primarias. Y último punto, las historias de usuarios son un componente de la estimación. Por lo que hablaremos de estimación con mucho detalle en el capítulo posterior. Pero por ahora, solo recuerda que para la historia de cada usuario, estimamos usar algo llamado puntos de historia. Por lo que estas historias de usuarios también sirven como medio para la estimación. Entonces sigamos adelante y echemos un vistazo a cómo estamos realmente la historia de usuario se ve. Entonces chicos aquí es como se ve una historia de usuario. Y esto es problema. Probablemente un User Story creado para imprimir algo desde el panel de temas como G2 o algo así. Pero no te preocupes, solo ignora el contexto. Vamos a enfocarnos en el formato. Entonces como puedes ver, la historia del usuario comienza con la palabra como usuario. Entonces como dije, siempre escribimos las historias de los usuarios desde la perspectiva del usuario final. Nunca lo mencionaremos desde el punto de vista empresarial. Nunca lo mencionaremos desde un punto de vista técnico. Siempre se devolverá desde el punto de vista de un usuario final. Y es por eso que la historia del usuario siempre comienza con la línea como usuario. Y luego se puede ver que tenemos los requisitos detallados, ese es el criterio de aceptación. Y los criterios de aceptación se han escrito muy bien en balas. Por lo que los datos, es claro, todo se ha explicado con gran detalle. Entonces ahora ya sabes cuando el equipo se reúne para el aseo atrasado o la planeación del sprint, pasarán por esta historia. Leerán los criterios de aceptación si tienen alguna pregunta que puedan hacerle al dueño del producto, él o ella lo responderá y así sucesivamente. Pero tenemos que dar todos y cada uno de los detalles al más mínimo nivel posible en este criterio de aceptación. Recuerda, podemos agregar cualquier detalle técnico también como si hay alguna deuda de información técnica ayudará al equipo de desarrollo. Podemos añadirlo en la parte inferior después de cada detalle de usuario de negocio. Y si nosotros, si es necesario, podemos adjuntar un bonito maqueta también. Por lo que la maqueta ayuda en claridad visual, sobre todo si estamos haciendo un cambio de diseño o si estamos haciendo un cambio intensivo de la interfaz de usuario, entonces siempre es útil adjuntar una maqueta al usuario es historia. Entonces así es como es un usuario. La historia se parece a Guys. Y ahora que sabemos lo que es un usuario, historia es watts, es formatos, lo que sienta importancia. Sigamos adelante y aprendamos sobre las mejores prácticas para crear una historia de usuario en la próxima conferencia. Gracias. 21. Cómo escribir historias de usuarios geniales: Hola a todos. Hablemos de las mejores prácticas para escribir una gran historia de usuario. Como comenté anteriormente, escribir una historia de usuario es principalmente el trabajo del propietario del producto. Entonces, si vas a trabajar como propietario de un producto, necesitas saber esto, o si estás trabajando como analista de negocios o desarrollador o probador, aún necesitas conocerlo para que puedas asegurarte de que las historias de usuario estén escritas correctamente en tu organización. Entonces vamos a ver. El primer punto, tener en cuenta al usuario final y escribir desde su perspectiva. Muy importante es que Crum se trata entregar productos de buena calidad al usuario final Pensemos como usuario final cuando estamos creando los requisitos. No queremos pensar como propietario de un producto o desarrollador o una prueba o no. ¿Qué es lo que quiere el usuario final? Anotémoslo de esa manera. A continuación, que sea breve y simple. No escribas demasiados detalles para crear confusión. Si se está volviendo demasiado largo o demasiado largo, probablemente signifique que la historia se está volviendo demasiado complicada, y deberíamos desglosarla en dos historias separadas. Mantenlo corto, mantenlo simple. Siguiente punto, agregar criterios claros de aceptación. El criterio de aceptación como vimos es lo que conforma la historia de usuario. Necesitamos tener criterios de aceptación claros, y es por eso que en la siguiente diapositiva veremos cómo escribir criterios de gran aceptación. Cuarto punto, crear en colaboración. Discuta con las partes interesadas, discute con el equipo de desarrollo, especialmente si se trata de una historia técnica, toma sus aportes y luego crea su historia. Recuerda que crear las historias es trabajo del propietario del producto, pero siempre debe hacerlo en colaboración con el equipo. Una persona puede faltar a las cosas. Una persona no puede conocer todos los requisitos. La colaboración es una gran alternativa. Siguiente punto, lluvia de ideas, refinar o dividir. Cuando estamos haciendo preparación atrasada, o cuando estamos haciendo planeación de sprint, discuta la historia, habla de ello, haz cualquier pregunta que tengas Haga que el propietario del producto responda sus consultas, hable de las incógnitas, hable del riesgo Si es necesario, modifique la historia, o si se está volviendo demasiado grande, divida la historia en dos o más historias más. Y último punto, agregar visualizaciones para mayor claridad. Yo personalmente sugiero en este caso, un simulacro ayuda a aclarar las cosas con mayor facilidad y es mejor que 100 palabras. Así que siempre trata de incluir un mock up en las historias de usuario, especialmente si se trata de una interfaz de usuario o un cambio de diseño. Hay muchas herramientas en el mercado como la visión que ayuda a crear grandes simulacros y compartir con el equipo. Así que vamos a utilizar esos. Todo bien. Entonces ahora que sabemos cómo se debe escribir una buena historia de usuario. Hablemos de cómo escribir buenos criterios de aceptación en él. Mejores prácticas para escribir buenos criterios de aceptación. Y el primero en realidad es asegurarse de que los criterios de aceptación estén presentes, ningún sarcasmo pretendido Pero, chicos, verán mucho tiempo que los equipos simplemente crearán la historia de usuario con solo una descripción, y no habrá criterios de aceptación. Esto no es correcto. Una historia siempre debe contener criterios de aceptación porque ese es el requisito detallado. Si solo creo una historia vacía, por ejemplo, diciendo hacer pedido con tarjeta de crédito, entonces no hay un entendimiento común sobre cómo debería funcionar. Todos tendrán su propia interpretación de las cosas, y obviamente va a crear confusiones y problemas Siempre escriba criterios de aceptación en las historias, asegúrese de que no creamos historias de usuario sin poner los criterios de aceptación en ellas. Segundo, documento antes del desarrollo. Escribir primero las historias de usuario y los criterios de aceptación y luego desarrollar las cosas como parte que detalla, no primero desarrollar las cosas y luego escribir sin embargo está funcionando como saben los criterios de aceptación. Eso podría significar que estamos tomando el camino equivocado como la ruta de seguir adelante. Siguiente punto, hazlo alcanzable, medible y comprobable. Al escribir algo en los criterios de aceptación, asegúrate de que sea factible, asegúrate de que sea comprobable No escribas cosas que no serían prácticas de hacer. Cuarto punto, discutir con el equipo, tener consenso. Entonces, obtenga aportes de los grupos de interés, asegúrese de que todos estén de acuerdo con lo mismo, obtengan aportes del equipo, discutan con ellos, escríbalos, tengan preguntas, respondan. Recuerde que el equipo de desarrollo es el que realmente estaría haciendo estas historias y criterios de aceptación. Por lo que la colaboración y el consenso con ellos es la clave. Siguiente punto, enfócate en el resultado final, no en la parte de cómo. Nuevamente, muy importante, debemos escribir criterios de aceptación como usuario final, y el aspecto técnico no debe eclipsar esta parte Si se necesita algún detalle técnico, podemos escribirlo por separado como nota técnica o nota para el equipo de desarrollo. Pero la mayoría de los criterios de aceptación deben ser sobre lo que se necesita, no cómo debemos hacerlo. Y por último, recuerda incluir también los aspectos no funcionales, por lo que la usabilidad y el rendimiento son aspectos igualmente importantes. Cuando hablamos de check out en nuestro sitio web de comercio electrónico, si hay como diez páginas de largo flujo para hacer un pedido o si tarda 5 minutos en agregar una tarjeta de crédito, entonces nadie lo hará. No se hable sólo de los aspectos funcionales. Piense también en los aspectos no funcionales y cómo podemos implementarlos mejor. Bien, chicos. Todo eso se trataba de historias de usuarios y criterios de aceptación. Recuerda las historias de usuario más detalladas y bien documentadas que tendremos con claros criterios de aceptación. El mejor equipo estaría alineado a un entendimiento común, y habrá menos fallas. Ya sea que estés escribiendo historias de usuario en tu trabajo o las estés usando en tu trabajo. Siempre asegúrese de que estén escritos clara y amablemente según los puntos que discutimos. Genial. Ahora que hemos hablado epopeyas y hemos hablado de userytories Ahora, volvamos y veamos el tema real de este capítulo, los artefactos. Empecemos con el primero de la siguiente conferencia. Gracias. 22. Artifact 1: Backlog de productos: Hola a todos y bienvenidos al primer artefacto, el rezago del producto. Entonces chicos del capítulo anterior, tenemos una idea de lo que es el Retraso de Producto. Simplemente, es una lista de entregables petroleros que se tienen que hacer en un producto. Entonces si queremos hacer algunas características nuevas o modificar algunas existentes, o queremos arreglar algunos errores. Estas son las cosas que conforman el rezago del producto. Siguiente punto, siempre se intenta mantener el Retraso del Producto en orden prioritario. Por lo que el propietario del producto debe volver a visitar el rezago con frecuencia porque es responsable del rezago del producto y él o ella debe mantenerlo de manera priorizada. De lo contrario, no sabríamos qué es urgente. No sabríamos lo que hay que hacer primero y se puede perder en la lista a medida que el rezago del producto se expande. Entonces, pasemos por la bala. El primero en la pantalla como ves es la definición del rezago del producto, que como discutimos, es el número uno, una lista de todos los entregables que se tienen que hacer. Y número dos, debe estar en el orden de prioridad. Estos son los dos puntos clave de esta conferencia. Como dice la primera viñeta, rezago del producto incluye nuevas características, cambios, correcciones de errores en Francia, cambios, etcétera. Por lo que estas son algunas de las cosas que tendremos en el rezago del producto como discutimos. Y de hecho, en base a nuestro aprendizaje pasado, podemos refinar más esta lista y simplemente decir que en el rezago del producto idealmente contendría el número uno, historias de usuarios y el número dos dólares. Segundo, El Propietario del Producto organiza estos requisitos o historias de usuarios según prioridad. Tan importante, como discutimos, es necesario mantener el rezago del producto en orden prioritario. Y quién es la persona que se encarga de agregar cosas nuevas al rezago del producto o mantener su orden de prioridad, el propietario del producto. Por lo que vimos en una de las conferencias anteriores que crear el rezago y mantener el rezago es una de las principales responsabilidades laborales del propietario del producto. Siguiente punto, el Retraso de Productos puede seguir creciendo y actúa como el titular del lugar para todos los cambios futuros. Por lo que en cualquier metodología de desarrollo de productos, siempre habría nueva adición a los requisitos. Y así el rezago del producto seguiría cambiando para siempre con cosas nuevas agregadas, eliminadas o re-priorizando. Y último punto, cada sprint el equipo toma historias del usuario del rezago del producto que se hará en el ciclo actual. Por lo que cualquier cambio que se tenga que hacer en el producto, primero se agrega al rezago del producto por parte del propietario del producto. Se discute con todo el equipo. Se parasita con todo el equipo, la estimación en él, y luego se toma en una de estas impresiones para trabajar. Entonces chicos, eso es todo, eso es todo sobre el rezago del producto. Una vez más, en resumen, se puede pensar en el rezago del producto como una lista de deseos priorizada, lista tareas pendientes anudadas porque podríamos cambiar pistas y no queremos hacer todo ahí dentro. Por lo que lo llamamos como una lista de deseos priorizada que es manejada por el propietario del producto. Y sirve como un gran cubo de requerimiento del cual sacamos los pequeños requisitos y lo desarrollamos en un sprint. Entonces chicos, este fue nuestro primer artefacto. Vamos a revisar la siguiente en la siguiente conferencia. Gracias. 23. Artifact 2: Backlog de Sprint: Hola a todos. Hablemos del siguiente artefacto que sprint atraso. Entonces chicos, en este punto tenemos un rezago de producto que contiene las historias de los usuarios para cada nuevo requisito que el equipo tiene que hacer. Ahora el equipo arreglará esas historias en el aseo atrasado. Y luego se reunirán para una sesión de planeación de sprint donde tomarán las primeras cinco o primeras diez historias de usuarios para trabajar en el próximo sprint en función de su capacidad. Y este grupo de cinco o diez usuarios historias que sí tomaron es nuestro próximo artefacto conocido como el rezago del sprint. Por lo que como se puede ver, la definición también dice que un sprint atraso es un subconjunto de Product Backlog identificado por equipo para ser completado durante el sprint. Por lo que ya vimos el rezago del producto. Es una gran lista de requerimientos que equipo tome un pequeño conjunto de requisitos a partir de ahí y conforma el rezago del sprint. ¿ Y cuánto sería data sprint rezago? Sería esa cantidad de trabajo que el equipo puede completar durante el próximo sprint, tan simple como eso. Entonces sigamos adelante y leamos las balas. Entonces primero en una planeación sprint ese equipo selecciona historias de usuarios según la prioridad definida por el propietario del producto y la capacidad del equipo. Por lo que ya vimos de esto cuando el equipo se reuniría para una planeación de sprint, vamos a repasar el Retraso de Producto, que está en orden prioritario. Recuerda, y el equipo recogería las primeras cinco o diez historias en función de su capacidad. Harán esto cinco o diez historias en el sprint actual y los datos es lo que es el rezago del sprint. Siguiente punto para la historia de cada usuario en el rezago de sprint, ese equipo identifica la tarea necesaria para completarla. Entonces este es el otro aspecto de la planeación de sprint que discutimos en el último capítulo. Simplemente tomar las historias y crear un storyboard es sprint atraso no es suficiente. Tenemos que averiguar quién trabajará en ello. Este proceso se llama como tarea. Básicamente significa asignar tareas a cada miembro del equipo individual. Por lo pronto, una es historia. Asignaremos tareas de desarrollo a un chico, tareas de prueba a un tipo, maqueta diseñando UAT, etcétera. Y miembros individuales del equipo se ocuparán de esta tarea y trabajarán en ella. Por lo que esto ayuda a aclarar quién trabajará en qué, cuánto trabajo tiene cada chico. ¿ Está ocupado el propietario? ¿ Tienen bajo trabajo todas estas cosas? Siguiente punto, un atraso de sprint idealmente debería permanecer sin cambios durante la duración de un sprint. Entonces una vez que nos hemos comprometido a hacer historias como de tenis en el sprint, idealmente no deberíamos hacer cambios a esa lista. Y recuerda que estoy usando la palabra idealmente porque digamos que si alguien tiene capacidad disponible porque terminó el trabajo, o seamos más realistas. Y digamos que si surgió algo urgente, entonces seguramente tendremos que tirar cosas nuevas al rezago del sprint, ¿verdad? Pero aparte de eso, siempre debemos apegarnos a terminar lo que nos comprometimos durante la planeación. También tenga en cuenta que en caso de que estemos jalando algo nuevo, ese equipo necesita averiguar cómo acomodarlo. No pueden hacer todo el trabajo ya comprometido más este nuevo trabajo, ¿verdad? Por lo que podrían necesitar volver a priorizar cosa, podrían necesitar quitar algo, podrían necesitar tomar ayuda de otro equipo, etc. Así que idealmente, no deberíamos hacer cambios el rezago de sprint una vez que sprint tenga comenzó, pero lo más probable es que suceda. Y cuando sucede, cuando tenemos que tomar algo nuevo, tenemos que pensar en todos estos factores. Podemos hacer el nuevo trabajo retomado también. Y último punto, chicos, si algún artículo no se completa, se puede agregar de nuevo a Product Backlog y volver a priorizar al inicio del siguiente sprint. Entonces hasta ahora hemos hablado del camino feliz, en su mayoría donde tomamos como diez historias de usuarios en un sprint. Terminamos todos ellos y luego empezamos con el siguiente sprint. Pero así es ahora como sucede siempre, a veces las cosas no se van a cerrar y se les va a dar vuelta al siguiente sprint. Por lo que al final del sprint, comprobamos el rezago del sprint. Vemos lo que no se hace todo y se le da la vuelta. Y podemos o seguir trabajando en ello en el próximo sprint o podemos moverlo al Retraso de Producto y volver a priorizarlo por debajo de otras cosas. Entonces este es un ejercicio que hacemos al final de cada sprint. Y antes de que comiencen el próximo sprint, tenemos que averiguar qué hacer si alguna de las cosas del rezago del sprint no se cerraba. Entonces chicos, todo esto se trataba de nuestro segundo artefacto. Ellos sprint atraso. Recuerda entraremos una vez más en los aspectos completos de Sprint Planning incluyendo estimación y cómo hacemos todos estos, retomando las historias, piensa kappa sentado cosa, etcétera en el último capítulo cuatro ahora tenemos acaba de ver un alto nivel del rezago del producto, nuestro segundo artefacto. Entonces sigamos adelante. Revisemos el siguiente y último artefacto en la próxima conferencia. Gracias. 24. Artifact 3: incrementos: Hola a todos. Hablemos del último artefacto, del incremento. Entonces chicos, hemos usado mucho esta palabra en el curso. Entonces veámoslo con todo detalle. ¿ Qué es un incremento y qué significa? Entonces en términos simples, y el incremento es una adición al producto. En nuestra discusión hasta ahora, hemos visto que en Scrum ese equipo crea un producto y luego cada sprint le agregan nuevas características o incrementos. Cada uno de estos incrementos se suma a la versión anterior del producto, creando un producto mejor, mejorado y de calidad. Entonces esa es la definición de incremento. el realce del producto desde corriente es sprint más todos los sprints anteriores. Veamos los otros detalles. En primer lugar, al final de un sprint, el Incremento de Producto debe estar en una condición utilizable y debe cumplir con la definición del equipo de hecho. Entonces recuerda cualquier incremento que estamos haciendo en el sprint, sólo podemos considerarlo valioso si está en una condición utilizable y si satisface los criterios de aprobación de equipos conocidos como definición de hecho. Veremos esta definición de hecho en una conferencia posterior. Pero por ahora, solo considera que es una lista de comprobación de todos los criterios que debe cumplir el producto de punto para ser considerado como completado. En segundo lugar, el incremento debe estar en una condición utilizable independientemente de si los lados POD también lo liberan o no. Por lo que esto se ve bastante similar a la primera, pero hay una deuda en efectivo adicional está liberando el producto. Recuerda uno de los criterios de Scrum es que cada sprint debe resultar en lo que llamamos un producto potencialmente enviable. Entonces eso significa lo que hagamos en un sprint, debería ser lo suficientemente bueno como para ser liberado al usuario final. Ahora es otra pregunta si el dueño del producto quiere liberarlo o no. Podría querer liberarlo después de dos es sprints. Podría querer liberarlo después de un mes enteramente su llamado. Pero, sin embargo, cada incremento debe estar en condiciones utilizables y debería resultar en un producto potencialmente enviable. Siguiente punto con cada Sprint, el Incremento de Producto aumenta hacia la visión o meta final. Tan bastante claro, tenemos una hoja de ruta de producto, nuestra visión de cómo queremos que sea el producto final. Y con cada sprint, con cada incremento, vamos poco a poco sumando a esa hoja de ruta, ese objetivo final. Y último punto, chicos, el aspecto central de Scrum es entregar un incremento hecho. Entonces si alguien nos preguntó, qué hacemos en un sprint, la respuesta es que en cada sprint creamos un incremento al producto. Creamos un incremento agradable, mejorado, de alta calidad del producto. Y ese incremento cumple con la hoja de ruta productiva. Ese incremento cumple con la definición del equipo de hecho. Muy bien chicos, así que papá nos trae al final de los tres artefactos, el rezago del producto, el rezago del sprint y el incremento. Recapitulemos los tres artefactos una vez más a través de esta imagen. Por lo que tenemos múltiples requisitos que pueden surgir de los stakeholders en forma de nuevas características o correcciones de defectos o adiciones técnicas, etcétera. El propietario del producto retoma estos requisitos y crea un rezago del producto, que es como una gran lista de deseos de los requisitos de las cosas por hacer. Tomamos un pequeño subconjunto de requisitos de este rezago y creamos el rezago de sprint, que es el trabajo que asumirá el equipo en el próximo sprint. Y por último, una vez concluido el trabajo de sprint, tenemos un incremento al producto, que es como nuevas mejoras de edición a través nuestro producto y debería ser potencialmente enviable. Por lo que este tipo está en tu pantalla es un resumen de los tres artefactos que puedes recapitular rápidamente para tu memoria. De acuerdo, así que hemos visto todos los tres artefactos, pero hay un término que escuchamos mucho en la última diapositiva y esa es definición de hecho. Entonces veamos también qué datos hay en la próxima conferencia. Gracias. 25. Definición de Done: Hola a todos y bienvenidos al último tema de este capítulo. Hablemos de algo llamado como la definición de hecho. Entonces imagina que estamos trabajando en un sprint y tomamos una historia de usuario para diseñar la caja con tarjeta de crédito como hablamos antes. Por lo que hay como siete criterios de aceptación en la historia del usuario. Y al final del sprint, viene desarrollador y dice que he hecho todos esos siete Cambios. Todo está bien. Podemos considerar que la historia ha hecho. Ahora bien, ¿deberíamos simplemente ir por su comprensión de w1 y cerrar su historia? No. Correcto. Deberíamos tener más bien una lista de criterios de evaluación para hacer ese juicio. Porque recuerde, cada uno es 2D en el sprint debe sumarse al incremento y dar como resultado un producto potencialmente enviable. Entonces si no tenemos un conjunto de reglas, deuda certifica que la historia del usuario ha hecho. Podríamos estar agregando cosas incompletas o de baja calidad al producto. Y aquí es donde entra en escena la definición de hecho. Como equipo de Scrum, debemos crear una lista de comprobación. Deberíamos crear una lista de criterios que ese equipo pueda hacer referencia cruzada. Y en base a eso, pueden decir que el usuario es historias hechas o no. Y papá checklist se conoce como la definición de hecho. Se trata de una lista de criterios que se supone que ese equipo debe completar con éxito antes declarar la historia del usuario a hacer y antes de considerar el producto suficiente para liberar. Y cuáles son las cosas que comúnmente están presentes en la definición de hecho, podemos tener criterios como el diseño técnico debe revisarse, código debe ser probado por unidad. Las pruebas funcionales deben estar completas sin defectos críticos o bloqueadores. Se deben hacer pruebas de aceptación del usuario, etcétera. Entonces estos son solo algunos de los criterios. Sólo estoy tirando algunos ejemplos. En realidad, el equipo discutió juntos y crean una lista exhaustiva, y siguieron esa lista, cada sprint para asegurarse de que están agregando valioso incremento al producto. Entonces leamos primero la bala. Des, definición de hecho ayuda a verificar que se complete el Incremento de Producto y listo para su entrega. Entonces cuando alguien dice o historias de usuario hechas, verificamos cruzados todo en la definición de hecho está terminado o no. caso afirmativo, el incremento de planta debe considerarse completado y listo para su liberación al usuario final. Si no, corrijamos las cosas que están fallando y luego volveremos a revisar. Segunda definición de hecho ayuda a minimizar el riesgo, entender el progreso y el trabajo sabio, esfuerzo o costos. Entonces si no confirmamos que nuestro producto cumple con la definición de hecho, podría estar incompleto, podría tener defectos, podría, podría no cumplir con el requisito del usuario, etcétera. Y esto incrementará el costo de riesgo, esfuerzo, todos estos factores. Por lo que la definición del w1 ayuda a minimizar todas estas cosas. Siguiente punto, la definición de hecho varía según las empresas y el equipo, pero debe ser acordada por completo por Scrum Team. Por lo que no existe una lista fija de ítems que tengan que ser incluidos en la definición de hecho. Es algo que todo el equipo de scrum se une y discute, entre ellos el propietario del producto y el Scrum Master. Discuten todos los puntos que discuten modo deben estar ahí dentro y luego están de acuerdo con ello. Esto se convertirá en la guía de equipos y evaluarán todos los cambios futuros contra esta definición de hecho. Y por último, como se puede ver, algunos de los rubros deuda pueden estar en la definición de hecho, como ya comenté antes. Pero recuerda, esta es una lista básica que debería estar ahí en mi opinión. Es, por supuesto que se llama el equipo, deberían tener una discusión y deben llegar con su propia lista. Puedes imprimirlo, puedes pegarlo en el área de TMJ para que todo el mundo sepa cuáles son los criterios de papá que el equipo seguirá antes de certificar todo como terminado. Muy bien chicos, así que dat era todo sobre la definición de W1. Y con esto, hemos llegado al final de este capítulo. Estoy muy contento de decirles que ahora hemos cubierto las tres categorías centrales de Scrum, los roles, ceremonias, y artefactos. Por supuesto, continuaremos nuestro viaje de aprendizaje. Pero en este punto hemos aprendido muchas cosas relacionadas con su scrum. Ahora en el siguiente capítulo vamos a abordar un nuevo tema es planeación sprint y estimación muy importante y aprender al respecto. Entonces te veré en el siguiente capítulo hasta entonces. Gracias. 26. Planificación de Sprint en detalle y su importancia: Hola a todos y bienvenidos al sexto capítulo del curso. Vamos a dedicar este capítulo a dos conceptos importantes es la planeación y estimación sprint. Ya hemos hablado de la planeación de sprint en el capítulo sobre ceremonias de Scrum. Pero aquí vamos a ampliar aún más en ello porque como dije antes, también, una planeación de sprint es la ceremonia más importante de Scrum y muchas decisiones importantes y todo el trabajo del equipo para las próximas dos semanas, sprint dependerá de ella. De igual manera, al igual que cualquier otro marco de gestión de proyectos, el concepto de estimación también es muy importante pero complicado en Scrum. Es por eso que he tropezado estos dos temas de planeación y estimación de sprint en un capítulo separado para que podamos cubrir los aspectos completos en todos los detalles aquí. Entonces, empecemos. Aquí está el orden del día de este capítulo. Empezaremos con por qué la planeación sprint es importante y luego pasaremos a la estimación. Hablaremos de los puntos de historia, que es el método de estimación principal en AGI y poker de planificación, que se utiliza comúnmente para esta estimación. Y por último, hablaremos de capacidad y velocidad, que son dos aspectos a considerar cuando estamos haciendo es planeación y estimación de sprint. Entonces, empecemos. Entonces lo primero que chicos, vamos a hablar es ¿por qué es tan importante la planeación del sprint? Como vimos en el capítulo anterior, es sprint planning meeting donde todo el equipo de scrum, incluido el propietario del producto y el Scrum Master, se reúnen antes de que comiencen un sprint y retoman el usuario es historias del equipo de datos atrasados de productos trabajarán en el próximo sprint. Por lo que obviamente la planeación del sprint es la ceremonia en la que decidimos el objetivo de todo el sprint. Planeamos lo evitado que estaría haciendo el equipo completo en los próximos días y también el incremento de Producto que se desarrollaría en base a esto. Por lo que dat explica partes de ella, parte de su importancia, la importancia de la Planeación Sprint es dat. También ayuda a identificar factores como el esfuerzo y la capacidad para todo el equipo. Y esto también es muy importante para calcular y registrar. Veremos en la siguiente diapositiva cómo se hace y cuáles son los conceptos básicos detrás de ella. Pero por ahora, sólo recuerda que el plan de trabajo y la estimación son dos salidas muy clave de Sprint Planning y datas sabia planificación sprint es algo muy importante. Por lo que el punto número dos, en una planeación de sprint, finalizamos el rezago del sprint. Es decir, ¿qué estaría haciendo el equipo del verbo deudor en el próximo sprint? Por lo que las dos semanas o cuatro semanas de trabajo de todo el equipo, cualquiera que sea la duración de nuestros sprints se decidiría enteramente en base a esta reunión de planeación. Siguiente punto, se discuten y acuerdan los criterios de aceptación de requisitos exactos. Por lo que como vimos antes, los requisitos se capturan en forma de historias de usuarios y tenemos criterios de aceptación dentro de ellos. Y solo para que hagamos el producto correcto como expectativas, es importante que todo el equipo entienda estos criterios de aceptación. Por lo que en la reunión de planeación, discutimos estos criterios de aceptación y si algún miembro del equipo tiene alguna consulta o preocupación o riesgo, se destaca y se resuelve ahí dentro. Ahora recuerden, esto también podría ser algo que se haría en el aseo atrasado. Pero sin embargo es la planeación sprint es el foro en el que se vuelven a discutir y acordar los requisitos antes de que finalmente podamos llevarlos al sprint. En cuarto lugar, cada miembro del equipo estima o señala las historias de los usuarios. Por lo que es la planeación de sprint es donde también ocurre la estimación. Por eso esta reunión vuelve a ser muy importante. Siguiente tarea de punto se asignan a miembros individuales del equipo. Entonces después de haber finalizado en qué historias de usuarios estaríamos trabajando. La siguiente pregunta que surge es ¿quién hará qué? Por lo que asignamos trabajo a los miembros del equipo, creamos tareas para ellos para que todos sepan lo que se supone que deben hacer. Y último punto, se discute el desempeño del equipo vía Burndown, carta de velocidad, etcétera. Por lo que hablaremos de estos informes en capítulo posterior. Pero por ahora, solo piensa que ¿cómo podemos asegurarnos de que ese equipo esté estimando las cosas correctamente? ¿ Cómo sabemos que estamos progresando correctamente en el sprint? Entonces para eso tenemos gráficos como quemado y velocidad, etcétera. Los referimos durante la planeación del sprint para ver el desempeño del equipo. Y eso nos ayudará a no sobrecomprometernos con las cosas y aseguramos de que tomemos sólo esa cantidad de deuda laboral que podemos entregar por completo. Entonces chicos, espero que ahora tengan claro por qué la planeación del sprint es una reunión importante. Y cuando estés trabajando en una organización, asegúrate de permanecer atento y enfocado durante las reuniones de planeación de sprint, pregunta cualquier consulta que tengas. Y por último, no lo superes más de lo que puedes entregar. Muy bien, sigamos adelante y discutamos otra estimación temática en la próxima conferencia. Gracias. 27. Estimación en Scrum: Hola a todos y bienvenidos de nuevo. Hablemos ahora de estimación. Entonces chicos, la estimación es un concepto general. No se limita sólo a Scrum. Siempre que estamos trabajando en crear algo, ya sea algún producto o software, nos pediría que proporcionáramos una estimación. Estimación de datos es algún valor o número de cuánto tiempo o esfuerzo tardaría en hacer la cosa. Entonces eso es lo que es estimación. Ahora este concepto de estimación es muy importante y déjame sentarme complicado también, porque siempre que estés trabajando en un proyecto, gente podría no recordar muchas cosas, pero siempre recordarán la estimación que diste ellos y te harán rendir cuentas ante eso. Por lo que es muy importante estimar las cosas correctamente. Ahora, al igual que cualquier otro marco de gestión de proyectos es, miga también implica estimación. Y cuándo hacemos eso? Estimación? Lo hacemos durante la planeación del sprint. ¿ Qué estimamos? Estimamos historias de usuarios. Ahora recuerda en algunas empresas también estiman errores o defecto porque también toman tiempo y esfuerzo. Pero no es una tendencia general. Depende de la organización. La mayoría de las organizaciones sigue siendo sólo estimar usuario es historias. Siguiente punto, hay una diferencia fundamental en la forma en que estimamos las cosas en HI Norris Scrum y la forma en que solíamos hacerlo en otro lugar. Entonces si hablamos de los enfoques tradicionales que utilizamos para estimar de abajo hacia arriba, significado es el paso uno enumerará los requisitos. Es el paso dos, pensamos en todas las tareas a hacer es el paso tres, estimamos cada una de las tareas en horas o días. Y luego finalmente, paso cuatro, los sumamos todos para obtener la estimación general. Entonces este fue el enfoque de abajo hacia arriba que se usaba tradicionalmente. Ahora en un gel, seguimos el enfoque de arriba hacia abajo, lo que significa que estimamos en todo el conjunto de características en base a la información disponible, correcta, actualmente. Y luego a medida que surge algo nuevo, podemos incorporar deuda. Entonces la idea general, recuerda esto muy importante es estimar con cualquier información disponible. Y luego si las cosas cambian, podemos considerar eso. Y esto nos da la ventaja de reaccionar rápidamente según los cambios. Entonces esto es lo que le da su gran punto de ser adaptable a los cambios constantes. Estimamos con cualquier información disponible. Y luego si las cosas cambian, consideramos que en tercer lugar, cada miembro del equipo debería dar sus estimaciones. Por lo que un Sprint Planning es una reunión a la que asisten todos los integrantes del equipo como vimos y excepto dueño del producto y el maestro Scrum, todos ellos deben dar su estimación. Los propietarios de productos no apuntan historias de usuario, solo dan respuesta de consulta es migajas maestros tampoco apuntan a historias de usuarios. Sólo ayudan a ejecutar la planeación del sprint. No obstante, si el Scrum Master está haciendo un doble papel como desarrollador o prueba o también entonces él o ella puede señalar si el equipo está de acuerdo con ello. Pero en circunstancias normales, los donantes de productos y Scrum Masters no señalan historias de usuarios. Todo el equipo de desarrollo lo hace. Siguiente punto, si hay un conflicto el PIO o el maestro scrum debe pesar en explicar. Por lo que la mayoría de las veces sucede que un miembro del equipo estimará una historia como decir cinco puntos y otro diría como OK, son ocho puntos y no se asusten al escuchar los puntos de Word. Eso es lo que vamos a aprender en este capítulo. Simplemente piensa en ellos como unidades ahora. Por lo que una persona da el punto como 5B y otra persona da el punto es ocho. Entonces hay un conflicto. Y en casos como este donde hay un conflicto, el Scrum Master puede ayudar al equipo a llegar a un acuerdo. El propietario del producto también puede pesar si siente que 1% señaló más alto porque echan de menos los requisitos entendidos o por encima del pensamiento. Entonces la idea general es discutir y luego llegar a un consenso si hay un conflicto. Y de nuevo, tocaremos estos puntos en detalle más adelante. Pero como se puede ver, todo el ejercicio de estimación es un enfoque basado en el consenso en Scrum. En quinto lugar las unidades de estimación más comunes son los storypoints, el tiempo, los tamaños de camisetas, las unidades personalizadas, etcétera. Entonces, ¿con qué apuntan los equipos? ¿ Cuáles son las unidades? Los más comunes son los puntos de historia como 135, etcétera, la serie Fibonacci. Y vamos a aprender en un tiempo lo que significa y cómo decidir estos puntos. Ahora aparte de estos puntos, ese equipo también puede estimar sobre el valor del tiempo, o incluso pueden estimar en tallas de camiseta como pequeñas, medianas, grandes, extra grandes, etc. Punto final, los métodos de estimación más importantes son planeación poker, talla camiseta, votación de puntos, afinidad, agrupación, etcétera. Por lo que estos son solo los nombres de los métodos que utilizamos para asignar puntos a las historias de los usuarios. Ahora planear el poker es los más comunes, por lo que hablaremos de eso a detalle más adelante. Tallas de camiseta como vimos, se trata de agrupar es historias en pequeñas, medianas, grandes, extra grandes, etc. Votación de puntos da a cada miembro del equipo un número limitado de stickers de puntos y pueden votar por historias de usuarios individuales por poniendo una pegatina junto a ella. Por lo que más el número de puntos en una historia de usuario más grande es su tamaño. Ahora este método se utiliza para un pequeño número de historias y cuando queremos mantener las cosas simples, no es tan común. El método más común es planear el póquer. Y el último método 2, agrupación de afinidad. Lo que hace es pedir a los miembros de su equipo agrupar historias similares en categorías de dimensionamiento. Por lo que este método también se utiliza para estimar fácilmente si hay un gran número de historias de usuarios si quieres agrupar las cosas rápidamente. Pero como dije, el método más común para estimar es planear el póquer, y eso es lo que veremos en este capítulo. Por lo que estos son los cielos de unidad de estimación más comunes y estos son los métodos de estimación más comunes en la industria. Y recuerda, hablaremos de estos con mucho detalle en un capítulo posterior. Entonces sigamos nuestro aprendizaje y hablemos de sus puntos de historia en la próxima conferencia. Gracias. 28. Puntos de historia: Hola a todos y bienvenidos de nuevo. Hablemos ahora de puntos de historia. Entonces chicos, ¿qué es un punto de historia? En términos simples, se trata de una unidad de medida que es utilizada por los equipos de Scrum para proporcionar estimación de requisitos de completar. Entonces eso es lo que son los storypoints es solo una unidad de estimación. Y vamos a aprenderlo con un ejemplo. Entonces digamos si me acerco a ti y digo que quiero crear un sitio web de comercio electrónico. ¿ Cuánto esfuerzo se tardará en diseñar la página de inicio de sesión? Y dirás algo así, vale, es nuestro medio esfuerzo, ¿verdad? Y luego te preguntaré, vale, ¿cuánto esfuerzo tomará diseñar el flujo de caja? Ya verás que, vale, es un esfuerzo muy grande o un esfuerzo grande como papá. Entonces así es como hablamos, ¿verdad? Y ahora reemplacemos lo mismo con números. Y llamaremos a estos números como señala su historia. Por lo que vamos a estimar las cosas en algo así como 13581321. Entonces esta es la serie Fibonacci y vamos a utilizar estos valores por ahora. Por lo que le pediremos que proporcione estimaciones sobre estos números solamente. Entonces si te pregunto eso, está bien. Si es un cambio muy pequeño, como sólo cambiar algunos textos verbiage, dirás que, vale, es un 1. Si es un poco más complejo de lo que es de tres puntos, si quiero diseñar la página de inicio de sesión, entonces probablemente dirás que son cinco puntos u ocho puntos. Si quiero diseñar la página de checkout, verás que es muy compleja. Probablemente sean 13 puntos o 21 puntos. Tan como la deuda. Entonces chicos, papás, lo que es storypoint es, podrías haber pensado que es demasiado complicado, pero en realidad es tan simple como eso, un número para indicar la estimación de pensar, escribir. Y aprenderemos más sobre esto, cómo progresamos, lo más importante, cómo damos esta estimación. Pero por ahora, sólo recuerda que un punto de historia no es más una unidad de medida que se utiliza para la estimación. En segundo lugar, los equipos de ILL de edad utilizan el formato de puntos de historia versus tiempo. Por lo que en HI Lori Scrum, la unidad primaria de estimación es un punto de historia. Y la razón por la que no usamos el tiempo es porque la definición del tiempo de todos es diferente. Si le pregunto a persona uno cuánto tiempo tardará en diseñar el flujo de caja. Dirá que tal vez 20 horas. Si le hice la misma pregunta a la persona B, dirá que tardará 30 horas. Por lo que diferentes personas tienen diferente unidad de tiempo, y eso es por la diferencia en su conocimiento o experiencia pasada, etcétera. Pero si le pido a la misma persona que estime historias de un usuario relativas a otro a través de sus puntos de historia. Al igual que si ejemplo, les pedí a ambos que me dijeran lo complejo que es el flujo de caja en cuanto a puntos de historia, lo más probable es que surjan valores similares. Y esa es la lógica de por qué confiamos en sus puntos de historia sobre valores basados en el tiempo. No obstante, recuerda que los puntos también lo son, los puntos se utilizan en la historia, nivel User Story. Seguimos utilizando la nuestra en la tarea asignada a miembros individuales del equipo para que podamos decidir su tiempo disponible. Pero esa no es nuestra unidad primaria de medida en AJI. Si alguien viene a ti y te pregunta cuál es la salida del equipo, dirás que es x puntos, no vía horas. Por lo que Story Points son la unidad primaria de estimación en VIH o scrum. Siguiente punto estimamos sin compromiso de tiempo y abrazamos la incertidumbre. Entonces cuando estamos estimando en unidades de tiempo, tenemos que hacer un compromiso preciso de tiempo. Pero son los storypoints evitan esto porque no hay mención del tiempo. También cuando estás usando los puntos de historia, nos permite captar la incertidumbre, que todos sabemos es una realidad práctica cuando estamos tratando con requerimientos. Por lo que cuatro puntos de historia. Utilizamos valores discretos como 1358 etcétera, que es una serie Fibonacci, como dije. Y esto aborda la incertidumbre porque verás que a medida que los números son cada vez más grandes, la diferencia entre ellos también va en aumento. Por lo que esto ayudará a levantar una alarma si el punto es enorme, como 13 o 21, y esto significaría que los requisitos son demasiado complejos. Tenemos que descomponerlos en historias más pequeñas. En cuarto lugar, los valores relativos importan más que el valor crudo. Por lo que los puntos de historia de día muy importantes podrían no significar mucho si los miras aislados con, pero si los consideras de una manera relativa, entonces proporcionaría gran claridad. Entonces por ejemplo, es historia deuda se señala tres sería tres veces más que una historia apuntada uno, y sería la mitad de algo apuntado cinco. Entonces así como así, podemos entenderlo en términos relativos. El siguiente punto son los storypoints consideran esfuerzo más complejidad, incertidumbre. Entonces este es un concepto muy importante y muchas veces se le pide esto a la gente en entrevistas. ¿ Qué indica esta historia? Entonces la respuesta es que sus puntos de historia indican la complejidad de una historia junto con el esfuerzo y cualquier incertidumbre. Por ejemplo, digamos que queremos cambiar el tamaño de la imagen de perfil en Facebook. Queremos hacerlos más grandes ahora mismo vienen en cuatro por 400 pixel y queremos hacerlos 700 por 700 pixels. Tan sencillo, sólo queremos hacer este cambio. Entonces si le preguntamos al desarrollador, diría que es un cambio muy simple 1 para mí. Pero si consideras lo mismo desde el aspecto del tester, él o ella tendría que verificar el mismo cambio en diferentes dispositivos de navegadores. Tendría que asegurarse de que no rompa nada como mostrar la imagen del perfil en página del grupo, etcétera. Entonces por eso la complejidad podría ser baja, pero el esfuerzo para el probador es alto. Por lo que tenemos que considerar todos estos factores. Y este es un ejemplo muy, muy sencillo de esfuerzo y complejidad. Veremos más sobre él más adelante. Y si tenemos algunas incógnitas también en el requerimiento, dash también debería reflejar en el punto. Por lo que probablemente tomaremos un camino seguro y señalaremos un poco más alto si hay alguna incertidumbre. Entonces estos son todos los procesos de pensamiento que van a apuntar y veremos cómo dar punto pronto. Pero por ahora, recuerda muy importante, se pregunta en entrevistas también, si alguien te pregunta, qué indica este punto de historia sobre qué base al dar puntos de esta historia, dile que es esfuerzo plus complejidad más incertidumbre. Y el último punto es Story Points son un poco confusos al principio, pero evolucionamos como equipo. Cuando veo gente nueva en su equipo, inicialmente son esfuerzo de apuntar o simplemente repiten los puntos dados por otros. Y eso es porque no saben lo que darán los demás. Y luego se les puede cuestionar dónde, por qué sus puntos son diferentes. Entonces evitar todas estas dudas no caigan en esta trampa son storypoints es un poco desconcertante en el principio, ¿de acuerdo? Pero dentro de uno o dos sprints, aprenderás a evolucionar como equipo, a apuntar las cosas como equipo, y entonces estarías bien. De acuerdo, para ayudar a que este viaje sea aún más fácil para ti ayudarte a explicar todos los detalles de sus puntos de historia. Hablemos de cómo algunos consejos que nos pueden ayudar a decidir sobre dar los puntos correctos de la historia. Entonces veamos eso en la próxima conferencia. Gracias. 29. Cómo decidir los puntos de la historia con ejemplos comunes: Hola a todos y bienvenidos de nuevo. Vamos a aprender sobre los consejos para decidir los mejores puntos de la historia. Pero antes de seguir adelante, recapitulemos las tres informaciones más importantes sobre sus puntos de historia que vimos antes. Número uno es Story Points son una unidad de estimación en un IG. Número dos es Story Points se dan como números, más comúnmente serie Fibonacci 13581321. Y número tres, los puntos de la historia incluyen complejidad, esfuerzo, y cualquier incertidumbre. De acuerdo, entonces ahora que sabemos lo que son Story Points, supongamos que estamos sentados en la planeación del sprint y el primer usuario es historia viene a discusión. Y sabes que tienes que señalarlo pronto con todos los demás en el equipo. Entonces, ¿cuál es el proceso de pensamiento que está pasando en tu mente? Cuáles son los diferentes consejos y trucos que puedes usar para asegurarte de que estás apuntando de manera efectiva y correcta. Entonces leamos sobre ellos. El primero, dé lectura a los criterios de aceptación y haga preguntas para mayor claridad. Por lo tanto, asegúrese de entender el requisito detallado que está devolviendo los criterios de aceptación. Ya sabes lo que acepta el Propietario del Producto, se espera que se haga y no hay duda si tienes alguna duda, pregunta al Propietario del Producto, pregunta al desarrollador o a un probador y deshazte de cualquier incógnitas o cualquier consulta que vas a tener. Siguiente final el aspecto más importante a hacer de nuestra parte. Piensa en tu trabajo a fondo. Si eres desarrollador, Piensa en lo que todo lo que tendrás que codificar. Ya sea un código heredado, ya sea front-end, back-end API, si se trata de un área compleja, etcétera. Si eres una prueba o piensas en los escenarios de alto nivel, cómo obtendremos los datos de prueba. ¿ Tienes que probar en varios navegadores? ¿ Tienes que probar en diferentes dispositivos, etcétera? Entonces piensa en todo esto. Piensa en estas cosas cuando estés leyendo los criterios de aceptación y esto resolverá el 99.9% de tus problemas. Esto te dará un gran detalle sobre la complejidad y esfuerzo que está involucrado en esa historia. Y usted sería capaz de apuntar de acuerdo a eso. En tercer lugar, escuchaba otras respuestas y comentarios. Entonces como dije antes, es la planeación de sprint es una reunión muy importante. Así que estar atentos ahí, estar enfocados. Están escuchando lo que otros están viendo porque tus dudas o alguna información adicional podrían estar escondidas en deuda y eso cambiará tus pensamientos sobre la historia. Siguiente punto, aprende de estimaciones pasadas. Por lo que la estimación es algo chicos, la deuda viene mucho de la experiencia pasada también. Por lo que debes tener en cuenta tu aprendizaje del pasado, ya sea trabajando en algo similar o conociendo la funcionalidad e incluir eso en tu estimación. En quinto lugar, hacer estimaciones informadas pero no inflar por conveniencia. Por lo que una de las cosas que pasa mucho es gente tiende a apuntar las cosas más altas por el bien de la comodidad, simplemente mantendrán todo en el cubo más alto, pero eso no es correcto. Trata de hacer tu estimación lo más basado en conocimientos como sea posible. Siguiente punto discutido, no sólo promedien cuatro 0s. Entonces este es un punto muy importante. Digamos que el equipo está señalando una historia de usuario. Y la persona a da pi, cinco puntos, y la persona B da 13 puntos. Entonces hay un conflicto. Una persona está diciendo que es 5 o la persona está diciendo que es un puntero 13. Ahora lo que no debemos hacer es decir eso, vale, le das cinco. Dio 13. Entonces, acomodémonos con un ocho. No, la deuda está mal. Tenemos que discutir por qué la persona a piensa que es un cinco, y tenemos que discutir por qué la Persona B piensa que es un 5V, necesitamos escucharlos a ambos. Y entonces necesitamos llegar a un consenso y por qué. Porque tal vez haya alguna información adicional que está con ellos. A lo mejor no pensamos en algo, mejor no conseguimos los detalles completos. Por lo que siempre debe haber una discusión en caso de conflicto, cada parte debe dar sus argumentos y luego el equipo debe leer punto. Entonces esto es muy importante, como dije. Y como siempre, el Maestro Scrum jugaría un papel importante para facilitar esto. Séptimo, si es demasiado alto, se divide. Por lo que cada equipo aprende de su experiencia, lo que es el máximo es punto de historia que pueden hacer. Normalmente si son 13 o 21 para la mayoría de los equipos. Pero si es 13 puntero o 21 puntero, significa que es demasiado grande. Los requisitos son irrumpir y dividir visualmente la historia del usuario en componentes más pequeños. Y el último número ocho, no te preocupes, mejorará con el tiempo. Entonces como dije, la estimación es algo que viene mucho de la experiencia. No te preocupes si tus puntos son demasiado diferentes a los demás al principio, solo dale un par de sprints y luego estarás bien. Recuerda también que está bien tener diferentes puntos porque podrías tener alguna información que otras personas no tenían. A lo mejor no pensaron en algo. Entonces, apunta como te parece bien y luego da tu lógica de apoyo si hay un conflicto. Muy bien chicos, así que estos son algunos de los consejos prácticos que te ayudarán a apuntar mejor. Ahora consideremos algunos ejemplos comunes de cada historia puntos para que ayudes, para que entiendas aún mejor el concepto. Entonces chicos, como comentábamos en el pasado, normalmente usamos la serie Fibonacci para apuntar. Y como se puede ver en la pantalla, tenemos las tarjetas cuatro valores, 13581321, deuda que el equipo puede utilizar para apuntar. Normalmente, el 21 es un valor muy alto y significaría que el cambio es demasiado complejo o toma de esfuerzo. Y debe desglosarse en historias más pequeñas. O si hay un montón de incógnitas 2, entonces deberíamos resolver primero esas incógnitas y luego retomar la historia tal vez en el próximo sprint. El recuerdo. En algunas empresas también podrían pensar en 13 punto alto S2 y lo dividieron. Simplemente depende de la experiencia pasada del equipo, si habían podido hacer 13 punteros en el pasado o no. Si no se sienten cómodos con 13 punteros, si no hubieran podido completarlo en el pasado, podemos dividirlo en múltiples historias de como 5.8.3 puntos así. Entonces veamos cuáles son algunos de los escenarios comunes que encajaremos en cada valor de punto. Y como siempre, tomaremos el ejemplo del sitio web de comercio electrónico porque eso es algo que todos hemos utilizado y con lo que nos podemos relacionar. Por lo que los chicos en la pantalla de la derecha está empezando desde el punto más bajo, el de un punto. Entonces 1 es una obra muy, muy menor, extremadamente baja o 0 complejidad, como supongamos en la página web queremos cambiar el nombre de algo. Queremos hacer algunos cambios a cualquier mensaje de texto. Queremos cambiar el nombre de inicio de sesión para iniciar sesión, o queremos cambiar la palabra del historial de pedidos a tu pedido. Tan como la deuda trabajo muy pequeño, muy baja complejidad. A continuación tenemos tres puntos. Entonces esto es algo poco más esfuerzo y complejo que uno porque recuerden, como discutimos, es Story Points son relativos. Entonces justifique, si sólo les digo que algo es 3, no significa nada. Sólo significará algo si lo comparas con un puntero o un puntero y entonces tendría sentido clasificar las cosas. Entonces, ¿qué tres es? Tres es un poco más de esfuerzo y complejidad que uno, como si estamos creando la opción Eliminar en el carrito de compras. Haga clic en el producto, se retira de la tarjeta, se actualiza el precio, cosas como deuda u otro ejemplo es el email de contraseña olvidada. Por lo que todo el cambio de contraseña olvidado sería muy grande. Pero aquí sólo estamos hablando de enviar correo electrónico. Hemos desglosado la historia en pedazos pequeños. Sólo estamos hablando del correo electrónico. Por lo que enviar el correo electrónico con un enlace para restablecer contraseña es muy probable un tres y la deuda es solo para darte un ejemplo, una cosa más a considerar aquí es que algunos equipos también usaron dos puntos. Por lo que utilizan en la serie Fibonacci, también insertan punto valor dos. Entonces eso es algo de nuevo que se basa en la relatividad. Es algo que es un poco más complejo que uno, pero menos complejo que tres. A continuación tenemos el puntero fie. Entonces déjenme decirles chicos que 58 son los valores usados más comunes y significan la complejidad media. Entonces la fibra es algo así como buscar un producto porque hay muchas combinaciones en la búsqueda. Hay integraciones externas también para entregar el resultado de búsqueda, etc. Así que es una complejidad media y soviética diciendo que es a-fib. O digamos si quieres crear un formulario de contacto vendedor que el usuario llene y envía la información al vendedor como deuda. Entonces eso también es fie pointer porque estamos creando una forma. Lo estamos integrando al tercero proveedor. Estamos enviando el correo electrónico al equipo correspondiente. Por lo que un montón de piezas móviles. Diremos que es un puntero de archivo. Muy bien, el siguiente es ocho puntero. Entonces otra vez, más complejo y esfuerzo tomando luego 5p. Entonces como diseñar el flujo para registrarse en la página web, Necesitamos un formulario, necesitamos guardar los detalles. Tenemos que asegurarnos de que el correo electrónico sea único. Tenemos que asegurarnos de que la contraseña sea fuerte. Necesitamos enviar el correo electrónico al usuario. Entonces como puedes ver, es un poco más de trabajo y complejidad que lo que llamamos 5p. De igual manera, si estamos agregando el artículo al carrito, es un flujo muy importante en el comercio electrónico. Por lo que necesitamos atender a Agregar al Carrito un solo artículo, artículo múltiple. Y en realidad las cosas más complicadas como si el producto no está disponible o si no puedes agregar o menos o más de diez cantidad, si ya tienes el artículo en tarjeta a través de ese tipo de cosas. Por lo que hay muchos escenarios, muchos flujos a considerar. Y también tenemos que tener en cuenta la cantidad de precios, todos estos sistemas diferentes. Entonces por eso lo llamaré ocho. Ahora la mayoría de las veces cuando estás integrando algo a un sistema externo, lo que significa algo fuera del equipo, suele ser un poco mayor esfuerzo, complejo. Es poco complejo superior, lleva más tiempo. Por lo que siempre que estés esperando algo, siempre que haya una dependencia externa de su equipo, asegúrate de incluir eso también en la imagen y apuntes un poco más alto. Está bien. El siguiente es 13. Entonces como dije, los 13s generalmente se dividen en historias de usuarios más pequeñas si el equipo no se siente cómodo porque es un gran cambio como diseñar todo el flujo de caja. Y tal vez eso sea incluso a los 21. Nota a los 13 más, tal vez estamos integrando un nuevo método de pago como estamos integrando PayPal o Apple deuda de pago estaría en 13 porque puedes entender mucho trabajo por hacer. Hay muchas integraciones, coordinaciones con el equipo externo. Hay muchas pruebas de extremo a extremo que están involucradas. Entonces por eso lo señalaré como 13. Ahora recuerden chicos, estos son solo ejemplos en sus empresas. Algunos de ellos pueden ser apuntados de manera diferente en función de tu experiencia pasada y cuánto conocimiento tienes y lo aprenderás una vez que empieces a trabajar. Estos ejemplos que he dado aquí son desde una perspectiva laica y sólo consideran el caso más común. Pero si tú alguna parte, si vas a una entrevista y te piden ejemplos, puedes citarlos. Muy bien chicos, así que espero que estén claros en sus puntos de historia ahora es todavía si tienen alguna duda o algún escenario de su empresa o entrevistado en, querrán dudar, no duden en usar la Q y una opción o envíeme un correo electrónico. Entonces este es mi email id, chicos. Y si tienes alguna duda, como dije, si tienes alguna duda o algún escenario de tu empresa o entrevista donde las cosas no estaban claras para ti quieres discutir, no dudes en usar la opción q ND o me dejas caer un correo en esta dirección. De acuerdo, ahora que hemos aprendido acerca de sus puntos de historia, hablemos del método de apuntar las cosas. Y va a ser un tema muy interesante. Entonces veamos eso en la próxima conferencia. Gracias. 30. Planificación de Poker: Hola a todos y bienvenidos al tema de planeación poker. Entonces no se preocupen chicos, no voy a empezar de repente a enseñar su póquer. Todavía estás en el correcto curso de HL. De lo que es el poker de planificación, es una técnica de estimación y planificación milenaria que se basa en la participación del equipo y el consenso. Entonces recuerda, como hablamos antes, también planear el poker es uno de los métodos para estimar las cosas, y hay muchos otros métodos también, pero planear el poker es lo más común. Es el más consensuado Y yo diría que es el método más envolvente para la estimación de equipos. Y por eso es utilizado por la mayoría de las organizaciones. Y la forma en que funciona es, y eso es lo que está escrito en la diapositiva también, pero hablemos de ello. Entonces digamos que estamos en la planeación del sprint. El propietario del producto abre el primer usuario es historia del rezago del producto y él o ella habla de ello. Dice al equipo cuál es el requisito, cuáles son los criterios de aceptación, etc. Si hay alguna duda o riesgo, etcétera aquí, o el propietario del producto lo atiende. Y una vez hecho todo, una vez que el equipo está claro en todos los requisitos, no tienen ninguna consulta, no tienen ninguna incógnitas, no tienen ningún riesgo. El dueño del producto o un Scrum Master dará a cada miembro del equipo un conjunto de tarjetas como esta que vimos en la pasada conferencia. Por lo que a todos les darían tarjetas con el número 13581321 escrito en él. Y recuerdo chicos, el dueño del producto y el Scrum Master, no apuntan. Por lo que no llevarían ninguna tarjeta en el equipo de desarrollo tomaría. Y al conteo de 1.2.3, todo el equipo revelará la tarjeta en base a su estimación de la historia del usuario. Por lo que todo el mundo levantaría una de estas tarjetas reflejando los puntos de la historia que creen que es apropiado. Si todo el mundo obtiene los mismos puntos, lo suficientemente bueno, eso se convertirá en el punto de la historia. Si no, si hay un conflicto como, digamos, persona uno, corre la carta por cinco puntos y la persona B levanta la carta por 13 puntos, entonces ambos tienen que explicar cuál es la razón detrás de elegir ese número. Y por eso dije en un principio también este es un ejercicio basado en consenso. No vamos a decir eso, vale, todos menos una persona dieron 13, todos los demás dieron cinco. Entonces digamos que cinco es el punto de la historia. Tenga en cuenta que es incorrecto. Incluso si una persona dio 13 o incluso si una persona dio un número diferente al otro, entonces esa persona tiene que explicar la lógica detrás de elegir ese número. Porque recuerden chicos, podría saber algo o podría haber pensado en algo, o podría haber, por su experiencia pasada, saber algo que otros miembros del equipo no lo saben. Por lo que es necesario escucharlo. Y así tenemos una discusión en torno a esto, por qué dio unos puntos altos, por qué la otra persona piensa que es un punto bajo. Y en base a lo que dice la persona, de nuevo, leemos punto todo el asunto y esta cosa sigue y sigue de nuevo hasta que haya consenso. Si hay alguna nueva información que sale de ella, el dueño del producto tiene que contestar eso. Si hay un riesgo o desconocido que sale de él, entonces el propietario del producto tiene que disolverlo. Y sólo entonces el equipo seguiría adelante y tomaría la historia de este usuario y apuntado. Entonces así funciona. Y este mismo punto, todas las historias de usuarios que el equipo tiene que tomar en el sprint. Entonces chicos, eso era todo sobre planear el póquer. Y como dije, es un método muy interactivo, basado en el consenso para estimar cosa. Y es el más ampliamente Uno. Un punto más a añadir aquí, la actividad de planear el poker dat está dando puntos de una historia. También se puede hacer en el aseo atrasado. Una vez que el equipo pasa por las historias de los usuarios en el aseo atrasado y se despejan todas sus dudas, entonces podemos señalarlo. Solo están usando Story Points y planeando poker. No obstante, 1 de nota, pesar de que lo hacemos en el aseo atrasado, todavía se recomienda volver a visitar los puntos de la historia y discutir las cosas una vez rápidamente durante una planeación de sprint porque recuerda que algo podría tener cambió, habría surgido alguna nueva información y además todo el equipo no estuvo presente en el aseo atrasado como vimos, pero ahora están presentes en la planeación. Por lo que es una mejor práctica para recapitular rápidamente aunque ya hayamos apuntado cosas en el aseo atrasado. Muy bien chicos, así que todo se trataba de planear póquer. El tobogán también dice las mismas cosas que hablamos. Entonces si quieres, puedes hacer una pausa y leer la diapositiva. Pero de todos modos, ya hemos cubierto todo eso. Entonces sigamos adelante y hablemos del siguiente tema, capacidad de equipo en la próxima conferencia. Gracias. 31. Capacidad de equipo: Hola a todos y bienvenidos a esta próxima conferencia. Entonces en este vamos a hablar de la capacidad del equipo y cómo hacemos una planeación de sprint basada en esta capacidad. Entonces, primero entendamos qué es la capacidad. Ahora cuando el equipo se reúne para la planeación del sprint. Y supongamos que estamos discutiendo las cosas para un sprint de dos semanas. Por lo que dos semanas significan que hay diez días hábiles y cada día laborable es de ocho horas. Por lo que se supone que cada persona aporta una t horas en este sprint. Pero esto podría no ser cierto. Alguien podría estar tomando un permiso o alguien podría tener un entrenamiento, o puede estar ocupado con otros compromisos. Esto puede pasar, ¿verdad? Esto es algo práctico y esto es lo que la capacidad toma en contexto. ¿ Cuál es la disponibilidad del equipo en horas para este sprint? Y en base a eso, haríamos la planeación del sprint. Entonces veamos ahora la diapositiva. En primer lugar, Capacidad es la disponibilidad de equipo en horas para el sprint. Entonces ya vimos esto. Estamos estimando la palabra deuda se puede hacer en este sprint según las horas disponibles del equipo. Siguiente punto, la capacidad se calcula por el total de horas de trabajo en un sprint menos los compromisos personales o profesionales que son miembros del equipo podrían tener. Digamos que los integrantes del equipo podrían tener reuniones de hojas en ceremonias de Scrum, etcétera. Entonces tenemos que descartar eso y luego tenemos que calcular el total de horas de trabajo del equipo. Y de hecho, veámoslo por ejemplo. Entonces chicos, digamos que tenemos cinco integrantes en el equipo, a, B, C, D, E, y hay diez días en el sprint con un total de horas de trabajo de ocho horas cada día. Por lo que el total de horas que todo el mundo en el equipo tiene es de 80. Ahora consideremos que un día en el sprint es un día de fiesta, así que todos estarían libres, nadie estaría trabajando. Por lo que todo el mundo no tendría ocho horas disponibles para este sprint. Entonces digamos que la persona a está de licencia por un día, por lo que no va a estar ahí por otras ocho horas. Descansa, nadie está tomando hoja, así que estamos poniendo 0. Y entonces digamos que la persona D tiene un entrenamiento durante cuatro horas en un día. Por lo que durante cuatro horas no va a estar trabajando en el sprint. Y por último, dejemos de lado algunas veces para diferente es ceremonias de miga porque recuerden, estamos teniendo un standup diario, Estamos teniendo rezago aseo. Podríamos tener algo otras reuniones, etcétera. Por lo que más o menos dejemos fuera seis horas de tiempo para todo el sprint para todos. Entonces que la disponibilidad real del equipo es así, que son 400 horas menos todas estas cosas que están aquí. Por lo que el total de horas disponibles fue de 400, y luego vamos a estar ocupados por 82 horas, algún miembro u otro. Por lo que la capacidad disponible va a ser de 400 menos 80 a 318 horas. Por lo que 318 horas es la cantidad de tiempo que tenemos para este sprint. Y cualquier cosa que queramos hacer en este sprint, sólo debemos planear para esa cantidad de trabajo que se puede hacer en estas 318 horas. Eso es lo que es todo el concepto de capacidad. Y de hecho, vamos a ser más realistas porque sólo estamos planeando borde a borde aquí. Entonces, idealmente, seamos más realistas y solo consideremos una parte de este tiempo. Por lo que hay algo llamado como factor de enfoque. Eso es lo que es el equipo es capaz de mantenerse enfocado. Y asumimos que cualquier equipo tiene un factor de enfoque de sólo 80%. Eso significa que el equipo va a estar enfocado sólo el 80% del tiempo. Entonces la capacidad real que vamos a tener es del 80% de este 318, es decir 258254 horas. Entonces esta es nuestra capacidad. Esta es la capacidad del equipo y esta es la duración de tiempo por la que debemos estimar el trabajo en este sprint. Entonces ahora que sabemos que tenemos 254 horas de capacidad, partiremos de la historia de mayor prioridad y luego comenzaremos a sumarle tareas. Entonces volvamos al tobogán y veamos al respecto. Por lo que tenemos 254 horas de capacidad. Empezaremos desde la historia de mayor prioridad y le añadiremos tareas. Al igual que agregaremos desarrollo front-end, pruebas de desarrollo back-end, etcétera, todas las diferentes tareas que se necesitan para completar esa historia. Y para cada una de estas tareas, agregaremos estimado nuestro satélite para una historia número uno, ese desarrollo tomará cinco horas. El desarrollo del back-end tomará cuatro horas, las pruebas tardarán dos horas, etcétera, solo por ejemplo. Por lo que tenemos un total de 11 horas de deuda se retomaría en esta historia en particular. Ahora la capacidad restante, recuerda que teníamos una capacidad total de 254 horas. Por lo que la capacidad restante es de 254 menos 11, es decir, 243 horas. Por lo que tuvimos una capacidad inicial de 250 o cuatro horas. El primer cuento va a llevar 11 horas de trabajo. Ahora nos quedan 43 horas de trabajo, por lo que aún tienes capacidad. Pasemos a la siguiente historia. Estimemos la tarea en deuda, y digamos que tomará diez horas. Por lo que tuvimos que 43 horas después de la primera historia. El cuento creará diez horas. Entonces ahora tenemos 233, nuestro soviético todavía tiene capacidad. Pasemos a la siguiente historia y así es como va. Seguimos escogiendo una historia hasta que tengamos capacidad disponible. Una vez que se agota la capacidad, dejamos de tomar más historias y lo que hayamos tomado hasta ahora se convierte en nuestro rezago de sprint en el que trabajará el equipo en el próximo sprint. Entonces eso es todo chicos, así es como se hace la planificación basada en capacidad. Y se considera una forma muy eficiente de hacer una planeación de sprint. Porque recuerden, estamos siendo muy realistas en el cálculo de la disponibilidad de todos para trabajar. Nadie puede estar ahí para trabajar unas 100 horas. La gente podría tomar hojas, la gente podría no estar disponible. Y estamos tomando en consideración todos esos factores. Estamos comparando su tarea con el JavaScript está disponible para averiguar cuánto tiempo hay. Y es por eso que la capacidad del equipo planear la capacidad del equipo y usar esa capacidad del equipo para hacer una planeación de sprint es muy eficiente, muy útil. De acuerdo, entonces ahora que hemos visto planeación basada en capacidad, veamos la otra variante, planeación basada en velocidad en la próxima conferencia. Gracias. 32. Velocidad de equipo: Hola a todos y bienvenidos a esta conferencia sobre velocidad y velocidad basada es la planeación sprint. Entonces hablemos primero de qué es la velocidad. Velocity es la cantidad de trabajo que se termina por equipo en cada sprint papás lo que es. Entonces, en realidad lo aprendamos con un ejemplo. Entonces digamos que en un sprint uno, tomamos diez historias de usuarios y son totalmente story point fue de 75. Se, al final de esta impresión ese equipo pudo completar ocho historias de usuarios. Y el total de puntos de historia que pudieron entregar fue de 60. Sprint al equipo tomó un t puntos de historia y pudieron entregar en 55 puntos de historia. En un sprint tres, el equipo se llevó 60 puntos de historia y pudieron entregar sólo 40. Por lo que nuestra velocidad promedio es el promedio de estos tres números que el equipo pudo completar. Entonces aproximadamente alrededor de 50 o 51 puntos, esa es nuestra velocidad y eso es lo mucho el equipo debe planear asumir en el sprint. Entonces lo haremos, cuando nos reunamos para la planeación sprint, comenzaremos con las Historias de Usuarios en orden prioritario, y seguiremos llevándolas, seguiremos sumando sus puntos. Y una vez que lleguemos a 15 puntos de historia, notaremos que esto es lo mucho que podemos hacer. Esto es lo mucho que hemos podido hacer en promedio en los últimos tres sprints. Nos detendremos ahí. No tomaremos más de 50 puntos de historia. Subiremos todas las historias hasta que esa 15 historia apunte a nuestro rezago de sprint. Y eso es todo. Es así como la planeación del sprint basado en velocidad funciona tan simple como la stat Veamos ahora qué dice la diapositiva. Todo aunque hemos cubierto muchas de estas cosas. Por lo que la velocidad de los puntos de partida es la cantidad de trabajo terminado por equipo en cada sprint. Esa es la definición de velocidad que vimos. Y se calcula sumando los puntos de historia de todas las historias de usuarios completadas en el sprint y tomando su promedio, como vimos en la hoja de excel. Tercer punto, idealmente usamos los últimos tres sprints hasta los datos para capturar la velocidad. Y este tipo es muy importante. Se hace para evitar cualquier fluctuación temporal. Entonces digamos que ese equipo era un equipo tierno entregó menos en un sprint porque las historias que tomaron eran más complejas. O digamos que mucha gente estaba de licencia en datos Sprint o hubo alguna interrupción, etcétera. Por lo que queremos descartar esas fluctuaciones temporales. Y por eso vamos a calcular la velocidad. Tomamos el promedio de al menos los últimos tres sprints y usamos eso para calcular nuestra velocidad. Segundo último punto, aparte de estimar las cosas correctamente y evitar sobrecompromiso, los datos de velocidad son muy útiles, especialmente para la planeación de proyectos. Y eso se debe a que le da al propietario del producto y al titular de la participación una idea clara de cuántos sprints tomará para entregar la funcionalidad requerida. Entonces digamos que tenemos n número de historias de usuarios que quedan en el rezago y el equipo es capaz de hacer 15 puntos de historia en promedio. Esa es nuestra velocidad. Entonces eso nos dará una idea de cuánto tiempo tardará completar esas cualesquier historias en el rezago. Y último punto, siempre debemos considerar los datos de velocidad en cada planeación de sprint para que conozcamos el historial pasado de ese equipo y no lo superemos a las cosas. Por lo que uno de los problemas más comunes que enfrenta el equipo en realidad es el problema del exceso de compromiso. Y echando un vistazo al historial pasado de ese equipo, los datos de velocidad ayudarán a resolver este problema. Muy bien chicos, así que hablamos de velocidad y capacidad, y también hablamos de hacer una planeación de sprint basada en ellos. Quería mencionar una vez más en este punto que es que los equipos de Scrum sufren de un problema muy común de sobrecompromiso, donde metemos muchas historias de usuarios en el sprint. Y luego al final del sprint, muchos de ellos permanecen abiertos. Por lo que esta es una realidad muy común y práctica. Se llama como sobre compromiso y sucede mucho. Por eso es muy importante mantener un ojo en la velocidad y también calcular la capacidad cuando estamos haciendo una planeación de sprint porque si el equipo no está disponible, si el equipo está de licencia, entonces no estaríamos no debe tomar tanto trabajo como idealmente deberíamos completar. Entonces eso es lo que normalmente hago y recomiendo. Lo que hago es usar la capacidad para planear cosas para el próximo sprint. Y uso los datos de velocidad para tener una idea general de cómo el equipo sigue siendo cada récord. Por lo que ambos puntos son igualmente importantes. Ambas métricas son igualmente importantes y debemos considerarlas a ambas cuando estamos haciendo una planeación de sprint. De acuerdo chicos, entonces con esto, llegamos al final de este capítulo tan importante y cubrimos aquí el muy importante tema de estimación. Tan gran aprendizaje. Déjame repetirlo que si tienes alguna consulta o duda sobre algún tema de este curso, por favor, no dudes en usar la Q y una opción o dejarme un correo electrónico. Los conceptos de estimación son particularmente muy confusos al principio, aunque a medida que evolucionas, estarías bien. Pero si tienes alguna pregunta, si no tienes claro nada, si necesitas ayuda con algún tema específico de tu organización, por favor no dudes en dejarme un email, mis ideas de email ahí mismo. Y siempre responderé a su mensaje en un plazo de 24 horas. De acuerdo, así que sigamos con el impulso de nuestro aprendizaje y veamos un nuevo tema en el próximo capítulo. Gracias. 33. El tablero de Scrum e introducción a las métricas de Scrum: Hola a todos y bienvenidos al séptimo capítulo del curso. Entonces chicos, este capítulo se trata de reportes o métricas utilizadas en Scrum. Y si lo piensas, cada marco de gestión de proyectos en el mundo necesita un mecanismo de presentación de informes para medir la efectividad y el progreso de las cosas. Y es Scrum no es la excepción. En su Crump hay varias opciones para medir el progreso y vamos a aprender de ellas en este capítulo. Y notarás una cosa única, y es que todos ellos no se trata de rendimiento individual. Más bien se trata de equipo de Dart. Entonces eso es lo que es Scrum es como vimos antes. Tenemos éxito o fallamos como equipo. Entonces empecemos y echemos un vistazo a los contenidos. Ahora recuerden chicos, he incluido aquí algunos temas que normalmente no encontrarán en otros informes discusión, pero son igualmente importantes para medir las cosas y por eso quería hablar de ellas. Por lo que comenzaremos con la junta de Scrum y diariamente reportando desde ella. A continuación, aprenderemos el Bund abajo y quemaremos gráficos seguidos gráfico de velocidad y cómo incluso podemos usar el Retraso de Productos para observar las cosas. Entonces, empecemos. Entonces el primer tema que vamos a ver es el tablero de Scrum. Y en realidad el tablero de Scrum es la cara de cada proceso de Scrum. Si vas a algún lugar que esté siguiendo es miga, probable que notes este tablero físico y en él se enumeran las diferentes historias de usuarios que ese equipo está haciendo y su progreso. O podría haber una versión virtual del mismo en el Gita o cualquier otra herramienta que estemos usando. Pero sin embargo es Scrum tableros y la colocación de los usuarios historias sobre ellos. El primer medio para comprobar el avance de las cosas. Entonces como dice la diapositiva también, se desmorona es una instantánea visual del rezago de sprint. Es decir, el usuario es historias que estamos haciendo en este sprint. Y se mantiene en forma virtual o física. Por lo que algunos de los equipos hacen el se desmorona en formato virtual, mientras que otros lo mantienen en una versión física. Ambos son iguales en el diseño. Si primero te muestro la versión virtual, así es como se ve. Entonces este es un proyecto para un sitio web de comercio electrónico, y como puedes ver, hay múltiples historias de usuarios como esta. Uno aquí es para la página de inicio de sesión, este de aquí es para la página de pago, etcétera. Y para cada una de estas son historias que hemos creado esa tarea como el desarrollo front-end, las pruebas, la UAT, etcétera. Y esto es sólo un ejemplo. Los equipos pueden crear tarea a nivel más granular también si se va a separar a las personas. Y también como se puede ver, hay cuatro columnas para que los estados son de hacer, en progreso, pruebas hechas, etcétera. Y de nuevo, esta es sólo una forma de categorizar. Los equipos pueden personalizar esto en base a su discusión y acuerdos. Y esa es una de las ventajas de herramientas como esta. Por lo que por la mañana cuando sus equipos hagan su estándar antes de eso, todos deberían mover su tarea en este barco en consecuencia. Entonces al igual que el desarrollo está actualmente en curso, así que está sentado aquí, diseño de caso de prueba está en tasa de progreso está sentado aquí, etcétera, que tú no es un iniciado, así que sigue sentado en el cubo de tareas pendientes como la deuda. Y a medida que se complete el trabajo de alguien, lo trasladarán a ese cubo hecho. Entonces al igual que cuando se complete el desarrollo, lo trasladarán a Dan mentor diseño de caso de prueba está completo, lo moverán a hacer. Y una vez que todas estas tareas se mueven a abollar deuda significa que todo el trabajo está terminado y se puede cerrar una historia. Entonces esta fue la embarcación virtual. Y en realidad vamos a utilizar este mismo tipo de aburrido cuando vamos a hacer nuestro capítulo de proyecto de vida. Por lo que esto fue sólo una breve introducción de embarcaciones culturales por ahora. Y de igual manera tenemos otro tablero físico también. Por lo que este es uno de los ejemplos de embarcación física. Y entonces tenemos otro justo aquí también. Por lo que ambos son similares. Y si nos fijamos con cuidado, es muy similar a la deuda de la junta virtual también vimos. Y tiene la otra vez, las columnas para diferentes estados como hacer en progreso, prueba hecha, etcétera. Por lo que estamos creando estas columnas. Los estamos separando por amenazas para marcar el estado de cada tarea. Estamos teniendo una nota pegajosa para cada tarea lata Los moveremos a diferentes cubos a medida que se completen. Entonces todo el concepto es el mismo, ya sea el tablero virtual o el barco físico. Es solo la diferencia en su configuración y cómo reacciona el equipo ante ella, cómo lo usa su equipo. Perdón. Por lo que volviendo a la diapositiva, a algunos equipos les gusta hacer cosas en un tablero físico porque siempre es visible. Cualquiera puede pasar por aquí y ver el progreso de las cosas. Hay una sensación de logro cuando estás moviendo sus notas pegajosas, etcétera. Y algún equipo, prefirieron hacer el tablero virtual porque es más tiempo real. No se necesita ningún esfuerzo para crearlo. Guarda las notas pegajosas, papeles, etcétera. Por lo que nuevamente, dependiendo de la preferencia de los equipos, pueden elegir cualquier versión. Pero lo más importante para llevar es que la junta del equipo scrum es el reporte más común del trabajo que el equipo está haciendo en un sprint. Y es por eso que incluí en este capítulo, es uno de los grandes métodos de presentación de informes para el trabajo del equipo. Con sólo ir a la Junta Directiva, cualquiera puede ver en qué está trabajando todo el equipo, qué miembro del equipo está trabajando en qué tarea? ¿ Cuáles son los puntos totales que ha tomado nuestro equipo? ¿ Cuántos de ellos están cerrados? ¿ Cuántos de ellos están abiertos? Es decir, hay algún bloqueador, etc. Así que toda en toda la información total del Sprint está contenida en este único tablero. Por lo general los equipos hacen su stand matutino también con este barco abierto o si están haciendo una versión física, se paran cerca del tablero y hacen el stand-up. Y promueve la discusión entre el equipo sobre cada uno de los ítems. Y lo más importante, uno de los buenos aspectos es que cuando alguien ha completado su trabajo, cuando alguien mueve sus tareas a la columna hecha, crea una sensación de logro en todo el equipo. Muy bien chicos, así que eso fue por un tablero de Scrum. Echemos un vistazo a otro reporte en una próxima conferencia. Gracias. 34. Tabla de Burn: Hola a todos y bienvenidos de nuevo. Hablemos ahora del gráfico de quemado. Entonces, antes de hacer eso, consideremos un ejemplo típico. En nuestro equipo, hacemos dos semanas de un sprint y comenzamos el sprint, digamos todos los lunes. Por lo que de lunes a viernes de la semana en curso y luego de lunes a viernes de la próxima semana, estaremos trabajando en este sprint. Y luego el tercer lunes que viene, ese equipo empezaremos con el próximo sprint. Ese es el caudal de un sprint de dos semanas. Ahora digamos que en esta corriente es sprint tomamos ocho usuarios historias con un total de 45 puntos de historia. Ahora el equipo tiene que trabajar de tal manera que mantengamos un buen progreso y seguimos cerrando son historias a intervalos frecuentes. De lo contrario, ¿qué pasaría? Estaríamos sobrecargados hacia el final. Y luego podría haber historias de usuarios, las deudas no se cierran y se vuelcan. Entonces el gráfico que nos muestra esta información en particular, ese es el trabajo que queda por hacer versus el tiempo se llama como el gráfico de quemado. Y así es como se ve. Por lo que tenemos los User Story Points en el eje Y vertical, y que días o tiempo está en el eje x horizontal. Y si miras el gráfico, aquí hay dos líneas. Esta grava es la línea ideal. Eso significa, lo que significa la progresión gradual de las cosas y la finalización como si estuvieras trabajando a un ritmo ideal constante. Y la segunda línea es la línea de finalización real. Por lo tanto, no te preocupes por cómo se hace este gráfico. Si utilizas una melodía como G, derecha, se crearía automáticamente para ti, no habría necesidad de trabajo manual. Tratemos de entender lo que transmite este gráfico. Por lo que comenzamos con 25 puntos de historia. Esa es nuestra estimación total. Y toda la idea es mantener esta línea roja lo más cerca posible de la gris. Si el ReadLine real va por encima del DRE, significa que vamos más lento de lo estimado. Y si está por debajo, significa que vamos por más rápido. Entonces ambos casos no están bien. Tenemos que permanecer lo más cerca posible de la línea gris. Estas cajas, cajas grises que ves son para el fin de semana, por lo que no habría progreso aquí. Por eso esta línea gris es plana por aquí. De lo contrario, en absoluto, en otras ocasiones, va bajando poco a poco. Entonces eso significa que estamos cerrando las cosas gradualmente. Entonces toda la idea es que el trabajo real también esta línea roja debe estar lo más cerca posible de esta línea gris. Y la mejor manera de hacerlo es cerrar historias a intervalos regulares, tan simples como eso. Eso es todo lo que se necesita para obtener un gráfico de quemado ideal, estimar lo que puede tomar tanto trabajo como pueda entregar y luego cerrar las cosas en el conjunto de datos de intervalos graduales. Ahora antes de volver a la diapositiva y leer, otras cosas son observación rápida aquí. Verán que por aquí este gráfico se ha disparado. Entonces, ¿por qué ha sucedido eso? Eso sucedió porque podríamos haber tomado en un nuevo usuario es historia en medio de un sprint, cual no es algo ideal como lo discutimos, pero sucede porque pudo haber habido algún nuevo requerimiento urgente de negocios que surgió. Entonces por eso la gráfica corta en ese punto. Muy bien, volvamos a la diapositiva ahora y sigamos. Por lo que ya vimos lo que es un gráfico quemado y cuáles son su eje X y eje Y. tercer gráfico de burndown nos ayuda a rastrear progress office sprint porque podemos revisarlo diariamente y ver si estamos cerrando las historias o no y cómo van los sprint. Entonces si solo quedan dos días en el sprint y la línea real está a millas de distancia de la línea gris, entonces es un problema. A continuación, mantiene al equipo a tiempo. Por lo que con sólo mirar el gráfico, equipo puede saber si están en buen camino o no. Y tercero, la quemadura es muy sencilla de entender. Como dije, es creado automáticamente por Gita o cualquier otra herramienta que estés usando. No se necesita esfuerzo manual y puedes mirarlo todos los días y entender si el equipo está en buen camino o no. Último punto, las cartas de quemado deben ser analizadas regularmente, sobre todo por el propietario del producto y el Scrum Master para asegurarse de que los equipos estén en buen camino y los equipos estén haciendo progresos. E incluso todo el equipo puede mirarlo en el stand-up. En uno de mis proyectos, teníamos una junta físicamente de Scrum donde sí nos levantábamos todas las mañanas. Y el Maestro Scrum solía poner una huella fuera de la tabla de quemado cada mañana antes de que se levantaran para que el equipo pueda ver lo que están haciendo y puedan asegurarse de que están progresando por el buen camino. Y también recuerden que este gráfico quemado es una muy buena herramienta para la reunión retrospectiva. También, le dirá al equipo cómo progresan. Había algún bloqueo de carretera, por qué no podían cerrar las cosas a intervalos regulares, etcétera. Gráfico tan simple y utilidades múltiples. De acuerdo, sigamos adelante y hablemos de otro reporte en la próxima conferencia. Gracias. 35. Tabla de quemar: Hola a todos y bienvenidos de nuevo. Ahora que sabemos del gráfico de quemado, hablemos de algo que suene similar, pero es algo completamente diferente. El gráfico quemado. Entonces chicos, el gráfico quemado muestra la cantidad de trabajo que el equipo ya ha completado y la cantidad total de trabajo que se requiere en el proyecto. Por lo que es una medida del trabajo total necesario frente a lo que se completa. Y así es como se ve el gráfico quemado. Y aquí una vez más, tenemos el esfuerzo o los puntos de la historia en el eje Y vertical y el tiempo en el eje x horizontal. Pero en el gráfico verás ahora tres líneas. Por lo que la amarilla es la línea ideal, la roja es el esfuerzo total necesario para lograr el objetivo de desarrollo del producto, lo que significa nuestro esfuerzo total requerido. Y azul uno es el trabajo terminado, cuánto ya ha logrado el equipo. Y se puede ver que esta línea ideal amarilla va subiendo con el tiempo. Eso significa que tenemos que avanzar hacia la meta final con tiempo y de manera consistente. Por lo que cada sprint debemos llegar un poco más cerca de él. Si estamos por debajo de la línea ideal, significa que vamos con lentitud y estamos en riesgo de culminación. Entonces eso es lo que es el gráfico de quemados. Recuerda en el gráfico de quemado comprobamos que estamos quemando cosas que es, estamos cerrando es historias donde como en el gráfico de quemados, vemos que si vamos arriba, vamos subiendo hacia nuestro objetivo final. Esa es la forma de entenderlo. Volvamos a las diapositivas y revisemos los demás detalles. Entonces punto número uno, N2 ya cubrimos. Recuerda en el gráfico de quemado tenemos el trabajo sobresaliente sobre el eje y, pero aquí en el gráfico quemado hemos terminado y trabajo total. Y es por eso que algunas personas consideran más positivas las gráficas de quemar porque habla del trabajo terminado versus burndown, que habla del trabajo sobresaliente. Siguiente punto, cuáles son los beneficios de la carga de gráficos por lo que muestra el trabajo total y el trabajo terminado lado a lado. Entonces esa es una muy buena comparación. A continuación, muestra la cantidad de trabajo que queda y que estamos viendo ambas cosas lado a lado. Podemos ver el progreso de las cosas. Y último punto quemado gráfico proporciona más detalles de la finalización del proyecto. Por lo que obviamente tenemos líneas separadas de trabajo total y trabajos terminados como vimos. Y así sabremos que nuestro proyecto es cómo avanza y si está en camino de su culminación. Además, digamos que si hay una nueva adición al proyecto, puedes ver este bache aquí mismo. Por lo que esto demostrará que algo nuevo se agregó y así nuestro alcance aumentó. Esa es una muy buena ventaja de quemar gráfico para rastrear el estado general del proyecto. Muy bien chicos, así que ese fue el gráfico de quemados y otro importante es el reporte de migajas. Aprendamos un nuevo reporte en la próxima conferencia. Gracias. 36. Tabla de velocidad: Hola a todos y bienvenidos de nuevo. Hablemos de uno de los reportes más sencillos pero poderosos en Scrum dot es el gráfico de velocidad. Entonces en el último capítulo hablamos de velocidad, y significa cuánto trabajo hemos comprometido en un sprint particular y cuánto hemos comprometido realmente. Entonces esa es la velocidad. Y cuando trazamos estas cosas lado a lado, obtenemos lo que se llama el gráfico de velocidad. Entonces este es el gráfico de velocidad, y como dije antes, es un reporte muy sencillo. Todo lo que tenemos son dos gráficos de barras uno al lado del otro. Y en el eje y tenemos nuestra unidad de esfuerzo como cada historia apunta. Y en el eje x tenemos los sprints. Y recuerda, como hablamos antes, también, lo mejor es mirar los datos de las últimas tres o cinco se imprime para entender mejor las cosas. Entonces lo que estamos haciendo es por cada sprint, estamos tramando los Story Points comprometidos en gris y lo completado son storypoints lado a lado en verde. Por lo que como se puede ver para una ayuda de sprint, ese equipo quedó corto de completar todo lo que se comprometió. El gráfico de compromiso está en algún lugar alrededor de 35, mientras que el completado es alrededor de 30. Entonces eso significa que el equipo no completó todas las cosas que habían acordado. Por lo que en un sprint ocho, caímos en él en fin es imprimir nueve y es print ten nos dieron una terminación del 100%. Sprint 11, En realidad hicimos más. Entonces eso significa que el equipo se llevó algo extra en medio de un sprint y pudieron completar datos también. Por lo que este es un buen equipo de gráficos de velocidad chicos porque como se puede ver en la mayoría de los casos, lograron lo que se estimaba. Y de hecho, en uno de los casos están sobreentregando. También. Otra cosa a destacar es que aquí en un sprint 13, ese equipo se llevó un gran hit y hay una enorme brecha entre lo que los comprometidos y entregados. Y recuerda por qué eso sucedió es tema arriba para retrospectiva. Pero ya sabes, podría deberse a varias razones como varias personas tuvieron que tomar hojas repentinas o equipo se retuvo debido a algún trabajo urgente que llegó o surgió algún otro bloqueador, etcétera. Y sucedió en un sprint. Todos solo descansan. Todo es sprints son buenos. Y por eso, si recuerdas, dijimos antes también que al mirar velocidad, deberíamos mirar el promedio de al menos pasar tres sprints. Entonces mirando este gráfico, ¿cuál es la información que podemos obtener? Podemos decir que para este equipo en particular, alrededor de 45 a 55 puntos de historia es un buen número. Los datos son el equipo de datos idealmente debería tomar porque han sido capaces de completar esa cantidad trabajando todo el día sprints. Entonces ese es un buen número para ellos cuando se reunieron para Sprint Planning y cuando deciden aceptar sus historias uno por uno, deberían conformarse con algún lugar cercano a 45 a 55 puntos. Entonces eso es todo. Eso es un gráfico de velocidad, chicos y cómo usarlo. Y recuerda, como dije, es un gráfico muy sencillo pero muy efectivo. Crearlo es muy sencillo. Sólo tenemos que trazar el estimador es historia y en realidad completó la historia lado a lado. Y de hecho, si estás usando una herramienta como Gita o cualquier otra herramienta de gestión de proyectos en estos días, automáticamente crearán para ti. No tienes que hacer ningún esfuerzo. Lo único es que cuando estás viendo se asegura de que estás usando las últimas tres o cinco impresiones IS de datos para realizar el análisis. Muy bien chicos, volvamos al tobogán y sigamos. Entonces hablemos del último punto porque ya hemos visto el resto una vez. Por lo que el gráfico de velocidad ayuda a saber cuál es la capacidad del equipo, cuánto pueden entregar idealmente. Y en base a eso, podemos planear nuestros sprints. Ya lo vimos en el último capítulo. En realidad no sólo un sprint , nos da una idea del proyecto en general también. Entonces por ejemplo, el equipo hace aproximadamente 50 en un sprint y tenemos 150 puntos más que hacer antes de poder liberar el producto. Por lo que obviamente podemos ver que se necesitarán tres sprints para terminar todo el trabajo. Ese es el propósito de usar el gráfico de velocidad, ese es el propósito de saber cuánto trabajo puede hacer el equipo. Entonces otra vez, informe muy sencillo pero eficaz. Está bien, así que ahora hemos cubierto lo más común son los informes de Chrome, pero hay un análisis más del que quería hablar. Entonces veamos eso en la próxima conferencia. Gracias. 37. Mantener un ojo en el Backlog: Hola a todos y bienvenidos de nuevo. Entonces chicos, hasta ahora vimos varias opciones que nos ayudan a analizar cómo van los sprints, cuál es el progreso del equipo, etc. Echamos un vistazo al gráfico de burndown, el gráfico de quemado, el gráfico de velocidad, etc. Y estos son algunos de los informes más utilizados en Scrum. Pero al mismo tiempo, el rezago de productos que hemos seguido hablando desde hace tanto tiempo, eso también es algo de lo que quería hablar y datas porque solo mirar este rezago de producto puede darnos mucha visión de cómo son las cosas yendo. Si recuerdas de nuestros últimos capítulos, el Retraso de Productos es como nuestra hoja de ruta de productos. Entonces es una lista de deseos de lo que todas las cosas queremos hacer. Tenemos un nuevo requisito, lo ponemos en el Retraso. Si obtenemos un nuevo defecto que se puede hacer más adelante, lo ponemos en el rezago. Entonces a intervalos regulares deberíamos analizar si nuestro atraso no se está convirtiendo en algo demasiado grande e inmanejable porque entonces nunca seríamos capaces de terminar las cosas, correcto. Estaríamos haciendo cinco cosas en este sprint para un lanzamiento en particular, pero habría como diez más agregados al atraso y será un proceso sin fin. Entonces esa es la idea general de esta diapositiva. Quería hacerle saber este concepto a partir de mi experiencia personal que reporta como burndown, quemar velocidad. Son muy buenas métricas. Pero al mismo tiempo, simplemente mirar el atraso también puede revelar cómo están pasando las cosas en el equipo. Entonces veamos qué dice la diapositiva. En primer lugar el atraso es demasiado grande e inmanejable? Por lo que ya hablamos de ello. Nunca deberíamos llegar al punto donde tenemos que decir eso, vale, hicimos tres puntos de trabajo para liberar el producto. Perdón, hicimos tres sprints de trabajo para liberar el producto. Pero ahora necesitamos huellas Maurice porque ha habido una tonelada de cosas agregadas al rezago. No queremos hacer eso. Nuestro atraso nunca debería llegar a ser demasiado grande. Nuestro atraso nunca debería volverse inmanejable. siguiente punto es el atraso que se está revisando y priorizando con frecuencia. Entonces esta aquí es la respuesta a todos nuestros problemas. El propietario del producto debe revisar el atraso con frecuencia. Debería priorizarlo y tú debes limpiarlo con frecuencia. Entonces dat es la solución. tercer punto es que todos simplemente tiran cosas al atraso. Entonces en algunos de los equipos con los que he hablado, Lo que pasa es que tomó una historia de usuario y luego cualquier defecto o cualquier requisito que surja, simplemente lo mueven al rezago. Por lo que aconsejaré en contra de esta práctica. Recuerde que el resultado de cada sprint es un producto potencialmente enviable. Por lo que abordar el defecto también es importante si se trata un defecto de caso de borde y no esperamos que suceda con frecuencia, entonces probablemente podamos posponerlo para más adelante. Pero simplemente poner todo a ciegas en el rezago no es una buena idea de hacer las cosas. Siguiente punto, ser transparentes sobre la deuda técnica. Por lo que la deuda técnica es un agente conceptor muy interesante. Se puede leer al respecto. Simplemente significa el costo de futuras reobras que vendrán porque el equipo eligió solución fácil y rápida ahora en lugar de la mejor y tiempo tomando una. Entonces un gran atraso es una señal de alta deuda técnica porque simplemente estamos posponiendo las cosas. Y recuerda, en algún momento va a comer en nuestro esfuerzo y costo porque tendremos que abordarlos. Entonces esa es la deuda técnica. Y la deuda es algo que hay que tener en cuenta, sobre todo si estás en un papel directivo. En quinto lugar, RV cerrando una historia de usuario y agregando dos más al atraso. Entonces si no estamos pensando claramente en los requisitos lo que sucederá es que haremos una historia de usuario, pero más tarde descubriremos dos requisitos más que nos hemos perdido. Y tendremos que sumar esos requisitos al atraso para hacer más adelante. Entonces piense, piense claramente en los requisitos. Piénsalo en equipo, discuta al respecto, trató de captar tanto requisito como sea posible en un solo disparo. Esto es algo que podría no ser totalmente evitable, pero debemos hacer lo mejor que podamos. Y por último, estamos agregando muchos bugs por trabajo hecho al atraso. Entonces si cada Sprint, nuestro recuento de errores está aumentando, entonces significa que en algún lugar y no estamos haciendo las cosas con calidad. Y desafortunadamente esta es una ocurrencia muy común en es miga porque las cosas se mueven tan rápido. Por lo tanto, trate de entender claramente los requisitos. Pregunta cualquier consulta que tengas. La idea no es crear algo con como diez defectos que llevará mucho tiempo para que el equipo lo arregle. Esto es algo que debe observarse, sobre todo por los directivos y directivos técnicos. Muy bien chicos, así que esto fueron algunas señales de alarma para mirar en el rezago, como mencioné, tenemos reportes como Burndown Velocity, etcétera. Pero si vigila estas cosas simples en el rezago, te dará mucha información sobre cómo van las cosas. Está bien, entonces con esto, llegamos al final del capítulo. Y de hecho, ahora hemos cubierto todos los temas relacionados con Agile y Scrum que habíamos planeado en el contenido del curso. Ahora sabemos del VIH, Scrum, los diferentes roles, ceremonias, artefactos, estimaciones, métricas, etcétera, todo lo que se necesita para ser un experto en AGI y Scrum. Por lo que las felicitaciones corporativas chicos, ahora eres un campeón en edad Isla es Scrum. Estás totalmente familiarizado con todas las cosas de estos temas. Puedes empezar a ponerlo en uso. Puedes usarlo para impulsar mejoras en tus organizaciones. Puedes mencionarlo en tu currículum o cualquier cosa que quieras. Entonces chicos, este curso no termina aquí, aunque hemos cubierto todos los temas ahora que hemos aprendido cada detalle en teoría, pongámoslo a usar en un proyecto práctico y veamos cómo funcionan las cosas en el mundo real. Porque recuerda Andi, cuando haremos las cosas, aprenderemos sobre la implementación en el mundo real. Entonces los veré en el siguiente capítulo y empezaremos a trabajar en un proyecto de extremo a extremo para discutir todo a detalle. Gracias. 38. Proyecto práctico: aplicación de ágil, la parte 1: Hola a todos y bienvenidos. Entonces chicos, este es el proyecto de aprendizaje práctico de este curso. Y en este capítulo vamos a aplicar todo el aprendizaje que hemos hecho hasta ahora en el curso para ver cómo funcionan las cosas en el mundo real, te sugiero que pongas mucha atención a este capítulo porque solo si te enfocas en los aspectos prácticos de cosa, conocerás todos los detalles. Entonces, empecemos la acción. Por lo que en este capítulo se va a dividir en cuatro partes donde vamos a empezar con cómo obtenemos los requisitos y cómo sí los escribimos como historias de uso. Entonces vamos a ver cómo se crea el rezago del producto. ¿ Cómo hacemos la planeación del sprint y cómo finalizamos el rezago del sprint? A continuación, vamos a ver cómo sucede el sprint, cómo sucede el trabajo cuando se está ejecutando el sprint. Y por último, vamos a ver cómo se libera la obra y avanzamos. Y como se puede ver, no habría diapositivas en este capítulo, todos los aprendizajes son prácticos. Vamos a utilizar esta herramienta Xcel Energy EDA para entender las cosas. Ahora en este proyecto vamos a simular la creación de un sitio web de comercio electrónico. Y me gusta usar el e-commerce para explicaciones porque es un dominio muy dinámico. Y todos nos podríamos relacionar con ello. Todos hemos usado Amazon, eBay, o cualquier otro sitio web de comercio electrónico. Por lo que es un buen ejemplo a considerar. Y vamos a crear un sitio web de comercio electrónico desde cero, y se va a llamar de niño Mega Mart.com, ese proyecto de verano configurando este sitio web de comercio electrónico. Y veremos cómo hacer eso. Entonces, empecemos. Entonces empecemos con la primera parte, consiguiendo los requisitos y convirtiéndolos a historias de usuarios. Entonces, ¿cómo obtenemos los requisitos? Ahora los requisitos pueden provenir de diferentes fuentes. Todas las empresas en la actualidad cuentan con un grupo dedicado de gestión de productos que se encargan de generar o recolectar estos requisitos. Y para nuestros propósitos los llamamos como interesados. Por lo que ya hemos visto lo que son los titulares de participaciones. Tienen el requisito de negocio a cumplir, y así cada equipo obtendrá los requisitos de ellos. Ahora, recuerda que estos titulares de participaciones primero generan o recolectan requisitos de alto nivel, lo cual es como un documento de visión de producto. Por lo que podrían reunirse con el cliente final o usuario para entender estos requisitos o para nuestro propósito de crear un sitio web de comercio electrónico. Se referirán a las necesidades del mercado o a los competidores para entender qué características deben estar ahí. Y en base a esto, crearán un requisito o visión de alto nivel. Y a esto le seguirá una sesión de lluvia de ideas requeridas donde, ya sabes, los equipos de gestión de productos se reúnen y deciden qué todas las características o Epic necesitaban hacerse desde los requisitos de alto nivel. Y por último, debe finalizarse esto. Tenemos las épicas, que se desglosarán en historias de usuarios. Y escribiremos los criterios de aceptación para estas Historias de Usuario que se convertirán en nuestros requisitos. Entonces ese es todo el flujo general. Requisitos de alto nivel, luego Epics, luego historias de usuarios y criterios de aceptación en ellos. Entonces con el propósito de crear un sitio web de comercio electrónico, imaginemos a Amazon o eBay en nuestra mente. Y pensemos en lo que todas las características o epics que no necesitaban. Entonces, por ejemplo, necesitan lo siguiente. Necesitamos una cuenta épica con historias de usuario para el registro, inicio , contraseña olvidada, página de mi cuenta , registro de correo electrónico, cambio de contraseña, etc. Y luego necesitamos un pixel buscador. En el píxel tal tendremos cosas como crear una página de lista de cuadro de búsqueda de todos los productos, refinamientos de productos, clasificación de páginas de categorías, páginas de productos, etc. Entonces podríamos tener una página de pago. Por lo que es un área muy importante y crítica de cualquier sitio web de ecommerce. Y tendremos historias de usuario para la página del carrito de compras, la página de dirección de envío de caja, pago con tarjeta de crédito, PayPal, confirmación de pedido de Apple Pay, correo electrónico, todas estas cosas. Y por último vamos a tener la épica para la arquitectura de procesamiento de pedidos. Entonces este va a ser el material técnico que necesitamos para crear una base de datos de usuarios, una base de datos de productos, base de datos ordenada, etc. Y he incluido aquí este ejemplo para que sepas que por hacer los requerimientos del negocio, necesitamos ese material técnico también. Por lo que podría haber requerimientos técnicos también puros requisitos técnicos como crear todas estas bases de datos. Muy bien, entonces ahora tenemos todas estas épicas y sabemos lo que todas las historias de los usuarios necesitamos crear para ellos. Empecemos por escribir estas historias de usuarios y sus criterios de aceptación. Y para los chicos de papá, estaremos usando esta herramienta. Entonces esta es la herramienta JIRA. Podría haber oído hablar de ello. Es una herramienta muy bonita y poderosa y es utilizada por diferentes empresas. Deuda sigue un IG y algunos de los, la mayoría de los grandes nombres en el mercado para la gestión de productos y la implementación de HL. Y puedes probarlo tú mismo. Basta con ir a su página web que está en lesbian.com y click en este botón intentar ahora por aquí para crear una cuenta gratuita no es necesaria información de pago. No necesitas dar ninguna tarjeta de crédito, es totalmente gratis. que pueda crear una cuenta usted mismo y pueda explorar todas estas características de forma gratuita. Entonces, cuando creas una cuenta en Gita, lo primero que necesitarías hacer es crear un proyecto. Y he creado el mío con el nombre de la deuda del sitio web de comercio electrónico. Estamos creando un gel Mega Mart. También puedes crear tu propio proyecto. Basta con dar click en este Botón Crear Proyecto por aquí. Y abrirá algo como esto. Por lo que hay que hacer clic en el botón selecto clásico por aquí. Y una vez que llegues a esta página, solo dale un nombre para el proyecto y asegúrate de mantener la plantilla como es miga porque vamos a estar desarrollando este proyecto usando la metodología scrum. Y papá se sienta, una vez que hayas llenado todos estos detalles, volverás a aterrizar aquí con tu proyecto enumerado por aquí. De acuerdo, entonces ahora que tenemos un proyecto, sigamos adelante y creemos nuestras primeras épicas. Así que vamos a dar click en este botón Crear por aquí, y vamos a crear nuestra épica. Entonces si vuelvo a la hoja de Excel, teníamos cuatro epics, cuenta, búsqueda, checkout y arquitectura. Entonces vamos a crear estas épicas en el g r2. Por lo que seleccionaré la opción de epics por aquí. Y usaré para crear la primera épica. Nombre épico sería la cuenta. Y vamos a dar el resumen ya que esta es la épica para las obras de la cuenta. Ya hice esto, así que está mostrando auto poblado de sugerencias, pero son, ya sabes, puedes dar cualquier cosa en alguien y puedes mantener la épica nombrada como algo específico de la deuda señala qué área es o qué equipo es, ese tipo de cosas. Entonces, vamos a dar click. Entonces vamos a crear esta primera Epic. Y lo que vamos a hacer es dar click en esto, Crear otro botón por aquí. Porque tenemos que crear tres épicas más. Por lo que voy a dar clic en este Crear. Y como dice, se crea nuestra primera Epic. De acuerdo, vamos a crear el siguiente para el pago. O en realidad se buscó. Entonces vamos a crear para la búsqueda, y esta es la épica para las obras de búsqueda. Entonces vamos a dar click en Crear. A continuación podemos agregar el 14x Checkout. Por lo que esta es la épica para las obras de checkout. Y por último, podemos hacer click Crear el último para la arquitectura. Y papá set, hemos creado todas nuestras cuatro épicas. Entonces si recuerdas de nuestros aprendizajes, y épica es un gran requisito del que despejamos las historias de usuarios más pequeñas y pequeñas. Por lo que decidimos adoptar para epics para nuestra cuenta de proyecto checkout, search y architecture. Por lo que hemos creado esas épicas. Ahora el siguiente paso que tenemos que hacer es crear historias de usuario dentro de ellas. Entonces déjame dar click en esta opción aquí mismo, y déjame dar click en esta historia. Entonces ahora vamos a crear nuestra historia más rápida. Y vamos a crear esta historia para el autoregistro. Entonces le voy a nombrar algo así como flujo de autoregistro de usuario. ¿Está bien? Y una vez más, no te preocupes por todas estas cosas auto pobladas que está pasando porque lo he hecho una vez para practicar en este navegador. Pero en tu caso, puedes escribirlo. Puedes darle cualquier nombre que quieras. Una vez más, queremos que los nombres sean específicos para que señale lo que sabe la historia. Cualquiera puede mirar el resumen y averiguar cuál es esta historia. Por lo que vamos a ir con este resumen. Y entonces el siguiente paso que vamos a hacer muy importante es enumerar aquí los criterios de aceptación. Entonces si recuerdas chicos, cuando estábamos haciendo el capítulo sobre historias de usuarios y criterios de aceptación, mencionamos que cada vez que estamos escribiendo criterios de aceptación, siempre comenzamos con las palabras como usuario. Y en realidad el formato general es esto como persona. Por lo que como usuario o como especialista en marketing o como equipo legal, quien sea el cliente final para el que estamos diseñando esta cadena. Entonces como persona, quiero un gol. Entonces, cuál es el objetivo final de crear este historial de usuarios como en este caso, el resultado final es que el usuario debería poder registrarse. Ese es nuestro objetivo. Y luego finalmente, para que las partes beneficien de lo que es el beneficio de hacer esta cadena. El beneficio es que una vez que el usuario pueda registrarse, podrá hacer las compras. Entonces este es el formato general en el que morimos, los criterios de aceptación. Y voy a escribirlo de esta manera. Como usuario, quiero registrarme en la página web para que pueda comenzar a comprar. Esta es nuestra esta es nuestra declaración general, ¿verdad? Y se ha escrito en este formato. El personaje es el usuario. El objetivo es registrarse en la página web y el beneficio es que pueda. Él o ella puede empezar a comprar. Entonces esta es nuestra primera línea, el resumen. Permítanme que me quite esta parte. Y luego lo que tenemos que hacer, necesitamos escribir esos criterios de aceptación detallados. Entonces el criterio de aceptación, como vimos antes, es esa lista detallada de los requisitos. Y recuerda cada vez que estamos escribiendo los criterios de aceptación, tenemos que ser lo más detallados posible. No tenemos que dejar nada a la suposición. Tenemos que marcar todo lo más claramente posible. Tenemos que cubrir todos y cada uno de los detalles tanto como sea posible, ¿verdad? No tenemos que entrar mucho en la parte de cómo, cómo se va a implementar, pero ciertamente necesitamos poner todo lo que se requiere, la parte y. Está bien, así que vamos a dar click en este. Nosotros lo vamos a escribir de una manera bonita con balas. Entonces voy a decir que un usuario aterriza en el sitio web y hace clic en el botón de registro. Siguiente punto, registro. Y no te preocupes por el contenido exacto aquí. Es decir, esta es solo una forma de anotar las cosas en base la aplicación en la que estás trabajando o que tu empresa diseñe los criterios de aceptación ha podido variar, pero la idea general sigue siendo la misma. Queremos proporcionar todos y cada uno de los detalles tanto como sea posible. Y queremos asegurarnos de que todo esté plasmado aquí para que la gente esté, no deje nada a su suposición porque ya sabes, lo que pasaría es si mañana uno de los desarrolladores consigue esta historia y empieza a trabajar en él, y si hay algún punto falta, entonces podría querer llenar los vacíos con su propia comprensión de las cosas. Y entonces podría terminar diseñando algo que el dueño del producto no quiere o la empresa no quiere. Por lo que queremos evitar situaciones como esa. Y por eso vamos a brindarle todo aquí el mayor detalle posible. Ahora, una cosa más eso, y estoy diciendo esto mientras estoy escribiendo. Entonces una de las cosas sobre las que particularmente hago hincapié a la hora de crear historias de usuario es tener una maqueta. Entonces como si te imaginas este caso en particular, estamos tratando de crear una página de registro. Ahora, podemos escribir toda la información tanto como sea posible. Pero si ponemos una imagen aquí, dire muestra la página de registro con todos estos campos, entonces, ya sabes, ayudaría a despejar las cosas más fácilmente. Recuerda, una imagen vale 1000 palabras. Y si estamos brindando una imagen aquí, entonces la gente podría relacionarse más estrechamente con las cosas y ellos entenderían las cosas con detalles completos. Por lo que hemos escrito los criterios de aceptación y dice que el usuario aterriza en la página web y hace clic en el botón de registro. La página de registro debe contener estos campos. Entonces CVR señalando claramente cuáles deberían estar todos los campos, ¿verdad? Si la dirección de correo electrónico ya está en uso, estamos diciendo claramente ¿cuál es el mensaje de error que queremos dar? No estamos simplemente saliendo terminando escribiendo que muestran un mensaje de error. No, incluso estamos diciendo cuál debe ser el mensaje de error porque queremos que quede claro. Queremos que sea la forma en que queremos exactamente lo correcto. Y entonces hemos dado algunas reglas para contraseña como deberían estar entre 815 y contener número de letra es corrector espacial como este. Y una vez que el usuario proporcione todos los detalles y clics en el botón Enviar, deben ser llevados a la página de mi cuenta. Entonces esta es la forma de escribir los criterios de aceptación. Tenemos que ser lo más detallados posible. Y esta es la opción de navegación desde la que podemos adjuntar una maqueta. Demostrará ese diseño que se requiere y será de gran ayuda. Y por último, qué vamos a hacer si nos desplazamos hacia abajo, tenemos que adjuntar esta historia de usuario a épica. Recordar epopeya es nuestro gran requisito y hacemos varias historias de usuarios para completar esa épica. Entonces para esta historia de usuario, tenemos que seleccionar una Epic y esta historia de usuario pertenece a las épicas de la cuenta. Por lo que vamos a crear la cuenta épica por aquí. Y voy a dar click en este botón Crear. Entonces eso es todo, chicos. Enhorabuena, hemos creado nuestro primer usuario es historia. Y si vamos a este usuario es historia, verás que enumera todo, claras, claras balas y sangría. Entonces todo el que entre aquí, verá las cosas con claridad. Entonces así es como funciona. Ese es el flujo completo. Y de hecho, hemos visto ese viaje desde el principio mismo. Hemos visto cómo se crean los requisitos, cómo se ordenan en épicas, y luego cómo estas épicas se convierten en historias de usuarios. Entonces si vuelvo a nuestro Excel, hemos completado el proceso de una sola vez de parte, que es conseguir los requisitos y convertirlo a historias de usuario. Ahora mismo lo que voy a hacer es crear historias de usuario para todos estos requisitos que vimos. Voy a entrar en el Gita para que podamos obtener lo que llamamos como un rezago de producto, una lista completa de nuestros requisitos. Entonces déjame crear estas historias y luego los veré en la próxima conferencia para llevar adelante nuestro paso de extremo a extremo. Gracias chicos. 39. Proyecto práctico: aplicación de ágil. Parte 2: Hola a todos y bienvenidos de nuevo. Entonces ahora vamos a ver esta parte, la segunda parte, donde estaremos creando el atraso. No estaríamos simulando las acciones de aseo atrasado y una planeación de sprint. Y estaríamos terminando con nuestro atraso de sprint. Ese es el trabajo que tenemos que hacer en cada sprint. Entonces volvamos al proyecto. Entonces si hago clic en este nombre del proyecto y entro dentro de él. A tu izquierda verás estas primeras cuatro opciones, que es de lo que hemos estado hablando mucho en nuestro aprendizaje hasta ahora. Entonces tenemos el tablero de Scrum, que en este punto estaría vacío porque no hemos configurado completamente las cosas y empezamos nuestro sprint. Entonces volveremos a esto más tarde. Entonces tenemos el atraso. Por lo que este chicos es nuestro rezago de productos. Ya hemos hablado tanto de ello. Hemos seguido diciendo que el rezago de productos de datos es una lista completa de nuestros requisitos. Entonces esto es aquí lo es. Y he creado la historia de usuario para todos los requisitos que teníamos en nuestro Excel. Y para que puedas ver todas estas historias están sentadas en el Retraso. Esta es la lista completa de requisitos que teníamos que hacer. Y se puede ver que todos estos requisitos están empatados a la épica también. Entonces como en tu empresa, si Cuenta es un equipo, entonces sabemos que ok, son la contabilidad tiene que hacerse cargo de todos estos cambios. Si las búsquedas y otro equipo entonces sólo por mirar aquí, podemos decir que está bien, equipo de búsqueda tiene que cuidar todas estas cosas o estas pertenecen a la funcionalidad de búsqueda. Entonces ese es el beneficio de tener epics que sabemos de qué área viene y cuál i funcionalidad específica, esas cosas atadas a la derecha? Ahora permítanme cerrar esta sección para que tengamos más espacio. Y así chicos, tenemos todas estas 23 historias de uso que están sentadas en su atraso. Ahora estamos bien para empezar con el siguiente paso. Entonces aquí es donde vamos a hacer nuestra primera HI es ceremonia, el grooming atrasado. Entonces abrimos esta primera historia de usuario que creará que escribimos con los criterios de aceptación. Por lo que el donante de producto o el Scrum Master abrirá esta historia de usuario y el propietario del producto leerá los criterios de descripción y aceptación, qué todo lo que quiere que se haga en la historia. Demostrará si hay un maqueta, que una vez más, recomiendo encarecidamente para cambios de este tipo porque aclarará las cosas. El dueño del producto explicará todos estos detalles y les mostrará maqueta. Ahora ese equipo tratará de entender estos requisitos y si tienen alguna pregunta, lo harán como, ¿cuál es la longitud de este campo de nombre por aquí? ¿ Cuál es la longitud de este campo Apellido, etcétera? Porque recuerden, queremos mencionar claramente cada detalle. Por lo que el dueño del producto responderá toda deuda y también agregará esos detalles a la historia. Entonces, sumémoslo por aquí. Entonces digamos que el nombre debe ser de 30 caracteres. El apellido debe ser de 30 caracteres enlight DAT, ¿verdad? Porque recuerden la idea es que queremos capturar todas estas cosas lo más detalladas posible. No queremos que un desarrollador cree el nombre con tan solo diez campos porque ese fue el proceso de pensamiento. No, queremos que sea exactamente como necesitamos. Entonces lo mencionaremos todo aquí y es bueno documentar todo porque recuerda, nadie recordará todo esto más adelante. Tan mejor documentarlo ahora para que sirva de referencia para después también. Entonces esta fue la pregunta respuesta abajo seguirá y la gente hará pregunta, el equipo de desarrollo hará pregunta. El dueño del producto le responderá todas esas cosas. Y una vez hecho eso, una vez que se haya respondido cada pregunta, una vez que se despejen todos los puntos, llegamos a la parte muy importante de la estimación. De acuerdo, así que digamos que ese equipo está sentado así y el dueño del producto aquí mismo abre la historia en esta pantalla, lee los criterios de aceptación, responde cualquier pregunta que tenga ese equipo. Todo esto sucede ahora, los datos del equipo están sentados aquí, el equipo de desarrollo, excepto el dueño del producto y el Scrum Master. Todo este equipo de desarrollo tendrá tarjetas como esta que vimos. Por lo que se trata de tarjetas sencillas con el número 13581321, la serie Fibonacci. Entonces estas no son más que todas las opciones de punto de la historia. Y entregamos a cada uno de los integrantes de este equipo de desarrollo un conjunto de estas tarjetas para que puedan apuntar una historia. Y lo que sucederá es al conteo de 123, todos levantarán una tarjeta con su punto de estimación. Entonces digamos que para esto es historia, todos levantan una fib e ignoran mis malas guías de habilidades de dibujo. No soy muy bueno en Photoshop. Por lo que todos en el equipo levantan la carta con cinco. Todo el mundo dice eso, vale, esta es nuestra historia de usuario. Los puntos de la historia son cinco, todos están de acuerdo en deuda. Y así estamos bien para contar y procederemos con el siguiente. Entonces este es el flujo de camino feliz donde todos estuvieron de acuerdo en un punto común. Ahora digamos que hay un conflicto. Todo el mundo aquí señaló de cinco, pero este tipo de aquí, lo señaló como un ocho. Entonces, ¿ahora qué pasa? Recuerda, no podemos decir que ya que la mayoría de los chicos apuntan a las cinco, Vamos con cinco. No, tenemos que conseguir un consenso. El ejercicio de póquer de planeación está impulsado por consenso. Todos tienen que ser escuchados, todos tienen voz. Por lo que el maestro de scrum o dueño del producto le preguntará a este tipo deuda por qué piensa que es un ocho. Y entonces explicará su proceso de pensamiento y podría ser como algo que otros no pensaron. Y así el equipo recompensará con base en esta nueva información y tal vez ahora todos lo voten como ayuda porque no pudieron pensar en algo antes que el cielo señaló. Y en ese caso también habría un consenso o el dueño del producto y el equipo despejará a estos chicos dudas que habían señalado en 08. Y en base a esa nueva información, estará bien en aceptarla como un cinco. Entonces todo el mundo lo está señalando como un cinco. Tenemos un consenso. Y así en este caso, el punto de la historia se finalizará como cinco. Para que podamos volver a la historia y podemos agregar un punto de historia como cinco. Por lo que esta es historia se estima como un cinco y así es como chicos va a suceder la estimación. Y lo ideal sería que lo hiciéramos durante el aseo atrasado. Algunos equipos lo hacen durante la planeación del sprint, pero eso no es ideal. El aseo atrasado es el mejor, lo siento, dinero para esto. Ahora, déjame volver al rezago y ves que si lo refresco, empezará a mostrar esos cinco puntos aquí. Entonces esos puntos son app sin embargo ahora sabemos cuáles son los puntos de historia para la historia más rápida. Ahora déjame pausar este video y actualizar los puntos de la historia para algunas historias más también. Vale chicos, así que he fechado el punto de la historia para las próximas 60 historias, y esto es colectivamente 42 puntos. Y supongamos que los datos son la velocidad de nuestro equipo. Hemos analizado los datos de los últimos tres giros y hemos encontrado que ocurre en algún lugar alrededor de 40 a 45 puntos es la estimación ideal para este equipo. Entonces vamos a parar aquí. Ya hemos hecho suficiente aseo para estar preparados para el próximo sprint. Ahora si el equipo quiere y si tienen tiempo, pueden preparar la próxima o dos historias para el futuro. De lo contrario, lo estamos. Bueno para empezar con el siguiente sprint. Tenemos suficiente material para empezar con el siguiente sprint cuando llegue el momento. Entonces ahora que tenemos un rezago priorizado y estimado, avancemos rápidamente a la ceremonia de planeación del sprint. Ahora llegará el día en que tendremos que empezar con el próximo periódico. Por lo que haremos click en este botón Crear Sprint. Y este es uno muy sprint. Y entonces lo que vamos a hacer es tirar puntiagudo son historias dentro de él por lo que sólo tenemos que arrastrarlo y soltarlo. Entonces ustedes chicos recuerdan hasta ahora que han visto en nuestro viaje cuánto JIRA nos está ayudando a hacer todas estas tareas. Y esa es la razón por la que JNI es una de las herramientas más populares en las industrias hoy en día y es utilizada por todas las empresas que quieren, ya sabes, datos usando un GI elites, una de las herramientas más útiles para la gestión de productos, Desarrollo de gestión HI EL, todas esas cosas. Y es muy popular en la industria hoy en día. Entonces arrastraremos estas primeras siete historias al sprint porque este es el trabajo que vamos a llevar al sprint. Entonces solo aguanta conmigo mientras hago eso. De acuerdo, así se han movido todas estas 70 historias y, ya sabes, dentro de las siete también, si queremos, podemos cambiar su orden dependiendo de la prioridad. Por lo que este rezago de producto es una lista priorizada de requisitos. Y dentro del Sprint también, debemos mantener las historias en la lista de la prioridad porque el equipo comenzará a trabajar desde la historia más rápida. Y ese debería ser nuestro orden prioritario. Si no tienen tiempo suficiente, el día sordo podría no ser capaz de completar este. Entonces sigamos pensando en orden prioritario aquí. Por lo que hemos metido un 70 historias en un sprint. Ahora ese equipo se meterá en una planeación de sprint, volverán a repasar las historias uno por uno. Rápidamente lo recapitularán y luego asignarán tareas. Entonces hagámoslo. Esta es nuestra primera historia que habíamos creado donde habíamos escrito los criterios de aceptación. Y también este está en la cima de nuestro rezago de sprint. Entonces vamos a crear la subtarea dentro de ella. Entonces voy a crear múltiples sub-tareas como déjame crear una para el desarrollo de la interfaz de usuario, ¿verdad? Y luego otro para el desarrollo de Java, diseño de casos de prueba, ejecución de casos de prueba, y finalmente UAT y etc. Así que esto es solo un ejemplo. Lo estoy creando en base a mis lógicas. Se puede crear tarea según las normas en su organización. Pero recuerda, de nuevo, la idea es mantenerlos detallados. Como si una persona va a estar haciendo desarrollo de UI y otra persona va a estar haciendo desarrollo Java, entonces no queremos crear una tarea para el desarrollo. Nosotros queremos separarlo para que todos sepan con quién se le encomienda, qué trabajo y quién está haciendo qué. Podemos hacer un seguimiento de su progreso, etc. Así que esta es la forma en que crearemos la subtarea. Y si entro dentro de esta tarea de Foster up, asignaremos al desarrollador. Quien sea miembro del equipo de desarrollo está trabajando en esto. Y también le sumaremos la estimación del promedio a este tipo. Entonces recuerda, Sprint Planning, aparte de tirar de las historias también implica dos tareas más. En primer lugar es la tarea, así que tenemos que asignar la tarea a quien lo esté haciendo. Y el segundo es que tenemos que estimar sus horas para ello. Por lo que eso nos ayudará a determinar la capacidad general. Entonces digamos para esta tarea, este tipo está tomando cinco horas, ¿verdad? Entonces tiraremos, pondremos datos aquí. Y esa es su estimación, la estimación de tiempo para completar esta tarea. Y eso es todo chicos, esa tarea y nuestras asignaciones hechas. Ahora una vez más, déjame pausar el video y hacer lo mismo por todas las historias. De acuerdo, entonces ahora he completado la tarea para todas estas historias y todos estamos listos para comenzar nuestro sprint con estas 70 historias. Recuerda cuando estamos tomando estas historias, mantuvimos un ojo en sus puntos y nuestra velocidad. Entonces nuestra velocidad para los últimos tres sprints fue, digamos un promedio de 45. Por lo que decidimos mantener nuestros puntos de historia todavía 42. Entonces tenemos que, tenemos que estar conscientes de nuestra velocidad y no superarla, no superar lo que hemos podido hacer en los últimos tres sprints. Y al mismo tiempo, vimos que cuando creamos tareas, agregamos horas dentro de ellas. Por lo que en base a eso, el nuestro, podríamos compararlo con la capacidad de ese equipo. Y de nuevo, asegúrate de que no estamos más de comprometernos. Por lo que estos son dos aspectos que tenemos que considerar durante una planeación de sprint como vimos en teoría, velocidad y capacidad. Y nos ayudaría a evitar sobre compromiso que así se aseguraría de que no estamos tomando más de las 70 historias que idealmente seríamos capaces de completar. Ok, entonces estamos todos terminados. terminamos con el jalón en la historia es tarea, poner en horas, etcétera. Así que vamos a dar click en el botón de inicio es Sprint y vamos a empezar nuestro Sprint más rápido. Y vamos a quedarnos con estos chicos de sprint de dos semanas. Hay una opción para seleccionar tantas semanas como quieras o hay una opción Personalizada, pero nos vamos a quedar con dos semanas. Y empecemos desde él hoy y luego déjame dar click en inicio. Y como puedes ver, nuestro sprint se crea con éxito. Gita lo creó todo y lo puso en nuestro, en nuestro tablero Scrum. Entonces este es chicos nuestro barco Scrum. Y como puedes ver enumera todas las historias que habíamos tomado en índices imprimir todas las 70 historias junto con toda su tarea que se asigna a quien sea miembro del equipo lo estaría haciendo. Entonces este es cada bote de sprint, este es nuestro atraso de sprint, el trabajo que estaremos haciendo en este sprint. Y en base a esto, sabemos que en qué estaríamos trabajando para las próximas dos semanas. Muy bien chicos. Entonces si vuelvo a nuestro Excel, hemos completado esta parte. Creamos con éxito un atraso. Asimilamos con éxito la ceremonia de aseo atrasado y una planeación de sprint. Vimos cómo estimamos las cosas, cómo sacamos tarjetas. Creamos tareas para diferentes historias. Ponemos el nuestro en ellos, creamos nuestro propio rezago de sprint, y finalmente iniciamos el sprint. Por lo que ahora estamos en un sprint. Pasemos al siguiente capítulo y simulemos ese tanque de activistas Imprimir Periodo. Ustedes chicos. 40. Proyecto práctico: aplicación de ágil. parte 3: Hola a todos y bienvenidos de nuevo. Entonces este es nuestro sprint chicos atrasados que habíamos creado en nuestro último capítulo. Entonces este es nuestro trabajo para las próximas dos semanas y todos se movieron una vez que arranquen el sprint, todos comenzarán a trabajar en la tarea que se les asigne. Y también ahora que estamos en el sprint, recuerda que tenemos que hacer un stand diario cada mañana. Por lo que cada mañana el equipo se reunirá para un stand como este. Ahora recuerden que están haciendo este stand-up con este bote físico. Contamos con un modo virtual. Entonces si queremos, podemos hacerlo de la misma manera usando una pantalla con el tablero virtual abiertamente, como lo están haciendo estos chicos con un tablero físico. Pero la idea es la misma. Todo el mundo debe actualizar su estado de tareas antes de ponerse de pie. Así que al igual que el desarrollo de la interfaz de usuario para la primera historia como empezó. Entonces, pasémoslo en progreso. Esa creación de caso de prueba para la primera historia acaba de comenzar. Entonces, pasémoslo en progreso. Por lo que este es el equipo dental a granel que idealmente debería hacer antes de ponerse de pie y ponerse de pie, siempre se pararán en un círculo como este junto al tablero físico o al modo virtual, lo que sea. Y van a contestar su estatus en tres preguntas. En primer lugar, ¿qué hice ayer? ¿ Qué voy a hacer hoy? Y cualquier bloqueador atraiga a los chicos de formato estándar dorado, estas tres preguntas, va a ser una reunión rápida de 15 minutos, minutos todos los días y luego todos vuelven a su trabajo y esto sigue pasando todos los días. Entonces se esprint, se está ejecutando, todo el mundo está haciendo el trabajo que se les asigna. Están actualizando su tarea. Están asistiendo al stand-up y así sucesivamente. Ahora consideremos punto para esto es verdaderamente el desarrollo de la interfaz de usuario está cerrado, por lo que moveremos esto a hecho. El diseño del caso de prueba también se cierra mientras se mueve a hacer. Una vez que el desarrollo ha sucedido. Moveamos a este tipo también. Por lo que una vez que el desarrollo haya ocurrido en las pruebas comenzará, las pruebas también se completarán. Entonces, una vez concluida la prueba, la UAT también iniciará y completará. Por lo que ahora todo dentro de esto son historias completadas. Entonces ahora lo haremos, JIRA dirá eso, vale, ya has completado toda la tarea dentro de ella. Se quiere actualizar la historia. Entonces déjenme dar click en actualizar. Y como puedes ver, esta historia pasará de estar en progreso a cerrar. Por lo que hemos concluido nuestro primer trabajo en el Sprint. Hemos completado nuestro primer entregable, nuestra historia más rápida. Y de igual manera, el equipo también estaría trabajando en paralelo en todas estas cosas. Y estarían actualizando su tarea. Estarían entregando ese estatus en el stand-up y estarían cerrando las cosas. Y recuerda, lo mismo se haría a los defectos también, los defectos también se asignarían a miembros individuales del equipo. Estarían trabajando en esos defectos, moviéndolos a diferentes columnas de estado de enfermedad que estamos viendo y lo estarían cerrando. Entonces así es como se sprint. Trabajaremos, así es como avanzaremos el sprint. Y otra cosa que debes notar es que mientras estamos en este sprint uno, también tenemos que hacer el aseo atrasado para Sprint dos. Por lo que dos o tres días antes de que se supone que termine el sprint uno, haremos el aseo atrasado para el próximo sprint. Por lo que toda la secuencia de eventos que hemos visto hasta ahora, vamos a repetir, revisaremos el rezago del producto. Daremos prioridad a estas historias. Revisaremos las historias. Entonces nos meten en el sprint 1 tercio siguiente sprint planeación viene y todas esas fuentes de esto, como dije, un Sprint es un scrum no es iteración de tarea. Por lo que seguimos repitiendo estos ciclos iterativos una y otra vez, y seguimos entregando nuevos incrementos al usuario. Ahora recuerda si haces click en esta cosa y verás una opción aquí para reportes. Por lo que si haces click en estos reportes, verás que diferentes métricas o reportes de los que hablamos. Por lo que tienes el gráfico de quemado. Tienes el gráfico de quemados. Yo sprint reportar el informe de velocidad todo el pan que vimos. Y estos gráficos no se poblarán adecuadamente para mí porque recuerden, acabo de crear el sprint hace unos minutos y vengo a verlo hoy por lo que no va a poblar para mí. Como puedes ver, ahí está la línea ideal está ahí, pero no hay línea de finalización porque acabamos de iniciar el sprint unos minutos atrás. Pero puedes probarlo por tu cuenta. Se puede tratar de crear un sprint claro primero, crear algo de historia, Epics, luego crea algunas historias con criterios de aceptación. Entonces crea un sprint a partir de él. Y luego se pueden cerrar algunas de estas historias cada día y se puede ver este gráfico moviéndose de todos modos, la idea aquí era no mostrar estos reportes. Ya lo hemos visto. Lo que quería mostrarles fue que JIRA les está brindando la opción de ver estos informes y JIRA está creando estos informes automáticamente para ustedes. No hay que poner en ningún esfuerzo manual para crear estos informes. Y una vez más, esta es otra ventaja por la que usamos tanto JIRA para proyectos Agile y Scrum, chicos correctos, así que este es el flujo primario de las cosas y hemos cubierto la mayor parte de las cosas y he explicado todo de una manera agradable y fácil y espero que tengas claro en todo. Entonces si ves el excel, hemos cubierto las tres partes. Conseguimos los requisitos iniciales. Creamos épicas para ellos, creamos historias de usuarios, agregamos criterios de aceptación. Después hicimos el aseo atrasado, priorizamos las historias, las revisamos, las estimamos, las metimos en la tarea de sprint, ellos, poniendo nuestro tipo ellos, creamos un Primavera, sabíamos cualquiera que sea el rezago del sprint, el trabajo que tenemos que hacer para las próximas dos semanas. Después hicimos nuestro trabajo en el sprint, hicimos el standup diario. Trasladamos una tarea en la pizarra, cerramos las historias, cerramos defectos, vimos el gráfico de quemado, todo por lo que este fue el flujo primario de las cosas. Esto fueron muchas cosas que hemos visto. A espero que tengas claro en todo. Si no, me puedes hacer las preguntas si tienes alguna. Por lo que también se hace esta parte. Ahora, veamos la última parte de la última conferencia. Gracias chicos. 41. Proyecto práctico: aplicación de ágil. Parte 4: Hola a todos. Por lo que cubrimos muchos aspectos relacionados con el proyecto de extremo a extremo en los capítulos pasados. Ahora, veamos si algunas últimas cosas en esta conferencia. Echemos un vistazo a este bonito calendario que tenemos aquí. Entonces, como saben, empezamos nuestro sprint de dos semanas justo aquí. Hicimos la planeación del sprint. Conseguimos nuestro trabajo para las próximas dos semanas e hicimos despejado tarea de quién va a hacer lo que todo estaba claro en la pizarra, nadie podía cambiarlo. He leído la obra era visible para todos. Sabemos quién está haciendo qué, si están en progreso, si están blogueados, etc. Así que las cosas están bastante ordenadas por su cuenta. El trabajo avanza. Estamos haciendo nuestros standups diarios, etcétera, etcétera. Y luego si te das cuenta aquí, todo va sin problemas. Y luego justo aquí unos días antes de que termine el sprint y tenemos que iniciar el siguiente sprint. Estamos haciendo el aseo del atraso o el refinamiento del atraso. Ahora lo podemos hacer aquí, lo podemos hacer aquí. No hay regla dura y rápida, pero queremos mantenerla unos días antes de empezar el próximo sprint. Porque recuerden, si algo surge en este aseo de atraso como un desconocido o riesgo, tenemos tiempo suficiente para resolverlo antes de que empiece el siguiente sprint. Y también recuerden estos son los últimos días de nuestro correr un sprint. Por lo que la gente podría tener trabajo compilado anexado devolved para completarlo antes del final de este giro. No queremos dedicar mucho tiempo a la gente en los últimos dos o tres días. Por lo que normalmente preferiría hacer el aseo atrasado este miércoles o máximo jueves. Entonces lo haremos por aquí y luego estaremos todos listos para el próximo sprint. Y luego como verán este martes cuando termine el actual sprint, estamos haciendo la revisión de sprint o demo. Estamos, estamos mostrando nuestro trabajo a todas las partes interesadas. Y también estamos haciendo la retrospectiva donde todo el equipo se reuniría para analizar cómo funciona todo esto de impresión, si tienen alguna sugerencia o retroalimentación, etc. Y chicos, si notan, este es el belleza de todo el proceso. Estamos haciendo esta demo y retrospectiva de inmediato al final del sprint. Por lo que una vez que demos el producto a las partes interesadas, estamos llegando allí retroalimentación rápida y temprana. Y una vez que estamos haciendo la retrospectiva, estamos obteniendo las lecciones aprendidas de esta corriente es sprint que podemos implementar en el próximo sprint que va a comenzar al día siguiente. Por lo que también se hacen estas dos ceremonias, y ahora al día siguiente comenzaremos con una planeación de sprint para el próximo sprint, sprint dos, ya tendremos el rezago de producto que finalizamos aquí en ese aseo. Y similar a lo que vimos, retomaremos las historias según nuestra velocidad y capacidad. Los vamos a encomendar, vamos a poner horas, etcétera, y este proceso iterativo seguirá y seguirá. Y una última cosa, este calendario no lo menciona, pero en algún lugar tendremos un lanzamiento también del producto de los incrementos que hemos diseñado para que el usuario final pueda usarlo. Y no hay una regla fija para establecer la fecha de lanzamiento. Se finaliza en la reunión de planeación de lanzamientos, y se puede hacer como aquí o aquí. No hay fecha fija a ocho. Depende de la hoja de ruta del producto, la demanda del cliente, costo, esfuerzo, etc. Vimos todos estos temas y el capítulo de planeación de lanzamientos. Entonces chicos, este fue todo el aspecto práctico de Agile y Scrum. Hemos implementado un proyecto desde cero. Hemos creado las historias de usuario es sprints, task, etcétera. Nosotros hemos hecho las diferentes ceremonias o Refinamiento Backlog, grooming atrasado, Sprint Planning, retro demoed, stand up, todas estas cosas. Entonces espero que hayas entendido todo con claridad y ahora estés súper confiado de todo lo que aprendimos. Por lo que esta última parte también lo está completando. Pero como ven, hemos cubierto muchas cosas en este capítulo. Entonces si tienes alguna pregunta, si no tienes claro nada, por favor no dudes en usar la Q y una opción o puedes dejarme un correo por aquí. Esta es mi dirección de correo electrónico y como mencioné en el pasado, también, respondo proactivamente a todos los correos en un plazo de 24 a 48 horas. Entonces mándame cualquier pregunta que tengas y haré todo lo posible para responderlas. Ahora antes de pasar a los siguientes temas, uno más preguntó de mi lado, chicos, por favor dejen una revisión del curso. Apenas tardará dos minutos de su tiempo, pero usted está calificando nos motivará aún más para crear un gran contenido como este para usted. De acuerdo, así que sigamos adelante. Hemos completado todos nuestros aprendizajes en Scrum. Hemos cubierto las partes teóricas, hemos cubierto las partes prácticas. Ahora echemos un vistazo al aspecto de certificación en el próximo capítulo. Gracias. 42. Exámenes de certificación con consejos para romper: Hola a todos y bienvenidos al nueve capítulo de este curso. Entonces ahora que hemos visto todos los aspectos de Scrum en teoría y práctica, hablemos de cómo utilizar este conocimiento y obtener una certificación. Entiendo que mucha gente que tome este curso estaría interesada en obtener una certificación también. Entonces echemos un vistazo a ese viaje. Hablemos primero de qué otras certificaciones, cómo inscribirse para ello y cómo dar el examen. Y luego te compartiré algunos consejos que te ayudarán a despejarlo. Por lo que hay dos certificaciones que son más populares en Scrum. El primero es el maestro scrum certificado o CSM. Y el otro es de 35 a donante de producto Scrum o CSP o.Si eres iniciador en Scrum o solo buscas obtener una certificación para tu conocimiento de su miga, entonces te sugiero que vayas por el CSM uno. Y si ya estás en la línea de negocio como puede ser un analista de negocios, puedes tomar el curso de dueño del producto. Entonces depende de tu línea de trabajo, tus planes de futuro, etcétera. Pero te sugeriré que empieces con el CSM. Por lo que en esta conferencia hablaremos del curso de CSM. Se puede leer más sobre CSP también, el proceso no es muy diferente. Entonces vayamos a su página web, que está en pantalla y veamos detalles. Recuerda si vas a hacer este curso más tarde, las cosas que hablo aquí podrían cambiar un poco. Y por eso te estoy señalando a la página web también porque eso siempre se mantendrá actualizado. Por lo que esta es la página de certificación. Y si te desplazas hacia abajo, puedes ver los diversos viajes de aprendizaje aquí en la pista maestra de Scrum. Contamos con el certificado Scrum Master Advanced Certified es Scrum master certificado scrum profesionalmente Scrum Master, igual que en producto no rastrear. También tenemos un par de cursos y en la pista de desarrollador también tenemos algunos cursos. No recomiendo cursos en pista de desarrollador. Si eres desarrollador y si quieres aprender es miga para tu propio aprendizaje personal o profesional, entonces solo tienes que ir por el curso CSM que es el mejor si eres un producto, si eres intruso línea de negocios como un analista de negocios y quieres convertirte en propietario de producto, probablemente puedas salir para este curso certificado propietario de producto Scrum. Pero para la mayoría de la gente, las canchas magistrales de scrum certificadas serían las mejores. Así que vamos a dar click en este link master scrum certificado y se abrirá algo como esto. Por lo que en esta página puedes ver todos los detalles y si te desplazas hacia abajo, puedes ver los requisitos para dar el examen. Existe un requisito previo para dar estos exámenes y datos CSM que tienes que asistir a un curso en línea o presencial antes de poder dar el examen. Eso es como un taller y es obligatorio y no te preocupes, no hay cargos extra por ello. Ya forma parte de las cuotas de examen y te ayudará también porque será una especie de revisión para ti lo que ya has aprendido en este curso. Ahora, una vez que hayas terminado con este taller, puedes dar el examen y habría como 50 preguntas y tienes que conseguir al menos 37, correcto. Y el límite de tiempo es de 60 minutos. Y créanme chicos, esta es una regla demasiado relajada. El examen CSM es muy, muy sencillo. Y si has seguido este curso a fondo, si revisarás las cosas en el taller, lo despejarás muy fácilmente, solo prepárate. Es muy sencillo. Ahora si te desplazas hacia abajo y si haces clic en este botón del buscador Curso, te llevará a la página de detalles del taller en función de tu país. Y puedes ver las ubicaciones, fechas, entrenadores, etcétera, en función de tu ubicación. Por lo que te recomiendo que puedas hacer algún lookup en la línea cuatro basado en los detalles del curso, horarios, entrenadores, etcétera, lo que sea que te convenga, puedes leer sobre la ubicación también. Entonces en mi caso, todo si ves su presentación en línea sólo porque estamos en el tiempo COBIT, así que las cosas están cerradas. Pero una vez que las cosas son normales, iv y talleres se abren para la interacción presencial. Te sugeriré que vayas por una clase presencial solo es más interactiva y te ayudará más mejor. Por lo que puedes hacer clic en el enlace Registrarse para cualquiera de los cursos que más te convenga. Y abrirá una página como esta con los detalles más finos. Y una vez que haga clic en esta casilla, le dará los detalles para realizar el pago. Entonces justo aquí y después de realizar el pago, recibirás un correo electrónico de bienvenida. Puedes hacer el taller, puedes, una vez que completes el taller, obtendrás otro correo electrónico que contendrá los detalles para dar el examen tan sencillo como eso. Recuerda, el único requisito previo es que tengas que asistir a este taller antes de poder dar el examen. Y creo que es algo muy bueno también, obtienes dos, interactúa con otro campo de software profesional. Se llega a revisar las cosas rápidamente y luego se puede dar el examen en base a ese conocimiento actual. Y en realidad toda esta y más información está presentando su página de preguntas frecuentes también. Entonces si vas a la página de inicio, desplázate todo el camino hacia abajo y haz clic en esta FAQ. Abrirá algo como esto. Y ahora tienes que dar click en este recuadro Preguntas de Certificación aquí mismo. Y obtendrás los detalles completos sobre un master scrum certificado y examen CSP. Las preguntas más frecuentes, navegé por toda su página web para conseguirte la mejor información. Y me pareció que esta página de preguntas frecuentes era muy bonita. Entonces si haces click en esto primero, ¿cómo me convierto en un master de scrum certificado? Te llevará a una página como esta. Y en las dos primeras preguntas aquí puedes encontrar prácticamente toda la información que te gustaría saber. Quieres saber. Ya te lo he dicho, pero sigue siendo si quieres leerlo, estas 2 primeras preguntas tendrán toda la información. También puedes hacer click en esto. ¿ Qué puedo, puedo esperar de la pregunta de prueba CSM y leer los detalles sobre el examen. Entonces como dije, es un examen de 60 minutos con 50 preguntas de opción múltiple y hay que responder al menos 74% correcto. Y es una prueba en línea. Puedes darlo desde cualquier lugar que quieras. Entonces eso es todo. Esos son todos los detalles que deberás conocer sobre el examen CSM. Y lo más importante, recuerda, como dije, es un examen muy sencillo. Podrás despejarlo muy fácilmente con los aprendizajes de este curso y una revisión que obtendrás en el taller. De acuerdo, así que ahora que sabemos del examen, volvamos atrás y dejemos ver algunos viajes, consejos para descifrar este examen. Por lo que la primera es leer la Guía Scrum antes de realizar el examen. Entonces si vas a la página web, hagámoslo otra vez. Por lo que fui a su página web, que es un scrum Alliance.org, y hago clic sobre estos recursos y doy clic en este e-books. Y disfrazarse. Aquí mismo está la Guía Scrum. Por lo que puedes hacer click en él y puedes descargar el PDF. Es de solo 19 páginas y puedes sacarle una huella y guardar una copia durante el examen. Este es el enlace de descarga para obtenerlo. Siguiente punto, toma alguna prueba simulada antes del examen para que puedas encontrar mucha prueba simulada en línea, solo Google para ello y pasar por un par de ellos. Te ayudará a practicar. Te dirá MOOC algunas preguntas comunes también que puedes preparar. En tercer lugar, cuando estás apareciendo para el examen, Uno de los temas comunes que todas las respuestas podrían sonar similares. Así que asegúrate de leer cuidadosamente todas las respuestas y luego seleccionas una opción que cuestiones que tomaste en el curso. Estamos en las líneas similares para darte una idea de cómo fue el examen. Por lo que eso te ayudará en cierta medida. Pero recuerda, siempre asegúrate de que estás leyendo todas las respuestas cuidadosamente y diez, seleccionando una opción. Siguiente punto puedes, puedes usar las reglas de eliminación, así que elimina primero la respuesta incorrecta. Esto te ayudará a descartar algunas opciones y luego identificar la respuesta correcta. En quinto lugar, ser paciente es apegarse a los hechos conocimiento. Entonces como dije, el examen es muy sencillo. Ya hemos aprendido muchas cosas para ello en el curso, y tendrás un refresco en el taller también. Así que sé paciente, ten confianza y apégate a lo que has aprendido. 6, revisa las preguntas antes en donde tienes una duda para poder sostener las respuestas donde tengas una duda y volver a ellas más tarde. Esto te ayudará a ahorrar tiempo. Y por último, antes de presentar el examen, asegúrate de haber respondido a todas las preguntas. Así que vuelve a comprobar rápidamente que todas las preguntas estén marcadas como respondidas antes de terminar las cosas. Entonces eso es todo, chicos. Esos fueron algunos de los trucos para ayudar con el examen de certificación CSM. Y permítanme repetirlo por última vez. Si haces este curso a fondo, si revisas las cosas en el taller y apareces para el examen con confianza, es muy, muy sencillo y podrás despejarlo muy fácilmente todo lo mejor. Está bien, entonces con esto, llegamos al final del capítulo. Pasemos a la siguiente y aprendamos sobre las preguntas de entrevista. Gracias. 43. Consejos para la entrevista: Hola a todos y bienvenidos al último capítulo de este curso. Hablemos de algunos consejos rápidos que te ayudarán a despejar cualquier entrevista, ya sea para un rol relacionado con el VIH o en general cualquier perfil. He incluido esta sección en el curso porque creo que el objetivo de nosotros en aprender algo nuevo es mejorar nuestro perfil de transportista y en algún momento u otro traducido a un mejor trabajo. Entonces ahí es donde te será útil esta sección. Y en la misma línea, he incluido alrededor 13 preguntas de entrevista en la sección de recursos de capítulos. Se pueden leer antes de cualquier entrevista y revisar rápidamente las cosas. Entonces, empecemos. Entonces chicos, digamos que aplicamos a un trabajo y ahora tenemos que ir a una entrevista. Entonces, ¿cómo podemos prepararnos para dat? Dejemos ver algunas reglas doradas. En primer lugar, estar bien arreglado y preparado. Por lo que vestirse profesionalmente, si hay un código de vestimenta requerido seguido en LC, Puedes vestirte en cualquier cosa que sea profesional y luego ir a la entrevista totalmente preparada para no solo presentarse por el bien de ello. Segundo, hacer algunas investigaciones sobre la empresa, el perfil laboral, etcétera. Es bueno saber a dónde vas. El entrevistador también podría preguntar si sabes de la empresa, así que haz tu tarea. Tercero, comportarse, preparar las preguntas conductuales. Entonces la primera pregunta que hacen en cualquier entrevista es siempre Cuéntame de ti o llévame a través de tu perfil. Entonces prepara una buena respuesta a eso. Algo que diga de quién eres, tus detalles educativos, tu experiencia laboral, tus habilidades técnicas, cualquier premio de proyecto notable, reconocimientos, etc. En mis días iniciales, solía tener una respuesta escrita para esto para que pudiera ser preparado. También puedes hacer eso. Pero si haces eso, solo asegúrate de que no suenas como si hubieras estropeado la respuesta, di las cosas en tu tono regular. Y luego aparte de esto, hay otras preguntas conductuales también como, ¿cuál es tu expectativa? ¿ Eres jugador de equipo? Todo ese tipo de cosas. Por lo que puedes encontrar la lista completa en internet. El concepto es que se preparen también para estas preguntas conductuales, y no sólo las técnicas. Cuarto, prepárate para hablar de cada proceso en tu empresa. Por lo que cuando estoy haciendo entrevistas, pido a la gente que explique el proceso ágil y complete el viaje en su empresa. Entonces prepara algo en las mismas líneas. ¿ Cómo se obtienen los requisitos? ¿ Cómo haces las ceremonias, cómo estimas sus puntos de historia, cómo manejas el tablero de HL, todas estas cosas. Siguiente y muy importante respuesta clara, así respondida de manera directa y precisa, puedes usar ejemplos para complementar tu respuesta. Siempre es útil dar seguimiento a los ejemplos. Puedes dar ejemplos de cualquier cosa similar que hiciste en n, en tu empresa actual o en otro lugar. 6 no te pelees. Ser de mente abierta, escuchar al entrevistador y mantener las cosas educadas. Siguiente punto y otra vez, muy importante. Si no sabes la respuesta, di que honestamente, hay nadie en el mundo que lo sepa todo, Así que permanezcan honestos y pasen la pregunta. No trates de farol al entrevistador. Te atraparán seguro y no estaría bien. Segundo último punto en cualquier entrevista, el entrevistador te preguntará al final si tienes alguna pregunta. Entonces aprovecha esa oportunidad para preguntar cualquier cosa sobre el perfil laboral, la empresa, etcétera, que quieras saber que también mostrará tu interés por el trabajo. Puedes pedirle al entrevistador su retroalimentación general sobre ti si pueden proporcionar alguna, pero no discutas sobre los aspectos salariales ahí que vendrán en una etapa posterior. Y finalmente el último punto b, confianza. Así que prepárate, sé optimista, responde todo con confianza y ojalá el resultado sea bueno. Entonces chicos, estos fueron algunos consejos importantes para entrevistas. Ahora también encontrarás una lista de 13 preguntas de entrevista adjuntas a este capítulo, que he creado cuidadosamente para cubrir diferentes aspectos de AGI y Scrum. Asegúrese de pasar por ellos, revisarlos antes de cualquier entrevista. Y papá, combinado con los aprendizajes de este curso, los consejos aquí deberían ayudarte a navegar por cualquier entrevista. Les deseo a todos los mejores chicos con esto, llegamos al final de este curso. Es realmente emocionante pensar en todo lo que hemos aprendido en este viaje. Empezamos con las carencias del enfoque tradicional y por qué un niño entró en escena. Hablamos de los conceptos centrales y definiciones de Agile y Scrum. Vimos los roles de Scrum es ceremonias de miga, es Scrum Artifacts, informes de planeación y estimación, certificación, entrevista, muchas cosas. Y también hicimos un proyecto con implementación práctica para que consigas una comprensión práctica de cómo funcionan las cosas en el mundo real. Por lo que efectivamente fue un gran viaje. Y espero que este curso haya ayudado en su objetivo de aprender sobre Agile y Scrum. Una vez más, quisiera reiterar dos puntos que mencioné también al inicio del capítulo. En primer lugar, el HL no es sólo una metodología más importante, es una mentalidad. Tenemos que ser un gigante en nuestros pensamientos, nuestro trabajo, nuestra colaboración con su equipo. Sólo entonces podremos implementar con éxito un gel o un Scrum. Así que mantén que SU mentalidad siempre te anden. Segundo, HI Lori. Scrum no es un palo mágico que resolverá todos tus problemas. Nos mostrará cuáles son los problemas o cuáles han sido los problemas con la industria. Y nos toca llevar la mentalidad de HL, trabajar juntos en equipo y entregar productos excepcionales. Por lo que el usuario final. Muy bien, así que estamos al final del curso, pero recuerda inscribiéndote en este curso, tienes derecho a la facilidad de soporte de consultas de por vida. Entonces si alguna vez tienes alguna pregunta, retroalimentación, si quieres hablar de algo en tu organización, cómo funcionó, y si tienes alguna confusión, no dudes en dejarme un email, mis ID de email en la pantalla, y contesto puntualmente a los alimentos en 24 a 48 horas. Ahora antes de que termine, una final preguntó desde mi sitio, por favor haz un par de momentos para revisar este curso y darnos una calificación. Tu feedback es muy importante para nosotros y nos ayuda a crear contenido excepcional para nuestros alumnos. Entonces una vez más, chicos, muchas gracias por elegir este curso y les deseo todo lo mejor en su viaje de aprendizaje. Gracias.