¿Scrum tiene algún mérito en la contratación de defensa?

12

Escuché ayer en el refrigerador de agua: "Scrum no tiene lugar en la contratación de defensa".

Tiendo a estar en desacuerdo en el sentido de que creo que Scrum puede adaptarse para trabajar en muchos escenarios y puedo ver que la defensa es uno de ellos. Esto provocó un gran debate entre mis colegas (muchos de nosotros trabajamos en contratos de defensa) con una división bastante a favor o en contra.

Para hacer esto una pregunta apropiada: ¿Alguien ha utilizado con éxito (o tiene experiencia trabajando con) scrum en una situación de contratación de defensa? ¿Qué funcionó bien, qué no funcionó bien y qué modificaciones (si las hubo) al vainilla scrum hiciste?

development-process scrum development-methodologies Sean Madden
fuente
3
Agile se esfuerza por eliminar los desechos. Las organizaciones que intentan tener éxito con Agile deben estar alineadas con ese objetivo. Las organizaciones políticas tienden a tener otras prioridades.
Martin Wickman

Respuestas:

5

"Scrum no tiene lugar en la contratación de defensa".

En mi experiencia, el principal impedimento es el cliente. La mayoría de las agencias gubernamentales tienen el modelo de cascada en su ADN. Incluso los contratos se realizan en fases de cascada: primero financiaremos los requisitos, luego el diseño y luego la implementación. En la teoría clásica de las cascadas, incluso pueden pensar que pueden lograr que diferentes compañías realicen diferentes fases.

Hay formas de evitar eso a través de la OMI. Haga un pedido por adelantado y diseñe como cascada, luego, en la implementación, divida los requisitos en historias de usuario iterativas. Utilice la prueba interna / los usuarios expertos evalúan cada iteración. Dependiendo del cliente, pueden o no estar interesados ​​en participar. No es un scrum puro, pero puede ser lo mejor que puedes hacer.

Doug T.
fuente
3
Trabajé como pasante para tres equipos en una instalación de Laboratorio de Investigación de la Fuerza Aérea, una vez en el desarrollo de software de producción, una vez en la creación rápida de prototipos, y una tercera vez en la verificación y validación del trabajo por contrato. Ambas posiciones de desarrollo fueron ágiles. De hecho, la posición de producción estaba muy cerca de Scrum, con menos interacción con el cliente (software entregado cada pocas iteraciones, cliente en el sitio cada 3-6 meses), y esto fue en 2006. Estoy de acuerdo en que la compra y comprensión del cliente es la mayor problema, pero algunas agencias gubernamentales (o al menos equipos) están adoptando métodos ágiles.
Thomas Owens
@Thomas Owens Este comentario sería una buena respuesta.
Hugo
1

Si bien puede ser difícil implementar Scrum por completo, puede ser beneficioso adoptar algunas de las prácticas de Scrum. Por ejemplo, ahora, independientemente de cómo esté reuniendo los requisitos, aún puede tener lanzamientos y demostraciones frecuentes. Aún puede beneficiarse de las retrospectivas periódicas. Observe otros procesos como Lean o Kanban y vea si hay algo que puedan ayudar a su equipo también.

En lugar de seguir dogmáticamente cualquier proceso, piense en cómo puede mejorar el proceso específicamente para su equipo, su proyecto y su industria. El proceso importa . La metodología de un equipo tiene un gran impacto en el software que se entrega.

epotter
fuente