¿Cuál es una buena manera para que un equipo Scrum maneje presupuestos y trabaje con otros departamentos?

En mi organización, los desarrolladores usan Scrum (que comenzó recientemente), pero los administradores de sistemas no.

Estamos a punto de comenzar un proyecto grande y se nos ha pedido una descripción detallada de nuestras necesidades de hardware para que se pueda agregar al presupuesto, y debido a que los administradores de sistemas tienen una larga cola de trabajo, necesitamos solicitar una nuevo servidor con mucha anticipación, si lo necesitamos. La persona a la que informan los jefes de ambos departamentos no está completamente de acuerdo con el proceso, parece preferir la cascada, por lo que es posible que deba ser delicado con mis sugerencias.

¿Alguien puede sugerir una forma mejor o al menos más consistente con Scrum de manejar esto, además de simplemente adivinar lo que necesitaremos y esperar que no cambie?

Respuestas (2)

Utilice la estimación de trabajos pendientes para proporcionar valores de planificación

En Scrum, los equipos a menudo realizan un primer paso a través del Product Backlog (generalmente en los niveles Theme o Epic) al comienzo de un proyecto para definir el alcance del proyecto y establecer las fechas objetivo iniciales. Si bien los puntos de la historia, los objetivos del Sprint y la cartera de productos cambian con frecuencia a lo largo de la vida del proyecto, las fechas objetivo generalmente se modifican con menos frecuencia cuando se usan para delimitar el tiempo de los entregables del proyecto.

Este mismo proceso de primer paso puede ser útil para determinar los requisitos de recursos. Si bien el cono de incertidumbre es mayor al comienzo del proyecto, todavía es posible presentar una aproximación basada en supuestos documentados.

Por ejemplo, si está creando una nueva aplicación web, durante su primera estimación del trabajo pendiente, podría identificar:

  1. La necesidad de un servidor de base de datos, un servidor web y un servidor de correo electrónico en cada entorno.
  2. La necesidad de tres entornos: desarrollo, control de calidad y producción.
  3. Un requisito para la alta disponibilidad en producción, que el equipo asume será un servidor activo y uno en espera por servicio.

Podría tomar este conjunto inicial de suposiciones y presentar una solicitud de 12 servidores según lo que el equipo sabe hoy . Incluso podría presentarlo como un rango, que representa su nivel de confianza en las suposiciones. Por ejemplo, podrías decir algo como:

Según la evaluación inicial del equipo de los requisitos del proyecto, esperamos que el proyecto requiera un mínimo de 12 servidores. Estos supuestos se basan en X, Y y Z con un intervalo de confianza actual de aproximadamente el 60 %. Por lo tanto, recomendamos que el presupuesto del proyecto para 18 servidores y que los supuestos del proyecto se revisen trimestralmente para determinar si:

  • Los requisitos de recursos han cambiado.
  • Los valores de planificación siguen siendo válidos.

Al brindar transparencia en su proceso de estimación, brinda a la organización visibilidad de los supuestos del proyecto y deja en claro que se trata de estimaciones que pueden revisarse a medida que el proyecto evoluciona y el cono de incertidumbre se estrecha, a diferencia de las garantías fijas. Después de todo, la capacidad de inspeccionar y adaptar es el sello distintivo de un proceso ágil y proporciona a la gerencia las palancas que necesita para administrar el proyecto con éxito.

Gran respuesta. Gracias. La oración make it clear that these are estimates that can be revised as the project evolveses realmente el corazón de la pregunta que quería hacer. Es la parte que no espero que sea bien recibida. ¿Tienes algún consejo para eso?
@Ivy La honestidad y la transparencia ayudan mucho. Si ha articulado claramente las suposiciones que subyacen a los valores de planificación, ha hecho su trabajo. Sin embargo, no puede controlar si otras personas estarán contentas con los valores de planificación; eso está bajo su control, no el tuyo.

Scrum se enfoca en el trabajo de desarrollo entregado durante un intervalo establecido (es decir, iteración o sprint).

Si el equipo de scrum no está configurando físicamente el hardware, el marco de scrum no se aplica a su situación.

Para los proyectos ágiles de scrum, existen requisitos de planificación de alto nivel que incluyen la creación de una hoja de ruta del producto. Esta hoja de ruta debe describir la progresión de las épicas o las características y proporcionar detalles suficientes para estimar cuándo es necesario aumentar los recursos de hardware adicionales.

El hardware generalmente consta de dos componentes de presupuesto; gasto fijo y recurrente por mantenimiento/soporte del hardware más una tarifa única de compra o configuración. Realmente depende de si su proyecto utiliza "servidores" en la nube/VM/físicos, pero estos costos se pueden presupuestar fácilmente al inicio de cualquier proyecto de tipo cascada o Agile.

Los costos recurrentes y únicos para un proyecto Agile-Scrum pueden derivarse de la hoja de ruta del producto y los administradores del sistema no necesitan escuchar una mención de las palabras Agile, Scrum, Waterfall, etc.

Tenga en cuenta que el presupuesto es un ejercicio de estimación. Ya sea que su proyecto sea en cascada o scrum, la mayoría de los presupuestos contienen un % de cobertura para la incertidumbre.