Dos preguntas sobre Scrum

Question

Tengo dos preguntas relacionadas con Scrum.

Nuestra empresa está tratando de implementarlo y seguro que estamos saltando por encima de los aros.

Ambas preguntas son sobre "hecho significa hecho!"

1) Es muy fácil de definir en "Done" para las tareas que son/tienen - la aceptación de pruebas claras criterios - completamente independiente - probado al final por los probadores

Lo que se debe hacer con tareas como: diseño de la arquitectura - - refactorización - un cierto desarrollo clases de utilidad

El principal problema con él, que es casi completamente entidad interna y no hay manera de verificar/probar desde fuera.

Como ejemplo, la implementación de funciones es un tipo de binario; está hecho (y pasa todos los casos de prueba) o no está hecho (no pase algunos casos de prueba).

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

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

2) Depuración/tarea de corrección de errores

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: algunos grandes rediseños del módulo (a reemplazar la nueva arquitectura de salida con una nueva). Claro, esta tarea se divide en docenas de pequeñas tareas. Sin embargo, sé que al final tendremos bastante larga sesión de depuración/corrección.

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

¿Debo asignar tarea especial para las integraciones de depuración/corrección/sistema y etc.?

En el caso, si lo hago, generalmente esta tarea es simplemente enorme en comparación con todo lo demás y es algo difícil de dividir 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 con errores), ponerlos en la lista de espera, priorizar y agregarlos a las iteraciones al final de actividad, cuando sabré cuáles son los errores.

No me gusta de esta manera, porque en tal caso toda la estimación se convertirá en falso . Estimamos la tarea, la marcamos pregunta completa en cualquier momento. Y vamos a abrir las nuevas tareas para errores con nuevas estimaciones.Por lo tanto, terminaremos con tiempo real = tiempo estimado, que definitivamente no es bueno.

¿Cómo resuelves este problema?

Saludos, Victor

Answer 1

Para la primera parte "diseño de la arquitectura - refactorización - algunas clases de utilidad de desarrollo" Estas nunca se "hacen" porque las haces a medida que avanza. En pedazos.

Usted quiere hacer la arquitectura suficiente para lanzar la primera versión. Luego, para el próximo lanzamiento, un poco más de arquitectura.

La refactorización es la forma de encontrar las clases de utilidad (no se establece para crear clases de utilidad, las descubre durante la refactorización).

La refabricación es algo que se hace en piezas, según sea necesario, antes de su lanzamiento. O como parte de una gran pieza de funcionalidad. O cuando tiene problemas para escribir una prueba. O cuando tiene problemas para pasar una prueba y necesita "depurar".

Pequeñas piezas de estas cosas se realizan una y otra vez a lo largo de la vida del proyecto. En realidad, no son "candidatos de lanzamiento", por lo que solo son sprints (o partes de sprints) que se realizan en el proceso de lanzamiento.

Answer 2

"¿Debo asignar una tarea especial para las integraciones de depuración/corrección/sistema, etc.?"

No es lo mismo que hizo con una metodología de cascada en la que nada funcionaba realmente.

Recuerde, está creando y probando de forma incremental. Cada sprint se prueba y depura por separado.

Cuando llegue a un candidato de publicación, es posible que desee hacer algunas pruebas adicionales en esa versión. Las pruebas conducen al descubrimiento de errores que lleva a la acumulación. Por lo general, se trata de una acumulación de alta prioridad que debe corregirse antes del lanzamiento.

Algunas veces, las pruebas de integración revelan errores que se convierten en una acumulación de baja prioridad que no necesita ser reparada antes de la próxima versión.

¿Qué tan grande es esa prueba de lanzamiento? No muy. Ya has probado cada sprint ... Hay que no debería ser demasiadas sorpresas.

Answer 3

Argumentaría que si una actividad interna tiene un beneficio para la aplicación (que deben tener todos los elementos atrasados ​​dentro del scrum), se realiza el beneficio. Por ejemplo, "Arquitectura de diseño" es demasiado genérica para identificar el beneficio de una actividad. "Arquitectura de diseño para la historia de usuario A" identifica el alcance de su actividad. Cuando haya creado una arquitectura para la historia A, habrá terminado con esa tarea.

