Scrum / Agile: ¿Cómo planeas mejoras internas? [cerrado]

Question

Ahora he trabajado en dos equipos diferentes que utilizan el enfoque Agile / Scrum en los últimos dos años y ambos equipos estaban ansiosos por mejorar la forma en que abordan el desarrollo de software. En el primer equipo, podríamos convencer fácilmente a nuestro propietario del producto para que tenga tiempo para cosas internas como mejorar el sistema de compilación, establecer mejores pruebas de integración, tener una mejor estrategia de lanzamiento, etc. En este momento, la OP también está dispuesta a darnos tiempo, pero Él está más deprimido, lo cual es razonable, ya que también debe hacer sus cosas.

De todos modos, mi pregunta es ahora, ¿cómo manejan esto los otros equipos? ¿Crea una historia de mejora y la pone sobre la mesa durante la planificación o mantiene un " cubo " de tiempo para esas cosas? ¿Qué tan difícil es su experiencia para convencer al propietario del producto para que obtenga tiempo para mejorar? Después de todo, este tipo de mejoras beneficiarán al equipo, pero no directamente o inmediatamente al propietario / negocio de prodcut.

Answer 1

Gran pregunta. Creo que hay varios sabores de "elementos de acción". de retrospectivas que merecen diferentes enfoques.

1) tareas técnicas para abordar aspectos como la deuda técnica o las mejoras de infraestructura, como '' Debemos asegurarnos de que no tengamos llamadas a la base de datos en la capa de vista de nuestra aplicación, porque eso nos hizo perder el tiempo en esta última iteración ... alguien debería hacer una búsqueda a través del código para asegurarse de que no lo haremos en otro lugar. "

2) mejoras en el proceso (por ejemplo, " la gente no llega a tiempo a pie ... comencemos con un $ 1 para donaciones de caridad cuando alguien llegue tarde " ;.)

La primera categoría puede ser un trabajo significativo, o puede ser sencillo. El ejemplo que mostré fue bastante fácil ... pero podría generar otras tareas que deben programarse (por ejemplo, eliminando las llamadas de la base de datos en las 5 ubicaciones donde se descubrieron).

La segunda categoría debe ser manejada / impulsada por el administrador de iteraciones, el administrador de proyectos, el administrador de scrum, etc. Yo (como Scrum Master o Project Manager) generalmente los incluyo en una wiki del proyecto y hablo de ellos en retrospectivas, verifíquelos apagado cuando se abordan, e informar al equipo sobre el estado. Mantengo el fuego encendido.

Creo que el error en la primera categoría, tareas técnicas, es que no definimos los criterios de aceptación. Sus ejemplos incluyeron "mejorar el sistema de compilación, configurar mejores pruebas de integración, tener una mejor estrategia de lanzamiento". Estos no son deterministas y deben ser enumerados en términos claros (usando picos si es necesario). Por lo tanto, mejorar el sistema de compilación podría comenzar con una tarea técnica o un pico para evaluar las opciones.

