SCRUM desde cero, sin marco base establecido?

11

Somos un pequeño grupo de 5 personas que está a punto de comenzar un nuevo proyecto. Este es el primer proyecto donde iremos todo incluido en scrum.

Estamos luchando un poco con la forma en que vamos a establecer una base para el proyecto (marcos y similares). Dichas tareas no son algo de lo que el usuario se beneficiará directamente, por lo que nos resulta difícil descubrir cómo escribimos historias de usuarios para ello.

Entonces, en general, ¿cómo usas scrum cuando comienzas un proyecto desde cero, sin marcos y sin una biblioteca base en su lugar?

Niklas H
fuente

Respuestas:

7

No creo que muchos métodos ágiles manejen bien las actividades que generalmente son parte del inicio del proyecto. Muchos de los frameworks comunes (XP, Scrum, Kanban) no abordan esta preocupación, pero algunos de los frameworks escalados (Disciplined Agile Delivery, SAFe) lo hacen en cierta medida.

Algunas personas abogan por un concepto de incremento inicial (en Scrum, un sprint) diseñado para configurar su proyecto. Esto a menudo se llama Incremento cero (o, en Scrum, Sprint 0). Sin embargo, no es una parte formal de Scrum y los puristas dicen que el primer Incremento debería ser potencialmente liberable.

Tal incremento se usa para configurar el entorno del equipo: configure sus entornos de desarrollo, prueba y producción, configure sus herramientas y scripts de soporte y establezca sus entornos de trabajo con gráficos de carga y atrasos. Si alguien en el equipo no está familiarizado con las herramientas de desarrollo que se usan, aquí es donde aprenden los conceptos básicos para funcionar y comienzan a producir resultados en la primera iteración.

Junto con esto, a menudo comenzará a escribir sus primeras historias de usuario y priorizará la cartera de pedidos de su producto, ya que no hay una pila de sprint en este momento. Quien sea el propietario del producto ideará historias. Si esta persona es nueva en Scrum, también aprendería a escribir buenas historias de usuario con las que el equipo pueda trabajar. No enfatices en obtener todas las historias, pero querrás lo suficiente para comenzar la primera iteración de desarrollo.

Diferentes equipos manejan Sprint 0 de manera diferente. Algunos pueden usar la misma duración que cualquier otro sprint. Otros pueden hacerlo un poco más largo o un poco más corto dependiendo de las necesidades del equipo. Dado que este es su primer intento en Scrum, podría hacerlo más largo, especialmente si tiene iteraciones más cortas como parte de su ciclo de desarrollo. Si está planeando iteraciones de dos semanas, hágalo en 3 semanas.

En cuanto a la formulación de las tareas, no las formularía necesariamente como historias de usuarios. Podría, desde la perspectiva de los miembros del equipo y varios roles (Propietario del producto, ScrumMaster, desarrollador, probador, diseñador, escritor técnico, etc.). Sin embargo, Sprint 0 es para el equipo, no para el cliente o el usuario. Sería suficiente una simple lista de tareas y actividades.

Thomas Owens
fuente
3
Sprint 0 es directamente para el equipo, pero indirectamente beneficia al cliente, ya que sienta las bases para el trabajo de Sprint por venir. Gran respuesta, haces que suene fácil y no tan caótico como suele sentir Sprint 0.
maple_shaft
Cualquier lanzamiento de proyecto suele ser caótico hasta cierto punto, dependiendo del equipo. Por lo general, no solo existen problemas técnicos con la configuración de todo, sino también problemas personales entre los miembros del equipo y problemas del proceso que determinan la mejor manera de abordar los problemas que surgen.
Thomas Owens
Otra herramienta en el cinturón de herramientas de Scrum es una serie de "picos" (historias de investigación) donde el resultado es esencialmente determinar qué opciones están disponibles y qué ha elegido el equipo como su solución preferida. Es decir, cuando no se usan marcos, puede tener un sprint para determinar qué marcos (si los hay) lo ayudarían a acercarse a un producto útil. Ningún marco es siempre una opción, particularmente para pequeñas utilidades únicas.
Berin Loritsch
1

Estos son los requisitos previos que establecimos antes de implementar SCRUM en nuestro equipo. Una vez que haya terminado con la lista, puede implementar el proceso y las herramientas para el scrum real.

  1. Los miembros del equipo son altamente o moderadamente calificados.
  2. El equipo está muy unido.
  3. El intercambio de información entre los miembros del equipo es rápido, consistente y de flujo libre.
  4. El equipo está ubicado conjuntamente.
  5. El negocio está altamente involucrado con el equipo.
  6. La arquitectura (negocios, información y técnica) está bien definida.
  7. La infraestructura está en funcionamiento: Dev, prueba y entorno UAT.
  8. Construcción y lanzamiento automatizados.
  9. Alto nivel de automatización de pruebas.
  10. La dependencia del equipo con el mundo externo es mínima (idealmente cero).
  11. El conteo de sistemas participantes es mínimo.
  12. Los requisitos son estables en los niveles superiores, por lo que la acumulación de productos tiene cambios mínimos.
  13. Los miembros del equipo son autónomos para tomar una decisión sobre qué historia de usuario debe ser parte del sprint / scrum, así como el número total de scrums / sprint necesarios para lograr el objetivo establecido.

Otras dos partes importantes:

  1. Seleccione las personas para los roles (Scrum master, Product Owner y el equipo)
  2. Tenga lista su pizarra, calcomanías.
java_mouse
fuente
¿Qué quieres decir con # 11?
Matt Grande
3
En mi experiencia, si la aplicación depende o está interconectada con sistemas externos, SCRUM no funcionó bien. La dependencia de otros equipos redujo la eficiencia de nuestro proceso. Puede ser que fue solo nuestro proyecto ...
java_mouse
Oh, está bien, entonces te referías a sistemas que necesitaban modificaciones. Simplemente pensé que se incluían sistemas, de ahí la confusión. En el pasado, lo logramos al tener dos "niveles" de scrum. Uno de nivel inferior para cada sistema y uno de nivel superior para todo el proyecto para incluir a todos los equipos.
Matt Grande