D'après un traducteur: il s'agit du Guide DIB: Détection des BS agiles (version 0.4) , que le Comité d'innovation du Département américain de la défense (DIB) a publié publiquement le 9 octobre 2018.

Agile est un mot à la mode dans le développement de logiciels, donc tous les projets logiciels du ministère de la Défense sont désormais par défaut «flexibles». Ce document aidera les gestionnaires de programme et les spécialistes du ministère de la Défense à distinguer les projets logiciels avec une méthodologie vraiment flexible des projets qui utilisent simplement «cascade» ou «spirale» («agile-scrum-fall») sous l'apparence d'Agile.

Principes, valeurs et outils

Les experts et les passionnés agiles identifient les paramètres clés qui caractérisent cette culture et cette approche du développement agile. Dans son travail, DIB a développé ses propres directives qui reflètent à peu près les vraies valeurs d'Agile:

Valeur agile	Principe DIB
Les individus et les interactions sont plus importants que les processus et les outils	«La compétence est plus importante que le processus»
L'exécution d'un logiciel est plus importante que la documentation complète	«Réduisez le temps entre le début du projet et le déploiement de la fonctionnalité de base la plus simple»
Collaboration avec un client pour convenir d'un contrat	«Implémentation de la culture DevSecOps pour les systèmes logiciels»
Répondre au changement par rapport au plan	«Les programmes devraient commencer petit, être itératifs et s'appuyer sur le succès - ou ils sont rapidement annulés.»

Signes clés que le projet n'est pas très flexible:

