Clase 18 de 30 • Introducción a las Metodologías Ágiles 2017
Contenido del curso
Rafael Romario Roncancio Vinchery
Yesica Lizeth Cortés Pineda
Julio J Yépez
Rafael Reyna Lagunas
Yesica Lizeth Cortés Pineda
Fernando Macías
Yesica Lizeth Cortés Pineda
Yesica Lizeth Cortés Pineda
Juan Carlos Quishpe
Yeison Daza
Juan Carlos Quishpe
Jasan Azael Hernández Bautista
Juan Esquivel Méndez
Yesica Lizeth Cortés Pineda
Simón Ottoniel González Acosta
Nextop Nextop
David Toca
Yesica Lizeth Cortés Pineda
Edwar Enrique Vilchez Serrano
Christian Castillo
Yesica Lizeth Cortés Pineda
José Ignacio Miranda
Ricardo Mesa Gallego
Yesica Lizeth Cortés Pineda
Alexis Antonio Moraga Gallardo
Alexis Antonio Moraga Gallardo
Luis Loigiluis
Sí quieres llegar que tu Team diga:
“El líder es bueno, el líder es bello, no hay voluntad olvidate de ello”
Ref: Los Simpson Temporada 9°, Episodio 13
Yo creo que el liderazgo va de la mano con el conocimiento del Equipo de trabajo, sí eres el “jefe líder” con el síndrome del “YoYo” (Yo hago, Yo soy) difícilmente podrás llegar a que las otras personas te sigan porque no existe la motivación si solo “YoYo” es que se lleva los méritos del trabajo.
Hacer una relación un poco mas personal como generar afecto es algo que ayuda bastante para que las personas sigan a su líder ciegamente.
Sipi, de hecho el trabajo de líder es de los que más trabajo cuesta, porque no solo debes ser tan bueno técnicamente que pueda dar apoyo en todos los aspectos relacionados con el proyecto, sino que debe saber identificar las diferentes personalidades de cada uno de las personas del equipo y buscar la forma, de acuerdo a esas personalidades, de aprovechar al máximo las capacidades del equipo.
Estoy completamente de acuerdo contigo, un líder que solo habla de lo que ÉL hace no de lo que EL EQUIPO hace no es un buen líder, le falta trabajar en su ego.
No estoy de acuerdo con ir “actualizando” las versiones de los frameworks usados en el proyecto en cada nuevo release, ya que implicaría estar revisando todo el código, incluso el que ya está aprobado, para hacer cambios.
Creo que una vez que se definió el framework, el lenguaje de programación, la plataforma, etc. la infraestructura tecnológica … debería conservarse y sacarle el máximo provecho en la versión escogida, y sólo al finalizar el proyecto, pensar en la actualización mayor que implique cambiar la versión del framework, entre otras.
Totalmente de acuerdo, quizás actualizaciones menores que sean de corrección de bugs o mejoras del performance, pero definitivamente actualizaciones mayores de los frameworks cada release no.
Con SCRUM se hacen reuniones al final de los sprints y al final en la entrega del proyecto en las que se determina qué cosas se hicieron bien y qué cosas se hicieron mal, probablemente durante la ejecución se debe evaluar si los cambios que se hagan en el framework o en las tecnologías usadas van a afectar positivamente o negativamente al proyecto.
Conozco una empresa que empezó trabajando con una plataforma de pagos en línea que apenas estaba dando sus primeros pasos en producción, pero claro cuando estaban ofreciendo el producto esto no lo mencionan, durante la ejecución del proyecto esa plataforma estaba causando demoras y tiempos muertos para personas del equipo lo que conlleva a gastos.
Aunque ya se habia hecho una inversión la decisión fue cambiar de plataforma de pagos en línea y es probablemente la mejor decisión para no seguir en pérdidas y continuar con la ejecución.
Finalmente un framework solo es un “camino propuesto” que puedes seguir o no, y puedes modificarlo de acuerdo a tus necesidades y las de tu negocio.
El video de “Server B” habla de “Liderazgo adaptativo y colaborativo” y no de “Incremental delivery”
Hola!, gracias por avisar ya lo estamos corrigiendo 😃
Gracias, ya esta corregido 😃
Este video no corresponde a lo que dice
Este video trata sobre "Liderazgo adaptativo y colaborativo"
Favor poner el video correcto “Desarolla tus productos de manera incremental”
Hola, veo que en este video el habla sobre incremental delivery, por esto tiene este nombre, te parece mal dejar este nombre?
Ya se muestra el video de “Incremental Delivery”,
Cuando lo reporte, el video hablaba sobre “Liderazgo adaptativo y colaborativo”.
Gracias.
Incremental Delivery
Consiste en las entregas productivas incrementales quiere decir que el trabajo va a ir siendo mayor y mayor a lo largo del tiempo para un proyecto determinado.
¿Por qué es incremental?
Porque vamos a ocupar varios features o pequeños grupos de tareas que vamos a entregar como software funcional, es decir que vamos a hacer solo el código necesario para cumplir ciertos requerimientos técnicos y no funcionales, cabe mencionar que el incremento delivery no en todas la iteraciónes se va a ir haciendo código, puede haber iteraciónes con historias de usuario que representen un entrenamiento, que representen investigación y desarrollo, que representen un Spike o un área de experimentación, etc.
Vamos a definir incrementos en nuestras evaluaciones
Evaluaciones que van desde las pruebas unitarias, pruebas de funcionalidad que vamos a hacer en nuestro software revisiones de código, o revisiones desde el punto de vista del cliente para ver el tiempo y costo de nuestro proyecto sean mínimas, es decir que si yo voy a hacer una revisión de código sea de una porción de código muy pequeña pero que es funcional, si yo voy a aprobar un nuevo feature, un nuevo botón, un nuevo campo, un nuevo formulario en mi software que sea solo esa mínima parte para que todos los resultados puedan ser favorables y el software se entregue de una mayor calidad.
Software de alta calidad
El software de alta calidad no se hace en grandes cantidades se empieza a hacer incrementalmente, un trabajo a la vez, cada iteración puede llevar una temática, por ejemplo la primera iteración puede ser de diseño, la segunda iteración puede ser de desarrollo, y la tercera iteración puede ser de pruebas, pero si nosotros podemos ir granulando esas historias y esas tareas a lo largo de las iteraciones podemos tener que nuestra primera iteración puede tener diseño, desarrollo y pruebas al mismo tiempo, esto nos va a llevar a opciones de terminación y con esto no quiero decir que vallamos a buscar terminar con el cliente nuestra relación laboral, sino que si hay algún problema hasta este punto realmente la perdida entre una iteración y otra o entre una entrega y otra de los features pequeñitos no va a impactar ni al negocio ni al cliente directamente y se puede retomar de una forma mas transparente.
Debemos actualizar siempre técnicamente nuestro software, es decir debemos proponer en cada una de las iteraciones usar tecnologías de punta y tecnologías nuevas que estén en modo estable ya que si nosotros hacemos una actualización de framework, por ejemplo si estamos utilizando una versión 1.4 de angular y queremos actualizarla al momento de que halla deprecados o que allá alguna falla en la compatibilidad de dicho framework, prácticamente el proyecto va a presentar un problema y es un riesgo muy grande para la funcionalidad del mismo por eso siempre debemos ir actualizando poco a poco en las diferentes y pequeños features que vamos a ir utilizando a lo largo del tiempo.
Como podemos ver agile utiliza mucho la ideología de divide and conquer, esto quiere decir “divide y vencerás” mientras mas pequeños sean las porciones de código o las tareas que estamos realizando mas fácil nosotros podemos avanzar
Platzi, donde puedo puntuar este curso como que no cumple mis expectativas? espero me contesten
Hola @juanesquivelmendez, si quieres hablemos sobre lo que esperabas del curso y así podemos ver como hacerlo mejor para darte lo que esperas 😃
Para mi uno de los pilares en el exito de un producto de software, el desarrollo incremental 😄
Al parecer hace meses están diferentes los vídeos del server B y server D, el del server D corresponde a la clase sobre liderazgo que viene mas adelante y el B es el correspondiente al titulo de esta clase. Ojalá lo arreglen pronto.
gracias por reportarlo, lo vamos a revisar
Gracias, ya esta corregido 😃
Desde mi punto de vista, el que se quiera aplicar el principio de que en metodologias ágiles no haya un “jefe” en el sentido tradicional de la palabra no significa que no deba ser hacer per ser. Es muy necesario que exista alguna persona que funja como tal porque entonces se podría creer que no el equipo no es profesional. Y que no hay seriedad. Nos guste o no debe haber la figura del Gerente de Proyecto o Lider de Proyecto o Coordinador porque a quien va a recurrir el equipo en caso de dudas, preguntas, conflictos. O simplemente notificar algo.
Aparece el video correspondiente a “Liderazgo adaptativo y colaborativo”, el mismo que está en la Sección 5 del curso. Este video no corresponde a su título: “Desarrolla tus productos de manera incremental” ni hace parte de esta sección.
Hola! gracias, ya esta corregido 😄
Esta clase es la misma que la número 21.
https://platzi.com/clases/scrum/concepto/soft-skills/liderazgo-adaptativo-y-colaborativo/material/
Utiliza servidor B, ahi si esta bien.
Ya está corregido 😃
Incremental Delivery
divide y vencerás
Justamente me está pasando esto en mi proyecto, comenzamos con tareas muy sencillas pero al avanzar con dichas tareas estas se incrementaron con más subtareas. Algo que nos ayudó mucho es analizar toda la tarea principar para sacar los posibles problemas pasa así crear pequeñas tareas desde un principio y hacer las pruebas para darle un double check.
Gracias al apoyo del equipo técnico, las reuniones semanales y la comunicación constante con el equipo se evitan muchos problemas. Para un PM la comunicación es esencial y es lo más importante para el proyecto.
