Tengo dos preguntas relacionadas con Scrum.

Nuestra compañía está intentando implementarlo y está segura de que estamos saltando por encima de los aros.

Ambas preguntas son sobre "hecho significa hecho!"

1) Es realmente fácil definir "Hecho" para las tareas que tienen / tienen - criterios claros de aceptación de prueba - completamente independientes - probados al final por los evaluadores

Qué se debe hacer con tareas como: - diseño de arquitectura - refactorización - desarrollo de algunas clases de utilidad

El problema principal es que es una entidad casi completamente interna y no hay manera de verificarla / probarla desde afuera.

Como ejemplo, la implementación de funciones es un tipo binario: se realiza (y pasa todos los casos de prueba) o no se hace (no se pasan algunos casos de prueba).

Lo mejor que me viene a la cabeza es pedirle a otro desarrollador que revise esa tarea. Sin embargo, de cualquier manera no proporciona una manera clara de determinar si está completamente hecho o no.

Entonces, la pregunta es ¿cómo define "Hecho" para tales tareas internas?

2) Debug / bugfix task

Sé que la metodología ágil no recomienda tener grandes tareas. Al menos si la tarea es grande, debe dividirse en tareas más pequeñas.

Digamos que tenemos un problema bastante grande, un gran rediseño de módulos (para reemplazar la arquitectura obsoleta por una nueva). Claro, esta tarea se divide en docenas de tareas pequeñas. Sin embargo, sé que al final tendremos una sesión bastante larga de debug / fix.

Sé que ese suele ser el problema del modelo de cascada. Sin embargo, creo que es difícil deshacerse de él (especialmente por cambios bastante grandes).

¿Debo asignar tareas especiales para las integraciones de depuración / reparación / sistema y etc.?

En el caso, si lo hago, generalmente esta tarea es enorme en comparación con todo lo demás y es difícil dividirla en tareas más pequeñas.

No me gusta de esta manera, debido a esta enorme tarea monolítica.

Hay otra manera. Puedo crear tareas más pequeñas (asociadas a errores), ponerlas en el registro, establecer prioridades y agregarlas a las iteraciones al final de la actividad, cuando sabré cuáles son los errores.

No me gusta de esta manera, porque en tal caso toda la estimación se volverá falsa. Estimamos la tarea, la marcamos pedir completa en cualquier momento. Y abriremos las nuevas tareas para errores con nuevas estimaciones. Entonces, terminaremos con el tiempo real = tiempo estimado, que definitivamente no es bueno.

¿Cómo resuelves este problema?

Saludos, Victor