¿Debería usarse SCRUM para un proyecto con una sola persona trabajando en él?

19

En nuestra empresa, tenemos un equipo que trabaja en 3 proyectos diferentes al mismo tiempo, donde típicamente solo una o dos personas participan en cada proyecto. El trabajo del proyecto a menudo implica dominar nuevas tecnologías y / o resolver errores, lo que lleva a tareas que son muy difíciles de estimar. En esta situación, la administración aún insiste en usar SCRUM y no permite asignar un búfer de seguridad al final del sprint para situaciones inesperadas. La reunión de pie ocurre para todo el equipo, aunque casi todos trabajan juntos en componentes de software no relacionados o en diferentes proyectos de software.

  • Me preguntaba si alguien había visto a SCRUM trabajando bien para un proyecto con un solo desarrollador y tareas difusas, y ¿cómo hizo que el proceso funcionara bien?

  • ¿Cómo estimar tareas que implican investigación / dominar nuevas tecnologías (esto implica aprender nuevos lenguajes de programación, plataformas y herramientas de desarrollo)?

  • ¿Alguien ha logrado convencer a la gerencia de que no use SCRUM para proyectos particulares y, en caso afirmativo, qué argumentos tuvieron más éxito?

¡Gracias!


fuente
Parece que a su gerencia le gusta usar palabras elegantes sin siquiera entender lo que hay detrás de esa palabra. No Scrum no es para su entorno y parece que debería buscar otro trabajo. Hacer cada tarea en otra tecnología es probablemente una pérdida de tiempo.
Ladislav Mrnka
Scrum de 1 persona = disciplina. Simplemente tiene que aprender a hacer las cosas más importantes / arriesgadas primero. Esto es ... sentido común.
Trabajo
suena como "la gerencia", no entiendo Scrum desde una perspectiva organizacional. Los proyectos deben tener un intervalo de tiempo cada uno y usted debe trabajar en equipo. Entregue a "la gerencia" una copia de Triunfar con Agile: Desarrollo de software con Scrum
Dave Hillier
No es posible, por definición. "Scrum-like" es posible y podría ser productivo o antiproductivo, pero debe sentarse con mgmt y una lista de verificación de lo que significa scrum puro, y decidir qué aspectos desea seguir. No importa si continúas llamándolo scrum o no, siempre y cuando todos sepan específicamente lo que se desea. También trate de comprender la perspectiva de mgmt y lo que están tratando de obtener del proceso.
Dax Fohl el

Respuestas:

8

Busque "Scrum personal" ... He visto un par o tres publicaciones de blog de personas haciendo esto. Full Scrum tiene algunas nociones que no se traducirán perfectamente a equipos de una sola persona. (Mi experiencia: una cierta "masa crítica" de aproximadamente 4 personas parece hacer que las cosas de equipo funcionen bien).

http://blog.jgpruitt.com/tag/personal-scrum/ por ejemplo.

Pero cosas como la estimación de tareas, la velocidad y los sprints con límite de tiempo durante los cuales la lista de tareas está "protegida" funciona bien incluso para 1.

David Van Brink
fuente
+1 para un buen enlace a un proyecto de posgrado completo usando Scrum personal: "todo el proyecto ha sido registrado en los materiales a continuación. Que yo sepa, esta es la primera instancia completamente documentada de un proyecto de Scrum personal, y ciertamente es el más abierto."
Hugo
7

Por supuesto no. ¡Tus scrums diarios serían muy cortos e increíblemente aburridos!

Sin embargo, puedes elegir los pedazos que crees que te ayudarían, las tarjetas tienen sentido aunque no tienes que llenarlas completamente; detenerse después de un período de tiempo establecido para verificar su progreso también tiene sentido. Pero si está haciendo eso, eche un vistazo a Kanban, Crystal y todos los demás métodos ágiles también para obtener información que lo ayude.

gbjbaanb
fuente
3

No, no puedes hacer scrum sin un equipo. El equipo definido por SCRUM es "Un grupo interdisciplinario de personas responsables de administrarse para desarrollar el producto", que es un papel importante en SCRUM.

De acuerdo con http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf

Tamaño del equipo de desarrollo El tamaño óptimo del equipo de desarrollo es lo suficientemente pequeño como para ser ágil y lo suficientemente grande como para completar un trabajo significativo. Menos de tres miembros del Equipo de Desarrollo disminuyen la interacción y resultan en ganancias de productividad más pequeñas. Los equipos de desarrollo más pequeños pueden encontrar limitaciones de habilidad durante el Sprint, lo que hace que el equipo de desarrollo no pueda entregar un incremento potencialmente liberable. Tener más de nueve miembros requiere demasiada coordinación. Los grandes equipos de desarrollo generan demasiada complejidad para un proceso empírico para administrar. Las funciones de Propietario del producto y Scrum Master no se incluyen en este recuento a menos que también estén ejecutando el trabajo de la Pila de Sprint

Sin embargo, aún puede ser ágil, y tal vez usar las otras características del SCRUM, como mantener el trabajo atrasado del producto / sprint y planificar y trabajar en sprints / iteraciones, revisar y obtener comentarios de todas las partes interesadas y volver a planificar, etc. Lea más sobre scrum, ya que es mucho más como se describe aquí.

