Hemos movido el flujo de trabajo de nuestro grupo a un enfoque basado en scrum, con mucho éxito. Estamos haciendo las cosas, las personas están más comprometidas y estamos más enfocados en las necesidades reales de nuestra comunidad de usuarios.
Debido a que necesitábamos trabajar en procesos en lugar de herramientas, usamos tarjetas físicas en un tablero de trabajo pendiente y un tablero de tareas. Esto funciona bastante bien, aunque probablemente pasemos a una versión electrónica eventualmente, ya que comenzamos a tener más miembros del equipo remotos.
Esto funciona muy bien para historias de usuario de "tamaño correcto". Pero, ¿cómo lidiamos con cosas que son realmente demasiado pequeñas para una historia de usuario? A veces, estos son errores/defectos, oa veces son solo solicitudes o mejoras de funciones realmente pequeñas. Por ejemplo, nuestra instalación de Gitorious agrega superfluo sa los nombres de los repositorios cuando uno hace un clon. Sería mejor si no fuera así.
Uno podría escribir historias de usuarios para cada cosa como esta (que es lo que hacemos), pero a) se siente con sobrepeso y nada "ágil" yb) tales historias inevitablemente se programan debajo de cosas más grandes e importantes, a pesar de que son a menudo frutas al alcance de la mano (pequeño esfuerzo para resultados pequeños pero notables).
O bien, uno podría tener un rastreador de problemas separado. Sin embargo, eso pasa repentinamente de un lugar para buscar trabajo, el panel de tareas Scrum, a tener dos herramientas. ¿Hay una buena manera de integrar estas cosas para que no actúen en oposición entre sí?
O bien, uno podría simplemente dejar estas cosas fuera del proceso y gritárselas unos a otros en la habitación. Existe un grave riesgo de que esto se convierta en el proceso de facto si no lo soluciono. Cuando esto funciona, básicamente está bien, pero es problemático porque a) puede interrumpir la productividad cuando las personas se distraen de su otro trabajo por interrupciones no programadas y b) cuando estos problemas no se solucionan de inmediato, pueden (como el título de la pregunta) obtener abandonó.
Tenemos una tarjeta de índice en nuestra pizarra, que se encuentra permanentemente en el Backlog, etiquetada como "Deuda técnica". Cualquier miembro del equipo puede tomar una nota adhesiva y escribir TD que creen que estamos recopilando. Por ejemplo, si saben que una decisión de codificación podría tener complicaciones más adelante, la colocamos en la tarjeta de deuda técnica.
Al comienzo de cada sprint revisamos todos los post-it acumulados. Si sentimos que hay alguna deuda que podemos liquidar en el nuevo sprint, y no es en sí misma una historia adecuada, la agregamos como Tareas. También verificamos dos veces si alguna de las Deudas recolectadas afectará las historias en las que se trabajará en el sprint.
Muy a menudo, algunas de las "pequeñas cosas" que mencionaste terminan en la sección TD. Tendemos a eliminar un puñado de ellos en cada sprint solo para asegurarnos de que estamos al tanto de las cosas. No les asignamos puntos (ya que son Tareas, no Historias), pero se evitan grandes trabajos a menos que sean absolutamente críticos.
Personalmente, prefiero usar notas post-it. Es más táctil e interactivo que una herramienta de software (aunque mantengo una hoja de cálculo para mi propia cordura). El equipo tiende a barajarlos por curiosidad cuando están en el tablero. Dudo que se tomen el tiempo de buscar una herramienta de software en sus escritorios.
Dices que necesitas trabajar en procesos sobre herramientas. En general, con Scrum exitoso, las personas y las interacciones son incluso más importantes que los procesos y las herramientas, por lo que si el equipo solo se está comunicando errores entre sí y eso funciona, ¿por qué no seguir haciéndolo?
Por el momento, la naturaleza liviana de las interacciones probablemente le brinde muchos beneficios: supongo que tal vez la velocidad de respuesta, la sensación de ser parte de un equipo y el hecho de que no está escrito, por lo que tiene que arreglarse antes de que la gente lo olvide.
Dados los beneficios, ¿qué espera que le den los procesos? ¿Está buscando realizar un seguimiento de la calidad (recordando que la comunicación ligera está ayudando a mejorarla de todos modos)? ¿Para quién y qué les interesa realmente? ¿A quién le importan las pequeñas cosas que se rastrean?
¿O las pequeñas cosas en realidad se están dejando caer? Si es así, ¿ha comunicado el impacto al equipo y les ha pedido que propongan soluciones? En realidad, podrían considerar tener dos herramientas o un poco más de documentación pesada que valga la pena soportar para obtener una mayor calidad, pero no lo sabrá a menos que pregunte a los muchachos en el terreno, y sabrán cuál es el equilibrio mejor que nadie. aquí.
Se trata de elegir prioridades y visualizar tu trabajo.
Su tablero de Scrum no tiene que estar restringido solo a historias de tamaño. Y, por favor, no intente dimensionar el trabajo sin valor comercial. Muchos olvidan que la velocidad está destinada a medir el "valor comercial" que se entrega a partir de la acumulación de productos.
Esto significa que está limitado por todas las demás "cosas" o "gastos generales". Pero eso no significa que cuando se trata de priorizar el trabajo, no combine TODAS las listas de trabajo.
Un equipo con el que he trabajado elige corregir algunos errores entre cada historia. Estos están en nuestro tablero, clasificados por pila, pero sin tamaño. Nuestro PO los prioriza junto con las historias. Luego, observamos nuestras tendencias de errores para medir si estamos manteniendo o reduciendo nuestra deuda tecnológica al ritmo deseado, mientras entregamos las historias de los usuarios.
Si bien tenemos un tablero de notas post-it, también usamos Rally, lo que nos permite tener un Backlog priorizado y una lista de defectos priorizados, nos permite fusionarlos en un Sprint Backlog durante la planificación. También incluimos otras "pequeñas cosas" como pruebas unitarias faltantes o CI. Tenemos otro conjunto de acuerdos de trabajo cuando también se debe solucionar un problema de "gravedad 1" durante el sprint. También va en el tablero.
Cualquier cosa que queramos ver, va en el tablero y se prioriza. Es genial para todos porque no estamos en ningún tipo de conflicto constante entre la deuda tecnológica y las historias de usuarios comerciales. Los equilibramos en cada sprint con la ayuda de nuestro PO y aprendemos mucho sobre cómo gestionamos todo nuestro trabajo.
Creo que Lunivore y Durzagott dan buenos consejos. El seguimiento de la Deuda Técnica es muy inteligente. Si algo no califica más de un 1, realmente no necesita planificar en exceso.
Un par de pensamientos para construir sobre lo que dijeron (ve a leer sus publicaciones si aún no lo has hecho).
1- ¿Cuál es su valor comercial? Usted menciona cuántas de estas cosas son de baja prioridad. Una cosa que he notado es que a veces, en nuestro enfoque en el valor para el usuario, olvidamos el costo para el usuario. Al asignar valor a un error, no se trata de lo que le dará al usuario, sino de cuál será el impacto para el usuario si se encuentra con esto. Esto es anti-valor y necesita ser factorizado.
2- Nunca cargues al 100%. Muchos agilistas promueven este concepto. No permita que sus equipos acumulen tantas historias que no tengan flexibilidad. Algo saldrá mal, siempre lo hace. Deje algo de tiempo sin tareas en el sprint para manejar estos picos.
3- Arreglar ahora vs Arreglar más tarde: El blog ScrumShortcut tiene una muy buena publicación sobre esto. El concepto es que si encuentra un problema antes de que la historia se marque como "Listo", entonces arréglelo en ese momento. Es parte de los criterios de aceptación de la historia y no se hace hasta que se arregla. Si el error se encuentra después del sprint, entonces lo programa para el backlog (la idea de durzagott del área de deuda tecnológica funciona muy bien aquí).
Agruparlos (tales historias/tareas) para formar un grupo que se adapte a su equipo, de acuerdo con las áreas funcionales relevantes. Luego relaciónelos y priorícelos de acuerdo con el valor comercial.
Esto requeriría una gran cantidad de conocimientos técnicos y la capacidad de los técnicos para defender y convencer a las empresas/PO de que estas historias (p. ej., deuda tecnológica a largo plazo, capacidad para automatizar más cuando sea necesario, necesidad de escribir pruebas unitarias, ajustes de rendimiento, etc.) realmente tienen peso comercial.
Un scrum es, desde mi punto de vista, un modelo teórico que debe adaptarse a su propia situación precisa. Tiene pautas a seguir, reglas y responsabilidades como el scrum master, por ejemplo; pero puede cambiarlos si su equipo cree que funcionaría mejor de otra manera. Lo mantendría simple; reúnase con sus compañeros de trabajo y determine cuál es la mejor manera para usted de organizar sus procedimientos de trabajo diarios: qué mantener o qué cambiar en ese modelo. Inventa algo que encaje perfectamente con lo que eres y lo que estás haciendo. Estoy seguro de que todos ustedes tienen grandes ideas. Simplemente compártalos entre sí. Verás aumentar mucho tu motivación y tu calidad de vida en tu lugar de trabajo. Te divertirás mucho innovando. Creo que el objetivo de cualquier modelo de gestión es adaptarse a un entorno de trabajo preciso. yo tu pregunta,
Zsolt
ben k