Cómo hacer que un equipo sea ágil

Caso práctico:

Accionables:

• Definir tamaño del sprint (+corto si hay +incertidumbre)
• Escribir HU y priorizarlas con el cliente
• Presentar al final de cada sprint el valor / incremento funcional
• Involucrar al cliente en las etapas del proyecto
• Ceremonias y espacios para mejorar la comunicación
• Excelencia técnica para lograr un mejor producto

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.

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. _

• Entrega de Producto Frecuentemente

El cliente está muy molesto porque no le aceptan cambios en el alcance.

• Satisfacción del Cliente con entrega continua y temprana de valor
• Aceptamos que los requisitos cambien

Los desarrolladores culpan del retraso al usuario, ya que tarda semanas en responder por correo las dudas que tienen sobre el producto.

• Comunicación cara a cara
• Los responsables de negocio y desarrolladores trabajan juntos de manera cotidiana

_Como el porcentaje de avance no es el esperado, la gerencia ha exigido a los desarrolladores trabajar jornadas de 10 horas diarias. _

• Ritmo sostenible
• El software funcionando es la principal medida de progreso
• La simplicidad

El equipo ha decidido eliminar algunos casos de prueba para recortar la brecha de tiempo en el plan de trabajo.

• La atención continua a la excelencia técnica

https://docs.google.com/document/d/1NW-gi7UGrUzZp0akQJoT-pkMEYIk2iZiUwEgEl4R9Kk/edit?usp=sharing

Ejercicio realizado

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:

1. Contratar a una persona especializada en metodologías agiles (Scrum Master)
2. Identificar quién es el Product Owner, el equipo de desarrollo y el usuario final.
3. Identificar claramente cuál es la necesidad qué tiene el usuario final.
4. Realizar una lista ordenada de lo que se requiere para obtener el producto final.
5. Priorizar las actividades para generar valor en menor tiempo.
6. Identificar cuáles son las estimaciones en cuento a recursos y tiempos para desarrollar el producto. (Tener en cuenta impedimentos)
7. Listar los cambios que se tengan durante el desarrollo por parte del usuario final.
8. Agendar reuniones diarias con todo el equipo, para conocer los avances que se tienen y los impedimentos para continuar el desarrollo.
9. En caso de tener dudas sobre el desarrollo del producto, agendar reuniones con el usuario final para refinar las actividades a realizar.
10. Agendar reuniones periódicas para mostrar el avance que se tiene en el desarrollo del producto.

Atenta a sus comentarios, gracias!

https://docs.google.com/document/d/1NW-gi7UGrUzZp0akQJoT-pkMEYIk2iZiUwEgEl4R9Kk/edit?usp=sharing envío mi ejercicio

Resultado del caso practico:

También les dejo el enlace en Notion por si alguien quiere copiar la plantilla del caso https://sofiamunozm.notion.site/Caso-Practico-ab2e0bc1d67e4cc5b2a909465810e4d3?pvs=4

buen dia
-Satisfaccion con el cliente( no hay un cliente a gusto con el trabajo)
-Aceptar que los requisitos cambien.
-No hay un trabajo cotidiano , ni cara a cara entre el negocio y los desarrolladores(tardanza en responder)

No se están aplicando:

• La satisfacción del cliente mediante entregas tempranas
• Los responsables de negocio y los desarrolladores
  no están trabajando juntos

Accionables que se pueden introducir:

• Aceptar que los requisitos cambien, incluso en etapas
  tardías del desarrollo.
• buscar que el equipo este motivado. Brindando el apoyo que necesiten para la ejecución del proyecto manteniendo un ritmo constante
• Entregas frecuentes
• Buscar la satisfacción del cliente

es clave las relaciones personales reuniones cara a cara y determinar que es importante para el cliente el centrismo en el cliente y su valor no es solo metodo es lo que asegura el exito y el agilismo.

Falto más foco en las relaciones para no llegar hasta el punto de molestia o inconformismo
Falta de medición y comunicación para que el cliente viera frecuentemente el avance involucrándolo en cada etapa
Falto llevar ciclos más cortos y entregas fraccionadas.

El cliente está alejado.
No hay entregables incrementales periódicos.
No hay cara a cara.
No son bienvenidos los cambios

