Los 12 principios del manifiesto ágil
Contenido del curso
Los 12 principios del manifiesto ágil
Contenido del curso
Sandra Sierra
LEONARDO DELGADO
Juan Fernando Utria Guisado
Company_admin
Lisset Alexandra Neyra Romero
Patricio Sánchez Fernández
José Javier López López
Marcelo Taco
Andrés Felipe Salcedo Sepúlveda
Profesor
Rodolfo Varela
Andrés Felipe Salcedo Sepúlveda
Profesor
Luis Camilo Fernandez Gomez
Edwar Y. Castillo B.
Cristian Giovani Carbajal Herrera
Lady Diana Camelo Ramirez
Magno Alarcón
Andrés Felipe Salcedo Sepúlveda
Profesor
Ana Maria Rojas Alcaraz
Paola Andrea Gómez Ariza
Diana Paola Muñoz Prada
Patricio Sánchez Fernández
JUAN PABLO ACOSTA AGUILAR
JUAN PABLO ACOSTA AGUILAR
dserrano4350
dserrano4350
CLAUDIA PATRICIA CABRERA CASTAÑO
maicol esteban tovar diaz
Juan Felipe Martinez González
Caso práctico:
Accionables:
Hola Sandra, a la última situación le agregaría también la X en el principio 9: La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
Muy buen análisis,
Hola Sandra, a la parte de ceremonias y espacio, ya que la ruta tomada no ha sido efectiva, yo presentaría un cambio de canal de comunicación ya que el actual no ha dado resultados.
Resumen de la Clase Principios • Principio 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. o ¿Qué es lo valioso para el cliente? • Principio 2: Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. • Principio 3: Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. • Principio 4: Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. • Principio 5: Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. o Cuando las personas están motivadas es entre el 15% y 20% más productivos. • Principio 6: El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. • Principio 7: el software funcionando es la medida principal de progreso. • Principio 8: Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. • Principio 9: La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. • Principio 10: la simplicidad, o arte de maximizar la cantidad de trabajo no realizado es esencial. • Principio 11: las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. • Principios 12: a intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Gran resumen, Lisset. Felicitaciones.
El equipo no vive los valores y principios ágiles y en específico:
_Estamos frente a un equipo que durante 3 años ha desarrollado un producto que no ha salido a producción. _
El cliente está muy molesto porque no le aceptan cambios en el alcance.
Los desarrolladores culpan del retraso al usuario, ya que tarda semanas en responder por correo las dudas que tienen sobre el producto.
_Como el porcentaje de avance no es el esperado, la gerencia ha exigido a los desarrolladores trabajar jornadas de 10 horas diarias. _
El equipo ha decidido eliminar algunos casos de prueba para recortar la brecha de tiempo en el plan de trabajo.
Como líder de un equipo, ¿cuánta tolerancia posee para las equivocaciones? Por ejemplo: si un miembro del equipo desea realizar una tarea de una forma que usted sabe que es errónea, ¿lo dejaría aprender de la experiencia? Reláteme alguna experiencia.
Hay una técnica en Management 3.0 que se llama delegation póker. Consiste en determinar 7 niveles de empoderamiento por cada tarea. De esta forma se determina el riesgo y que nivel de tolerancia se puede tener al error en cada actividad.
Si el riesgo es bajo, se asume el error en favor del aprendizaje. De igual forma, creo que siempre se puede opinar y sugerir (esto promueve el debate y la interacción), que es diferente a decirle a otros lo que tienen que hacer (esto promueve la opresión).
No se hace participe al cliente. No se hacen revisiones periódicas de avance. comunicación impersonal. No se permite el cambio en el transcurso del desarrollo.
Bien Rodolfo, añadiría también que el equipo no tiene un ritmo de trabajo sostenible.
En este caso, el equipo no está aplicando varios principios ágiles clave:
Aplicando estos cambios, el equipo podría ser más ágil, entregar valor antes y recuperar la confianza del cliente.
Comparto el ejercicio practico:
Profesor, de acuerdo con el principio 2, aceptamos que los requisitos cambien, pero digamos ya se acordó una fecha de entrega del producto y el cliente necesita hacer cambios urgentes, como se negocia esto?, lo aceptamos pero le decimos que atrasará la entrega del producto?
Hola Magno, uno de los aspectos clave de la agilidad es que el cliente hace parte del equipo. Los proyectos tradicionales fracasaban desde la década de los 90 según The CHAOS Report de Standish group, por falta de involucramiento del cliente, las prácticas ágiles emergen como una respuesta esto. Si el cliente no hace parte del equipo, no se está haciendo algo muy diferente a como se gestionaban proyectos en los 90.
En este caso, el cliente al hacer parte del equipo debe entender que toda decisión tiene un impacto, todo cambio es aceptado en agilidad pero reconociendo y aceptando desde todas las partes el impacto que tiene el cambio (en lo positivo, como en lo negativo)
Acciones a tomar:
Definir un sprint, tener claros los objetivos para comenzarlo
Definir historias de usuario para garantizar entregas frecuentes de valor
Hacer partícipe al cliente del desarrollo de software o producto
Realizar dailys
Capacitar mejor a los desarrolladores en su conocimiento técnico
Al final de cada sprint realizar un review
Se tienes los siguientes criterio de la problemática:
3 años lleva un producto que no se ha podido entregar
Cliente insatisfecho
Baja o nula comunicación y adecuada frente a los desarrolladores y el negocio (cliente)
Porcentaje de avance no esperado y no hay estructura de un plan de trabajo.
Se debe partir de un cambio:
coordinar una sesión con el equipo y el negocio para llegar a los diferentes acuerdos, aceptar los cambios de los requisitos
Llegar a un acuerdo en consultar con el cliente que espera como primera entrega y que es lo que realmente se va comprometer a entregar para no generar altas expectativa.
Generar sprints de trabajo de cada 15 días y dar seguimiento oportuno utilizando dailys de cómo va con el desarrollo y qué tipo de stopper están incurriendo por las demoras.
la comunicación se debe trabajar por ambos canales, correo electrónico para tener evidencias y sesiones de trabajo para que la justificación sea aún más clara de lo que se requiere en el producto.
Motivar al equipo y tener buen acercamiento.
Pactar con el cliente fechas de entregas significativas para que esté conforme con el trabajo y la planeación que se está ejecutando
Mantener la agilidad y la excelencia del cumplimento
Recordar al equipo que las tareas al ejecutar deben ser autogestionadas
Reflexionar con el equipo en que podemos mejorar y optimizar el tiempo de actividades llevando un Project con fechas definitivas para proceder a un buen seguimiento estructurad.
Buenas tardes compañeros, a continuación mi solución al caso propuesto:
Como se evidencia en la imagen, el equipo actual en mi opinión no está cumpliendo ninguno de los 12 principios de Agilidad, por eso ahora que se puede hacer para que esto cambie, relaciono algunos accionables a tener en cuenta:
Atenta a sus comentarios, gracias!
Excelente.
Equipo altamente comprometido y motivado, asegura el éxito.....
Los procesos deben ser flexibles y adaptables a las necesisades ranto de la empresa como del cliente, este binomio debe estar presente de inicio a fin.
Desafíos manifiesto ágil
Cumple
No los veo
No Cumple
Adaptación al cambio
Satisfacción
Accionables:
en mi caso 3, 3, 5, 2.
CASO PRACTICO RESUELTO CON PLAN DE MEJORA PROPUESTO:
en la problematica principal se debe a que estamos frente a un equipo que el al parecer en el primer caso , el producto a mirar y escoger con el tiempo que llevan se a atrazado por las actualizaciones de los requerimientos del cliente
por segundo caso se ve que los requerimientos y cambios del cliente no se estan tomando en cuenta para poder llevar acabo el aplicatico o diseño de lo que se apedido y asi es imposible terminar o llegar a algo concreto
los desarrolladores no toman los pequeños tiempos de solucion para darle al cliente el abnace y puedan interactuar para los cambios y mejoras .
Estamos frente a un equipo que durante 3 años ha desarrollado un producto que no ha salido a producción.
Principio no aplicado: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
El cliente está muy molesto porque no le aceptan cambios en el alcance.
Principio no aplicado; Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Los desarrolladores culpan del retraso al usuario, ya que tarda semanas en responder por correo las dudas que tienen sobre el producto.
Principio no aplicado,
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Como el porcentaje de avance no es el esperado, la gerencia ha exigido a los desarrolladores trabajar jornadas de 10 horas diarias.
Principio no aplicado: Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El equipo ha decidido eliminar algunos casos de prueba para recortar la brecha de tiempo en el plan de trabajo.
Principio no aplicado: El software funcionando es la medida principal de progreso.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
Y Transversalmente, Principio no aplicado: A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
****
****
Plan de acción:
1. Hay que alinear el equipo metodológicamente, cerrar brechas metodológicas hará que podamos hablar un lenguaje común sobre la forma de trabajar.
2. Acuerdo explícito, sobre cual alternativa permite primero asegurar un producto funcional, una salida en vivo controlada con una primera versión.
3. A nivel Directivo, pedir la presencia de un dueño de producto, en este espacio se requiere un responsable de negocio que permita priorizar el valor.
4. Se debe construir un producto backlog, es necesario saber del producto que podría estar ok, y que definitivamente está faltando, ojo – las arquitecturas deben estar aseguradas y vienen de equipos autoorganizados.
5. Accionar, unas primeras iteraciones, desde un esquema ágil controlado – híbrido pues no se puede sacar el equipo de la lógica cascada de un día para otro, el software funcionando nos dará el mejor indicador sobre la maduréz del proceso.
