He estado usando Scrum durante mucho tiempo en mis propios proyectos, que generalmente son a tiempo parcial (un par de horas por semana, tal vez hasta 10 horas por semana) y generalmente solo (aunque ocasionalmente incluyen equipos de hasta 3-4 personas ).
Me gustan ciertos beneficios que obtengo al usar Scrum:
Algunos problemas con los que lucho:
Tratar de usar la velocidad para la planificación de la capacidad ("cuánto tiempo llevará...") es casi imposible. De hecho, además de dividir el trabajo en partes más pequeñas, es principalmente por encima de la cabeza.
¿Hay alguna modificación o mejor manera de obtener una velocidad significativa en este tipo de situación? Los sprints más largos pueden funcionar (promediar mejor, por ejemplo, un mes), pero todavía no estoy seguro de que mi velocidad sea realmente significativa.
Descubrí que "scrum" puede significar cosas muy diferentes para diferentes personas. Para mí, lo que lo diferencia de otros procesos ágiles es el enfoque en los sprints basados en el compromiso. Dado que no ha enumerado la entrega de entregables basados en sprints como un beneficio importante para estos proyectos, puede obtener más valor de otros procesos ágiles ligeros en lugar de ceñirse a las actividades prescritas por scrum.
Estimar historias puede tener una utilidad limitada. Descubrí que si eres bueno manteniendo las historias pequeñas y del mismo tamaño, entonces funciona igual de bien contar historias en lugar de puntos o asignar a todas las historias el mismo valor de puntos tan pronto como creas que están bien definidas. Incluso he tenido proyectos de equipo que caen en este patrón y pasamos actividades de "estimación" para que las historias fueran apropiadamente pequeñas en lugar de debatir el conteo de puntos.
Para obtener una velocidad útil, creo que debe intentar medir los puntos o las historias entregadas por hora en cada iteración. Eso debería eliminar gran parte de la variabilidad que está viendo. Si el tiempo que dedica a cada iteración es muy variable, no podrá proyectar una fecha de finalización, pero debería poder proyectar aproximadamente cuántas horas de trabajo quedan.
Muchas herramientas incluyen la capacidad de ajustar la fuerza del equipo por iteración para tener en cuenta este tipo de cambios. Por ejemplo, Pivotal Tracker le permite establecer un porcentaje de la fuerza normal del equipo para cada iteración, lo que le permite tener en cuenta a los miembros del equipo de vacaciones, horas reducidas u otras variaciones. Alternativamente, puede contar una iteración como X horas de trabajo en lugar de Y días transcurridos y una iteración puede tardar de 1 a 3 semanas en completarse, pero obtendrá una cantidad estimada más útil de iteraciones restantes en el proyecto.
El valor de Scrum comienza con un desarrollador. equipo de mínimo 3 personas y se siente a partir de 5 personas en adelante. Si usted es el único desarrollador, no me molestaría con Scrum, puede inspirarse en él, pero en realidad se reduce a una buena priorización de funciones y administración personal.
Estimar historias parece un desperdicio, especialmente si soy el único desarrollador, no existe el concepto de lanzamiento/objetivo/fecha límite
Aquí podría ser donde obtenga el máximo rendimiento de su inversión. Puede parecer una pérdida de tiempo, pero si haces tus estimaciones podrás ver cuánto debes asumir en cada sprint.
En lugar de Story Points, es posible que desee utilizar Horas para sus estimaciones. Sé que los puntos son generalmente la opción aceptada, pero si no mantiene un horario regular, no sé cómo su velocidad se traducirá en algo significativo.
En algún momento, nadie tendrá una respuesta aceptable para usted: si la escala de su trabajo se vuelve tan pequeña que cualquier variación en su horario personal hace que cualquier métrica no tenga sentido, entonces no hay mucho que pueda hacer al respecto...
Puede usar Agile con éxito siendo una o más personas. Barnaby Golden me dijo una vez
Puede adoptar ágil con cualquier tamaño de equipo, ya que es un enfoque para hacer desarrollo de software.
Cuando se trata de Scrum, como mencionas, se recomienda para equipos de al menos 3; además, usar Kanban con solo 1 persona puede tener resultados muy lejanos a las expectativas.
Aún así, alguien sintió la necesidad de crear una metodología Agile para desarrolladores independientes llamada Cowboy , que creo que se adapta a tus necesidades, considerando que la mayor parte del tiempo eres solo uno y te gustan ciertas prácticas Agile y Scrum. Esta metodología, como se afirma en el artículo
toma prestado en gran medida de las prácticas ágiles, así como de XP, Scrum, AUP y Real.
Usando Cowboy básicamente
Para leer más al respecto, vaya a las páginas 18-24 del documento .
cenizas999
Jonás