Gestión ágil de proyectos intermedios: planifica lanzamientos, lidera equipos y mide el éxito

1. INTRODUCCIÓN: Hola, y bienvenidos a la Agile Project Management corriendo a escala Master Class Si ya aprendiste los fundamentos de Agile y Scrum, es el momento de dar el siguiente paso En esta clase, vamos a ir más allá de gestionar un solo sprint y empezar a pensar como un líder de proyecto Ágil. Mi nombre es Luke Phillips. Soy gerente de proyectos con alrededor de siete años de experiencia liderando equipos ágiles y entregando proyectos en una variedad de industrias. A lo largo de mi carrera, he trabajado con enfoques Scrum, Camban y Agile híbrido para ayudar a los equipos a colaborar de manera más efectiva, adaptarse a las prioridades cambiantes y entregar valor En este curso, voy a compartir las técnicas prácticas que he utilizado para gestionar proyectos más allá de lo básico. Comenzaremos por ver el panorama general, cómo los sprints individuales encajan en ruta del proyecto y los planes de lanzamiento Aprenderás a planificar múltiples sprints y organizar objetivos de proyectos a largo plazo usando herramientas como No y luego profundizaremos en la estimación y previsión Aprenderás cómo los equipos ágiles estiman el trabajo, miden la velocidad y hacen predicciones realistas sin pretender que cada estimación es perfectamente precisa También compararemos los enfoques Scrum, Cam Ban e híbridos, ayudándote a comprender cuándo funciona mejor cada framework y cómo adaptar tu flujo de trabajo a diferentes tipos de proyectos La comunicación es otro foco importante de este curso. Aprenderá a trabajar con las partes interesadas, administrar los requisitos cambiantes, ejecutar revisiones productivas y comunicar progreso del proyecto de manera clara y eficiente. Finalmente, exploraremos las métricas ágiles, entendiendo qué medir, qué ignorar y cómo usar los datos para mejorar rendimiento de su equipo en lugar de simplemente generar informes. Al final de esta clase, tendrás el conocimiento y la experiencia práctica para gestionar proyectos ágiles más grandes, comunicarte de manera más efectiva y tomar mejores decisiones de proyectos con confianza. Empecemos. 2. Bienvenido al curso de gestión de proyectos intermedia.: Hola, y bienvenidos al curso intermedio de gestión de proyectos Ágil. Si ya has corrido un sprint o dos y estás listo para pensar más allá de un solo ciclo de dos semanas, este curso es para ti. Cubriremos cómo planificar en múltiples sprints, cómo estimar honestamente a escala, cuándo alcanzar Cam Ban en lugar de Scrum y cómo mantener informados a las partes interesadas sin ahogarse en En esta breve lección de apertura, repasaremos lo que ya debes saber antes de comenzar este curso intermedio, qué cubre este curso y qué deberás seguir. Entonces un resumen rápido de lo que ya debes saber antes de comenzar este curso intermedio Necesitas los fundamentos de la mentalidad Agile y el manifiesto Agile Si algo de esto no te resulta familiar, querrás apuntalar tus conceptos básicos antes de continuar Entonces debes entender la mentalidad Ágil y el manifiesto, no solo poder recitar los valores, sino reconocerlos en cómo funciona realmente un equipo Debe conocer los tres roles de Scrum, propietario del producto, Scrum Master y el equipo de desarrollo, qué hace cada equipo y qué no hace cada equipo Debe sentirse cómodo escribiendo historias de usuario, definiendo criterios de aceptación y sabiendo cuándo realmente se hace algo. También deberías tener un espacio de trabajo Trello y Notion ya configurado con un backlog poblado para el proyecto en el que estás trabajando Y lo más importante, deberías haber corrido al menos un sprint de extremo a extremo, planificarlo, ejecutarlo, revisarlo y luego ejecutar una retrospectiva La experiencia vivida importa aquí porque todo en este curso se construye sobre esa base. Entonces echemos un vistazo a lo que abarca este curso intermedio. Tenemos seis secciones. El cambio es de un sprint a muchos sprints. Cubriremos planes de lanzamiento de edificios que vinculan múltiples sprints juntos. Veremos estimar y rastrear la velocidad correctamente. Veremos las diferencias entre Scrum y Caban y cómo elegir Veremos la gestión de los stakeholders sin que nos coman vivos, y veremos las métricas que realmente importan más las que no. Entonces, al final de este curso, sabrás planear y ejecutar una serie de sprints que construyen hacia algo más grande Y ese es el salto principal de correr sprints individuales a desarrollar realmente algo significativo a través de Agile Lo que vas a necesitar. Aquí están las herramientas prácticas. Necesitarás Trello para tu tabla. Necesitarás Notion para la documentación. Si ya tienes los establecidos de trabajos anteriores, ya estás listo para comenzar. También querrás tu resumen de proyecto y tu cartera existente frente a ti La mayor parte de este curso se basa en el trabajo real, por lo que sacarás el máximo provecho de aplicarlo cada lección a un proyecto real. Entonces estamos listos para comenzar. Gracias por acompañarme. En la siguiente lección, alejaremos de un solo sprint y veremos el panorama general, cómo encajan los sprints individuales en los lanzamientos y por qué eso importa. Te veré ahí. 3. From Sprint to Release: Bienvenido de nuevo. En el mundo real, ningún equipo solo corre un sprint. Corren decenas, cientos, o construyendo hacia algo más grande. A ese algo se le llama liberación. Al final de esta lección, entenderás qué es un lanzamiento, cómo encajan los sprints y por qué pensar a nivel de lanzamiento cambia la forma en que planeas Entonces, ¿qué es un lanzamiento? Un lanzamiento es una parte significativa del trabajo entregado a los usuarios No solo un sprint vale un trozo del que vale la pena contarle a la gente Podría ser una nueva versión del producto, una característica importante, una campaña en vivo. Algo que el mundo exterior nota. Para un producto de software, una versión podría ser la versión dos puntos oh con el nuevo tablero y la incorporación rediseñada Para un evento, el lanzamiento es el evento en sí. Para el comercio electrónico, un lanzamiento podría ser la línea de productos Autumn, los seis productos, la nueva página de destino y la campaña de marketing. Los lanzamientos dan forma a tu trabajo. Ellos son los hitos en el viaje. Entonces, cómo se construyen los sprints hacia los lanzamientos. Cada sprint es como un peldaño. Así que la mayoría de los lanzamientos toman múltiples sprints. Tres es común, seis no es inusual. Algunos lanzamientos podrían tomar diez sprints. Entonces aquí está la relación. Un sprint ofrece un incremento, una pequeña pieza de salida de trabajo Un lanzamiento es una colección de incrementos que juntos logran algo más grande Así que imagínalo así. Tu objetivo de sprint podría ser Los alumnos pueden ganar estrellas después de completar las lecciones. Es útil, pero por sí solo, es una característica y no un lanzamiento. Tu objetivo de lanzamiento podría ser la versión dos punto oh, una experiencia de aprendizaje completamente gamificada Ese lanzamiento incluye las estrellas, más rayas, más insignias, más el tablero principal Tienes múltiples sprints construyendo juntos. Esto es importante porque cada sprint debe sentirse como un progreso hacia el lanzamiento. Si no puedes ver cómo se vincula este sprint a un gol de lanzamiento, o estás haciendo el sprint equivocado. O no tienes un objetivo de liberación claro. Entonces, ¿por qué pensar a nivel de lanzamiento? Veamos por qué importa. Hay tres razones por las que el pensamiento de nivel de liberación importa. Uno, a los interesados les importan las liberaciones, no los sprints. tu manager no le importa que terminaste la historia 47 el martes pasado. Les importa que la nueva característica se envíe en tres semanas. Hablar en lanzamientos conecta tu trabajo de sprint con las cosas que la gente realmente espera. Segunda razón, surge las dependencias temprano. Cuando planeas tres sprints juntos, ves esa historia B depende de que la historia A termine primero, y esa dependencia es invisible si solo planeas un sprint a la vez La tercera razón es que obliga a la honestidad sobre el tiempo. Por lo que este lanzamiento se envía en ocho semanas es un reclamo mucho más difícil que este objetivo sprint. O lo crees o no lo haces. La planificación de liberación es donde se expone la ilusión. Entonces una liberación versus planeación sprint, cadencia ligeramente diferente y diferente precisión Por lo que una planificación de sprint de distinción rápida ocurre cada dos semanas. La planificación de lanzamientos ocurre una vez por lanzamiento. Por lo que se detalla la planeación del sprint. Escoges historias específicas, te comprometes con ellas. Sabes exactamente lo que vas a hacer en las próximas dos semanas. La planificación de lanzamientos es más aproximada. Agrupas historias en temas, calculas cuántos sprints podría necesitar cada tema Los secuencias y construyes una línea de tiempo aproximada. Ambos son muy importantes. La planificación de Sprint sin contexto de lanzamiento produce un trabajo ocupado. La planificación de lanzamientos sin disciplina sprint produce fantasía. Por lo que hay tres trampas a evitar cuando las liberaciones salen mal. Entonces algunos errores comunes en el pensamiento de liberación. El número uno es la fluencia del alcance. El lanzamiento comienza con tres temas. Por sprint cuatro, tiene seis. Ahora estás atrás. Tienes que ser despiadado Cualquier cosa nueva entra en el próximo lanzamiento, no en este. El número dos son dependencias ocultas. Descubres a mitad de camino que dos temas no pueden enviarse sin un tercio Dependencias de superficie durante una planificación de lanzamiento, no a mediados de sprint Y el tercero es ignorar la realidad. La velocidad del equipo dice cinco sprints, pero el liderazgo quiere tres Liberar tarde es normal. Ocultar esa realidad hasta el último momento posible es lo que hace que despidan a la gente. Así que ignora eso. Gracias por acompañarme. En la siguiente lección, profundizaremos en los tres niveles de planeación que usa cada equipo de Agile, hojas de ruta, lanzamientos y sprints, en qué se diferencian y cómo mantenerlos conectados. Entonces te veré ahí. 4. Tres niveles de planificación.: Bienvenido de nuevo. En la última lección, presentamos lanzamientos. En esta, ampliaremos aún más la lente. Cada equipo de Agile planea en tres niveles, la hoja de ruta, el plan de lanzamiento y el sprint Se ven similares desde la distancia, pero responden preguntas muy diferentes. Al final de esta lección, sabrás para qué sirve cada uno y cómo mantenerlos conectados sin ahogarte en los planes Entonces, los tres niveles de planeación. Cuadro tres círculos concéntricos. Desde afuera hacia adentro, tenemos hoja de ruta, plan de lanzamiento y sprint La hoja de ruta es la más externa. Es la dirección de alto nivel a lo largo de seis meses, 12 meses, a veces hasta dos años. Dice, Aquí es donde vamos en temas amplios. No se trata de características o temas específicos. El plan de liberación es la capa intermedia. Dice, Aquí está la entrega mayor. Agrupa características y temas específicos en una versión. Y esto suele abarcar unos meses. Sprint es el más interno. Dice, Esto es exactamente lo que estamos haciendo en las próximas dos semanas con historias específicas, trabajo comprometido, y cada nivel responde a una pregunta diferente. Roadmaps respuesta A dónde vamos, libera respuesta, ¿Cuál es la próxima gran cosa?, y respuesta sprints, ¿Qué estamos haciendo ahora mismo? Entonces echemos un vistazo a lo que va en una hoja de ruta. Las hojas de ruta son temáticas. Muestran dirección pero no compromisos. ruta típica podría tener tres a cinco carriles de natación que cubran de seis a 12 meses Cada carril es un tema. Dentro del carril, tienes trozos ásperos de trabajo dimensionados por trimestre o por mes Evite poner fechas específicas en los elementos de la hoja de ruta. ruta son sobre dirección y las fechas crean falsa certeza Oth cuarto está bien. El 15 de agosto es rehén de la fortuna. ruta son propiedad del propietario del producto o gerente de producto, y se comparten ampliamente Las partes interesadas miran la hoja de ruta para entender lo que el equipo está haciendo este año Plan de liberación, el círculo medio. Los planes de liberación son más concretos. Convierten una hoja de ruta en entregable. Por lo que un plan de lanzamiento típico abarca de dos a seis meses. Enumera las principales características o historias del lanzamiento en orden de prioridad aproximado. Tiene una fecha de lanzamiento objetivo, pero la fecha es un objetivo más que una garantía. Planes de lanzamiento también dependencias de servicio. La historia X depende de la historia Y. No podemos enviar la página de lanzamiento sin los productos. No podemos llevar a cabo el evento sin la sede. Todas estas dependencias deben ser visibles a nivel de lanzamiento, incluso si el detalle vive en el plan de sprint individual Estos planes se revisan cada sprint. Son documentos vivos que se actualizan a medida que aprendes. Y finalmente, tenemos el plan sprint. Esto es detallado, está comprometido, y se trata de ahora. Un plan de sprint suele abarcar dos semanas. Enumera historias específicas con criterios de aceptación. Se compromete con un gol sprint. Incluye capacidad, riesgos y dependencias para las próximas dos semanas Los planes de sprint son los más precisos de los tres niveles porque el trabajo está sucediendo en este momento, lo que significa que también puedes ser específico. Cuanto más lejos planeas, menos específico podrás ser sin mentirte a ti mismo. Oh, algunos consejos para mantener conectados estos tres planes separados. Los tres niveles sólo funcionan si están conectados. Entonces, el primer consejo es cada gol de sprint debería escalar hasta un resultado de liberación. Si un sprint no se mueve hacia la liberación, ¿por qué incluso haces el sprint en primer lugar? Número dos, cada lanzamiento debe subir a un tema de hoja de ruta Si una versión no encaja en la hoja de ruta, la hoja de ruta es incorrecta o la liberación es Tres, revisarlos en diferentes cadencias. Planes de Sprint cada dos semanas, planes de revisión cada revisión de sprint, hojas de ruta cada trimestre Cuatro, usa el mismo vocabulario en los tres. Si tu hoja de ruta dice compromiso y tu liberación dice intención y tu sprint dice estrellas, has roto ese vínculo Asegúrese de que el lenguaje sea consistente. Y el quinto consejo es, mantenerlos a todos en el mismo lugar, si es posible. La noción funciona muy bien para esta página por nivel, todos vinculados entre sí. Bien, tres niveles, Roadmap, release y sprint conectados a través de objetivos claros y lenguaje compartido Gracias por acompañarme para esta lección. En la siguiente, pondremos manos en la construcción un plan de lanzamiento real para su proyecto en Notion. Te voy a ver ahí. 5. tu plan de lanzamiento.: Hola, y bienvenidos de nuevo. En este video, vamos a ver cómo construir tu primer plan de lanzamiento. Esto lo haremos dentro de Noción. En primer lugar, voy a repasar los pasos que vamos a dar para construir esta página, y luego te mostraré la página todo configurado en Notion. También te mostraré cómo agregar tus enlaces bidireccionales, que vincularán el lanzamiento con el sprint Oh, antes que nada, lo que estamos construyendo, vas a agregar a tu espacio de trabajo existente de Notion. Vas a agregar una nueva subpágina. Vas a agregar una nueva base de datos. Potencialmente vas a usar plantillas de página. Y luego también vamos a ver cómo agregas tus enlaces bidireccionales, que conecta el lanzamiento el sprint y el sprint con el lanzamiento En primer lugar, el primer paso es crear la página de subpágina tipo forward slash page, nombrar una nueva página llamada plan de lanzamiento dentro de la página principal del proyecto El número dos es agregar la base de datos a esa página. Así que adelante tabla de slash, y luego se puede configurar las columnas con los nombres nombre, meta de lanzamiento, fecha objetivo, estado, y sprint planeados Tres es poblar tu primer lanzamiento. Entonces haga clic en la fila y complete su primer objetivo de lanzamiento, su objetivo, el estado, etcétera cuarto paso es estructurar la página de lanzamiento con cinco secciones, con tus temas, tu desglose de sprint, las dependencias, los riesgos y el progreso Y luego el paso cinco será vincular tu sprint, que sería un enlace bidireccional de liberación a sprint y de sprint a lanzamiento Entonces echemos un vistazo a la configuración en Notion. Entonces he agregado el plan de lanzamiento de la página aquí en la parte inferior, así que te mostraré cómo debería ser esto. He agregado una base de datos. Tenemos el primer lanzamiento aquí, que es el lanzamiento 1.0 para mi proyecto, que es un proyecto de Ed Tech. El primer lanzamiento es Game Fide Learning. Tengo el gol de liberación aquí. El campo que he seleccionado ahí es texto, lo que me permite agregar por la versión 1.0, los alumnos están motivados a regresar diariamente a través de estrellas, rayas y personalización de avatar La siguiente columna es la fecha objetivo, donde he seleccionado la entrada que es fecha. Es el 14 de agosto de 2026, dentro de seis semanas, y he hecho clic en status, que es el campo select, que permite luego agregar los diferentes He agregado lanzado activo y planeamiento, y luego sprints planeados Esta entrada sería número. Acabo de poner tres. Entonces tenemos tres sprints planeados para este lanzamiento Entonces echemos un vistazo a la página de lanzamiento. Entonces, si abres la página de lanzamiento, puedes estructurar tu página de lanzamiento como tal. Ya tiene toda la información de la base de datos arriba y abajo, aquí es donde tenemos la estructura. Entonces tenemos temas con el sistema de recompensa estelar, rachas y hábitos, y personalización de avatar Tenemos desglose de sprint con el primer sprint y el enlace a la primera impresión. Tenemos la sección de dependencia clave con una decisión de biblioteca de animación si es necesario al final de sprint one, puntos finales de API backend para asistente estrella, activos de diseño para opciones de avatar Tenemos algunos riesgos en la parte inferior, la complejidad de la animación podría sangrar en sprint tres La mitigación es el pico temprano, y luego la lógica de racha, los casos de borde, los días perdidos, los cambios de zona horaria, etcétera Y en la parte inferior, tenemos el progreso, que es lo que rellenarías mientras hacías el sprint. Entonces, ¿cómo agregar el enlace? Aquí, he agregado el enlace al primer sprint, que es el sistema de recompensa Star. Entonces para hacer eso, solo agregas el signo de la aplicación, y luego comienzas a escribir el nombre de la página, que se llama sistema de recompensa estrella. Se le da clic ahí, y se agrega el enlace. Y luego cuando haces clic en el enlace, te lleva al sprint del sistema de recompensas estelares. Y como pueden ver, tenemos la capacidad. Tenemos las historias seleccionadas, tenemos los riesgos y dependencias, y el compromiso Este es el detalle del sprint. Y en lo alto de aquí, he puesto parte del plan de lanzamiento. Nuevamente, para agregar el enlace, basta con hacer clic. Escriba el signo de at. Aquí puedes buscar cualquier nombre de cualquier página que tengas, y puedes enlazar a esa página. Entonces tienes aquí el plan de liberación. Así que solo haz clic en plan de lanzamiento y podremos ver que está ahí. Y esto nos lleva de vuelta al plan de lanzamiento, que tenemos en esta página aquí. Así que déjame volver rápidamente ahí. Elimino esto. Es muy fácil agregar tus enlaces bidireccionales. Recomiendo encarecidamente hacer esto. Mantendrá todo muy bien vinculado. Entonces ese es el final de la noción, guía paso a paso sobre cómo configurar tu página de lanzamiento. Siguiente video, tenemos un pequeño ejercicio de práctica, que sería tu plan de lanzamiento. Así que redactando un plan de tres sprint para su breve seleccionado. Eso es lo siguiente. Te veré en la siguiente. 6. Ejercicio de práctica: plan de lanzamiento en 3 sprints: O Bienvenido de nuevo. Es momento de poner en práctica todo lo que has aprendido en esta sección. En este pequeño ejercicio, redactarás un plan de lanzamiento de tres sprint para tu propio resumen, y al final, tendrás un plan de lanzamiento real en noción listo para usar para el resto de este curso. Su tarea, tiene cinco pasos. Tómese su tiempo, pero no agonice por esto. El primer paso es definir tu objetivo de lanzamiento. Debe ser una frase, que es el resultado enfocado, y es lo que quieres verdad al final de tres sprints El segundo paso es identificar tres temas. Cada uno se convierte en el foco de un sprint y cada tema debe avanzar en el objetivo de lanzamiento. El tercer paso es desglosar cada tema en tres a cinco historias, su mayoría historias que ya existen en tu backlog si tienes una paso cuatro es sacar a la superficie dependencias y riesgos, lo que debe ser cierto para que se envíe esta versión Y el paso cinco es escoger una fecha objetivo y ser realista. Seis semanas es un buen estadio para una liberación de tres sprint. Ahora veamos mi ejemplo de trabajo de EdTech. Así es como se ve un buen objetivo de lanzamiento y cómo podría ser un plan terminado para mi informe de EdTech Por lo que el objetivo de lanzamiento es por la Versión 1.0, los alumnos de cuatro a ocho años están motivados para regresar a través de estrellas diarias, rachas y personalización tema uno es sprint uno, el sistema de recompensa estelar, las historias, las estrellas después de las lecciones, exhibición de estrellas y la animación. El tema dos es el sprint dos, que comprende rayas y hábitos Las historias son contador de racha diaria, recompensas de racha y manejo de racha de vueltas, y luego el Tema tres o sprint tres es la personalización de Avatar. La historia está ahí. Tenemos selección de Avatar, Avatar persistente y avatar en essons. Algunas dependencias, la biblioteca de animación elegida al final del sprint uno, los riesgos son que una lógica de racha pueda ser más compleja de lo esperado, y la fecha objetivo sea dentro de seis semanas Tenemos algunos errores comunes que evitar. Aquí están los tres grandes. El primero es hacer que el lanzamiento sea demasiado grande. Por ejemplo, por la versión uno, la app es perfecta, lo cual es esto es inútil. Elija un resultado más pequeño y más estrecho. Dos es si los temas no encajan en un sprint, si necesita dos sprints, realidad son dos temas, así que divídalo Y el tercero es ignorar la capacidad. No planee tres sprints por valor de trabajo en dos sprints. Comprueba tu velocidad, la cual cubriremos correctamente en la siguiente sección. Entonces algunas comprobaciones de cordura antes de llamarlo terminado. Una es, ¿el gol de lanzamiento se siente alcanzable en tres sprints con el equipo que tienes? Tienes que ser honesto. Dos es, si enviara solo el primer sprint, ¿eso sería útil por sí solo? buenos lanzamientos tienen victorias tempranas, no solo un gran final. Y Paso tres, ¿puedo explicar la liberación en una frase a alguien que nunca ha visto el proyecto? En caso afirmativo, está claro, si te encuentras clasificando, el gol no es lo suficientemente ajustado. Así que guarda tu noción de planificación de lanzamientos en la base de datos del plan de lanzamiento que construías en la última lección y vincúlala a tus páginas de planificación de sprint existentes para que los niveles se conecten. Y este es ahora su documento de referencia para las próximas secciones. Así que cada estimación o las métricas, lección de stakeholders en este curso, se referirán de nuevo a esto. A continuación, en la Sección dos, tenemos estimación y velocidad. En esta sección, hemos alejado un poco de sprint uno a lanzamiento, y tenemos el plan de página Así que gracias por acompañarme. En la siguiente sección, nos tomaremos serio la estimación y velocidad y las técnicas que hacen que la planificación multisprint sea realmente creíble. Te veré en la siguiente sección. 7. Por qué la estimación es difícil, y a menudo incorrecta.: Bienvenido de nuevo. En la gestión de proyectos, estimación es una de las cosas más difíciles que hace cualquier equipo, y es una de las más incomprendidas Antes de indagar en las técnicas en el resto de esta sección, debemos ser honestos sobre por qué estimación es tan difícil. Al final de esta lección, comprenderá los sesgos que hacen que la estimación no sea confiable y por qué eso cambia, cómo debe usar las estimaciones en primer lugar Primero, tenemos la falacia de planeación. Así que empieza con el mayor problema. Los humanos son terribles estimar cuánto tiempo tardarán las cosas Existe un sesgo cognitivo bien conocido llamado falacia de planeación, descrito por primera vez por Daniel Carnman y Amos Tversky El hallazgo es sencillo. Cuando las personas estiman cuánto tardará una tarea, subestiman consistentemente, no por poco, por mucho Los estudios han encontrado que incluso cuando se le dice a la gente sobre la falacia de planeación y se les pide que la corrija, todavía subestiman ¿Por qué? Porque cuando pensamos en una tarea, imaginamos el camino ideal. Nos imaginamos trabajando sin problemas sin interrupciones, sin contratiempos, sin descubrir que los requisitos no estaban claros Y la realidad no es nada de eso. Entonces, ¿por qué nuestro trabajo es peor? Ahora bien, la falacia de planeación se aplica a todo, pero algunos tipos de trabajo son más difíciles de estimar que otros Y desafortunadamente, la mayor parte de lo que hacemos cae en la categoría más dura. Estás pintando una barda, por ejemplo, puedes estimar razonablemente bien. Ya lo has hecho antes. Es una tarea física con progreso visible, y hay algunas incógnitas Sin embargo, si estás construyendo software, si estás ejecutando una campaña o estás organizando un evento, todo es diferente. Cada tarea es un poco nueva. A menudo estás resolviendo un problema que nunca antes habías resuelto. Los requisitos cambian a medida que aprendes, surgen dependencias que no anticipaste, y descubres a mitad de camino que el enfoque que escogiste no funciona Y hay que probar otra cosa. Por eso nuestras estimaciones en este tipo de trabajos suelen ser erróneas, no porque seamos malos para estimar, sino porque el trabajo en sí es inherentemente Entonces algunos sesgos comunes en la estimación. Más allá de la falacia de planeación, estos son varios otros sesgos que vale la pena conocer Primero está el sesgo de optimismo. Asumimos que las cosas irán bien incluso cuando la evidencia pasada diga lo contrario, te olvidas de las últimas tres veces que tu estimación explotó, te enfocas en las veces que funcionó incluso cuando la evidencia pasada diga lo contrario, te olvidas de las últimas tres veces que tu estimación explotó, te enfocas en las veces que funcionó . Siguiente es el anclaje. El primer número mencionado en una discusión se convierte en el ancla hacia la que gravitan todos Si tu manager dice ¿podría hacerse esto en dos semanas? De repente, dos semanas se siente razonable si realmente lo es o no. El siguiente es la presión social. Nadie quiere ser la persona que diga que esto llevará seis meses en una sala llena de ansiosas partes interesadas. Así que las estimaciones bajan silenciosamente para adaptarse a lo que la gente quiere escuchar. Y por último, tenemos el cono de la incertidumbre. Al principio de un proyecto, cuando menos sabes, tus estimaciones son las menos confiables. Pero también suele ser cuando la gente los quiere más. El cono se vuelve más estrecho a medida que aprendes, pero las estimaciones más tempranas son básicamente conjeturas Entonces, qué significa esto para cómo estimas. Entonces tres implicaciones prácticas. Uno, tratar las estimaciones como rangos, no puntos. Esto tomará 2-5 sprints es más honesto que esto tomará tres sprints Cualquier estimación de un solo número está ocultando incertidumbre. Dos, rastrea tus estimaciones frente a la realidad. Con el tiempo, aprenderás el sesgo real de tu equipo. Si subestimas consistentemente en un 40%, puedes comenzar a corregirlo, pero no puedes corregir por lo que no mides Tres, utilizar estimaciones para planeación y no para prometedoras. Este es el mayor cambio. Una estimación es una herramienta para tomar decisiones sobre qué trabajar. No es un compromiso entregar en una fecha concreta. En el momento en que una estimación se convierte en una promesa, has roto la honestidad que la hace útil. Entonces, ¿por qué todavía estamos estimados? ¿Por qué molestarse? Entonces, ante todo esto, quizás te preguntes por qué molestarte en estimar en qué, para ser justos es una pregunta justa, pero la respuesta es incluso malas estimaciones ayudan Te obligan a pensar en la obra. Surgen incógnitas. Te dan un tamaño aproximado para comparar opciones. Entonces esto es definitivamente más grande que eso es más útil que los números exactos. Las técnicas que cubriremos en el resto de esta sección no se tratan solo de producir estimaciones precisas. Nadie realmente produce estimaciones precisas todo el tiempo. Se trata de producir estimaciones útiles, estimaciones que informan decisiones que fuerzan conversaciones honestas y que mejoran con el tiempo a medida que rastrea cómo se comparan con la realidad. Bien, la estimación es difícil, pero ser honesto al respecto es el primer paso para hacerlo bien. Gracias por acompañarme. En la siguiente lección, profundizaremos adecuadamente en los puntos de la historia, qué son, cómo usarlos y cómo evitar las trampas en las que caen la mayoría de los equipos . Te veré ahí. 8. Puntos de historia: inmersión profunda: Bienvenido de nuevo. Los puntos de historia son la técnica de estimación más común en Agile, pero también son los más incomprendidos En esta lección, vamos a ir un poco más profundo que el nivel de la superficie. Veremos qué son realmente los puntos de la historia , por qué funcionan y las prácticas específicas que los hacen útiles más que performativos Entonces, ¿qué son los puntos de la historia? Son una unidad para medir el tamaño relativo de una pieza de trabajo. Combinan tres cosas, cuánto esfuerzo requiere una historia, qué tan compleja es y cuánta incertidumbre conlleva. La historia de cinco puntos es aproximadamente cinco veces el tamaño de una historia de un punto, no cinco veces las horas, cinco veces el tamaño. esfuerzo, la complejidad y las incógnitas se juntan en un solo número El punto es que los cerebros humanos son mucho mejores comparar tamaños que en estimar duraciones absolutas Pregúntale a alguien cuánto tardará una tarea en horas, probablemente se le preguntará si es más grande o más pequeña que otra tarea, generalmente lo harán bien. Por lo que la secuencia de Fibonacci explicó correctamente. La mayoría de los equipos utilizan la secuencia de Fibonacci uno, dos, tres, cinco, ocho, 13, 21, a veces 40 y 100 para artículos muy grandes Hay dos razones para esta secuencia específica. Primero, las brechas se hacen más amplias a medida que los números se hacen más grandes. La diferencia 1-2 es pequeña. La diferencia 13-21 es enorme. Y esto refleja una verdadera incertidumbre. Cuando algo es pequeño, en realidad se puede ver con claridad. Cuando algo es grande, probablemente no lo entiendas lo suficientemente bien como para distinguir un ocho de un nueve. Segundo, las amplias brechas obligan a las decisiones. No puedes sentarte en la barda entre dos números adyacentes. O es un cinco o un ocho, esa elección de fuerza acelera estimación y evita un debate interminable Así que anclando tu historia de referencia. La práctica más importante con puntos de la historia es elegir una buena historia de referencia. Este es el ancla, una historia que todos en el equipo conocen bien, que todos coincidan es cierto tamaño, generalmente un dos o tres. Todas las demás estimaciones ocurren en relación con esta referencia. Una pequeña historia de referencia que es lo suficientemente pequeña como para ser fácilmente entendida, bien documentada, y ya entregada, así que todos recuerdan cómo le fue Entonces cuando estimas una nueva historia, la pregunta no es, qué tan grande es esto en abstracto. ¿Cómo se compara esto con nuestra referencia? Si tu equipo está haciendo la historia de tu proyecto sobre ganar estrellas para completar la lección, acuerdo en que fue un tres. Entonces cuando miras una nueva historia como agregar rayas, preguntas, ¿es esto más grande o más pequeño que las estrellas Por cuánto, dos veces a la mitad. Sin una historia de referencia, estimaciones comienzan a la deriva. Cada sprint, significan algo ligeramente diferente y los números dejan de ser comparables con el tiempo. Planear el poker correctamente. Los puntos de historia funcionan mejor cuando lo estiman todo el equipo. Jugar al póquer es la técnica clásica, pero déjame ir más profundo que el nivel de la superficie. Todos en el equipo obtienen un juego de cartas con los números de Fibonacci El propietario del producto lee la historia. El equipo hace preguntas aclaratorias brevemente. Entonces cada persona escoge una tarjeta en secreto y todos revelan al mismo tiempo. El momento crítico es cuando las estimaciones no están de acuerdo. Digamos que tres personas dijeron tres y una persona dijo ocho, no solo promedien. No solo tomes el más alto o el más bajo. Pida a los valores atípicos que expliquen. Nueve de cada diez veces, la persona que estimó ocho sabe algo que los demás no saben. Tal vez haya una dependencia o una complejidad o un fracaso pasado que ellos recuerden, y ese conocimiento necesita salir a la superficie. Una vez que lo han compartido, todos los demás lo reestiman. El número entonces suele converger. Si trabajas solo, eres todo el equipo, lo que significa que debes ser extra riguroso. Intenta estimar la misma historia con un día de diferencia y compara. Busca consistencia. Tu primera estimación de rubor suele ser bastante optimista. ¿Qué puntos de la historia o no? Algunos malentendidos comunes. Se equivocan estos, y los puntos de la historia se vuelven prácticamente inútiles. Uno, los puntos de la historia no son horas. Diez puntos de historia no significa 10 horas o diez días o cualquier tiempo específico. La relación entre los puntos y el tiempo solo surge a lo largo de múltiples sprints y solo para ese equipo específico Dos, los puntos de historia no son una métrica de rendimiento. Si todos te dicen que el equipo debería estar entregando 40 puntos por sprint, han entendido mal Los puntos de la historia son para planeación. No son un palo para vencer a los equipos. Tres, los puntos de la historia no son comparables entre equipos. cinco del equipo A no son lo mismo que los cinco del equipo B porque los puntos de la historia se colaboran con la historia de referencia específica de un equipo, solo son significativos dentro de ese equipo. Cuatro, los puntos de la historia no son fijos. Si una historia que estimaste como un tres resultó ser mucho más grande de lo que pensabas, no actualizas retrospectivamente la Dejas la estimación tal cual, y usas la diferencia para mejorar las estimaciones futuras. Cuando los puntos de la historia no funcionan, por lo que no son la herramienta adecuada para cada situación todo el tiempo. Hay tres situaciones en las que quizás no las necesites. Equipos muy pequeños haciendo un trabajo muy similar. Si estás solo y cada historia es aproximadamente la misma, no necesitas puntos. Solo cuenta historias. Trabajo altamente variable si un sprint es ingeniería pesada y el siguiente es pulido ligero. Los puntos no serán comparables, Cam Ban con el equipo ciclista que podría funcionar mejor. Cualquier situación en la que se esté utilizando la estimación para prometer una fecha. Si el liderazgo toma tu argumento total y lo convierte en una fecha límite, la técnica está siendo mal utilizada. Es mejor no estimar en absoluto que alimentar un proceso roto. Los puntos de la historia hechos correctamente son una poderosa herramienta de planificación. Hacerlos mal, pueden convertirse en fuente de confusión. Gracias por acompañarme en esta lección. En el siguiente, veremos qué puntos de la historia hacen posibles a través de múltiples sprints y velocidad de seguimiento Te veré ahí. 9. de la velocidad de seguimiento a través de los Sprints: Bienvenido de nuevo. Ahora que hemos cubierto los puntos de la historia, podemos hablar de la métrica que hacen posible, que es la velocidad. La velocidad es una de las métricas más potentes y más mal utilizadas en Agile En esta lección, cubriremos qué es la velocidad, cómo rastrearla bien y cómo mantenerla útil sin dejar que se vuelva peligrosa. Entonces, qué es realmente la velocidad. La velocidad es simple. Es el número total de puntos de historia un equipo completa en un solo sprint. El equipo terminó cuatro historias por valor de tres, cinco , cinco y ocho puntos, su velocidad para ese sprint fue de 21. Aviso, la velocidad cuenta solo historias completadas. Cualquier cosa que quede en el hacer al final del sprint no cuenta, y esto es deliberado. El trabajo terminado es lo que más importa. crédito parcial fomenta los comportamientos exactos que no quieres como acumular trabajo medio hecho Se calcula la velocidad para cada sprint. Con el tiempo, obtienes una serie de números que muestran cuánto entrega tu equipo de manera consistente. Tan muy útil. Por qué importa. Hay tres razones por las que la velocidad es valiosa una vez que tienes algunos sprints por valor de datos Uno, ayuda con la planificación de sprint. Si tu velocidad promedio es de 25 puntos, no te comprometas a 40 en el siguiente sprint porque fallarás. Trabajarás en exceso y tus estimaciones futuras serán envenenadas por este falso punto de datos Dos, permite pronosticar. Si tu liberación restante tiene 100 puntos de trabajo y tu velocidad es de 25, estás aproximadamente a cuatro sprints. Exactamente, pero suficiente para hacer planes reales. Tres, da servicio a problemas. Una caída repentina en la velocidad es una señal. ¿ Alguien estaba enfermo? ¿Asumiste un trabajo inusualmente complejo? ¿Se está quemando el equipo? Los datos de velocidad indican las conversaciones correctas. ¿Cómo rastrearlo bien? Por lo tanto, orientación práctica. Primero, ignora los tres primeros sprints. La velocidad inicial de cada equipo no es confiable. Aún estás calibrando los tamaños de tus puntos de historia. Tu historia de referencia se estabiliza. Entonces, tres sprints es aproximadamente el tiempo que tardan los números en comenzar a tener sentido Segundo, usa un promedio rodante, ni un solo sprint. Mira tus últimos tres o cinco sprints y toma el promedio medio Esto suaviza un solo sprint al ruido de sprint. Un solo sprint con velocidad 40 no significa nada si tu promedio rodante es 25. Tercero, rastrearlo visiblemente. Una mesa simple funciona. Agrega un registro de velocidad en tu espacio de trabajo Noción con una fila por sprint. Columnas, número de sprint, puntos planeados, puntos completados y cualquier nota sobre por qué el sprint fue como le fue. Con el tiempo, estos datos se convierten en oro. Cuarto, revísalo cada sprint. En tu retrospectiva, mira tu tendencia de velocidad, no para calibrar o regañar, solo para Hemos caído en cada uno de los últimos tres sprints. ¿Por qué es eso? Podrás averiguarlo. A continuación, tenemos los peligros de la velocidad. La velocidad es poderosa, pero también es fácilmente mal utilizada. Hay cuatro peligros que hay que conocer. Uno, la velocidad como objetivo. El momento en que la velocidad se convierte en una meta, deja de medir lo que pensabas que hiciste. Los equipos inflan sus estimaciones de puntos de historia. De pronto, una historia que era un tres es un cinco, velocidad sube, a pesar de que en realidad nada cambió. Dos, comparaciones de velocidad entre equipos. El Equipo A hace 40 puntos. El equipo D hace 25. El equipo B se ve perezoso, pero tal vez solo estiman de manera diferente. A lo mejor su trabajo es genuinamente más duro. Nunca compare la velocidad entre equipos. Tres, velocidad como productividad. La alta velocidad no es lo mismo que el valor alto. Un equipo podría entregar 100 puntos de características que nadie usa. Los puntos de historia miden el tamaño pero no el valor. Y para la velocidad acostumbrada a la vergüenza. En demasiadas organizaciones, velocidad se convierte en un palo que el liderazgo utiliza para presionar a los equipos. Esto destruye la honestidad que hace útil la métrica en primer lugar Así que agregando velocidad a tu espacio de trabajo. Esta podría ser una nueva subpágina de Noción con cuatro columnas. Así que abre tu espacio de trabajo Noción, agrega una nueva subpágina dentro de tu página principal del proyecto, llámalo registro de velocidad Dentro de esa página, agregue una base de datos con cuatro columnas, número sprint como número. Los puntos planeados como un número, los puntos completados como un número y las notas como texto. Completa una fila por sprint a medida que los completas si ya has hecho uno o dos sprint, puedes rellenarlos ahora porque incluso los datos históricos aproximados son útiles que nada, y con el tiempo, esto se convierte en la memoria de tu equipo Ahora, los miembros del equipo pueden ver la historia, retros pueden apuntar a los datos y los pronósticos se pueden basar en la realidad Así que oro absoluto a un proyecto. Sin embargo, la velocidad puede provocar algunas oscilaciones. Algunos equipos tienen velocidad tremendamente variable sprint a sprint Si ese eres tú, no entres en pánico. Hay tres causas comunes de esto. Uno, tu historia de referencia sigue cambiando. Fijar la referencia, anclar en una historia que todos recuerdan Dos, la longitud de tu sprint es inconsistente. Si algunos sprint a dos semanas y otros son de una semana, claro, la velocidad va a variar. Solo arregla la longitud del sprint. Tres, estás haciendo tipos de trabajo tremendamente diferentes en cada sprint Algunos sprints son de construcción pesada, algunos son pruebas. Así son sólo pulir. En ese caso, los puntos de la historia podrían no ser la herramienta adecuada para tu equipo. Cubriremos a Caban como alternativa en la siguiente sección. Velocity used well es una herramienta genuina de pronóstico, pero mal utilizada, se convierte en teatro Así que asegúrate de que lo estás usando correctamente porque se usa correctamente, puede convertirse en oro. Gracias por acompañarme en esta lección. En el siguiente, pondremos a trabajar la velocidad, pronosticando cuántos sprints tomará realmente tu lanzamiento. Te veré ahí. O 10. Forecasting the Release: Bienvenido de nuevo. Todo lo que va de esta sección ha sido la base. Ahora vamos a ponerlo a trabajar. En esta lección, aprenderás a responder a la pregunta que cada actor eventualmente hace, ¿Cuánto tiempo va a tomar esto? Al final, sabrás producir un pronóstico defendible y honesto sin pretender ver el futuro El cálculo básico, esta una línea de aritmética, es bastante simple, realmente, los puntos restantes totales divididos por la velocidad promedio Entonces, si a tu lanzamiento le quedan 100 puntos de trabajo por hacer y la velocidad promedio de rodadura de tu equipo es de 25 puntos por sprint, entonces necesitarás aproximadamente 100/25, que son cuatro sprints Esto es simple y es lo suficientemente confiable para la mayoría de los propósitos. Pero hay un poco más que eso porque el cálculo depende dos números que ambos llevan un poco de incertidumbre. Los puntos totales y la velocidad. Si uno de estos se equivoca, entonces el pronóstico también es incorrecto. Entonces comenzamos con el conteo total de puntos. Esto supone que has estimado cada historia del lanzamiento. Cuando en la práctica, rara vez se tiene. Algunas historias son bien entendidas, pero algunas siguen siendo vagas y algunas pueden incluso no existir todavía. Ahí está esta vieja regla en Agile no todo lo que hay en el backlog se estima Solo las historias que están cerca de la cima de la acumulación obtienen estimaciones adecuadas Historias más abajo o marcadores de posición ideas o incluso deseos Entonces, cuando estés pronosticando, sé honesto sobre lo que realmente representa tu total de puntos ¿Es un total de historias bien estimadas o es una mezcla de estimaciones sólidas y conjeturas aproximadas Práctica útil aquí para historias que aún no están estimadas, agrega un marcador de posición usando el tamaño promedio de la historia de tu equipo Si tus historias son cinco puntos, usa cinco para cualquier cosa que sea vaga Es mejor que nada, pero marcarlo explícitamente en el pronóstico Problema con la velocidad. Ahora bien, para el lado de la velocidad, tu velocidad promedio solo es útil si el futuro se parece al pasado, y muchas veces no lo hace. Los miembros del equipo se van de vacaciones, se unen nuevas personas, el trabajo se vuelve más duro a medida que aborda las historias más complejas que quedan en la parte superior de la acumulación Surgen dependencias que ralentizan las cosas. Un pronóstico más honesto utiliza un rango en lugar de un solo número. Entonces miras tus últimos cinco o seis sprints, y la velocidad más baja es tu peor de los casos El más alto es tu mejor caso. El promedio es tu caso medio. Después presentar tres números. El mejor caso son tres sprints. El caso probable es de cuatro sprints, y el peor de los casos son seis sprints Esto es mucho más honesto que decir cuatro sprints y luego fingir que ya sabes Entonces, hablando con las partes interesadas, aquí hay algunas reglas para la conversación con las partes interesadas ya que la forma que comunique su pronóstico importa tanto como los números en sí mismos. No dar un solo número. No digas que se enviará en seis semanas. Esto siempre termina mal. La realidad nunca coincide con una estimación de un solo punto. Sin embargo, da rango con contexto explícito. Basado en nuestra velocidad actual, este lanzamiento tomará 4-6 sprints, pero probablemente cinco Ese rango asume que no hay cambios de equipo y no hay grandes sorpresas. Refinaremos la estimación de sprint cada sprint a medida que aprendamos más. Nombra explícitamente tus suposiciones. Esto supone que no asumimos ninguna otra prioridad. Esto supone que no pierdes a nadie. Esto supone que las estimaciones que tenemos son aproximadamente correctas, y las partes interesadas pueden entonces desafiar esas suposiciones, que es exactamente la conversación en la que actualizas el pronóstico cada sprint. El pronóstico fresco te da datos frescos, comunícate el cambio abiertamente. Por ejemplo, hace dos semanas dije de cuatro a seis sprints. Con base en estos datos de sprints, ahora parece de cinco a siete, y esto normaliza el cambio Nadie espera que un pronóstico hecho hace meses siga siendo exacto. Aquí hay algunos errores comunes a evitar. Uno está asumiendo que la velocidad es estable, lo cual es. Algunos sprints son peores que otros, así que por eso usamos rangos y no promedios Dos, olvidando el trabajo sin historia, correcciones de errores, reuniones, administración, deuda tecnológica, thesy inter capacidad, pero a menudo no están en su total de puntos de historia, por lo que debe ajustar para esos Tres, suponiendo que el equipo pueda ir más rápido, si todos trabajamos los fines de semana, entregaremos en tres sprints Esto es una fantasía completa. Ritmo sustentable es lo que mide la velocidad. Trabajar horas extras no escala, y no es la realidad Cuatro, ignorando dependencias ajenas al equipo. Si su liberación depende de otro equipo, un proveedor, un cliente o una decisión de parte interesada, su pronóstico solo es bueno como su puntualidad Hacer visible la dependencia en el pronóstico. Entonces, ¿y si tu pronóstico no es bienvenido? En este caso, sólo hay que ser honesto de todos modos. Entonces, a veces tu pronóstico honesto entra en conflicto con lo que quiere el liderazgo, y esto sucede todo el tiempo. ¿Qué haces en esas situaciones? La honestidad es la mejor política. Basado en nuestra velocidad, esto parece una liberación de seis sprint. Sé que querías tres hablemos de lo que podríamos hacer para darle a eso. Nunca te comprometas silenciosamente con una cita a la que no puedas acertar. Eso no te da tiempo. mueve un fracaso a más tarde, que donde simplemente va a doler más. Si la presión es severa, ponla por escrito. Acordamos que lo intentamos por tres sprints. Entender esto está muy por debajo nuestra velocidad promedio y requeriría dejar caer X, Y y Z. Esto protege a todos si el horario falla Entonces un pronóstico no es una promesa. Es una estimación considerada hecha con los mejores datos que has comunicado con honestidad sobre sus límites. Gracias por acompañarme en esta lección. En la siguiente, vamos a armar este ejercicio, y usted estimará su propio lanzamiento y producirá un pronóstico real. Te veré en la siguiente. 11. Ejercicio de práctica: estimación y pronóstico.: Bienvenido de nuevo. Es momento de poner todo de esta sección en un ejercicio práctico adecuado. Vas a estimar las historias en tu lanzamiento, producir un pronóstico real y comunicarlo de una manera que funcione con partes interesadas reales. Al final, tendrás un pronóstico defendible para tu plan de lanzamiento, respaldado por datos reales Entonces, antes que nada, configura tu espacio de trabajo, abre Notion y Trello Entonces en tu Trello, tienes tu tablero y tienes tu espacio de trabajo o documentación de Notion, estarás trabajando con ambos En Notion, si aún no lo has hecho, agrega una subpágina de registro de velocidad, una base de datos simple con cuatro columnas. Número de sprint, puntos planeados, puntos completados y notas. Si ya has corrido un sprint o dos, rellena tu registro de velocidad con lo que realmente entregaste en esos sprints Las estimaciones aproximadas aquí están bien. Algo es mejor que nada. En tu tablero de Trello, asegúrate de que todas las historias de tu versión actual estén visibles Si están repartidos por todo el backlog, agruparlos de alguna manera tal vez con una etiqueta como la versión 1.0 De esta manera, se puede ver el alcance completo en un solo lugar. Lo siguiente es elegir tu historia de referencia. Este es el ancla en la que cuelga todo lo demás. Este es el primer paso del ejercicio. Así que mira las historias que ya has completado y elige una que sea pequeña, bien entendida, y que todos puedan recordar. Claramente. Este es tu ancla. Asignarle un valor de punto. Dos es un buen defecto. Ahora, anote lo que lo convierte en un dos, algo así es un simple cambio de interfaz de usuario que tardó un par de horas sin incógnitas y sin dependencias. Son nuestros dos. Esta descripción te ayudará a calibrar otras estimaciones en el futuro. Estima cada historia de tu lanzamiento en relación con tu historia de referencia. Así que repasa tus historias una a la vez. Por cada historia, pregunta, ¿esto es más grande o más pequeño que mi referencia? ¿Cuánto más grande? Elige un número de Fibonacci, uno, dos, tres, cinco, ocho, 13 Algunos consejos. Si te encuentras dudando entre números, elige el más grande El sesgo de optimismo es real. Entonces, si una historia se siente como un ocho, estime ocho. Si una historia se siente como una 21 o más grande, detente, es demasiado grande y dividirla historias más pequeñas y luego estimarlas. Si realmente no entiendes la historia lo suficientemente bien como para estimarla, entonces márcala como que necesita refinamiento No adivine porque eso te dará falsa confianza. Apunta a diez o 20 historias estimadas, pero no trates de estimar toda la acumulación, esta versión Agrega tu presupuesto como etiquetas en las descripciones de las tarjetas en Trello para mantenerlo visible. El paso tres es sumarlo todo. Suma los puntos para todas tus historias estimadas. Este es tu total para el lanzamiento. Mira tu registro de velocidad. Si tienes datos de sprints anteriores, toma un promedio rodante Si aún no tienes datos, está bien. Puedes hacer una estimación aproximada basada en lo que entregó tu primer sprint, o puedes estimar lo que crees que producirá un sprint realista. Divide los puntos de liberación totales por tu velocidad, y este es tu pronóstico básico. Ahora haz el cálculo del rango, divide por tu velocidad más baja para el mejor de los casos, por tu más alta para el peor de los casos, y esto te da un rango adecuado. Escribir el pronóstico en Noción es el siguiente paso, y esta es la parte más importante. Abra su plan de lanzamiento en Notion bajo su encabezado de progreso o agregue uno nuevo llamado pronóstico. Escribe lo siguiente. El rango de pronóstico en sprints, mejor de los casos, probable , peor de los casos, el rango de datos a los que corresponden esos sprints, si un sprint es de dos semanas, cuatro sprints son ocho semanas Así que anota las suposiciones que hiciste, la disponibilidad del equipo, sin cambios de alcance, sin grandes sorpresas, sin refinamiento de estimaciones a medida que aprendes Lo último es el nivel de confianza basado en tres sprints de datos de velocidad, confianza media, o basado en un sprint, baja confianza Este es su documento de pronóstico, y esto es lo que compartiría con las partes interesadas. Es real, es honesto, y es defendible. Datos dorados. Antes de que lo llames hecho, hay tres comprobaciones que realmente deberías hacer. Uno, ¿el pronóstico se siente bien? Si dice tres sprints y tu instinto dice seis, realmente deberías confiar en tu instinto Algo está mal ya sea en tus estimaciones o en tu velocidad. Dos, ¿podría defenderle esto a un stakeholder? Si alguien desafió los números, ¿ podría guiarlos a través del ejercicio? En caso afirmativo, entonces es bueno. Si no es así, es necesario agregar más detalles. Tres, ¿qué me cambiaría de opinión? Si surgió una nueva dependencia o si el equipo encogió o si la historia resultó ser mucho más grande, nombrarlos los hace visibles. Entonces ahora tienes un pronóstico real y honesto para tu liberación. Así que guarda esto y actualiza cada sprint. Gracias por acompañarme para esta sección. En la siguiente sección, veremos Scrum, Canban y cómo elegir el enfoque adecuado para el trabajo que realmente estás realizando. Te veré ahí. 12. Scrum revisitado: When It Works, When It Doesn't (traducción de inglés: "Cuando funciona, cuando no lo hace".: Bienvenida de nuevo. En esta lección, vamos a echar un vistazo honesto Scrum y hacer un resumen rápido de lo que es Scrum es el framework Agile más utilizado en el mundo y por una buena razón, pero no es la herramienta adecuada para cada situación Entonces, al final de esta lección, sabrás dónde brilla genuinamente Scrum y dónde funciona silenciosamente en tu contra y cómo detectar las señales de advertencia de que podría ser la opción incorrecta para tu proyecto Bien, rápido pequeño resumen de Scrum condensado en 1 minuto Solo asegurémonos de que estamos todos en la misma página aquí. En caso de que Scrum sea nuevo para ti, aquí tienes todo en solo 1 minuto Scrum organiza el trabajo en bloques de longitud fija llamados sprints, que suelen durar de una a dos semanas Planeas un sprint, te comprometes con un conjunto de trabajo, y proteges al equipo de los cambios durante ese sprint, y al final, revisas lo que construyes y reflexionas sobre cómo fue, y luego lo vuelves a hacer todo. Tres roles, un propietario del producto que decide qué se construye y en qué orden, Scrum Master que ayuda al equipo a trabajar bien y eliminar bloqueadores y el equipo que realmente hace el trabajo Hay un puñado de reuniones regulares, planeación al inicio, un breve check in diario, y la revisión y una retrospectiva al final. Ese es Scrum Es ritmo fijo con roles claros y un compromiso cada sprint. Entonces Scrum es brillante en las condiciones adecuadas, y aquí es cuando funciona maravillosamente Primero, cuando tu trabajo se puede planificar un sprint adelante, si puedes decidir con sensatez el lunes qué construirás en la próxima quincena, y esa decisión se mantiene mayormente, Scrum te da un ritmo muy cómodo En segundo lugar, cuando el trabajo encaja en piezas del tamaño sprint, construir una nueva característica para nuestra aplicación de aprendizaje de idiomas para niños, por ejemplo, como un conjunto de cuestionarios de vocabulario, se descompone muy bien en historias que puedes terminar dentro de un Y ese es el territorio ideal de Scrum. Tercero, cuando tus stakeholders valoran la previsibilidad, la cadencia fija significa que todos saben habrá algo que ver al final de cada sprint Para una parte interesada nerviosa, ese latido cardíaco regular es muy tranquilizador Y cuarto, cuando el equipo es estable y dedicado, Scrum asume un grupo consistente de personas enfocadas en un solo producto Cuando eso es cierto, el equipo construye un ritmo y un sentido de ritmo compartido. Echemos un vistazo a dónde lucha el framework Scrum. Entonces Scrum empieza a pelear contigo en algunas situaciones comunes. El primero es el trabajo impulsado por interrupciones. Si tu día está dominado por cosas urgentes que llegan de manera impredecible, como problemas de soporte o incidentes en vivo, la idea de comprometerse con un plan fijo por dos semanas simplemente se desmorona El plan está desactualizado para el martes. El segundo es que el trabajo no se quedará quieto. Si las prioridades realmente cambian varias veces a la semana, no porque tus stakeholders estén siendo difíciles, sino porque la situación es realmente así de fluida, entonces una planificación de sprint se convierte una ficción que terminarás reescribiendo constantemente El tercero es el trabajo que no encaja en el cuadro sprint. Algunas tareas son diminutas y constantes. Algunos son grandes y lentos. Si tu trabajo es un flujo desordenado de tamaños tremendamente diferentes, forzarlo a compromisos ordenados de dos semanas crea más fricción que Y la cuarta es cuando las ceremonias se sienten huecas. Si tu chequeo diario se ha convertido en un reporte de estado a un gerente y tu retrospectiva produce las mismas quejas cada quincena sin que nada cambie, el marco ha dejado de atenderte Entonces echemos un vistazo a algunas señales de advertencia de que Scrum está peleando ¿Cómo sabes que Scrum es el que encaja mal? Échale un vistazo a estos signos delatadores. Firme uno, llevas refacciones al final de casi todos los sprint El derrame ocasional es normal, pero si las historias inacabadas ruedan en el siguiente sprint una y otra y otra vez, tu compromiso no significa nada Firme dos, la planificación se siente como teatro. Pasas por los movimientos de planeación de sprint, pero todos saben que el plan será destrozado en cuestión de días Si nadie confía en el plan, entonces ¿por qué lo haces en primer lugar? Firmar tres. Los cambios llegan constantemente a mediados del sprint, y sigues dejándolos entrar. Scrum está destinado a proteger el sprint. Si estás renegociando el sprint cada dos días, realmente no tienes Firme cuatro, el equipo teme las ceremonias. Las reuniones que agregan valor no se resentirán. Los encuentros que se han convertido en rituales hacen. El tamaño de tu equipo en el sitio de otra sesión de planeación, es decir, los datos. Ninguna de estas señales significa que fracasaste. Significan que la herramienta y el trabajo han dejado de coincidir, y eso vale la pena tomarlo en serio. Entonces Scrum, de ninguna manera es la única manera. Entonces aquí hay cosas que muchos equipos extrañan. Scrum no es Ágil. Scrum es una forma de ser Ágil. Agile es la mentalidad, entregar valor temprano, responder al cambio y mejorar continuamente Scrum es un conjunto popular de prácticas que respalda esa mentalidad No es el único. Si Scrum se ajusta a tu proyecto, maravilloso. Úsalo bien. Pero si has estado asintiendo a lo largo de las señales de advertencia, es otro enfoque que maneja el trabajo impredecible, fluido, impulsado por interrupciones mucho mejor Se llama Kanban, y es a donde vamos a continuación. Entonces Scrum es un framework muy poderoso, pero sólo cuando el trabajo le conviene. Saber cuándo no es un signo de madurez y no de fracaso. Gracias por acompañarme en esta lección. En la siguiente, profundizaremos en Kanban, cómo utiliza los límites de flujo y progreso de trabajo para manejar exactamente el tipo de trabajo con el que Scrum lucha. Te veré ahí. 13. Inmersión profunda en Kanban: límites y flujo de WIP: Bienvenida de nuevo. En esta lección, vamos a profundizar en Caban, el enfoque basado en el flujo para gestionar el trabajo. Si Scrum se trata de ritmo y compromiso, Cam Ban se trata de flujo y límites Al final de esta lección, entenderás cómo se ve una placa Cam Ban, qué son los límites de progreso de trabajo y por qué hacer menos deliberadamente a la vez puede ayudarte a entregar más. Vamos a meternos en ello. Entonces Camban viene de fabricación japonesa donde significa una señal visual o tarjeta En nuestro mundo, es una forma de gestionar el trabajo como un flujo continuo más que en sprints fijos No hay sprints en Cam Ban. No hay compromiso con un lote de trabajo de dos semanas. En cambio, el trabajo fluye en todos los ámbitos de izquierda a derecha, un elemento a la vez, y el equipo realiza nuevos trabajos cada vez que tienen la capacidad de asumirlo. Y ese es el corazón de ello. Camban tiene tres prácticas básicas. Visualiza tu trabajo limita cuánto trabajas a la vez y gestiona el flujo para que el trabajo siga en movimiento. Tomaremos cada uno de esos a su vez. Entonces primero, comienza con la visualización de la obra. Un tablero Cam Ban es un conjunto de columnas, y cada columna es una etapa por la que pasa la obra. Aquí hay un típico tablero de cinco columnas para nuestra aplicación de aprendizaje de idiomas para niños. En el extremo izquierdo, tenemos el atraso, todo lo que podríamos hacer en orden de prioridad A continuación, para hacer el pequeño conjunto de cosas que están listas para ser recogidas. Entonces en curso, en lo que se está trabajando activamente en este momento, luego revisar el trabajo que está hecho y está a la espera de ser revisado y finalmente hecho, lo que significa terminado y verificado. Cada pieza de trabajo es una tarjeta y se mueve hacia la derecha a través de esas columnas a medida que De un vistazo, cualquiera puede ver exactamente dónde está todo, y esa visibilidad por sí sola vale mucho. Pero el verdadero poder de Camban viene del siguiente. Que son los límites de progreso de trabajo. Así que mira de nuevo a la pizarra. Observe los pequeños números en las dos de las columnas. En curso tiene un límite de tres. La revisión tiene un límite de dos. Estos son límites de progreso de trabajo o límites de WIP para cortos WIP solo significa progreso de trabajo. Todo lo que empezaste pero aún no terminaste. Un límite de trabajo en curso es un límite cuántos elementos pueden haber en una columna a la vez Si un límite en progreso tiene un límite de tres, el equipo puede tener como máximo tres cosas en las que se trabaja activamente, no cuatro, no diez. Tres. Ahora bien, esto es lo que eso significa en la práctica. Si en progreso está lleno y terminas una tarjeta, no empiezas algo nuevo de para hacer de inmediato Primero, miras si algo está atascado y ayudas a que siga adelante. Solo haces trabajo fresco cuando realmente hay espacio para ello. El límite enfoca al equipo a terminar las cosas antes de comenzar cosas nuevas. Ahora bien, esto se siente un poco contrario a la intuición al principio, tal vez Seguramente, hacer más cosas a vez significa hacer más cosas, pero realmente es todo lo contrario, y vale la pena entender por qué. Entonces, ¿por qué menos es más? Tres razones por las que limitar el trabajo en progreso te hacen más rápido, no más lento. El primero, menos conmutación. Cada vez que haces malabares con otra tarea, pagas un costo para cambiar entre ellas. Pierdes tu lugar, recargas el contexto, cometes más errores Un equipo con cinco cosas sobre la marcha cambia constantemente. Un equipo con tres acabados cada uno antes. Segundo, los cuellos de botella se hacen visibles. Cuando la revisión se limita a dos y se llena, trabajo deja de fluir hacia ella. Eso no es un problema que esconder. Es sólo una señal. Te dice exactamente dónde está el atasco para que el equipo pueda pulularlo y despejarlo. Sin límites, el trabajo simplemente se amontona de manera invisible. Y tres, acabados de trabajo, una tarjeta sentada medio hecha entrega, nada. Sólo es valioso cuando está terminado y está en manos de alguien. Limitar el trabajo y el progreso empuja al equipo a impulsar todas las cosas hasta el final en lugar de comenzar lotes y terminar poco. Incluso una ley ruda detrás de esto. Cuantas más cosas tengas en progreso a la vez, más tardará cada una en terminar. Menos cosas en vuelo equivale a entregas más rápidas, y ese es todo el juego de Caban. Así que jala no empujes. Esto le da a Caban su ritmo definitorio. Tire, no empuje. En un sistema push, se te entrega el trabajo ya sea que estés listo o no. Tu taco solo crece. En un sistema pull, solo asumes nuevo trabajo cuando tienes la capacidad para ello. Los límites de WIP lo hacen cumplir automáticamente. Cuando una columna tiene espacio, se introduce el siguiente elemento. Cuando está lleno, no lo haces es la diferencia entre una cocina donde los pedidos se apilan más rápido de lo que los cocineros pueden manejar y otra un nuevo pedido solo se inicia cuando un cocinero es gratis Pull mantiene todo el sistema fluyendo a un ritmo sustentable. Entonces el cambio de mente en el corazón de Cam Ban es el flujo, no el compromiso. Cam Ban te dice que te concentres en el flujo, no en un compromiso de sprint, sino en el flujo y el movimiento suave y constante del trabajo de izquierda a derecha. No hay sprints, no pregunta a qué nos comprometeremos en esta quincena Usted pregunta, trabajo fluyendo bien, y ¿dónde se queda atascado? Mides cosas como el tiempo que tarda una tarjeta en cruzar el tablero de principio a fin, y volveremos a esas mediciones de flujo correctamente más adelante en el curso. Por ahora, la mentalidad del cambio de mentalidad es la parte importante, desde comprometerse con un lote hasta mantener un flujo constante Ahora bien, es por eso que Cam Ban se adapta a un trabajo impulsado por interrupciones e impredecible en constante cambio tan bien. No hay un plan fijo para volar. Ahí está la siguiente cosa más importante. Se tiró cuando hay espacio para ello. Entonces Caban es engañosamente simple. Visualizas el trabajo, limitas el trabajo en progreso y lo mantienes fluyendo. Pero esas pocas ideas pueden transformar la forma en que un equipo cumple. Gracias por acompañarme en esta lección. En la siguiente, construiremos una verdadera placa Cam Ban juntos en Trello paso a paso, para que veas exactamente cómo se todo. Te veré ahí. 14. Configurar un tablero Kanban en Trello: Bienvenida de nuevo. En esta lección, vamos a construir una placa Cam Ban desde cero en Trello. Entonces Trello es gratis Se ejecuta en tu navegador, y todo lo que hacemos hoy funciona en el plan gratuito sin funciones de pago y sin necesidad de complementos. Entonces, al final de esta lección, tendrás un cambabard de cinco columnas para tu proyecto, completo con límites de progreso de trabajo Entonces comencemos. Rápidamente, echemos un vistazo a lo que vamos a construir. Aquí está el plan. Vamos a crear un tablero con cinco listas, izquierda a derecha, backlog para hacer en progreso, revisar y listo Dos de esas listas en curso y revisión tendrán límites de trabajo en progreso, que limitan cuántas tarjetas pueden sentarse en ellas en el. Te lo explicaré paso a paso, y luego te mostraré cómo debería ser en Trello cómo debería ser en Trello Entonces, antes que nada, la convención de límites WIP. Aquí está una de las desventajas de la cuenta gratuita de Trello. No hay una función incorporada que le impida físicamente agregar una cuarta carta a una columna limitada a tres. Entonces, en cambio, usaremos una convención simple pero confiable que no use nada. Simplemente pondremos el límite justo en el nombre de la lista. Entonces, en lugar de llamarlo en progreso, se llamará en progreso WIP tres Entonces echemos un vistazo a cómo debería ser el tablero. Entonces tienes tu atraso. He añadido cuatro cartas a esta. Tiene que ver con una tarjeta, tengo a Ding, que tiene un límite de avance de trabajo de tres. Ahí dentro hay tres cartas. Tenemos revisión con un límite de avance de trabajo de dos, y ahí hay dos tarjetas, y tengo una columna hecha con dos tarjetas más ahí dentro. Eso es. Esa es una simple tabla de Caban. Entonces muy rápido, las etiquetas y el jalar funcionan, esta es probablemente la parte más importante de cualquier tablero Caban. Cuando el equipo esté listo para comenzar algo, deben arrastrar la tarjeta de hacer a en progreso o para hacer. Vigila el límite. En progreso se limita a tres. Entonces, antes de que alguien arrastre una cuarta carta, se detienen y preguntan, podemos terminar o bloquear algo que ya está aquí primero, y el trabajo se mueve de izquierda a derecha, un tirón a la vez, y solo se mueve a una columna cuando esa columna tiene la habitación Entonces, por ejemplo, podemos mover la insignia de progreso de derecha a izquierda de la acumulación a hacer Es tan sencillo como eso. Es una app muy intuitiva. Es muy sencillo de usar, Trello, por suerte. Pero nuevamente, Caban es un concepto bastante sencillo. Antes de que terminemos algunos errores comunes para recordar, primero, no te saltes el límite. Un tablero sin límite de progreso de trabajo es básicamente una lista elegante con columnas adicionales. El límite de progreso laboral es un concepto de Caban, así que no se lo saltes o de lo contrario ya no es una junta Caban. Dos, dejar que el trabajo hecho se convierta en un cementerio. Así hecho realmente significa terminado y verificado. Si no se verifica, tiene que permanecer en revisión, y solo debe moverse cuando haya sido verificado y aprobado por el propietario del producto o el gerente del proyecto. Y por último, demasiadas columnas. Entonces cinco es suficiente para comenzar. No es necesario agregar una columna por cada pequeño paso. Solo agrega una etapa más tarde si realmente falta una real, o de lo contrario las columnas adicionales crearán un trabajo ocupado, y también hará que el tablero sea un poco más confuso. Entonces, entonces eso es todo. Hemos echado un vistazo a cómo construir un cambmbard simple desde cero Es un concepto muy sencillo. Es algo muy sencillo de construir en Trello, también. En el plan gratuito, es muy, muy fácil de hacer. En las cuentas profesionales, sí obtienes los límites de WIP para cada columna, y también obtienes obviamente algunas otras características también en la cuenta paga Entonces, en la siguiente lección, veremos los modelos híbridos, que es un poco de ambos. Entonces una mezcla de Scrum y Caban, que también se conoce como Scrumban, y la adaptaremos a Agile para que se ajuste a cómo funciona realmente tu equipo Entonces eso es lo siguiente. Gracias por acompañarme en esta lección. Te veré en la siguiente. 15. Modelos híbridos: enfoque Scrumban y adaptado.: Bienvenido de nuevo. En esta lección, vamos a hablar de híbridos, mezcla y emparejamiento de prácticas ágiles para adaptarse a tu equipo En particular, veremos Scrumban, la mezcla más popular de Scrum y Entonces, al final, entenderás qué es Scrumban cuando ayuda y la única regla que evita que los enfoques híbridos se conviertan en un completo desastre Empecemos con un punto de mentalidad. Scrum y Cam Ban no son religiones. Son kits de herramientas. Nadie te entrega una medalla por seguir un marco a la perfección, y nadie sensato te dirá que tu forma de trabajar está equivocada solo porque tiene un poco de ambos en él. Los equipos reales se enfrentan a situaciones reales y específicas, a veces los ajustes puros de Scrum, a veces los ajustes puros de Caban, y muy a menudo, el mejor ajuste está en algún punto intermedio El ritmo de Scrum con el control de flujo de Camban que entre el espacio es donde viven los híbridos, y el más común tiene nombre Scrumban es exactamente como suena Scrum más Caban. Mantienes parte de la estructura útil de Scrum y agregas las herramientas de flujo de Cam Ban En la práctica, un equipo de Scrumban suele mantener una cadencia regular, como un ritmo de dos semanas y mantiene las ceremonias útiles, como una conversación de planificación y una retrospectiva Pero en lugar de comprometerse un lote fijo de trabajo durante las dos semanas completas, corren en una placa estilo Cam Ban con límites de progreso de trabajo, y extraen nuevos trabajos continuamente a medida que la capacidad se libera Entonces obtienes el latido del corazón y el ritmo de Scrum con la planificación regular y la reflexión, junto con la flexibilidad de Cam Ban, el flujo basado en pull que hace frente al cambio Para muchos equipos, esa combinación es el verdadero punto óptimo. Entonces, cuando Scrumban realmente ayuda, cuándo deberías alcanzar Hay tres situaciones comunes. Primero es cuando tu equipo quiere un ritmo, pero tu trabajo es impredecible. Digamos, por ejemplo, a nuestro equipo de aplicaciones de aprendizaje de idiomas le gusta reunirse cada dos semanas para planificar y reflexionar, pero la mitad de su trabajo son correcciones de errores urgentes que llegan sin previo aviso. Scrumban les permite mantener el ritmo quincenal mientras manejan las interrupciones a través de una tabla a través En segundo lugar, cuando te mueves de Scrum hacia Cam Ban, cambiar el pasillo de trabajo de un equipo durante la noche es discordante Scrumban es un puente suave. Mantienes las ceremonias familiares mientras presentas límites de progreso laboral y tiras, y el equipo se ajusta gradualmente. En tercer lugar, cuando el compromiso de Scrum sigue cayendo pero no quieres perder su estructura, si llevas entrenamiento a lo largo de cada sprint, pero perderías la planificación en la retrospectiva, Scrumban te permite dejar caer el compromiso rígido mientras mantienes las partes que realmente estaban ayudando en Así que la sastrería más allá de Scrumban, Scrumban es el famoso híbrido, pero la sastrería Aquí hay algunos otros ajustes sensatos que los equipos a menudo. Puedes ejecutar Scrum pero agregar límites de progreso de trabajo a tu tabla, que el equipo termine de trabajar antes de comenzar más, incluso dentro de un sprint Puedes ejecutar Cam Ban pero agrega una ligera cadencia regular, como reseña corta todos los viernes Por lo que las partes interesadas aún un momento predecible para ver el progreso, y puedes dejar caer las ceremonias muertas que no se están ganando su sustento. Si tu check in diario realmente no agrega nada un pequeño equipo coubicado que ya habla constantemente, entonces está bien hacerlo dos veces por semana y ver qué pasa. El punto es mantener lo que ayuda y quitar silenciosamente lo que no ayuda. Entonces hay una regla, que es sastre deliberadamente. Esto mantiene todo esto saludable. Cambiar las cosas deliberadamente e inspeccionar el resultado. Hay una gran diferencia entre la sastrería y la deriva. La sastrería es una decisión consciente. Estamos dejando caer el compromiso fijo porque sigue fallando, y registraremos una vez al mes donde el flujo ha mejorado. Drift es simplemente abandonar silenciosamente las partes duras porque se sienten incómodas sin ningún plan y sin revisión Así que cada vez que ajustes tu proceso, haz tres cosas. Nombra el cambio, acuerde por qué estás haciendo el cambio y establece una hora para mirar atrás y preguntar si realmente ayuda. Si lo hizo, guárdalo, si no lo hizo, entonces vuelve a cambiar. Ese hábito y cambiar a propósito e inspeccionar el resultado es Ágil en sí mismo El marco es solo el punto de partida, pero Ágil es la mentalidad Entonces híbridos como Scrumban on son de compromiso. No es un policía fuera. Cuando se hacen deliberadamente, a menudo son los más honestos para que nuestro equipo realmente funcione. Gracias por acompañarme en esta lección. En la siguiente, pondremos todo esto junto y resolveremos cómo elegir el marco adecuado para tu propio proyecto. Te veré en la siguiente. 16. Cómo elegir el marco adecuado para tu resumen: Bienvenido de nuevo. Hemos mirado a Scrum a Camban y a modelos híbridos como Ahora, la pregunta práctica, ¿cómo eliges realmente? En esta lección, te daré un breve conjunto de preguntas para hacerte sobre cualquier proyecto, y luego trabajaremos juntos a través de ellas para nuestra aplicación de aprendizaje de idiomas para niños para que podamos aterrizar en una recomendación real. Entonces, antes que nada, no hay una respuesta universal. Matemos ese mito desde el principio. Cualquiera que te diga que Scrum siempre tiene razón o que Cam Ban siempre tiene razón te está vendiendo algo El marco adecuado depende completamente de su contexto, el tipo de trabajo que realice, cuán predecible es y lo que necesitan sus grupos de interés. El mismo equipo podría usar Scrum para un proyecto y Cam Ban para otro Entonces, en lugar de elegir favoritos y obligar a tu trabajo a encajarlo, comenzamos con preguntas sobre el trabajo y dejamos que las respuestas nos apunten a un marco correcto. Aquí están las cuatro preguntas que más importan. Pregunta uno, ¿su trabajo es planificable o impulsado por interrupciones? ¿Puedes decidir con sensatez un par de semanas de trabajo por adelantado o constantemente llegan cosas urgentes y reorganizar todo? Pregunta dos, ¿tu trabajo encaja en piezas del tamaño sprint? ¿Tus tareas son de un tamaño bastante uniforme que termina dentro de una quincena, o son una mezcla salvaje de pequeñas y enormes? Pregunta tres, ¿ sus grupos de interés necesitan fechas predecibles? ¿Dependen en saber que algo se envía a un ritmo fijo, o en su mayoría solo quieren un flujo constante de progreso? Pregunta cuatro, ¿la prioridad es estable dentro de una ventana corta? Una vez que estás de acuerdo en lo que es importante esta quincena, ¿se sostiene o realmente cambia cada pocos días En términos generales, muchos planificables, de tamaño uniforme, predecibles y estables te apuntan hacia Scrum Un montón de interrupciones impulsadas, tamaño mixto, flujo constante y siempre cambio te apunta hacia Camban. Una mezcla te apunta hacia Scrumban. Bien, aplicándolo a nuestra app de aprendizaje de idiomas para niños a través de esas cuatro preguntas. Pregunta uno, planificable o impulsada por interrupciones. Esta aplicación es en su mayoría planificable. Estamos construyendo características como cuestionarios e insignias de progreso que pueden decidir sobre las que podemos decidir con anticipación Pero hay algunos bichos. También hay un goteo constante de correcciones de errores de los usuarios en vivo, por lo que en su mayoría es planificable pero con Pregunta dos, ¿las tareas se ajustan a piezas del tamaño sprint? Sí, en gran parte un cuestionario de vocabulario, una placa, correo electrónico de resumen. Cada uno de estos se descompone en historias que podemos terminar en una quincena Pregunta tres, ¿las partes interesadas necesitan fechas predecibles? Sí. Nuestros grupos de interés, incluidos los padres y el negocio en general, como la tranquilidad de ver algo nuevo a un ritmo regular La cuarta pregunta es prioridad estable dentro de una quincena, en su mayoría, pero no perfectamente, un error desagradable que afecta a niños reales que aprenden puede saltar en la cola Por último, tenemos el veredicto. Entonces, ¿cuál es el veredicto para nuestra aplicación? Las respuestas se inclinan hacia Scrum. El trabajo es en su mayoría planificable de tamaño sprint, y las partes interesadas valoran el ritmo Pero ese goteo de correcciones de errores urgentes significa que Scrum puro se vería interrumpido. Entonces el mejor ajuste aquí es Scrum con un toque de disciplina Cam ban. Entonces prohibición de Scrum Mantenemos el ritmo quincenal, mantenemos la planeación y la retrospectiva porque se adaptan a la obra, y también tranquilizan a las y también tranquilizan Pero manejamos una junta con límites de progreso de trabajo, y reservamos un poco de capacidad cada quincena para las correcciones urgentes que sabemos que llegarán No. Haz lo mismo para tu propio proyecto. Responde las cuatro preguntas honestamente. No escojas el framework porque te gusta el sonido del mismo o porque lo prefieres. Escoge el que apunte las respuestas. Y recuerda, siempre puedes ajustarlo más tarde, deliberadamente a medida que aprendes. Bien, ahora, elegir un marco no se trata de moda o de dogma Se trata de hacer coincidir la herramienta el trabajo que está justo frente a ti. Responde las preguntas y sigue a dónde llevan y mantente dispuesto a cambiar de opinión. Gracias por acompañarme en esta lección. En la siguiente lección, pondrás en práctica todo este trabajo y tú mismo convertirás tu proyecto en una placa Cam Ban. Te veré ahí. 17. Práctica: convierte tu proyecto en Kanban.: Mm. Bienvenida de nuevo. Esta es una lección de práctica, así que es tu turno de hacer algún trabajo. Vamos a tomar un proyecto que ha estado funcionando como sprints y convertirlo en una tabla Cam Ban fluida en Trello Todo funciona en la versión gratuita de Trello. No se necesitan funciones de pago. Bien, esto es lo que vas a hacer. Toma tu tablero existente, guarda las tarjetas que ya has escrito y reestructura las listas en un flujo Caban Agregar límites de progreso de trabajo a las columnas activas. Luego reordene su trabajo atrasado por prioridad y verifique que el trabajo pueda fluir sin problemas de izquierda a derecha Lo siguiente es establecer los límites. Recuerda, Trello gratis no hará cumplir estas listas por ti, así que usamos la convención de nomenclatura Cambiar el nombre de hacer a hacer WIP tres. Los límites ahora son visibles para todo el equipo. Por último, asegúrate de ordenar también tu backlog y arrastra la tarjeta más importante a la parte superior, ordena el resto por debajo de ella por prioridad Y luego verificar la cordura para que fluya. ¿Hay una tarjeta transparente lista para entrar o hacer? ¿Algo está atascado? Una tabla de prohibición de Cam saludable tiene trabajo que fluye constantemente hacia la derecha, y ninguna columna reventando más allá de su límite. Entonces, qué aspecto bueno se ve. Cuando hayas terminado de convertir tu placa, compruébalo con estas tres cosas. Tus listas mapean el escenario real medida que pasa tu trabajo. Tus columnas activas tienen límites visibles de progreso de trabajo, y tu acumulación se ordena de arriba hacia abajo con el trabajo más importante en la parte superior Si los tres son ciertos, tienes una placa Cam Ban en funcionamiento. Muy bien hecho. Ahora has llevado un proyecto de sprint a flow y tienes una placa Cam Bn que en realidad puedes ejecutar. Gracias por acompañarme. En la siguiente lección, nos dirigiremos a las personas que rodean tu proyecto y comenzaremos a mapear y administrar tus grupos de interés. Te veré ahí. 18. Identifica y mapea a tus partes interesadas.: Bienvenido de nuevo. En esta lección, vamos a ver a las personas que rodean tu proyecto. Cada proyecto tiene partes interesadas, las personas que se ven afectadas por lo que construyes o que pueden afectarlo, y hacerlos bien suele ser la diferencia entre un proyecto fluido y uno doloroso. Al final de esta lección, sabrás cómo encontrar a todos tus grupos de interés, cómo ordenarlos por cuánto importan y cuánta atención necesita realmente cada uno. Entonces, ¿quién es un stakeholder? Empecemos con la definición porque es más amplia de lo que la mayoría de la gente piensa. Un stakeholder es cualquiera que tenga una participación en lo que construyes. Se ven afectados por el desenlace o pueden darle forma, y muy a menudo son ambos. Algunos están dentro del equipo, las personas que construyen el producto, más el propietario de su producto y su Scrum Master, pero la mayoría están fuera de él Entonces tu patrocinador que paga por el trabajo a los usuarios por nuestra app de aprendizaje de idiomas para niños, eso significa los niños, pero también sus padres y sus maestros. Y los que son fáciles de pasar por alto son el personal de soporte y las personas legales o de cumplimiento de las que solo escuchas cuando algo sale mal Si el trabajo los toca, son un stakeholder. Antes de que puedas gestionar a los stakeholders, tienes que encontrar quiénes son, y el objetivo es no perder a nadie. Hay dos preguntas sencillas que surgen casi todos. Primero, quién se ve afectado, quién usa el producto, quién lo paga, lo apoya, o tiene que convivir con el resultado. Segundo, ¿quién nos puede afectar? Quién puede acelerarte, ralentizarte, financiarte o bloquear una liberación. Entonces tercer aviso porque estos son los que te muerden después. Quién es fácil olvidar a las partes interesadas silenciosas. Ustedes los usuarios finales que rara vez se sientan en sus reuniones, su equipo de soporte, esa persona de cumplimiento que no dice nada desde hace meses, y luego en el peor momento, dice que no, anota a todas estas personas. Se puede administrar un nombre en tu lista. Un stakeholder del que te olvidaste no puede ser manejado. Ahora una larga lista no es un plan. No puedes darle a todos la misma cantidad de atención, y realmente no deberías intentarlo. Entonces los ordenamos usando una herramienta simple y muy conocida, la red eléctrica y de interés. Imagínese un cuadrado dividido en cuatro. Lo vertical como eje es el poder, cuánta influencia tiene esta persona sobre el proyecto. El acceso horizontal es interés, cuánto les importa. Esto te da cuatro grupos, y cada uno quiere manejarlo de manera diferente. Arriba a la derecha es alta potencia y alto interés. Gestionar de cerca a estas personas. Ellos son tus actores clave, así que involúcralos a menudo. Arriba a la izquierda es de alta potencia, pero menor interés. Mantén satisfecha a esa gente. Manténgalos felices y tranquilos, pero no los ahogues en detalle que no quieran Abajo a la derecha es menor potencia, pero alto interés. Manténgalos informados. Les importa mucho, así que manténgalos informados. Y abajo a la izquierda es baja potencia y bajo interés. Tan solo vigila a estas personas. Un toque ligero es suficiente. Así que hagamos todo eso concreto con nuestra aplicación de aprendizaje de idiomas. Su jefe de producto tiene tanto poder como gran interés. Entonces van en la parte superior derecha. Administras de cerca y los involucras en tus revisiones y tu plan el fundador de la compañía controla el presupuesto, pero no está en el día a día, por lo que están arriba a la izquierda, mantenlos satisfechos, pero ahorrarles el detalle. Los maestros y los padres tienen poco poder formal sobre tu hoja de ruta, pero les importa enormemente Por lo que van en la parte inferior derecha, los mantienen informados, y legal y cumplimiento se sientan en monitoreo durante la mayor parte del proyecto, baja participación, pero tenga en cuenta la captura, nunca deben sorprenderse. Un actor silencioso aún puede detener una liberación. Entonces, ¿qué obtiene realmente cada grupo de ti? Empareja el esfuerzo el cuadrante y gastarás tu energía donde cuente Gestionar de cerca significa contacto frecuente y de dos vías. Están en la habitación en las revisiones y planeación. mantiene satisfecho, significa un resumen breve y regular, además de un aviso temprano antes de cualquier gran decisión. Mantenerse informados significa una simple actualización que pueden leer cuando quieran, y crucialmente, no tener reuniones Estás informando, no consultando, y monitor significa un toque ligero solo una palabra rápida cuando algo realmente los afecta y nada de otra manera. Si haces esto bien, pasarán dos cosas importantes partes interesadas se sentirán debidamente atendidas y dejarás verter horas en las personas que ni las necesitan ni quieren. Entonces sí, muy importante considerar cuánto y con qué frecuencia. Así que encuentra a todos, ordenalos por poder e interés y dale a cada grupo la cantidad correcta de atención. Ese mapa es la base de todo lo demás en esta sección específica. Gracias por acompañarme. En la siguiente lección, tomaremos a tus partes interesadas más importantes y les mostraremos el trabajo real realizando una revisión de sprint que realmente valoran . Te veré ahí. 19. Realizar una revisión de Sprint productiva.: Bienvenido de nuevo. En esta lección, vamos a realizar una revisión de sprint, que es la reunión al final de un sprint en la que muestras tus stakeholders lo que has construido y recabas sus comentarios. Si esto se hace bien, puede convertirse en una de las medias horas más valiosas de todo tu proceso. Pero si se hace mal, se vuelve como una aburrida reunión de actualización de estado que nadie quiere asistir. Entonces, al final de esta lección, sabrás cómo ejecutar una revisión de sprint que te gane confianza y que realmente te dé retroalimentación que puedas usar. Entonces, aclaremos para qué sirve una revisión de sprint porque aquí es donde algunas personas pueden equivocarse. La revisión de Sprint está mostrando un producto de trabajo real. Es una mirada en vivo a lo que se construyó. A este sprint le siguió una conversación honesta sobre cómo le fue. Lo que no es es una presentación de diapositivas, y no es una ceremonia de firma, y no es una ceremonia de estampación de goma. La antigua frase ágil es software de trabajo sobre documentación completa. Y la revisión es donde estás a la altura de eso. Tú mostraste la cosa, no una cubierta de diapositivas sobre la cosa. El punto es la retroalimentación sobre la que puedes actuar, no algunos aplausos Gran revisión necesita unos 10 minutos de preparación. Y hay tres cosas principales. Primero, prepara la demo. Tenga la función de trabajo lista en un dispositivo real y pruebe primero el camino feliz para que no esté depurando en vivo frente a su patrocinador Segundo, invitar a las personas adecuadas, los grupos de interés que se preocupan por este trabajo en particular, a toda la empresa. Y tercero, establece un objetivo, conoce la pregunta única que más quieres que se responda para cuando la habitación se vacíe. A lo mejor el nuevo cuestionario se siente bien para un maestro o algo así, entra, sabiendo lo que estás ahí para aprender. Entonces aquí hay una agenda rápida y sencilla que funciona, y es solo cuatro pasos, y será aproximadamente media hora en total. Uno es recapitular el gol sprint en una sola línea. ¿Qué nos propusimos hacer este sprint? Dos, es demo el trabajo, muéstralo en vivo y donde puedas, déjalos probarlo ellos mismos. número tres, es invitar a comentarios, hacer preguntas abiertas y luego escuchar mucho más de lo que hablas. Número cuatro, platicar brevemente sobre los siguientes pasos. Qué significa para el plan lo que acabamos de ver , y eso es todo. Resumen, demostración, comentarios y sus próximos pasos. Si tomas un hábito de esta lección, toma este. Demo, no presentes. Muestra lo real en un dispositivo, no hables de ello en una diapositiva. Un cuestionario de trabajo, por ejemplo, que su parte interesada realmente puede aprovechar late diez viñetas describiéndolo cada vez. No hay dónde esconderse en una demostración en vivo, y ese es exactamente el punto. Mantiene a todos honestos sobre lo que realmente se hace. Dos cosas hacen que una tierra de demostración, Que conduzcan, entreguen el dispositivo y vean donde dudan, donde persona real hace una pausa o frunce el ceño vale más que cualquier informe de estado, y omita el pulido Rudo pero real late slick pero falso. No estás vendiendo, estás aprendiendo. Mostrar lo que realmente funciona, qué y así cuando llegue el feedback y lo hará, tres hábitos lo mantienen útil. Primero, capta los comentarios, no defiendas, escríbalos y resiste el poderoso impulso de explicar por qué se equivocan. Tú pediste su opinión, así que déjalos que se la den. En segundo lugar, están los cambios en el alcance del parque. Cuando alguien dice, Oh, ¿ podría también hacer esto? Esa es una gran idea para el backlog, no un cambio en este sprint Así que anotarlo, agradecerles y seguir adelante. Tercero, agradecerles genuinamente. La gente que se presenta y habla realmente te está haciendo un favor incluso cuando duelen los comentarios, especialmente entonces en manejar la habitación así, y la gente se va sintiéndose escuchada, lo que significa que volverán y te dirán la verdad la próxima vez, también. Entonces una buena revisión de sprint es simple, de verdad. Muestre algo de trabajo real, escuche muy bien y luego actúe según lo que escuche. Así que gracias por acompañarme en esta lección. En la siguiente, nos ocuparemos de lo que sucede cuando los comentarios cambian el plan y cómo absorber los requisitos cambiantes sin perder el enfoque. Te veré en la siguiente. 20. Cómo gestionar los cambios en los requisitos: Bienvenido de nuevo. En esta lección, vamos a abordar algo a lo que se enfrenta cada proyecto. Los requisitos cambian. Un stakeholder quiere algo nuevo, un usuario hace algo que no esperabas, así que las prioridades cambian. En un proceso rígido, un cambio como este es crisis, pero en Ágil, es normal. Sin embargo, existe una habilidad real absorber el cambio sin tu proyecto descienda al caos, y esa habilidad es lo que veremos en esta lección. En primer lugar, se permite un cambio de mentalidad en Agile, cambiando de opinión Incluso se espera y se alienta. El objetivo de trabajar en ciclos cortos y mostrar productos reales es que aprendas cosas, y aprender debería cambiar lo que haces a continuación. Entonces el objetivo no es congelar el plan y defenderlo. El objetivo es cambiar el plan a propósito deliberadamente en lugar de entrar en pánico cada vez que alguien te envía una nueva idea por correo electrónico. Acoger con beneplácito el cambio y perder el control no son lo mismo, y esta lección trata sobre esa diferencia clave. Por lo que ayuda saber de dónde tiende a provenir el cambio porque ninguna de estas fuentes es un fracaso de tu parte. Es solo la realidad. Las partes interesadas cambian de opinión una vez que ven el trabajo. A menudo solo descubren lo que realmente quieren cuando miran lo que tienen. Los usuarios reales se comportan de manera diferente a como adivinaste que lo harían El mercado se mueve, un competidor envía algo más, una regla cambia, una prioridad cambia por encima de ti y tu propio equipo aprende a medida que construye, y el último importa información no es un error en tu plan Es la razón por la que planeas en ciclos cortos en primer lugar. Entonces, ¿dónde debería aterrizar realmente todo este cambio en tu atraso? Piense en el atraso como el amortiguador que detiene cada nueva solicitud sacudiendo todo el proyecto Entonces tres pasos. Primero, capturarlo con calma. Una nueva solicitud se convierte en una nota sobre el atraso, no en un giro U instantáneo Segundo, no actúes sobre el reflejo. Casi nada tiene que cambiar este mismo segundo. Deja que el polvo se asiente antes de hacer un movimiento. Tercero, deje que el propietario del producto vuelva a priorizar. El propietario del producto o la orden de compra pesa la nueva solicitud contra todo lo demás que está esperando y decide dónde se encuentra realmente. Ese es su trabajo, y protege al equipo de ser tirado por ahí por quien gritó algo más recientemente Entonces, la forma en que absorbas un cambio depende un poco de qué framework estés usando, y cubrimos ambos anteriormente en este curso. Entonces en Scrum, proteges el sprint actual. Nuevo trabajo esperará a la próxima sesión de planeación. El compromiso de hoy se mantiene intacto, por lo que el equipo en realidad puede terminar lo que comenzó. En Cam Ban, no hay sprint que proteger, así que simplemente reordenas la cola Puedes colocar el nuevo trabajo en la prioridad correcta y respetar tus límites de progreso laboral, que son los límites de cuánto progreso puede estar en progreso simultáneamente. Las herramientas difieren, pero el principio es idéntico. El cambio se maneja deliberadamente en un momento sensato, no dejando caer todo el instante en que llega una nueva solicitud. Aquí tienes una sola frase que te ahorrará más proyectos que casi cualquier otra cosa. Di sí al qué y negocia el cuándo. Di sí a la idea, entonces sé honesto sobre el intercambio. Entonces, en lugar de un no plano o un sí imprudente que arruina silenciosamente tu plan, dices algo así como, sí, podemos agregar el tablero de los padres, y esto es lo que mueve hacia abajo en la lista para dejar espacio para eso No estás negando el cambio. Estás haciendo visible el costo de la misma y estás dejando que las partes interesadas te ayuden a elegir. Nueve de cada diez veces, una vez que ven el intercambio, hacen una llamada sensata, y ahora es su llamado más que una pelea. Mantente flexible sin derrapar, algunas barandillas te pueden ayudar Mantenga un orden de prioridad claro, un solo retraso clasificado, para que la palabra importante siempre tenga un significado Mantener una definición de hecho que mantenga. Tus estándares de calidad no llegan a flexionarse solo porque están plantados. Manejar el cambio en la revisión por defecto, retroalimentación por lotes en ese momento regular, lugar de dejar que llegue como un flujo constante de interrupciones y rechazar el chapado en oro Di no al brillante agradable a los que en realidad nadie pedía enfoque no es algo que tengas, es algo que eliges una y otra vez. Entonces, el cambio no es una amenaza para un buen proyecto Agile. En realidad es el combustible. La habilidad consiste en absorber estos cambios a propósito a través de la acumulación en el momento adecuado. Gracias por acompañarme. En la siguiente lección, veremos las actualizaciones de estado y cómo mantener informados a sus grupos de interés sin perder el tiempo de nadie. Te veré ahí. 21. Actualizaciones de estado que respetan el tiempo de las personas.: Bienvenida de nuevo. En esta lección, vamos a echar un vistazo a cómo escribir actualizaciones de estado que la gente realmente lea. Así que la mayoría de las actualizaciones son demasiado largas o son demasiado vagas o se ignoran silenciosamente, pero las tuyas no tienen por qué serlo Entonces, al final de esta lección, tendrás una estructura simple que podrás reutilizar cada semana, y también tendrás una buena idea de cuándo una actualización de estado requiere una reunión y cuándo solo requiere una simple nota escrita. Empecemos por qué fallan tantas actualizaciones porque si evitas estas cuatro trampas, lo estarás haciendo correctamente. En primer lugar, son demasiado largos, un muro de texto que nadie termina, donde la única línea importante ahoga en detalle. Dos, son demasiado vagos Hacer un buen progreso no le dice precisamente nada a una parte interesada. Tercero, no tienen una pregunta clara. Si necesitas una decisión, dilo. Y si no lo haces, pregúntate por qué esa persona lo está leyendo en absoluto. Y cuatro, es el público equivocado. Detalle de ingeniería profundo enviado a un patrocinador que solo quiere el titular. Si arreglas esas cuatro cosas, entonces ya estás por delante de la mayoría de los equipos. Entonces aquí está la estructura. Todo lo importante encaja bajo tres titulares, y todos comienzan con P, así que es más fácil de recordar. Avances, planes y problemas. Avances. Lo que realmente se hizo desde la última vez, terminar las cosas, no en progreso las cosas. Planifica lo que vas a hacer a continuación y más o menos cuándo lo verán y los problemas, lo que está bloqueado o lo que necesita una decisión que se establezca específicamente con una pregunta clara. Y esa es toda la plantilla. Si algo no encaja en el plan de progreso o problemas, probablemente no pertenezca a la actualización de estado en primer lugar. Así que aquí hay una plantilla que puedes reutilizar, y vamos a llenarla para nuestra aplicación de aprendizaje de idiomas que puedas ver cuán corta puede ser realmente una actualización de estado. En progreso, tenemos el cuestionario de animales enviado y las insignias de progreso ya están disponibles para el 40% de los usuarios. Plan, el correo electrónico de resumen de los padres es el siguiente, y haremos una demostración en la revisión del viernes. Problemas, hay un error de audio en la lección de números, y necesitamos una decisión sobre si retrasa el lanzamiento. Esa es una actualización completa, útil en tres líneas. No hay relleno, y lo único que necesitas del lector, es imposible pasar por alto una decisión. La mayoría de las actualizaciones no necesitan una reunión. Entonces una decisión que tienes que tomar es cómo enviar esto. La respuesta honesta, la mayoría de las actualizaciones no requieren una reunión en absoluto, porque tu defecto debe ser escrito y asincrónico o asincrónico, lo que solo significa que la gente lo lee en su propio tiempo en lugar de todos reuniéndose Entonces una breve nota skimmable que aterriza en una bandeja de entrada o una página compartida, y que cubre la gran mayoría de Solo vale la pena reservar una reunión cuando necesitas discusión o necesitas una decisión, algo que escribir de ida y vuelta no puede manejar muy bien. Como regla general, una reunión cuyo propósito es sólo compartir información suele ser un correo electrónico que se puso por encima de su estación, informando por escrito y reunirse para tomar decisiones. Entonces tienes tres encabezamientos, progreso, plan y problemas mantenidos cortos y enviados a través del último canal que hace el trabajo Así que gracias por acompañarme. En la siguiente lección, es tu turno. Escribiremos juntos una actualización real de las partes interesadas para su propio proyecto, y la documentaremos en Noción. Te veré ahí. 22. Práctica: Escribe una actualización para interesados: Bienvenida de nuevo. En esta lección de práctica, vas a hacer el trabajo. Vamos a escribir una actualización real de las partes interesadas para tu proyecto usando la estructura de tres partes de la última vez. Te mostraré en una pantalla en Noción Primero, y luego puedes pausar el video y puedes escribir el tuyo propio. Así que comencemos. Entonces aquí está el ejercicio en cuatro pasos. Elija la audiencia, elija un solo stakeholder o un grupo de su mapa de stakeholders y escriba específicamente para ellos. Dos, usar las tres partes, progreso, plan y problemas, y nada más. Tres, que sea breve y dulce. Si no cabe cómodamente en la pantalla de un teléfono, probablemente sea demasiado largo. Y cuatro, el paso más importante, envíelo. Una actualización enviando tus borradores no vale nada. Entonces escribirlo es la práctica. Enviarlo es el trabajo. Entonces echemos un vistazo a nuestra página de Noción. Tenemos desde antes de la página de actualizaciones de las partes interesadas. Voy a abrir esta página aquí, y te voy a mostrar el reporte de estado que he agregado aquí para sprint one. He agregado la fecha 22 de mayo de 2026 en un viernes, lo general un buen día para hacer reporte de estado Y el público es jefe de producto, que he agregado aquí en esta columna enviada a. Y si abrimos esta página, vea el título sprint one reporte de estado con toda la información importante en la parte superior. Y en el cuerpo, tenemos la fecha, 22 de mayo de 2026, el reporte de estado con avances con dos balazos, plan con dos balazos y los problemas con dos balazos más Y es tan sencillo como eso. Ahora, obviamente, este es el reporte de estado que se ha escrito. Ahora tenemos que enviar. Si haces clic en Compartir en la parte superior aquí, si tus stakeholders están en Noción, tienen cuentas de Noción, puedes enviarla a su cuenta a través de este campo aquí o puedes copiar el enlace y simplemente puedes enviarles el enlace directamente. Y todo esto está disponible en el plan gratuito de Noción. No necesitas ninguna suscripción paga para hacer esto. Entonces eso es todo. Entonces sí, lo más importante es que en realidad lo envíes es la página gratuita que has agregado en Noción. Así puedes pausar el video y puedes escribir tu propia página ahora para uno de tus grupos de interés. Cuando termines, compruébalo las cuatro cosas que cabe en una pantalla, que sea lo suficientemente corto para leerlo en menos de un minuto, y que cada línea gane su lugar, así que no haya relleno, y si una línea informa ni pide nada, córtala. La pregunta es obvia. Si necesitas algo, es imposible perderte, y se adapta al lector lanzado a lo que realmente le importa a esta audiencia en particular, no a todo lo que pasa a saber Los cuatro son ciertos, entonces has escrito una actualización que la gente realmente leerá. Una última nota aquí, la parte más difícil de la comunicación de las partes interesadas no es realmente la escritura. Es el hábito. Una actualización breve y honesta que se envía cada semana genera de manera rutinaria más confianza que envía un hermoso informe una vez al trimestre Así que mantén la estructura igual cada vez, y se convierte en un trabajo de cinco minutos que en realidad seguirás haciendo, y transmitirás una actitud de competencia y de proactividad haciendo esto todas las semanas, y muestra buena disciplina en la gestión de proyectos Entonces ese es el final de esta lección. Bien hecho por hacer el ejercicio de práctica. A continuación, tenemos midiendo lo que más importa y las métricas. Entonces los números que cuentan. Bien hecho por llegar al final de esta lección. Gracias por acompañarme, y los veré en la siguiente. 23. Explicación de los gráficos burndown y burndown: Bienvenida de nuevo. En esta lección, vamos a ver los dos gráficos de progreso más comunes en Agile, el gráfico de burndown y el gráfico de burnup Ambos llevan una pila desordenada de trabajo en una sola línea que puedes leer en segundos. Entonces, al final de esta lección, sabrás leer cada uno, lo que te dice la forma de la línea y qué gráfico alcanzar dependiendo de quién esté buscando. Entonces, ¿por qué realizar un seguimiento visual del progreso? Primero, ¿por qué molestarse en absoluto? Porque una imagen supera a una reunión de estado. Una mirada a un buen gráfico debería decirte si el sprint está en camino, y eso reemplaza silenciosamente a 100 mensajes de cómo va. Entonces hay dos cosas que hacen que estos gráficos valgan la pena un esfuerzo muy pequeño. Son rápidos. Una línea de tendencia te muestra en segundos qué estado de actualización de párrafo no pueden ser honestos, la línea no gira. Muestra la verdadera pieza de trabajo, sea una lectura cómoda o no. Entonces aquí está el gráfico de burndown. Empecemos con éste. La idea está en el nombre. El trabajo se quema a medida que se acerca a cero. El eje vertical es el trabajo restante, generalmente en puntos de historia o número de tareas, y el eje horizontal es el tiempo, los días que quedan de tu sprint. Al inicio, queda toda la obra, por lo que la línea comienza en lo alto de la izquierda. A medida que el equipo termina las cosas, la línea baja. Si todo se hace, llega a cero el último día. La línea de trazos es tu ideal, una carrera recta de todo el trabajo hacia abajo a cero al ritmo que necesitas para terminar exactamente a tiempo. Y la línea sólida es exactamente lo que pasó. Toda la habilidad es leer la brecha entre los dos así que veamos cómo leemos una tabla de burndown Entonces, ¿qué es lo que te dice exactamente la línea? Hay cuatro formas para reconocer. Si la línea real se asienta en el ideal, entonces estás aproximadamente según lo programado. Se puede continuar. Si se mantiene por encima de lo ideal, entonces queda más trabajo del planeado, así que te estás quedando atrás. Si está por debajo de lo ideal, estás adelantado a lo previsto, o lo más probable es que planeaste demasiado y no te comprometiste con suficiente trabajo. Y el que hay que vigilar, que es una línea plana donde la línea deja de caer por uno o dos días. Eso significa que no se está acabando nada , algo está atascado, y lo que vale la pena preguntar, y vale la pena preguntarlo en el próximo stand up. Ahora el gráfico de quemados, esto muestra el mismo progreso, pero al revés hacia arriba. Entonces, en lugar de la cuenta regresiva de trabajo, la obra terminada sube. La línea continua ascendente es el trabajo que terminaste , subiendo de cero, y hay una segunda línea en la parte superior, que es el alcance total, la cantidad total de trabajo que pretendes completar. progreso es la brecha que se cierra entre la línea de escalada y la línea superior. Cuando la línea terminada cumple con la línea de alcance, ya está. Entonces uno de los superpoderes de la tabla de quemados es el alcance Ahora bien, la línea superior podría parecer una pequeña adición, pero esta es la superpotencia del burnup porque te muestra cuando se mueven los postes de la portería Aquí está la diferencia. En burndown, si alguien agrega trabajo mid sprint, la línea simplemente se hunde extrañamente o aplana y no se puede ver fácilmente Los cambios de alcance en esta instancia, están ocultos. En un quemado, cuando el telescopio crece, la línea superior salta visiblemente El cambio está ahí, es honesto y es obvio para cada uno es exactamente por eso que muchos equipos prefieren el quemado cuando están hablando con las partes interesadas Si el plazo se resbala porque alguien seguía agregando solicitudes, el gráfico muestra que no fue el equipo el que se quedó atrás Yo fui el blanco que se movió. La foto tiene la conversación para ti. Entonces, ¿cuál debes usar y cuándo? Honestamente, ambos son muy útiles solo eliges en función de tu audiencia. Entonces alcanzarías el burndown dentro del equipo porque es un simple chequeo diario ¿Estamos en el ritmo de terminar el sprint y luego alcanzar el burnup con los stakeholders porque muestra progreso y alcance juntos, lo que significa muchas menos sorpresas incómodas sobre por qué se movió una fecha Pero el verdadero punto es este, o el gráfico supera a ningún gráfico. Una línea de tendencia visible cambia la conversación de piñones a evidencia Así que solo usa uno. Así que las cuentas de burndown funcionan hacia abajo , queman, lo sube y la forma de la línea hace la conversación Gracias por acompañarme en esta lección. En la siguiente, veremos dos métricas clave para el trabajo basado en flujo, el diagrama de flujo acumulativo y el tiempo de entrega. Te veré ahí. 24. Flujo acumulado y tiempo de entrega.: Bienvenida de nuevo. En esta lección, vamos a medir un sistema Cam Ban. Entonces Cam Ban no tiene sprints, así que el gráfico de burndown y burnup no encajan del todo aquí Entonces, en cambio, observamos el flujo del trabajo. Cubriremos dos herramientas que hacen la mayor parte del trabajo, el diagrama de flujo acumulativo y el tiempo de entrega. Al final, podrás detectar un cuello de botella de un vistazo y decir, honestamente, cuánto tiempo lleva realmente tu trabajo Entonces dos chequeos de salud Caban. Debido a que Caban no tiene límite de sprint, mide el flujo en su lugar, qué tan suavemente se mueve el trabajo en todos los ámbitos, de izquierda a derecha. Dos herramientas transportan la mayor parte de la carga. El primero es el diagrama de flujo acumulativo que muestra el trabajo apilándose o moviéndose suavemente a través del tablero El segundo es el tiempo de entrega, que muestra cuánto tiempo tarda realmente el trabajo en hacerse. Juntos, responden a las dos preguntas que más importan en el trabajo basado en el flujo. ¿Algo se está atascando, y cuánto tiempo están tomando las cosas? Entonces echemos un vistazo al diagrama de flujo acumulativo, también conocido como CFD, que significa diagrama de flujo acumulativo Parece un poco complicado al principio, pero la idea es bastante simple. tiempo corre a lo largo de la parte inferior, y hacia arriba por el lado están el número de tarjetas. Y cada banda de color es una etapa de tu tablero, y todas están apiladas encima de las demás. La banda inferior está hecha, entonces tienes en progreso y luego para hacer en la parte superior. Todos los días, cuentas cuántas cartas hay en cada etapa, y eso establece la altura de cada banda. Entonces toda la imagen te muestra tu trabajo fluyendo hacia arriba y a través. Nuevas tarjetas se unen a la banda para hacer en la parte superior, y luego viajan hacia abajo a través la en progreso hacia Dunn a medida que terminan En un sano sistema de bandas Cam, las bandas trepan juntas en franjas aproximadamente paralelas. Es cuando las rayas dejan de ser paralelas que en realidad aprendes algo. Aquí te explicamos cómo leer la forma de estas bandas. Las bandas paralelas significan que todo está creciendo de manera uniforme, y significa que el trabajo de flujo estable y saludable entra y sale a un ritmo similar. Una banda que de repente se ensancha es tu señal de advertencia. Esto muestra un cuello de botella, trabajo se amontonó en una etapa más rápido de lo que está saliendo. Si en los globos de la banda de progreso, empezaste a formar mucho más que tu acabado. Una banda plana hecha en la parte inferior es la peor de estas. En realidad no se está completando nada. Y un top plano donde no llega ningún trabajo nuevo suele estar bien, aunque ocasionalmente, es un indicio que tu atraso puede estar agotándose. Ahora, veamos el tiempo de entrega y el tiempo de ciclo, que es la segunda herramienta. Estos son fáciles de mezclar, así que vamos a fijarlos usando la placa. Entonces, el tiempo de entrega es todo el viaje desde el momento en que una solicitud aterriza en tu backlog hasta el momento en que se hace Es el reloj que siente el cliente porque inicia en el instante que pide, y el tiempo del ciclo es más corto. Es el reloj que comienza cuando el equipo realmente comienza a trabajar en la tarjeta en curso, y se ejecuta hasta que se termina. El tiempo de entrega es lo que siente su parte interesada y el tiempo del ciclo es la velocidad de trabajo del equipo una vez que recogen algo. Si sus tarjetas permanecen en el backlog durante semanas antes de que alguien comience, tiempo de su ciclo puede verse genial mientras que su tiempo de entrega se ve terrible, pero solo el cliente lo notará Entonces, ¿qué tiempo de entrega te dice? El tiempo de entrega es un solo número, pero gana su mantener de varias maneras diferentes. Primero es la previsibilidad. Una vez que su tiempo de entrega es estable, puede hacer promesas honestas como mayoría de las solicitudes se realizan dentro de dos semanas. En segundo lugar, la alerta temprana. Si el tiempo de entrega comienza a subir, entonces algo está obstruyendo el flujo, y a menudo lo verás aquí antes de que aparezca en cualquier otro lugar Y tercero es el pronóstico. Tus tiempos de entrega pasados son la mejor guía que tienes para cuando una nueva pieza de trabajo se terminará de manera realista Entonces no hay conjetura que es solo lo que en realidad tiende a suceder en esos casos Entonces, el diagrama de flujo acumulativo te muestra dónde está atascado el trabajo, y el tiempo de entrega te dice cuánto tiempo lleva realmente. Ahora, ambos convierten una tabla ocupada en algo sobre lo que realmente puedes razonar. Entonces ese es el final. Gracias por acompañarme en esta lección. En la siguiente, daremos un paso atrás y haremos una pregunta más grande. Estamos midiendo cuánto producimos o la diferencia que realmente hace? Te veré en la siguiente lección. 25. Métricas de resultados vs. métricas de salida: Bienvenido de nuevo. En esta lección, vamos a dibujar la única decisión más importante en la medición, la diferencia entre salida y resultado. Es la diferencia entre estar ocupado y ser valioso, y equivocarse es cómo los equipos terminan trabajando de plano mientras que nada de lo que importa mejora. Entonces, al final de esta lección, podrás distinguir a los dos y emparejarlos para que tus números realmente apunten al valor. Entonces, la distinción más importante en esta sección es que la salida es lo que se produce, y el resultado es la diferencia que marca. La salida es lo que envías , como características, boletos, puntos de historia, y el resultado es lo que cambia en el mundo real debido a ello. La gente aprendiendo más, volviendo más, pagando felizmente. Y la incómoda verdad es que puedes enviar mucho y no cambiar nada de lo que importe. Mucha salida sin resultado. Mantener esas dos ideas separadas es de lo que trata esta lección. Entonces, veamos primero las métricas de salida. Estos miden tu actividad, cuánto trabajo produjo el equipo. Estos son muy útiles, pero son ligeramente limitados. La velocidad es el clásico. Es la cantidad de puntos de historia que un equipo termina por sprint, y es una medida del rendimiento. Las características enviadas cuentan cuántas cosas lanzaste y los boletos cerrados, cuenta el gran volumen de trabajo. Es lo que todos tienen en común. Te dicen que el equipo estaba ocupado y no te dicen nada sobre si alguno de ellos realmente ayudó. Entonces salida respuestas, ¿ construimos cosas? No importaban. Entonces ahora llegamos a las métricas de resultados, que es la otra mitad, y aquí es donde vive el valor real. Estos son más difíciles de medir, pero valen mucho más. Entonces, para nuestra aplicación de aprendizaje de idiomas para niños, las métricas de resultados podrían estar menos terminadas. ¿Los alumnos realmente terminan las lecciones que inician o los alumnos activos semanales o las personas que regresan semana después o se están alejando O satisfacción de los padres. ¿La gente que lo paga siente que vale la pena? Ahora bien, estos son más difíciles de mover y más difíciles de falsificar porque miden si el producto está haciendo su trabajo o no. Entonces el resultado responde a la pregunta que en última instancia cuenta. ¿Ayudó? Ahora bien, esta es la trampa porque es una trampa fácil en la que caer. Cuando la salida es todo lo que mides, comienzas a optimizarlo, y puedes estar muy ocupado yendo a ninguna parte. Así imagínese la revisión trimestral. Por ejemplo, enviamos diez nuevas características este trimestre. Todos asienten con la cabeza y el equipo parece productivo, pero ninguna de esas características se movió menos que la finalización Entonces eso es un montón de movimiento sin progreso. Las características eran reales, pero el valor no lo era. Entonces dos hábitos para mantenerte fuera de esa trampa, la solución, atar cada métrica de salida a un resultado que está destinado a mover para que el envío siempre tenga un propósito más allá del envío y la prueba. Para cualquier número que rastrees, pregunta si esto subió y nada mejoró realmente, ¿por qué lo estoy midiendo en absoluto? Entonces la respuesta no es desechar las métricas de salida. Velocity y el resto son realmente útiles para dirigir un equipo. La respuesta es emparejar cada uno con el resultado que se supone que sirva. Las características enviadas deben servir para completar la lección. Velocity debe servir fechas de entrega predecibles. Los errores corregidos deberían servir a calificación de tu tienda de aplicaciones y la confianza que conlleva. El contenido agregado debe servir a los alumnos activos semanales. Entonces los rastreas uno al lado del otro, y el momento en que la salida sube mientras su resultado se sienta plano, te has pillado estando ocupado en lugar de ser útil, que es exactamente la advertencia que deseas Entonces, la salida es lo que haces, y el resultado es para lo que sirve, y los equipos más saludables mantienen ambos a la vista Gracias por acompañarme en esta lección. En la siguiente, veremos cómo incluso las buenas métricas se pueden reutilizar y qué debes tener cuidado de no medir nunca Te veré en la siguiente. 26. Evitar el uso indebido de las métricas: lo que no se debe medir: Bienvenido de nuevo. Esta es una lección corta pero importante porque una métrica puede ser un arma de doble filo. Vamos a ver cómo los buenos números se vuelven malos y las cosas específicas que debes tener cuidado de no medir, y una forma más saludable de mantener métricas para que ayuden a tu equipo en lugar de dañarlo Entonces comencemos. Así que empieza con una ley de métricas que vale la pena memorizar Se llama ley de Goodhart, y va cuando una medida se convierte en objetivo, deja de ser una buena medida Entonces, en términos claros, el momento en que conviertas un número en un objetivo por el que la gente sea recompensada o castigada, comenzarán a jugar el número en lugar de hacer el verdadero trabajo detrás de él Entonces la medida fue útil precisamente porque nadie intentaba moverla directamente. Si haces de esa métrica un objetivo, entonces rompes lo mismo que hizo que valga la pena verla en primer lugar. Entonces, aquí hay cuatro formas comunes en las que las métricas pueden salir mal, para que pueda detectarlas viniendo. El primero es la velocidad como objetivo. Si estableces un objetivo de punto de historia, y las estimaciones se inflarán rápidamente, los puntos suben, pero el trabajo real no siguiente es la producción individual, midiendo a las personas en lugar de a los equipos, lo que mata de manera confiable la colaboración porque ayudar a un colega ahora te cuesta en tu propio marcador. Métricas de vanidad. Son números que se ven maravillosos y no significan nada como descargas de aplicaciones en lugar de si alguien realmente usa la cosa. Y por último, se arma las métricas. Entonces los números solían culpar a las personas, que simplemente enseñan a todos a ocultar problemas en lugar de salir a la superficie y solucionarlos. Entonces lo importante es medir al equipo, no a la persona. Una de las formas más rápidas de medir un equipo es medir a un individuo en lugar del equipo. Las métricas ágiles están diseñadas para describir el sistema de un equipo, no el valor de un individuo. Velocidad, tiempo de entrega, flujo acumulativo, estos describen cómo funciona el flujo, no lo duro que alguien intentó esta semana. Momento es una métrica utilizada para clasificar a las personas entre sí. Deja de decir la verdad porque cada uno empieza a optimizar para su propio número en lugar de optimizar para el resultado compartido. Entonces se mide el sistema y se apoya a los individuos. Entonces, ¿cómo usas bien los mismos números? Hay tres cambios de espíritu. Úselos para aprender, no para juzgar. Pregunta qué te está enseñando un número, no quién tiene la culpa de ello. Observamos tendencias, no instantáneas. Un solo punto de datos es ruido, y la dirección a lo largo de varias semanas es la señal real, y tratar una métrica como una pregunta, no como un veredicto Un número sorprendente debería iniciar una conversación no terminar una. Mismos datos, efecto completamente diferente en tu equipo. Así que manejado con métricas puede guiarte, pero cuando se manejan descuidadamente, pueden engañarte y pueden dañar Así que manténgalos apuntados al sistema y manténgalos curiosos en lugar de acusar. Gracias por acompañarme en esta lección. En la siguiente, es tu turno. Construiremos un simple panel de métricas de make para tu proyecto en Notion. Te veré ahí. 27. Práctica: crea un panel de métricas: Bienvenido de nuevo. En esta lección de práctica, vas a construir tu propia base de datos de métricas en Notion. Así que vamos a armar esto para tu proyecto. Voy a construir uno en la pantalla, y luego puedes hacer una pausa y construir uno tú mismo. Entonces, como siempre, Notion es gratis, se ejecuta en tu navegador, y todo hoy funciona en el plan gratuito sin necesidad de agregar complementos. Así que vamos. Aquí está el ejercicio en cuatro pasos. Uno, elija tres o cuatro métricas, una mezcla deliberada de salida y resultado, y resista el impulso de rastrear todo Dos, para cada uno, digan para qué sirve. La pregunta está ahí para responder. Tres, construir una página, que es solo una simple tabla en la noción, y cuatro, el paso que realmente importa es actualizarla semanalmente. Un tablero que nadie actualiza es solo decoración. Entonces, una pequeña nota sobre la elección de tus métricas. Elijamos una configuración de saldo para nuestra aplicación de aprendizaje de idiomas para que puedas ver la mezcla. Velocidad, que es una métrica de salida, respuestas, ¿estamos entregando a un ritmo constante? La finalización de la lección, que es un resultado, las respuestas son los alumnos que terminan lo que comienzan con estudiantes activos semanales, otro resultado, las respuestas son personas que regresan. Y luego el conteo de errores abiertos, que es una salida responde es la calidad bajo control. Entonces no, es el saldo dos números sobre lo que estamos haciendo y dos sobre si está funcionando. Cuatro métricas son abundantes. Así que un tablero que en realidad guardarás late a uno hermoso que abandonas. Así que mantenlo simple. Bien, entonces construyéndolo en Notion. Puedes construirlo en tu cuenta gratuita siguiendo los siguientes pasos. Entonces vas a agregar una tabla con las columnas para métrica esta semana, semana pasada y la tendencia, y luego tendrás una fila en la tabla por métrica. Y luego en la final, tendremos la flecha de tendencia, ya sea arriba, abajo o plana, y esta es la lectura más rápida de la página. ¿Bien? Entonces echemos un vistazo a cómo se verá eso en Notion. He agregado una nueva página en la parte inferior llamada Tablero de métricas, y luego dentro he agregado una nueva tabla. En esta, no vamos a usar una base de datos. Sólo vamos a usar una mesa normal. Y he conseguido los títulos de cuatro columnas en la parte superior, la métrica esta semana, semana pasada y tendencia. Tengo la velocidad, lo que muestra un incremento con respecto a la semana pasada. Tengo un incremento en el porcentaje de finalización de clase. Así que de nuevo, usando la flecha hacia arriba. Los alumnos activos semanales subieron esta semana desde la semana pasada, así que hay otra flecha hacia arriba. Por último, tenemos bugs abiertos, siete esta semana, tuvimos nueve la semana pasada, así que la tendencia va a la baja. Este es un dashboard de métricas bastante positivo, tengo que decir, todo va muy bien en este proyecto. Volvamos al espectáculo. Ahora, puedes pausar el video y construir el tuyo propio. Cuando esté hecho, compruébalo con estas cuatro cosas. Entonces tenemos algunas métricas que están bien elegidas, tres o cuatro en las que confías, vencieron a 20 que ignoras. Tienes una mezcla de salida y resultado, no solo lo que hiciste, sino si realmente ayudó. Tercero es que cada métrica tiene un propósito. Si no puedes decir para qué sirve, entonces borra. Y la última es que en realidad se mantuvo al día. Entonces los números están actualizados en un horario que mantendrás de manera realista Si golpeas las cuatro cosas, tienes un tablero que silenciosamente te hará un maravilloso tomador de decisiones. Tan bien hecho. Ahora puedes seguir el progreso con burndown y burnup Puede leer un sistema Cam Band con flujo acumulativo y tiempo de entrega, y puede distinguir la salida del resultado, evitar las trampas comunes y puede juntarlo todo en un tablero simple. Tan gran trabajo. Gracias por acompañarme. En la siguiente sección, concluiremos todo el curso intermedio Ágil, y juntaremos estos hilos . Te veré ahí. 28. Errores intermedios comunes: M Entonces esta es una etapa peligrosa. Ya sabes lo suficiente. Entonces aquí está lo que pasa con esta etapa. Los conceptos básicos de Agile son fáciles aprender y desafortunadamente, fáciles de falsificar. Puedes llevar a cabo cada ceremonia a la perfección, ir a cada reunión, llenar cada tabla y aún así perderte por completo el punto de todas ellas. Entonces esa es la trampa intermedia. Pasando por los movimientos sin problemas mientras el valor se escapa silenciosamente. Entonces, a medida que atravesamos estos escollos, noten que casi ninguno de ellos trata de hacer lo incorrecto Se trata de hacer lo correcto, pero por la razón equivocada o con la razón completamente olvidada. Entonces, comience con el proceso en sí. Tenemos cuatro formas en que el ritual sobrevive, pero el propósito muere Las primeras son las ceremonias de culto a la carga, dirigiendo las reuniones de memoria, pasando por la coreografía sin idea real para qué sirve cada una A continuación está el stand up zombie, un informe de estado diario entregado al gerente en lugar de el equipo realmente se sincronice entre sí Sprints que son secretamente mini cascadas. Entonces una semana de diseño, luego una semana de construcción, luego una semana de pruebas, que es el viejo proceso secuencial lleva un disfraz de Agile. Y finalmente, una definición de hecho que flexiona silenciosamente, así hecho llega a significar casi lo mismo cada vez que se avecina un plazo En cada caso, la forma es correcta, pero la sustancia se ha ido. A continuación, tenemos escollos de la gente. Estas son las fallas más sutiles y las más caras. El tomador de pedidos PO, propietario del producto que simplemente transmite lo que se le pida en lugar de priorizar realmente para que el retraso se convierta en una señal de la solicitud de mascotas de todos A continuación está la cultura del héroe donde una persona salva cada sprint en el último minuto, que se ve impresionante pero en realidad es desesperadamente frágil porque el día que están libres, todo ha terminado La parte interesada olvidada es la persona tranquila a la que nunca mapeaste, que sale a la superficie en el peor momento posible para bloquearte, y luego retroalimentar al teatro. Así que obedemente pedir comentarios en cada revisión y luego ignorarlo todo, lo que enseña a la gente a dejar de molestarse A continuación, tenemos trampas métricas, que vimos en la última sección y que ahora notarás en todas partes Entonces el primero es la velocidad como objetivo. En el momento en que los puntos se convierten en meta, estimaciones se inflan para golpearlo, y el número sube mientras que el trabajo real no lo hace Salida sobre resultado, celebrando diez características enviadas que no mueven nada a nadie realmente le importaba las métricas de vanidad, por lo que los números que se ven geniales en una diapositiva pero que realmente no significan nada debajo, como descargar sin uso. Y luego finalmente midiendo a la gente. Así que tomando métricas diseñadas para describir un sistema de equipo y convertirlas en cuadros de mando individuales, lo que envenena de manera confiable a cualquier Entonces la cura suele ser la misma, así que hay buenas noticias ahí. Y básicamente es una sola pregunta. Entonces, para cualquier ritual, cualquier métrica, cualquier hábito, pregunta, ¿ esto realmente nos está ayudando a entregar valor? Si la práctica no está sirviendo eso, se le permite cambiarla. El framework te sirve. No se guarda el marco. Entonces y debajo de eso, siéntate los dos hábitos en los que descansa el Salón de Ágil, inspecciona. Así que mira honestamente lo que está pasando, no la versión ordenada que hay en tu cabeza, y adáptate. Entonces cambia una cosa, mira lo que pasa, y luego quédate con lo que funciona. Si haces esos dos repetidamente y honestamente, sales de casi todos los escollos de esta lista El peligro intermedio no es la ignorancia. Está pasando por los movimientos. Así que sigue preguntándote si cada práctica gana su lugar. Gracias por acompañarme. En la siguiente lección, pondremos esa lente en ti con una autoevaluación honesta. ¿Estás listo para liderar realmente un equipo? Te veré en la siguiente. 29. Autoevaluación: ¿Estás listo para liderar?: Bienvenida de nuevo. Entonces esta lección va a ser una mirada honesta en un espejo. Vamos a pasar por una autoevaluación para que veas claramente lo que ya puedes hacer y qué áreas necesitas practicar. Entonces esta no es una prueba con una marca de pase. Es más una manera de convertir un vago, ¿estoy listo para sentirme en una respuesta específica y útil? Así que agarra un bolígrafo si quieres, y pasemos juntos por la autoevaluación. Como dije antes, esto es un check in, no un examen. Regla número uno, sé honesto y específico. Para cada ítem, contesta con un ejemplo concreto, no esperanzado tal vez. Entonces sí, hice este último sprint sí cuenta, pero creo que podría no cuenta. El valor de este ejercicio está enteramente en la honestidad con la que lo respondes. Entonces, una puntuación generosa que no ganaste solo te roba un plan de mejora claro, si es necesario Oh, ¿puedes correr la mecánica, las partes móviles de un sprint? ¿Se puede correr un sprint completo de extremo a extremo? ¿Puedes planificarlo, ejecutarlo, revisarlo y realizar una retrospectiva ¿Puedes configurar tu tablero? ¿Se puede construir un scrum o una tabla Caban que otras personas realmente puedan usar, no solo tú? ¿Se puede priorizar un backlog ordenando la obra por valor y manteniéndola ordenada a medida que cambian esas cosas Y ¿se puede estimar el trabajo con sensatez con puntos o tallas de camiseta sin pretender una falsa precisión Si tienes cuatro síes aquí, entonces tienes mucha confianza con el concepto de sprint ágil Siguiente es ¿puedes manejar a la gente? Esto es más importante que la última sección. Esta es la zona que realmente decide si los proyectos tienen éxito o no. Entonces, ¿puedes mapear a tus grupos de interés y decir quién importa y cuánta atención necesita cada uno? ¿Puedes ejecutar una revisión de sprint que muestre trabajo real y obtenga comentarios que realmente puedes usar? ¿Se puede absorber el cambio, tomando un nuevo requisito a bordo sin descarrilar al equipo Y finalmente, ¿puedes escribir una actualización clara que le diga a un stakeholder lo que necesita en menos de un minuto? Estos son más duros que la mecánica de un sprint, y importan más. El siguiente es ¿puedes leer las señales? Entonces estos son los números que te mantienen honesto. ¿Puedes mirar un diagrama de quemadura o un diagrama de flujo acumulativo y decir en palabras simples, qué está pasando realmente? ¿Se puede distinguir la salida de un resultado? ¿Se puede notar la diferencia entre estar ocupado y ser genuinamente valioso? ¿Y puedes detectar el mal uso de métricas? Entonces, al darse cuenta cuando se está ganando un número o se convierte silenciosamente en un arma, si puedes leer estas señales, entonces puedes dirigir por evidencia en lugar de por un intestino Así que suma tus síes honestos. Si en su mayoría es sí, entonces estás listo para liderar un equipo. Puedes ejecutar los procesos, manejar a las personas y leer las señales, que es exactamente lo que requiere el trabajo. Así que adelante y hazlo. Si tienes algunas brechas, eso no es un fracaso. Es sólo un mapa. Entonces cada uno no apunta directamente a una sección de este curso que vale la pena volver a visitar Entonces nadie empieza con un conjunto completo de síes. El objetivo de este ejercicio es saber cuál es cuál, así sabes dónde precisamente poner tu esfuerzo a continuación. Una autoevaluación honesta realmente supera a la falsa confianza cada vez porque te dice dónde necesitas mejorar. Gracias por acompañarme. En la siguiente lección, la pondremos en práctica en tu proyecto real, revisando tu plan de lanzamiento y tus métricas hasta el momento. Te veré en la siguiente. 30. Revisión del proyecto: plan de lanzamiento y métricas: Bienvenida de nuevo. Esta es una lección práctica, así que es tu turno de hacer algún trabajo en tu proyecto. Vamos a hacer una revisión de tus proyectos hasta ahora, tu plan de lanzamiento y tus métricas, y vamos a juntarlos todos en un solo lugar, y ese lugar estará en Notion. Entonces aquí está el ejercicio en cuatro pasos. Primero, reúne tus artefactos, tu tablero, tu acumulación, plan de lanzamiento y tus métricas, y tenlos todos en un solo lugar Dos, revisar el plan de liberación y preguntar si sigue siendo realista o si el alcance se ha movido silenciosamente. Tres es revisar las métricas y leer lo que realmente te están diciendo las tendencias, tanto el resultado como el resultado. Y cuatro, fíjate lo que cambiarías. Entonces solo uno o dos ajustes honestos para la próxima vez. Ahora, echemos un vistazo un poco más profundo a los dos del medio. Entonces primero, revisando tu plan de liberación. Si no estás familiarizado con el plan de liberación a término, es solo un mapa rudo de lo que se va a enviar y más o menos un horario rígido, es una expectativa compartida. Entonces, para nuestra aplicación de aprendizaje de idiomas , podría verse así. Suelte uno, las lecciones principales que ya están enviadas. La segunda versión era Badgers más padres resumen correo electrónico actualmente en curso, y la versión tres es el tablero principal planeado pero no iniciado La pregunta de revisión aquí es simple e importante. ¿Esto todavía coincide con la realidad? Entonces los planes a la deriva, así que tal vez el lanzamiento dos creció o tal vez el lanzamiento tres resultó ser más importante de lo que pensabas. Revisando el plan es donde captas esa deriva a propósito en lugar de sorprenderte por él en una fecha posterior. Entonces, a continuación tenemos que revisar tus métricas usando el tablero que construimos la última lección. Así que no te limites a echar un vistazo a los números, leerlos como una historia. Así que la velocidad constante te dice que tu ritmo de entrega es predecible, lo cual es una buena noticia para cualquier promesa que hagas. La finalización de la lección te dice que el producto principal es realmente aterrizar con los alumnos. Los usuarios activos semanales te dicen que la gente va a regresar, no a la deriva, y abrir Bugs abajo te dice que la calidad está bajo control Entonces, leídos juntos así, estos cuatro números te dan una imagen sorprendentemente honesta de la salud de todo el proyecto. Entonces aquí hay un formato de revisión simple a seguir. Para capturar todo esto, en realidad solo necesitas cuatro encabezados honestos ¿Qué va bien? Así que nombra las victorias con claridad porque son realmente fáciles de olvidar cuando estás bajo presión. ¿Qué está atascado? Entonces los cuellos de botella y los bloqueadores sigues trabajando silenciosamente Lo siguiente es lo que ha cambiado. ¿Son los alcances, las prioridades o las personas que han cambiado desde que empezaste? Y luego finalmente, ¿qué sigue? Entonces una o dos cosas que deliberadamente harás de manera diferente en el próximo sprint. Esa es tu estructura de revisión. Entonces, poniéndolo todo en una página en Notion. En esa sola página, deberías tener un plan de lanzamiento. Deberías tener tu registro de velocidad y luego algunas notas de revisión. Te voy a mostrar exactamente cómo sería esto en Notion. Así que agregué la revisión del proyecto. Ahora bien, probablemente no vas a tener una revisión de proyecto en la primera semana, pero como solo hemos hecho una semana en este proyecto, hasta ahora, solo voy a poner la semana uno. En esta página, tengo dos enlaces al plan de lanzamiento y al panel de métricas. Entonces para hacer eso, puedes copiar el enlace, y luego pegarlo. Mostrarte cómo se ve eso. Entonces, si lo pegas, pegará el enlace directamente. Y luego si solo haces clic en mencionar, te dará el enlace directo a esa página. Entonces en esta página, también he agregado el enlace a las métricas, dashboard, y luego a continuación, he puesto lo que salió bien, qué está atascado, qué ha cambiado y qué sigue. Entonces bajo esos rubros, ese es el encabezamiento dos, por cierto Puedes poner una lista con viñetas y debes responder esas cuatro preguntas Entonces así es como debería verse el esqueleto de esta página en no ahora echemos un vistazo a cómo se ve bien. Así que pausa el video, construye tu propia reseña. Cuando esté hecho, compruébalo con estas cuatro cosas. Uno, que es honesto, que la columna atascada no está vacía porque una reseña sin fricción no es una revisión real. Utiliza evidencias. Tus afirmaciones están respaldadas por el tablero y las métricas, no solo por sentir. Es corto. Una página podría leerse antes de una reunión. Y finalmente, termina en acción, al menos una cosa concreta que cambiarás para la próxima vez. Si golpeas esas cuatro cosas, entonces has hecho algo que mayoría de los equipos no manejan del todo, que es detenerse y aprender genuinamente de su propio proyecto y aprender de la salud de su propio proyecto. Entonces una buena reseña convierte unas semanas ocupadas en lecciones que realmente puedes usar, y ese hábito es lo que separa a las personas que repiten sus errores de las personas que suman sus habilidades. Así que gracias por acompañarme. En la lección final, veremos a dónde vas desde aquí y el camino que tienes por delante en tu gestión de proyectos Agile. Entonces nos vemos para el siguiente. 31. Qué sigue: el camino por delante: Bienvenidos a la lección final de este curso. En esta lección final, solo vamos a alejar el zoom. Vamos a ver qué tan lejos has llegado, y nombraremos el turno que viene continuación y te señalaremos el camino por delante. Entonces esta es una corta, así que hagamos que cuente. Entonces, antes que nada, es solo mirar hasta dónde has llegado. Así que date algo de crédito porque has cubierto mucho en este curso. Y déjeme simplemente resumirlo muy rápido para usted. Entonces ya has estudiado frameworks. Puedes elegir y ejecutar Scrum o Cam Ban o un híbrido sensible de los dos en lugar de seguir uno por defecto Con las partes interesadas, puedes mapear a las personas alrededor de tu proyecto. Puedes ejecutar reseñas con ellas, y puedes mantenerlas actualizadas sin perder el tiempo de nadie. Y finalmente, las métricas, puedes medir el progreso, el flujo y los resultados reales honestamente, y también puedes detectar cuándo un número te está engañando. Entonces este es el kit de herramientas de alguien que realmente puede ejecutar un proyecto Ágil. Bien hecho. Entonces de hacer a liderar, este es el cambio que viene después. Entonces no es sólo más de lo mismo. Hasta el momento, has aprendido a ejecutar bien un proyecto Agile. El siguiente paso es diferente en especie. Se trata de liderar a la gente y mejorar la forma en que trabaja todo un equipo a lo largo del tiempo. Entonces correr un buen sprint es una habilidad, pero construir un equipo que corra buenos sprints sin que te pares sobre ellos y que siga mejorando sí solo es una habilidad diferente y más profunda Ese paso de hacer Agile a liderarlo es la siguiente etapa de tu crecimiento como líder Ágil. A dónde va tu viaje Ágil desde aquí, siguiendo desde el intermedio, en primer lugar, es escalar, entonces cómo coordinar a más de un equipo sin ahogar a todos en proceso Lo siguiente es la calidad y el riesgo, cómo construir la calidad desde el principio y manejar el riesgo con sensatez sin papeleo pesado Siguiente es la mejora continua. Entonces el final de Kai, vigilar la salud del equipo y mantenerse afilado sin quemar a la gente. Y por último, está entrenando, haciendo crecer un equipo que se mejore a sí mismo y liderando sin controlar. Entonces, en otras palabras, es la mitad de liderazgo de Agile para ir con la mitad de entrega que acabas de dominar. Entonces ese es el final de este curso. Enhorabuena. Lo iniciaste, capaz de seguir un proceso Ágil, y lo estás terminando, capaz de ejecutar uno con buen juicio con la gente de lado y con números honestos para guiarte Entonces ese es un logro muy real, y deberías estar orgulloso de ello. Así que muchas gracias por acompañarme y por todo el trabajo que has puesto y buena suerte en tu viaje de gestión de proyectos Agile. 32. Proyecto de clase: planifica un lanzamiento multi-sprint y crea un panel de gestión de proyectos: Ahora es el momento de ampliar tu proyecto Agile. Para tu proyecto de clase, construyes sobre el proyecto que has estado desarrollando a lo largo del curso planificando una versión completa de múltiples sprint y creando un panel de administración de proyectos simple. Comienza definiendo un objetivo de lanzamiento y dividiendo tu trabajo en múltiples sprints Luego, estime su trabajo atrasado, priorice su trabajo y pronostica cómo podría progresar su proyecto a lo largo A continuación elige el marco que mejor se ajuste a tu proyecto. Puedes seguir usando Scrum, convertir tu trabajo a Caban o crear un enfoque híbrido basado en las necesidades de tu proyecto También identificará a sus partes interesadas clave y preparará una actualización del proyecto que comunique el progreso, las prioridades y cualquier cambio importante. Finalmente, cree un tablero de métricas simple usando Notion o cualquier otra herramienta de su elección. Incluya métricas que le ayuden a comprender progreso de su proyecto y respalden una mejor decisión. Ya terminaste, sube capturas de pantalla de tu plan de lanzamiento, tablero de proyecto y panel de métricas a la galería del proyecto, y siéntete libre de incluir una breve explicación de por qué elegiste tu flujo de trabajo y cómo abordaste la planificación de tu proyecto. El objetivo no es construir un proyecto perfecto. Es solo para demostrar que se puede pensar más allá de un solo sprint y administrar un proyecto desde una perspectiva más amplia y estratégica. 33. ¡Felicidades!¿Qué sigue?: Enhorabuena por completar el curso. Ahora ha ido más allá de los fundamentos de Agile y ha desarrollado una comprensión mucho más amplia de cómo se planifican, administran y entregan los proyectos exitosos a lo largo del tiempo A lo largo de esta clase, aprendiste a construir planes de lanzamiento, estimar el trabajo de manera más efectiva, elegir entre Scrum y MBA, comunicarte con las partes interesadas y usar métricas significativas para guiar tus decisiones Recuerda, Agile no se trata seguir un marco a la perfección, sino de aprender continuamente, adaptarse y elegir las prácticas que mejor apoyen a tu equipo y a tu proyecto. Si aún no lo has hecho, asegúrate subir tu proyecto a la galería. Me encantaría ver cómo planeaste tu lanzamiento y estructuraste tu flujo de trabajo, si has disfrutado de la clase, por favor considera dejarnos una reseña. Nos ayuda a mejorar las clases futuras y ayuda a otros alumnos a descubrir el curso. Gracias por acompañarme y espero verte en la próxima clase.