No tienen una comunicación fluida con el cliente.
No les generan la suficiente confianza al equipo.
No dan el feedback necesario para los cambios.
El equipo se perjudica con los horarios.
El usuario no comunica con los miembros del equipo una conversación cara a cara.
Es por ellos que necesita:
Priorizar la calidad de la agilidad
Incorporar retroalimentación del cliente en el proceso del desarrollo.
Fomentar ambiente de confianza y colaboración.
Establecer una comunicación mas fluida con el cliente.
Realizar una restrospectiva
Dar atención continua a la excelencia técnica y al buen diseño.

Sobre el caso práctico, a continuación mis observaciones respecto a la aplicación de los principios de la agilidad:

Principio 1 y 2 Las molestias del cliente por no le aceptan cambios, no se está atendiendo la prioridad que es satisfacer al cliente.
Principio 3 Excesivo el tiempo de desarrollo sin entregas de valor al cliente
Principio 4 La ausencia de comunicación asertiva y en iteración muy corta de tiempo, entre los usuarios y desarrolladores
Principio 5 El trabajo excesivo creará fatiga en los desarrolladores y disminuirá la productividad
Principio 6 La ausencia de definición de canales de comunicación de acuerdo con la realidad de los equipos.
Principio 7 No se refleja software funcionando en un periodo de 36 meses, puede ser un desarrollo a portas de la obsolescencia
Principio 9 reducir las pruebas puede afectar la calidad y la relación con el cliente.

En este corto ejemplo vemos que ninguno de los principios de está aplicando, como recomendación para que este equipo mejore podría sugerir que adopten un framework de trabajo como Scrum para que se involucre el cliente con más frecuencia, adicionalmente, recomiendo que se trabaje en una transformación cultural fuerte para que el equipo entienda en que está fallando y busque alternativas de comunicación cara a cara con el cliente para trabajar en la transparencia entre ambas partes y primordial, buscar como motivar al cliente para que se involucre más en el desarrollo del producto.

Una vez leído el caso y antes de mencionar esos principios es fundamental reflexionar que si una iniciativa se toma 3 años para desarrollar un producto es por cuanto se está desconociendo en su integridad el manifiesto.

1. La respuesta ante el cambio sobre seguir un plan no se visualiza en el caso, en tres años las necesidades del cliente y las tendencias cambian, debemos aceptar que los requisitos cambien.
   2.Falta una interacción cara a cara, no puede un equipo si efectivamente está colaborando al cliente que se sienten en zona de confort esperando respuestas de correos electrónicos. Responsables del negocio y desarrolladores deben trabajar juntos.
   3.El porcentaje de avance no es el esperado por que no se realiza una entrega de productos funcionales de forma frecuente, debe darse un ritmo constante de forma indefinida.

Sobre el caso práctico se observa que no se cumplen con los siguientes principios por expresión:

Principio 1 y 3. Estamos frente a un equipo que durante 3 años ha desarrollado un producto que no ha salido a producción.
Principio 2 y 4. El cliente está muy molesto porque no le aceptan cambios en el alcance.
Principio 4 y 6. Los desarrolladores culpan del retraso al usuario, ya que tarda semanas en responder por correo las dudas que tienen sobre el producto.
Principio 5, 7 y 9. Como el porcentaje de avance no es el esperado, la gerencia ha exigido a los desarrolladores trabajar jornadas de 10 horas diarias.
Principio 10 y 11. El equipo ha decidido eliminar algunos casos de prueba para recortar la brecha de tiempo en el plan de trabajo.

Hola, leyendo el caso, identificó estos puntos:

• No hay satisfacción del cliente, el cliente ya está molesto e insatisfecho.

• Los plazos de entrega no son tempranos, llevan más de 3 años en el proyecto, por lo tanto, el cliente no ha visto el valor, ni en entregas parciales ni completa. En consecuencia, no hay dimensión del progreso.

• No se involucra a cliente en el producto final.

• No hay motivación del equipo, ya hay más exigencia por las jornadas del trabajo, por el atraso del proyecto. Lo que también lleva a un ritmo, no constante de trabajo.

