Comenzamos con Scrum porque su estructura formal (estimación, planificación de la historia del usuario, planificación de tareas, reuniones diarias, retrospectiva) nos ayudó a salir de nuestros viejos métodos para ser más ágiles. Ahora hemos encontrado que las 3 reuniones de planificación y organización se pueden realizar según la tarea/la historia del usuario en las reuniones de la mañana.
Tenemos un tablón de anuncios grande y un alfiler en las fichas para cada historia de usuario. El tablero se divide en no iniciado, en progreso y hecho. Nos aseguramos de que ninguna tarea tarde más de un día en desglosarla, y analizamos cada historia de usuario en la reunión diaria de la mañana el día en que la necesitaremos. Esto nos mantiene ágiles para que la lista de "características" como historias de usuarios pueda cambiar sin que pasemos tiempo dividiéndola en tareas. Esto asegura que los proyectos de dos semanas se puedan manejar fácilmente de la misma manera que los proyectos más grandes también.
Para estimar la velocidad, contamos las tarjetas al final de la semana para ver cuántas tareas hemos hecho. La desventaja es que la planificación de versiones y la estimación de velocidad no es tan precisa como con Scrum, pero esta metodología híbrida XP ayuda a los desarrolladores a concentrarse en las tareas cuando están listas y no perder demasiado tiempo en las reuniones.
Tener tareas más pequeñas también promueve compromisos más regulares para el control de fuente y combinado con un servidor de compilación y scripts de implementación, podemos entregar una progresión en la aplicación al menos una vez al día, ideal para obtener retroalimentación del cliente. También tenemos retrospectivas semanales y hemos contratado a un consultor ágil durante una semana cada 3 meses para asegurarnos de que seguimos el camino correcto.
Algunas ideas del scrum pueden funcionar, como las reuniones diarias de stand up face, pero creo que conceptos como la programación por pares en XP serían más útiles para proyectos pequeños. Y a los verdaderos "scrummists" no les gusta cambiar el horario de los intervalos de 2 semanas. – stephenbayer
En realidad, Ken Schwaber (uno de los creadores de Scrum) dice específicamente en su libro que debe adaptar el proceso de Scrum (incluida la duración del sprint) para que se ajuste a las necesidades de su equipo. –
Tengo que admitir que mi proyecto formal más corto hasta la fecha ha sido de 5 semanas, y utilicé un método XP bastante estricto con eso. Por lo general, trabajo en proyectos de 3 a 6 meses con scrum estricto. No he hecho proyectos de micro (2 semanas). Intento seguir estrictamente las metodologías en lugar de mezclarlas. – stephenbayer