continuous-integration - scaled - deployment continuo
Scrum/Agile: ¿Cómo planeas mejoras internas? (7)
El año pasado trabajé para uno de los primeros adoptantes / consultores / entrenadores de Agile (xp). Tenía un buen enfoque, creo.
Nos reuníamos todos los viernes y solo discutíamos qué funcionaba y qué no. Los escribiríamos en dos pedazos grandes de papel (Él estaba realmente interesado 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 desarrolló sin problemas, etc.
Las cosas que no funcionaron fueron igual de simples y aleatorias. Algunas personas podrían resistirse a pelar, o incluso "El jefe no nos llevó a su barco como se había prometido".
Todas las semanas revisábamos el pasado "No funcionó" y miramos si lo solucionamos. De ser así, siempre aparecerían en la columna "sí funcionó" de esta semana.
A pesar de que discutiríamos soluciones específicas, simplemente presentar los problemas al aire libre tendía a tener un efecto muy positivo. Si permanecían en la lista "No funcionó" durante 3 o 4 semanas, debatiríamos sobre soluciones diferentes / mejores y haríamos un intento deliberado de implementarlas.
Después de que un elemento pasa una semana o dos en la columna "Trabajó bien", lo descartamos, ya que más o menos se esperaba (a menos que siguiera mejorando).
También hizo que los viernes por la tarde fueran un poco más interesantes ya que fue una reunión bastante divertida en la que todos podían participar.
Ahora he trabajado en dos equipos diferentes que usan 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, pudimos convencer fácilmente al propietario de nuestro producto de que tuviera 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, el PO también está dispuesto a darnos tiempo, pero él está presionando más, lo cual es razonable ya que también debe hacer sus cosas.
De todos modos, mi pregunta es ahora, ¿cómo otros equipos manejan esto? ¿Creas una historia de mejora y la pones sobre la mesa durante la planificación o mantienes un "cubo" de tiempo para esas cosas? ¿Qué tan difícil es en su experiencia convencer al propietario del producto para obtener tiempo para mejorar? Después de todo este tipo de mejoras, beneficiará al equipo, pero no directamente ni de inmediato al dueño / negocio de prodcut.
Las mejoras deben ser parte del sprint de la misma manera que las nuevas características. Depende del equipo demostrarle al Product Owner que esas mejoras son necesarias para el próximo sprint. Esto puede ralentizar la velocidad a la que se producen nuevas características, pero al final es útil para el producto.
Por otro lado, tengo problemas con los sprints que solo contienen mejoras. Cada sprint debe producir un resultado que pueda demostrarse al propietario del producto.
Usaría un ''pico'' para tales cosas. Una mejora interna / de proceso no podría ser una historia de usuario, pero sería un aumento perfecto.
Crystal Methods tiene el concepto del Taller de Reflexión como un medio para ajustar su proceso de desarrollo. Los equipos se reúnen periódicamente (con menos frecuencia que su ciclo de desarrollo, tal vez) para analizar las mejoras y el estado del proceso. Vamos con 0-3 cosas que probamos esta vez que funcionó y vamos a mantener, 1-3 cosas que no están funcionando, y 1-3 cosas que probar la próxima vez. La idea es tener una mejora incremental en el proceso y en el producto.
Gran pregunta Creo que hay varios sabores de "elementos de acción" de retrospectivas que merecen diferentes enfoques.
1) tareas técnicas para abordar cosas como la deuda técnica o mejoras de infraestructura, como "Debemos asegurarnos de no tener llamadas a la base de datos en la capa de visualización de nuestra aplicación, porque eso nos hizo perder el tiempo en esta iteración pasada ... alguien debería hacer una busca el código para asegurarte de que no estamos haciendo eso en otro lugar ".
2) mejoras en el proceso (por ej., "La gente no llega a tiempo a los standups ... empecemos a donar $ 1 para donaciones de caridad cuando alguien llega tarde").
La primera categoría puede ser un trabajo significativo, o podría ser sencillo. El ejemplo que mostré fue bastante fácil ... pero podría generar otras tareas que deben programarse (por ejemplo, eliminar las llamadas a la base de datos en las 5 ubicaciones donde fueron descubiertas).
La segunda categoría debe ser manejada / manejada por el gerente de iteración, gerente de proyecto, administrador de scrum, etc. Yo (como Scrum Master o Project Manager) generalmente los incluyo en una wiki de proyecto y hablo de ellos en retrospectivas, los marque cuando Hablemos e informemos al equipo sobre el estado. Mantengo el fuego encendido.
Creo que el error en la primera categoría, las tareas técnicas, es que no definimos los criterios de aceptación. Sus ejemplos incluyen "mejorar el sistema de compilación, configurar mejores pruebas de integración, tener una mejor estrategia de lanzamiento". Estos no son deterministas y deben enumerarse en términos claros (utilizando picos si es necesario). Entonces, mejorar el sistema de compilación podría comenzar con una tarea técnica o un aumento para evaluar las opciones.
También necesitamos desglosar y priorizar las tareas técnicas (por ejemplo, quizás "mejores pruebas de integración" podrían comenzar con una tarea técnica de definición de la cobertura de integración actual, o evaluar el porcentaje de errores que podrían atribuirse a errores de integración para construir el caso). 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 para gastar en ellos. No soy un gran admirador de los cubos predefinidos para gastar en nada ... pero tener la conversación con el propietario del producto con requisitos nítidos, ROI y criterios de aceptación es la clave.
No, no se deben crear historias técnicas de usuarios: teóricamente, y dado que generalmente no aportan un valor directo para el cliente, tienen muy pocas posibilidades de ser seleccionadas 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 pequeña parte del tiempo de iteración reservado para esas tareas de mejora. Si todo fue bien durante la iteración, entonces podrá usar ese tiempo para esas mejoras. Por otro lado, tendrá la oportunidad de cumplir sus compromisos en caso de que el equipo se haya comprometido demasiado para la iteración (o una tarea haya sido subestimada, más difícil de lo esperado ...)
Otro beneficio de usar holgura es que esto disminuirá la variación de la velocidad, ya que es probable que cumpla con sus compromisos más a menudo, sin recurrir a horas extras.
Consulte Tom DeMarco Slack: Getting Burnout, Busywork, and the Myth of Total Efficiency (Enlace Amazon) - ISBN 0767907698.
No tengo mucho que agregar aquí, sin embargo, creo que uno debe tener un recurso dedicado a estos problemas relacionados con la mejora del medio ambiente y las tareas no se deben incluir en los gráficos de reducción. Si se trata de un hardware adicional requerido para este proyecto, entonces debería haber sido agregado y presupuestado en avanzado. Por lo tanto, en última instancia, esto no debería afectar la asignación de horas en el scrum, sin embargo, cualquier trabajo afectado como resultado de estos problemas debería justificarse.