• Comunicación cara a cara: la comunicación ha sido a través de correos electrónicos, por lo que limita el entendimiento.

• Al descuidar las pruebas para recortar la brecha de tiempo en el plan de trabajo, limita la excelencia técnica (compromete la calidad) de la entrega y por lo tanto, la agilidad del proyecto.

Accionables

• Precisar el marco de trabajo ágil a utilizar. — En este caso puede ser Scrum.
• Definir las responsabilidades del equipo. — Product Owner, Scrum Master, Developer Team.
• Definir las iteraciones del sprint. — Como hay mucha incertidumbre, debe ser entre una y dos semanas.
• Concretar el Product Backlog (aquí se requiere que el Product Owner tenga una reunión con el cliente) e Historias de Usuario con el equipo.
• En general, con ayuda del Scrum Master, iniciar el marco de trabajo Scrum, con sus eventos y artefactos. — El SM debe hacer que todo el marco de trabajo se cumpla.
• El Product Owner debe tener comunicación eficiente con el cliente.
• Darle máxima prioridad al ‘sprint review’ en formato cara a cara con el cliente, con el fin de recibir la mayor cantidad de feedback e información de la comunicación no verbal.

Buenas noches comparto a continuación.

Solución:
Estamos frente a un equipo que durante 3 años ha desarrollado un producto que no ha salido a producción.
(en esta parte se podrían está retrasando los tiempos de entrega del producto para que se corrija y se mejore la funcionalidad principio 3).

El cliente está muy molesto porque no le aceptan cambios en el alcance.
(no se está escuchando al cliente para poder corregir los errores evidenciados generando insatisfacción y afectando el valor que quiere el cliente siendo Principio 1, en esta misma situación no se está aceptando que los requisitos cambien incluso en etapas tardías que es el principio 2, al no evidenciarse funcionamiento del software hay falla Principio 7, no hay atención continua para la excelencia Principio 9).
Los desarrolladores culpan del retraso al usuario, ya que tarda semanas en responder por correo las dudas que tienen sobre el producto.
(en esta parte los responsables del negocio y los desarrolladores no están trabajando de la mano para sacar el proyecto Principio 4, también al ser un entrono poco motivado para trabajar no hay confianza por parte de los dos y esto afecta la ejecución y el cumplimiento, Principio 5, no se evidencia comunicación cara a cara generando insatisfacción por parte cliente Principio 6).

Como el porcentaje de avance no es el esperado, la gerencia ha exigido a los desarrolladores trabajar jornadas de 10 horas diarias.
(Al no haber desarrollo sostenible el proceso no es agil y por ello se extienden las jornadas y adicional la probabilidad de que el ritmo no sea constante Principio 8, No hay reflexión por parte del equipo para poder ser más efectivos Principio 12).

El equipo ha decidido eliminar algunos casos de prueba para recortar la brecha de tiempo en el plan de trabajo.
(El equipo no está auto organizado Principio 11, No hay simplicidad o pequeñas entregas comprometiendo el proyecto Principio 10)

Según el contexto del problema, existe una falencia en la implementación de todos los principios del manifiesto ágil. Considero que el primer manifiesto ágil que debe implementarse es el sexto. Existe un problema de comunicación eficiente y efectiva que afecta la interpretación de necesidad y/o valor del cliente y el desarrollo de entregables e iteraciones en cortos periodos de tiempo. Lo anterior, hace evidente que falta la implementación del tercer manifiesto, y entendiendo por el contexto del problema que el cliente necesita cambios del alcance, también el segundo.
Al implementar los anteriores manifiestos a la metodología del proyecto se alcanzaría el primer manifiesto.
Dos de los manifiestos que están en riesgo de incumplirse son el octavo y el noveno, debido a la necesidad de entregar lo antes posible se daría un pico de trabajo y se sacrificarían algunas pruebas lo que podría afectar la calidad. Estos principios no se pueden dejar de implementar debido a que hay un alto riesgo en que se afecte el primer principio. Por tanto, después de tener la claridad de las necesidades y el valor que el cliente busca, se debe implementar un nuevo plan de trabajo teniendo presente los manifiestos cuarto, quinto, séptimo, decimo, undécimo y doceavo, logrando así la aplicación de todo el manifiesto ágil.

