Somos un pequeño equipo de desarrollo móvil (6 desarrolladores, 3 QA, 1 líder de equipo). Somos un poco nuevos en ágil, y solo estamos aprendiendo las cuerdas/cometiendo errores a medida que avanzamos. Todo el equipo reporta a un gerente de proyecto en otro país, quien a su vez habla directamente con el cliente. Esto se hace debido a problemas de barrera del idioma.
Actualmente estamos tratando de adaptar un procedimiento ágil, donde hacemos scrums semanales. Para cada lanzamiento, aquí está el flujo actual:
Soy consciente de que no todos los casos de problemas o errores en las especificaciones se determinan en el paso 2 y aún pueden surgir en las fases posteriores de la versión actual. Sin embargo, hay ocasiones en las que, en el paso 4, los desarrolladores aún obtienen casos (a veces casos extremos) que afirman que los casos deben manejarse y debemos repetir el paso 2 nuevamente. Actualmente le está dando al equipo una mala reputación para el gerente, y muy probablemente a la empresa una mala reputación para el cliente. Para este tipo de problemas, es mejor:
Soy consciente de que esto es caso por caso, pero en general, ¿cuál sería mejor? ¿O hay otras soluciones posibles?
La razón principal por la que surgió Agile es que la gente se dio cuenta de que el cambio es inevitable en el desarrollo de software. Este cambio proviene de varias fuentes:
Durante muchos años la gente trató de luchar contra el cambio. Intentaron mejorar en el cumplimiento de los requisitos por adelantado. Intentaron permitir la contingencia para eventos inesperados. Nada de esto realmente ayudó.
Sus dos sugerencias siguen este patrón.
Ahí es donde entró Agile. Con Agile, el cambio no solo se acepta, sino que en realidad se alienta . Una vez que acepta que el cambio va a ocurrir, puede construir sus procesos alrededor de él.
Mi consejo sería optar por una solución Agile. Espere que suceda el cambio. No limite el tiempo que cree que tomarán las cosas, pero permita la flexibilidad. Espere que cada vez que muestre algo a sus clientes reciba comentarios y tenga que hacer cambios.
Así que estás corriendo ágil. Tiene una sesión de planificación de sprint y el cliente quiere que se instale una estufa en su cocina en la pared norte entre los gabinetes. Los desarrolladores hacen todas las preguntas correctas... ¿Cuál es el tamaño de la estufa, cuál es el color, gas o electricidad, salida de btu... etc.
Bueno... He aquí, una semana después de la instalación, los desarrolladores descubren que los instaladores de encimeras dejaron algo colgando en sus encimeras y la estufa no encaja en su lugar.
Su solución propuesta es "los requisitos están establecidos ... Obtenga una grúa y una cadena y presione el pedal del acelerador hasta que encaje".
Mi pregunta es, si el cliente no está disponible, ¿quién es el propietario del producto? Una conversación de 20 minutos con el propietario de un producto decidiría si:
Parece que el problema es que el cliente no está disponible y nadie está dando un paso al frente para actuar como propietario del producto para ponerse en el lugar del cliente y tomar una mejor decisión. Alguien solo tiene que decir "coge la estufa más pequeña y dile al cliente por qué lo hicimos". Nadie quiere tomar ninguna propiedad.
Parece que estás haciendo Scrum. El marco Scrum le ofrece dos respuestas, las cuales debe implementar lo antes posible.
El objetivo principal de un propietario de producto es alguien altamente disponible para el equipo que tiene la autoridad para tomar decisiones. Una cita: "Un buen dueño de producto debe asegurarse de que sus preguntas sean respondidas dentro de los 5 minutos, el 85% del tiempo". -Jim York.
Su gerente de proyecto podría estar actuando como propietario del producto, pero esto debe quedar explícitamente claro y esta persona debe estar disponible y capacitada para tomar decisiones.
Si no puede obtener un Product Owner real, es posible que desee considerar hacer algo diferente a Scrum.
Transparencia, Inspección y Adaptación son los pilares de Scrum. El objetivo de Scrum (y Agile en general) no es responder todas las preguntas con anticipación para "hacerlo bien la primera vez". El punto es construir algo que funcione, recibir retroalimentación y luego mejorarlo.
No es necesario que verifique cada una de las decisiones que debe tomar con el PO antes de realizar el trabajo. La idea es que los desarrolladores tomen buenas decisiones, presenten su trabajo para recibir comentarios, como en Sprint Review, y luego iteren para mejorarlo.
Un ejemplo
Supongamos que la orden de compra solicita que los propietarios de viviendas proporcionen el rango de fechas de cuánto tiempo vivieron en su casa anterior.
Antes de llevar el PBI a su sprint, se le aclara que esto solo debe cubrir rangos de fechas en el pasado y que debe haber una fecha de finalización, ya que se trata de la casa en la que no viven actualmente (¡buen trabajo!).
Después de comenzar, solicita y verifica que el rango de fechas debe incluir las fechas seleccionadas (inclusive). El PO responde de inmediato.
Cuando casi ha terminado, se da cuenta de que su solución no permite intervalos de un día. El PO está enfermo, por lo que toma la decisión de seguir con su solución actual, ya que vivir en una casa por un solo día parece muy poco probable.
En la Revisión del Sprint, señala que los intervalos de fechas deben ser de dos días o más. El PO admite que tenía una suposición razonable, pero que hay numerosos ejemplos de residencia de un solo día en el sistema heredado, por lo que quiere asegurarse de que el nuevo sistema también pueda manejar esto. La orden de compra crea un nuevo PBI para permitir que los propietarios de viviendas ingresen rangos de fechas de un solo día y lo mueve a la parte superior de la cartera de pedidos.
¡Buen trabajo por todos lados!
Construyes en base a lo que se sabe en ese momento. Cuando se descubre algo durante el desarrollo, puede pasar a otra discusión del "paso 2".
Si el equipo o el gerente de producto quieren que la especificación esté completa antes de que comience el trabajo y los cambios no son aceptables, entonces la pregunta es si no está haciendo un desarrollo de software ágil o no.
Revise el Manifiesto para el desarrollo ágil de software: http://www.agilemanifesto.org/ Los cuatro valores y los doce principios son poderosos.
tienes razón, siempre es una decisión situacional. Cuanto mejor sepa lo que el cliente necesita recibir del proyecto/fase/sprint, podrá comenzar a aprender como equipo dónde, dentro de la aplicación, usted, como equipo, obtiene valor.
Espero que esto ayude.
Totalmente de acuerdo con @Barnaby Golden
Estos son los desafíos para los que está Agile. Siempre es difícil para un equipo hacer la transición y, en particular, cuando se consulta a clientes externos.
La clave aquí es el entrenamiento. Invierta en capacitación de calidad para todo el equipo e incluya también a los equipos de BA y de ventas para que todo se entienda y se transmita al cliente.
pato de goma
Garmanarnar