¿Cómo manejas los costos de un cambio demasiado rápido?

Como la mayoría de los desarrolladores modernos, valoro los principios ágiles, como la colaboración con el cliente y la respuesta al cambio, pero ¿qué sucede cuando un propietario del producto (o quien determina los requisitos y prioridades) cambia los requisitos y prioridades con demasiada frecuencia? ¿Como varias veces al día?

Recientemente heredé una base de código pequeña que tenía errores, estaba incompleta y ni siquiera podía manejar el escenario más simple que se suponía. Puedo ocuparme de los problemas técnicos, pero recibo varios correos electrónicos, mensajes de texto o llamadas telefónicas al día que dicen "¡OMG, DEBES trabajar en esto AHORA MISMO! ¡PRIORIDAD SUPERIOR! ¡Esto es IMPRESCINDIBLE!" Lo que lo hace aún peor es que la mayoría de las cosas son detalles menores que ni siquiera son relevantes para lo que se supone que debe hacer el software y de todos modos tomaría días implementarlo. He intentado explicar que solo hay mucho tiempo y que debemos centrarnos en las cosas más importantes primero, pero algo parece perderse en la traducción porque lo mismo sucede uno o dos días después.

¿Existe algún tipo de rol, Estudio en profundidad, metáfora o cita de Product-Owner-Handler que pueda ayudarme a reducir la cantidad de esfuerzo desperdiciado o al menos explicar los costos de este comportamiento caótico?

Para eso está la cartera de pedidos. Las nuevas solicitudes se colocan en la cartera de pedidos, y las prioridades solo pueden cambiar en los límites de iteración. Un retraso promedio de una semana (la mitad de un sprint de dos semanas) es lo suficientemente ágil como para manejar todas las emergencias menos las más graves.

Así es como me ocupé de un problema similar. En los días en que éramos ágiles antes de Agile.

Para cualquier solicitud de cambio, el cliente establece la prioridad. El desarrollador solo puede, y debe, dejar de trabajar en una tarea para trabajar en una tarea de mayor prioridad. Las tareas de igual prioridad son los horarios en orden de llegada. (La prioridad de la tarea no se puede cambiar una vez que el trabajo ha comenzado).

Le dolerá cuando le diga al cliente que no puede trabajar en su tarea porque está trabajando en una tarea X sin importancia que tiene la misma prioridad que su última solicitud. Luego le dice que en ese nivel de prioridad hay 50 tareas triviales y sin importancia antes de su última solicitud. Ahora el verdadero truco: todas estas tareas están en el nivel de prioridad 1 (el más alto), establecido por ... ÉL ... Así que no puede impedirte la tarea que estás haciendo. Ahora, cuando haya terminado de mover el marco de la ventana 3 píxeles hacia la izquierda para dejar espacio para la palabra más larga en la traducción al islandés en la opción de configuración raramente utilizada .....

También cierro la puerta de la oficina de SD, la cerré con llave y descolgué los teléfonos. Los correos electrónicos fueron ignorados hasta las 10AM, 12PM y 2PM. A pesar de lo que la gente pensaba y sentía, el mundo seguía dando vueltas al sol, hicimos nuestro trabajo y los "Clientes" recibieron el software más rápido y mejor que nunca.

Las prioridades tardaron algunas semanas en establecerse en algo más realista, pudimos abrir la puerta, etc. Pero el sistema permaneció durante bastante tiempo. Es posible que no necesite ser tan extremo (lo hicimos), y necesitará el apoyo de la alta gerencia. Pero funcionará ...

COMPENSACIÓN. Procedimiento operativo estándar (o al menos un protocolo suelto firmado por su equipo de gestión). Su departamento necesita desarrollar uno o trabajar con su equipo administrativo para desarrollar uno. Las personas con las que necesita hablar están por encima del propietario del producto / gerente de cuenta.

Algunos ejemplos de lo que debe definir su SOP.

• Qué procedimientos se deben seguir cuando un cliente o entidad interna solicita un cambio
• ¿Cuáles son las implicaciones y / o impacto en el control de calidad o verificación de este producto?
• ¿Cuál es el método para determinar razonablemente un plazo de entrega? Esta iteración? Próxima versión?

Sin dichos procedimientos, todos correrán hacia ti como si estuvieran siendo perseguidos por zombis y esperarán todo AHORA AHORA AHORA. La gente así no respetará su cortés 'no' o 'por favor espere'. Con una política firme en el lugar, estos mutantes que anhelan el código comprenderán que están equivocados al pedir cosas de manera tan flexible.

El resultado final no le satisface, y eso no es lo mejor para su empresa.

En una nota al margen, es posible que haya heredado el desorden de alguien causado por una falta de respeto tan flagrante por su posición y deber. Las personas en esa situación tienden a tener dificultades para producir productos de calidad. ¿Es de extrañar? Ingeniería de software 101.

Es muy difícil trabajar en estas condiciones de "listo, disparar, apuntar". Me parece que está recibiendo requisitos de una persona muy insegura, cuya opinión cambia cada vez que una persona superior sugiere una idea conceptual.

En este tipo de situaciones, he encontrado valioso esperar AL MENOS una hora antes de responder a los correos electrónicos. (Ignoraría los mensajes de texto, a menos que los mensajes de texto hayan reemplazado ampliamente el correo electrónico de toda su organización). Léalos, tal vez, pero no responda. De esta manera, puede pasar su tiempo enfocándose en el trabajo real que necesita hacer, no en la discusión de urgencias aleatorias que pueden volverse irrelevantes mañana, o incluso dos o tres correos electrónicos más tarde. En mi último trabajo, si algo era REALMENTE urgente, alguien vendría a hablar conmigo en persona, suponiendo que aún no hubiera visto los correos electrónicos (si trabajas de forma remota, una llamada telefónica con una conversación real de dos vías puede ser equivalente).