Respuesta al trabajo práctico:

1. El equipo tiene muy poca comunicación con el cliente, ya que el cliente posiblemente no siente que sea parte esencial del equipo, sino que da el requerimiento y piensa que el equipo ya sabrá lo que debe hacer sin su presencia constante.

2. No se tiene un producto funcionando, por lo que el cliente seguramente tiene una idea vaga de como realmente esta quedando el producto en base al requerimiento.

3. El equipo al verse que tienen que trabajar más se desaniman por lo que va a bajar la calidad con la que se realizan los avances, adicional de que la comunicación con el cliente es muy escasa y trae más incertidumbre.

4. La eliminación de casos de pruebas puede traer consigo un atraso y perdida de tiempo al encontrar fallos más adelante que pueden desanimar, bajar la calidad y reputación del equipo con relación al trabajo que entregan.

Aquí primero que nada se puede reevaluar la situación para ver donde están parados como equipo y plantear el período de tiempo más corto posible para entregarle al cliente un MVP que puede ser testeado. Partiendo de esta base se puede empezar a involucrar al cliente periódicamente en sesiones en vivo donde se muestran los progresos y se le da un tiempo de no más de 2 semanas para realizar su feedback generando el espacio y el tiempo necesario para tener una dinámica de trabajo e involucramiento de la otra parte. Entrando en esta dinámica será posible incorporar los cambios que desee el cliente en cualquier etapa por más tardía que sea.

Gracias

Basado en el texto del caso podría indicar que el único principio que no puedo establecer como deficiente es “Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados”, ya que no tengo referencias del equipo de trabajo, pero en relación a los demás principios creo que no se cumplen ya que muchos de los principios están interrelacionados y el no logro de algunos implica una cadena de deficiencias.

A continuación, establezco mi plan de contingencia basado en las siguientes acciones:

• Generar reunion con cliente a modo de establecer los
  resultados no esperados y definir los alcanzables de manera de generar plan de acción en etapas de logros más acotados (involucrar al cliente, ayuda a definir requerimientos reales de las necesidades del cliente)

• Crear equipos de trabajo conformados en conjunto con clientes. (responder a necesidades del cliente, con requerimientos afinados en el desarrollo real de la necesidad del cliente, mejorarla tolerancia a cambio, involucrar al cliente en el desarrollo de la solución)

• Sincerar expectativas, evitando confrontar culpas, pero establecer oportunidades de acciones que permitan alcanzar logros (conversación cara a cara, mejor comunicación, aceptar que los requerimientos cambien)

• Establecer alcanzables en periodos cortos para resolver temas puntuales y avanzar al resultado final optimo. Diseñando un plan de control más acotado que permita ir liberando hitos hasta alcanzar el desarrollo esperado del proyecto. (desarrollo sostenible, entregar software funcionales constantemente)

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

  

Podriamos decir que casi todos los principios en medida NO se estan cumplendo aca mi aporte.
Falta generar espacion propicion para unaComunicación cara a cara (principio 6), identificar y cerrar la brecha de entrega del producto rapidamente no va a permitir activar el princpio de entregas de software funcional (principio 2) con esto tambien activar el principio 12 de recibir feedback y evaluar.
No menos importante que estos espacion comenzaran a identificar con el cliente sus necesidad y espectativa lo que generaria una activacion del principio 1 y 4 de colaboracion con todas las partes, todo esto ayudaria a mostrar resultados mas rapido y el principio 7 de progreso ya seria una realidad mas rapida. y como equipo trabajar en quitar o dejar de practicar el recorte de temas tecnicos y trabajar en como aprender mas de una manera simple pero efectiva en los periodos cortos (principio 9 y 10).
Saludos a todos un abrazo.

Para lograr que el equipo sea más ágil, se debe involucrar más al cliente, teniendo retroalimentación constante, consiguiendo generar entregas más valiosas y completas. Se debe aceptar los cambios en las planificaciones y en el alcance del proyecto, ya que el valor esperado puede cambiar. Se debe velar por llevar reuniones constantes cara a cara para evitar errores de interpretación de los equipos, generando trabajo y avances continuos y estables y manteniendo al personal motivado. Es clave poder responder dudas rápidamente y así no trabar el desarrollo de los entregables. Ambos equipos deben trabajar en alinear sus necesidades y requerimientos y gestionarse mejor en el desarrollo de tareas, siempre reflexionando al final de cada etapa y viendo si la planificación requiere ajuste.