• Aucune des équipes de développement ne communique avec les utilisateurs ou ne suit les logiciels en action; nous voulons dire de vrais utilisateurs de vrai code. (Le service d'évaluation de programme n'est pas considéré comme un véritable utilisateur, tout comme un cadre supérieur, à moins qu'il n'utilise le programme dans son travail). Alternatives acceptables à la communication avec les utilisateurs: surveiller leur travail, leur transmettre des prototypes pour obtenir des commentaires et d'autres méthodes de recherche qui n'impliquent pas beaucoup de communication verbale.
• Il n'y a pas de retour constant des utilisateurs pour l'équipe de développement (rapports de bogues, évaluations). Il ne suffit pas de parler une fois au début du projet pour vérifier les exigences!
• La conformité est considérée comme plus importante que l'obtention du résultat le moins utile le plus rapidement possible.
• Les parties prenantes (développement, tests, DevOps, sécurité, entrepreneurs, utilisateurs finaux, etc.) fonctionnent de manière plus ou moins autonome (par exemple, «ce n'est pas mon affaire»).
• Les utilisateurs finaux ne sont pas impliqués dans le développement; au minimum, ils doivent être présents lors de la planification de la version et des tests d'acceptation.
• La culture DevSecOps n'est pas suffisante lorsque les processus qui peuvent et doivent être automatisés sont exécutés manuellement (par exemple, test, intégration continue, livraison continue).

Quelques outils de développement agiles typiques (ils changent
l'apparence des meilleurs):

• Git, ClearCase ou Subversion est un système de contrôle de version pour suivre les modifications du code source. Git est la norme de facto dans le développement moderne.
• BitBucket ou GitHub - hébergeant des référentiels. Il assure également le suivi des tickets, propose des «applications» d'intégration continue et d'autres outils pour améliorer la productivité. Largement utilisé par la communauté open source.
• Jenkins, Circle CI ou Travis CI est un service d'intégration continue pour la construction et le test de projets Bitbucket et GitHub.
• Chef, Ansible ou Puppet - logiciel pour créer des «recettes» pour la configuration et diffuser les tâches de configuration et le soutien à un certain nombre de serveurs.
• Docker est un programme informatique qui effectue la virtualisation au niveau du système d'exploitation, également appelé conteneurisation.
• Kubernetes ou Docker Swarm pour l'orchestration de conteneurs.
• Jira ou Pivotal Tracker - tickets, suivi et gestion.

Version graphique:

Questions pour les développeurs

• Comment testez-vous le code? (Réponses erronées: «Nous avons une organisation spéciale pour les tests», «Le département des tests et de l'évaluation des produits est responsable des tests»)
  
  • Version étendue: quel ensemble d'outils utilisez-vous pour les tests unitaires, les tests de régression, les tests fonctionnels, les analyses de sécurité et la certification de déploiement?
• Dans quelle mesure les pipelines de développement, de test, de sécurité et de déploiement sont-ils automatisés?
  
  • Version étendue: quel ensemble d'outils utilisez-vous pour l'intégration continue (CI), la livraison continue (CD), les tests de régression, la documentation du programme; Votre infrastructure est-elle pilotée par du code?
• Qui sont vos utilisateurs et comment interagissez-vous avec eux?
  
  • Version étendue: quels mécanismes utilisez-vous pour obtenir des commentaires directs des utilisateurs? Quel ensemble d'outils utilisez-vous pour créer des rapports de bogues et suivre les tickets? Comment répartissez-vous le travail de correction de bogues entre les équipes? Comment informez-vous les utilisateurs que leurs problèmes sont en cours de résolution et / ou déjà résolus?
• Quelle est la date limite pour les cycles de sortie actuels et futurs?
  
  • Version étendue: quelles plateformes logicielles supportez-vous? Utilisez-vous des conteneurs? Quels sont vos outils de gestion de configuration?

Questions pour les chefs de projet

• Combien de programmeurs font partie de l'organisation qui alloue le budget et quelles sont les principales étapes du programme? (Réponses erronées: "Nous ne savons pas", "Zéro", "Cela dépend de la définition d'un programmeur")
• Quelles sont les mesures de gestion pour le développement et l'exploitation; comment ils sont utilisés pour communiquer les priorités, identifier les problèmes; à quelle fréquence consultent-ils et utilisent-ils le manuel?
• Qu'avez-vous appris au cours des trois derniers sprints et comment appliquer les nouvelles connaissances? (Réponses erronées: «Qu'est-ce qu'un sprint?», «Nous attendons l'approbation de la direction»)
• Quels sont les utilisateurs qui bénéficient de chaque cycle de sprint? Puis-je leur parler? (Réponses erronées: «Nous ne déployons pas le code directement pour les utilisateurs»)

Questions pour les clients et les utilisateurs

• Comment communiquez-vous avec les développeurs? Supervisent-ils votre travail et posent-ils des questions pertinentes qui indiquent une compréhension approfondie de vos besoins? À quand remonte la dernière fois qu'ils se sont assis à proximité et ont discuté des fonctionnalités que vous souhaitez voir?
• Comment soumettre des suggestions de nouvelles fonctionnalités ou signaler des problèmes ou des bogues dans le code? Quels commentaires recevez-vous pour vos demandes / rapports? Vous a-t-on déjà demandé d'essayer des prototypes de nouvelles fonctionnalités logicielles et avez regardé comment vous les utilisez?
• Combien de temps faut-il pour implémenter la fonction demandée dans l'application?

Questions d'orientation

• Une version de travail du logiciel est-elle fournie à au moins un petit échantillon d'utilisateurs réels à chaque itération (y compris la première) et des avis sont-ils collectés? (indice: toutes les deux semaines)
• Existe-t-il une charte de produit qui définit la mission et les objectifs stratégiques? Tous les membres de l'équipe comprennent-ils les deux? Voyent-ils comment leur travail contribue à la réalisation des objectifs?
• Les avis d'utilisateurs se transforment-ils en tâches spécifiques pour les équipes de sprint avec un délai inférieur à un mois?
• Les équipes sont-elles autorisées à modifier les exigences en fonction des commentaires des utilisateurs?
• Les équipes ont-elles le droit de modifier leur processus en fonction de ce qu'elles ont appris au cours du développement?
• L'ensemble de l'écosystème de votre projet est-il flexible? (Si le développement agile est suivi d'un processus de mise en œuvre linéaire et bureaucratique, c'est un échec.)

Pour les équipes Agile, la réponse à toutes ces questions devrait être oui.

Version graphique:



Des informations plus détaillées sur certaines fonctions des programmes du ministère de la Défense figurent à l'annexe A ( dix exigences logicielles ), à l'annexe B ( mesures pour le développement de logiciels ) et à l'annexe C (erreurs et règles logicielles [le lien sera ajouté ultérieurement]). )