Clase magistral de gestión de proyectos para principiantes: ejecuta tu primer proyecto ágil.

1. ¡Te doy la bienvenida a la clase magistral para principiantes de gestión de proyectos ágiles!: Mm hmm. Bienvenido al curso Agile Project Management para principiantes. Alguna vez se ha preguntado cómo los equipos exitosos organizan proyectos, gestionan las prioridades cambiantes y entregan resultados de manera consistente? Si es así, estás en el lugar correcto. Mi nombre es Luke Phillips, y soy gerente de proyectos con siete años de experiencia trabajando con metodologías ágiles en diferentes tipos de proyectos y equipos En este curso, te ayudaré a entender Gestión de Proyectos Ágil de una manera práctica y amigable para principiantes. Uno de los mayores retos a la hora aprender la gestión de proyectos es que muchos de estos cursos se centran en la teoría sin mostrar cómo funcionan realmente los proyectos en la práctica. Por eso esta clase está diseñada torno a la construcción de un proyecto real paso a paso. Juntos, exploraremos la mentalidad ágil. Aprenderemos los principios detrás de Scrum, entenderemos cómo funcionan los atrasos de productos y las historias de usuarios, y usaremos herramientas populares como Trello y Noción para organizar nuestro proyecto Aprenderás a planificar sprints, priorizar el trabajo, estimar tareas, organizar reuniones, administrar cambios y revisar el progreso, tal como hacen los equipos ágiles en organizaciones reales A lo largo de la clase, aplicará todo a un resumen de proyecto de su elección, ayudándole a adquirir experiencia práctica en lugar de simplemente memorizar conceptos Entonces, al final de este curso, comprenderás el estilo de vida completo del proyecto Agile y tendrás tu propio espacio de trabajo del proyecto, backlog y plan de sprint listos para exhibir. Empecemos. 2. La mentalidad ágil: introducción a la gestión ágil de proyectos: Hola, y bienvenidos. En los próximos 5 minutos, te voy a presentar una de las ideas más comentadas en la gestión moderna de proyectos. Ágil. Al final de este video, sabrás exactamente qué es Agile, de dónde vino y por qué tantos equipos mucho más allá del mundo del software lo han adoptado. Soy Luke, y he pasado los últimos siete años más o menos trabajando como gerente de proyectos en Edtech Eso es tecnología educativa, liderando proyectos de aprendizaje digital con equipos multifuncionales e internacionales, y Agile ha sido parte de mi vida laboral diaria durante todo ese tiempo, y quiero desmitificarlo Entonces, ¿qué es Agile? Empecemos simples. Agile es una forma de administrar proyectos que divide el trabajo en pequeños trozos manejables y entrega valor paso a paso, lugar de todo al final Para entender por qué esto importa, imagínese la alternativa tradicional, que se llama cascada. En proyectos de cascada, planificas todo por adelantado, y luego ejecutas cada fase en orden, requisitos, diseño, construcción, prueba, lanzamiento Esto funciona maravillosamente, pero sólo mientras nada cambie. Y en el mundo real, las cosas cambian constantemente. Así que los clientes podrían cambiar de opinión, los mercados pueden cambiar, nueva información puede aparecer a mitad de camino, y Agile fue diseñado exactamente para esa realidad Entonces, en lugar de un gran plan y un gran lanzamiento, trabajas en ciclos cortos, generalmente de una a cuatro semanas. Y al final de cada ciclo, tienes algo real que mostrar, recibir comentarios y mejorar. Entonces, ¿de dónde vino Agile? En febrero de 2001, 17 desarrolladores de software se reunieron en un albergue de esquí en Utah, y se sintieron frustrados porque gestión tradicional de proyectos pesados de documentos no funcionaba para el software. Entonces durante ese fin de semana, escribieron el Manifiesto Ágil Se trata de cuatro valores cortos y 12 principios de apoyo. Y vale la pena memorizar los cuatro valores cortos. Así que Agile valora a los individuos y las interacciones sobre los procesos y herramientas. Valora los productos de trabajo sobre la documentación completa. Valora la colaboración con el cliente sobre la negociación de contratos, y valora responder al cambio sobre seguir un plan. Ahora note la palabra terminada. Los artículos de la segunda línea siguen siendo importantes. Necesitas procesos, documentación y planes, pero cuando tengas que elegir, debes priorizar las cosas en la parte superior Ahora, aunque Agile comenzó en el software, esos valores se aplican casi en cualquier lugar donde estés creando algo nuevo con certeza, ya sea marketing, diseño de producto, educación o incluso atención médica. Entonces, ¿cómo se ve realmente Agile día a día? En su fondo, es un bucle. Planeas un pequeño trabajo , lo construyes, lo revisas con las partes interesadas, aprendes de los comentarios y luego lo vuelves a hacer todo. Ágil, este ciclo corto a menudo se llama sprint, y suelen durar dos semanas. Al principio, eliges un pequeño conjunto de elementos de un priorizado para hacer se llama backlog Entonces el equipo construye esos ítems, muestra los resultados, y luego reflexiona sobre lo que salió bien y qué mejorar. Y luego el ciclo se repite. Agile es una mentalidad, pero para aplicarla, mayoría de los equipos utilizará un marco específico Los dos más comunes de los que escucharás son Scrum y Cam Ban Scrum usa esos sprints fijos de dos semanas con roles de producto definidos como propietario del producto y Scrum Tienes ceremonias regulares, como planeación, stands diarios y reseñas y retrospectivas Cam Ban, por otro lado, es más continuo, el trabajo fluye a través de un tablero visual, y el foco está en limitar cuánto está en progreso a la vez. Muchos equipos usarán una mezcla real de ambos. Por qué importa. ¿Por qué Agile se ha vuelto tan dominante? Hay tres razones. Uno, reduce el riesgo porque los problemas emergen temprano, no al final. Dos, mantiene a los equipos alineados con los clientes porque constantemente te registras con ellos en lugar de adivinar Y tres, respeta a las personas confiando en equipos pequeños para organizar su propio trabajo Perfecto para el trabajo remoto. Para recapitular, Agile es una mentalidad para entregar trabajo en ciclos cortos impulsados por retroalimentación Viene del Manifiesto Ágil 2001, prioriza a las personas, la producción laboral, la colaboración y la adaptabilidad, y en la práctica, suele tomar la forma de Scrum, Cam Ban, o un Entonces, lo que te dejaré con Agile no se trata realmente sprints o stand-ups o notas adhesivas en una pared. Ellos son solo las herramientas. En su fondo, Agile es una forma de admitir algo honesto No siempre sabemos la respuesta por adelantado, y lo más inteligente que podemos hacer es construir un poco, aprender un poco y seguir mejorando Entonces, ya sea que administre equipos de software, ejecute campañas de marketing o coordine programas de aprendizaje, esa mentalidad ágil le servirá bien Gracias por ver y buena suerte en su viaje de gestión de proyectos. 3. Para quién es este curso y qué crearás.: Hola, y bienvenidos de nuevo. En el último video, vimos el panorama general de lo que es Agile, y lo comparamos con el estilo tradicional de gestión de proyectos en cascada. En este video, quiero hacer dos cosas. Primero, quiero ayudarte a comprobar que este es el curso adecuado para ti. Y segundo, quiero mostrarte con qué te vas a ir al final. Este no es uno de estos cursos donde solo ves una carga de teoría y luego te preguntas qué hacer con ella. Al final de este curso, habrás construido algo real. Entonces, este curso para ti? Hay cuatro tipos de personas para las que se construyó este curso. En primer lugar, fue construido para principiantes completos. Si has escuchado la palabra Ágil en el trabajo o en los anuncios de empleo y no estás muy seguro de lo que significa, estás exactamente en el lugar correcto. No necesitas ningún conocimiento previo para tomar este curso. Segundo, este curso fue construido para personas que se están moviendo hacia la gestión de proyectos o en un rol de producto. Entonces tal vez te han ascendido o estás tratando de irrumpir en el campo. Agile es el idioma hablan los equipos más modernos, así que lo necesitarás, y vocabulario realmente ayuda mucho en la gestión de proyectos. Demuestra que estás al menos consciente del concepto. El tercer tipo de persona las personas que ya están manejando proyectos de manera tradicional que sospechan que hay una mejor manera. La hay, y lo vas a aprender aquí. Y el cuarto tipo de persona son las personas que no trabajan en el software en absoluto. Entonces en marketing, en eventos, educación, cuidado de la salud, dueños de pequeñas empresas, Agile se aplica a casi cualquier cosa donde estés creando algo nuevo y no tengas todas las respuestas por adelantado Entonces, si ese eres tú, este es el rumbo correcto. Una nota rápida sobre para quién no es este curso. Si ya eres un Scrum Master certificado con años de experiencia, este curso se sentirá bastante básico Eso está bien. Los cursos intermedios y avanzados de esta serie van mucho más profundos. Así que solo asegúrate de comenzar donde realmente estás. Entonces veamos lo que construyes. Tienes tres artefactos reales dignos de cartera, no solo notas de un curso. Entonces, ¿qué vas a construir realmente? Este curso se basa en proyectos de principio a fin. Escogerás un resumen del proyecto en el siguiente video. Tendrás tres para elegir. Y luego todo lo que aprendas, lo aplicarás a ese proyecto. Al final del curso, tendrás tres cosas que son genuinamente dignas de cartera. Lo primero que tendrás es una cartera de productos completamente poblada Esa es la lista priorizada de trabajo desde la que cualquier equipo Agile real necesita comenzar Dos, tendrás una tabla de sprint que muestra un ciclo completo de sprint que realmente has corrido, y tres, tendrás un documento retrospectivo de sprint escrito donde reflexionarás sobre lo que salió bien y lo que cambiarías la próxima vez Estos son los mismos artefactos que cualquier equipo de producto en funcionamiento produce cada dos semanas. Y puedes poner estas cosas en una cartera. Podrías mostrarlos en una entrevista de trabajo, y puedes usarlos como plantillas para tu próximo proyecto real. Son tuyos. Entonces echemos un vistazo a lo que necesitarás. Todas estas son herramientas gratuitas. No se requieren planes pagados. No hay juicios. No hay ningún problema de registro. Las dos herramientas gratuitas que usaremos son Trello y NS ambas tienen niveles gratuitos Nunca te pediremos que pagues nada ni que te registres a ningún juicio. Y entonces lo tercero que necesitarás es un bolígrafo y papel. Entonces, a veces la opción de tecnología más baja es lo mejor para pensar. Entonces, a continuación, elige tu proyecto. Tendrás la opción de tres calzoncillos. Tendrás una opción, y luego construiremos. Así que elige el que creas que más te queda. No pienses demasiado en la elección. En el siguiente video, te ayudaré a decidir sobre tu breve. Entonces te veré ahí. 4. Elige tu resumen del proyecto: Edtech, comercio electrónico o eventos: Bienvenido de nuevo. Ahora por la parte divertida. En este video, vas a elegir el proyecto en el que trabajarás para el resto de este curso. He preparado tres calzoncillos diferentes para ti. Cubren industrias muy diferentes a propósito, principalmente para demostrar que Agile no es solo para proyectos de software. Verás a lo que me refiero en un minuto. Así que no te estreses por esta elección. Escoge el que más te excita o el que más se acerque a tu trabajo real Aquí no hay una respuesta correcta o incorrecta. Cualquiera de estos calzoncillos te servirá bien para este curso. Tan breve A es tecnología educativa Edtech para construir una función para una aplicación de aprendizaje de idiomas para niños Así que imagina que eres el gerente de producto o el gerente de proyecto en una pequeña startup de Edtech Tu equipo está construyendo una aplicación de aprendizaje de idiomas para niños, y la primera versión está en vivo, pero el compromiso cae después de la segunda semana. Tu trabajo es planificar y ejecutar un sprint que envíe una nueva función diseñada para traer de vuelta a los niños. A lo mejor se trata de un sistema de rachas o un nuevo modo de juego o algunas recompensas Éste depende de ti. Así que elige esta si te gustan los productos de consumo o las aplicaciones. Estás en o cerca de la educación, y quieres pensar motivación y el compromiso de los usuarios. Brief B es E-Commerce para lanzar una nueva línea de productos para un minorista sustentable. Entonces, para este, estás trabajando con un pequeño minorista en línea que vende artículos para el hogar sostenibles. Quieren lanzar una nueva línea de productos, por ejemplo, cocina ecológica todo tiempo para la temporada de compras navideñas. Ahora con esta, tienes muchas partes móviles. Tenemos fotografía, tenemos descripciones de productos, tenemos precios, negociaciones de proveedores, marketing, incluso el sitio web. Entonces tu trabajo es planificar y ejecutar un sprint que prepare el lanzamiento. Yo elegiría este si te gustan las no operaciones de negocios o si te interesa el marketing o el emprendimiento en general, o quieres un brief con muchas piezas funcionales cruzadas y móviles. Si C es un evento de la industria. Así que organice una conferencia híbrida de dos días. Conferencia híbrida significa que tienes personas que asisten en persona y en línea. Entonces con este proyecto, hay un lugar para reservar. Hay oradores para invitar. Hay patrocinadores que perseguir. Tenemos un sitio web para construir. Tienes Tech para configurar y una campaña de marketing para ejecutar. El evento es en tres meses, y tu trabajo es planificar y correr un sprint que mueva el proyecto hacia adelante. Yo elegiría este específicamente si no trabajas en tecnología. Eventos es el brief que demuestra que Agile funciona fuera del software. Si estás en operaciones de marketing, recursos humanos o cualquier campo que no sea de TI, este es probablemente tu mejor opción. Entonces, ¿cómo elegir? Estas son las tres preguntas si estás atascado. Uno, ¿qué industria está más cerca de tu trabajo real? Si tu trabajo diario es en retail, elige E-Commerce. Si no está en tecnología, elija eventos. Cuanto más cerca esté el breve tu realidad o de lo que quieras estar haciendo, más saldrás de este curso. Dos, ¿cuál te emociona más genuinamente? Vas a pasar al menos 3 horas en esto, así que elige la que disfrutes. Y número tres, si aún estás atascado, elige eventos. Es el más accesible para los principiantes, y probablemente sea el mejor que muestra todas las ventajas de Agile Project Management. Entonces, pausa el video, elige un breve, escríbalo. En el siguiente video, entraremos en el propio Manifiesto Ágil, los cuatro valores y 12 principios que sustentan todo lo demás. Te veré ahí. 5. El manifiesto ágil: cuatro valores, doce principios.: Bienvenida de nuevo. En el video de introducción, mencioné el Manifiesto Ágil, que fue el documento que 17 desarrolladores escribieron en el ski lodge en Utah, si recuerdas esto En este video, vamos a profundizar en lo que realmente dice. Vamos a ver los cuatro valores y los 12 principios de apoyo. Ahora bien, este es un video importante. Este es el núcleo filosófico de todo lo demás en el curso y el vocabulario importa. Así que tal vez quieras sacar tu pluma y papel para este video. Entonces, antes que nada, ¿por qué manifiesto? Bueno, había un problema que necesitaba resolverse. Y aquí está tu contexto. Entonces, a finales de los 90, los proyectos de software estaban fallando, grandes y los caros, principalmente porque los equipos pasaban meses y meses escribiendo especificaciones detalladas, y luego más meses realmente construyendo lo que decían esas especificaciones solo para entregar algo que el cliente ya no quería. No lo querían porque los mercados se habían movido, los requisitos habían cambiado. Entonces el plan era perfecto, pero fue el resultado el que no sirve de nada. Este fue el principal problema. Ahora, en febrero de 2001, 17 desarrolladores se conocieron en una estación de esquí en Utah. Ahora bien, no estuvieron de acuerdo en los métodos, pero todos coincidieron en que tenía que haber una mejor manera. Entonces, durante el fin de semana, escribieron un documento muy corto, que sorprendentemente solo tiene 68 palabras de largo. Entonces vamos a echarle un vistazo. Ahora bien, ese documento consiste principalmente en los cuatro valores, y valoramos los ítems de la izquierda más de lo que valoramos los ítems de la derecha. El manifiesto dice, estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo A través de este trabajo, hemos llegado a valorar, y luego tenemos las cuatro declaraciones. Así que valore uno, individuos e interacciones sobre procesos y herramientas. Esto significa que un gran equipo con herramientas mediocres superará a un equipo mediocre con Por lo que hablar entre ellos es muy importante. No te escondas detrás del software. Valor dos, software de trabajo sobre documentación integral. Entonces, lo que esto realmente significa es 100 páginas de hermosas especificaciones que nadie lee valen mucho menos que un pequeño prototipo de trabajo que la gente pueda usar e intentar. Así que construye algo real tan pronto como puedas. Tercer valor, la colaboración con el cliente sobre la negociación de contratos. Lo que esto significa es que no desperdicies tu energía discutiendo exactamente lo que se acordó en el escrito original. Trabaje con su cliente, colabore con ellos, descubra lo que realmente se necesita. Y el cuarto valor es responder al cambio sobre seguir un plan. Ahora bien, lo que esto significa es que un plan no es como una hipótesis. No es un contrato. Cuando la realidad contradice el plan, cambie el plan Y aquí está la parte que la gente echa de menos. El manifiesto termina con, es decir, si bien hay valor en los ítems de la derecha, valoramos más los ítems de la izquierda Entonces estas cosas tradicionales como procesos y documentación, contratos y planes, todas siguen siendo importantes. No son algo malo, pero no son la prioridad cuando se trata de empujar a empujar Entonces echemos un vistazo a los 12 principios. Ahora, agrupar los principios los hace un poco más memorables. Entonces no voy a leer los 12 principios uno tras otro. Eso sería bastante tedioso. Además, solo puedes leerlos tú mismo en un par de minutos. Recuerden, solo son 68 palabras de largo. Entonces, en lugar de pasar por uno a 12, voy a agruparlos en cuatro temas diferentes. Ahora, el primer tema, entregar valor temprano y con frecuencia. El primer principio dice, satisfacer al cliente a través entrega temprana y continua. Y el tercer valor dice, entregar software de trabajo con frecuencia, semanas en lugar de meses. Traducción, lo que esto realmente significa, consigue algo real frente a los usuarios lo más rápido que puedas y luego sigue haciendo. El segundo tema, bienvenido cambio. El segundo principio de los 12 dice literalmente, bienvenido, cambiando requisitos, incluso tarde en el desarrollo. Ahora, eso suena una locura si vienes de la tradicional gestión de proyectos en cascada. Pero la apuesta Ágil es que el cambio va a suceder de todos modos, así que bien podrías construir para ello. El tercer tema es la gente primero. En este tema se pueden agrupar varios principios. Construyes proyectos alrededor individuos motivados y confías en ellos para hacer el trabajo. conversación cara a cara es la forma más eficiente de compartir información, y los mejores arquitectos y diseñadores emergen de equipos autoorganizados. Si notas un patrón, Agile confía en las personas que trabajan en los proyectos. El cuarto tema es la sustentabilidad y la reflexión, dos principios que me encantan. Los procesos ágiles promueven el desarrollo sustentable. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante indefinidamente En otras palabras, ninguna marcha de la muerte. Y el último principio a intervalos regulares, el equipo reflexiona sobre cómo llegar a ser más efectivo. Se ha construido en la mejora continua. Entonces echemos un vistazo a lo que esto significa en la práctica y lo que significa el manifiesto para tu proyecto Entonces, ¿qué significa cuando estás haciendo tu resumen de proyecto? Significa priorizar el envío algo pequeño sobre planear algo perfecto Esto significa que cuando tu stakeholder cambie de opinión, trata eso como información útil, no como un problema por el que deberías estresarte. Significa confiar en tu equipo, reflexionar a menudo sobre lo que has hecho, mejorar constantemente. Ahora bien, nada de esto es ciencia espacial. Es principalmente el sentido común lo que han sido olvidados por estas grandes organizaciones que están muy atrapadas en sus caminos. El trabajo del manifiesto es recordarnos. Entonces, en el siguiente video, abordaremos los conceptos erróneos de Agile Project Management porque, ya sabes, como se usa tan ampliamente , surgen estos conceptos erróneos Es sorprendente lo mucho que a 68 documentos de Word pueden llegar a ser malentendidos Entonces, en el siguiente video, veremos los mitos ágiles, desacreditados. Nos vemos ahí. 6. Mitos e ideas erróneas de Agile.: Bienvenido de nuevo. Si sólo recuerdas una cosa de este video, hazlo así. La mayor parte de lo que la gente llama Ágil no lo es. Ahora, hay una enorme brecha entre lo que dice el manifiesto y lo que realmente hacen los equipos Entonces veamos los conceptos erróneos y desacreditemos los mitos. Mito número uno, Ágil significa que no hay planeación. Este me vuelve loco, razón por la cual es el número uno. El manifiesto dice responder al cambio sobre seguir un plan, no nunca seguir un plan Los equipos ágiles planifican constantemente. Simplemente planean en trozos más pequeños con más frecuencia, y están dispuestos a cambiar esos planes a medida que aprenden Si alguien te dice que no planeamos, somos ágiles, ellos no son ágiles. Simplemente están desorganizados. Así que ten cuidado Mito número dos, Ágil significa que no hay documentación. De nuevo, también me vuelve loco. El manifiesto dice trabajar software sobre documentación integral, eso no significa cero documentación Significa que no escribas 200 páginas que nadie lee. Escribir documentación realmente ayuda a una historia de usuario clara, un registro de decisiones simple, un diagrama de arquitectura de una página , todos ellos son bienvenidos. Mito número tres, Agile es solo Scrum. No. Scrum es un framework ágil Hay otros marcos incluyendo Caban, programación extrema, lean y Scrumban, que es el híbrido Agile es la mentalidad, los valores y los principios que acabamos de cubrir, y Scrum es una forma específica de aplicar esos Entonces cuando alguien dice, ¿ Estás haciendo Agile, respuesta más honesta suele ser que estamos haciendo Scrum, que es un sabor de Agile Profundizaremos en esto en el segundo curso. M número cuatro, Ágil es solo para software. El manifiesto fue escrito por desarrolladores, pero los principios y los valores son universales Los equipos de marketing usan Agile, los hospitales usan Agile, las escuelas usan Agile. Incluso las empresas constructoras lo utilizan. Entonces, si estás creando algo nuevo y la incertidumbre existe y tienes muchas partes interesadas, entonces Agile aplica, y es muy efectivo. Entonces es por eso que uno de tus resúmenes de proyecto en este curso es un proyecto de evento, no uno de software Mi número cinco, Ágil significa más rápido. Este es posiblemente el mito más dañino porque así es como se vende a los ejecutivos en proyectos Agile. Nos hará enviar más rápido. O sea, a veces lo hace, pero el beneficio real de Agile no es la velocidad. Es la adaptabilidad. Te enfocas en las cosas que más importan porque has aprendido cuáles son esas cosas a lo largo del proyecto. En realidad podrías hacer menos trabajo en general debido a esto. Entonces la velocidad es un efecto secundario. No la meta. Ahora, en el siguiente video, vamos a detectar el comportamiento Ágil. Tendrás la oportunidad de probarlo tú mismo. Haremos un ejercicio rápido y práctico. Te voy a mostrar algunos escenarios, y tú decides cuáles son en realidad Ágiles y cuáles están simplemente disfrazados para verse ágiles desde una perspectiva superficial. Entonces te veré. 7. Ejercicio de práctica: detecta los comportamientos ágiles y no ágiles.: Bienvenido de nuevo. Ahora llegamos a nuestro primer ejercicio de práctica, Ágil o no. Quiero que veas el comportamiento Ágil. Te voy a dar cinco escenarios cortos. Para cada uno, pausa el video y decide, ¿es este comportamiento ágil o no? Y entonces te voy a dar la respuesta. Entonces primero, escenario uno, un equipo escribe un documento detallado de especificación de 80 páginas antes de escribir una sola línea de código. Ahora pausa si quieres. ¿ Esto es Ágil o no Ágil? Esto no es Ágil. Entonces este es el pensamiento clásico en cascada, gran planificación por adelantado, y luego se construye, lo que va en contra de la metodología Ágil Entonces, en el escenario dos, un equipo envía una pequeña función cada dos semanas, recibe comentarios de usuarios reales y la usa para decidir qué construir a continuación. Haz una pausa aquí si quieres. ¿ Esto es Ágil o no Ágil? Esto es Ágil. Tenemos ciclos cortos. Tenemos comentarios reales de los usuarios y decisiones basadas en lo aprendido durante ese piloto, podrías llamarlo. Bien, escenario tres. El cliente pide un cambio a la mitad del proyecto El equipo responde, Lo siento, eso no está en el escrito original. Haz una pausa aquí, si quieres. ¿ Esto es Ágil o no Ágil? Esto no es Ágil. Así que recuerda, tenemos el tercer valor de colaboración con el cliente sobre la negociación de contratos. Bienvenida al cambio. No lo pelees. Ahora, escenario cuatro, el equipo tiene una reunión de 15 minutos cada mañana donde cada persona comparte avances, planes y cualquier bloqueador. También hablan de lo que hicieron ayer, lo que están haciendo hoy, cosas como esta. ¿Esto es ágil o no? Esto es Ágil. Este es el clásico stand up diario, que está apoyando el Principio seis. conversación cara a cara es la forma más eficiente de compartir información. Y escenario cinco, un equipo celebra una reunión todos los viernes para discutir qué salió bien, qué no y qué probar a continuación. Pausa aquí. ¿Esto es Ágil o no Ágil? Esto es Ágil. Esto se conoce como retrospectiva Se trata de Principal 12, que está en entrevistas regulares, el equipo reflexiona sobre cómo llegar a ser más efectivo. Entonces miran las cosas que salieron bien, las cosas que fallaron. Así que anota tú mismo. ¿Cuántos conseguiste? No te preocupes si te perdiste una pareja. Estos conceptos y estos valores se hundirán con el tiempo. Pero ese es el final de la Sección uno. 8. Los componentes básicos: sprints, incrementos y bucle empírico.: En esta sección, entraremos en la sala de máquinas de Agile. En la última sección, hablamos de la mentalidad, y en esta, vamos a hablar de la mecánica Al final de este video, sabrás qué un sprint, qué es un incremento, y también conocerás el sencillo bucle de tres pasos que utilizan los equipos ágiles para entregar valor Así que vamos a meternos en ello. ¿Qué es un sprint? Un sprint es un contenedor de longitud fija para el trabajo. Es un periodo de tiempo fijo durante el cual un equipo trabaja para completar una pequeña cantidad de trabajo acordada. La longitud es consistente. Por lo general, es una , dos, tres o cuatro semanas. Dos semanas es, con mucho, la más común. Y la palabra clave ahí es fija. Un sprint siempre comienza el mismo día y termina el mismo día. No lo extiendes porque el trabajo no está hecho y no lo acortas porque alguien está de vacaciones La caja del tiempo es sagrada. ¿Por qué es eso importante? Porque la previsibilidad es una de las cosas que te da Aja Después de unos sprints, comienzas a aprender lo que tu equipo puede hacer de manera realista en dos semanas, y esa información es oro para Entonces no lo extiendes, no lo acortas. Esa caja de tiempo está arreglada. A continuación, ¿qué es un incremento Esto es lo que se produce al final de cada sprint. Es una pequeña pero completa pieza de valor que podría ser liberada o utilizada, algo real. El punto crucial aquí es la palabra trabajar. No es una característica a medio terminar. No es un wireframe. No es un montón de notas o documentación. Es una pieza de trabajo pequeña pero completa que en valor, podría ser liberada o utilizada. Para su proyecto Edtech, un incremento podría ser un contador de racha de trabajo en el para E-Commerce, podría ser una página de producto terminado Para eventos, una reservación confirmada del lugar y una fecha de publicación, cosas como esta. Tan real, terminado y utilizable. A continuación, tenemos el bucle empírico. Tenemos tres palabras. Este es todo el motor de Agile. Este es probablemente el concepto más importante en este video. Suena elegante, pero son solo tres sencillos pasos que se repiten una y otra y otra vez. Transparencia, inspección y adaptación. Transparencia significa que todos pueden ver lo que está pasando. El trabajo es visible en una pizarra, en un backlog, en algún lugar donde todos puedan mirarla. No tenemos avances ocultos ni sorpresas. La inspección significa que revisamos regularmente lo que hemos producido y cómo estamos trabajando. No solo aramos adelante, nos detenemos y revisamos. ¿Esto es lo que quería el cliente? ¿Estamos en buen camino? ¿ Algo está bloqueado? Y la adaptación significa que cambiamos en base a lo que vemos. Entonces, si algo no está funcionando, lo cambiamos. Si un grupo de interés nos da nueva información, actualizamos el plan. No seguimos haciendo lo incorrecto sólo porque estaba en el plan original. Tenemos que adaptarnos. Transparencia, inspección, adaptación. Este es todo el motor de Agile. Entonces veamos cómo encaja. Tienes tu incremento de sprint, y repites. Esto es básicamente lo que es Ágil. Corres un sprint. Digamos que dura dos semanas. Durante el sprint, haces que el trabajo sea transparente en una tabla. Al final del sprint, has producido un incremento de trabajo Después inspecciona. Se lo muestras a la gente. Preguntas qué piensan ellos, reflexionas sobre cómo trabaja el equipo en conjunto, y luego te adaptas para el siguiente sprint y lo vuelves a hacer todo. Este es el ritmo fundamental del trabajo ágil. Sprint, bucle de incremento, sprint, incremento, bucle. Oh. A continuación, tenemos los tres roles que lo hacen funcionar, el propietario del producto, el Scrum Master y el equipo de desarrollo. Te veré para la siguiente. 9. Roles: propietario de producto, Scrum Master, equipo de desarrollo: Bienvenido de nuevo. En esta lección, veremos los tres roles que hacen que los equipos ágiles funcionen. Al final de este video, sabrás quién hace qué y por qué existe cada rol. nos estamos enfocando en el framework Scrum Aquí nos estamos enfocando en el framework Scrum porque es el más común y las definiciones de roles son las más claras. Entonces comencemos. Primero, tenemos al dueño del producto, también conocido como PO. Esta es la voz del cliente en el equipo. Su trabajo es decidir qué construye el equipo y en qué orden. Ellos son dueños del backlog del producto, que es esa lista priorizada de trabajo, y ellos son la persona que dice, Esto es lo que más importa . Haz esto a continuación. Crucialmente, el PO no es el jefe del equipo. No le dicen al equipo cómo hacer el trabajo. Le dicen al equipo qué hacer y por qué importa. El cómo está a la altura del equipo. Un buen propietario de producto pasa tiempo con los clientes. Entienden el negocio y toman decisiones difíciles sobre las prioridades. Dicen que no mucho porque siempre hay más demanda de la que tienen capacidad para. Tu resumen de proyecto, podrías estar jugando este papel tú mismo, lo cual está completamente bien. Solo recuerda la mentalidad del propietario del producto, ten claro las prioridades, habla con tus usuarios y haz compensaciones El siguiente papel es el Scrum Master, también conocido como el SM Este rol ayuda al equipo a trabajar bien. Ahora bien, este es uno de los roles más incomprendidos en Agile Scrum Master no es el encargado del proyecto. No asignan tareas. No rastrean quién hizo qué. No persiguen a la gente por actualizaciones o entregables, y no son el jefe Lo que realmente hacen es ayudar al equipo a trabajar bien. Facilitan las reuniones. Eliminan obstáculos, cosas que impiden que el equipo progrese y entrenan al equipo en prácticas ágiles También protegen al equipo de cualquier interferencia externa. Una de las mejores analogías aquí es que el Scrum Master es como un entrenador de fútbol. Ellos no juegan el juego. No les dicen a los jugadores cómo patear la pelota, pero crean las condiciones donde el equipo puede rendir al máximo. Equipos pequeños, el Scrum Master a menudo se duplica con otro rol, tal vez el desarrollador senior Toda la responsabilidad es compartida, lo cual está completamente bien. Mientras se haga el trabajo, en realidad no importa. El siguiente rol es el equipo de desarrollo. Estas son las personas que realmente construyen el producto. Ahora bien, a pesar del nombre, no se trata solo de desarrolladores de software o programadores El equipo de desarrollo son todos los que realmente construyen el producto. Software, eso serían desarrolladores, pero también diseñadores y probadores. Para un proyecto de marketing , serían redactores, diseñadores, comercializadores Para un evento, son las personas de operaciones, los coordinadores de oradores, el gerente del lugar, dos cosas clave sobre el equipo de desarrollo Una es que se autoorganizan. Nadie les dice cómo dividir la obra. Ellos lo averiguan ellos mismos. Y dos, son multifuncionales. El equipo tiene todas las habilidades que necesita para entregar un incremento sin depender de forasteros El tamaño típico es de tres a nueve personas, lo suficientemente grande como para que tengas todas las habilidades que necesitas y lo suficientemente pequeño como para que todos sepan lo que está pasando y quién está haciendo qué. Entonces echemos un vistazo a cómo estos tres roles funcionan juntos. Tenemos tres responsabilidades y muy poca superposición. El propietario del producto decide qué construir. El equipo de desarrollo decide cómo construirlo, y el Scrum Master se asegura que el proceso funcione sin problemas Estos tres roles y responsabilidades tienen muy poca superposición. Y esta claridad es una de las razones por las que Scrum funciona. Todo el mundo sabe de quién es la decisión de quién. Si una parte interesada quiere una nueva función, habla con el propietario del producto. Si un desarrollador está bloqueado, el Scrum Master ayuda a desbloquearlo. El equipo necesita decidir un enfoque técnico, ellos mismos lo deciden. Ahora, en la vida real, especialmente en equipos pequeños, una persona podría hacer dos roles. Podrías ser el propietario del producto y un Scrum Master. O, como dije antes, el desarrollador senior también podría ser el Scrum Master, lo cual es completamente normal Los roles son sobre responsabilidades y no específicamente sobre títulos de trabajo. Así que gracias por acompañarme en esta lección. A continuación, veremos el backlog del producto. Veremos qué va en él, cómo está estructurado y cómo construir uno bueno. Te veré en la siguiente. 10. El portafolio del producto explicado.: Bienvenido de nuevo. En esta lección, vamos a profundizar en el backlog de productos Este es probablemente el artefacto más importante en el trabajo ágil Y una vez que lo entiendas, muchas otras cosas empezarán a dar click en su lugar. Entonces, al final de este video, sabrás qué es un backlog, qué va en él y qué hace que uno sea bueno Entonces, ¿qué es un backlog de productos? Veamos una definición simple con tres palabras clave. La cartera de productos es una lista ordenada priorizada única de todo el trabajo que se puede hacer en un proyecto o un Ahora bien, hay tres palabras clave aquí en esta definición. El primero es sencillo. Sólo hay un atraso. No hay uno por miembro del equipo. No hay uno por stakeholder. Tenemos un atraso. Se prioriza la siguiente palabra clave. Los ítems en la parte superior de la lista son los más importantes. Y se ordena el tercero. No hay corbata. Si dos artículos son igualmente importantes, el propietario del producto elige uno para que tenga una prioridad más alta que el otro. Piense en ello como una lista de deseos con un pedido. Todo lo que cualquiera quiere haga el equipo eventualmente vive en esta lista, y la orden le dice al equipo en qué trabajar a continuación. Entonces, ¿qué entra en un atraso? Generalmente, tenemos tres tipos de artículos en un backlog. Todos van en la misma lista. Las primeras son las características. Entonces estas son cosas nuevas que quieres construir. Entonces, por ejemplo, agrega un contador de rachas, construye una página de pago o reserva el lugar El segundo ítem serían correcciones. Entonces estas son cosas que están rotas o necesitan mejorar. Por ejemplo, el botón de inicio de sesión no funciona en dispositivos Android. Las fotos del producto son demasiado oscuras. El tercero son los quehaceres. Entonces estos son artículos técnicos. Estas son cosas que el equipo necesita hacer y que no producen directamente una característica sino que son necesarias. Entonces, por ejemplo, configurar la herramienta de análisis, renovar el nombre de dominio, los tres viven en el mismo backlog, priorizar juntos, lo cual es importante Por lo que se ve obligado a sopesar una nueva característica contra una solución crítica frente a un pedazo de deuda técnica. No hay listas separadas que oculten las compensaciones. Los priorizas a todos en la misma lista. Entonces, lo que hace que un buen backlog de productos, recuerde el acrónimo profundo Ahora bien, no todos los elementos en un backlog están igualmente bien definidos. Entonces aquí tenemos un acrónimo útil de lo que debería ser un buen backlog Entonces, PROFUNDO o profundo. D es para detallar apropiadamente. Los artículos cerca de la parte superior de la acumulación en los que se trabajará pronto deberían tener muchos detalles Los artículos cerca de la parte inferior pueden ser vagos. Así que no pierdas el tiempo perfeccionando algo que tal vez nunca se haga E es para estimado. Cada artículo debe tener algún tipo de estimación de tamaño. No tiene que ser horas ni días. Hablaremos de los puntos de la historia más adelante, pero el equipo debería tener una idea aproximada de cuán grande es cada ítem. La siguiente E es para emergente. El atraso nunca se acaba. Se agregan nuevos artículos todo el tiempo. Los artículos antiguos se cambian o eliminan. Ahora bien, esto es saludable. No es una señal de fracaso. Y por último, se prioriza P. Hay un orden claro. Los artículos principales son la máxima prioridad. El propietario del producto es responsable de mantener este flujo de corriente. Para construir tu backlog. Tenemos tres pasos. Esto toma, sí, una o dos horas de trabajo, dependiendo del tamaño del proyecto. Entonces el primero de los tres pasos es una lluvia de ideas. Saca todo de tu cabeza y entra en una lista. No te preocupes por un pedido todavía. No te preocupes por el tamaño. Simplemente volcar todo a tu página. Cada característica, cada solución, cada tarea. Apunta al menos 20 artículos. Segundo paso, agrupa y limpia. Mira tu lista. Algunos artículos pueden ser duplicados. Entonces los artículos serán demasiado grandes para hacerlo en un sprint y necesitarán un poco de desglose. Algunos serán demasiado pequeños y se pueden combinar con otras tareas. El tercer paso es priorizar. Pon el artículo más importante en la parte superior. Lo más importante significa cuál entrega el mayor valor al usuario y más pronto y por la menor cantidad de esfuerzo, y luego hacer lo mismo para el siguiente artículo y el Y al final, tendrías un atraso ordenado. Todo este ejercicio debería llevarte una hora, quizá dos. Lo haremos de verdad en la siguiente sección. Entonces, a continuación, tenemos historias de usuarios, que es el formato para cada elemento en tu backlog Gracias por acompañarme en esta lección. Te veré en la siguiente. 11. Historias de usuarios: escribir en el "Como A..., quiero..., Así que..." Formato: Bienvenida de nuevo. En esta lección, aprenderemos la plantilla más útil en Agile, la historia de usuario. Entonces, al final de este video, podrás escribir una historia de usuario para cualquier elemento de tu backlog, y sabrás qué hace que una historia de usuario sea buena y qué hace una mala Así que absolutamente aspecto clave de los proyectos Agile. La plantilla clásica, comencemos con lo que no es una historia de usuario. Una historia de usuario no es una especificación detallada. No es un contrato ni una lista de requisitos. Una historia de usuario es una breve declaración que captura lo que un usuario quiere y por qué. La plantilla clásica, que verás por todas partes se ve así. Como tipo de usuario, quiero algún objetivo. Entonces esa alguna razón. Hay tres partes, quién, qué y por qué. Entonces como ejemplo, como aprendiz que regresa, quiero ver cuántos días seguidos he practicado para que me sienta motivado para seguir adelante Observe las tres piezas, el usuario, el objetivo y la razón. Entonces, ¿por qué funciona este formato? Hay tres razones por las que merece la pena la estructura rígida. Una, te obliga a identificar al usuario. Tantas características se construyen hoy en día sin que nadie piense en para quién son. Construye un tablero, pero para quién para qué, el formato de historia de usuario hace que esa pregunta sea inevitable Dos, se centra en la meta, no en la solución. Así que fíjate que la historia no dice, agrega un widget de contador de racha en la página de inicio Dice, Mira cuántos días seguidos he practicado. Ahora, esto deja libre al equipo para encontrar la mejor solución para lograr ese objetivo. A lo mejor es un contador, a lo mejor es una vista de calendario, a lo mejor es una notificación. La historia no dicta. Y el tercero, capta el por qué eso así que esa parte suele ser la parte más omitida, pero es la más importante Sin ella, no se puede decir si vale la pena hacer la historia. Si no puedes escribir un convincente para que, tal vez la historia no debería estar en el backlog en absoluto Entonces veamos algunos ejemplos para cada resumen de proyecto. Entonces en Edtech, como padre de familia, quiero ver reportes semanales de progreso sobre mi hijo para que sepa si la app realmente está funcionando En E-Commerce, una historia de usuario podría ser como visitante por primera vez, quiero ver claros los costos de envío antes de agregar a mi cesta, que no me sorprenda al momento de pagar. Y en los eventos, una historia de usuario podría verse como patrocinador, quiero un desglose claro de lo que incluye cada nivel de patrocinio para que pueda decidir con cuál comprometerme. Ahora fíjate en cada caso, que hay un usuario real, un objetivo claro y una razón sensata para ese objetivo. Ninguno de ellos es técnico. Ninguno de ellos prescribe una solución, y este es el punto óptimo. Ahora bien, ¿qué hace que una mala historia sea mala? Veamos cuatro modos de falla comunes. Primero, el fracaso es demasiado vago. Por ejemplo, como usuario, quiero una mejor experiencia para que sea feliz. Ahora bien, esto no es una historia. Esto es como un deseo. ¿ Qué significa better even? Esto es completamente inviable. Un segundo fracaso sería ocultar una solución. Como usuario, quiero un botón rojo en la esquina superior derecha para que pueda hacer clic en él. Ahora bien, esto no es una historia. Eso es solo una especificación de diseño disfrazada de una sola. No tenemos meta ni razón sin ninguna solución prescrita. Tercera falla demasiado grande. Como usuario, quiero un sistema completo de gestión de cuentas para que pueda administrar mi cuenta. Eso no es una historia. Esto es como un proyecto completo. Una buena historia debería ser lo suficientemente pequeña como para completarla en un solo sprint, y si no lo es hay que desglosarla. Al cuarto fracaso le falta el así que, faltando la razón. Entonces, como usuario, quiero iniciar sesión. ¿Por qué? Sin el para eso, no se puede juzgar si vale la pena hacerlo en primer lugar. Entonces hay un acrónimo útil que podemos usar aquí para lo que una buena historia debería ser invertir INVERTIR. Independiente, negociable, valioso, estimable. Pequeño y comprobable. Independiente significa que no depende otra historia se haga primero, si es posible. Negociable significa que los detalles pueden cambiar a medida que aprendemos más. Valioso significa que entrega algo que le importa al usuario. Estimable significa que el equipo puede dimensionarlo aproximadamente. Pequeño significa que cabe en un sprint, y comprobable significa que puedes saber cuándo se hace Ahora, no memorices esto ahora. A lo mejor escríbalo, pero sólo recuerda las siglas. Y si estás atascado en una historia de usuario, puedes recorrer este acrónimo para intentar mejorarla. Oh, gracias por acompañarme en esta lección. En la siguiente lección, agregaremos las piezas finales a una buena historia de usuario, que es el criterio de aceptación y la Definición de Hecho. Estos son los bits que te dicen que el sprint en realidad está terminado. Entonces te veré en la siguiente. 12. Criterios de aceptación y La definición de lo terminado.: Bienvenido de nuevo. En esta lección, abordaremos una de las preguntas más difíciles en Ágil ¿Cómo sabemos cuando algo está terminado? Existen dos herramientas clave que utilizaremos para entender esto los criterios de aceptación y la Definición de Hecho. Entonces comencemos. Ahora bien, ¿qué significa Done even? Si no estás de acuerdo en esto, el equipo discutirá en cada sprint. Entonces aquí hay una pregunta. ¿Cuándo se realiza una función? ¿Es cuando se escribe el código? ¿Es cuando se ha probado? ¿Se hace cuando se ha desplegado? ¿Se hace cuando el usuario puede usarlo? ¿Se hace cuando se actualiza la documentación? Si no estás de acuerdo en estas cosas, terminarás con argumentos a cada paso del camino. Alguien podría decir: Sí, eso está hecho, y alguien más dice, no, no está hecho. No se han realizado las pruebas. Entonces esta ambigüedad puede matar ímpetu. Entonces es por eso que los equipos ágiles utilizan dos herramientas complementarias, los criterios de aceptación. Que son específicos de una sola historia y de la Definición de Hecho, que se aplica a todo. Entonces veamos primero los criterios de aceptación. Estas son declaraciones breves y específicas que pueden describir lo que tiene que hacer una historia para ser aceptada por el propietario del producto. Van junto a la historia de usuario. Entonces tomemos la historia del contador de racas que escribimos antes. Entonces, como aprendiz que regresa, quiero ver cuántos días seguidos he practicado para que me sienta motivado para seguir adelante Los criterios de aceptación para esto podrían ser los shows de racha en la pantalla de inicio La racha se restablece a cero si se pierde un día. La racha muestra el número actual, no los mejores históricos La racha se muestra correctamente en el teléfono y la tableta. Ahora note que estos son específicos, son comprobables, y están vinculados a esta historia de usuario único No prescriben el diseño, pero te dicen exactamente qué tiene que hacer la cosa terminada. Entonces, una buena regla general aquí es de tres a cinco criterios de aceptación por historia. Si tienes más que eso, tu historia probablemente sea demasiado grande. Ahora veamos la definición de Hecho. Esta es una lista de verificación que se aplica a cada pieza de trabajo que produce el equipo. No es sólo una historia. Es para todos ellos. Una definición típica de Done podría incluir que el trabajo ha sido revisado por pares, el trabajo ha sido probado. El trabajo ha sido documentado en su caso. El trabajo se ha desplegado en un lugar donde los usuarios pueden verla. cualquier criterio de aceptación para Se ha cumplido cualquier criterio de aceptación para la historia específica, y el equipo escribe esta lista y la aplica de manera consistente. Esta es la red de seguridad que atrapa cosas que los criterios de aceptación de criterios podrían faltar. Los criterios de aceptación dirán, esta historia específica hace lo que debería. Una Definición de Hecho dice que este trabajo cumple con nuestra barra de calidad. Para un breve no software, la definición de hecho se vería diferente. Para un evento, podría ser que la tarea esté documentada en el registro del proyecto. Todos los contratos son firmados y presentados. Los costos se registran en el rastreador de presupuesto. Se ha notificado a los interesados afectados. Entonces esta es la definición de hecho para un evento, por ejemplo. Entonces, ¿cómo encajan? Una historia se hace realmente cuando se ambos criterios de aceptación cumplen ambos criterios de aceptación y se satisface la definición de hecho. Ambos, ni uno ni el otro, ambos. Este es el estándar. Una vez que tengas esas dos herramientas en su lugar, esas, si se hace o no, los argumentos deberían desaparecer al final de un sprint. Entonces eso es todo para los criterios de aceptación y Definición de Hecho. A continuación, tenemos un pequeño ejercicio de práctica, que será escribir tres historias de usuario para el brief de su proyecto elegido, completo con un criterio de aceptación. Entonces te veré en la siguiente. 13. Ejercicio de práctica: escribe tres historias de usuarios para tu resumen.: Hola, y bienvenidos de nuevo. Este es el video final de la sección. Vamos a hacer ejercicio de práctica. En el último video, miramos historias de usuarios y criterios de aceptación. En este video, vamos a hacer un pequeño ejercicio donde escribas tus propias historias de usuario. Entonces, al final de esto, tendrás tus primeros artículos atrasados adecuados listos para usar Entonces, lo que necesitarás, todo lo que necesitas es un lugar para escribir, así que usa tu pluma y papel. O si ya configuraste Trello, podrías usar Trello y usar una tarjeta Trello, o puedes usar una página de Notion si prefieres escribir, pero la herramienta aquí o puedes usar una página de Notion si prefieres escribir, pero la herramienta Es más del contenido en el que debemos enfocarnos. Entonces primero, paso uno. Antes de escribir alguna historia, identifica tres tipos diferentes de usuario para tu proyecto. Diferentes usuarios tienen diferentes necesidades, y una buena acumulación debería reflejar esto Entonces, para Edtech, podrías tener un niño que aprende, un padre y un maestro E, estas son tres personas muy distintas, por cierto, así que van a tener tres objetivos diferentes. Para el comercio electrónico, tus tres personas podrían ser un visitante por primera vez, un cliente que regresa y un cliente que regresa un producto. Y para eventos, podrías tener un asistente, un orador y un patrocinador Y nuevamente, cada uno de estos se preocupa por cosas diferentes. Así que elige a tres personas, escríbelas y pausa el video ahora. Necesitas algo de tiempo para pensar. Pasemos al paso dos. Entonces ahora es el momento de escribir las historias. Tienes una historia por usuario. Así que usa esta plantilla como usuario. Quiero meta, entonces esa razón. Una historia por usuario, apegarse a este formato estrictamente. Al principio se siente rígido, pero esta fuerza es un pensamiento claro. Y sí, no tienen que ser las historias más ingeniosas. Solo piensa en las obvias. Qué es lo más básico que cada usuario quiere y empieza ahí. Entonces puedes pausar el video ahora y anotar tus tres historias si necesitas algunos minutos para hacerlo. Paso tres, para cada historia, escribir de tres a cinco criterios de aceptación. Así que recuerda, específico comprobable y atado a esa historia Por ejemplo, si tu historia es, como asistente, quiero un calendario de conferencias claro para que pueda planificar mi día Tus criterios de aceptación aquí podrían ser el horario muestra todas las sesiones con horarios. El horario está disponible en línea antes del evento, y cada sección muestra el nombre del orador. El horario se puede filtrar por pista o tema. Entonces, pausa el video ahora. Puedes agregar criterios, perdón por tus tres historias ahora. Entonces ahí vamos. Ahora deberías tener tus tres historias de usuario y tus criterios de aceptación. Ahora mantén estos a salvo. Los vamos a utilizar de nuevo en la tercera sección. Los usaremos para llenar tu trabajo atrasado. Entonces, bien hecho, has llegado al final de la segunda sección. En la siguiente sección, veremos cómo configurar correctamente tu espacio de trabajo del proyecto. Tan bien hecho por llegar hasta aquí, veré en la sección tres. Bienvenido de nuevo. En esta lección, veremos los tres roles que hacen que los equipos ágiles funcionen. Al final de este video, sabrás quién hace qué y por qué existe cada rol. Aquí nos estamos enfocando en el framework Scrum porque es el más común y las definiciones de roles son las más claras Entonces comencemos. Primero, tenemos al dueño del producto, también conocido como PO. Esta es la voz del cliente en el equipo. Su trabajo es decidir qué construye el equipo y en qué orden. Ellos son dueños del backlog del producto, que es esa lista priorizada de trabajo, y ellos son la persona que dice, Esto es lo que más importa, haz esto Crucialmente, el PO no es el jefe del equipo. No le dicen al equipo cómo hacer el trabajo. Le dicen al equipo qué hacer y por qué importa. El cómo está a la altura del equipo. Un buen propietario de producto pasa tiempo con los clientes. Entienden el negocio y toman decisiones difíciles sobre las prioridades. Dicen que no mucho porque siempre hay más demanda de la que tienen capacidad para. Para el resumen de tu proyecto, podrías estar desempeñando este papel tú mismo, lo cual está completamente bien. Recuerda la mentalidad del propietario del producto, ten claro las prioridades, habla con tus usuarios y haz compensaciones El siguiente papel es el Scrum Master, también conocido como el SM Este rol ayuda al equipo a trabajar bien. Ahora bien, este es uno de los roles más incomprendidos en Agile El Scrum Master no es el encargado del proyecto. No asignan tareas. No rastrean quién hizo qué. No persiguen a la gente por actualizaciones o entregables, y no son el jefe Lo que realmente hacen es ayudar al equipo a trabajar bien. Facilitan las reuniones. Eliminan obstáculos, cosas que impiden que el equipo progrese Entrenar al equipo en prácticas ágiles. También blindan al equipo de cualquier interferencia externa. Una de las mejores analogías aquí es que el Scrum Master es como un entrenador de fútbol. Ellos no juegan el juego. No les dicen a los jugadores cómo patear la pelota, pero crean las condiciones donde el equipo puede rendir al máximo. En equipos pequeños, el Scrum Master a menudo se duplica con otro rol, tal vez el desarrollador senior Toda la responsabilidad es compartida, lo cual está completamente bien. Mientras se haga el trabajo, realmente no importa. El siguiente rol es el equipo de desarrollo. Estas son las personas que realmente construyen el producto. Ahora bien, a pesar del nombre, no se trata solo de desarrolladores de software o programadores El equipo de desarrollo son todos los que realmente construyen el producto. Para el software, eso serían desarrolladores, pero también diseñadores y probadores. Para un proyecto de marketing , serían redactores, diseñadores, comercializadores Para un evento, son las personas de operaciones, los coordinadores de oradores, el gerente del lugar Dos cosas clave sobre el equipo de desarrollo. Una es que se autoorganizan. Nadie les dice cómo dividir la obra. Ellos lo averiguan ellos mismos. Y dos, son cross funcionales. equipo tiene todas las habilidades que necesita para entregar un incremento sin depender de forasteros El tamaño típico es de tres a nueve personas, lo suficientemente grande como para que tengas todas las habilidades que necesitas y lo suficientemente pequeño como para que todos sepan lo que está pasando y quién está haciendo qué. Entonces echemos un vistazo a cómo estos tres roles funcionan juntos. Tenemos tres responsabilidades y muy poca superposición. El propietario del producto decide qué construir. El equipo de desarrollo decide cómo construirlo, y el Scrum Master se asegura que el proceso funcione sin problemas Estos tres roles y responsabilidades tienen muy poca superposición. Y esta claridad es una de las razones por las que Scrum funciona. Todo el mundo sabe de quién es la decisión de quién. Si una parte interesada quiere una nueva función, habla con el propietario del producto. Si un desarrollador está bloqueado, el Scrum Master ayuda a desbloquearlo. Y si el equipo necesita decidir un enfoque técnico, ellos mismos lo deciden. Ahora, en la vida real, especialmente en equipos pequeños, una persona podría hacer dos roles. Podrías ser el propietario del producto y un Scrum Master. O, como dije antes, el desarrollador senior también podría ser el Scrum Master, lo cual es completamente normal Los roles son sobre responsabilidades y no específicamente sobre títulos de trabajo. Así que gracias por acompañarme en esta lección. A continuación, veremos el backlog del producto. Veremos qué va en él, cómo está estructurado y cómo construir uno bueno. Te veré en la siguiente. 14. Cómo configurar tu proyecto: recorrido por Trello: tableros, listas, tarjetas y etiquetas: Hola, y bienvenidos a la Sección tres de nuestro curso de gestión de proyectos. En esta sección, vamos a ver algunas de las herramientas gratuitas que puedes usar para gestionar tu proyecto. El primero que vamos a ver se llama Trello. Se trata de una herramienta gratuita y bastante sencilla que podemos utilizar para gestionar nuestros rezagos de productos, y también podemos gestionar nuestros sprints Así que bastantes de los conceptos anteriores que vimos los estaremos usando en esta sección. Así que vamos a meternos en ello. En primer lugar, voy a repasar los cuatro componentes principales de Trello, y luego abriré Trello y te mostraré un ejemplo de cómo usarlo y sí, te mostraré lo y sí, te mostraré En primer lugar, Trello consiste principalmente en una tabla, de una placa de banda Cam Tenemos un tablero por proyecto. Todo tu proyecto se mostraría aquí. Por lo que todas las historias de usuarios se mostrarían aquí. El tablero consta de listas. En nuestro ejemplo, vamos a utilizar cuatro columnas o cuatro listas que representan las etapas de trabajo. Entonces tenemos el backlog, que serían todas las tareas y todas las historias de usuarios Tenemos que hacer, que serían artículos comprometidos con el sprint. Entonces, cuántos vamos a hacer en este, periodo de dos semanas. Hacer es en lo que alguien está trabajando activamente y luego hecho son todas las tareas que están terminadas y listas para ser celebradas. Entonces sí, el trabajo fluye de izquierda a derecha. Bastante sencillo. Ahora, en cada lista, tendremos tarjetas individuales. Entonces estos son elementos de trabajo individuales o tareas. Tenemos una historia de usuario por tarjeta. Entonces en una tarjeta, ponemos el título sería la historia de usuario. En este caso, sólo vamos a poner el como persona, quiero, y luego pondremos esta sección como título. La descripción incluirá toda la historia de usuario, y también pegaremos un enlace a Notion porque Notion es otra herramienta gratuita que vamos a ver en esta sección, y es posible vincular Notion con Trello Entonces eso es muy útil. Tenemos la lista de verificación, que vamos a llamar criterios de aceptación. Estas son las cosas que hay que completar para que la tarjeta se considere hecha. Y luego tenemos etiquetas con tipo de prioridad y luego la categoría de usuario. Entonces te mostraré las diferentes etiquetas. Estas son las etiquetas de colores que hacen que el tablero sea legible de un vistazo. Tenemos las etiquetas prioritarias, cuales usaremos rojas, amarillas y verdes. Tenemos las etiquetas tipo, y todavía no vamos a usar las etiquetas tipo, y luego tenemos las etiquetas de usuario. Es una buena idea elegir, ya sabes, colores distinguibles en estos sentidos Y otra vez, te voy a mostrar esto cuando miremos el recorrido. Así que de nuevo, mantenerlo sencillo es una buena idea. Es una buena práctica. Cinco a ocho etiquetas, Max. Algo más que eso se vuelve bastante complejo, y probablemente necesitarías una clave para entender cuáles son todos los colores. Entonces vamos a Trello. En Trello, puedes registrarte gratis, y luego una vez que te hayas registrado y tu In Trello, vas aquí a los tableros de sección, y verás todos Habrá uno por defecto aquí, como por defecto como una plantilla Pero queremos crear un nuevo tablero. Entonces, si haces clic en Crear nuevo tablero, el título del tablero aquí, así que solo vamos a poner. El ejemplo que voy a usar es Edtech. Entonces vamos a poner aquí. Sólo lo llamaremos ejemplo. Y luego haz clic en Crear. Y es tan sencillo como esto. Ahora, aquí, entonces tenemos que poblar el tablero con nuestras listas Entonces tenemos el atraso. Si haces clic en Agregar lista, tenemos que hacer, tenemos hacer, y lo hemos hecho. Eso es. Entonces tenemos las cuatro, las cuatro listas. Ahora voy a mostrarles la pizarra que preparé antes. Entonces es exactamente lo mismo, pero he poblado el backlog con algunas historias de usuarios Entonces sí, para poder hacer esto, agreguemos una nueva tarjeta. Entonces voy a llegar a una nueva historia de usuario. Como aprendiz, quiero ganar accesorios para mi avatar. ¿Bien? Entonces agrega esa tarjeta. Ahora, si haces clic en la tarjeta para abrirla, ahora tienes estas diferentes opciones. Pongamos en la descripción, antes que nada, pongamos en toda la historia de usuario. Bien. Como aprendiz, quiero ganar accesorios de mi avatar para que pueda personalizar, siento que es mío, y eso lo guardaremos Y luego para las etiquetas, así que he poblado las etiquetas aquí. Puede hacer clic, crear una nueva etiqueta para disculparlo, para editar la etiqueta. Simplemente haz clic en él. Luego puedes elegir el título, y luego puedes elegir cualquier color. He ido con algunos colores bastante fáciles de distinguir. Vamos a cambiar éste también. Ahí vas. Entonces para éste, digamos que es de prioridad media, y es el aprendiz ¿Bien? Entonces tenemos esas dos etiquetas, y las podemos ver aquí. Y luego vamos a agregar la lista de verificación. Por lo que esta lista de verificación se llamaría criterios de aceptación. Y luego hacemos clic en Agregar, y aquí agregaremos los artículos que deben completarse para completarse para los criterios de aceptación se consideren realizados. Entonces para esto, necesitaremos una biblioteca de accesorios. Firmado. Necesitaremos animaciones para nuevos accesorios, y también necesitaremos biblioteca de sonidos para accesorios. Así biblioteca de efectos de sonido. ¿Bien? Entonces tenemos estas tres cosas, y eso es todo. Así que hemos agregado toda la historia de usuario, hemos agregado los criterios de aceptación, y aquí está. Ahora bien, si es como parte del próximo sprint, lo pondrías aquí en hacer. Um De nuevo, solo tienes que hacer clic en él y arrastrarlo, y es tan simple como eso. O puedes moverlo a hacer. Ahora bien, si lo está haciendo, podrías comenzar a marcar algunas de estas casillas de verificación para demostrar que está hecho Y luego una vez que los tres están hechos, podemos ver que sube al 100%. Si lo cerramos. Tiene tres de cada tres se completan aquí, los elementos de la lista de verificación, para que pueda ver aquí los elementos de la lista de verificación. Si haces clic en él, se expandirá. Puedes mostrar más si quieres. Sí, muy sencillo. Muy intuitivo. Y luego, sí, una vez que esté completo, lo trasladamos a Hecho. Eso es. Entonces así sería como administras tu cartera de productos y, ya sabes, moverás las historias de los usuarios a hacer Ahora bien, si eres el propietario del producto, puedes estar asignando estas tareas al equipo de desarrollo En este caso, harías clic aquí miembros, y luego puedes buscar a los miembros que formarían parte de tu equipo y podrás agregarlos y asignarlos a la tarea. Entonces eso es todo para Trello. En la siguiente sección, tendremos una visión general rápida de Notion. 15. Un recorrido por Notion: páginas, bases de datos y plantillas: Hola, y bienvenidos de nuevo. En este video, vamos a ver Notion, que es otra herramienta gratuita que podemos usar. Para este caso, vamos a usar esto para gestionar nuestros sprints Nuevamente, como hicimos en el video anterior, te voy a dar una visión rápida de Notion y los conceptos de la misma, y luego te llevaré a Notion y te mostraré exactamente qué hacer para construir estas páginas. Entonces, Notion es muy simple. Básicamente es un documento que puede contener otros documentos. Entonces la estructura recomendada sería algo así. Tenemos el encabezado con My Agile Project, y luego debajo de eso, tenemos diferentes subpáginas para cada tipo de documento. Te mostraré exactamente cómo hacer eso cuando mires el recorrido. Otra cosa que puedes agregar son tablas o bases de datos. Entonces es como una hoja de cálculo, pero cada fila es una página Entonces puedes abrir, por ejemplo, donde dice en la columna sprint, tienes sprint uno. Sprint uno cuando hagas clic en eso, nos abriremos a la página de sprint uno, y tendrá más detalles. Y en breve te voy a mostrar cómo hacerlo. Por lo que haces clic en cualquier camino para abrirlo como una página completa. Se trata de los mismos datos. Hay dos formas de mirarlo. Es una mesa escaneable y una colección de páginas detalladas Las bases de datos son extremadamente útiles en Notion, y va a ser una de las principales cosas que uses cuando la uses. Y luego también vamos a echar un vistazo a las plantillas. Entonces, por ejemplo, con las historias de usuarios, esto probablemente tendría la misma estructura cada vez. Así podremos rellenar previamente la estructura de cada nueva entrada. Para una plantilla de planificación de sprint, por ejemplo, tendríamos el objetivo de sprint, los elementos de backlog seleccionados y la verificación de capacidad Y esta sería la misma estructura cada vez que se repetiría para cada sprint. Para que podamos crear esta plantilla y usarla una y otra vez. Entonces echaremos un vistazo a una plantilla de planificación de sprint, y también veremos una plantilla retrospectiva, que son las reuniones que haces después cada sprint donde discutes qué salió bien, qué mejorar y los elementos de acción para el próximo sprint Y luego puedes conectarlo todo usando el letrero at. Para que puedas escribir decidimos esto en premios de racha de decisiones, y eso te vincularía a una página específica, y todo lo que tienes que hacer es hacer clic Bien, así que ahora echemos un vistazo a Notion Ahora bien, esto no va a ser un video en profundidad sobre cómo usar Notion porque eso estaría mucho más allá del alcance de este curso. Notion tiene muchas, muchas características, muchas de las cuales, ya sabes, probablemente nunca vas a usar, pero las más básicas son las que probablemente uses. Entonces puedes encontrar videos en línea para aprender a usar esto. Incluso el sitio web de Notion en sí tiene algunos tutoriales bastante básicos, y eso es todo lo que realmente necesitas saber cómo hacer, para usar bien Notion. Entonces aquí tengo un ejemplo del sprint del proyecto Edtech que he creado en Notion Consta de cuatro páginas. Contamos con planeación de sprint. Tenemos retrospectivas, tenemos decisiones y tenemos actualizaciones de las partes interesadas Entonces, en la planeación de sprint, he creado una nueva base de datos, y he agregado algunas columnas diferentes. Entonces tengo el nombre. el número sprint. Tengo el rango de fechas. Tengo el objetivo sprint, y tengo el estatus. Ahora, cuando abro esta página, también puedo ver algunos detalles diferentes sobre esta etapa del sprint. Puedo ver la capacidad, y puedo ver historias seleccionadas. Aquí tiene un enlace a Trello que te mostraré en un video posterior Tengo una columna aquí para riesgos y dependencias. Entonces cualquier problema que preveas que te pueda bloquear en el sprint, deberías ponerlos aquí abajo, y luego también una sección aquí para compromisos para así que sí, el equipo se compromete con este plan, y luego la fecha de inicio Entonces llenarías esto con diferentes sprints si vas a tener retrospectivas Entonces esta es, nuevamente, otra base de datos que puede utilizar reuniones. Ahora, recomiendo aprender a usar plantillas porque en retrospectivas, va a ser la misma estructura de reunirse una y otra y otra vez Para que puedas crear una plantilla retrospectiva de sprint. Y en esto, se puede poner lo que salió bien. Puedes poner qué mejorar, y puedes poner algunos elementos de acción. Así que acabo de poner algunos ejemplos aquí. El objetivo del sprint estuvo claro desde el primer día, función de estrellas se envió a tiempo. Los stand-ups permanecieron menos de 10 minutos, qué mejorar, subestimamos la complejidad de la animación, necesitamos una definición clara de Hecho para el pulido visual, y los elementos de acción agregan animación revisada por el diseñador a Definición de Hecho y pico en las bibliotecas de animación antes de estimar necesitamos una definición clara de Hecho para el pulido visual, y los elementos de acción agregan animación revisada por el diseñador a Definición de Hecho y pico en las bibliotecas de animación antes Entonces aquí puedes tener una base de datos de todas tus retrospectivas sprint, lo cual en Gestión de Proyectos Ágil es muy, muy importante Es muy importante que esté utilizando estas retrospectivas para informar las decisiones de sus productos La página siguiente aquí se llama decisiones. Entonces aquí tenemos las decisiones en las que hemos actuado después del sprint anterior. Así que aquí he creado una nueva base de datos. He añadido dos nuevas decisiones. He añadido algunas columnas diferentes. Yo tengo la decisión. Tengo la fecha. Yo tengo el por qué, y tengo el quién. Entonces, si abrimos esto, ya podemos ver, la fecha era el 12 de mayo. ¿Quién decidió que era el equipo? El equipo decidió usar la plataforma lottie para las animaciones porque esas animaciones son más ligeras y son más fáciles de actualizar Entonces tenemos el consenso del equipo aquí. Por lo tanto, es bueno hacer un seguimiento de todas tus decisiones porque puedes responsabilizar a las personas por sus decisiones. Solo otro ejemplo aquí, aplazó el tablero de los padres a sprint tres, algo que va a tomar más tiempo de lo que esperábamos Tenemos la fecha, tenemos quien decidió PO, propietario del producto, por qué la capacidad limitada, las características del alumno son una prioridad más alta Entonces las decisiones, por qué se tomaron las decisiones, y quién decidió, todas guardadas aquí. Entonces la última página que probablemente deberías hacer son las actualizaciones de los stakeholders. Entonces aquí, he agregado, nuevamente, otra base de datos con sprint número uno, la fecha en que se envió y a quién se envió. Entonces aquí he creado una nueva página, sprint una actualización al liderazgo. Se envía al equipo directivo. Entonces, ¿se logró el objetivo del sprint? Sí, se enviaron los artículos que se enviaron al sistema de recompensa estrella y a la selección de avatar. Estos son los productos de trabajo que se envían. Se envió el resumen del correo electrónico principal, que hemos movido a sprint Oh, sprint tres, no sprint dos. Y las próximas rachas de enfoque de sprint y recordatorios diarios, Así que las partes interesadas actualizan, con quién has actualizado los avances del proyecto. Puedes guardar todo eso aquí. Entonces, sí, ese es el final de nuestro recorrido por Notion. A continuación, construyendo tu primer backlog. Así que construiremos un nuevo backlog desde cero en Trello. Esto es muy práctico, así que te veré para el siguiente video. 16. Crear tu primer catálogo de productos en Trello.: Hola, y bienvenidos de nuevo. En esta sección, vas a construir tu primer backlog de productos en Trell Esto lo harás desde cero. Ahora, puedes usar el video anterior como referencia, pero te daré la guía paso a paso sobre cómo construir tu primer backlog de productos en Trell Entonces el primer paso es configurar tu tablero, crear el tablero, nombrarlo después del brief que elegiste al inicio de este curso. El segundo paso es agregar cuatro listas, tu backlog para hacer y listo Y luego si quieres, puedes elegir un color de fondo. Puedes personalizarlo. Eso depende de ti. El segundo paso es hacer una lluvia de ideas. Ahora, quieres hacer un volcado de cerebros de todo lo que tu proyecto pueda necesitar. Ahora, aún no es necesario filtrarlo o refinarlo. Así que apunta a alrededor de 15 a 20 artículos en bruto. O sea, si sólo puedes conseguir diez, está bien. O menos, está bien. Solo asegúrate de tener varios. Escriba cada una como una tarjeta de enrejado rápida en la lista de atrasos. Y entonces no te preocupes todavía por el formato de la historia, consígalo todo. Entonces el siguiente paso sería escribir las historias de usuario. Así que convierte esos artículos en bruto en historias adecuadas con los criterios. En ese caso, tal vez dos artículos en bruto se combinarían para ser una historia de usuario. Entonces para ello, abre cada tarjeta, reescribe el título en el como usuario Quiero esto para que pueda formatear. En la descripción, agregue los detalles completos de la historia. Como viste en el video anterior, acabo de usar la sección ASA y Quiero como título, y luego uso todo en la descripción. Debajo de eso, agregarás tus criterios de aceptación con los dos o tres artículos comprobables. Podría ser más. En el video video anterior, teníamos cuatro ítems. Estas serían las cosas que hay que hacer para que esta historia de usuario se considere completa. Y entonces lo último que puedes hacer es refinar primero los cinco a siete artículos del top. Los demás pueden esperar, hacer tantos como quieran, pero no hagan demasiados. Nuevamente, esto es que solo estamos aprendiendo a usar Trello El paso cuatro sería etiquetar y priorizar Así que crea tus etiquetas de prioridad, altas, rojas, medianas, amarillas o naranjas, y la prioridad baja suele ser verde. Agregue etiquetas de tipo o de usuario si es útil. Para mi proyecto EdTech, los usuarios de tres personas diferentes involucradas aquí fueron el maestro, el alumno y el padre Solo puedes tener un usuario o dos usuarios aquí. O más. Entonces deberías arrastrar tus tarjetas de máxima prioridad a la parte superior de la lista de atrasos Este es, ya sabes, el papel típico del propietario de un producto. Priorizas las tareas en consecuencia. Y luego recuerda el valor versus matriz F cuando estás priorizando, las tareas más rápidas suelen ganar y luego finalmente, paso cinco es un refinar y un chequeo de cordura Entonces, antes que nada, ¿ mis cinco artículos principales pasan el acrónimo de invertir? Si solo construyera los cinco primeros, los usuarios estarían mejor, sí o no, y obviamente falta algo. Así que asegúrate de revisar todas esas tres cosas antes de que consideres que tu registro ha terminado Hay algunas trampas comunes que debes evitar. El primero es ser demasiado grande. Nuevamente, no es necesario crear un backlog absolutamente enorme aquí Así que sí, no crees un backlog de 80 artículos que nunca volverás a mirar. Solo apuntar a, ya sabes, 15 a 25 puede ser un poco demasiado. Diez es un buen número. No lo hagas demasiado vago, sé muy específico sobre quién, qué y por qué Y luego finalmente, sí, tenerlo escrito en piedra. Este es un escollo común Agregarás eliminar y reordenar semanalmente. El backlog de productos es algo que se mueve para siempre. Nunca está escrito en piedra. Las cosas siempre van a cambiar. Siempre vas a cambiar incluso los nombres de las columnas que podrías cambiar en algún momento. A continuación, veremos cómo vinculas Notion a Trello. Entonces esto es vincular las dos herramientas en un solo sistema conectado. Te veré para la siguiente. 17. Vincular Notion con Trello para la documentación: Hola, bienvenido de nuevo. En este breve video, vamos a ver cómo vinculas Notion a Trello Entonces, a estas alturas, debería tener su muestra de acumulación de productos incorporada en Trello, y también debería tener su esqueleto de documentación incorporado Te voy a mostrar rápidamente cómo y también por qué vinculamos las dos herramientas juntas. En primer lugar, ¿por qué vincularlos? Trello y Notion, aunque ambos son muy útiles para la gestión de proyectos, ambos se vinculan y se alinean con diferentes modos de pensamiento Entonces Trello es más para ¿cuál es el trabajo? Dónde está, quién lo está haciendo, así que el avance real del día a día de los proyectos. Mientras que la noción es más como información en cuanto a las decisiones que se tomaron. ¿Por qué decidimos esto? ¿Qué aprendimos y cuál es el plan? Noción, siendo una herramienta de documentación suele ser mejor para suele ser mejor para pensamiento a largo plazo y la planeación a largo plazo, mientras que Trello es para la planeación a corto plazo y la gestión a corto plazo de proyectos y sprints Entonces hay dos métodos para vincular Notion y Trello. Primero están los vínculos de Trello en Notion, que son un poco más sofisticados que los enlaces de Notion en Y te mostraré a lo que me refiero en un minuto. Pero antes que nada, haces clic en una tarjeta en Trello, copiaste la URL del navegador Pégalo en tu página de Noción, y luego Notion te mostrará una vista previa en vivo de esa tarjeta. Entonces es un poco más sofisticado donde cuando pegas una vista previa de las cargas de la tarjeta donde pegaste esa URL Método dos, los vínculos de Noción en Trello no son tan sofisticados, y es solo el Link Entonces, para ello, abres la página Noción que deseas vincular. Hace clic en Compartir y copia el Enlace a esa página, y luego lo puedes pegar en descripción de la tarjeta en Trello, lo cual es muy útil Sin embargo, no tiene ninguna vista previa de ninguna tarjeta ni nada, pero cualquiera que tenga acceso a la tarjeta puede hacer clic directamente a través del enlace y acceder a esa página. Entonces, si aún no has construido tu estructura de nociones, hazlo ahora mismo. Entonces deberías tener cuatro subpáginas, una para planeación de sprint, otra para retrospectivas, otra para decisiones y otra para actualizaciones de las partes interesadas Como en realidad, a medida que avancen tus proyectos, estas subpáginas simplemente se harán cada vez más grandes y más, se les agregarán más y más detalles. Entonces es muy importante que tengas, ya sabes, el esqueleto de esta estructura para empezar. Entonces sí, en el próximo ejercicio, veremos armar todo esto, pero antes de movernos rápidamente te mostraré exactamente cómo agregar lo que necesitamos agregar para vincular las dos herramientas. Entonces tenemos nuestro tablero Trello. Tenemos nuestro documento Notion. Y lo que voy a hacer es vincular a Trello a Notion. Entonces voy a copiar un enlace de Trello y ponerlo en Entonces echemos un vistazo a la planificación del sprint. Tenemos este sprint del sistema de recompensas estelares. Voy a abrir esta página. Y tal vez recuerden esto del video anterior cuando abrí esta página, aquí había una vista previa de una tarjeta. Este es el enlace de Trello. Te voy a enseñar cómo hacer esto ahora. Entonces necesito encontrar esta historia en mi tablero de Trello, y la tengo aquí. Como aprendiz, quiero ganar estrellas por completar lecciones. Para vincular esto, todo lo que hacemos es dar clic derecho sobre esta tarjeta, y hacemos clic en este botón aquí, Copiar enlace. Una vez copiada, podemos volver a Notion y luego pegarla aquí. Y como pueden ver, ahora tenemos la opción. Podemos pegarlo como la vista previa. Puedes pegarlo como mención o simplemente podemos pegar la URL. Vamos a pegar una vista previa. Y eso es todo. Entonces, al hacer clic en esto, abrirá la tarjeta directamente en Trello Entonces esto es muy, muy útil. Ahora veamos cómo agregamos cómo agregamos el enlace de Noción a Trello Entonces, si abrimos esta tarjeta, como pueden ver, ya tengo el enlace aquí. Acabo de copiarlo y pegarlo en la descripción. Entonces es bastante sencillo con Notion para copiar y pegar. Haga clic en este. Entonces, sea cual sea la página que quieras vincular En Trello, la abres, haces clic en los tres puntos y haces clic en Copiar enlace. Es tan fácil como eso. Y luego en la descripción, la pegas ahí. Y como puedes ver, es exactamente el mismo enlace. Entonces sí, voy a borrar eso. Y eso es todo. Es tan sencillo como eso. Solo estás copiando enlaces y pegándolos en los lugares correctos A continuación, configurando tu espacio de trabajo, armando todo. Te veré entonces. 18. Ejercicio de práctica: configura tu espacio de trabajo para proyectos.: Bienvenido de nuevo. Por lo que es momento del ejercicio práctico que cierra toda esta sección. Si aún no lo has hecho, vas a configurar el espacio de trabajo completo que usarás para el resto del curso, tu tablero Trello, tu estructura de nociones Entonces, al final de este video y sección, estarás listo para la planificación del sprint en la Sección cuatro. Entonces, si aún no lo has hecho, aquí tienes tu lista de verificación de ocho artículos. Esto es lo que debes haber hecho al final del ejercicio, ocho ítems. Voy a recorrer cada uno rápidamente, y luego puedes hacer una pausa y trabajar a través de ellos a tu propio ritmo. El primero, el tablero de Trello creado y nombrado en honor a su breve segundo lugar hay al menos 15 ítems en backlog como historias de usuario, etiquetas de prioridad creadas y aplicadas Entonces listas con retraso para hacer y hacer, cinco historias principales que tienen verificación de criterios de aceptación Una noción página principal titulada My Agile Project o algo así. Y al menos una página de noción tiene un enlace Trello, y al menos una tarjeta Trello tiene Entonces esa debería ser tu lista de verificación de ocho ítems. Para la configuración de Trello, solo un recordatorio rápido, si hiciste el último ejercicio de lección, entonces todo debería hacerse de todos modos Pero, número uno, asegúrate de que tu tablero exista. Se llama. Tienes las cuatro listas en su lugar. Tienes tu backlog poblado y tienes tus cinco historias de usuario principales refinadas con criterios de aceptación y etiquetas De hecho, recomendaría poner etiquetas en todas ellas porque vas a tener que hacer esto. Configuración de la noción. Así que asegúrate de tener algunas plantillas hechas y de tener tu estructura en su lugar, deberías tener tu página principal con el título, y este es el hogar para todo. Entonces deberías tener tus cuatro subpáginas con planificación de sprint, retrospectivas, decisiones y actualizaciones de las partes interesadas Nuevamente, si quieres estructurar esto de una manera diferente, está bien. La estructura que utilicé es sólo una forma sencilla de hacerlo. Si quieres hacerlo más elegante o más sofisticado. Adelante. Es tu prerrogativa Y por último, intenta crear al menos dos plantillas. Entonces, una para planeación de sprint y otra para retroactiva, así que están listas para usar porque estas van a ser dos plantillas que uses una y otra vez y otra vez Tienes que planear los sprints, y tienes que hacer tu retrospectiva sobre esos Por lo que muy importante para la planeación del sprint es tener esas dos plantillas ya establecidas y listas para funcionar. Entonces tres preguntas antes de que termines. Abra ambas herramientas una al lado y podrá moverse entre ellas con un solo clic. Lo segundo que hay que verificar es, ¿podría alguien nuevo en el proyecto entender tu proyecto en 5 minutos solo de mirar el tablero y solo de mirar la noción Y entonces también podrías preguntarte, ¿obviamente falta algo que creas que necesitarás la próxima semana? Probablemente las plantillas. Las plantillas tal vez algo que podrías olvidar. Asegúrate de tener al menos dos plantillas listas para usar en nuestra sección de planificación de sprint. Eso es para el final de la Sección tres. Hemos envuelto a Trello. Hemos terminado Notion. Tenemos, ya sabes, un poco de huesos desnudos con los que trabajar en nuestra siguiente sección, cual estaremos planeando tu primer sprint. Entonces esta es nuestra inmersión en el trabajo real de planeación de proyectos. Te veré en la Sección Cuatro. 19. Planifica tu primer sprint: prioriza la carga pendiente: Moscú y el valor frente al esfuerzo: Hola, y bienvenidos a la Sección cuatro de nuestro curso de gestión de proyectos. En la Sección tres, analizamos configuración de sus espacios de trabajo en Trello Y ahora llegamos al corazón de Agile, que es decidir qué hacer realmente y en qué orden. En esta lección, cubriremos las dos técnicas de priorización simples y poderosas que puedes usar de inmediato, Moscú y la matriz de valor Entonces, ¿por qué es difícil priorizar? Ahora bien, esta priorización es probablemente la habilidad más dura en la gestión de proyectos en Agile Project Management No es porque las técnicas sean complicadas. Es porque decir puede ser doloroso. Entonces, cada elemento de tu cartera de trabajo le importa a alguien, y cada uno se agregó por una razón Pero la verdad es que no se puede hacer todo. Si intentas hacer todo, no entregarás nada bien. La priorización es la disciplina de aceptar eso y elegir dónde dedicar tu tiempo limitado Las técnicas que cubriremos son solo herramientas para hacer esas elecciones más fáciles y más defendibles Entonces la primera técnica es el método de Moscú. La primera técnica tiene la abreviatura MOSCu. Las letras mayúsculas representan cuatro categorías. Debe tener, podría tener y no tendrá los must haves, sin estos, el sprint o la liberación falla No son negociables. Entonces, por ejemplo, si estás lanzando un sistema de pago, la capacidad de realmente tomar dinero es imprescindible. Si tu evento cuenta con ponentes, entonces tener un escenario es imprescindible. Deberían tener, son importantes, pero el sprint o la liberación pueden tener éxito sin ellos. Puede que les resulte incómodo dejarlos fuera, pero no va a romper las cosas. Entonces, por ejemplo, buen mensaje de error en un formulario de inicio de sesión, es un debe tener. Es agradable, pero puedes enviar sin el producto o trabajar sin él. Podría tener estos son agradables de tener. Son de menor prioridad. Si tienes tiempo, puedes incluirlos. Entonces, por ejemplo, una animación de carga más elegante o una integración bonus, cosas que deleitan, así como una guinda en la parte superior, para que no lo hagan ni Y luego finalmente, no vamos a tener estas son decisiones explícitas de no incluir algo en un sprint o en un lanzamiento. Así que los no tenidos son una opción activa para despriorizar. Documentarlos ayuda a prevenir la fluencia del alcance más adelante. Por lo que la disciplina es un saludable rezago priorizado de Moscú tiene aproximadamente 60% debe, 20% debería, 20% podría Si tienes 80% must haves, no has priorizado. Acabas de volver a etiquetar todo como urgente. Ahora veamos la matriz de valor versus esfuerzo. Lo tocamos un poco en la Sección dos. Ahora vamos a echarle un vistazo en uso correctamente. Entonces para esto, puedes dibujar una cuadrícula rápida de dos en dos. El eje vertical es el valor. ¿Cómo ayudará este artículo a tus usuarios o a tu negocio? Ahora el eje horizontal es el esfuerzo. ¿Cuánto trabajo se necesita para entregar? Y esto te da cuatro cuadrantes. Arriba a la izquierda es de alto valor, bajo esfuerzo, victorias rápidas, hazlas primero. Construyen ímpetu. Desbloquean cosas, y son bastante baratas. No hay razón para retrasarlos. Arriba a la derecha es alto valor, alto esfuerzo, grandes apuestas, hazlas en segundo lugar. Importan mucho, pero se llevan trabajo real. Planee para ellos, descompárelos y hágalos deliberadamente. Abajo a la izquierda, tenemos bajo valor pero bajo esfuerzo. Entonces estos son rellenos. No son críticos, pero son baratos en tiempo y recursos. Ranurarlos entre tus artículos más grandes donde el equipo tenga capacidad sobrante. Y luego abajo a la derecha, tenemos bajo valor y alto esfuerzo. Simplemente tíralos, solo elimínalos. No ganan el tiempo que cuestan. Si realmente importan, volverán y puedes reconsiderarlo Pero una de las trampas en las que caen la mayoría de los equipos es pasar mucho tiempo en el cuadrante Big Bet Grandes características importantes que tardan meses en enviarse, obligarse a encontrar las victorias rápidas, hacer compromisos Esto mantendrá el impulso mientras los grandes apuestan. Usando ambos juntos, ahora debes complementarlos entre sí No deberías estar usándolos en competencia. Funcionan muy bien juntos. Así que empieza con Moscú para categorizar todo tu backlog. Esto te da una rápida idea del progreso. Y ahora toma tus must haves y tus must haves y colócalos en la matriz de valor versus esfuerzo Y esto te dará el orden en que los abordes. Ahora bien, ¿por qué combinarías estos? Porque Moscú te dice lo que importa, el valor versus el esfuerzo te dice qué hacer primero. Así que combinado, obtienes un backlog que está priorizado por importancia y también secuenciado Ahora, aplicándolo a tu brief. Así que abre tu tablero Trello. Lleva tu top 15, tu top ten o 15 artículos. Pasa primero por Moscú. Usa las etiquetas que configuraste en la Sección tres. Entonces agrega cuatro etiquetas de Moscú, rojas para mosto, naranja para calzados, amarillas para bolo, grises para wont, y luego toma tus mostos y cierras y califícalas Las victorias rápidas a la cima de tu lista de backlog, gran apuesta a segundo, rellenos en el medio Cualquier cosa que aterrice a tiro. Archivarlo ahora. No seas precioso con estas cosas. Entonces dos herramientas simples aplicadas, honestamente, esto transformará que planeas y cómo priorizas Así que gracias por acompañarme en esta lección. En la siguiente, veremos la estimación sin mentir con algunos ejemplos usando tallas de playeras y puntos de historia. Te veré en la siguiente. 20. Conceptos básicos de estimación: tamaños de playeras y puntos de historia: Hola, bienvenido de nuevo. La estimación es una de las partes de Agile Project Management que mucha gente se equivoca. Lo tratan como una predicción, y no lo es. Entonces, en esta lección, veremos dos formas honestas de estimar el tamaño del trabajo, las tallas de las camisetas y los puntos de la historia. Así sabrás cómo dimensionar tu backlog sin mentirte a ti mismo ni a tus grupos de interés Entonces primero, qué es la estimación y qué no es, vamos a obtener una cosa directamente desde el principio. Una estimación es una conjetura basada en lo que ya sabes. Esto no es una promesa y no es un compromiso y no es una fecha límite. Esto suena bastante obvio, pero la mayoría de los equipos lo olvidan. Alguien pregunta, cuánto tiempo llevará esto, y el equipo dice tres semanas. Y tres semanas se convierte en fecha. Se convierte en un compromiso. Ahora, el equipo está entrando en pánico, trabajando hasta tarde, cortando atajos o porque alguien confundió una estimación con un contrato Una buena estimación es honesta sobre la incertidumbre. Dice, Esto se siente pequeño o esto se siente grande, y luego usa eso para planificar, no para prometer. Así que las tallas de playera son vagas a propósito. Los humanos son malos en números absolutos. Entonces la primera y más simple técnica de estimación, tallas de playera, extra pequeña , pequeña, mediana, grande, extra grande. Eso es. Sin números, sin horas, sin días. Pero, ¿por qué tan vago? Eso porque ese es el punto. Los humanos son muy malos para estimar en unidades absolutas. Pregúntale a cualquier desarrollador cuánto tardará algo en días, y probablemente obtendrás una respuesta equivocada. Pero si les preguntas es esta pequeña o mediana, y obtendrá una precisa. Entonces, aquí te explicamos cómo usarlo. Por cada artículo en tu backlog, el equipo acuerda una camiseta tallas. Extra pequeño es trivial, pequeño, quizás medio día de trabajo, mediano, uno o dos días, grande es la mayor parte de un sprint y extra grande es demasiado grande, necesita ser desglosado Ahora, ese último punto es importante. Si algo sigue etiquetándose como l, es una señal de que necesita ser dividido en trozos más pequeños. Y cualquier cosa más grande que un solo sprint no es una historia, es una epopeya. Esto necesita ser desglosado. Las tallas de playera son perfectas para principiantes y para trabajos que no son de software. Si estás haciendo breves los eventos, esta es probablemente la técnica con la que comenzaría. Siguiente son los puntos de la historia. Esto es un poco más estructurado, y es más común en los equipos de software. Los puntos de historia son números que suelen seguir la secuencia de Fibonacci Uno, dos, tres, cinco, ocho, 13, 21, yo Fibonacci, es porque las brechas se hacen más grandes a medida que los números se hacen más grandes, lo que refleja cómo La diferencia 1-2 es pequeña. La diferencia 13-21 es enorme porque no sabes realmente lo grande que es ninguno Los puntos de la historia no son nuestros. Los puntos de la historia representan el tamaño relativo de una pieza de trabajo en comparación con otras. A cinco no son 5 horas ni cinco días. Es cinco veces el esfuerzo de una historia de un punto en tu equipo. Para usar puntos de historia, elige una pequeña historia de referencia tu equipo esté de acuerdo que vale, digamos, dos puntos. Entonces estime, todo lo demás relativo a eso es la historia el doble de larga. Es un cinco, la mitad de grande, es un uno. Aproximadamente del mismo tamaño, es un dos. La magia de los puntos de la historia es que permiten tu equipo mida cuánto normalmente entregan por sprint, y esto se llama velocidad. Profundizaremos en la velocidad en el curso dos. Entonces, ¿cómo estimar juntos como equipo? Cualquiera que sea la técnica que elijas, la forma en que realmente haces la estimación La técnica clásica se llama planeación de poker. El equipo se reúne, lee una historia. Todo el mundo elige secretamente una talla o un número, y a la cuenta de tres, todos revelan a la vez. Si todos están aproximadamente de acuerdo, entonces la estimación es lo que todos elijan. Hecho. Si hay desacuerdo, esa es la parte interesante . No lo promedies. Se pide a los estimadores más altos y a los más bajos que expliquen su A menudo, uno de ellos sabrá algo que los demás no saben, por ejemplo, oh, no te diste cuenta que la API no tiene ese campo, tendremos que construirla nosotros mismos. Entonces, después de la discusión, vota de nuevo, y luego usualmente converges Si estás trabajando solo en tu proyecto para este curso, aún puedes hacerlo, estima honestamente. Y cada vez que termines una historia que salió muy diferente a tu estimación, puedes tomar nota de eso. Así es como te pones mejor. Oh, las estimaciones son seres vivos. Un último principio es que las estimaciones no están grabadas en piedra. A medida que aprendas más, los vas a cambiar. Nuevamente, concepto fundamental de Gestión de Proyectos Ágil, por lo que esto es muy saludable. Una historia que dimensionaste como mediana la semana pasada podría parecer pequeña ahora que has hecho una similar. Una historia que pensabas que era extra pequeña resultó ser enorme una vez que empezaste a rascar la superficie de la misma. Entonces eres estimación. No es un fracaso. Aprendiendo y adaptándose. Los equipos que obtienen la estimación correcta son los que tratan sus estimaciones como hipótesis, igual que todo lo demás en Agile. Así que los objetivos de sprint que importan. Esto será en nuestra siguiente lección, una frase, pero está muy centrada en los resultados. Así que gracias por acompañarme para esta lección, y los veré en la siguiente. 21. Cómo establecer un objetivo de sprint que sea importante: Hola y bienvenidos de nuevo. Hasta el momento, hemos hablado de priorizar y estimar, y ahora llegamos a un concepto pequeño pero bastante poderoso, que es el objetivo del sprint Entonces, al final de esta lección muy corta, sabrás qué es un objetivo de sprint, por qué cada sprint necesita uno y cómo escribir realmente uno que enfoque a tu equipo. Cosas muy importantes aquí. Bien, ¿qué es un objetivo sprint? Esta es una frase única pero concisa sobre el resultado de un sprint. Es una frase que describe lo que tu equipo está tratando de lograr en este sprint específico. No qué trabajo vas a hacer. Es el resultado que quieres. El objetivo sprint es la respuesta a la pregunta. Al final de este sprint, lo que será cierto eso no era cierto al inicio. Entonces esto no es una lista ni un hito. Este es un cambio real y significativo. ¿Por qué importan? Entonces tenemos tres razones principales por las que cada sprint necesita un objetivo de sprint. Entonces estos goles importan mucho, pesar de que muchos equipos se los saltan. Uno, enfocan al equipo. Sin un objetivo, cada historia sobre el backlog de sprint parece igualmente importante Cuando tienes un objetivo, puedes ver qué historias realmente lo avanzan y cuáles son como misiones secundarias. Número dos, te ayudan a tomar decisiones a mitad del sprint. Las cosas siempre cambian. Sin un objetivo, cada cambio se convierte en un debate con tu equipo. Con una meta, usted pregunta, ¿este cambio nos ayuda a alcanzar la meta? En caso afirmativo, lo haces, si no, al siguiente sprint o no lo haces en absoluto. Y la tercera razón por que crean un sentido compartido de propósito. La gente trabaja más duro y mejor cuando entiende el por qué. Un backlog de sprint sin objetivo es solo hacer una lista. Un objetivo sprint con un backlog apoyándolo es como una misión principal Entonces, ¿qué hace que un buen gol sprint? Tenemos cuatro cualidades, todas las cuales importan. En primer lugar, se centra en los resultados. Describe lo que cambia, no lo que va a construir. Así que enviar la función de inicio de sesión es una tarea. Los usuarios que regresan pueden acceder a su historial de pedidos es el resultado. A, específico es lo suficientemente específico como para saber que lo has acertado. Objetivos vagos como mejorar la app no ayudan a nadie. Demasiado vago. No obstante, algo así como aumentar la retención del segundo día simplificando el abordaje Tienes algo a lo que realmente apuntar. Tercero es alcanzable. Es alcanzable en el sprint. Si tu objetivo tardaría tres meses, entonces no es un gol sprint. Es como el gol de lanzamiento. Escúchala hacia abajo, así es alcanzable. Y el cuarto es que es una sola cosa. Un gol por sprint, sin excepciones. Si tienes tres goles, en realidad no tienes gol porque ninguno de ellos es la prioridad. Tan importante que solo tienes un gol por sprint. Entonces déjame mostrarte cómo es un buen gol de sprint para cada calzoncillos para Edtech Al final de este sprint, los alumnos de 6 años pueden ganar y ver estrellas después de completar las lecciones. Esto es específico, se centra en los resultados y se puede lograr en dos semanas Observe que no dice nada sobre las características que va a construir. Las historias sobre el backlog de sprint responden a eso. Para el comercio electrónico, al final del sprint, nuestros tres mejores productos ecológicos nuevos están en vivo en el sitio con descripciones completas, fotografía y precios. Nuevamente, es un resultado claro, que es fácilmente verificable en el y para el proyecto de eventos, al final del sprint, los cinco oradores principales se confirman con viajes y alojamiento reservados Tienes un resultado específico y medible. Entonces, si notas el patrón aquí, cada objetivo comienza con al final de este sprint y luego describe un cambio real y observable en el mundo Ahora bien, ¿dónde lo pones? Entonces, la parte práctica, escribe tu objetivo de sprint en la parte superior de tu descripción de Trello o fícalo como una tarjeta en la parte superior de tu lista de tareas por hacer En noción, ponlo en la parte superior de tu página de planeación de sprint, como te mostré antes, todo el equipo debería verlo constantemente. Si está oculto, bien podría no existir. Bien, entonces ese es el final de esta lección. Goles Sprint. Una frase bien pensada puede transformar un sprint. Tan muy, muy importante que escribas sprints claros y concisos todo el tiempo A continuación, tenemos en marcha la reunión de planeación de sprint. Entonces un sprint de dos horas con cinco pasos, una plantilla, y eso es lo siguiente. Entonces te veré. 22. Realiza una reunión de planificación de Sprint (con plantilla): Mm hmm. Bienvenido de nuevo. Así que a estas alturas, ya has priorizado tu backlog Has estimado, has pensado en tu objetivo de sprint. Entonces ahora es el momento de reunir todas esas cosas en una reunión de planificación de sprint. Al final de esta lección, sabrás exactamente cómo organizar una reunión, y tendrás una plantilla que podrás usar para cada sprint una y otra y otra vez. Entonces, antes que nada, ¿qué es la planeación de sprint? Este es de lejos el encuentro más importante del sprint. Lo tienes al inicio de cada sprint, ya que aquí es donde el equipo decide en qué trabajarán las próximas dos semanas. Todo lo que siga a esta reunión depende de las decisiones que tome aquí. sumamente importante. Entonces, la guía clásica aquí es mantenerlo en caja de tiempo 2 horas para un sprint de dos semanas es el estándar. Si es más largo, probablemente estés por encima de planear un poco. Hay un objetivo de sprint acordado, y tenemos cinco pasos en la agenda. Entonces hay dos preguntas que toda planeación de sprint debería responder en este orden. Pregunta uno, ¿cuál es el objetivo de este sprint? Y aquí es donde acuerdas el objetivo sprint que cubrimos en la lección anterior. Ahora, el dueño del producto aquí generalmente lo propondría, y luego todo el equipo discutirá y luego se comprometerá con la y luego la pregunta dos es ¿qué trabajo nos llevará a ese objetivo? Entonces esto es que sacas artículos de tu backlog y los mueves a la lista de tareas Trello Y solo avanzas los artículos que adelantan la meta. Así que sé despiadado aquí Cualquier cosa que no apoye directamente la meta debe permanecer en el backlog para el próximo sprint Y eso es todo. El encuentro responde a estas dos preguntas y termina. Cualquier otra cosa sería una distracción. Entonces veamos la agenda de cinco pasos, que deberías estar usando para cada sprint. Puedes usar esto una y otra vez. Son cinco pasos muy sencillos. primer paso es revisar el objetivo del sprint, tomar alrededor de cinco a 10 minutos para hacer esto. El propietario del producto propone un objetivo, y luego el equipo lo discute, y todos ustedes están de acuerdo. El segundo paso es revisar la capacidad del equipo. Por lo que tarda unos 5 minutos. Sea honesto acerca de cuánto equipo tiene realmente. Entonces, si hay algún feriado o días de enfermedad, alguna reunión, cualquier otro compromiso, nunca debes planear como si todos estuvieran trabajando al 100% porque ese nunca es el caso. La mayoría de los equipos suelen planificar alrededor del 70 al 80% de su capacidad. El tercer paso es seleccionar historias de la acumulación. Esto debería tomar entre media hora y una hora. Puedes recorrer cada uno de tus artículos atrasados priorizados Por cada historia, preguntas, ¿esto avanza el objetivo del sprint? En caso afirmativo, ¿podemos encajarlo en nuestra capacidad? Si puedes, entonces mételo para hacer, y te detienes cuando hayas alcanzado tu capacidad. paso cuatro es verificar el plan, tomar alrededor de diez a 15 minutos. Así que da un paso atrás. ¿Este trabajo que realmente has seleccionado ¿ Realmente logra el objetivo? Si no, deberías intercambiar algunas historias. ¿Hay dependencias obvias? Subrételos ahora, no en el día cinco. Y luego el paso cinco es confirmar y comprometerse. Todos están de acuerdo, toma alrededor de 5 minutos. Todo el equipo dice que sí. Esto es lo que estamos haciendo. Todos salen de la habitación, conociendo la meta, sabiendo exactamente en qué tienen que trabajar y conocer su papel en esa obra. Entonces echemos un vistazo a algunas trampas comunes. Estas son cuatro trampas en las que veo todo el tiempo en que caen los equipos a la hora de planificar. Trate de evitar estos. Entonces el primero es sobrecomprometerse. El equipo siente presión para hacer más, por lo que ponen demasiadas historias en la sección de hacer, y luego no logran entregar. A continuación, lo vuelven a superar en el siguiente sprint para suplirlo, que es un círculo vicioso Así que es mejor comprometerse menos y luego entregar consistentemente. La segunda trampa está planeando a la perfección. La planeación de sprint es una reunión de trabajo, no un interrogatorio Si te encuentras dedicando 15 minutos debatiendo la redacción exacta de un criterio de aceptación, entonces estás en la reunión equivocada Eso sería refinamiento y no planeación. Así que sigue adelante. La trampa tres es saltarse la portería solo recogeremos los artículos y romperemos. No, no, no, no. Sin un gol, el sprint es solo una lista de tareas pendientes. Entonces el objetivo es lo que hace que un sprint sea un sprint. Y la cuarta trampa es la planeación de manera aislada. El propietario del producto no debe escribir el plan y presentarlo al equipo. El equipo necesita planificar juntos. Se comprometen juntos. Esa propiedad compartida es todo el punto. Y nuevamente, la gestión ágil se basa en que las personas que hacen sus propias responsabilicen de su propio trabajo. Ahora la plantilla. Así que abre tu base de datos de planeación de sprint y crea una nueva entrada, una nueva página. Rellena estas secciones para cada sprint. Entonces tu Sección uno, que puedes usar, encabezando tres o encabezando dos, número de sprint y rango de fechas solo para el seguimiento. La sección dos sería el objetivo sprint, que es sólo una frase. Recuerden, enfocados en el resultado. La sección tres es la capacidad. Por lo que no hay días de enfermedad, feriados, ni compromisos de tiempo conocidos, el total de horas o días disponibles para el equipo. Sección cuatro historias seleccionadas, paga los enlaces de la tarjeta Trello por todo lo que te comprometes con las estimaciones si las tienes Sección cinco son los riesgos y dependencias. Entonces, ¿cualquier cosa que pueda bloquear al equipo cualquier peso externo, alguna incógnitas, alguna dependencia de otros equipos Y entonces la Sección Seis sería el compromiso. Entonces solo una línea que diga: Sí, nos comprometemos con este plan con la fecha. Suena tal vez innecesario, pero sí hace una diferencia real. El acto de escribirlo crea rendición de cuentas. Entonces sí, aquí está tu plantilla. Guarda esto en Notion para que cada vez que crees una nueva entrada de planeación de sprint, puedas usarla. 5 minutos de configuración, lo que ahorrará muchos, muchos, muchos minutos y probablemente horas en el futuro. Ahora bien, si trabajas solo, la disciplina sigue aplicándose. Si no tienes un equipo con el que planear, está bien. Corre la reunión tú mismo, bloquea 30 minutos, camina por los cinco pasos, habla en voz alta, si te ayuda. Puede sonar tonto, pero sí ayuda. Sí funciona. El objetivo de la planeación en solitario es el mismo. Estás de acuerdo en lo que estás haciendo, por qué y cuánto. Sigue aplicándose la disciplina de escribirlo, y futuro agradecerás presentarte. Entonces esa es la planificación de sprint para dos preguntas, cinco pasos, una plantilla. En la siguiente sección, veremos backlog de sprint en Trello Nos fijamos en cómo configurar tu tabla de sprint para el trabajo que tienes por delante, que es el siguiente en el siguiente video. Te veré entonces. 23. Crear tu Sprint Backlog en Trello.: Bienvenido de nuevo. Entonces a estas alturas ya has planeado tu sprint. De hecho, vamos a configurarlo en tu Trello. Entonces en esta lección, te voy a explicar exactamente qué hacer en qué orden. Entonces, al final, tienes un backlog de sprint listo para funcionar. Ahora, antes que nada, el backlog de productos versus el backlog de sprint. Es importante que no confundamos a estos dos. Entonces es importante que tengamos una distinción rápida. En realidad, hay dos atrasos en Agile, pesar de que solo decimos la palabra backlog, el backlog de productos es todo lo que podría construirse alguna vez Entonces vive en tu lista de atrasos en Trello. Esto lo construimos en la Sección tres. Esto sería todo lo que requieres para completar. Tu proyecto. El backlog de sprint es un subconjunto mucho más pequeño con el que te has comprometido en este sprint Vive en tus listas de hacer, hacer y hacer. Es una instantánea de un sprint. Así que construir tu backlog de sprint no es crear nuevas tarjetas. Se trata de mover las tarjetas correctas de la cartera de productos a la lista de tareas por hacer Entonces, el primer paso es agregar el objetivo de sprint, fijado en el visible siempre, crear una nueva carta, agregar tu objetivo de sprint a la parte superior de tu lista de tareas por hacer, así que arrástralo hacia arriba En Trello, puedes hacer clic en Agregar una carta, moverla a la parte superior de tu lista de tareas por hacer, hacer una carta llamada meta sprint, pegar tu meta de una oración en el título, agregar una etiqueta de color, algo que sea distintivo, para que destaque de las cartas de historia regulares Podría usar una naranja brillante llamada meta, por ejemplo, o tal vez una negra. Algunas personas prefieren poner el objetivo sprint en la descripción del tablero en su lugar, lo cual está bien. Cualquiera de ellos funciona. Lo importante es que sea visible. El segundo paso es mover las historias para hacer. Así que máxima prioridad en la parte superior. Recuerda esto, los arrastras de tu backlog. Entonces, todas las historias con las que te comprometiste en tu planeación de sprint, vas a mover estas cartas. Así que ve a tu lista de atrasos, encuentra cada tarjeta con la que te comprometiste, arrástrala de backlog a hacer El orden en que los pones importa, pon tu máxima prioridad en lo más alto. Entonces, cuando alguien termina una tarjeta y necesita recoger la siguiente, la elección es obvia. No traigas todo solo con lo que te has comprometido. El resto permanece en el backlog para futuros sprint. paso tres es actualizar los datos de la tarjeta, y quizás también podrías vincularte con Notion y Trello, también Entonces, paso tres, abre cada tarjeta en tu lista de tareas, haz la cordura marca todos los detalles ¿Tiene una historia de usuario adecuada en el título? ¿La descripción tiene algún contexto extra que el equipo necesite o los criterios de aceptación en la lista de verificación? Si has agregado estimaciones, se registran en algún lugar ya sea como etiqueta o como en la descripción de la tarjeta Entonces esta es tu última oportunidad de hacer un chequeo de cordura y refinar antes de que comience la obra Así que no te saltes esta parte. Tarjeta con criterios de aceptación débiles se convierte en un argumento más adelante, y es sólo un ejemplo de mala planificación. paso cuatro es aplicar tus etiquetas si aún no lo has hecho. Entonces nuevamente, recuerden, las secciones anteriores, miramos a Moscú las tallas de playera. Aplica tus etiquetas para mayor visibilidad, agrega etiquetas de Moscú si las estás usando, debes, deberías y podrías. Si has estimado, también podrías agregar las etiquetas de tallas de camiseta, SML o l o etiquetas de punto de historia dos, tres, cinco y ocho, si vas con la secuencia de Fibonacci Estas etiquetas significan que incluso de un vistazo, se puede ver cómo se ve el sprint. Si hay muchas etiquetas de must y tamaños grandes, te has comprometido demasiado, si tienes muchas tarjetas pequeñas, entonces podrías tener alguna capacidad extra Paso cinco, toma una captura de pantalla de tu cartera de sprint ahora mismo antes de que comience cualquier trabajo, guárdala en alguna parte Los mejores lugares en Noción. ¿Y por qué? Porque al final del sprint, quieres comparar lo que te comprometiste con lo que realmente entregaste. La captura de pantalla hace esta comparación, muy fácilmente. También hace un gran artefacto de cartera. Esto es lo que planeamos, y esto es lo que enviamos. Oh, muy importante. Entonces eso es todo para esta sección. El ejercicio de práctica viene a continuación. Vas a planear tu primer sprint ahora que tienes tu oro en la cima y tienes un conjunto comprometido de historias con etiquetas para la visibilidad y también la captura de pantalla. Ya estamos listos para juntarlo todo y concluir la Sección Cuatro. Por lo que los veré en el video final de la Sección Cuatro. 24. Ejercicio de práctica: planifica tu primer sprint: Hola, y bienvenidos de nuevo. Es hora de armar todo. En este ejercicio, vas a planificar tu primer sprint para tu breve elegido, de extremo a extremo. Para cuando termines, tendrás un objetivo de sprint, un backlog estimado y priorizado, y un backlog de sprint comprometido en trello, así como un documento de planificación de sprint en así como un documento de planificación de sprint Y este sería un plan de sprint completo, y ya estás listo para ejecutar esto en la próxima tection. Entonces, antes que nada, cinco pasos. Por lo que el extremo a extremo debería tomar alrededor de 45 minutos. Podría llevarte menos. A lo mejor ya has hecho algunos de estos también. Entonces, el primer paso sería priorizar sus diez artículos atrasados principales usando Moscú, agregue sus etiquetas paso dos es estimar con tallas de camiseta o puntos de historia, que prefieras El tercer paso sería escribir tu meta de sprint con una frase concisa y centrada en los resultados. paso cuatro es tirar todas las historias que adelanten el objetivo a tu lista de tareas pendientes en Trello y comprometerte con una cantidad realista Y el paso final es rellenar tu plantilla de planeación de sprint en movimiento. No te saltes esto. Este es el artefacto que demuestra que has hecho el trabajo y así que vamos a repasar rápidamente cómo se ve bien Aquí hay un ejemplo trabajado de un brief de Ed Tech, para que sepas a qué te apuntas. Objetivo de sprint al final de este sprint, los alumnos de 6 años pueden ver las estrellas después de completar cada lección Para hacer la lista contiene cuatro historias. Historia uno, los alumnos ven animación después de completar la lección. Historia dos, las estrellas se guardan en el perfil de los alumnos. Historia tres, estrellas se muestran en la pantalla de inicio, y la historia cuatro, los padres pueden ver cuántas estrellas se ha ganado su hijo esta semana. Los cuatro adelantan la meta. Los cuatro juntos son aproximadamente dos semanas de trabajo, y la capacidad es honesta. El objetivo es muy específico y las historias lo apoyan. Entonces así es como se ve bien. Y también hay algunas comprobaciones de cordura que puedes hacer antes de llamarlo todo hecho Entonces estas tres preguntas que hacer, la primera si entregué cada historia en mi lista de tareas pendientes, ¿ habría acertado mi meta de sprint? Si no, tienes las historias equivocadas o tienes el objetivo equivocado. número dos es, ¿he sido honesto sobre mi capacidad o me estoy bromeando Es mejor comprometerse con menos y entregar en exceso que comprometerse en exceso y decepcionar a la gente Recuerda esto, esto es clave. Y tres, ¿alguien externo mirando mi tabla Trello entiende este sprint en 30 segundos Si la respuesta es no, tu objetivo no es lo suficientemente visible o no es lo suficientemente claro. Errores a evitar en esta etapa. El primero es saltarse el gol. Saltarse el objetivo porque las historias hablan por sí mismas. No, no lo hacen, no lo hacen. Sin un gol, no puedes decir cuándo estás ganando. Así que nunca te saltes el gol. Dos, meter todos los must en la lista de tareas pendientes sin pensar en la capacidad es un no no. hecho de que algo sea imprescindible no significa que tenga que hacerse en este sprint. A veces un must tiene que esperar el futuro. Y tres, llenar el sprint al 100% de capacidad siempre dejan espacio para lo inesperado. Los sprints reales casi nunca van según lo planeado. Entonces algo más para recordar allí nunca se llenó al 100%. Y eso es que hemos llegado al final de la Sección cuatro, por lo que excelente trabajo por seguir conmigo hasta el momento. En la Sección cinco, veremos los entresijos de correr el sprint. Veremos los stands, las reseñas, los retros y el trabajo en sí Tan bien hecho por llegar al final de la Sección Cuatro, los veo en la Sección Cinco. 25. Correr la Sprint: El stand Up diario: formato, tiempo y trampas comunes.: Bienvenido a la Sección cinco de nuestro curso de gestión de proyectos. Entonces, hasta ahora, has planeado tu sprint. Ahora comienza la obra. En esta lección, cubriremos la ceremonia Agile más conocida, que se llama el stand up diario. Entonces, al final de esta sección, sabrás correr uno en 15 minutos, qué decir, qué evitar y por qué tantos equipos se equivocan. Entonces, ¿qué es un stand? Este es un pequeño sumidero diario del equipo. No es un reporte de estado. Por lo general, son unos 15 minutos. Por lo general, lo tienes a la misma hora, el mismo lugar, todos los días del sprint. Y el nombre proviene de la idea original de que todos literalmente se ponen de pie porque pie mantiene el encuentro corto. Siéntate y hablarás durante una hora. Entonces no es un reporte de estado. No es una reunión donde el jefe controle a la gente. Es un sumidero rápido donde el equipo se alinea sobre lo que está sucediendo Superficies cualquier problema y los justs rumbo si es necesario. Por lo que las tres preguntas principales, cada persona a su vez responderá a estas preguntas con unos 60 segundos cada una. Este es el formato clásico. Entonces cada persona habla a su vez. La primera pregunta es, ¿qué hice ayer? Un resumen rápido de tu progreso. Dos, ¿qué voy a hacer hoy, qué estás recogiendo? Tres es lo que me está bloqueando. Entonces, si hay algún obstáculo o alguna duda o dependencia, esto se trata ahí Y cada persona debe responder a las tres en aproximadamente 60 segundos. Con un equipo de cinco, serán 5 minutos. Y los 10 minutos restantes son para las conversaciones reales, las cosas que surgen por lo que la gente acaba de decir, y ahí es donde radica el verdadero valor en estas reuniones. Entonces, la guía más reciente de la guía Scrum se centra menos en las tres preguntas y más en la meta ¿Cómo podemos, como equipo, hacer el mayor avance hacia el objetivo del sprint hoy en día? Ambos enfoques funcionan. Las tres preguntas son más fáciles a la hora de empezar. Puede desarrollar su propio enfoque a medida que pase el tiempo . Tenemos tiempo y logística. Aquí hay algunas cosas prácticas que hacen que los stand-ups funcionen. Entonces, antes que nada, cronometrarlo 15 minutos como máximo, establece un temporizador cuando se apaga, te detienes, aunque sea a mitad de frase. La presión del temporizador obliga a tu disciplina. Deberías tenerlo a la misma hora todos los días. Elige una hora que funcione para todos. Común es 930 o 10:00 A.M. Porque les da tiempo a los arrancadores tempranos para instalarse, pero no pierde la mañana. Y no lo pongas a las 4:00 P.M. Para entonces, la mayor parte del día ya no está. Debe estar en el mismo lugar, ya sea físico o virtual, una ubicación predecible es muy importante. La mayoría de los equipos remotos suelen utilizar una videollamada diaria. En persona, todos ustedes deben reunirse alrededor del Cambanbard Y o para control remoto, al menos mantén tus cámaras encendidas. La energía es un poco diferente de esta manera, y las personas se mantienen enfocadas cuando están de pie. Entonces, finalmente, es caminar por el tablero, no por la gente. Este es un cambio sutil pero importante. En lugar de dar la vuelta al equipo como Sarah va a continuación, luego James, caminar a través de las tarjetas en las listas de hacer y hacer. Y por cada tarjeta, habla la persona que trabaja en esa tarjeta específica. Y esto mantiene el foco en el trabajo, no en los individuos. Algunas trampas comunes, algunas cuatro formas que los stand-ups salen mal, evítelos Evite convertirlo en un reporte de estado. La gente habla con el gerente o el líder del proyecto enumerando lo que han hecho en detalle defensivo. Esta es la audiencia equivocada. El stand up es para el equipo, no para el jefe. Habla con tus compañeros. La segunda trampa, problemas en la reunión. No resuelves bloqueadores en esta reunión. Si alguien menciona un bloqueador, lo guardamos para un tiempo posterior. El equipo comienza a generar soluciones de lluvia de ideas, y 20 minutos después, sigues ahí . Así que no hagas esto. El stand up es para salir a la superficie problemas, no para resolverlos. Trampa tres, saltándose la reunión cuando está ocupado. Si hoy estamos demasiado ocupados para hacer el stand up, esto es exactamente cuando más lo necesitas. Por lo tanto, los equipos ocupados suelen estar ocupados porque no están coordinando lo suficientemente bien. Saltarse el stand up solo hace que eso sea aún peor. Es como un círculo vicioso Así que no te saltes este stand up diario. Y por último, Trap four está cancelando cuando la gente está en remoto Solo publiquemos actualizaciones en Slack ahora. Es decir, esto está bien por un día, pero lo haces por todos los días de la semana, entonces el equipo perderá su sentido compartido del sprint, y el punto del encuentro es la coordinación en vivo, no la actualización escrita. Entonces, si estás haciendo este solo, aquí tienes alguna adaptación que puedes hacer para proyectos en solitario. Los trabajadores en solitario aún se benefician de un registro diario. Tómate 5 minutos cada mañana para abrir Trello, mira tu tabla, pregúntate, ¿qué hice ayer? ¿Qué voy a hacer hoy? ¿Qué me está bloqueando? Escríbalo en alguna parte, incluso solo en una entrada rápida de Notion, está bien. Puede sonar ridículo hablar contigo mismo, pero el acto de articularlo surge problemas que de otra manera ignorarías Así que pruébalo por lo menos una semana y ya verás cómo está. Así que a continuación, tenemos trabajo de visualización que hacer haciendo y hecho El flujo de tres columnas que configuramos en Trello. Nos sumergiremos en esto con más detalle en el siguiente video. 26. Visualizar el trabajo: Qué hacer y logro.: Hola, y bienvenidos de nuevo. La idea Ágil más simple y poderosa que jamás hayas contrarrestado es esta. Hacer visible la obra. En esta breve lección, cubriremos el flujo de tres columnas que impulsa cada placa Agile y cómo usarla bien. Entonces, ¿por qué visualizar? Aquí hay tres razones que hacen que la visualización sea muy poderosa. Número uno, no puedes manejar lo que no puedes ver. Si el trabajo vive en la cabeza de las personas o en hilos de correo electrónico, es invisible. No sabes dónde están las cosas atrapadas, qué está sobrecargado, quién está sobrecargado o cuáles dos, crea conciencia compartida Todo el equipo puede ver la misma imagen. No más. No sabía que estabas haciendo esto. No sabía que estabas trabajando en eso. Todo el mundo sabe en qué está trabajando todo el mundo. Tres, atiende cualquier problema de flujo. Entonces, cuando puedes ver todo el trabajo en un solo lugar, los patrones saltan, las tarjetas se amontonan al hacer, las tarjetas atrapadas en la revisión, los largos retrasos entre listas Cada patrón apunta a algo que arreglar. aquí tenemos las tres listas para hacer, hacer y hacer. En cada tablero de Agile, estas tres listas hacen el trabajo pesado. Para hacer es trabajar comprometido para este sprint, pero aún no iniciado. Las tarjetas solo están esperando ahí. Lo primero de la lista es lo que alguien debería recoger a continuación. Hacer es trabajar activamente que se está haciendo ahora mismo. Aquí es donde está la atención del equipo. Y críticamente, el trabajo sólo entra en hacer cuando alguien realmente está trabajando en él en ese momento. No, hoy voy a llegar a ella más tarde. Lo están haciendo ahora mismo. Hecho es trabajo que está terminado, así que el trabajo que está debidamente terminado, no 90% hecho, no pendiente de revisión, está hecho. Está en caja. Entonces estas tres listas lado a lado, te dan una imagen en tiempo real de cómo está progresando el sprint Entonces, el trabajo en progreso limita. Este es un poderoso consejo que la mayoría de los principiantes pueden perderse. Es limitar cuántas cartas se pueden sentar en hacer a la vez. Ahora bien, a esto se le llama límite de trabajo en curso o límite de WIP ¿Por qué? Porque nada mata el progreso como tener demasiadas cosas que están a medio hacer. Si cinco personas tienen tres cartas en curso, tienes 15 cosas en vuelo a la vez, y casi seguro que nada se está acabando. Entonces, una buena regla general aquí no es más de una tarjeta en hacer por miembro del equipo. Algunos equipos usan N más uno, por lo que un equipo de cinco tiene seis espacios WIP El número exacto importa menos cuando el principal terminó las cosas antes de comenzar las nuevas. Entonces, si estás trabajando solo en tu proyecto, tu límite de WIP es uno Escoge una historia, trabaja en ella, termina y luego elige la siguiente. Resista el impulso de rebotar. Por último, una vez que tengas una tabla en marcha, aprende a leerla. Entonces hay tres cosas principales que buscar día a día. Una es el desequilibrio. Una lista abultada para hacer significa que hay demasiado trabajo en progreso Una lista vacía hecha en el punto medio del sprint significa que no se está terminando nada Dos son las tarjetas que no se han movido en días. Estas son tarjetas pegadas. Averiguar por qué están atascados. Por lo general, es un bloqueador que no se ha levantado en un stand up diario. Tres son tus cartas sorpresa, cosas que aparecen al hacer que no formaban parte del plan de sprint original. Estos son los asesinos silenciosos de cualquier gol sprint. Así que afértalos, decidamos que tenemos sus prioridades reales o si en realidad son distracciones que deberían dejarse para después Oh, tres columnas. Un límite de progreso de trabajo, un hábito de leer el tablero, y eso es todo. Así que gracias por acompañarme para esta lección. En la siguiente, veremos manejo del cambio mid sprint, lo que sucede todo el tiempo. Es algo que cualquier gerente de proyecto Agile tiene que ser hábil en hacer. Entonces repasaremos tres preguntas que protegen la meta, y esto es lo siguiente. Entonces te veré en el siguiente video. 27. Manejo del cambio a mitad del Sprint: Hola, y bienvenidos de nuevo. Ahora, para ser honesto, ningún sprint realmente va según lo planeado. Algo siempre cambia. Entonces, en esta lección, vamos a ver cómo puedes cubrir los cambios de mid sprint sin entrar en pánico, sin perder la concentración, y lo más importante, sin abandonar tu objetivo original Entonces esto es algo a lo que acostumbrarse con la gestión de proyectos Agile. El cambio no es fracaso. Esto es completamente normal. Cada sprint, surgirá algo que no estaba en el plan. partes interesadas podrían cambiar de opinión, un usuario podría reportar un error crítico, tal vez una dependencia fracasa, tal vez surja una nueva oportunidad. Ahora bien, el Manifiesto Agi da la bienvenida explícitamente al cambio. Entonces, si recuerdas el valor cuatro del manifiesto, está respondiendo al cambio sobre seguir un plan Ahora bien, eso no quiere decir que el cambio sea siempre bueno o siempre aceptable mid sprint. Simplemente significa que tienes un proceso para manejarlo en lugar de fingir que no va a suceder Esto es clave para los gestores de proyectos. vamos a pasar por un pequeño marco de decisión. Ahora, cuando una solicitud de cambio aterriza a mediados de sprint, este es un framework simple que puedes usar. Tenemos tres preguntas en regla. La primera pregunta es, ¿ este cambio nos ayuda a alcanzar la meta del sprint? En caso afirmativo, entonces podría valer la pena hacerlo. Ahora, yo no, entonces va al backlog del producto para un futuro sprint. Pregunta dos, sí ayuda, ¿qué tendríamos que dejar caer para darle espacio? La capacidad siempre es finita y no puedes simplemente agregar trabajo, así que tienes que hacer un compromiso en alguna parte Y la pregunta tres es, ¿el equipo está de acuerdo en que vale la pena el intercambio? Si todo el equipo decide, no solo el dueño del producto, al final del día, ellos son los que hacen el trabajo. Si la respuesta a estas tres preguntas es sí, entonces puedes intercambiarla. Puedes agregarlo a la lista de tareas por hacer. Si no, entonces deberías empujarlo al backlog. Ahora bien, la disciplina de usar este framework cada vez es lo que va a proteger tu objetivo sprint. Ahora bien, no todos los cambios nacen iguales. Hay tres categorías rudas que podríamos usar aquí emergencias. Por ejemplo, el sitio está caído, un error crítico está golpeando a los usuarios o acaba de llegar un problema legal, y estos realmente no pueden esperar. Así que deja algo y cámbialo. Pero sea honesto, las emergencias reales son bastante raras. Si todo es una emergencia, entonces nada es una emergencia. A continuación, tenemos importantes pero no urgentes. Entonces, por ejemplo, una nueva idea de característica o un cambio de mercado interesante o solicitud de partes interesadas que importa pero que realmente no rompe nada. Estos pueden entrar en el backlog del producto, agregar una tarjeta y priorizarlos para el próximo sprint. No interrumpas y luego brillantes distracciones cuando alguien tiene una nueva idea, lo cual suena genial, pero no está realmente vinculado al objetivo del sprint, cortésmente lo puso en el backlog y La mayoría de las solicitudes de mid sprint caerán dentro de esta categoría. Ahora bien, cómo decir que no, bastante difícil como gerente de proyecto. La gente odia escuchar no, y vas a odiar decirlo. Entonces aquí hay tres técnicas que te ayudan a no quemar un puente. Entonces uno es sí en el backlog. Así que no le digas no a la idea en sí, sino que di sí a capturarla. Ese es un gran punto. Permítanme agregarlo al backlog que podamos priorizarlo correctamente. Eso validará la idea sin comprometerse con ella. Dos, refiérase al marco Quiero asegurarme de que llegamos a nuestro objetivo sprint, que es X. Esta nueva solicitud no soporta directamente eso. Entonces, ¿podemos verlo en la próxima reunión de Prints? El objetivo se convierte en la razón, no en su preferencia personal, y tres es el comercio abiertamente. Entonces, bueno, podemos hacer esto ahora, pero significa dejar caer Y. ¿ Estás de acuerdo con eso? Por lo que de pronto el solicitante tiene que sopesar el costo de su solicitud, no sólo el beneficio Y muchas veces decidirán que puede esperar más tarde. Lo siguiente es documentar la decisión. Lo que decidas, escríbalo, agrégalo a tu base de datos de decisiones de noción, pon la fecha, lo que se solicitó , qué decidimos y por qué. 2 minutos de escritura esto ahorrará horas de por qué no lo hicimos en reuniones posteriores. Recuerda, el cambio va a suceder. Lo más importante es proteger la meta sprint y tener un marco establecido y también documentar la decisión. Entonces, a continuación, veremos la revisión del sprint, mostrando el trabajo real. Estas revisiones involucran a las partes interesadas. Implica retroalimentación, e implica algo de honestidad. Entonces veremos eso en el siguiente video. 28. La revisión del Sprint: mostrar el trabajo real a las partes interesadas.: Bienvenido de nuevo. Entonces se acabó el sprint. Ahora es el momento del momento de la verdad, que está mostrando tu trabajo. En esta lección, cubriremos la revisión de sprint, que también se llama demostración de sprint, y al final, sabrás cómo llevar a cabo una de estas reuniones que realmente informa a tus grupos de interés en lugar de simplemente actuar para ellos. Entonces, ¿qué es una revisión de sprint? La revisión de Sprint es una reunión que se lleva a cabo al final de cada sprint. Es increíblemente importante ya que estas son las reuniones donde el equipo muestra el trabajo que han realizado a los grupos de interés. Los stakeholders son las personas que se preocupan por el proyecto pero en el equipo, así que ese podría ser el gerente, podría ser un cliente, podría ser algunos patrocinadores internos, o podrían ser los usuarios reales. lo general, es de 1 hora para un sprint de dos semanas, y hay dos propósitos para estas reuniones. Una es demostrar lo que se ha construido para comprobar que cumple con las expectativas y que funciona. Dos, es recopilar comentarios que informen el próximo backlog del producto y el siguiente sprint Ahora bien, este no es un reporte de estado. Es una conversación sobre resultados reales de trabajo que su equipo ha producido. Entonces hay tres reglas que debes seguir sobre lo que debes mostrar en estas reuniones. Número uno, muestra la salida de trabajo, no diapositivas sobre la salida de trabajo. Si crea una función, demuestre la función real en un dispositivo real o en una pantalla, demuestre que está funcionando. No hagas una plataforma de 30 diapositivas describiéndola. El punto aquí es que realmente funciona , así que demuéstralo funcionando. Dos es empatar todo de nuevo al objetivo original del sprint, abrir con el gol, caminar por cómo cada pieza de trabajo contribuye a ese objetivo, de trabajo contribuye a ese objetivo, y cerrar diciendo si el objetivo se logró o no. Y tres, solo muestra lo que se hace hecho por tu definición de hecho. No esto es 80% fijo. Lo sentimos, esto está 80% completado, o solo necesitamos arreglar algunas cosas. Tiene que ser un verdadero trabajo terminado que esté 100% hecho. Si no está hecho, déjelo fuera. Puedes mencionarlo en la sección sobre lo que no se terminó, pero no demostremos cosas que no están completas. Ahora, deberías tener una agenda de 60 minutos, que podrás reutilizar para cada sprint. Así que el minuto cero al cinco es una bienvenida y recapitular el gol del sprint, conseguir que todos en la sala estén orientados minuto cinco al 35 sería tu demo para cada historia terminada, cinco a 7 minutos por historia, mostrarla funcionando, explicar el contexto y luego hacer preguntas. El minuto 35 al 45 es lo que no se terminó. Sea honesto sobre lo que aún está en progreso y por qué esto genera confianza y esconder algo lo destruye. A 45 a 55 comentarios de los interesados, abra la palabra para preguntas. ¿Qué opina el público? Qué les gustaría a continuación, capturar todos los datos que puedas escuchar y no hacer ninguna promesa. Y entonces los últimos 5 minutos serían para concluir, recapitular los comentarios clave, acordar acciones y terminarlo a tiempo Entonces manejando bien los comentarios, aquí es donde la mayoría de los revisores se equivocan. Las partes interesadas dan retroalimentación. El equipo se pone a la defensiva, o el equipo acepta cada solicitud como promesa. Ambos son malos. Un mejor enfoque es escuchar primero. No estés a la defensiva. No se comprometa, lo escuche, lo escriba en un tablero visible en Notion, o frente a los stakeholders. Gracias, capturando eso. Eso es lo que puedes decir. Después de la reunión con el equipo, decide qué hacer con cada comentario. Algunos artículos se convertirán en nuevos artículos atrasados. Algunos podrían estar refinando historias existentes. Entonces podría ser interesante pero no procesable, lo cual está bien. Simplemente no hagas promesas en la habitación. Añadiremos que al siguiente sprint hay una trampa que debes evitar. Aún no sabes si debe ser una prioridad o no, así que no lo prometas. Capture la solicitud y decida más tarde cuando esté planeando. si estás trabajando solo en este curso, aún necesitas un stakeholder. Así que encuentra uno o sé uno. Puede ser un amigo, podría ser un colega, podría ser un socio, cualquiera que tenga paciencia y curiosidad por ti y tu proyecto. Programe un espacio de 30 minutos, camine a través de su objetivo de sprint, demuestre sus historias completadas y haga las tres preguntas. ¿Esto se ve bien? ¿Qué te sorprendió? ¿Y qué querrías después? Incluso una persona no relacionada puede surgir comentarios útiles solo por ser un par de ojos frescos Así que toma notas, esta es una práctica ágil adecuada, pero reducida a un usuario en solitario Entonces son reseñas de sprint, muestran trabajo real. Se reúnen en sus comentarios. Nunca debes prometer en el acto. Entonces a continuación vamos a mirar la retrospectiva, que es la oportunidad del equipo de mirar hacia adentro y de mejorar Te veré para el siguiente video. 29. La retrospectiva del Sprint: "Comienza, deténte, continúa": Bienvenida de nuevo. Entonces, la revisión de sprint que acabamos de mirar mira hacia afuera lo que construimos, mientras que la retrospectiva del sprint mira hacia adentro y mira cómo trabajamos Entonces, en esta lección, repasaremos el formato retrospectivo más simple y popular, que es iniciar, detener y continuar Entonces, al final, sabrás cómo llevar a cabo una de estas reuniones que realmente cambia la forma en que trabaja tu equipo. Entonces, ¿qué es una retrospectiva? Esta es una reunión al final de cada sprint justo después de la revisión, donde el equipo reflexiona sobre cómo trabajan juntos durante el sprint. No hablan de lo que construyeron. Hablaron de cómo trabajaban. Entonces esto suele ser de 45 a 60 minutos si es un sprint de dos semanas. Solo el equipo sin partes interesadas, por lo que este es un espacio seguro donde el equipo puede ser honesto sobre lo que está funcionando y lo que no funciona. Y el principio detrás de esto es del principal 12 del Manifiesto Ágil, que afirma a intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo, luego afina su comportamiento en consecuencia La retrospectiva es cómo sucede eso en la práctica. Entonces el formato retrospectivo más simple tiene tres columnas en una pared o en una tabla Comienza, detente y continúa. Así que empieza. Esto es cosas que el equipo debería empezar a hacer y que no están haciendo ahora. Tal vez comenzar a escribir criterios de aceptación antes de estimar o iniciar un check in de cinco minutos a mitad del sprint. Detener. Son cosas que el equipo debería dejar de hacer, tal vez dejar de aceptar cambios después de planear o dejar de sostener stands ups cuando el dueño del producto no puede asistir, cosas como esta, y luego continuar o cosas que el equipo está haciendo bien y debería seguir haciendo. Entonces tal vez seguir almorzando juntos los miércoles o continuar actualizando la junta diariamente, lo que sea que el equipo piense que funciona que les va bien Entonces cada persona puede agregar notas adhesivas a cada columna, y luego el equipo lo discutirá. Los grupos pueden elegir temas similares, elige los más importantes para actuar en el próximo sprint. Entonces, cómo llevar a cabo este tipo de reuniones. Aquí hay una agenda de cinco conjuntos para una retrospectiva de 45 minutos. El primer paso es establecer la escena a unos 5 minutos. Recuérdele al equipo para qué sirve un retro, establece el espacio. La regla de Vagas es que lo que se dice en lo retro se queda en lo retro Paso dos, escritura silenciosa. Entonces, 10 minutos, todos escriben sus artículos de inicio, parada y continuación de manera independiente. Sin discusión. Esta tranquila sesión de escritura saca a luz opiniones honestas sin grupo. El paso tres es compartir y agrupar. Por lo que esto debería tomar unos 10 minutos. Cada persona lee sus artículos. Agrupamos artículos similares juntos. No los debatan todavía. Esta es una parte de categorización de la reunión. paso cuatro es discutir los temas principales, tómate unos 15 minutos para esto. Puedes para que cada persona obtenga tres puntos, pegarlos en los artículos que más importan, como un proceso de votación. Y luego, cuando hayas terminado, habla de los tres primeros. Cinco es acordar acción. Entonces, para cada uno de los primeros rubros, acordar acciones concretas, quién hará qué, para cuándo. De lo contrario, lo retro se vuelve como terapia con mucha charla y sin cambios. Entonces acuerden esas acciones, quién, qué, y para cuándo. Por lo que una retrospectiva solo es útil si las personas son honestas y las personas solo son honestas si se sienten seguras Entonces tres cosas ayudan. Uno, sin culpa. La norma Kurth prime directiva dice, independientemente de lo que descubramos, entendemos y realmente creemos que todos hicieron el mejor trabajo que pudieron, dado lo que sabían en ese momento Lee esto en voz alta al inicio de cada retrospectiva porque esto marcará la pauta para el equipo Dos, no debería haber directivos en el equipo. Si tienes un gerente de línea que no está en el equipo en sí, no atienden porque gente no puede ser honesta si ese es el caso. Entonces sí, no puedes ser honesto sobre cómo reacciona la gente con el gerente cuando los gerentes están en la habitación. Entonces no hay gerentes. Por último, es enfocarse en el sistema, no en la gente. Entonces, ¿por qué sucedió esto? ¿Por qué Sarah hizo esto? Este principio ágil es que las personas buenas pueden quedar atrapadas en sistemas malos, así que mejora el sistema. Tienes algunos otros formatos para probar. Entonces, si tu stop start se siente rancio, puedes mezclarlo. Por lo que cubriremos esto adecuadamente en el tercer y el curso más avanzado. Pero aquí hay un catador rápido de tres alternativas. Nos hemos vuelto locos, tristes y contentos. Entonces la gente escribe lo que los volvió locos, tristes o contentos en este sprint superficies en movimiento que el formato de inicio, parada, continuación a menudo puede aplanar Tenemos los cuatro s gustados, aprendidos, faltados, anhelados, más reflexivos, especialmente para grandes Por último, velero. El equipo es un barco. ¿Qué viento nos empujó hacia adelante? ¿Qué anclas nos detuvieron? ¿Qué rocas debemos evitar? Esto es bastante lúdico y visual y bueno para equipos distribuidos. Pero vamos a profundizar más en esto en el curso tres. Entonces, eso es todo. Retrospectivas, espacio corto, seguro, centrado en la acción. Los equipos que más mejoran son los equipos que hacen bien las retrospectivas Entonces en la siguiente sesión, haremos un ejercicio de práctica donde correrás un mini sprint de cinco días y experimentarás el ritmo de un sprint de extremo a extremo. Te veré para el video final de la Sección cinco. 30. Ejercicio de práctica: realiza un mini-sprint de cinco días.: Bienvenido de nuevo. Por lo que llegamos ahora al ejercicio de práctica más ambicioso hasta el momento. Vas a correr un sprint real. Lo comprimiremos a cinco días, pero es real en todas las demás formas. Así que planifica, ejecuta, revisa y retro. Al final, habrás vivido un ciclo completo de sprint y tendrás los artefactos para demostrarlo. Así que vamos a meternos en ello. En primer lugar , por qué un mini sprint. Los sprints estándar suelen durar dos semanas. Para este ejercicio, lo comprimiremos a cinco días, de lunes a viernes. Lo haremos porque el objetivo del ejercicio es sentir el ritmo de una planificación de sprint, el progreso diario, los ajustes de mid sprint, la revisión y lo retro. Cinco días son suficientes para experimentar todo eso sin comprometer semanas de tu vida. Así que mantén tu alcance pequeño, apunta a dos o tres pisos en total. El objetivo es el ciclo, no el volumen. Por lo que el lunes lunes por la mañana, bloquear 30 minutos para planeación de sprint. Usa la plantilla de la Sección cuatro, si puedes, escribe tu objetivo de sprint, elige dos a tres historias de tu acumulación y luego avísalo Muévalos a tu lista de tareas pendientes, aplica las etiquetas y toma una instantánea inicial. Entonces deberías comenzar la obra. Entonces, al final del lunes, deberías tener algo en la columna de hacer, idealmente, algo hecho también. De martes a jueves, este será el ritmo diario donde construyas el hábito. Tenemos tres días hábiles. Entonces sí, martes, miércoles, jueves. Cada mañana, 5 minutos solo de pie. ¿Qué hice ayer? ¿Qué voy a hacer hoy? ¿Qué me está bloqueando? Puedes escribir las respuestas en una nota de noción rápida. Asegúrate de fechar cada entrada. Cada día, actualiza tu tablero Trello. Las tarjetas pasan de hacer a hacer a hacer a hecho no acumulan trabajo en hacer. Algo intenta interrumpir, usa el framework de cambio que vimos en la Lección tres, si ayuda a sprint goal, si no lo atrasa Si lo hace, entonces ¿qué se deja caer para darle espacio? Apunta a terminar al menos una historia para el miércoles. Si para el miércoles no has terminado nada, entonces esa es una señal de que te has comprometido en exceso Alcance reducido ahora. Y luego el viernes por la mañana, aquí es cuando tendrás la reseña. Así que toma unos 20 minutos para ejecutar tu revisión de sprint. Consigue un stakeholder si puedes, un amigo, un compañero, ex colega, charla GPT, guiarlos a través de lo que has construido, muéstralo, pero no lo describas Si no hay nadie disponible, hágalo por su cuenta. Grábate haciendo la demo. En un video telefónico. Simplemente describiendo el entrenamiento en voz alta, agudiza tu pensamiento, captura los comentarios en Notion, graba todo ahí Las nuevas ideas deben entrar en tu cartera de productos como tarjetas en Trello Y luego el viernes por la tarde, después de haber tenido la revisión, entonces tendrá su retrospectiva, que nuevamente es de unos 30 minutos Aunque estés haciendo esto por tu cuenta, debería funcionar. Open Notion, cree una nueva entrada en su base de datos de retrospectivas, use la plantilla que creó Las columnas, inician, paran y continúan. Dedica 10 minutos escribiendo artículos en cada columna y sé honesto. Deja de revisar las noticias a mitad de tarea, por ejemplo, otra, comienza a bloquear sesiones de trabajo profundo de 90 minutos, continúa cerrando pestañas al final del día y luego elige las tres cosas principales sobre las que actuar para el siguiente sprint y escríbelas como acciones concretas. ¿Quién, qué y cuándo? Etiqueta tu entrada retro con el número sprint. Quieres mirar hacia atrás a estos en dos o tres sprints tiempo para ver si realmente hiciste algún cambio Entonces algunos errores comunes a evitar, tres cosas a evitar en tu primer sprint. Los principiantes los hacen bastante. El primero se está comprometiendo en exceso el primer día, por lo que es mejor comprometerse menos y luego entregar en exceso que comprometerse en exceso y entregar El segundo es saltarse los stand-ups cuando estás solo. Sólo soy yo. Sé lo que estoy haciendo, pero a lo mejor no disciplina de articular tu día revela cosas que quizás te hayas perdido si no lo articulaste Y luego finalmente se está cancelando la retrospectiva. Entonces la retrospectiva es el objetivo de la metodología Ágil Si no lo usas, entonces no mejoras. Así que nunca canceles el retro. el viernes por la noche del fin de semana, deberías tener todo esto. Deberías tener un Trello mostrando el viaje con tu meta de sprint en la cima, historias completadas y hechas, todo lo que no terminó enviado al backlog Dos, cinco notas diarias en pie en Notion. Tres, deberías tener un documento de planeación de sprint para este sprint todo rellenado. Número cuatro, tus notas de revisión capturando lo que mostraste y los comentarios que regresaron. Cinco, una entrada retrospectiva terminada con tres acciones concretas para el siguiente sprint y seis, una captura de pantalla de tu tablero Trello terminado junto a la Juntos, estas son una demostración de grado de cartera que puedes ejecutar un sprint. Entonces, eso es todo. Hemos llegado al final de la Sección Cinco. Te veré para la Sección Seis. 31. Para terminar: Errores comunes de los principiantes y cómo evitarlos: Hola, y bienvenidos a la Sección Seis. Es la sección final por supuesto uno. Antes de concluir, quiero dedicar un tiempo a las trampas que veo a los principiantes haciendo una y otra vez cuando se trata de Agile Project Management y principalmente ejecutando sprints ágiles Entonces, al final de esto, sabrás qué buscar, y probablemente te ahorrarás meses de prueba y error si sigues estos recuerdas estos escollos comunes Entonces Pitfall uno, haciendo Ágil sin ser Ágil. Ahora, los nuevos equipos adoptan las ceremonias y ejecutan stand-ups. Tienen una tabla. Llaman planeación de sprint de reuniones, pero debajo de todo eso, nada ha cambiado realmente. El propietario del producto aún sin duda requisitos como gerente de proyecto. El equipo aún espera que se le diga qué hacer. Los cambios siguen siendo tratados como fallas. La forma es Ágil, pero la sustancia es cascada disfrazada No caigas en esto. El arreglo no está en más ceremonias. Está en la mentalidad, la mentalidad de confiar en tu equipo, de dar la bienvenida al cambio, de entregar Entonces, si estás haciendo los rituales pero no viviendo los valores, realidad no estás haciendo Agile. Para el número dos es sobre planear el sprint. Esto lo mencioné bastante en los videos anteriores. Por lo que la planificación de sprint toma alrededor de 2 horas. Algunos equipos lo convierten en un taller de día completo, lo cual no es correcto. Debaten cada historia como por 20 minutos. Estiman el medio punto más cercano. Escriben párrafos de criterios de aceptación para historias que ni siquiera han comenzado. Entonces, detén todo esto. Se supone que la planeación es liviana en Agile, porque el objetivo de Agile es que aprendas a medida que avanza. Planos tan detallados para cosas que aún no has construido o adivina, disfrazado de certeza y que pertenecen a la gestión de proyectos en cascada Así que planifica lo suficiente para comenzar y luego refinar a medida que aprendas. O el número tres se está saltando la retrospectiva. Esto pasa bastante. No lo hagas. Equipos bajo presión. Podrían cortar primero lo retro, como, Oh, no tenemos tiempo. Haremos uno en el siguiente sprint. Dos sprints después o tres, seis meses después, el equipo ha dejado de mejorar por completo Entonces el retro es el encuentro sencillo más importante en Agile porque así es como el equipo mejora con el tiempo. Y sin ella, no aprendes. Sin aprender, te estancas. Así que por favor asegúrate de mantener siempre lo retro, aunque sean solo 20 minutos, e incluso si es solo un bloc de notas, asegúrate de nunca saltarlo Y Pitfm número cuatro, dejando que el atraso crezca Cada idea se agrega, y esto es un problema. No se quita nada. Entonces después de seis meses, tienes 400 artículos. Nadie puede encontrar nada. La parte superior del backlog ya no es solo el trabajo más importante Es lo que sea que le ocurra agregar más recientemente. Entonces es muy importante que podes tu atraso como un arbusto Una vez al mes, escanee la mitad inferior. Cualquier cosa que haya estado ahí por tres meses o más y que no sea prioridad de nadie, elimínelo. Si realmente importa, volverá. Entonces, un retraso limpio es un atraso saludable. A los 45 años, el problema del héroe. Entonces esta es la idea de que una persona del equipo haga la mayor parte del trabajo pesado. Son brillantes. Recogen los boletos más duros. Trabajan fines de semana. Todos los demás dependen de estas personas. Ahora bien, esto se ve muy bien a corto plazo, pero a largo plazo, esto es un desastre. Entonces el héroe se quema cuando dejan la compañía o incluso si se van de vacaciones, el equipo colapsa porque el conocimiento está atascado en la cabeza de una persona y peor aún, nadie más llega a crecer Así que difunde a la gente de la pareja en historias duras, déjalas colaborar, rotar a las personas que recogen las más duras, asegúrate de que el equipo sea resistente y no dependa de un héroe. El siguiente escollo es confuso, ocupado con lo productivo. El tablero está lleno. Tarjetas por todas partes. La gente se ve estirada. Seguramente, esto es lo que se ve un buen sprint. No necesariamente. Un equipo con 15 tarjetas en hacer rara vez envía algo. Están cambiando de contexto, están medio terminando. A lo mejor los están bloqueando, y probablemente se están quemando. Un equipo con dos tarjetas en marcha podría estar enviando silenciosamente más valor. Así que recuerda que la actividad no siempre es progreso. Mira la lista de hechos, no la lista de hacer. La pregunta ¿no está ocupada la gente? La pregunta debería ser, ¿es flujo de valor? Es para el número siete ignorando a los bloqueadores. Esto es muy, muy importante. Si alguien menciona a un bloqueador en un stand up y el equipo simplemente asiente con la cabeza, y luego la reunión continúa Tres días después, el bloque sigue ahí. La tarjeta no se ha movido, y todo el sprint está en problemas. Por lo que los bloqueadores son el artículo más urgente en cualquier tablero. Cuando uno sea levantado, nombra, escríbelo, asigne a alguien para que lo desbloquee o trate con él usted mismo, hágalo muy visible en el tablero como etiqueta o como una tarjeta separada. Un bloqueador que nadie posee es un bloqueador que nunca se arregla. Así que recuerda esto. Entonces sí, siete trampas todas evitables Los equipos que consiguen un buen Agile son los que evitan todos estos errores, y son ellos los que los notan más rápido. Entonces, entonces ese es el final de esta lección. En la siguiente lección, veremos dónde se encuentra ahora y haremos una autoevaluación rápida para ver cuánto ha absorbido realmente en este curso. Entonces te veré en el siguiente video. 32. Autoevaluación: ¿Dónde estás ahora?: Bienvenida de nuevo. Así que a estas alturas has pasado varias horas aprendiendo los fundamentos de la gestión de proyectos Agile. Y en esta breve lección, harás un balance de lo mucho que realmente sabes ahora. Entonces, al final, tendrás una imagen clara de tus fortalezas, tus brechas y dónde enfocarte a continuación. ¿Por qué incluso autoevaluarse en primer lugar? Hay tres razones principales por las que importa. Número uno, hace que el aprendizaje sea real. Leer y mirar es solo pasivo, pero reflexionar te obliga a comprometerte realmente con lo que sabes. Número dos, te muestra en qué enfocarte a continuación. Entonces, sin una autoevaluación honesta, podrías volver a ver el Bit fácil Y omita las partes duras. Ahora bien, este es un mal hábito. Y número tres, te prepara para entrevistas. Entrevistas PM y Agile preguntan rutinariamente, cuéntame sobre tu experiencia con Entonces, saber dónde estás parado facilita esas conversaciones. Entonces tenemos una verificación de diez preguntas, pausa el video, y puedes responder honestamente, y luego volver. Por lo que aquí no es necesaria la calificación. Solo fíjate en dónde te sientes seguro y dónde no. Entonces uno, ¿puedo explicar Ágil en dos oraciones sin usar jerga? Número dos, ¿puedo nombrar los cuatro valores del manifiesto Ágil Tres, ¿puedo escribir una historia de usuario en el formato adecuado con criterios de aceptación para un proyecto en el que no trabajo actualmente? Número cuatro, ¿ entiendo la diferencia entre los atrasos de producto y sprint Cinco, ¿puedo describir lo que hace cada uno de los tres rollos de scrum y lo que no hacen? Seis, ¿podría hacer una reunión de stand up de 15 minutos mañana sin preparación? Número siete, ¿puedo explicarle la matriz de Moscú y el valor versus esfuerzo a un colega que nunca antes había oído hablar de ellos? Número ocho, ¿podría escribir un objetivo sprint de una oración para un proyecto ficticio en una oración que esté enfocada en resultados? Número nueve, ¿conozco la diferencia entre una revisión de sprint y una retrospectiva y para qué sirve cada una Y el número diez es, ¿podría configurar una tabla Trello y un espacio de trabajo de noción desde cero, listo para correr mi propio sprint? Entonces esas son las diez preguntas. Respóndeles honestamente y vuelve. A continuación, qué hacer con tus resultados. Entonces tres categorías, sé honesto sobre en cuál te encuentras. Esto es muy importante. Entonces, en su mayoría, confía en que tendrá ocho o más síes, lo que significa que ha absorbido muy bien el material, pasa al curso dos cuando esté listo y comience a practicar en proyectos reales En su mayoría mezclados serían 5-7 síes. Entonces tienes lo básico, pero algunas piezas siguen siendo borrosas Vuelva a ver las lecciones, cubriendo las preguntas con las que luchó, y luego vuelva a hacer el ejercicio de práctica con un nuevo proyecto En su mayoría temblorosos, menos de cinco síes. Eso está bien. Simplemente significa que el curso necesita otro pase o solo necesitas revisar el vocabulario. No te pegues a ti mismo. Ágil. Es mucho para absorber, así que puedes volver a la Sección uno y trabajarla un poco más despacio, tomar notas y mantener un glosario es extremadamente útil con la gestión de proyectos ágil ya que muchos de los términos, sí, gran parte del concepto de gestión de proyectos ágil se encuentran en el vocabulario Entonces, finalmente, una pregunta más honesta. Realmente hiciste los ejercicios de práctica o los omitiste? Entonces aquí está la verdad. Realmente no se puede aprender a correr sprints con solo ver videos Aprendes a correr un sprint corriendo un sprint. Entonces, si te saltas los ejercicios, tu siguiente paso real no es más contenido, es volver atrás y en realidad hacer esos ejercicios. Por lo que hasta un mini sprint completo te enseñará más de 20 horas de videos de teoría. Bueno, esa es tu autoevaluación hecha. Sé amable contigo mismo, pero asegúrate de ser honesto. En la siguiente lección, haremos una revisión rápida del proyecto para ver rápidamente cómo debería ser tu sprint terminado, así te veré en el siguiente video. 33. Revisión del proyecto: cómo se ve tu sprint terminado: Hola, bienvenidos al penúltimo video de este curso. Entonces, a estas alturas, si has seguido el curso, has planeado y has corrido un sprint, en esta lección, haremos una revisión de cómo debería ser ese sprint terminado , qué aspecto tiene bien, de qué estar orgulloso y cómo hablar de ello en un portafolio o en una entrevista. Entonces el artefacto que deberías tener, tus seis artefactos, deberías tenerlos en papel o en tus herramientas En primer lugar, deberías tener una placa Trello con una cartera de productos poblada Tu meta de sprint en la cima, un sprint completado con historias en Hecho y capturas de pantalla del tablero antes y después. Dos, deberías tener un espacio de trabajo de Notion con cuatro subpáginas, planificación de sprint, retrospectiva, decisiones y actualizaciones de stakeholders Tres, deberías tener al menos un documento rellenado de planeación de sprint. Cuatro, se debe tener una retrospectiva concluida con tres acciones concretas Y cinco, deberías tener tus notas de tu revisión de sprint, y luego finalmente, seis, deberías tener vínculos entre Trello y Noción en ambas direcciones Si tienes los seis, has construido algo real. Enhorabuena. Ese es un sistema ágil que funciona. No es sólo un ejercicio. Ahora bien, ¿qué aspecto tiene el bien? Aquí están las cinco principales cualidades de un buen primer sprint. Entonces, más allá de tener los artefactos, ¿cómo hacemos que este primer sprint se vea bien? Cinco cualidades para buscar el número uno, es que el objetivo del sprint es claro y enfocado en el resultado, y puedes decir de un vistazo si eres capaz de acertarlo o no. Dos, las historias de usuario siguen el formato correcto y tienen criterios de aceptación comprobable Son específicos. No son vagos Tres, el trabajo en tu lista de hechos se conecta directamente con el objetivo de sprint. No tienes nada extra, y no te falta nada. Cuatro, tu retro identifica cosas reales para cambiar, no solo platitudes genéricas, como, comunicar más es malo Muévete, ponte de pie hasta 930 porque las 10:00 A.M Los choques con X es mejor. Los choques con X es mejor Cinco, la documentación es ligera pero útil, lo suficiente para ser útil, pero no tanto como para que nadie la lea. Entonces estas son las cinco cosas. Si revisas todos estos, y la respuesta es sí a todos estos, entonces sabes que tu sprint puede quedar bien. Ahora bien, aunque tu primer sprint fuera duro, hay algunos vientos reales que vale la pena reconocer. Ahora, has aprendido una nueva mentalidad, no solo una nueva metodología Agile es una forma de pensar sobre el trabajo El hecho de que ahora puedas detectar cascada pensando en tus propios hábitos es en sí mismo un gran cambio. Has construido algo tangible. La mayoría de las personas que dicen entender Agile nunca han corrido realmente un sprint, pero tú sí. Has creado una pieza de portafolio. Entonces, sea cual sea el trabajo que vayas a continuación, puedes apuntar a un sprint terminado con metas, historias, retros y reflexión También te demuestras a ti mismo que puedes terminar algo estos cursos son fáciles de comenzar, pero son difíciles de terminar. Ya has hecho el trabajo, así que enhorabuena. Ahora, veamos cómo podemos hablar de esto en entrevistas. Si estás buscando empleo, el sprint es oro de entrevista si lo enmarcas bien. No digas que tomé un curso de Agile. Eso realmente no dice la entrevista ni nada, pero se podría decir que ejecuto un proyecto manos en Agile donde construí un backlog, planeé y ejecuté un sprint, corrí una retrospectiva y envié X número de historias atadas a una meta específica de sprint Esto es mucho más impresionante y en realidad es cierto. Trae los artefactos, muestra el Trello, camina por el espacio de trabajo Notion La mayoría de los entrevistadores nunca han visto a un candidato demostrar su proceso Los que lo hagan destacarán más que nada. Así que también sé honesto sobre lo que has aprendido. Se podría decir, mi primer sprint, me sobrecomprometí. Tuve que dejar caer dos historias. En lo retro, descubrí que había estimado en base a los mejores escenarios de los casos. Ahora siempre rellené mis estimaciones. Así que la autoconciencia siempre se lee como senior y altamente profesional. Ahora bien, si quieres usar esto como una pieza de portafolio, esto es lo que debes incluir un breve resumen escrito, solo un breve párrafo de lo que construías y por qué? Capturas de pantalla de tu tablero Trello antes y después, con el objetivo sprint visible, sumamente importante Su documento de planificación de sprint exportado de Notion. Incluso la versión aproximada demostraría que pensaste en la capacidad, el riesgo y el compromiso. Tu retro con las acciones que identificaste. Ahora este es oro porque demuestra que puedes auto mejorar, puedes mejorar un equipo. Y opcionalmente, podrías tener un video en telar de cinco minutos a través del proyecto. Son sólo 5 minutos, y la gente recuerda los candidatos que los mostraron en lugar de decirles. Si tienes tu propio sitio web, alojarlo allí o subirlo a un repo público de GitHub o compártelo usando la función de uso compartido público de Notion Así que hazlo enlazable y hazlo ordenado. Oh, enhorabuena. Has llegado al final por supuesto uno. Has construido algo real. Nunca debes subvender esto. Has logrado algo real que puedes agregar a un portafolio y usando entrevistas. Podría acercarte un paso más a conseguir el trabajo de tus sueños. Entonces en el video final de este curso, veremos lo que sigue, y veremos el puente al curso dos, que será el curso intermedio en gestión de proyectos. Entonces te veo para la lección final. 34. ¿Qué sigue?: Bienvenido de nuevo por última vez en el curso uno. Bien hecho. Has llegado hasta el final. En este video final, solo vamos a ver a dónde vas desde aquí. Veremos el curso dos y lo que hay en él y más allá. Entonces sí, sabrás exactamente cuáles son tus próximos pasos. Entonces, antes que nada, hagamos un resumen rápido de lo que has aprendido Has aprendido la base, que es más de lo que la mayoría de las personas que afirman que la experiencia ágil puede decir. Hemos cubierto el manifiesto AGi y la mentalidad Agi. Hemos cubierto sprints, incrementos, el bucle empírico. Hemos cubierto rollos de scrum. Hemos cubierto rezagos, historias de usuarios, criterios de aceptación, la definición de hecho Hemos analizado cómo montar un lugar de trabajo en Trello y en Miró cómo priorizar, estimar y correr un sprint Hemos analizado cómo correr un sprint con stands ups, con ajustes de mid sprint, con reseñas y retrospectivas También hemos mirado las trampas a tener en cuenta. Entonces todo esto es la base. Entonces conoces más que la mayoría de las personas que reclaman experiencia ágil. Así que podrías estar orgulloso de eso. El segundo curso se llama sprint a escala. Entonces aquí es donde el curso dos retoma donde el curso uno lo dejó, y profundiza en las habilidades intermedias. Entonces aprenderás a manejar múltiples sprint en una secuencia. Aprenderás a mantener el impulso. Aprenderás a lidiar con los cambios de sprint sobre sprint y también a manejar la velocidad. Te sumergirás en las ceremonias avanzadas de scrum en sesiones de refinamiento atrasado y verás una planificación más sofisticada con retrospectivas más con También cubrirás Kanban correctamente, qué se diferencia del scrum y cuándo usarlo, y también cómo combinar los dos en un enfoque híbrido También aprenderá a manejar a las partes interesadas a escala, administrar ejecutivos, a administrar clientes y también a administrar prioridades competidoras. También explorarás las herramientas más allá de Trello. Veremos los proyectos Jira, lineales y Github, y también veremos cuándo valen pena y cuándo son exagerados Entonces, por supuesto, uno solo se trataba de ejecutar una spre mientras que el segundo se trata de ejecutar una corriente de ellas, que está más cerca de la realidad de la gestión de proyectos ágil Ahora, el curso tres es el avanzado. Se llama liderar y mejorar equipos. Este curso es para personas que quieren correr más allá de simplemente correr sprints para liderar transformaciones ágiles dentro de las empresas Esto cubre todas las habilidades blandas, como el entrenamiento de los miembros del equipo, manejo de conflictos en el equipo, la construcción de la seguridad psicológica. También cubre las métricas y cómo medir la salud del equipo sin convertirse en las métricas policiales. También analiza las cosas organizativas más difíciles, como obtener la compra del liderazgo, lidiar con la resistencia y escalar Agile más allá de un solo equipo. Este es el nivel en el que Agile deja convertirse en una metodología y se convierte en una habilidad de liderazgo para tus roles más senior. Algunos otros lugares para aprender más allá de estos tres cursos, si quieres seguir adelante, tenemos algunas recomendaciones de libros. Primero es Scrum de Jeff Sutherland. Es corto, es accesible, y Jeff es uno de los inventores. El proyecto Phoenix es una novela sobre DevOps y Agile, que es extrañamente legible, y finalmente, inspirada en Marty Kagan es la Biblia Certificaciones que tal vez desee echar un vistazo a la certificación CSM scrum master y PSPO profesional propietario de productos scrum son los más respetados en la industria Estos son útiles para trabajos, aunque el examen real no te enseñe mucho más allá de lo que ya aprendiste. Genial tener en tu CV. Comunidades, las subediciones Agile y Scrum son geniales eventos de la alianza ágil y las reuniones locales de scrum Una de las mejores formas de aprender es venir de platicar con otros practicantes. Y por último, su propio trabajo. Entonces, aplicar lo que has aprendido a un proyecto real, aunque sea solo un proyecto paralelo es genial. El siguiente sprint que corras, que será en el mundo real. Te enseñará más de lo que otro curso lo hará. Entonces, una última cosa antes de cerrar, Agile no es de ninguna manera una metodología perfecta. Tiene problemas, y sí se abusa, y puede convertirse en burocracia disfrazada Los mejores practicantes son quienes la utilizan pragmáticamente Toman lo que funciona, dejan lo que no funciona y nunca dejan de adaptarse. Entonces tu trabajo desde aquí es hacer exactamente eso. Ejecuta sprints, observa lo que funciona, observa lo que no funciona, ajústalo. Esta es toda la mentalidad ágil aplicada al aprendizaje Agile mismo. Así que muchas gracias por acompañarme en el curso uno, que es el curso principiante e introductorio a la gestión de proyectos Ágil. Bien hecho por llegar hasta el final. La mayoría de la gente no. Realmente espero que esto te dé una verdadera base de trabajo que incluso podrías usar en entrevistas de trabajo y solicitudes de empleo. Entonces otra vez, muchas gracias. Buena suerte con lo que sea que construyas a continuación, y te veré en el curso dos. Adiós. 35. Proyecto de clase: crea tu propio proyecto ágil.: Ahora es el momento de poner en práctica todo lo que has aprendido. Para tu proyecto de clase, crearás y administrarás tu propio proyecto ágil usando Trello, noción o ambos Comience simplemente eligiendo uno de los resúmenes del proyecto del curso o cree su propia idea de proyecto si lo prefiere Entonces construirás tu proyecto paso a paso. Crearás un backlog de productos, escribirás historias de usuarios, agregarás criterios de aceptación, priorizarás tu trabajo, estimarás tareas y planificarás tu primer sprint A continuación, organice todo dentro su herramienta de gestión de proyectos y cree una tabla de sprint, mostrando cómo el trabajo pasará de hacer a hacer a hacer a hecho. El objetivo no es crear un proyecto perfecto. El objetivo es demostrar que entiendes el flujo de trabajo ágil y puedes aplicarlo de manera práctica. Una vez que tu proyecto esté completo, sube capturas de pantalla de tu tablero Trello, tu noción, espacio de trabajo, backlog de sprint o cualquier otro artefacto del proyecto que te gustaría compartir Y también puedes incluir una breve explicación de tu proyecto y tu meta de sprint. Este proyecto te dará experiencia práctica con los mismos conceptos y herramientas que utilizan los equipos Agile todos los días. 36. ¡Felicidades!¿Qué sigue?: H. Enhorabuena por terminar el curso. Ahora ha aprendido los fundamentos de Agile Project Management, desde comprender la mentalidad ágil y marco Scrum hasta crear backlogs, planificar sprints y administrar el trabajo utilizando herramientas profesionales de gestión utilizando herramientas profesionales Lo más importante es que has aplicado estos conceptos construyendo tu propio proyecto, que es exactamente como desarrollan las habilidades de gestión de proyectos en el mundo real. Recuerde, los grandes gerentes de proyecto no se crean memorizando marcos Se vuelven exitosos al practicar continuamente la planeación, comunicación, la priorización y la adaptación A medida que continúe aprendiendo, intente aplicar estas técnicas a proyectos personales, iniciativas de equipo o incluso tareas del lugar de trabajo. Cuanta más experiencia adquieras, más natural será la Gestión de Proyectos Ágil. Si aún no lo has hecho, asegúrate subir tus proyectos a la galería. Me encantaría ver cómo has aplicado los conceptos del curso. Y si disfrutaste de la clase, por favor considera dejarnos una reseña. Nos ayuda a mejorar el curso y ayuda a otros alumnos a descubrirlo, también. Gracias por acompañarme en este viaje de aprendizaje, y espero verte en el próximo curso.