No se cumple el principio numero 4 ya que no se tiene una comunicación constante entre los desarrolladores y los encargados del negocio.

También se podría hacer énfasis en el criterio numero 5 ya que se le ha exigido al equipo de trabajo quedarse mas tiempo.

A su vez por parte del equipo se falta al principio numero 8.

Y ya especulando creo que también faltaría la 10 ya que un desarrollo que dure ese tiempo seguramente descarto la simplicidad.

Hola, mis notas sobre el caso de estudio:

Principio 1: Conocer la necesidad del cliente desagregandolo, para hacer una entrega mínima que le de valor haciendo ciclos cortos.

Principio 2: Este marco de trabajo permite refinar el Product Backlog, permitiendo que se hagan cambios al objetivo del producto, entonces el alcance puede variar.

Principio 3: Hacer ciclos cortos en los Sprint para entregar el objetivo del sprint y que el usuario vaya viendo los incrementos que contribuyen al objetivo del producto.

Principio 4: El Daily Scrum es una forma de revisar que impedimentos se están presentando, en este evento o ceremonia se deben ver los tres pilares, transparencia, la inspección y la adaptación.

Principio 5: A través de la Retrospectiva Scrum le permite al Equipo la manera de corregir y mejorar el trabajo, se debe contribuir a la mejora continua, empoderar al equipo para que sea autogestionado.

Principio 6: Definir las Daily Scrum con esto contribuye a que el equipo este comunicado, interactuando y haciendo que la comunicación sea más fluida.

Principio 7: Si se define un Product Backlog que se compromete con el Objetivo del Producto y hago un Sprint Planning que se compromete con el objetivo del Sprint, esto permitirá que entregue siempre un incremento en tiempos cortos generando valor hasta conseguir el objeto final del producto.

Principio 8: Se debe tener el equipo motivado y esto permitirá que sea más productivo y eficiente y lograr esa entrega de valor, para que trabajar más horas si el equipo esta desmotivado esto no garantiza que va a ser más productivo.

Principio 9: Este marco de trabajo permite que siempre haga entregas de calidad y no de cantidad, debo tener como objetivo el producto mínimo viable.

Principio 10: Los Sprint deben ser de lapsos cortos de tiempo, al hacerlos de mucho tiempo esto puedo generar incertidumbre, los Sprint Backlog deben ser simples y desmenuzarlos para entregar mayor valor.

Principio 11: Revisar cuales son las falencias que tienen los miembros del equipo para brindarles el conocimiento y las herramientas necesarias para que puedan ser autogestionados y autoorganizados.

Principio 12: Los Sprint Retrospective permite revisar y freflexionar cómo estoy haciendo el trabajo y cual es la mejora al servicio del equipo

En conclusión, en este caso práctico no se esta aplicando el marco ágil.

No se está cumpliendo el principio de colaboración con el cliente, ya que no se evidencia una comunicación cercana con el cliente, excusándose en la no respuesta de correos, cuando hay múltiples formas de contactar al cliente, adicional que no le aceptan los cambios que el cliente sugiere, aunque ya lleven algún avance el equipo debe colocar en primer lugar las preferencias y opiniones del cliente validando previamente la funcionalidad de sus sugerencias, esto hace que el equipo tampoco está cumpliendo con el principio de “respuesta ante el Cambio” , y con la exigencia de trabajar más tiempo a los colaboradores se pone por encima los procesos sobre los individuos, ya que más horas de trabajo no los motiva a terminar el proyecto.

Un caso muy habitual en el desarrollo de software.

Los ordeno de acuerdo a mi punto de vista en que empezaría a solucionarlos.

1.- El cliente está muy molesto porque no le aceptan cambios en el alcance.
acciones a implementar:
+Se trabaja juntos negocio/desarrolladores de forma cotidiana durante todo el proyecto.
+La mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua con valor.
+Se entrega software funcional en un periodo dos semanas a 2 meses, en el periodo más corto posible.
+Aceptamos que los requisitos cambien incluso en etapas tardías del desarrollo mediante el cambio se proporciona ventaja competitiva al cliente.
Ya platicamos con el cliente pasamos a platicar co el equipo:

2.- Estamos frente a un equipo que durante 3 años ha desarrollado un producto que no ha salido a producción.
*El método más eficiente y efectivo de comunicar información al equipo es la conversación cara a cara.

3.- Los desarrolladores culpan del retraso al usuario, ya que tarda semanas en responder por correo las dudas que tienen sobre el producto.
+Los proyectos se desarrollan en torno a individuos motivados, darles el entorno y el apoyo que necesitan y confiarles la ejecución del trabado.
+Los procesos ágiles promueven un desarrollo sostenible, lo que permite un ritmo constante indefinido.
+La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

Trabajar más tiempo no quiere decir que se obtengan mejores resultados al contrario puede crear equipos con falta de motivación.

4.- Como el porcentaje de avance no es el esperado, la gerencia ha exigido a los desarrolladores trabajar jornadas de 10 horas diarias.

+La simplicidad o el maximizar el trabajo no realizado es esencial

+Las mejores arquitecturas emergen de los equipos auto-organizados.

+A intervalos regulares el equipo reflexiona en como ser más efectivo ajustando y perfeccionando su comportamiento en consecuencia.

4.- El equipo ha decidido eliminar algunos casos de prueba para recortar la brecha de tiempo en el plan de trabajo.

+La simplicidad o el maximizar el trabajo no realizado es esencial

+La mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua con valor.

+Aceptamos que los requisitos cambien incluso en etapas tardías del desarrollo mediante el cambio se proporciona ventaja competitiva al cliente.

+Se trabaja juntos negocio/desarrolladores de forma cotidiana durante todo el proyecto.

+El software funcionando es la medida principal de progresó.

Seria la forma en que aplicaría los principios a la solución de este caso.

No se estan aplicando los siguientes principios:
Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
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.
El software funcionando es la medida principal de
progreso.
Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.

Deben trabajar en equipo los desarrolladores y el cliente para entender los cambios, ajustar el plan de trabajo y definir entregas tempranas para aportar valor. El trabajo en equipo es fundamental porque se cruzan esfuerzos de ambas partes y así no se va a reventar el equipo de desarrollo, un equipo desmotivado hace que las cosas no salgan como se esperan, la comunicación asertiva es una herramienta fundamental.

Observaciones al caso propuesto

• El equipo lleva 3 años sin entregar resultados tangibles lo que visibiliza varias oportunidades de mejora.

1. La comunicación entre las personas los procesos y las herramientas.
2. Software funcionando, entregas tempranas que reflejen que vamos por el camino correcto. Generando satisfacción con el cliente.
3. Realizar reuniones cortas de seguimiento (Daily) para identificar que hemos hecho, que vamos hacer y que impedimentos tenemos.
4. Buscar la excelencia técnica para obtener un mejor resultado.

No toman en cuenta los requerimientos del cliente.
El cliente no responde los correos por qué no se siente involucrado en el desarrollo del producto por lo que la interacción debería ser P2P. De manera de hacer seguimiento constante a los resultados y aplicar cambios.
Eliminar casis de prueba atenta contra la calidad del producto.

Este equipo no está trabajando agilmente porque no está cumpliendo con el alcance en tiempo, seguramente ha invertido más el tiempo en un producto que no esta generando valor, el cliente por lo tanto no se sentira satisfecho en tanto no se tome en cuenta sus requerimientos. Es probable que el equipo este trabajando de forma tradicional y tenga de antemano una visión de un producto final que no corresponde a los criterios de agilidad y de entregas parciales que generen valor y que involucren al cliente en el desempeño de los requerimientos y los criterios de aceptación. Cambiar de modo de trabajo y emplear la agilidad debe generar entrega frecuente de valor, motivación del equipo de trabajo, cumplimiento de los requerimientos del cliente y menos reprocesos en l aejecución del producto.

-Satisfaccion del cliente
-Los requicitos cambian incluso en etapas tardias
-conversacion cara a cara
-Sofware funcionando