También necesitamos desglosar y priorizar las tareas técnicas (por ejemplo, tal vez " mejores pruebas de integración " podrían comenzar con una tarea técnica de definir la cobertura de integración actual, o evaluar el porcentaje de errores que podrían atribuirse a fallas de integración a construir el caso para la inversión allí.

Una vez que haya establecido sus prioridades, puede transmitir el valor de los elementos de alta prioridad y negociar con el propietario del producto el tiempo que debe dedicar a ellos. No soy un gran fanático de los compartimientos predefinidos para gastar en nada ... pero tener una conversación con el propietario del producto con requisitos precisos, ROI y criterios de aceptación es clave.

Answer 2

Las mejoras deberían ser parte del sprint de la misma manera que las nuevas características. Depende del equipo demostrarle al propietario del producto que esas mejoras son necesarias para el próximo sprint. Esto puede disminuir la velocidad a la que se producen las nuevas características, pero es útil para el producto al final.

Por otro lado, tengo problemas con los sprints que solo contienen mejoras. Cada sprint debe producir un resultado que se pueda demostrar al propietario del producto.

Answer 3

Métodos de cristal tiene el concepto del Taller de reflexión como un medio para afina tu proceso de desarrollo. Los equipos se reúnen periódicamente (quizás con menos frecuencia que su ciclo de desarrollo) para discutir las mejoras y el estado del proceso. Piense en 0-3 cosas que probamos esta vez que funcionaron y mantendremos, 1-3 cosas que no funcionan, y 1-3 cosas para probar la próxima vez. La idea es tener una mejora incremental tanto en el proceso como en el producto.

Answer 4

El año pasado trabajé para uno de los primeros adoptadores / consultores / formadores de Agile (xp). Tenía un buen enfoque, creo.

Nos reunimos todos los viernes y discutimos qué funcionaba y qué no. Los escribiríamos en dos grandes trozos de papel (estaba realmente en el papel y el caballete en lugar de la pizarra porque era más permanente y podía reposicionarse más fácilmente).

Las cosas que funcionaron podrían ser muy simples: interactuamos bien como equipo, el emparejamiento se realizó sin problemas, etc.

Las cosas que no funcionaron fueron tan simples y aleatorias. Algunas personas podrían resistirse a pelar, o incluso "El jefe no nos llevó en su bote como se prometió".

Cada semana también volvemos a visitar el pasado "No funcionó" y ver si los arreglamos: si es así, siempre aparecerían en esta lista "funcionó". columna.

Aunque discutiríamos soluciones específicas, solo sacar a la luz los problemas al aire libre tendió a tener un efecto muy positivo. Si permanecieron en el "No funcionó" durante 3 o 4 semanas, discutiremos diferentes / mejores soluciones y haremos un intento más deliberado de implementarlas.

Después de que un artículo pase una o dos semanas en el " Funcionó bien " columna, lo dejaríamos caer ya que más o menos se había esperado (a menos que continuara mejorando).

También hizo que los viernes por la tarde fueran un poco más interesantes, ya que era una reunión bastante divertida en la que todos podían participar.

Answer 5

Yo usaría un 'pico' para tales cosas. Una mejora interna / de proceso no podría ser una historia de usuario, pero sería un pico perfecto.

Answer 6

No tengo mucho que agregar aquí, sin embargo, creo que uno debe tener un recurso dedicado a estos problemas relacionados con la mejora del entorno y las tareas no deben incluirse en los gráficos de quema. Si se requiere un hardware adicional para este proyecto, entonces debería haberse agregado y presupuestado por adelantado. Así que, en última instancia, estos no deberían afectar la asignación de horas en el scrum, sin embargo, cualquier trabajo afectado como resultado de este problema debe justificarse.

Answer 7

No, uno no creará historias técnicas de usuario: en teoría, y dado que generalmente no aportan un valor directo al cliente, tienen muy pocas posibilidades de ser seleccionados en una iteración. Convencer al propietario del producto es una opción para aliviar esto, pero hay otra herramienta que se puede usar aquí: holgura.

Slack es una parte pequeña de su tiempo de iteración reservado para esas tareas de mejoras. Si todo salió bien durante la iteración, podrá usar ese tiempo para esas mejoras. Por otro lado, tendrá otra oportunidad de cumplir con sus compromisos en caso de que el equipo se haya comprometido en exceso para la iteración (o se haya subestimado una tarea, más difícil de lo esperado ...)

Otro beneficio del uso de holgura es que esto reducirá la variación de la velocidad, ya que es probable que cumpla con sus compromisos más a menudo, sin recurrir a las horas extraordinarias.

Consulte Tom DeMarco Slack: Pasando el agotamiento, el trabajo ocupado y el mito del total Eficiencia (enlace de Amazon) - ISBN 0767907698.