Estás iniciando un proyecto ágil. Como scrum master, usted es el facilitador y ayuda al propietario del producto con el trabajo pendiente en la creación y también en su mantenimiento. También se coordina con las comunicaciones con los clientes externos para informar sobre el progreso del proyecto.
Su equipo autoorganizado está listo para iniciar los sprints del proyecto.
Todo está configurado, pero imagine que aquellos clientes que no están acostumbrados a este enfoque ágil y no son conscientes de las iteraciones en los sprints de prueba y solo están esperando el entregable final para probar todo como en el enfoque clásico.
¿Cómo capacita o trata a sus clientes que aún no conocen un enfoque ágil?
EDITAR:
Digamos que una vez que ya comenzó su proyecto y obtuvo su alcance/objetivos iniciales, crea sus sprints de 2 semanas para todas las características que se construirán con fechas y qué se probará y cómo cada característica cumple el objetivo (Esperando usarse más tarde como entrada para una nueva iteración).
Pero como dije, el cliente no tiene "recursos" para probar y dar muchos comentarios sobre los entregables, porque están acostumbrados al enfoque clásico en el que espera recopilar toda la información desde la concepción y refinar los datos ligeramente a través de la ejecución y luego quieren para realizar el esfuerzo de prueba más tarde (esto podría fallar y podría conducir a un retrabajo) Como experto en scrum, explique los beneficios del enfoque, les explica todo el proceso, pero aún así no están convencidos. 2 riesgos aquí:
Como su equipo ya es ágil, se autoorganizan y tienen la facultad de gestionar sus sprints con el propietario del producto. No tienes el "control" como un PM normal. No me malinterpreten, creo que el enfoque ágil es excelente para crear equipos motivados y difundir la creatividad.
¿Cuáles son sus estrategias a partir de la experiencia para tratar con clientes sin experiencia en enfoques ágiles?
Esta es una pregunta compleja porque supone dos cosas:
1) ha reconocido que parte del problema con la mayoría de los esfuerzos de desarrollo de software es que puede llegar al final y darse cuenta de que, aunque ha creado exactamente lo que se le pidió, no era lo que se necesitaba, por lo tanto, cambia a Scrum ; y
2) tu cliente ha decidido que, a pesar de esto, va a esperar hasta el final para decirte si está bien de todos modos.
Para su primer riesgo, no sé si esto tiene algo que ver con ágil. El problema con los proyectos de software de costo fijo siempre ha sido que pueden generar gastos descontrolados. Incluso si hay un alcance fijo, la mayoría de las empresas nunca dirán "tienes el alcance, tómalo o déjalo": daña demasiado su reputación, lo que significa que solo pagarás el costo. No puedo contar la cantidad de empresas que he visto hundirse debido a esto a lo largo de los años, independientemente del enfoque de gestión de proyectos. Lo que Scrum aporta a esta conversación es en realidad hacer que sea seguro para el cliente aceptar un contrato de tiempo y materiales porque puede ver un progreso constante, puede interrumpirlo en cualquier momento y puede mantener cualquier progreso que haya logrado. formado hasta ese momento.
Para el segundo riesgo, sospecho que es posible que no entiendan la pregunta. No tienen que hacer horas de pruebas UAT. Necesitan presentarse para una revisión de 2 horas cada dos semanas. Si alguien está dispuesto a pagar el costo de su empresa para desarrollar software, pero no da 2 horas de su propio tiempo ni designa a alguien para que lo represente, eso generaría algunas señales de alerta importantes para mí. De nuevo, sin embargo, esto no es realmente un problema ágil. Los proyectos se han estrellado y quemado por esta razón durante décadas. Muchas de las prácticas Agile y Scrum surgieron para mitigar este problema existente.
Lo primero, en mi opinión, a considerar aquí es esto:
¿Los requisitos de su proyecto son fijos/congelados?
Si la respuesta anterior es sí, entonces quizás el riesgo de que los entregables finales no cumplan con las expectativas del cliente es bajo. Doy por sentado que el equipo del proyecto ha entendido el alcance, los requisitos exactos del producto y tiene las habilidades, las herramientas y el cronograma/tiempo suficientes para cumplir con las expectativas de calidad del cliente.
Aquí, el enfoque clásico de hacer un entregable final al cliente para su UAT es menos riesgoso.
Por supuesto, se recomienda un enfoque ágil cuando el proyecto está experimentando un alto grado de cambios. Si esto es cierto con su proyecto, entonces se debe involucrar y participar activamente a las partes interesadas/clientes del proyecto.
Ahora, si el cliente tiene menos recursos/ancho de banda, a menudo, el equipo de desarrollo y el cliente pueden intercambiar información y actualizaciones del estado del proyecto en un proceso dinámico y co-creativo, como una demostración rápida de 20 minutos. con el cliente mostrando módulos/componentes importantes del proyecto.
Este tipo de interacciones regulares con el cliente les da la sensación de "dónde estamos" en el proyecto, genera confianza y también le da al equipo del proyecto la oportunidad de hacer ajustes (si es necesario) en los entregables del proyecto.
erik
aventura2099
Máximo Décimo