La mêlée a-t-elle un quelconque mérite dans les contrats de défense?

12

Entendu hier au refroidisseur d'eau: "Scrum n'a pas sa place dans les contrats de défense."

J'ai tendance à être en désaccord dans le sens où je crois que Scrum peut être adapté pour fonctionner dans de nombreux scénarios et je peux voir la défense comme l'un d'entre eux. Cela a déclenché un énorme débat parmi mes collègues (nous sommes nombreux à travailler dans le secteur de la défense) avec une répartition assez équitable pour / contre.

Pour en faire une bonne question: Quelqu'un a-t-il utilisé avec succès (ou a de l'expérience avec) la mêlée dans une situation de contrat de défense? Qu'est-ce qui a bien fonctionné, qu'est-ce qui n'a pas bien fonctionné et quelles modifications (le cas échéant) à la mêlée de vanille avez-vous faites?

development-process scrum development-methodologies

— Sean Madden
source

3

Agile s'efforce d'éliminer les déchets. Les organisations qui tentent de réussir avec l'agilité doivent être alignées sur cet objectif. Les organisations politiques ont généralement d'autres priorités.

— Martin Wickman

5

"Scrum n'a pas sa place dans les contrats de défense."

D'après mon expérience, le principal obstacle est le client. La plupart des agences gouvernementales ont le modèle de la cascade dans leur ADN. Même les contrats sont réalisés en phases de cascade - nous financerons d'abord les exigences, puis la conception, puis la mise en œuvre. Dans la théorie classique de la cascade, ils peuvent même penser qu'ils peuvent demander à différentes entreprises d'effectuer différentes phases.

Il existe des moyens de contourner cela grâce à l'OMI. Faites une demande initiale et concevez comme une cascade, puis dans la mise en œuvre, divisez les exigences en histoires d'utilisateurs itératives. Utilisez des tests internes / des utilisateurs experts évaluent chaque itération. Selon le client, il peut ou non être intéressé à participer. Pas de mêlée pure, mais c'est peut-être le mieux que vous puissiez faire.

— Doug T.
source

3

J'ai travaillé en tant que stagiaire pour trois équipes dans un laboratoire de recherche de l'Air Force, une fois dans le développement de logiciels de production, une fois dans le prototypage rapide et une troisième fois dans la vérification et la validation des travaux contractuels. Les deux positions de développement étaient agiles. En fait, la position de production était très proche de Scrum, avec moins d'interaction avec le client (logiciels livrés toutes les quelques itérations, client sur site tous les 3-6 mois), et c'était en 2006. Je suis d'accord que l'adhésion et la compréhension des clients sont les plus importantes problème, mais certaines agences gouvernementales (ou du moins des équipes) adoptent effectivement les méthodes Agiles.

— Thomas Owens

@Thomas Owens Ce commentaire serait une bonne réponse.

— Hugo

1

Bien qu'il puisse être difficile d'implémenter entièrement Scrum, il peut être avantageux d'adopter certaines des pratiques Scrum. Par exemple, peu importe la façon dont vous effectuez la collecte des exigences, vous pouvez toujours avoir des versions et des démos fréquentes. Vous pouvez toujours bénéficier de rétrospectives périodiques. Regardez d'autres processus comme Lean ou Kanban et voyez s'ils ont quelque chose qui peut également aider votre équipe.

Au lieu de suivre dogmatiquement n'importe quel processus, réfléchissez à la façon dont vous pouvez améliorer le processus spécifiquement pour votre équipe, votre projet et votre industrie. Le processus est important . La méthodologie d'une équipe a un impact majeur sur le logiciel livré.

— epotter
source