La refabricación también debe hacerse en el contexto de lograr una historia de usuario. "Refactor Customer class para permitir que varios números de teléfono admitan Story B" es algo que se puede identificar como hecho cuando la clase Customer admite varios números de teléfono.

Answer 4

Tercera pregunta "un gran rediseño del módulo (para reemplazar la nueva arquitectura de actualización con una nueva). Claro, esta tarea se divide en docenas de pequeñas tareas. Sin embargo, sé que al final tendremos sesiones de depuración bastante largas /fijar."

Cada sprint crea algo que puede liberarse. Tal vez no sea así, pero podría ser.

Por lo tanto, cuando tiene un rediseño importante, tiene que comer el elefante una pieza pequeña a la vez. En primer lugar, observe el valor más alto, lo más importante, el mayor rendimiento para los usuarios que puede hacer, completar y liberar.

Pero, usted dice, no existe una pieza tan pequeña; cada pieza requiere un rediseño masivo antes de poder lanzar cualquier cosa.

No estoy de acuerdo. Creo que puedes crear una arquitectura conceptual, lo que será cuando hayas terminado, pero no implementar todo de una vez. En cambio, usted crea interfaces temporales, puentes, pegamento, conectores que harán un sprint.

Luego modifica las interfaces temporales, los puentes y el pegamento para que pueda finalizar el siguiente sprint.

Sí, ha agregado un código. Pero, también has creado sprints que puedes probar y lanzar. Los sprints que están completos y cualquiera puede ser una versión candidata.

Answer 5

Parece que está borrando la definición de historia y tarea del usuario. Simplemente:

• Historias de usuario agregar valor. Son creados por el propietario de un producto.

• Las tareas son actividades realizadas para crear ese valor . Fueron creados por los ingenieros .

clavasteis partes clave de la historia de usuario diciendo que deben tener claros los criterios de aceptación, que son independientes y que pueden ser probados.

Arquitectura, diseño, refactorización y desarrollo de clases de utilidad son tareas. Son lo que se hace para completar una historia de usuario. Depende de cada tienda de desarrollo establecer diferentes estándares para estos, pero en nuestra empresa, al menos otro desarrollador debe haber examinado el código (programación de pares, lectura de códigos, revisión de códigos).

Si tiene historias de usuario que son "clase de refactor X" y "característica de diseño Y", está en la pista incorrecta. Puede ser necesario refactorizar X o diseñar Y antes de escribir el código, pero esas podrían ser las tareas necesarias para cumplir la historia del usuario "crear un nuevo widget de inicio de sesión".

Answer 6

Nos hemos encontrado con problemas similares con el código "entre bastidores". Por "detrás de escena" quiero decir, no tiene valor comercial aparente o comprobable.

En esos casos, hemos decidido definir que los desarrolladores de esa parte del código eran los verdaderos "usuarios". Al crear aplicaciones de muestra y documentación que los desarrolladores podían usar y probar, teníamos algún código "hecho".

Por lo general, con scrum, usted estaría buscando una funcionalidad empresarial que utilizara un fragmento de código para determinar "hecho".

Answer 7

Para tareas técnicas como la refactorización, puede verificar si la refactorización realmente se realizó, p. call X ya no tiene ningún método f(), o no tiene más función foobar().

Debe haber confianza hacia el equipo y dentro del equipo también. ¿Por qué quieres revisar si la tarea está realmente hecha? ¿Encontraste situaciones en las que alguien afirma que se hizo una tarea y no fue así?

---

Para su segunda pregunta, primero debe esforzarse realmente por dividirla en varias historias más pequeñas (elementos atrasados). Por ejemplo, si está rediseñando el sistema, vea si la arquitectura nueva y la anterior pueden coexistir con el tiempo para hacer la portación de todos sus componentes de uno a otro.

Si esto es realmente no es posible, entonces esto se hace por separado del resto de los elementos del backlog del sprint, y no integrado antes de que sea "hecho, hecho". Si el sprint finaliza antes de la finalización de todas las tareas del elemento, debe estimar la cantidad restante de trabajo y volver a planificarla para la siguiente iteración.

Aquí están twenty ways to split a story que podrían ayudar a tener varios artículos más pequeños atrasados, con la manera más segura y recomendada.