luqi
fuente
3

Estoy trabajando en una tienda similar. Como otros han señalado aquí, lo que describe puede ser ágil pero no scrum. También agregaría que si los registros y sprints posteriores tienen sentido o no depende de si se trata de un nuevo trabajo o mantenimiento y soporte continuo. Si es lo primero, entonces un enfoque en cascada tendría más sentido para un equipo de una sola persona. Si no, desde una perspectiva de PM, lo que están haciendo parece un buen enfoque si tienen múltiples proyectos en su cartera.

Para los entusiastas de Agile, la mera mención de usar cascada es un sacrilegio. Pero las personas necesitan usar el sentido común.

Permítanme dar un ejemplo de un proyecto mío reciente. Lideraba un equipo de 3 desarrolladores en un cronograma agresivo de 5 meses para rediseñar dos sitios web principales. Tuvimos reuniones diarias de pie. Pero fue un proyecto en cascada porque era un equipo pequeño, un ciclo de vida limitado, y los desarrolladores eran contratistas a corto plazo comprometidos con el proyecto solo hasta el lanzamiento. El proyecto siguió un ciclo de vida en cascada muy tradicional. Absolutamente nada de malo en eso. Excepto que trabajamos de manera "ágil", mantuvimos las reuniones de pie y mantuvimos las mejores prácticas de desarrollo ágil. Nuestro pequeño equipo estaba exento de las reuniones semanales de planificación de sprints del equipo más grande. ¿Por qué? Porque no tuvimos implementaciones semanales. Y nuestro equipo no dependió ni influyó en el trabajo realizado por ningún otro equipo. De hecho, trabajamos casi de manera autónoma. Después del lanzamiento de los sitios web, pasamos a un proceso ágil para el mantenimiento y soporte continuo. Los otros desarrolladores ahora están trabajando en otro lugar. Todas las mejoras se planifican según implementaciones periódicas.

El punto es que es mejor usar los procesos que tengan más sentido para el tamaño, la complejidad y la madurez de cada proyecto. Si está investigando mucho, entonces es difícil hacer una estimación para los próximos cinco meses, por lo que ágil es probablemente un mejor enfoque que la cascada.

Parte del problema es que algunas personas parecen pensar que puedes planificar los próximos cinco sprints con anticipación. Ese ha sido el caso conmigo antes. No deberías estar planeando más de dos sprints porque si lo estás, estás derrotando el propósito de tener sprints. Se supone que un sprint es un compromiso para ofrecer una cantidad realista de mejoras dentro de un período de tiempo determinado. No debes comprometerte con algo de lo que no estás seguro. La planificación de Sprint es, por naturaleza, una planificación a corto plazo, pero ese es el punto. Si tiene un cronograma a largo plazo, piense en dividir las cosas en entregas más pequeñas. O configurar reuniones de punto de control en función de dónde se encuentre en el SDLC.

Se supone que la planificación de Sprint es un compromiso realista sobre lo que se garantiza que se completará dentro de un cierto período de tiempo. Si encuentra que la planificación no tiene en cuenta variables desconocidas, tal vez debería comenzar a dar rangos o estimaciones pesimistas. O como otro sugirió, use puntos de la historia. Los sprints tampoco deben reservarse por completo para permitir el deslizamiento y otras tareas importantes que surjan.

Jason
fuente
1

No debería haber una sola persona en su equipo y dudo que realmente exista. Un "equipo" en SCRUM no son solo los desarrolladores. ¿Eres el representante del cliente, scrum master, desarrollador, etc.? ¿Eres realmente la única persona que hace algo relacionado con este producto, toma decisiones al respecto o intenta venderlo?

En cuanto a la estimación de la investigación, lo haces como una historia. Haces una historia específicamente para "Investigación XXX" y le das puntos de historia (recuerda, no estás estimando el tiempo aquí, sino la dificultad). También debe poder estimar de manera bastante adecuada la dificultad de implementar alguna característica, incluso si necesita investigar tecnologías. A veces, este último hecho simplemente convierte una historia en "máxima dificultad".

No, realmente no deberías reunirte con todos los desarrolladores como tu standup. Debería reunirse con su equipo , que nuevamente no son solo los desarrolladores.

Buena suerte. Espero que lo entiendan.

Edward extraño
fuente
1

Suponiendo que tenga un propietario del producto y un maestro de scrum (si no, entonces no es scrum), scrum puede funcionar para un equipo de un solo hombre. Los artefactos Scrum (atrasos, gráficos de burddown) se usarán tal como se usan en el equipo de varias personas. Ahora sobre reuniones:

Standups diarios: utilizaría el standup diario para actualizar a todos, es decir, el propietario del producto, el scrum master o cualquier otra persona interesada en el progreso. Scrum Master utilizará estas reuniones para conocer los impedimentos que tenga. El propietario del producto puede ayudarlo a revisar el alcance si es necesario.

Revisión de Sprint: al final de cada sprint, entregaría el incremento de trabajo de su software al propietario o cliente del producto. Si el objetivo del sprint era aprender "algo", demostrará un PoC que puede ser utilizado por la administración (es decir, generalmente el cliente para PoC).

Asim Ghaffar
fuente