Cuando tiene una conversación cara a cara o telefónica, es útil repetir lo que la persona está pidiendo en sus propias palabras, y luego hacer sus preguntas sobre los nuevos requisitos y prioridades. "Si entiendo correctamente, está diciendo que deberíamos dejar de trabajar en la prioridad X actual y ahora centrarnos en la prioridad del minuto Y. Ese es un gran cambio. ¿Puede explicar el cambio en el negocio? Puede que necesite hacer más antecedentes funciona más que simplemente cambiar la interfaz de usuario. ¿Habrá cambios en otros procesos comerciales, como la facturación o el inventario (por ejemplo)? ¿Va a esperar que estos nuevos elementos de datos aparezcan en todos los informes mensuales? " También es útil decir algo en el sentido de "Usted comprende que si continuamos con este nuevo esfuerzo, retrasará el lanzamiento de la Prioridad actual actual X al menos un (semana, mes,

Si se trata de una emergencia real, el solicitante debe poder responder a este tipo de preguntas o remitirlo inmediatamente a alguien que pueda hacerlo. Si no es una emergencia real, este tipo de conversación obligará al solicitante a reducir la velocidad y determinar qué tan importante es realmente el cambio, dado que necesitan obtener más información. A menudo verán que lo que ya está en la tubería es más importante, o al menos no vale la pena detenerse, y la nueva solicitud puede ir a la lista.

Si se determina que los cambios son necesarios, me parece útil escribir lo que se solicitó y su comprensión de los cambios en un correo electrónico, y enviarlo al solicitante original, preguntándoles si están de acuerdo con el alcance del cambio, de nuevo, como aclaración. De esta manera, tiene documentación escrita de lo que debe hacerse y por qué se solicitó, en caso de que haya un retroceso en el motivo por el cual ya no está trabajando en la Prioridad X actual, o si necesita explicar por qué no se cumplen los plazos originales. ser reunidos.

Con suerte, esto debería mejorar su relación con el solicitante, ya que está demostrando su conocimiento y asegurándose de que está trabajando en lo que quiere, pero está siendo honesto acerca de lo que se necesita para hacer cambios. Al preguntar sobre la solicitud en detalle, ven que piensas con anticipación y consideran cosas que podrían no haber tenido originalmente.

Parece que nadie lo mencionó todavía, Sprint y sus historias de usuario ideally should be locked till the next sprint(el sprint típico demora de 2 a 4 semanas). Al bloquear, quiero decir que no se deben agregar tareas adicionales en Sprint ya iniciado.

Si la historia del usuario es lo suficientemente grande como para no ajustarse al sprint, fíjela a tareas más pequeñas y alcanzables durante el sprint. Además, como se mencionó, incluso las tareas priorizadas deben mantenerse en la cartera de pedidos , y durante la próxima planificación de sprint, una alta prioridad una vez que se active la bandera :)

Editar: solo se pueden introducir cambios menores durante la primavera. si llevan estado de emergencia. Sin embargo, si siempre hay un par de emergencias durante el sprint, entonces algo debe ser cambios en la planificación de Sprint.

Scrum tiene el rol de Scrum Master, que sería la persona que debería abordar los problemas que mencionó.

Si hay alguien como un líder de equipo, gerente de proyecto, scrum master, etc., que es responsable, hablaría con esa persona.

He intentado explicar que solo hay mucho tiempo y que primero debemos centrarnos en las cosas más importantes, pero parece que algo se pierde en la traducción porque lo mismo sucede uno o dos días después.

Creo que tendrá que seguir explicándolo una y otra vez. Parece que es posible que deba aceptar que ciertas personas con las que trabaja tienen hábitos inútiles. Si tienes suerte, verás un cambio eventualmente.

El Manifiesto Ágil dice que uno de los principios más fundamentales es:

Bienvenido a los requisitos cambiantes, incluso al final del desarrollo Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.

Sin embargo, no creo que signifiquen un cambio diario. Es posible que deba cambiar el precio base de un producto muchas veces al día, pero no cambiar la forma en que ese producto podría venderse muchas veces al día. Más bien, el flujo de trabajo de las ventas de un producto puede cambiar semanalmente (en negocios dinámicos y altamente receptivos).

Nuevamente, si bien el flujo de trabajo de las ventas de un producto puede cambiar cada semana, creo que el producto general no cambiará cada semana. No puedo imaginar un Microsoft que hoy nos dé Office, pero mañana nos dará Offooose, y una semana después Offasooooooooooos.

No, eso no es lo que ágil quiere decir con cambio. Creo que proviene de malas visiones y de una gran incomprensión profunda del concepto de cambio.

Y mucho menos mencionar que el cambio no es bienvenido en un sprint, donde los desarrolladores van a sus cuevas y necesitan concentrarse en lo que están haciendo. Por el contrario, los cambios deben agregarse a la cartera de productos y analizarse y priorizarse antes de que se entreguen a las manos del equipo scrum. En otras palabras, un Backlog de Sprint no es inmutable. Se debe buscar una mayor agilidad utilizando sprints más cortos, no inyectando directamente en las salas de desarrolladores, muchas veces al día.