Scrum: reunión de gestión de proyectos ágil

1. ¡Hola!: Bienvenido a este curso sobre Scrum. Si eres un ScrumMaster, un gerente de proyecto, un desarrollador e ingeniero, una prueba con solo mirar Agile, entonces este es el curso para ti. Scrum es un marco de gestión de proyectos. Originalmente fue desarrollado para el desarrollo de software, pero en realidad se puede usar para cualquier cosa. Entonces las habilidades que impartiré en este curso tanto como sea posible. Voy a tratar de aplicar a todos los ambientes. Pero vamos a pasar por un estudio de caso real. Entonces vamos a mirar construir una plataforma de comercio electrónico es una aplicación de software. Y vamos a ver cómo se aplica Squirm a eso. Entonces aprendes la teoría, lo práctico, y nosotros también la aplicaremos a esta situación. Entonces, si todo eso suena bien, entonces empecemos. 2. Conceptos básicos de Scrum: Empecemos por lo básico. Entonces, ¿qué se cultiva? Bueno, es el marco de gestión de proyectos. Te ayuda a entregar proyectos, estructurarlos de una manera que funcionen. Por lo que originalmente se desarrolló para desarrollar software, para desarrollar proyectos técnicos, pero desde entonces se ha aplicado a toda una gama de temas. Entonces tipo de desarrollo de software es su hogar. Pero en realidad puedes aplicar squirm a cualquier cosa y funciona muy bien. He usado en mi vida personal, lo he usado proyectos no tipo. Y esos valvulería muy buenos. Scrum forma parte de la familia Agile. Tan ágil es un movimiento. No es una cosa. Agile es, es una forma de ser y de trabajar. Y tienes el tipo de filosofía genial de Agile. Pero entonces tienes implementaciones específicas, cosas como Scrum, cosas como Kanban, ese tipo de manual de bien, bueno, así es como pones esos principios ágiles en efecto. Tan escamosa parte del movimiento Agile general, y es una implementación específica de eso. Scrum. Y Agile en general está realmente diseñado para reducir el fracaso del proyecto, hacer que los proyectos sean más confiables. Entonces a la antigua manera, los proyectos tendían a fallar mucho. Y así después de todo vino y dijo: ¿Cómo podemos hacer esto mejor? ¿Cómo podemos reducir eso? Y vamos a entrar en más sobre cómo lo hace a medida que avanzamos. Entonces, ¿cómo funciona Scrum? ¿Cómo logra todas estas cosas? Exploremos eso en el próximo par de lecciones. 3. Ágiles: Comparemos una metodología de cascada de estilo antiguo con una metodología basada en scrum más ágil. El viejo sistema, lo tendríamos todo en grandes pasos. Sería una gran fase de especificación. Entonces se pudo hacer todo el trabajo de desarrollo, seguido de las pruebas y la aceptación del usuario. Ahora aquí es donde eso sale mal. Podríamos, podría llevarnos mucho más tiempo de lo esperado y nos quedamos sin dinero en algún momento, llegamos a la etapa de pruebas y nos dimos cuenta de que necesitamos los requisitos para cambiar, pero ya hemos hecho todo el trabajo de desarrollo. O llegamos a la Etapa de Aceptación del Usuario y la ponemos frente al cliente o al cliente y no les gusta y necesitan un querer cambios. Y entonces qué se supone que hagamos eso porque ya estamos en el fago de Aceptación de Usuario. Entonces en lugar de esto, Agile propone que utilicemos un proceso iterativo en el que hagamos muchos pequeños pasos. Entonces hacemos una pequeña mota, pequeña compilación, pequeñas tareas, pequeña aceptación de usuarios, y luego comenzamos el ciclo de nuevo. Entonces, en lugar de tener estos cuatro grandes bloques donde todo se hace a la vez, tenemos estos pequeños ciclos rápidos. Y las ventajas de hacer esto son cosas como, bueno, podemos hacer un lanzamiento después del primer ciclo. Cuando son la vieja metodología de cascada, solo se llega a lanzar al final. Pero aquí construimos algo muy básico y podemos liberarlo después del primer ciclo. También podemos ponerlo frente al cliente para que lo vean. Y pueden hacer cambios si es necesario, si no está coincidiendo con lo que quieren. Y estos cambios están bien porque después de que hayamos hecho la aceptación del usuario fue la primera ronda. Volvemos a la fase de especificación de entrenamiento. Lo siguiente es que necesitamos construir y luego lo construimos y lo probamos y se lo devolvemos al cliente. Y seguimos dando vueltas en estos ciclos rápidos donde recopilamos muchos comentarios y sacamos las cosas temprano, lo que reduce la posibilidad de fallas y significa que va a coincidir con lo que el cliente necesita. 4. Fortalezas y limitaciones: Consideremos algunas de las fortalezas y limitaciones del scroll. Una de las grandes ventajas es la falla del proyecto de vacíos. Entonces platicamos de esta idea de proyectos de cascada que tardaron años, llegando al final. Y a lo mejor no se meten al final porque el costo sobrepasa o lo hacen y al usuario no le gusta. Y todo es un fracaso ¿ Scrum y Agile en general realmente evitarán eso? Los clientes pueden verlo antes para que estén más felices porque pueden ver el progreso y pueden ver que está coincidiendo con lo que quieren en lugar de obtener algo al final que puede o no ser lo que quieren. Es muy bueno reportar, cambiando los requisitos de los usuarios. Entonces si el cliente lo consigue y dicen: Oh, necesito cambiar esto o esto no está funcionando del todo. Es mucho más fácil cambiar si no lo has construido todo. Y si estás trabajando en una metodología que dice cambios, un cambio fino es parte del proceso que son, que es el problema con la cascada es que el cliente va a hacer cambios a medida que avanzas por el proyecto. Y necesitas una manera de manejarlo. Y su metodología iterativa realmente ayuda con eso. Significa que puedes sacar la primera versión antes porque no necesitas terminar todo para poder enviarla. Puedes construir la funcionalidad esencial, enviarla y luego seguir construyendo después de que ya hayas lanzado los proyectos. Ahora que todas las limitaciones a Scrum y Agile. Entonces una de las grandes es que lleva un poco más de tiempo. A veces la gente piensa que Agile suena un poco más rápido, pero no lo es. Está diseñado para reducir las tasas de fallas. Entonces Cascada, Cascada es bastante eficiente si obtienes todo 100% correcto. Entonces si tienes 100% planeado y construido y luego pruébalo y luego entregado, y todo funciona perfectamente. Y no hay requisitos de usuario cambiantes que serían más rápidos que este ciclo iterativo donde construyes un poco, lo revisas, construyes un poco, lo revisas, sería más rápido. Ahora, nunca he visto un proyecto donde se haya planeado al 100% y luego sabemos cambiar los requisitos de los usuarios. Entonces creo que la agilidad funciona mucho mejor. Pero hipotéticamente, si pudieras conseguir todo eso alineado, entonces la cascada sería más rápida porque Scrum funciona en este ciclo iterativo, lleva un poco más de tiempo. las partes interesadas no siempre les gusta. Entonces, si son del estilo cascada de la vieja escuela que probablemente estén un poco nerviosos por adoptar esta nueva metodología ágil. Y a veces les preocupa que si estamos desarrollando este ciclo iterativo donde estamos mostrando al cliente una pieza de software medio construida que tiende a entrar en pánico. Mi experiencia, a los clientes les encanta. Realmente se comprometieron. Quieren ver el progreso y entienden que no están mirando el proyecto terminado. Pero a muchos directivos de la vieja escuela preocupa realmente que les enseñemos, les enseñemos un botón que no esté completamente terminado y el cliente asumirá que está terminado y lo esperará mañana. Y a veces puede ser difícil manejar esas expectativas. Scrum tiene mucha flexibilidad, pero de alguna manera escamoso, inflexible. Entonces funciona en estos sprints de típicamente dos semanas donde dices lo que vas a hacer al inicio de las dos semanas, luego lo haces y no cambias eso. Ahora de alguna manera eso es bueno porque si permites cambios dentro del sprint, entonces a menudo obtienes gerentes tratando de empujar más trabajo y distraer a los ingenieros y arrastrándolos fuera de la tarea. Y no es genial. Pero hay algunos entornos donde tienes cosas urgentes que surgen en squirm no es tan bueno manejando eso como decir algo como Kanban, que es otro Agile Framework, que está diseñado como una especie más de una vez que estás vivo haciendo negocios como de costumbre, empujando arreglos, es más adecuado para eso con Scrum es más adecuado para si estás construyendo un proyecto por primera vez. Y, ya sabes, puedes decir, aquí tenemos un bloque de dos semanas. Esto es lo que vamos a hacer y permitir que todos se concentren en eso. 5. El sprint: Uno de los conceptos clave en Scrum, que es diferente a algunos de los otros frameworks Agile es esta idea del sprint. Este es un período de tiempo fijo en el que el equipo acepta entregar un conjunto específico de características. Así que a menudo son dos semanas y decimos, bien, en las próximas dos semanas, vamos a construir esta característica, esta característica y esta característica. Entonces, un sprint, tendremos un objetivo, por ejemplo, tal vez el objetivo sea entregar la página de pago para nuestra plataforma de comercio electrónico. Y eso está compuesto por varios boletos que construyen cada una de las funcionalidades requeridas para hacerlo. Y luego iniciamos un sprint y todo el equipo trabaja en conjunto para entregar esta funcionalidad. Por lo que la entrega, la finalización de la meta sprint no es el trabajo de ninguna persona. Es responsabilidad colectiva de todo el equipo. Entonces, lo que parece en un proceso es que comenzamos con Sprint Planning. En Sprint Planning, se acuerda Sprint Goal y elegimos las tareas que se van a completar. Entonces seleccionamos los números o los boletos que vamos a traer y se convierten en el backlog de sprint, que es esencialmente la lista de tareas pendientes para estas dos semanas. Entonces lo haremos entonces en el sprint mismo. Por lo que el equipo trabaja en entregar las características acordadas y no se trae nada nuevo al sprint. Entonces cuando hacemos planeación de Sprint, comenzamos esto cuando y luego eso bloquea ese sprint, ese periodo de tiempo para decir esto es lo que vamos a hacer y vamos a trabajar juntos para hacerlo. Al final del sprint. Luego tenemos la retrospectiva y revisión. Por lo que el trabajo terminado se presenta en una revisión y el equipo reflexiona sobre cómo le fue, que es la retrospectiva. Entonces los dos eventos separados, y hablaremos más sobre esos en una lección posterior. Y cualquier problema que no se complete se traslada al siguiente sprint o se devuelve al backlog del producto. 6. Longitud de Sprint: La longitud de un sprint puede ser lo que quieras. Por lo general, los sprints se realizan en periodos de dos semanas porque eso parece funcionar bien para la mayoría de los proyectos, pero eso no es una regla. A veces he hecho sprints de una semana, a veces he hecho sprint de tres semanas. Lo que realmente quieres hacer es averiguar cuánto tiempo te va a llevar entregar ciertas características, cierta parte en el proceso de desarrollo y hacer que sea tu longitud de sprint. Entonces, si tienes una característica realmente grande y complicada para entregar una parte del proyecto para entregar. Entonces si eso te va a llevar decir, un mes para hacerlo, entonces quieres hacer tu sprint de un mes si literalmente no podemos descomponernos. Y esa es una buena pregunta para hacerte si estás pensando, bien, necesito un sprint de cerca de cuatro semanas o seis semanas o algo así. Vuelva a examinar si puede desglosar aún más eso porque probablemente pueda. Pero si es literalmente imposible, está bien alargar tu sprint porque puedes adaptar la longitud de la férula para que se ajuste a nuestras necesidades. Por lo general, dos semanas es un buen periodo de tiempo. Todos pueden bajar la cabeza. No estás gastando demasiado tiempo pasando por el ciclo sprint y tienes un buen periodo de diez días hábiles para hacer las cosas, pero puedes hacerlo más corto o más largo para que se adapte a tus necesidades. 7. ¿Qué son artefactos?: Los artefactos son piezas de información que un equipo de Scrum utiliza para ayudar a planificar y entregar su trabajo. Entonces, por ejemplo, a. Lista de características para construir sería un artefacto. Ahora esto podría guardarse en una hoja de cálculo. Podría guardarse en una herramienta como JIRA, o incluso podría mantenerse en nuestras cabezas. Pero eso no lo recomendaría porque eso obviamente crea un solo punto de fracaso. En este módulo, vamos a explorar los diferentes tipos de artefactos que es común que usen los equipos de Scrum. 8. Lista de espera del producto: El producto es lo que estás entregando y el backlog del producto es todo lo que hay que hacer. Entonces todas las tareas involucradas en el proyecto. Cada boleto representa una pieza discreta de funcionalidad. Entonces, un boleto, una pieza de funcionalidad entregable, por ejemplo, si tomamos nuestro ejemplo de tienda de comercio electrónico, entonces probablemente necesitemos una página de visualización del producto donde pueda hacer clic en el producto y ver todos los detalles. Y eso tiene varios componentes ya que probablemente sea como un título y descripción de la foto del producto y algunas reseñas y especificaciones técnicas. Ahora, cada una de esas cosas podría ser su propio boleto que se encuentra en una cartera de productos atrasados. Entonces agregando la creación de la página en blanco, agregando el título, agregando la imagen del producto, no hice especificaciones agregando las reseñas. Todos estos podrían ser boletos individuales porque podrías entregarlos uno a la vez. Podrías entregar una página que solo tenga un título de producto encendido. Y luego podrías volver más tarde y agregar una foto de producto o algunas reseñas de productos que discretan piezas de funcionalidad, y por lo tanto obtienen su propio boleto. Ahora los boletos pueden entrar en un trabajo más grande. Entonces, en este caso, tenemos nuestra página de producto, o la página del producto, podría ser lo que se llama una epopeya. Entonces esta es una colección de boletos que trabaja hacia una pieza más grande de funcionalidad. Así que nuestra página de productos en su conjunto podría estar en una epopeya. Y luego tenemos boletos individuales ahí dentro. Así que tenemos nuestra descripción del producto, foto del producto, revisión del producto, y todo eso es parte de la épica página del producto, que luego podemos poner en marcha en algún momento. Entonces, el objetivo de la acumulación de productos es mantener todas las tareas que hay que hacer. Así que guardarían todo para la página del producto, todo para la página de navegar, todo para la página de pago, todo desglosado en boletos individuales y lo separarían en estas epopeyas. Entonces sabemos a qué boleto pertenece, a qué tipo de sección. 9. Ejemplo de registro de productos: Aquí tenemos un ejemplo de backlog de productos. Entonces esto es para nuestro ejemplo de tienda de comercio electrónico. Y tenemos nuestras historias de usuarios escritas aquí. Entonces el escrito en el formato de historia de usuario del que hablaremos un poco más adelante. Pero cosas como, como visitante, no voy a ver el nombre del producto, la imagen del producto. Y luego como gerente, quiero ver una lista de pedidos. Y en esta columna la hemos agrupado por época. Entonces estas son todas las épicas de la página del producto, su checkout apically order management epic. Y hemos puesto un sprint provisional sobre estos aquí y la columna de estado para decir si lo han hecho cada vez que estamos haciendo ahora, o si están listos. Y habrá algunos que no estaban listos porque no los hemos refinado aquí abajo. Ahora hay un montón de excelentes herramientas que puede usar para administrar su cartera de productos. Pero quería mostrártelo en esta hoja de cálculo porque creo que es una gran manera de aprender los fundamentos. Puedes hacerlo en una hoja de cálculo, puedes hacerlo en una hoja de papel, puedes hacerlo como quieras. Nos sumergiremos en las herramientas porque también son muy importantes. Eso es probablemente lo que usarás en un entorno empresarial del mundo real. Pero esta es una buena manera de considerar los fundamentos. 10. Atrás de Sprint: Al inicio de cada sprint, seleccionas qué boletos vas a hacer en este sprint. Entonces digamos que estás trabajando en un sprint de dos semanas. Pasas por el rezago del producto y dices: Bien, a, B, C, D, Estos son los boletos que vamos a traer y hacer en este sprint. Entonces, una vez que comienzas el sprint, estos boletos que has seleccionado forman lo que se llama tu backlog de sprint. La lista de backlog de productos, todo lo que tendrás que hacer para el proyecto, la lista de backlog de sprint de boletos que vas a hacer para este sprint específico. Entonces, cuando alguien está listo para trabajar en algo, van al backlog de sprint y recogen uno de los boletos, cualquiera de los boletos que puedes priorizar. Pero normalmente dentro de un sprint, realidad no hay mucha priorización a menos que algo esté bloqueando algo. Pero si tienes un bloqueador, lo mejor es dejar eso a un sprint separado para que los boletos se puedan recoger en cualquier orden. Y luego pasan de la columna de tareas pendientes, que es el backlog de sprint en todos los ámbitos a medida que pasan por el desarrollo, la implementación, la entrega. 11. Ejemplo de backlog de sprint: Aquí tenemos un ejemplo, backlog de sprint. Entonces tenemos nuestras columnas aquí con la lista de tareas pendientes, el backlog aquí. Y luego como hacemos estos boletos, así que si digo que escogí este como cliente, quiero ver el nombre del producto. Puedo mover eso en progreso, luego enviarlo para revisión de código. Y simplemente seguir moviéndolo a través del proceso. Y digamos que se prepara para las pruebas. Las pruebas lo representan. No funciona. Podrían moverlo de nuevo a En progreso, reasignármelo. Y podría volver por ese ciclo otra vez y luego eventualmente, ojalá termine en la columna de hecho. Ahora estas columnas pueden ser tan flexibles como quieras. Así que podríamos, en lugar de la vista del codificador en curso, tal vez queremos dividir eso. Agrega una nueva columna aquí abajo. Ahí vamos. Lo llamaría antes de que pudiéramos decir listo para la revisión del código. Y en revisión de código. Y luego una vez que haya terminado escribir el código, podría pegarlo aquí. Y entonces alguien más podría recogerlo. Cuando lo recogen. Podría entrar aquí, por ejemplo, entonces estas columnas, no hay reglas, pero hay algunos principios generales en los que probablemente quieras algún tipo de retraso mientras él necesitaba atraso, y no necesitaba ese. Y en progreso en alguna revisión y prueba de código. Entonces en última instancia quieren terminar en la columna de hecho. Ahora de nuevo, un montón de herramientas geniales para hacer esto, pero es agradable verlo en un nivel muy básico. Mucha gente usa tablas físicas con post-its que se moverían a lo largo. Eso fue muy popular cuando todos trabajaron en la oficina últimos miles de pandémicos y los equipos remotos son mucho más influyentes. Pero puedes, si lo estás haciendo en un proyecto de una sola persona, sigue siendo una gran manera de hacerlo porque tienes una experiencia realmente táctil de mover las cartas a lo largo del tablero. 12. Definición de done: ¿Cómo sabes cuándo se puede mover un boleto a la columna de hecho? Será un documento importante aquí es la definición de hecho. Este es un documento que describe exactamente lo que se requiere para que un boleto se considere hecho. Entonces, por ejemplo, si volvemos a mirar el software, un ingeniero puede construir la función. Pero eso no cumpliría con la mayoría de las definiciones de hecho porque no es que no se haya ido a ninguna parte, no se está probando. Y así la definición de hecho enumerará todos los pasos, por ejemplo , ha sido construido y probado. Se ha desplegado. Ahí hay suficiente cobertura de pruebas. Tal vez haya algún monitoreo y algún registro para que pueda guardar esa función que salga mal o se rompa más tarde. Se ha probado el rendimiento y la seguridad para asegurarse de que no ha introducido ningún agujero, cosas así. Todos los pasos adicionales donde puedes decir que este boleto está terminado, no necesitamos agregar nada extra. No necesitamos volver atrás y mirarlo. Estamos contentos de que esté ahí afuera en la naturaleza. En la siguiente lección, veremos un ejemplo de Definición de Hecho para que puedas ver cómo se ve en la práctica. 13. ¿Qué son las ceremonias?: Las ceremonias son eventos que ayudaron con la planificación, ejecución y entrega de sprint. Por lo general, involucran a los miembros del equipo de scrum, pero en algunas ceremonias, podemos optar por invitar también a partes interesadas externas. En este módulo, exploraremos cada una de las ceremonias clave a su vez. 14. Scrum diario: El scrum diario es una reunión diaria. Por lo general ocurre por la mañana, pero no tiene que hacerlo y es como un check-in para todos los miembros del equipo de scrum. Por lo general, se hace de pie, de ahí que generalmente se le llame stand-ups en la PC. Término cruzado ágil, múltiples frameworks ágiles usarán el término stand-up en Scrum específicamente, técnicamente se llama The Daily Scrum, pero es lo mismo. Y el formato es cada miembro dice lo que hizo ayer, qué están trabajando ahora mismo, y cualquier bloqueador, así que hay algo que se interponga en su trabajo, lo pueden plantear. Entonces. El propósito es ayudar a todos a rendir cuentas entre sí. Y es una buena oportunidad para pedir cualquier ayuda que necesitemos también. No está diseñado para ser una reunión larga. Normalmente es timebox a un máximo de 15 min y está hecho de pie. Por lo que se anima a todos a que sea breve y al grano. Entonces, si hay algo que necesite más discusión, tenías lo que se llama desconectarlo. Así que organice una reunión por separado. Podemos discutirlo con las partes relevantes porque lo más probable es que todos en el Daily Scrum no necesiten involucrarse. Y así realmente lo guardamos a esas actualizaciones concisas. Es útil tener tu tabla de sprint abierta mientras lo haces para que la gente pueda recordar en qué están trabajando y platicar a través de los boletos y mostrarle al resto del equipo dónde están los boletos y cómo se mueven. 15. refinamiento de backlog: Una reunión de refinamiento atrasado prepara boletos para entrar en el sprint. Entonces, cuando creas por primera vez tu cartera de productos, probablemente no vas a dar tanto detalle que piensas, bien, página del producto, imagen del producto, producto, películas. Mantenerlo bastante simple en ese boleto realmente no está listo para ir a un ingeniero para que lo recojan para ser implementado. Y eso es en lo que ayuda el refinamiento del backlog. Entonces puede involucrar a todo el equipo de Scrum o podría involucrar, digamos, al propietario del producto y tal vez al ingeniero principal trabajando juntos. Y las tareas del refinamiento de backlog R21, descomponen el boleto en sus pedazos más pequeños. Entonces, si el boleto es la página de ver producto, eso se puede desglosar aún más en reseñas e imagen del producto y la página misma en bonitas piezas pequeñas. Entonces estamos para asegurarnos de que el boleto esté listo para llevar a gastado. Entonces aquí estamos hablando de elaboración de los boletos. ¿Qué quiere exactamente el propietario del producto el negocio? Son la especificación es realmente clara. ¿Hay alguna nota técnica o implementación que deba agregarse al ticket para que el ingeniero entienda lo que hay que hacer? ¿Hay alguna nota en las pruebas del probador para entender lo que hay que hacer? ¿Hay suficiente información para que este boleto entre en un sprint y lo recoja y comience a trabajar en él sin tener que hacer preguntas adicionales? Y luego revisaremos cualquier bloqueador. Entonces, por ejemplo si el boleto es agregar las reseñas del producto a la página de ver producto, ese boleto sería bloqueado por la construcción de una página de producto de vista de shell. Porque si esa página de vista del producto no existe, no puedes agregarle ninguna reseña. Y entonces por lo tanto eso sería un bloqueador y necesitaríamos tener en cuenta eso en. Entonces, para que un boleto pase el refinamiento de backlog, debería estar listo para llevarlo a un sprint. Eso significa que no tiene bloqueadores, está listo para funcionar, y tiene una definición clara de lo que hay que hacer. 16. Estimación de puntos: Una de las cosas que debes saber antes traer un boleto a un sprint es, bueno, ¿cuánto tiempo va a tomar? ¿Es este un boleto pequeño y un boleto mediano? Un boleto grande. Necesitamos algún tipo de idea aproximada sobre cuánto tiempo va a tomar el boleto para que podamos intentar estimar cuánto trabajo podemos hacer en el sprint que actualmente estamos tratando de planificar. Ahora en alcance, en lugar de usar el tiempo, usamos puntos. Y los puntos son arbitrarios, por lo que no hay necesariamente una correlación de punto cero lleva tanto tiempo. Lo que haces es que ves, estimas los puntos, luego ves cuántos puntos puedes hacer en un sprint. Y luego a partir de entonces, ya sabes, bien, bueno, puedo hacer pensamos que podemos pasar dos puntos como equipo. Por lo que tenemos que traer por dos puntos la próxima vez. Ahora bien, ¿cómo funciona esto? Si ya necesitas haber hecho un par de sprints y haber trabajado cuáles son tus valores puntuales. Me gusta. ¿Cómo empiezas con eso? Bueno, ahí sí necesitas inicialmente llegar a un poco de vínculo entre el tiempo y los puntos. Entonces tal vez dices, bueno no apuntaría es un día para una persona o medio día para una persona. Y así si piensas en boletos le va a llevar al ingeniero dos días la prueba o un día, y otro día del tiempo de alguien para desplegar, entonces dices, bien, bueno, son cuatro días, así que vamos a llamar cuatro puntos por ahora. Y en punto de todos los boletos de manera similar. Y entonces a medida que estás entrecerrando los ojos crece y continúa y obtienes comida múltiples sprints, empiezas a hacerte una idea de, bien, bueno, este boleto es más o menos tantos puntos. Y así va a tardar tanto en implementarse. Sabemos que podemos llegar a través de unos 30 puntos para sprint. Así podemos traer 30 puntos de cosas a la tirada. Puntos de boletos. 17. poker ágil: Una buena manera de hacer la estimación de puntos es con Agile poker. Con algunas de estas tarjetas, puedes conseguirlas, conseguirlas en cualquier parte. Y así cada miembro del equipo obtendría un juego de estas tarjetas. Y las cartas tienen valores de puntos en ellas siguiendo la secuencia de Fibonacci. Entonces tienes como la mitad 0.123, 581320. Estos van a 25, por lo que hacen muy poco comprar tarjetas. Nunca tendrías boletos de 100 puntos. Tienes infinito desconocido. Y así la idea es que todos obtengan un conjunto de estos. Todos los sostendrían como un póker y tú estimarías, entonces dices, Bien, vamos a estimar este boleto ahora. Y a lo mejor, a lo mejor recojo éste. A lo mejor otro miembro del equipo va y recoge este. Y luego una vez que todos hemos escogido, les damos la vuelta. He ido gratis, alguien más viene por ocho. Tan grande diferencia ahí, hablamos de esa diferencia y luego acordaríamos un valor de puntos, pero permite a todos dar una estimación independiente. Entonces puedes averiguar si todos han escogido tres excepto una persona. Probablemente quiera ir gratis después de un poco de discusión. Pero es una buena manera de obtener la opinión independiente de todos antes de volver a estar juntos y discutir los temas y tratar de calcular el valor de los puntos. 18. Velocidad: Hablamos de esta idea de que los puntos no necesariamente necesitan igualar tiempos. Se puede señalar a la complejidad abierta. Así que algo realmente simple podría ser un punto. Algo realmente complejo podría ser decir, un punto 13. Y luego después de haber hecho un par de sprints, como que te haces una idea de cuántos puntos estás pasando en un sprint. De hecho, normalmente medimos eso. Entonces vemos cuántos puntos nos movimos a la columna de volcada en un sprint en particular y eso podría ser cualquier cosa. Entonces digamos que la lata consiguió a través 35 o 42 o 47 puntos, sea lo que sea. Bueno, si tienes esos antecedentes de sprint, entonces un sprint, hiciste 55 cuando hiciste 42, cuando lo necesitabas para que fuera a siete. Bueno entonces sabes que en promedio, obtienes a través de unos 38 puntos por sprint. Entonces ese promedio se convierte en lo que llamamos la velocidad. Esa es la rapidez con la que nos movemos y la rapidez con la que nos movemos en este caso suele rondar los 38 puntos por sprint. Entonces, una vez que hayas calculado esa velocidad, entonces, ya sabes, bien, bueno, el próximo sprint, podemos aportar aproximadamente 38 puntos de cosas, porque eso es lo mucho que normalmente hacemos en un sprint. 19. Planificación del Sprint: planificación de sprint ocurre al inicio de cada sprint. Acordarás una duración de sprint, y luego trabajarás cuántos puntos crees que puedes completar en ese tiempo. Entonces, si estás haciendo, si estás trabajando en digamos, sprint de dos semanas y tienes una velocidad de 38 puntos, entonces probablemente traes 38 puntos con los boletos. Si por alguna razón acortarlo. Entonces tal vez haciendo un Sprint de una semana, entonces los mapas te dirán que probablemente puedas atravesar unos 19 puntos en la mitad del tiempo. Envías con cuántos puntos tienes que jugar. Y luego traes una cantidad apropiada de boletos para llenar ese valor de puntos. Entonces, si tienes 38 puntos con los que jugar, vas a tu cartera de productos y seleccionas 38 puntos en boletos, y esos se convierten en tu backlog de sprint. Entonces esa es la lista de tareas pendientes para el sprint en el que estás trabajando actualmente. Este punto, la estimación puede ocurrir en refinamiento o puede suceder en planeación de sprint si no ha sucedido en refinamiento, refinamientos, una buena idea. Si ya se han hecho y ejecutas la planificación de sprint, entonces tal vez si en un par de personas involucradas en el refinamiento y la planeación de sprint es un buen momento para verificar que todos estén de acuerdo con los puntos. Y por lo tanto, ese es un trabajo razonable que puedes hacer en este sprint. Una vez que hayas terminado, puedes comenzar tu sprint y ponerte a trabajar en todos esos boletos. 20. Retrospectiva: La retrospectiva, también llamada carretera retro para abreviar, ocurre al final de un sprint. Aquí revisas lo que funcionó bien y lo que no funcionó tan bien para que podamos resolver lo que queremos mejorar en el futuro. Es importante señalar aquí que se trata una reunión de proceso más que de una reunión sobre el trabajo en sí. Entonces digamos que teníamos un boleto que compramos en sprint y luego resultó que tiene un bloqueador. Y así no podíamos hacer nada. No se hizo dentro de ese sprint. En lo retro, no hablaríamos de cómo desbloquear ese boleto para poder hacerlo. Pero podríamos hablar de cosas como, bueno, ¿cómo es que no nos dimos cuenta de que tenía un bloqueador, por lo tanto estancado. Y qué podemos hacer en el futuro para asegurarnos de que no vamos a traer entradas que en realidad no se puedan completar en un sprint. Entonces probablemente comentes algunos de los boletos en los que trabajó y qué temas compraron esos. Pero no estamos comentando directamente sobre el trabajo directamente, sino más sobre cómo podemos trabajar juntos como un equipo mejor en el futuro para el equipo de América aún más rápido y más eficiente. Puedes hacer un retro de la manera que quieras. Pero tengo algunas ideas para ti en la siguiente lección. 21. Ideas para retrospectivas: En esta lección, veremos algunas ideas sobre cómo ejecutar sus retrospectivas. Entonces este es realmente un punto de partida y se te ocurren tus propias ideas, haces las cosas creativamente, te diviertes con ellas. Uno de los clásicos es Start, Stop, Continue. Así que dale a todos en tu equipo un rotulador y algunos post-its y póngalo en la pared o detente, inicia y continúa. Y la gente puede escribir sus sugerencias de cosas que debemos dejar de hacer, cosas que deberíamos empezar a hacer y cosas que debemos seguir haciendo. Entonces en este ejemplo, por ejemplo las sugerencias son, dejará de llegar tarde a las reuniones y de tener largas discusiones en stand-up. A lo mejor se están interponiendo en el camino. Entonces el próximo sprint, el equipo se concentra deliberadamente en detener estos comportamientos que los ácaros, cosas que queremos comenzar como, tal vez las retrospectivas siempre se organizan última hora y así reservar una sala de reuniones sería útil, y luego las cosas continúan. Así que empezamos a usar un nuevo servidor de pruebas para hace semanas cuando eso está funcionando muy bien. Vamos, sigamos haciendo eso. Otra forma de hacerlo es usar puntajes. Entonces podrías tener encabezamientos como, ¿qué tan seguro vas a entregar este proyecto? Cuánta energía sientes que tenemos como equipo y cómo psicológicamente el campo de seguridad y cada miembro del equipo puede dar un número de puntuación. Se puede poner ahí arriba de forma anónima. Y luego puedes mirar esos números y podrás trazar tu progreso a lo largo del tiempo. Entonces tal vez haga esto cada dos meses y vea cómo cambia. Pero también si te das cuenta, nuestra confianza ha bajado realmente o la seguridad ha bajado realmente. ¿Qué estamos haciendo como equipo en el que podamos mejorar? A lo mejor vamos a hablar más sobre ese tema. Lean Coffee es un tipo de reunión que funciona bien en retro también está fuera de metros. Y la forma en que esto sucede es que no hay una agenda preestablecida. Entonces, la primera tarea es crear una agenda. Y otra vez, tal vez, tal vez darle a todos publicarlo. Algunas personas escriben lo que quieren discutir abajo en un post-it, lo ponen en una pared, y luego todo el equipo puede votar sobre una orden para la discusión. Entonces hablas como si escogieras las cinco cosas de las que quieres hablar, nueva caja de tiempo, cada una de esas. Entonces digamos que el equipo quiere hablar sobre la forma en que estamos haciendo stand-ups. Lo primero, pones un temporizador para 5 min y tienes una discusión de cinco minutos. Y cuando suena la alarma, entonces el equipo puede votar para o bien decir, queremos hablar más de esto, sigamos hablando de stand-ups. O queremos pasar al siguiente tema. Y si el equipo vota para seguir adelante, entonces lo recoges el segundo post y hablas a través de eso. Y otra vez, haces lo mismo. Enseñó durante 5 min. Al final de esos cinco minutos, tú decides dónde esto necesita más tiempo o quieres seguir adelante. Y luego, finalmente, el trabajo en equipo. No toda retrospectiva tiene que ser trabajada platicar para que un equipo trabaje de manera cohesiva. Cosas como Smalltalk, cosas como jugar juegos, cosas como actividades de formación de equipos pueden ser muy importantes para encarcelar a ese equipo juntos. Entonces, si el equipo está cansado o si no lo está, es bastante desafiante como te gustaría, entonces hacer un poco de diversión en equipo y juegos también puede ser muy bueno. 22. Formas de trabajar: Uh, formas de trabajar reuniéndose es el equipo esté de acuerdo en cómo van a trabajar juntos. Entonces, cada equipo es diferente y los miembros pueden querer trabajar de diferentes maneras para diferentes equipos. Entonces preguntas como, Bueno, ¿ puedes recoger algún boleto del backlog o tiene que ser el de arriba? Lo asignas a la siguiente persona o lo dejas en blanco y lo dejas para que recojan lo que hay en nuestra definición de hecho. ¿Cuándo se llevarán a cabo las ceremonias y a quién invitaremos? ¿Cuánto tiempo tardará Sprint? Todas estas son preguntas de proceso las que el equipo necesita ponerse de acuerdo. Y ustedes discutirían todo esto en una reunión de formas de trabajo. Normalmente tendrías que reunirte cuando estás formando un nuevo equipo y poniéndote en marcha. Pero también si muchos miembros del equipo se van y se unen nuevos miembros, o solo ha pasado un miembros del equipo se van y se unen nuevos miembros, tiempo desde que te has herido y quieres renegociar algunas de las reglas del equipo, entonces llamar a una reunión de formas de trabajo es una muy buena manera de hacerlo. clave del éxito es asegurarse de que todos tengan voz y todos lleguen a su opinión sobre lo que funciona y lo que no, cómo les gustaría hacer las cosas. Y luego lograr que todos estén de acuerdo en ello para que todos en el equipo realmente adquieran esas formas de trabajar y todos trabajen juntos para apoyarse mutuamente. 23. Revisión de Sprint: Una revisión se lleva a cabo al final de un sprint o después de que se termine. El propósito de la revisión es revisar y demostrar el trabajo que se ha realizado. Entonces todos están invitados, todos desde el equipo de Scrum y también las partes interesadas externas quieren saber qué ha estado haciendo el equipo también. El equipo se turna para hacer una demostración de cada una de las características. Y puede haber preguntas de actores externos. Normalmente los mantenemos hasta el final de las reseñas que muestran todo y luego permiten algunos comentarios. En este punto, todos los boletos están hechos. Entonces, si hay algún cambio, si hay algo de trabajo adicional que surja ese debería plantearse como boletos nuevos. 24. Equipo de Scrum: Scrum tiene que ver trabajo en equipo y los equipos de Scrum son interfuncionales. ¿Qué significa eso? Bueno, en los viejos tiempos, los equipos podrían estar organizados por títulos de trabajo. Así que tendrías un equipo de diseñadores por aquí, un equipo de ingenieros por aquí, un equipo de probadores por aquí. Y cuando quisieras algo diseñando, envíalo a la piscina de diseño. Y la alberca de diseño funcionaría en todo y luego la pasaría de vuelta. Entonces, cualquier cosa que necesitara diseño para toda la compañía, íbamos a un equipo de diseño específico. Los equipos de scrum no funcionan en absoluto así. Son interfuncionales en el equipo de Scrum deben tener todo lo que necesita. Un equipo de Scrum habría dicho, un diseñador e ingeniero, un probador, cualquier objetivo puede ser un analista de negocios que necesitemos en eso, todo está contenido en el equipo. que en lugar de tener que ir a los diseñadores, a los ingenieros, al texto es que todo lo que necesitas está encapsulado dentro de un equipo. Para que a los equipos les guste una especie de unidad móvil en el ejército que pueda operar de manera independiente sin ser bloqueados por otros equipos, sin tener que ir. Necesitamos un probador para esto, pero no hay prueba disponible. Todo está contenido dentro del equipo. que cuando estamos tratando de superar nuestro backlog de sprint, estamos tratando de entregar nuestros boletos no fueron bloqueados por otras personas. 25. Propietario del producto: El propietario del producto es el responsable final del producto o proyecto. Entonces se trata de tomar decisiones y prioridades, sobre cómo va a ser el proyecto y cómo va a funcionar. Entonces, por ejemplo, si pensamos en nuestra página de productos de comercio electrónico, ¿cómo va a verse exactamente? ¿A dónde va, a dónde, cómo se sentirá la experiencia del usuario? Y también prioridades, como ¿qué parte del sistema debería construirse primero? ¿Debería ser la página del producto la que echa un vistazo a la navegación? ¿Cuál pedacito? Ahora bien, lo que no es es un papel técnico. Entonces, cuando digo cómo va a funcionar, eso es en gran medida una cosa de experiencia de usuario. Que imaginando ser el cliente usando esta cosa, en lugar de cualquier conocimiento técnico. Todo el conocimiento técnico residirá en los ingenieros y el propietario del producto realmente no necesita saber cómo se implementa. Dicen lo que quieren implementado. Ahora, cada producto debe tener un propietario de producto. Entonces, si tienes, estás pensando en poner dos propietarios de productos en un mismo producto. Probablemente necesites dividir ese producto. Pero el propietario de un producto podría cuidar de varios productos. Entonces, si tienes muchos productos pequeños, el propietario de un producto podría cuidar de múltiples de ellos. Lo que hace que un buen propietario de producto alguien que sepa lo que quiere, pero también es flexible cuando algo no se puede hacer. Entonces por ejemplo digamos que estás construyendo una casa. El dueño del producto es la persona que dice, Bien, bueno, me gustaria recamaras y baños y cochera. Pero entonces si Comisión de Planeación regresa y dice, bueno, no puedes tener un garaje, quieres el dueño del producto que esté dispuesto a decir, bien, bueno, cambiemos eso y voy a especificar otra cosa. Pero tiene una visión clara para dar al equipo, para dar a los ingenieros sobre lo que buscan. 26. Maestro de Scrum: El Scrum Master ayuda al equipo de scrum a funcionar sin problemas. Entonces, a pesar del nombre Maestro, en realidad son otro miembro del equipo y están en el mismo nivel. No son el jefe del equipo. Organizan y facilitan ceremonias, pero a petición del equipo. Por lo que no necesariamente tiene que ser hecho por el Scrum Master. Cualquiera puede liderar cualquiera de las ceremonias desde cualquiera de los miembros del equipo puede dar un paso al frente y decir, Bueno voy a dejar el retro, voy a dejar el diario Scrum o si prefieren el ScrumMaster puede hacerlo. Los trabajos típicos para un ScrumMaster pueden implicar reservar salas de reuniones y facilitar las ceremonias, hablar con otras personas sobre bloqueadores. Entonces, si el equipo necesita comunicarse con otro equipo para resolver algo a los maestros de la escuela, una buena persona para enviar allí, representando al equipo en reuniones más amplias de la empresa. Hablaremos un poco más de eso en escalar squirm. Pero realmente en cualquier momento donde el equipo necesite ir a hablar con la gerencia, necesita ir a hablar con otro grupo. El escamoso es realmente buena persona para representarlos como asegurando que se cumplan las reglas. Entonces, si estamos de acuerdo en algo de una manera de trabajar reuniéndonos como que todos vamos a tiempo para nuestro medio nueve llegar a tiempo para nuestro medio nueve Daily Scrum y la gente no va a llegar a tiempo, entonces normalmente depende va a llegar a tiempo, entonces normalmente del maestro de escuela no decírselo sino decir, Oye, solo un recordatorio. Acordamos que todos estaríamos ahí el medio nueve y ninguno de ustedes también está capacitando y motivando al equipo. El scrum master normalmente tiene un buen conocimiento de Agile y Scrum y puede traer esas recomendaciones como excelentes formas de trabajar en el equipo y hacer que un equipo se entusiasme con el trabajo que están haciendo. 27. Analistas de negocios: Los analistas de negocios, también conocidos como BA para abreviar, están involucrados en la recolección de requisitos. Qué equipo normalmente tendría uno o dos BA. Y su trabajo es comprender los requisitos del usuario y formar un puente entre lo que quiere el propietario del producto y lo que los ingenieros necesitan saber. dueño del producto podría decir algo así como, quiero la capacidad de los clientes para rastrear sus entregas y ver dónde están sus entregas. El BA se iría y lo desglosaría en un recorrido del cliente. Entonces por ejemplo el cliente, como cliente, quiero poder ver mis pedidos como cliente. Quiero ver los detalles de un pedido específico como cliente, quiero ver la información de seguimiento para cualquier carrera en la que se esté enviando el pedido. Y así tomarían esa solicitud general de los propietarios de productos, desglosarían en boletos y desarrollarían criterios de aceptación. Entonces, ¿cómo sabremos cuándo se hace? Por ejemplo, si estamos viendo un boleto como cliente, quiero ver la información de seguimiento. El criterio de aceptación sería decir, el cliente puede leer el número de seguimiento. El cliente puede hacer clic en un enlace para ir al sitio web de Carreras y obtener más información. Y tal vez ese sea el criterio de aceptación para ese boleto. Por lo que el BA es responsable de traducir esos requisitos generales en más específicos con los que los ingenieros puedan trabajar. 28. Ingenieros: Los ingenieros o la gente que trabaja en la cosa, sea cual sea la cosa, sea cual sea el proyecto en el que estés trabajando. Por lo que a menudo se le llama el Equipo de Desarrollo, pero incluye un campo más amplio que este. Entonces cosas como probadores, ingenieros de automatización, ingenieros de aseguramiento de la calidad, todas estas personas estarían incluidas en él. Y realmente depende del tipo de proyecto en el que estés trabajando en cuanto a qué incluiría esto. En un proyecto de software, tendrías que tener tus ingenieros de software reales y probablemente algunos ingenieros de automatización de pruebas. Y entonces la prueba es en sí misma. Pero si estás trabajando, digamos, en un proyecto de investigación, entonces eres ingenieros. El equipo de desarrollo sería en realidad el equipo de investigación o los investigadores. Si tu proyecto es construir una casa que podrían ser constructores, trabajadores para hombres, ese tipo de cosas. Nuevo de alguna manera no importa porque en Scrum, hay un enfoque real en trabajar juntos como equipo para entregar boletos. Entonces, si bien podrías tener tus roles individuales de yo soy diseñador, soy ingeniero de software, soy una prueba o lo que sea, en realidad lo que realmente importa es la salida del equipo. Entonces dondequiera que todos se apaguen a sus roles, estén haciendo cosas diferentes, se estén ayudando mutuamente. Lo importante es que todos trabajen juntos para lograr ese objetivo de sprint para entregar esos boletos y no tanto enfocarse en compartimentar a todos en este equipo de diseño. Este es el equipo de implementación, este es el equipo de pruebas. Solo hay un equipo de Scrum de todos contribuyendo al éxito del proyecto. 29. interesados: de interés son personas ajenas al equipo, pero con interés en el trabajo del equipo. Entonces, ¿qué tipo de gente podría no ser? Bueno, algunos ejemplos, los gerentes de nuestra compañía, miembros de otros equipos que trabajan en soluciones de proyectos relacionados, arquitectos y arquitectos técnicos trabajan en toda la compañía. Equipos de mercadotecnia y ventas. Legal también podría estar involucrado, y también potencialmente cosas como clientes, proveedores y reguladores también serían partes interesadas. Los propietarios de productos a menudo invitaban a las partes interesadas a las revisiones de sprint, y también son bienvenidos a venir al Scrum diario también. Pero no tendrían ninguna entrada sobre The Daily Scrum para que puedan venir a escuchar, pero serán los miembros del equipo de Scrum los que hablaron. Por lo general, las partes interesadas no serían invitadas a la planificación de sprint o retrospectiva porque esa es una zona segura para que el equipo discuta su funcionamiento internamente. 30. Un equipo típico de scrum: Veamos un equipo típico de scrum. Entonces, dentro del equipo, probablemente tengamos un propietario de producto, scrum master y analistas de negocios desgastados o más. Entonces un propietario de producto, scrum master, normalmente uno o dos analistas de negocios. Y luego tenemos ingenieros. Ingenieros cubre realmente cualquiera de los hacedores. Entonces, un poco desarrolladores, diseñadores, pruebas de control de calidad, investigadores si estás trabajando en un proyecto de investigación, y trabajadores, si estás construyendo una casa, sea lo que sea, esas son las personas que hacen los boletos reales. Y luego fuera del equipo tienes stakeholders. Por lo que esto podría incluir gerentes de empresas, miembros de otros equipos, marketing y ventas legales, clientes y proveedores, y reguladores. 31. Incorporación de miembros de equipo: Si estás agregando miembros a tu equipo, entonces ¿cómo lo factoriales? La cantidad de trabajo que pueden hacer a la hora planear para futuros sprints. Bueno, lo primero que queremos hacer es calcular nuestra velocidad y nuestros puntos por miembro del equipo. Entonces digamos que nuestra velocidad es 48, y actualmente hay seis miembros en el equipo. Entonces podemos dividir 48 por seis y podemos ver que cada miembro del equipo está produciendo aproximadamente ocho puntos. Si luego agregamos un nuevo miembro del equipo, entonces sabemos que vamos a tener otros ocho puntos con los que jugar. Entonces eso significa que en el primer sprint, normalmente usamos un multiplicador de ceros. Entonces asumimos que no van a poner ningún punto para el primer sprint. Segundo sprint, habremos encajado si fueron ocho puntos, tiempo va a subir por 0.5 y eso nos va a dar cuatro puntos. Y luego en el tercer sprint, asumimos que están al día y contribuyendo, lo que significa que pueden darle los ocho puntos al equipo. 32. Tipos de problema: En esta lección, veremos los tipos de emisión o tipos de boletos. Y hay tres primarias. Entonces la primera es una historia de usuario. Entonces esta es una nueva pieza de funcionalidad escrita desde la perspectiva de un usuario, de un producto, por ejemplo , como usuario, quiero poder ver reseñas de productos para el producto que estoy viendo actualmente. Agrega algo nuevo al sistema. Entonces tenemos un defecto o un libro, un libro con una característica existente que necesita ser arreglado. Ya hemos enviado y necesita una solución. Y entonces tenemos que levantar un boleto. Ahora importante aquí, solo es un error si no funciona de la manera en que se pretendía. Entonces, si construimos algo de cierta manera y el gerente dice, quiero que funcione de una manera diferente. Eso no es un defecto, es una nueva historia de usuario que cambia la forma en que funciona el sistema. Si el boleto original coincide con los criterios de aceptación, entonces no es un defecto. Si no hace lo que decía en el boleto original entonces es y levantarlo a granel. Y luego tenemos deuda tecnológica. Entonces estos son problemas con el código que no tienen ningún efecto observable en el sistema. Entonces, algo debajo de ese desarrollador sabe que necesitamos arreglar, pero en realidad un usuario no necesariamente se daría cuenta. 33. Historias de los usuarios: En Agile, escribimos boletos como historias de usuario. Eso significa que en lugar de tener un ticket que diga algo como formulario de inicio de sesión, escribimos algo así como como como cliente, quiero verificar el estado de mi pedido. Ahora, a menudo eso implicaría un formulario de inicio sesión para que puedan iniciar sesión y ver sus pedidos, pero puede que no. Entonces, ¿por qué lo escribimos en este extraño formato de historia de usuario? Qué historias lo mantienen enfocado en el usuario. Así que estamos todo sobre el viaje del cliente de pasar por lo que sea que estamos construyendo y escribir de esta manera realmente mantiene ese enfoque en el usuario final. En segundo lugar, evita el trabajo innecesario. Entonces si tienes algo así como, quiero ver mis facturas anteriores, aquellas que requieren un formulario de inicio de sesión. En la siguiente lección, veremos un buen estudio de caso que demuestra que tal vez no siempre sea así. Y por lo tanto podemos ahorrarnos algo de trabajo si utilizamos estas historias de usuario. Crea criterios de aceptación muy claros. Si tu boleto, dice formulario de inicio de sesión. Bueno, ¿cómo sabes si el usuario es capaz de lograr lo que quiere lograr? ¿Quieren iniciar sesión? ¿Qué propósito les da eso? Mientras que si es algo como quiero como cliente, quiero verificar el estado de mi pedido. Está muy claro donde el sistema V0 hace eso o no. ¿El cliente puede ver el estado de su pedido? ¿Sí o no? Ahí tienes unos criterios de aceptación muy claros. Y es por eso que usamos historias de usuarios. 34. Estudio de caso de desarrollo basado en el comportamiento: De lo que estamos hablando aquí cuando escribimos historias de esta manera es el desarrollo impulsado por el comportamiento. Esta es una metodología que dice que escribimos lo los usuarios deberían poder hacer en inglés sencillo. Y entonces eso se convierte en nuestro criterio de aceptación. Escribimos pruebas automatizadas contra eso para ver si el sistema está haciendo eso. Y digamos que hay una gran cantidad de trabajo y tengo un estudio de caso para ti. Entonces había una firma de contabilidad y lo que querían guerras para que los clientes pudieran ver facturas anteriores. Ahora bien, si solo saltamos a eso y lo construimos de la manera normal, habríamos dicho: Bueno, bien, necesitamos un formulario de inicio de sesión y cada cliente necesita un inicio de sesión, así que necesitan ingresar su dirección de correo electrónico y luego necesitan una contraseña. Y así el cliente, tendríamos otra contraseña más para recordar en este mar de miles de contraseñas y probablemente la olviden. Entonces necesitaríamos construir un enlace de contraseña olvidada que les enviara por correo electrónico una nueva contraseña. Entonces, cuando inevitablemente olvidaron su contraseña, podrían solicitar una nueva. Podrían restablecer su contraseña y luego podrían iniciar sesión y ver esas facturas antiguas. En su lugar, este producto utiliza estas historias de usuario y desarrollo impulsado por el comportamiento. Entonces el criterio de aceptación fue como cliente, quiero ver facturas anteriores. Entonces, cuando el proyecto lo miraba de esa manera, se dieron cuenta de que lo más sencillo era permitir que el cliente ingresara su dirección de correo electrónico. Y les enviaría por correo electrónico un enlace mágico que les permitiría ver todas sus facturas anteriores. Entonces, en lugar de tener que construir todo el formulario de inicio de sesión y el formulario Olvidé mi contraseña, en lugar de que el usuario tenga que recordar otra contraseña mirándola desde este ángulo de historia de usuario, todos se dieron cuenta de que en realidad la forma más rápida de hacerlo es simplemente enviarles un enlace que les permita acceder a ella. Y es tan seguro como tener un inicio de sesión porque tienes el acceso al correo electrónico y luego ellos pueden ver todas sus facturas anteriores sin una carga de trabajo de desarrollo y sin que el usuario tenga que almacenar otra contraseña. Usando estas historias de usuario, uso de este enfoque de desarrollo impulsado por el comportamiento puede ahorrar una gran cantidad de tiempo y también puede producir una mejor experiencia para el cliente. 35. Ser "lo suficientemente bueno": Un concepto clave aquí es la idea de que algo sea lo suficientemente bueno. Necesitamos construir la función hasta que coincida con los requisitos del usuario, los criterios de aceptación. Y entonces tenemos que parar y cerrar ese boleto. Y si necesitamos hacer más trabajo después, podemos levantar un nuevo boleto. Pero básicamente, lo que tratamos de cumplir, lo que necesita cumplirlo, asumiendo que necesitamos todas estas cosas extra. Entonces por ejemplo digamos que estamos hablando de que tenemos nuestra tienda de comercio electrónico y puedes ver la página de productos y queremos mostrar productos similares. Y a lo mejor la historia de usuario es, como usuario, quiero ver productos similares a este. Bueno, podríamos irnos y podríamos construir un sistema de IA masivamente complejo que recomiende productos. Pero también podríamos simplemente poner sobre los productos que están en la misma categoría ahí que cumplirían con el requisito del usuario. Y no terminaríamos con una tarea de desarrollo masiva porque tal vez solo mostrar los productos similares y la misma categoría en realidad sería genial. Y podemos enviar eso muy rápido y eso funcionaría. Realmente no obtendríamos ningún beneficio al construir un enorme sistema de IA para recomendar productos. O tal vez enviamos lo fácil. Y luego nos damos cuenta de que en realidad obtendríamos mucho valor al tener mejores recomendaciones de productos. En qué punto podemos construir lo mejor, porque sabemos entonces que vale la pena invertir el tiempo. Esto es lo que se conoce como metodología Lean. Entonces obtienes algo ahí afuera en nuestra forma básica. Ves para usuarios como él, ves a qué responden, y luego reevalúas y vuelves a ir, así como hemos hablado de estas metodologías ágiles, has iterado, entregando algo, diciendo cómo funciona, mejorándolo, en lugar de construir este enorme producto del big bang que podría fallar desde el principio. 36. Invertir: En esta lección, veremos el acrónimo invest que se puede usar para buenas historias de usuario. Entonces yo es para cada independiente, cada tienda debe estar por su cuenta y es negociable. Las historias no son fijas pero se pueden actualizar si es necesario. Entonces, traer esa entrada y cosas como incluso cuando comienzas a implementar, si algo no se puede hacer por requisitos técnicos, es frustrante, pero tal vez necesites mirar cómo reelaborar la historia. Si ese es el caso, V es valioso, necesita agregar un valor genuino para el usuario. ¿Cómo va a obtener una mejor experiencia el usuario por este cambio? E es para estimable. Entonces necesitas tener una idea aproximada de cuánto tiempo tardará. Si no puedes estimarlo, entonces lo que probablemente tengas que hacer es plantear y boleto de investigación. Un ticket que es como desarrollador, quiero investigar cuánto tiempo tardaría en implementar esta característica. Y luego timebox eso para decir medio día y ver si se puede resolver una escala de tiempo difícil. Y luego en base a esa escala de tiempo, sabrás si quieres seguir adelante con el boleto o no. S es para pequeños, por lo que se puede entregar dentro de un solo sprint. Cualquier cosa que esté tomando múltiples sprints necesita ser desglosada aún más. Y T es comprobable. Criterios claros de aceptación, ¿cómo sabría un usuario si este ticket estaba completo? E idealmente, también hemos automatizado las pruebas. Así que realmente pensando en cómo podemos probarlo en la cobertura de prueba automática tipo de manera desde el principio. 37. Prototipos y laboratorios de usuario: Un bowl cooperativo tanto de Agile como Lean es construirlo rápidamente, construir algo, básicamente, ponérselo frente al usuario y ver cómo funciona eso. Ahora bien, una buena manera de hacerlo es con la creación de prototipos. Así que puedes usar algo como Adobe XD para construir interfaces de usuario simuladas. Y luego se le puede dar eso a un usuario. Vea cómo usan el sistema, vea cómo les va, haga algunos cambios antes de construir la complicada pieza de software ellos mismos. ¿Cómo se hace esto? Bueno, te lo burlas en algo así como Adobe XD. Y entonces le pediría a un usuario de muestra que viniera tal vez a un laboratorio. filmarías, filmarías la pantalla. Ve a verlos como lo están haciendo y solo toma notas de, bien, lo que les funciona. Participa en un diálogo con ellos, di, Bien , Bien, Bien, Me gustaría que encontraras este producto. ¿Cómo lo harías? ¿Van a ir a navegar y van a buscar y van a ver ese historial de pedidos para ver si lo han comprado previamente y pueden encontrar el enlace de esa manera? Qué método va a ser el mejor para ellos. Les das la demo, les pides que hagan la tarea. Hablas con ellos sobre dónde están pensando en conseguir que te hablen, ¿de acuerdo? Ya lo he dicho, trata de encontrar este producto. ¿En qué estás pensando ahora? Y el usuario podría decir, Oh, bueno, probablemente use una búsqueda, y la búsqueda es mi forma favorita de hacerlo. Y entonces podrían buscar y subir. Y de esa manera, sabemos exactamente cómo un usuario quiere que funcione el sistema, y si es donde podamos construir ese sistema y si podemos adaptarlo a sus necesidades. Ahora bien, mucho de esto lleva mucho tiempo, pero pedirle a alguien que entre a tu oficina, instalando un laboratorio donde puedas completar lo que está pasando o tener que verlo y darle un conjunto de tareas. Todo lleva tiempo, pero ese tiempo realmente lo devuelve cuando entregas algo que está exactamente en lo que quiere el cliente. Si puedes ver cómo usan el sistema, optimizarlo a su alrededor y realmente obtener esa retroalimentación desde el primer día. Al principio lleva mucho tiempo, pero luego tu tiempo de desarrollo es mucho menor porque estás construyendo exactamente lo que ellos quieren. Mientras que los sistemas tradicionales, harías el gran bloque de desarrollo. Entonces resultó que en realidad no era lo que querían y tenemos que rediseñar todo invirtiendo ese tiempo temprano. Entonces podemos construir exactamente lo que el usuario quiere y entregar esa funcionalidad más rápido. Así es, exactamente lo que tienen que hacer. Y podemos hacer eso por cosas como prototipado rápido y laboratorios de usuarios. 38. Requisitos funcionales: Los requisitos funcionales le indican lo que el sistema debe ser capaz de hacer. ejemplo, si decimos intentar verificar el estado de nuestro pedido, el requisito funcional podría ser que el usuario pueda ver el estado y los otros clientes no puedan ver el pedido específico de los clientes. O si estamos construyendo un sistema de inicio de sesión, por ejemplo, ¿es por contraseña, es por correo electrónico, es a través de autenticación de dos factores? ¿Y cómo son las contraseñas? ¿Reiniciar? Entonces, ¿hay un mecanismo de reinicio? A lo mejor los usuarios deberían poder, se les debería pedir que cambien su contraseña cada 90 días. Todas estas cosas son requisitos funcionales porque los requisitos funcionales documentan las funciones del sistema. Documentan cómo funciona el sistema. No ligeramente diferente a los requisitos no funcionales. Y cuando siga discutiendo esos, creo que podrán ver la diferencia de cuál es cuál. 39. Requisitos no funcionales: Los requisitos no funcionales son cosas que son importantes o esenciales, pero que no afectan directamente al funcionamiento del sistema. Entonces, ¿qué tipo de cosas podrían ser? Bueno, cosas como el rendimiento, ¿qué tan rápido responde el sistema? Disponibilidad y escalamiento a alta carga? ¿El servicio siempre va a estar disponible como monitoreo de seguridad? Entonces, ¿cómo sabrás si algo rompe reportando? ¿Podemos preguntar al back-end? Podemos ver qué está pasando? Accesibilidad y usabilidad? Esos requisitos probablemente más funcionales ahora, es realmente importante para esos y luego la documentación. ¿Cómo sabrán los futuros desarrolladores o los usuarios del sistema cómo funciona? Así que tenga en cuenta que estas cosas no son opcionales, ¿verdad? Al igual que la seguridad y la accesibilidad son requisitos legales porque nuestros proyectos tienen que ser accesibles. Y si no tenemos suficiente seguridad, vamos a violar la ley GDPR. Entonces las cosas, estas cosas no son extras opcionales que todos necesitan incluso, pero en realidad no son parte de cómo funciona el sistema. Entonces, por ejemplo si tienes una página de estado de pedido que muestra a un cliente dónde está su entrega, ese es el requisito funcional ahí es que la página le diga dónde está su entrega. Pero también hay un montón de requisitos no funcionales . Entonces, por ejemplo, ¿qué tan rápido tarda una página en cargarse? Bueno, podría tomar, no sería segundo ni 1 min. Ahora bien, si toma 1 min, los usuarios van a enojarse mucho y probablemente van a irse e ir de compras a otro lugar. Pero técnicamente, si lo muestra que cumple con los criterios de aceptación del usuario puede ver el estado del pedido. Entonces no es técnicamente un requisito funcional, pero es realmente importante. De igual manera, la seguridad si alguien más puede ver el estado de su pedido, eso no necesariamente viola los requisitos funcionales. Pero sería muy importante porque tendríamos exponer datos privados a alguien que no debería tener acceso a ellos. Por lo tanto, es muy importante que pensemos los requisitos no funcionales así como en los requisitos funcionales. Pero son fáciles de olvidar. Olvidé que construyes una función y te olvidas de ejecutarla a través las pruebas de seguridad o las pruebas de accesibilidad y F o algo se estropean. Por eso es muy importante incluir estos requisitos no funcionales en la definición realizada. Por lo tanto, no permita que un boleto se mueva a la columna hecho a menos que tenga monitoreo implementado, a menos que se haya probado su usabilidad, a menos que se haya probado el rendimiento. Pero todas esas cosas en tu definición de hecho y luego, ya sabes, probar contra ellas para que sepas, todo lo que entra en ello no las llama cumple con los requisitos funcionales y no funcionales. 40. Deuda técnica: Hay un tipo de boleto que un ingeniero podría recaudar y que es deuda tecnológica o deuda técnica. Entonces esto ocurre cuando hacemos algo para agilizar la entrega, sabiendo que vamos a tener que abordarlo más tarde. Por ejemplo, digamos que estamos construyendo algún software que tal vez sea como una aplicación meteorológica. Lo que tira si en los datos meteorológicos en de una fuente externa. Y hemos estado usando la biblioteca a. Pero ahora necesitamos usar la biblioteca ya sea porque es mejor o nos permite hacer algo y solo queremos cambiar a la biblioteca B. Será una manera muy rápida de hacerlo sería traer la biblioteca B a nuestra aplicación sin quitar la biblioteca a como eso seguía cumpliendo con los requisitos si ahora vamos a usar la biblioteca B, aunque biblioteca a todavía estaba incrustada o traída a la base de código de alguna manera. Ahora bien, si lo hiciéramos, eso generaría algo de deuda tecnológica. Debido a que la biblioteca a todavía necesita ser removida en algún momento, simplemente no la hemos hecho todavía. Ahora, ¿por qué es importante abordar la deuda tecnológica? Bueno, uno, hace que el código sea mucho más fácil leer si eres nuevo en el proyecto y estás pensando, Oh, por qué usamos library be, pero también tenemos Biblioteca a ahí. ¿Qué está pasando ahí? Eso puede ser realmente confuso y por lo tanto, es más difícil abordar a la gente. Es más difícil hacer un trabajo de desarrollo futuro. Puede ralentizar cosas como el proceso de construcción. Entonces, cuando estamos compilando el software, si estamos trayendo dos bibliotecas, eso lo va a hacer, lo va a hacer más grande de lo que necesita ser en ralentizarlo ahí abajo. O podría afectar el rendimiento, por ejemplo, si se trataba de una biblioteca JavaScript del lado del cliente. Y estamos trayendo en biblioteca a, biblioteca B, pero solo usando biblioteca be. Entonces estaríamos cargando la biblioteca a en el navegador del usuario sin necesidad de ello. Por lo que tiene muchos efectos no funcionales, aunque no necesariamente afecte la función del software. Y eso es deuda técnica y por qué es importante abordarla. 41. Cancelación de un sprint: En raras ocasiones, los requisitos para el proyecto podrían cambiar a mediados del sprint. Tenemos este principio de Scrum de nada nuevo entrando en un sprint. Entonces definimos las tareas que queremos hacer al inicio del sprint y luego iniciamos el sprint y las hacemos. Y no traemos más boletos hasta el próximo sprint. Entonces, ¿qué hacemos si lo que sea en lo que estemos trabajando se vuelve irrelevante y ya no necesitamos cumplir con los objetivos del sprint? Bueno, en tales ocasiones podemos cancelar un sprint y el dueño del producto tiene la autoridad para cancelar el sprint. Piensan que los requisitos han cambiado y no tiene sentido seguir trabajando en lo que estamos trabajando. Pueden seguir adelante y cancelar el sprint. Cualquier boleto en el que estuviera trabajando, luego vuelve al backlog del producto y formamos un nuevo sprint. Entonces tenemos una nueva reunión de planeación de sprint. Trabajamos cuando nuestro papel de periódico va a ser y traemos datos en boletos nuevos para que coincidan con los nuevos requisitos. 42. ¿Qué es la gestión de versiones ágil?: Cuando hablamos de Agile, estamos hablando de pequeñas iteraciones, pequeñas características pequeñas que construimos, que nos preparamos y luego las mejoramos. Ahora algunas organizaciones abrazan esta idea de trabajar Agile, pero en realidad las implementaciones todavía se hacen de una manera Big Bang. Entonces, todos estos equipos ágiles trabajan en funciones para un software, pero luego el software solo se envía cada dos meses y todas las funciones se lanzan al mismo tiempo. Entonces, cuando hablamos de Agile Release Management, estamos hablando de deshacernos de ese lanzamiento del big bang. Lo estoy reemplazando por un ciclo más iterativo, algunos más en línea con el trabajo de desarrollo que estamos haciendo en sprint, en sprints y en los equipos de Scrum. Entonces la idea es que podrías obtener un conjunto de características y podrías lanzar aquellas independientes de características en las que otros equipos están trabajando. Así que digamos equipo a, construye algunas características e implementa eso y basado en equipos, construye algunas características y se implementan por separado. Incluso podríamos estar hablando de boletos individuales. Así que TMA termina un tick in como parte de ese acabado, es fusionarse en la base de código principal e implementarlo, e implementar esos problemas uno a la vez. Sea cual sea la forma exacta de Agile Release Management termina siendo implementada. Se trata de reducir ese ciclo de desarrollo, ese ciclo de vida del software, para que podamos sacar pequeñas piezas de funcionalidad sin tener estos lanzamientos de big bang donde sacamos muchas funciones al mismo tiempo y no hacemos muchos lanzamientos y dijimos que queremos lanzamientos pequeños regulares en línea con el proceso Agile. 43. Ciclo de gestión de versiones: Todo el desarrollo pasa por un ciclo. Y en este caso vamos a ver el ciclo de gestión de lanzamientos. Así que puedes empezar realmente en cualquier punto, pero nosotros comenzaremos en la parte superior con las solicitudes de cambios. El propietario del producto quiere que algo cambie. Y así diseñamos una solución, creamos algunos criterios de aceptación que implementarían ese cambio. Luego lo construimos y escribimos el código y luego lo enviamos a otra persona para que lo revise para que pueda verificar que el código tenga sentido y sea una buena idea. Luego lo probamos para asegurarnos de que funciona y si pasa, eso luego desplegará ese pedazo de código. Entonces tendremos algún tipo de métricas son informes sobre su desempeño. Y si hay algún problema, entonces vamos a hacer reportaremos algunos temas. Trabajaremos juntos como equipo para plantear un defecto o plantear otra historia de usuario para cambiarlo. Y luego eso retroalimenta la solicitud de cambios. 44. Ventajas de la gestión de versiones ágil: ¿Por qué querríamos hacer lanzamientos de Agile? Bueno, aquí están las ventajas reales proceso de lanzamiento de Agile. El número uno es que saca las cosas más rápido. Así que estamos a punto de acortar ese ciclo de desarrollo. Entonces construyes una función, empujas de inmediato, puedes comenzar a recibir comentarios al respecto de inmediato. Si es un cambio importante, va a salir más rápido, el agrupamiento en una liberación más grande en el futuro. Número dos, funciona en línea con Agile. Entonces, si tienes todos estos equipos de Scrum trabajando de esta manera muy ágil, ¿por qué tu proceso de lanzamiento no soportaría eso? ¿Por qué de pronto volveríamos al enfoque del big bang, que tiene todos sus riesgos de fracaso? Número tres, permite que el equipo de scrum asuma la responsabilidad de la liberación. Entonces a la antigua manera, todos los equipos desarrollarían cosas y luego algunos del equipo tendrían que asumir responsabilidad de liberarlo y mirar bichos y monitorear el impacto de la fruta ha sido liberado. Cuando lo devuelves a un proceso Ágil donde cada equipo podría lanzar las funciones en las que han estado trabajando. Entonces el equipo de scrum puede asumir la responsabilidad de todo eso. Pueden empujar hacia fuera las funciones, pueden monitorear lo que está sucediendo. Pueden hacer una reversión si es necesario. Si hay el peor de los casos, hay algunos problemas y tienen que hacerlo. Pero encaja en línea con esta idea de que los equipos de Scrum son unidades independientes, interfuncionales. Asumen la responsabilidad con el boleto de principio a fin, y pueden guiar todo el proceso sin ser bloqueados por otros equipos. Y número cuatro, puede ser más seguro. Entonces está este tipo de mentalidad de la vieja escuela de la idea. A medida que construyes todas estas características, se las das a tus probadores y tu texto es cuando todos estos escenarios en él para asegurarte de que todo funcione en conjunto. Pero la realidad es que cuando lanzas 100 funciones de diez equipos diferentes al mismo tiempo, probablemente van a interactuar de formas que no imaginabas y es muy probable que las cosas salgan mal. Y cuando las cosas salen mal, es un verdadero dolor retroceder porque estás retrocediendo 100 características de diez equipos. Cuando permites estas versiones iterativas realmente pequeñas. Entonces, si un lanzamiento sale mal, es realmente fácil retroceder porque solo cambias una cosa. Y el equipo que lo cambió está manejando el lanzamiento para que puedan retroceder muy rápido. Yo diría que Agile Release Management no solo es más rápida y mejor, sino que también es más segura. 45. Horarios de lanzamiento comunes: Veamos algunos horarios de lanzamiento comunes. Todos ellos. El estilo más antiguo sería lo que llamamos un lanzamiento de Big Bang. Por lo tanto, es un lanzamiento grande para varios equipos y un gran equipo de pruebas revisen todas las características. Entonces este es el tipo de, digamos que tienes tres equipos diferentes trabajando en un producto. Estás, estás trabajando como Microsoft Windows nueve y quieres lanzar Microsoft Windows diez. Entonces todos los equipos que trabajan en eso ponen todos sus cambios en y tú lo sueltas. Lo del Big Bang que es Windows diez tiene todos los cambios a la vez. Y necesitas un enorme equipo de pruebas para revisar todas las características porque todos están poniendo estos cambios y no está claro cómo interactuarán o cómo se romperán las cosas porque necesitas volver a probar todo. Y así es muy lento. Entonces tenemos algo así como un sprint. Así que aquí estamos entrando en nuestro proceso de lanzamiento más ágil. Entonces un lanzamiento al final de cada sprint. Es agradable porque tiene un calendario de lanzamientos muy predecible. ¿Y cuál es el punto? Al igual que, podrías tener algunas férulas donde tienes mucho que liberar y tienes algunos sprints donde no tienes mucho que liberar. Y entonces probablemente quieras conseguir estas cosas cuando estás produciendo montones de cosas que pueden salir, probablemente quieras sacarlas más rápido. Y cuando estás produciendo no tanto material que necesita ser enviado, entonces ¿por qué lo harías, por qué soltarías? Entonces crea un poco de flexibilidad ahí. Bajando, entonces tenemos esta idea del lanzamiento de funciones. Entonces, lanzado manualmente, cada función está lista. Por lo que el equipo de scrum obtendrá una función lista. Entonces lo fusionarás manualmente en la base de código y lo liberarás. Rápido. Pequeños cambios. Es agradable y fácil de retroceder. Se requiere algo de gestión, como si fuera un proceso de liberación manual. Pero esto es incluso en el mundo Agile que tienen empresas que realmente han adoptado Agile feature release sigue siendo muy popular porque te consigue que rápidos, pequeños cambios sin tener los riesgos de continuo, lo que hablaremos a continuación. Tan continuo es donde cada cambio tan pronto como fusionas algo, simplemente se empuja hacia tu servidor de producción. Um, así que es súper rápido, muy fácil de retroceder porque estás empujando un solo commit. Y así, cuando estás rodando cosas hacia atrás, lo único que debes considerar es que el último commit se vuelve un poco complicado si solo te das cuenta de que está desglosado en la línea. Y entonces tal vez tengas que volver a tener múltiples commits. Pero si solo estás lanzando uno, probando, si funciona en producción y luego adelante y puede moverse muy rápido. Pero sí requiere un nivel muy alto cobertura de pruebas porque literalmente todo va a ser empujado hacia fuera y así podría romperse en cualquier momento. Y realmente necesitas ese alto nivel de cobertura de pruebas para asegurarte de que todo esté funcionando. 46. Claves para el éxito: Aquí hay algunas claves del éxito para Agile Release Management. número uno es obtener buy-in de la gerencia. Esto va básicamente por todo lo que haces alguna vez. Si puedes conseguir la gerencia a bordo, vas a tener un tiempo mucho más fácil. Y como discutimos anteriormente, hay algún tipo de gestión de la vieja escuela que prefiere lanzamientos de big bang porque piensan que son más seguros. Y así tiendo a centrarme en realmente venderlos en esta idea de realmente si hacemos estos lanzamientos realmente pequeños que podemos retroceder muy fácilmente. Y eso solo desplegaría una cosa a la vez para que sepamos cómo interactúa con todo lo demás. Es más seguro. Así que no sólo vamos a conseguir tus funciones más rápido, sino que también lo haremos para que las cosas salgan mal con menos frecuencia. número dos es diseñar características con la implementación en mente. Entonces, cuando estás construyendo una característica, ¿cómo vas a sacar esto? Un gran ejemplo son cosas como interruptores de características. Por lo tanto, puede implementar el código si lo coloca detrás del interruptor de características y luego lo enciende en una fecha posterior. Así que despliega el código, enciende la función. Si no funciona, simplemente lo apagas inmediato y no tienes que entrar en pánico. Y si puedes pensar con anticipación cuáles son los pasos que necesitaría para desplegar este ticket, entonces te va a resultar mucho más fácil hacer esos lanzamientos. El número tres es tener un buen plan de reversión. Si algo sale mal, ¿ puedes retroceder muy rápido? Tradicionalmente, en la metodología de cascada, no hemos tenido un gran método para hacer eso, pero es mucho más fácil cuando estamos haciendo estos lanzamientos realmente pequeños y genera mucha confianza si incluso cuando las cosas salen mal, solo tienes que escribir este pequeño comando. Se enrolla por toda la espalda automáticamente y todo está bien. Número cuatro, tienen una alta cobertura de pruebas automatizadas. Por lo tanto, desea asegurarse de que después de hacerlo cambiar, entonces puede ejecutar todo el recorrido del cliente es todos los escenarios que necesita hacer automáticamente usando todas las herramientas de prueba automatizadas que existen. Porque cuando estás haciendo lanzamientos realmente pequeños, entonces vas a querer estar probando constantemente. Haces un cambio, pruebas todo y haces un cambio, pruebas todo. La única manera de cubrirlo es con pruebas automatizadas porque no podrías tener suficientes probadores para hacer todos esos escenarios. Entonces, si obtienes esa cobertura de prueba, eso te da mucha confianza a ti y a la gerencia de que las cosas van a funcionar. Y número cinco, coordinar con otros equipos. Asegúrate de saber qué están haciendo otros equipos y cómo podrían interactuar contigo. Y también en cuanto a programar un ucraniano lanzado esta mañana, están haciendo y lanzamientos mañana, como vas a q cuando pueda tomar turnos para hacer estos lanzamientos, para que puedas sacar las cosas de manera rápida y eficiente. Y así no van a pisarse los dedos de los pies unos a otros. 47. Integración continua: La integración continua ejecuta las pruebas automatizadas después de cada commit. Entonces podría ser cada vez un desarrollador empuja algún código, lo ejecuta, o podría ser cada vez que un ticket se fusiona en un maestro, quieres ejecutarlo en esas ramas dependiendo de cuánto quieras gastar en tus herramientas de integración continua. Ahora te voy a mostrar un ejemplo aquí usando Travis, que es solo una de las opciones disponibles. Y tengo este proyecto aquí, que es un ambiente de aprendizaje de código abierto. Y he definido un archivo de configuración aquí solo para decirle al servidor de integración continua que está escrito en PHP. Y yo quería probarlo de nuevo, repentino punto 4.8, 0.0. Y aquí están todos los pasos que necesitas para configurarlo. Entonces eso significa que cuando empujo hacia arriba un commit, va a ejecutar las tareas tanto contra PHP como PHP 7.01. Podemos entrar en estos y ver qué ha pasado. Travis lo ha establecido todo. Se ejecuta la instalación como una solicitud y luego se ejecuta la unidad PHP para ejecutar las pruebas y se pasa. Entonces eso es genial. Y luego se hace exactamente lo mismo aquí, pero está funcionando de nuevo, 7.4. Entonces, si tiene múltiples configuraciones de producción diferentes, puede tener la prueba de servidor de integración continua contra todas estas configuraciones. Y también puedo ver una historia completa. Entonces, si voy a Construir historia, esto se mostrará cada vez que haya empujado un commit, se hace una compilación. Y por ejemplo aquí, teníamos uno que falló en la construcción. Así que podemos entrar y ya no podemos ver los registros desgraciadamente, pero sabemos que algo salió mal ahí. Y luego arreglo algo más aquí. Entonces en este caso se estaba cambiando la versión de PHP para que coincidiera con el servidor. Y podemos ver que la construcción está funcionando de nuevo. Así que es muy fácil de rastrear. Puede ejecutar las pruebas automatizadas contra una variedad de entornos y realmente puede ver fácilmente lo que salió mal porque puede ver exactamente dónde dejó de funcionar la compilación. 48. Entrega continua: Un paso adelante de la integración continua es la entrega continua. Así que aquí el código pasa automáticamente todas las pruebas automatizadas y se implementa automáticamente en su entorno de producción. Ahora bien, esto no significa que estés desplegando cada commit. Entonces hay varias estrategias de ramificación. Podrías usarlo, podrías tenerlo para que tengas una rama de producción. Y cada vez que fusionas algo de master a producción , ejecuta todas las tareas automatizadas. Y si eso funciona, suben sin ninguna otra intervención humana. O puedes tenerlo donde Master esté sentado en tu entorno de producción. Y cada vez que un equipo se fusiona y ticket individual en master, ejecuta todas las pruebas y se despliega automáticamente. Lo que es, está quitando la idea de despliegue manual. Así que un ticket puede fusionar una pieza de característica en todas las pruebas se ejecutan automáticamente y si está bien y se empuja hacia arriba al entorno de producción. 49. Herramientas de entrega continua: Hay una gran selección de diferentes servidores de compilación y herramientas de integración continua por ahí. En esta lección, discutiremos algunas de ellas. El primero a mencionar es probablemente Jenkins. Entonces este es un servidor de automatización de código abierto. Entonces necesitas hospedar esto tú mismo. Necesitas tener un servidor en tu organización y administrar Jenkins tú mismo. Pero es de código abierto, es gratis y puedes ejecutarlo internamente. Luego tenemos los entornos alojados que normalmente se conectan a. Si tienes algo así como un repositorio de GitHub, se conectará a eso y extraerá tu código desde allí. Entonces tenemos a Travis CI, cual te mostré el ejemplo. Y luego también tenemos un CircleCI. Y si prefieres mantener las cosas en GitHub, entonces GitHub realmente tiene una cosa llamada GitHub Actions, que te permite hacer CI, procesos de CD y obviamente se engancha muy bien si tu repositorio está ahí o puedes usar una plataforma como Get lamp. Esto es como un servidor de integración continua y obtener hub integrado en uno. Entonces es tanto para el servidor Git como también construirá tu software para ti. Y luego Team City es otro servidor de integración continua que también es muy popular. 50. Software ágil: Hasta ahora, en su mayoría hemos hecho cosas con hojas de cálculo y las publicamos. Y esta es una excelente manera de aprender los fundamentos y entender cómo funcionan los sistemas. Pero en un contexto empresarial, muchas de estas cosas normalmente se hacen usando software de gestión de proyectos. Y esto es realmente bueno, sobre todo si tienes un equipo remoto donde hay gente por todas partes y todos necesitan poder ver el tablero y el hijo donde están los boletos. Y tienes a todos colaborando juntos. Aquí es donde realmente entra en juego el software de gestión de proyectos . Y así en este módulo, vamos a explorar algunas de estas soluciones ya están disponibles para que las uses. 51. Jira: Jira es posiblemente la herramienta más popular para hacer scrum en línea. Así que sigamos adelante y creamos un proyecto aquí. llamaremos tienda de comercio electrónico. Y cambiaremos nuestra plantilla aquí para fregar. Perfecto. Sí, se ve bien. Vamos a seguir adelante y crear eso. Voy a saltarme tener alguna herramienta por ahora. Bien, genial. Así que tenemos nuestro atraso aquí. Entonces bajo esto aquí tenemos nuestra hoja de ruta. Aquí, tenemos un backlog para que podamos comenzar a agregar problemas al backlog si queremos. O podríamos empezar a agregar cosas también. Entonces aquí esta página del producto es como una epopeya. Y voy a decir como visitante, quiero ver el título del producto. Como visitante, quiero ver una foto del producto. Como visita. Quiero leer las reseñas de productos. Entonces podríamos agregar otra época aquí. Entonces podríamos decir Portal de Gestión. Y luego como gerente, quiero ver la lista de pedidos. Y como gerente, quiero despachar y ordenar. Esta pestaña de hoja de ruta permite ups. En cambio, he creado esas epopeyas. Y ayudaría si pudiera deletrear. Vamos despacho y pedido. Genial. Entonces eso probablemente no nos va a permitir eliminar estos, pero intentemos. Ahí vamos. Entonces podemos entrar en cada uno de estos y podemos agregar una descripción. Y luego podemos agregar algunos puntos de la historia aquí. Entonces tal vez muchos. Digamos que son tres. Y éste es cinco. Este va a ser un dos. Y éste va a ser un cinco también. Genial, Así que ahí tenemos algunos puntos valores. Y si tenemos un retraso, podemos empezar a organizarlos en sprints. Entonces aquí tenemos nuestro primer sprint. Y podemos arrastrar algunos de estos boletos n. Así que tenemos nuestra página de productos boletos n, los hemos dejado en el backlog. Y si golpeamos Start Sprint que esto, ahora estamos en la pestaña del tablero. Y aquí tenemos nuestro tablero. Entonces podríamos agregar algunas columnas aquí si queremos. Podríamos llamar a esta revisión de código. Voy a poner eso ahí. Y agregaremos uno para probar también. Pega eso ahí dentro. Entonces si quiero comenzar con un boleto, me lo puedo asignar a mí mismo. Puedo enviarlo en progreso. Y aquí tenemos nuestro tablero todo ya que actualizamos todos estos boletos, lo actualizarás para todos. Y obviamente a medida que invitamos a los miembros de nuestro equipo, entonces podrán ver los boletos moviéndose a través la pizarra a medida que los movemos también. 52. Gráfico de quemado: Entonces, una métrica clave que quieres ver en tu sprint es el Burndown Chart. Entonces, si hacemos clic en este botón Insights aquí, podemos ver que tenemos este progreso de sprint que nos dice qué porcentaje se hace está en progreso o no iniciado. Y también tenemos este Gráfico de Burndown de Sprint aquí. Entonces lo definí como un sprint de dos semanas. Y podemos ver en teoría, deberíamos estar completando este número de puntos. Entonces, a mitad de camino, deberíamos estar como a mitad de camino por los puntos. Entonces a medida que nosotros, a medida que movemos estos boletos, solo actualicemos que ahora podemos decir 100% en progreso, pero aún no se ha hecho nada. Pero entonces si tomo uno de estos boletos y lo muevo a Hecho. Y otra vez, vamos a refrescar. Ahora estamos en, ahora estamos en 56 por ciento terminado, 44% incompleto. Y podemos ver que nuestro gráfico de burndown se ve muy bien porque queremos esta línea azul, que es el trabajo realizado para bajar a cero antes de aquí. Y entonces tendríamos que estar pegando esta línea para lograrlo. Si es aquí arriba, entonces no estamos superando el trabajo tan rápido como pensábamos que lo haríamos. Si es aquí abajo, entonces estamos superando el trabajo más rápido de lo que pensábamos que lo haríamos. 53. Trello: Trello es una herramienta realmente simple para crear tableros y listas de tareas pendientes. Así que aquí tengo un tablero completamente nuevo y podemos agregar cualquier columna que queramos a esto y tal vez agreguemos un en progreso. Si puedo deletrear. Y luego una revisión de código, pruebas y hecho. Y entonces puedo empezar a agregar cosas aquí. Entonces quiero ver el nombre del producto. Como visitante, quiero ver una foto del producto. Diga visitante. Quiero leer las reseñas de productos. Y luego estos, podemos pinchar en ellos. Puedo asignármelos, e.g. I. Puedo agregar una descripción, así que guárdala. Y luego mis pequeñas fotos porque las firmé, puedo moverlas en progreso. Ahora bien, lo que Trello no hará porque es súper sencillo empezar con Trello . Eso es. Ahora estamos en un rollo. No nos va a dar todos los informes que algunas de las herramientas más avanzadas harán. Pero es genial para proyectos pequeños, proyectos simples o proyectos que solo quieres seguir adelante, ponerte en marcha y no quieres pasar demasiado tiempo metiendo porque puedes crear fácilmente estos pequeños tableros, compartirlos con tu equipo y hacer que todos trabajen muy rápido. 54. Mural: Aquí hay otra herramienta llamada Miro, y esta tiene un montón de plantillas. Entonces, cuando lo cargues por primera vez y nosotros solo tendremos, puedes usar estos bonos amigo colgando. Pero si vas a Agile, tiene un montón de cosas geniales. Entonces, por ejemplo tiene una plantilla retrospectiva, Start, Stop, Continue retrospectiva. Montón de las cosas de las que hemos hablado. O podemos bajar a la hoja de trabajo de cinco porqués, muy buena para buques de guerra, retrospectiva de equipo, squirm diario. Y elaborará una vista de tablero. Y luego otra vez, probables orbitales. Puedes compartirlo con todos los miembros de tu equipo y luego simplemente comenzar, comenzar a usarlo. 55. Construcción de seguridad psicológica: La seguridad psicológica se trata de si los miembros del equipo sienten que tienen la confianza hacia la seguridad, para expresar sus pensamientos e ideas. Y realmente es responsabilidad de un equipo construir esto. Porque desafortunadamente, muchos de nosotros hemos tenido la experiencia donde no queremos hablar. No queremos compartir ideas porque estamos preocupados. Nos van a juzgar, nos han gritado, nos van a despedir, sea lo que sea. Esos no son entornos psicológicamente seguros. Y en Scrum, reconocemos que cada miembro del equipo tiene algo realmente valioso para presentarlos, para comentarlos. Entonces, si podemos construir seguridad psicológica para que los miembros más tímidos o del equipo, o de hecho cualquier miembro del equipo puedan ser realmente honestos sobre sus sentimientos u opiniones, entonces eso es realmente beneficioso. Entonces, ¿cómo construimos la seguridad psicológica? Bueno, establecerlo verbalmente y en formas de trabajar es realmente buena manera de solo señalar que la opinión de todos es válida. Así que teniendo eso escrito y teniendo todo eso de acuerdo como equipo en que realmente queremos esa entrada y que no vamos a ser críticos. Vamos a escuchar y respetar la opinión de todos, va un largo camino para construir esa seguridad. Las buenas reglas para tener podrían incluir, está bien cometer errores. Si tenemos una cultura de juicio y culpa entonces la gente no va a admitir sus errores y por lo tanto no vamos a aprender nada. Mientras que si establecemos una cultura donde no culparemos a la gente por errores, solo miramos lo que salió mal y cómo podríamos asegurarnos de que no vuelva a suceder, entonces es más probable que la gente sea honesta. Y por lo tanto, podemos solucionar estos problemas. Tener el aporte de todos es valioso, es solo tenerlo como regla de decir, mucha gente podría sentir que su opinión no es importante. Y así, si el equipo está de acuerdo que la opinión de todos es importante, eso realmente puede reforzar a algunas personas a ser más abiertas. Tener una cultura de respeto, respetar la idea de los tampones y no tener interrupciones. Probablemente todos hemos estado en esas reuniones donde una persona simplemente sigue interrumpiendo y es realmente molesto, es grosero y es irrespetuoso. Y la persona que se interrumpa eventualmente simplemente se dará por vencida y no compartirá sus ideas. Entonces, si establecemos esta idea de que cuando alguien está hablando, no lo interrumpimos, que deberían ser modales básicos, pero muchas veces necesitamos un poco de recordatorio. Entonces esa puede ser una herramienta realmente útil para una de las formas en que podemos construir esto es asegurarnos que haya retrospectivas regulares para garantizar que las personas tengan su opinión y la gente pueda hablar sobre cómo piensan que va y qué tan seguros se sienten en el equipo. Y puede ser muy bueno sacarlos del sitio. Entonces, si tienes una oficina aquí, a lo mejor tienes una cafetería aquí. Puede ser muy bueno ir a esa cafetería o ir a otro lugar. Simplemente llévala de la oficina de la gente se siente como en la oficina que es claramente como el dominio de los gerentes. Y puede que nos sintamos un poco más nerviosos de que lo lleves a un ambiente más relajado como una cafetería realmente puede ayudar a la gente a abrirse también. 56. Reuniones de lavado: Las reuniones de adoración ocurren después de que se completa un proyecto, pero también probablemente más importante después de que algo sale mal. Este es un momento en el que a la gente le preocupa la culpa. Entonces el objetivo de la reunión es realmente resolver qué pasó y qué podemos hacer mejor la próxima vez. Tan importante recalcar que no es una investigación como en tratar de encontrar a algunas personas a las que culpar y castigarlas por ello, sino solo entender lo que ha pasado y dónde podemos arreglarlo. Para que la próxima vez podamos hacerlo mejor. Ahora muy buena herramienta en las reuniones de culto es usar lo que se llama los Cinco Porqués. Entonces solo preguntamos por qué cinco veces. Y cuanto más hacemos eso, más llegamos a la causa raíz del problema. Entonces digamos algo así como que hemos tenido una falla en el servidor y los equipos se juntaron para una reunión de lavado. Y podríamos decir, ¿por qué falló el servidor? ¿Cuándo, por qué? Bueno, se quedó sin espacio en disco. Bien. ¿Por qué se quedó sin espacio en disco? Bueno, los pulmones lo llenaron y había tantos registros que llenó todo el disco duro. Entonces, ¿por qué el servidor se llenó de registros? Bueno, no había configuración de monitor en el servidor para alertarnos cuando el disco duro llegó al 80 por ciento lleno. ¿Por qué no había configuración de monitor? Bueno, no estaba en nuestra definición de hecho cuando estábamos creando el servidor, así que olvidamos hacerlo. ¿Por qué no estaba en nuestra definición de hecho? Bueno, nunca tuvimos una reunión de formas de trabajar para que el equipo lo resolviera. Para que podamos ver cuando hacemos todas estas preguntas por qué y seguimos cavando, seguimos cavando un problema que podría parecer que al principio fue la caída de un individuo. Fue alguien que dejó fallar al servidor. En realidad, en la causa raíz de ello. Es un problema de equipo y algo que podemos hacer mejor la próxima vez. Podemos tener las formas de trabajar. Podemos mejorar nuestra definición de hecho. Podemos volver atrás y mirarlo, mejorar el monitoreo. Todas estas cosas surgieron porque seguimos preguntando por qué llegar a la raíz del problema en lugar de pensar en culpar. El punto clave de la reunión de adoración es realmente platicar. Hablamos de seguridad psicológica, construir ese ambiente. Bueno, no estamos culpando, solo estamos viendo lo que salió mal para que sepamos lo que podemos cambiar en el futuro. 57. Venta ágil para la gestión: Ágil puede sonar genial, demasiados de nosotros, pero gerencia y no siempre a bordo con ella. Entonces, ¿cómo los convencemos que es una mejor manera de hacer las cosas? Bueno, primero, debemos considerar qué preocupa, qué preocupaciones podría tener la administración. Uno, es un cambio. El cambio puede dar miedo. Es una manera diferente a la forma en que han hecho las cosas antes. Y así, si una empresa ha tenido éxito o al menos ha estado afrontando hasta ahora, entonces cambia. Siempre hay un elemento de riesgo ahí dentro. Puede parecer que lleva años hacer algo más que el tipo de antiguo método de cascada, que es eficiente si funciona perfectamente. Nefrón sí funciona perfectamente, por supuesto, pero hipotéticamente podría, mientras que estamos vendiendo gestión e ideas. Bien, bueno, vamos a construir una página de producto en blanco. Entonces le vamos a poner un título. Entonces vamos a ponerle una imagen y vamos a estar lanzando y exhibiendo y revisando todas estas cosas en este paso, puede sonar como que va a llevar años. Y también empodera a los equipos en lugar de a los directivos. Y eso da miedo si eres gerente y estás acostumbrado a microgestionar y tener el control de todo. Y entonces alguien viene y dijo, tenemos esta metodología de scrum y es muy bueno empoderar al equipo para que haga el trabajo, entonces pueden estar nerviosos por eso porque les gusta ser controlados. Entonces, ¿cómo abordamos estos miedos, estas preocupaciones? número uno es un documento de fallas costosas y procesos de aprobación lentos. Entonces si hay que decir, digamos que el big bang se libera y va a lo largo y se tarda horas en retroceder. Y hay todo tipo de quejas, entonces eso es una gran cosa para documentar. O si este proceso de aprobación lento donde te gusta despliega una función y lleva dos semanas. Y los términos del producto es preguntar, ¿ dónde está, dónde está? Y estás diciendo, bueno, saldrá el próximo lanzamiento, pero hacemos lanzamientos en toda la compañía así que no podemos hacer nada que presentes va a ser para comer tarde. Y luego faltamos un documento de fecha límite, todo eso. Porque si puedes ir a la gerencia y decir, mira, aquí fue un fracaso masivo porque hicimos los lanzamientos del big bang. Aquí nos faltó un plazo importante para conseguir que algo cambiara porque tuvimos que esperar hasta el próximo lanzamiento. Esa es una buena evidencia de que el proceso que está en marcha actualmente no está funcionando. Número para enfocarse en los beneficios de una entrega más rápida, a los gerentes generalmente les gusta sacar las cosas lo antes posible. Y así si les podemos decir, mira, esta característica que pediste, tardó ocho semanas en hacerlo. Después hubo otras dos semanas esperando un alivio. Y en realidad pensamos que podemos sacar una versión básica de esta mitad de ese tiempo, incluyendo el lanzamiento. Ni siquiera tendremos que esperar hasta el próximo lanzamiento. Ese va a ser un gran punto de venta. Y de lo que hablamos antes también traemos en esta idea de seguridad. Esta idea si estamos haciendo pequeños lanzamientos, más fáciles de retroceder, vamos a tener menos de estas fallas catastróficas. El número tres es hablar de equipos más felices. Generalmente los equipos prefieren trabajar de manera ágil en lugar de la manera de la cascada. A modo de cascada, el equipo no tiene realmente el control. Funciona en una parte del sistema. No se hace responsable de ello. No lo ve a través, no empodera al equipo. Despilfarra todo lo contrario de eso. Permite completamente al equipo asumir la responsabilidad de lo que están construyendo y cómo lo van a entregar. Y a la gente le encanta que a los equipos les encantó eso, a ellos les encanta eso. La empresa les está confiando esa responsabilidad. Y luego son capaces de hacer ese trabajo y lo pueden hacer bien. Y eso significa equipos más felices. Y desde una perspectiva de gestión, eso significa una reducción del volumen de negocios. La gente no se va a ir porque va a disfrutar más de su trabajo y así van a quedarse con la compañía. El número cuatro es reconocer que el cambio da miedo. Podrían estar preocupados por todas estas cosas y podemos decir, bueno, sí, esas son preocupaciones. Estamos bastante seguros cuando 99% seguro de que squirm es mejor que cascada porque todos van en estos días. Pero, ¿por qué no lo hacemos como juicio? Y un juicio es una excelente manera de obtener objeciones redondas porque si dices, Bien, probemos esto por tres meses o seis meses y veamos cómo funciona. Y si todo explota, volveremos a la cascada. Pero si funciona y podemos expandirlo y extenderlo en todos los equipos, entonces es mucho más probable que obtengas buy-in porque eso lo probará. Y es menos arriesgado porque es sólo una cosa temporal. Pero claro entonces lo intentaremos. Que trabajan muy bien. ellos les va a encantar y podremos implementarlo en toda la organización. 58. Coaching de buenas prácticas: Mencionamos esta idea de que a veces necesitamos entrenar las mejores prácticas y alentar a tu equipo a usar realmente todo el framework que está disponible en matorrales. Entonces, ¿cómo hacemos eso? ¿Cómo entrenamos de manera efectiva? Bueno, el número uno es comenzar donde está ahora el equipo y ver qué funciona para ellos. Entonces, a veces hay una tendencia a entrar y solo tratar de comenzar a hacer cambios. Pero si hacemos eso, el equipo probablemente va a ser bastante opositor. Y están contentos con la forma en que están las cosas. Si entramos, mira lo que funciona, mira lo que no funciona. Y podemos observar, podemos hacer preguntas y luego podemos ver lo que no está funcionando del todo para ellos. Y en ese punto, entonces podemos empezar a sugerir un cambio y decir, me di cuenta de que esto no está funcionando para ti. ¿Qué tal si lo intentamos de esta manera, tal vez eso ayudaría a resolver el problema? Hacer sugerencias, no comandos. gente generalmente no le gusta que le digan qué hacer. Entonces como acabamos de discutir, si podemos hacer sugerencias y ofrecérselas al equipo, ellos pueden optar por abrazarla. Pueden optar por no abrazarlo. Si se sienten en control de los cambios, van a estar mucho más a bordo en hacerlos que si intentamos imponerles algo. Usa cómo o qué preguntas en lugar de por qué le preguntamos a alguien, ¿por qué lo haces de esa manera? Suena bastante acusatorio. Y eso pone a la gente a la defensiva. Si usamos cómo o qué preguntas como, bien, bueno, ¿cómo haces eso y cómo es eso? ¿Cómo te va bien eso? Entonces consigues que la gente esté un poco más examinando la situación en lugar de estar a la defensiva ya que pueden ser con preguntas por qué. Recuerda que arrodillarse ArcGIS no es una religión. Entonces, enfoca lo que funciona, llévale lo que funciona, y no tienes que usar lo que no. Si algo no te está funcionando del todo dentro del framework de Scrum, no uses ese bit, usaste los bits que te funcionan en tu organización, en tu equipo, sea lo que sea, toma las cosas buenas y no seas demasiado dogmático sobre las reglas. Ser un modelo a seguir. Lo más importante que podemos hacer es seguir las mejores prácticas nosotros mismos. Si no lo estamos siguiendo, entonces no podemos esperar que otras personas lo sigan. Entonces, si hay áreas en las que pensamos que tal vez no estamos del todo en línea con la forma en que vemos las mejores prácticas, entonces nos empuja hacia ese curso para que estemos modelando a roles cómo es la buena práctica. Y también cuando la gente lo ve funcionando para nosotros, entonces no creo que esté funcionando para Chris, tal vez yo también lo adopte. Vea el panorama más amplio que los equipos están dentro de las organizaciones. Entonces a veces el equipo va a estar haciendo algo de cierta manera y hay una mejor manera de hacerlo. Pero a veces esa es la mejor manera de hacerlo dentro la estructura organizacional en la que están contenidos. Por lo tanto, es importante considerar cómo los valores más amplios de la organización podrían afectar al equipo y llevarlos a hacer las cosas de cierta manera. Y luego intentar los cambios como experimento. Así que el cambio puede dar miedo, pero si lo vendemos como un experimento, ¿por qué no probamos esto para los próximos dos sprints y vemos cómo funciona? mucho más probable que las personas participen en eso porque no creen que se están comprometiendo con un cambio permanente de dígitos. Bien, vamos a probarlo para Sprint. Dos sprints son un par de meses, sea lo que sea, si estás tratando de nadar en general, probablemente quieras comprometerte con una escala de tiempo mayor, tal vez de tres a seis meses, al menos, algo así. Pero si lo expresas como un experimento, probemos esto y podemos volver a la vieja manera. Si no está funcionando, gente va a estar mucho más relajada acerca de probar cosas que si dices, cierto, tenemos que cambiarnos ahora. Eso suena muy permanente y muy aterrador cuando decimos, probémoslo como experimento y veamos si funciona o no funciona. mucho más probable que las personas se involucren. 59. Cómo escalar Scrum: Scrum está diseñado para un equipo de alrededor de diez personas más que esto en el equipo y comienza a volverse inmanejable. No se puede hacer todo en un scrum diario. Y el significado, las actualizaciones son menos significativas porque la gente de aquí y la gente de aquí, probablemente voy a trabajar en cosas diferentes. Y así las actualizaciones realmente no funcionan y no es tanto un entorno de equipo. Pero, ¿qué pasa si tienes un proyecto que necesita más de unas diez personas trabajando en él como solemos hacer en los negocios? Bueno, en ese caso necesitas múltiples equipos de Scrum. Pero las áreas de preocupación, qué pasa si el equipo de scrum comienza a pisarse los dedos de los pies y a meterse en el camino del otro. ¿Cómo escalamos de un solo equipo de Scrum a varios equipos de Scrum? Bueno, eso es lo que vamos a ver en este módulo. 60. Scrum de Scrums: Si tenemos múltiples equipos de Scrum y necesitan poder comunicarse para evitar que se pisen los dedos de los pies unos a otros. Entonces, ¿cómo hacemos que esto suceda? Bueno, una solución es Scrum of Scrums. Entonces esto es esencialmente un scrum diario. Entonces lo mismo que el diario Scrum. Pero cada equipo de Scrum envía uno delicado y esa forma es un poco mayor Scrum de Scrums. Por lo que podría hacerse a diario, también se podría hacer semanalmente si eso funciona en su organización o cualquier frecuencia que funcione para usted. Pero es el mismo formato que un scrum diario. Cada natación está representada por una persona, y esa podría ser cualquiera. Entonces podría ser el Scrum Master, si eso tiene sentido, podría ser, digamos, un ingeniero principal, pero realmente podría ser cualquiera. Podrías rotar alrededor del equipo para que todos tengan un turno yendo al Scrum de Scrums y viendo cómo funciona. Cuando estás en el Scrum de Scrum en sí, funciona como los scrums diarios. Entonces pregunta a hacer es, ¿qué hemos hecho? ¿Especialmente cosas que podrían estar impactando a otros equipos? Qué estamos haciendo ahora mismo que pueda afectar a más Equipos y con qué bloqueadores podrían ayudarnos otros equipos. Entonces de la misma manera que cuando estamos haciendo nuestro scrum diario, hablábamos de lo que hicimos individualmente anteriormente, haciendo ahora mismo y qué bloqueadores tenemos, estamos llegando al Scrum of Scrums y diciendo para nuestro equipo, esto es lo que hemos hecho, esto es en lo que estamos trabajando. Estos son bloqueadores con los que necesitamos ayuda. Cada equipo se alimenta para que los equipos sepan en qué estamos trabajando cada uno de nosotros. Y luego el delegado regresa a su equipo individual de Scrum y retroalimenta e información irrelevante al resto de ese equipo. 61. Divida de productos: Un concepto clave en Scrum es que un producto tiene un propietario de producto. No puedes tener un solo producto. Tenemos múltiples propietarios de productos. ¿Qué pasa si tienes que Scrum? Los equipos necesitan trabajar en el mismo proyecto. Parece que tendrás dos propietarios de productos diferentes que quieren en cada equipo trabajando en el mismo producto. ¿Cómo lidias con eso? Bueno, en ese caso, necesitamos dividir los productos de alguna manera en secciones separadas. Entonces, volvamos a traer nuestro sitio de comercio electrónico , como ejemplo. Es una gran pelea y queremos que diferentes equipos de scrum trabajen en ella. Pero no podemos tener dos propietarios de productos que sean dueños del sitio de comercio electrónico. Lo que podríamos hacer, por ejemplo, es dividirlo en front-end y back-end. Entonces, por dominio front-end, las cosas que el cliente verá si viene al sitio a navegar. Y entonces el sistema back-end son las cosas que el personal del almacén y el equipo de ventas trabaja para el sitio de comercio electrónico utilizan para administrar y despachar todos los pedidos. Al separarlos, entonces puedes tener un equipo de Scrum asumiendo la responsabilidad de cada uno. Para que puedas tener equipo de Scrum trabajando en el lado orientado al cliente. equipo de Scrum estará trabajando en el back-end del producto y tendrás un propietario del producto para cada uno administrarlos. Ahora, otra solución que podría hacer es tener un propietario de producto trabajando en múltiples equipos de Scrum. Entonces el equipo a está trabajando en el front-end, equipo B está trabajando en el back-end. Y hay un propietario de producto que administra y trabaja en ambos equipos, lo convierte en un propietario de producto bastante ocupado. Pero dependiendo de la cantidad de decisiones y de la autonomía que tenga su equipo, eso puede funcionar bastante bien también. 62. Alineación de Sprint: Si tienes varios equipos de Scrum, entonces es posible que quieras empezar a pensar en la alineación de sprint. Entonces, ¿si tienes el equipo a y el equipo B o sus sprints van a comenzar al mismo tiempo? ¿Van a ser diferentes? El tiempo que los hagan funcionar al mismo tiempo funciona bastante bien porque si tienes algunos bloqueadores como TMA está bloqueado por algo en lo que está trabajando el Equipo B. El equipo comenzó a trabajar en esto y decir sprint free y equipo una nariz que van a poder recogerlo en sprint cuatro, shimming, ya se terminó. Y así todo está alineado. Puede alinear sus hojas de ruta de productos. Entonces se puede decir, bueno más o menos, vamos a tener trabajo de TMA en este equipo, estar trabajando en esto. Y luego en dos semanas tiempo cuando el sprint y lo cambiaremos para arriba. Así que tenerlos alineados puede ser realmente útil. Para algunas organizaciones, funciona mejor no tenerlas alineadas solo por razones logísticas. Tan seguro, solo tienes una sala de reuniones. Entonces si tienes todos tus equipos de scrum comenzando aspirina y terminando, se gastan en el mismo día. Ambos van a querer la sala de reuniones para Sprint Planning y para retrospectivas el mismo día. Entonces en esos casos, es posible que realmente quieras tambalearte de tener al equipo sprint una estrella aquí y hacer un sprint de dos semanas y el equipo B de sprint comience aquí como una semana después. Entonces el offset, para que no se encuentren con estos encuentros con conflictos. En cuanto a la alineación en la alineación de los diferentes equipos gastados. Aquí es donde variar la longitud del sprint puede ser realmente útil. Entonces digamos que tenías TMA y luego acabas comprar equipo estar en una semana después. Pero en realidad quieres alinear sus sprints y podrías tener equipo a hacer un sprint de tres semanas, por lo que ambos terminan al mismo tiempo. O podrías tener TB bajando a un Sprint de una semana. Y luego después de eso vuelven a si estás usando sprints de dos semanas por defecto, vuelven a los dos gastos y luego se alinean. Entonces solo puedes hacerlo de la manera que quieras, pero solo tener un poco antes sobre si los quieres alineados o no y cómo los vas a alinear usando longitudes de sprint puede ser realmente útil. 63. Otras metodologías: Este curso se ha centrado en Scrum, pero hay otras metodologías ágiles que quizás quieras usar de vez en cuando y sobre frameworks que quizás quieras traer junto a SCRUM que realmente complementa crecido. Entonces en este módulo los vamos a discutir sobre metodologías y frameworks ágiles que sería realmente útil conozcas al trabajar dentro de Scrum. 64. Kanban: Scrum y Kanban son probablemente los frameworks Agile más populares para administrar proyectos. Entonces, cuando usarías squirm y cuándo usarías Agile era realmente adecuado para entregar nuevos proyectos en los que estás construyendo algo, algo de Greenfield, tienes un trabajo que hacer. Sabes, tienes, digamos, seis meses para hacerlo en. Y solo necesitas atravesar todas las cosas. Kanban tiende a ser más adecuado o tipo de negocio como ambiente habitual. Entonces tal vez ya hayas construido tu plataforma de comercio electrónico. Es en vivo y solo necesitas ver qué surge. Pequeñas mejoras, pequeñas correcciones. No tienes el tipo de hoja de ruta de producto grande que has crecido. Pero sí necesitas responder a las cosas mucho más rápido porque estás lidiando con problemas en vivo en el sitio web. Entonces kanban funciona un poco diferente en que no hay scrum sprint. Tenemos esta idea de sprints y tenemos, digamos, un bloque de dos semanas. Decidimos qué vamos a hacer y empezamos con dos semanas y lo hacemos por dos semanas y revisaremos lo que vamos a hacer. En Kanban. Hay placa continua y la acumulación de productos. Y el tipo de lo que pensamos del Backlog de Sprint, la lista de tareas pendientes, de todos modos. Entonces el backlog del producto es todo, todo en la columna de tareas pendientes en el tablero ya y en orden de prioridad para que recojas el de arriba. Entonces digamos, volvamos a tomar nuestra plataforma de comercio electrónico. Lo tenemos en vivo. Y nos hemos dado cuenta de que el símbolo de la moneda no se muestra del todo bien, ¿ verdad? Para algunos usuarios. Y ese es un problema realmente grande porque se trata de pagos. Entonces el propietario del producto levantaría un boleto para decir, el símbolo de moneda no se muestra correctamente, probablemente lo enviaría directamente a la parte superior del backlog. Entonces el próximo ingeniero en recoger algo, vamos a poder recogerlo. Entonces, en lugar de tener estos sprints, todo está solo en una lista. Recoges lo de arriba y si algo necesita hacer urgentemente, solo lo traes y lo pones directo a la cima del backlog para que puedas empezar a trabajar en ello. Ahora bien, esto significa que en Scrum, medimos la velocidad. Cuanto más bien lo estemos haciendo es cuantos más puntos podamos conseguir comida por sprint, mejor lo estamos haciendo. En Kanban, hablamos de tiempo de ciclo. Entonces, desde el punto en que se levanta el boleto, qué tan rápido podemos obtenerlo en todos los ámbitos y salir liberado y hecho. Entonces, como un resumen rápido, Scrum es genial para cuando tienes piezas de trabajo fijas y estás feliz de trabajar en esos sprint de dos semanas una vez que tienes algo por ahí y solo necesitas hacer pequeños retoques. Y estás menos preocupado por hacer un gran trabajo. Solo necesitas obtener esas correcciones rápidamente. Kanban puede ser más útil. Ahí. 65. Programación extrema: La programación extrema es un enfoque ágil para escribir código. Como Agile en sí mismo no es un conjunto claro de reglas, pero alguna vez hay un montón de principios y un montón de técnicas que se forman juntos para formar lo que llamaríamos programación extrema. A menudo involucra a varias personas que trabajan en la misma pieza de código. Entonces esto podría ser código escrito en parejas, Programación por pares, donde una persona es el piloto en realidad escribiendo las cosas, pero están colaborando con alguien sentado a su lado hablando a través las decisiones que tanto capaces de las decisiones que tanto capaces de detectar lo que está funcionando como cómo diseñarlo. Incluso puedes escalar hasta la programación de la mafia. Así que tener cuatro o cinco personas están mirando una pieza de código, ya sea en sus propias computadoras, colaborando en tiempo real o todo sentado alrededor de la computadora herida, si eso funciona para usted. Asegura un código de muy alta calidad de esa manera. Pero claro que lleva más tiempo. Si estás en parejas, entonces solo la mitad de tus ingenieros están escribiendo código y programación mob aún más. Entonces. El código debe ser ampliamente revisado y aprobado por otra persona. Entonces esto debería ser a través de todo lo que escribas. Si escribes una pieza de código, envía una solicitud de extracción o una revisión de código a otra persona. Y alguien más debería mirar a través de ese código, asegurarse de que tenga algún sentido. Dar comentarios y pasárselo a la persona. Si un pasaje de inmediato o si hay algún cambio necesario o sugerido, devuélvelo al autor para ver si quiere hacer esos cambios. Las tareas automatizadas deben escribirse para todo. Entonces, avanzar hacia esta idea de integración continua y entrega continua debe ser una prueba automatizada para cada pieza de funcionalidad que escribimos, porque es imposible que los probadores humanos la recojan todo, manteniéndolo lo más simple posible. Entonces realmente, siempre queremos escribir menor código posible y hacerlo reutilizable. Y si podemos escribir una pieza de código que podamos usar en tres lugares diferentes y eliminar el viejo código voluminoso, entonces eso es genial porque menos líneas de código significa menos lugares donde las cosas pueden salir mal. Después el desarrollo impulsado por pruebas, que vamos a hablar en la siguiente lección. 66. Desarrollo impulsado por pruebas (TDD): desarrollo impulsado por pruebas, también conocido como TDD para abreviar, es una forma de escribir código donde escribimos la prueba unitaria antes de escribir el código real en sí. ¿Por qué hacemos esto? Bueno, nos impide agregar código que no necesitamos. Entonces hablamos antes de esta idea de escribir una historia de usuario y decir, como usuario quiero hacer esto. Y luego podemos escribir el código sabiendo que en cuanto cumplamos con los criterios de aceptación, entonces hemos cumplido con el trabajo. Bueno, esto es básicamente lo mismo en que escribimos primero la prueba para decir lo que este código necesita para poder hacer. Y luego escribimos el código para cumplir con ese texto. Así que en cuanto esté pasando la prueba unitaria, ya podemos empezar a escribir código. No necesitamos agregar ninguna otra hinchazón porque tenemos esa prueba unitaria de paso y por lo tanto hace todo lo que necesitamos que haga. Entonces, escribir primero la prueba y luego el código funcional después nos ayuda a garantizar que todo tenga cobertura de prueba en ella. Y dos, no estamos agregando ninguna hinchazón al código porque podemos detenernos tan pronto como la prueba sea exitosa. 67. Desarrollo basado en el comportamiento: El desarrollo impulsado por el comportamiento es una extensión del desarrollo impulsado por pruebas, donde escribimos nuestras pruebas en historias de usuario y luego escribimos el código para cumplir esas historias de usuario. Entonces, ¿qué significa eso realmente? Bueno, digamos que estamos codificando el sistema de pago para nuestra plataforma de comercio electrónico. Podríamos escribir una historia como, como cliente, quiero poder ver el total de mi canasta. O como cliente, quiero poder realizar el pago de mi pedido. Y ese sería el idioma en el que escribimos la prueba. Esa sería nuestra prueba, digamos, y es muy comprensible. Cualquiera puede venir a ver eso, el dueño del producto podría escribir por sí mismo. Cualquiera que esté mirando la prueba, incluso una persona no técnica, entiende lo que está pasando ahí. Entonces tenemos una capa de código en el medio, lo que traduce eso en una prueba real sobre decir, quiero hacer el pago en mi pedido. ¿Cuáles son los pasos automatizados para probarlo realmente? Así que teniendo el Lenguaje Natural traducido en una prueba. Y entonces por supuesto tenemos nuestro código funcional, la propia plataforma de comercio electrónico real. Y entonces hay un poco de 33 piezas ahí dentro. ¿Cuál es, cuál es el beneficio de hacer esto? Cuando escribimos el código en lenguaje natural. Todos pueden entenderlo, el propietario del producto, cosas no técnicas y entrar y ver exactamente lo que estamos probando. Segundo, realmente se enfoca en cumplir con esos requisitos del usuario. Para que podamos escribir primero nuestra prueba. Necesito que el usuario pueda completar este pago. Después escribimos nuestra prueba y nuestro código funcional para cumplir con eso. Y en cuanto cumplimos con eso, podemos parar. No estamos agregando ningún exceso de hinchazón porque sabemos que esa historia de usuario está definida y ya tenemos cobertura completa de prueba en ella. Entonces sabemos que podemos ejecutarlo a través un pipeline de integración continua y todo va a funcionar muy bien porque las coberturas de prueba ahí, no hay nada extra que necesitamos y todos pueden entender lo que está pasando. Ahora, hay una serie de marcos populares de desarrollo BDD impulsados por el comportamiento por ahí. Tenemos pepino en Ruby, tenemos b hat en PHP, tenemos J se comporta en Java, pero sea cual sea el lenguaje en el que estés trabajando, probablemente haya un framework BDD por ahí. Así que recomendaría subir, echar un vistazo alrededor y ver qué hay ahí y probarlo y ver cómo te va con él.