¿Cómo manejar los requisitos con un alcance poco claro que contienen palabras «todos», «en todas partes», etc.?

Negociar.

Hable con quien se le ocurrió el requisito. Explique la situación y los desafíos involucrados. Puede ser que el resultado sea un cambio en la definición del requisito, o tal vez estén de acuerdo en que primero se debe realizar una investigación para obtener una estimación más confiable.

Todos los requisitos deben ser negociables. Esto es importante cuando desea seguir un enfoque ágil y colaborar.

También es por eso que el mnemotécnico INVEST incluye N para negociable.

Interesante pregunta.

Para mí, planificaría el trabajo de esta manera:

0. Comunique al solicitante del cambio que los cambios que no se especifican completamente darán como resultado un plan que tiene una gama más amplia de estimaciones. (aparte: esto es un sofisma; todos los planes son estimaciones basadas en rangos. Los valores en un plan, no modificados por un rango, se conocen con el término técnico de gestión de proyectos "ficción"; los planes honestos se basan en una estimación y un rango alrededor de esa estimación. Cuanto más vaga sea la especificación de la tarea, más amplio será el rango de estimación)

1. Catalogue las instancias de 'término antiguo' en la base de código existente. Comience con una búsqueda simple del código base, pero almacene la respuesta en un repositorio acordado . (Esta debería ser una tarea que es relativamente simple de estimar, en el entendimiento de que el primer borrador del catálogo no tendrá más del 80% de precisión)

2. Calcule el tiempo para cambiar todas las instancias de 'término antiguo' a 'término nuevo' según el catálogo.

3. Realice la actualización en base a la estimación en 2.

4. Como parte normal de "pulir el trabajo pendiente" (no especifica scrum, por lo que estoy usando el término libremente, sin importar su metodología, hay una lista de trabajo que está "en el trabajo pendiente"), actualice el catálogo de 'antiguo término'. Esto también debería ser parte del mantenimiento del código: cuando esté trabajando en un error y encuentre una instancia de 'término anterior', actualice el catálogo. Cuando tenga un momento de inactividad y no pueda enfrentar la perspectiva de otra tarea centrada en el cliente, intente actualizar el catálogo. Cuando tenga un miembro del personal junior/nuevo que necesite una tarea que lo ayude a familiarizarse con el código base, actualice el catálogo. Si el catálogo cambia de tamaño significativamente, actualice la estimación en 2.

5. ¿Por qué su base de código no contiene ya una lista de referencias cruzadas de funciones/términos/variables/puntos de entrada? Agregue a la acumulación el esfuerzo requerido para expandir el catálogo a un índice completo de su base de código. Esta inversión dará sus frutos al acelerar los cambios futuros, reducir el diagnóstico de errores, mejores estimaciones, etc.

Antes de que el equipo calcule esto, hay que hacer algunos ajustes. Alguien, quizás varias personas, del equipo deberían tomarse el tiempo para comprender e investigar este trabajo para ver cuál es el alcance. Pueden identificar las secciones específicas del sistema que deben actualizarse y anotarlas. El refinamiento y la identificación de las partes afectadas del sistema pueden ayudar al equipo a estimar el trabajo. Esta investigación también puede encontrar formas de dividir el trabajo de una manera que tenga sentido para entregar de forma incremental.

En algunos casos, el cambio puede ser extremadamente urgente. En ese caso, puede valer la pena el riesgo de simplemente hacer el trabajo hasta que esté hecho. Puede que no valga la pena estimar el trabajo, sino simplemente comenzar a hacerlo. Sin embargo, siempre existe el riesgo de que suceda algo inesperado y el trabajo no esté completo. Si ese es un riesgo aceptable, se pueden realizar cambios adicionales como trabajo de seguimiento más adelante después de la entrega inicial.

Hay dos formas de hacerlo, a la derecha;

1. Haga un descubrimiento para encontrar cada pieza de código que necesita ser cambiada y agréguela a la tarea
2. Ve a ciegas e intenta hacerlo

Calcule cuál tomará menos tiempo y comunique su recomendación con el cliente de acuerdo con la prioridad del cliente; esfuerzos vs. calidad del resultado. Por ejemplo, "Si hacemos el descubrimiento, los esfuerzos serán demasiado altos. Empecemos a hacer los cambios sin descubrir; costará menos. Pero, si nos faltan algunas partes, las encontraremos en producción e intentaremos arreglarlas lo antes posible". ."

La definición de "todos" es bastante clara y explícita. Los peores infractores son: "adecuado", "buena calidad", "demasiado alto". Son términos medios, sin referencia numérica/medible.

Entonces, cuando reciba una solicitud con "todos", debe hacer lo siguiente (junto con su equipo).

1. Realice una búsqueda automática en todos los productos de trabajo para encontrar "todas" las ocurrencias de la palabra relevante (por ejemplo, "término", botón rojo, verde...) y haga una lista clara. No olvide buscar todas las formas de palabras, solo para estar seguro. Esperemos que hagas el trabajo usando algunas herramientas adecuadas. Si su información está en imágenes de pizarras blancas usadas, entonces le deseo mucha suerte.
2. Agrúpelos en función de lo claro que le resulte manejarlos. Ejemplo: debería-modificar, tal vez-modificar, no-modificar, no-tenemos-idea.
3. Presentar la lista al cliente, para dar su visto bueno.
4. Aclarar todos los detalles con el cliente, tomar decisiones juntos.
5. Implementar las decisiones.
6. Una vez finalizado el trabajo, si el cliente encuentra problemas no identificados inicialmente, maneje cada solicitud una por una.

Eso es gestión básica de proyectos e ingeniería básica de requisitos.

Elija algún subconjunto de "todos" que pueda estimar con sensatez, cree una nueva historia para él y priorice esa historia antes que el resto. Con suerte, hacer el trabajo en el alcance reducido le dará al equipo una mejor visión del trabajo más grande.

Alternativamente, dado que dice que la tarea es "bastante pequeña" si se conoce el alcance, tal vez sea lo suficientemente pequeño como para que pueda asumir un riesgo calculado de que podría realizarse en una iteración y ver hasta dónde puede llegar el equipo. Lo importante no es la estimación, sino el grado de confianza que tiene el equipo de que se puede completar en una sola iteración.