Curso: CC62V - Agustín Villena Rodrigo Ojeda - Julio Quinteros Extreme Programming: On-Site Customer Curso: CC62V - Agustín Villena Rodrigo Ojeda - Julio Quinteros

Motivación La idea es que la relación con el cliente sea totalmente diferente a lo que se ha venido haciendo en las metodologías tradicionales, que se basan fundamentalmente en una fase de captura de requisitos previa al desarrollo y una fase de validación posterior al mismo.

Fuente – The Standish Group Motivación

¿Qué es? “The Customer is Always Available” Tip Si no es posible tener un cliente “on-site”, debe por lo menos manejarse una suerte de “proxy” en su equipo. Una posibilidad es elegir una persona del equipo XP, la cual funcionará de proxy frente al cliente (quién depende de la compañía... algunas pueden optar por el gerente de productos, otras prefieren el gerente de programas... finalmente una opción puede ser uno de los programadores). ¿Qué es? “The Customer is Always Available” Cliente en el lugar de Desarrollo. Desarrollo en el lugar del Cliente. Obtener un representante local. Tip Manejar un “proxy”.

¿Para qué? Para aumentar el “ancho de banda” de la comunicación, ¿qué es mejor que hablar cara a cara? (y con más kbps mejor!). Para corregir, lo antes posible, la dirección de avance del proyecto durante el desarrollo de las iteraciones.

¿Qué hace el cliente? Contesta preguntas y toma decisiones Escribe tests de aceptación Fija prioridades Revisa resultados, decide la continuidad de la producción

Fortalezas Las decisiones se toman rápidamente y las dudas son aclaradas en el instante. El programador obtiene un test de aceptación a sus dudas o una User Story.

Fortalezas El programador no hace suposiciones, no programa y luego consulta. Mayor parte del tiempo se trabaja en tareas de mayor prioridad. Son las que realmente tienen valor para el cliente!!!

Debilidades / Dificultades Si no se hace un Test de Aceptación o una User Story no queda registro de la decisión o de la respuesta entregada. Dificultad de extraer al cliente de sus obligaciones labores oficiales. Un cliente poco claro puede llevar el volante hacia cualquier parte. (Riesgo)

RX - RECETARIO EXTREMO Problema: Nuestro cliente “on-site” a menudo no está disponible (vaya novedad!). Solución: Sáquele el jugo mientras pueda; los vacíos que queden párchelos con más comunicación y documentación.

RX Problema: Un cliente no es suficiente. Por la eventual diversidad de las áreas que el proyecto abarque. RX Problema: Un cliente no es suficiente. Solución: Un “Team” de clientes (analistas, gerentes, etc).

RX Problema: Un cliente es un trabajo terriblemente estresante. Cliente conflictivo!!! RX Problema: Un cliente es un trabajo terriblemente estresante. Solución: “Team” de clientes. Solución : Varios clientes part-time.

RX Problema: Si se dispone de un “team” de clientes, esto puede reducir la comunicación, incrementar la interferencia, o peor, la inconsistencia. Solución: Documentar acuciosamente. Warning! -la documentación queda rápidamente obsoleta en XP-. Solución: Preguntar más al “team” que a un cliente en particular.

RX Problema: Si se dispone de un “team” de clientes, esto puede reducir la comunicación, incrementar la interferencia, o peor, la inconsistencia... Solución : Maneje un cliente pivote (vocero). Solución : Asegúrese que su gente tenga presente que no todos los clientes del team manejan todos los temas.

RX Problema: El Cliente cambia de opinión... No es un problema!... por el contrario... Uno debe estar feliz por un cambio! Problema: El Cliente cambia de opinión... Solución : Tenga presente que es parte de la esencia de XP. Así es la vida. Solución : Revise el manual de XP (asegúrese de seguir todas las prácticas).

RX Problema: El Cliente cambia de opinión... Solución : Quite la palabra ”No!!!" de su vocabulario. Reemplácela por "No hay problema!... le costará la módica suma de... $$$".

RX Problema: El cliente es un punto crítico. Solución : Con una planificación bien hecha debería poder seguir sin problemas (por un tiempo). Mire hacia atrás. Solución : Un “Team” de clientes.

RX Problema: El cliente es un punto crítico. Solución : Un cliente "backup”. Solución : Cancele el proyecto. Muchas veces la falta de participación es reflejo de la poca importancia del proyecto para el cliente. No considere la cancelación como un fracaso.

RX Problema: El/los cliente(s) debe(n) escribir los test... pero mi cliente no es muy hábil en esto, ¿Qué puedo hacer? Solución : Asigne desarrolladores para asistir en la elaboración de los test. Solución : Establezca una regla de “no se pasa a la siguiente historia hasta que se pasen todos los test de la presente”.

RX Problema: El/los cliente(s) debe(n) escribir los test... pero mi cliente no es muy hábil en esto, ¿Qué puedo hacer? Solución : Maneje un historial de test. Úselo como referencia. Solución : Tenga a mano gente de QA en el team de clientes.

Ideas extras... La presencia del cliente debe ser aprovechada al máximo. Se debe tener claro los temas a tratar con él desde antes. (Preparar la reunión con el equipo) Asistir al cliente en la creación de historias de usuario. (Pair Programming, el cliente es parte del equipo!)

Ideas extras... Motivar la participación del cliente dejándole en claro que es su dinero el que se gasta (tiéntelo a participar más que convencerlo). Provea al cliente un ambiente adecuado de trabajo (snacks!).

Referencias http://www.extremeprogramming.org/rules/customer.html http://www.xpexchange.net/english/intro/onSiteCustomer.html http://www.softwaremag.com/archive/2001feb/CollaborativeMgt.html http://www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf http://c2.com/cgi/wiki?XpOnSiteCustomerPitfalls http://c2.com/cgi/wiki?LackOfOnSiteCustomer http://www.bestbrains.dk/xpvip-jaoo2003-report.html