Von einem Übersetzer: Dies ist der DIB-Leitfaden: Erkennung agiler BS (Version 0.4) , den das Innovationskomitee des US-Verteidigungsministeriums (DIB) am 9. Oktober 2018 öffentlich veröffentlicht hat.

Agile ist ein Schlagwort in der Softwareentwicklung, daher sind alle Softwareprojekte des Verteidigungsministeriums standardmäßig fast „flexibel“. Dieses Dokument wird Programmmanagern und Spezialisten des Verteidigungsministeriums helfen, Softwareprojekte mit einer wirklich flexiblen Methodik von Projekten zu unterscheiden, die einfach „Wasserfall“ oder „Spirale“ („Agile-Scrum-Fall“) unter dem Deckmantel von Agile verwenden.

Prinzipien, Werte und Werkzeuge

Agile Experten und Enthusiasten identifizieren Schlüsselkennzahlen, die diese Kultur und diesen Ansatz für eine agile Entwicklung charakterisieren. In seiner Arbeit hat DIB eigene Richtlinien entwickelt, die in etwa die wahren Werte von Agile widerspiegeln:

Agiler Wert	DIB-Prinzip
Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge	„Kompetenz ist wichtiger als Prozess“
Das Ausführen von Software ist wichtiger als die vollständige Dokumentation	„Reduzieren Sie die Zeit vom Start des Projekts bis zur Bereitstellung der einfachsten Grundfunktionen.“
Zusammenarbeit mit einem Kunden, um einen Vertrag zu vereinbaren	"Implementierung der DevSecOps-Kultur für Softwaresysteme"
Auf Planänderungen reagieren	"Programme sollten klein anfangen, iterativ sein und auf Erfolg aufbauen - oder sie werden schnell zurückgesetzt."

Wichtige Anzeichen dafür, dass das Projekt nicht sehr flexibel ist:

• Keines der Entwicklungsteams kommuniziert mit Benutzern oder verfolgt Software in Aktion. Wir meinen echte Benutzer von echtem Code. (Die Programmevaluierungsabteilung wird nicht wie ein leitender Angestellter als echter Benutzer betrachtet, es sei denn, er verwendet das Programm in seiner Arbeit.) Akzeptable Alternativen zur Kommunikation mit Benutzern: Überwachung ihrer Arbeit, Weitergabe von Prototypen an sie für Feedback und andere Forschungsmethoden, die nicht viel verbale Kommunikation erfordern.
• Es gibt kein ständiges Feedback von Benutzern für das Entwicklungsteam (Fehlerberichte, Bewertungen). Es reicht nicht aus, zu Beginn des Projekts einmal zu sprechen, um die Anforderungen zu überprüfen!
• Compliance wird als wichtiger angesehen, als so schnell wie möglich das am wenigsten nützliche Ergebnis zu erzielen.
• Stakeholder (Entwicklung, Test, DevOps, Sicherheit, Auftragnehmer, Endbenutzer usw.) arbeiten mehr oder weniger autonom (zum Beispiel „das geht mich nichts an“).
• Endbenutzer sind nicht an der Entwicklung beteiligt. Sie sollten mindestens während der Release-Planung und der Abnahmeprüfung vorhanden sein.
• Es gibt nicht genügend DevSecOps-Kultur, wenn Prozesse, die automatisiert werden können und sollten, manuell ausgeführt werden (z. B. Testen, kontinuierliche Integration, kontinuierliche Bereitstellung).

Einige typische agile Entwicklungswerkzeuge (sie ändern sich als
das Aussehen der Besten):

• Git, ClearCase oder Subversion ist ein Versionskontrollsystem zum Verfolgen von Änderungen im Quellcode. Git ist der De-facto-Standard in der modernen Entwicklung.
• BitBucket oder GitHub - Hosting von Repositories. Es verfolgt auch Tickets, verfügt über „Anwendungen“ für die kontinuierliche Integration und andere Tools zur Verbesserung der Produktivität. Weit verbreitet in der Open Source Community.
• Jenkins, Circle CI oder Travis CI ist ein kontinuierlicher Integrationsdienst zum Erstellen und Testen von Bitbucket- und GitHub-Projekten.
• Chef, Ansible oder Puppet - Software zum Erstellen von „Rezepten“ für die Konfiguration und zum Senden von Konfigurationsaufgaben sowie zur Unterstützung einer Reihe von Servern.
• Docker ist ein Computerprogramm, das Virtualisierung auf Betriebssystemebene durchführt, auch als Containerisierung bezeichnet.
• Kubernetes oder Docker Swarm für die Container-Orchestrierung.
• Jira oder Pivotal Tracker - Tickets, Überwachung und Verwaltung.

Grafikversion:

Fragen an Entwickler

• Wie testest du den Code? (Falsche Antworten: „Wir haben eine spezielle Organisation zum Testen“, „Die Test- und Produktbewertungsabteilung ist für das Testen verantwortlich“)
  
  • Erweiterte Version: Welche Tools verwenden Sie für Komponententests, Regressionstests, Funktionstests, Sicherheitsscans und Bereitstellungszertifizierungen?
• Wie automatisiert sind die Entwicklungs-, Test-, Sicherheits- und Bereitstellungspipelines?
  
  • Erweiterte Version: Welche Tools verwenden Sie für die kontinuierliche Integration (CI), die kontinuierliche Bereitstellung (CD), Regressionstests und die Programmdokumentation? Ist Ihre Infrastruktur codegesteuert?
• Wer sind Ihre Benutzer und wie interagieren Sie mit ihnen?
  
  • Erweiterte Version: Welche Mechanismen verwenden Sie, um direktes Feedback von Benutzern zu erhalten? Mit welchem ​​Toolset erstellen Sie Fehlerberichte und verfolgen Tickets? Wie verteilen Sie die Fehlerbehebungsarbeit auf die Teams? Wie informieren Sie Benutzer darüber, dass ihre Probleme gelöst und / oder bereits gelöst werden?
• Was ist die Frist für aktuelle und zukünftige Veröffentlichungszyklen?
  
  • Erweiterte Version: Welche Softwareplattformen unterstützen Sie? Verwenden Sie Container? Was sind Ihre Konfigurationsmanagement-Tools?

Fragen an Projektmanager

• Wie viele Programmierer sind Teil der Organisation, die das Budget zuweist, und was sind die Hauptphasen des Programms? (Falsche Antworten: "Wir wissen es nicht", "Null", "Es hängt von der Definition eines Programmierers ab")
• Was sind Managementmetriken für Entwicklung und Betrieb? wie sie verwendet werden, um Prioritäten zu kommunizieren, Probleme zu identifizieren; Wie oft sehen und verwenden sie das Handbuch?
• Was haben Sie in den letzten drei Sprints gelernt und wie wenden Sie das neue Wissen an? (Falsche Antworten: "Was ist ein Sprint?", "Wir warten auf die Zustimmung der Führung")
• Wer sind die Benutzer, die von jedem Sprintzyklus profitieren? Kann ich mit ihnen sprechen? (Falsche Antworten: "Wir stellen den Code nicht direkt für Benutzer bereit")

Fragen an Kunden und Benutzer

• Wie kommunizieren Sie mit Entwicklern? Überwachen sie Ihre Arbeit und stellen relevante Fragen, die auf ein tiefes Verständnis Ihrer Bedürfnisse hinweisen? Wann saßen sie das letzte Mal in der Nähe und diskutierten die Funktionen, die Sie sehen möchten?
• Wie reiche ich Vorschläge für neue Funktionen ein oder melde Probleme oder Fehler im Code? Welches Feedback erhalten Sie für Ihre Anfragen / Berichte? Wurden Sie jemals gebeten, Prototypen neuer Softwarefunktionen auszuprobieren, und haben beobachtet, wie Sie sie verwenden?
• Wie lange dauert es, die angeforderte Funktion in der Anwendung zu implementieren?

Fragen zur Orientierung

• Wird eine funktionierende Version der Software bei jeder Iteration (einschließlich der ersten) an mindestens eine kleine Stichprobe realer Benutzer geliefert und werden Bewertungen gesammelt? (Hinweis: alle zwei Wochen)
• Gibt es eine Produktcharta, in der die Mission und die strategischen Ziele festgelegt sind? Verstehen alle Teammitglieder beides? Sehen sie, wie ihre Arbeit zur Erreichung der Ziele beiträgt?
• Werden Benutzerbewertungen zu spezifischen Aufgaben für Sprintteams mit einer Frist von weniger als einem Monat?
• Sind Teams berechtigt, Anforderungen basierend auf Benutzerfeedback zu ändern?
• Haben Teams das Recht, ihren Prozess basierend auf dem, was sie während der Entwicklung gelernt haben, zu ändern?
• Ist das gesamte Ökosystem Ihres Projekts flexibel? (Wenn auf die agile Entwicklung ein linearer, bürokratischer Implementierungsprozess folgt, ist dies ein Fehlschlag.)

Für agile Teams sollte die Antwort auf all diese Fragen Ja sein.

Grafikversion:



Weitere Informationen zu einigen Funktionen der Programme des Verteidigungsministeriums finden Sie in Anhang A ( Zehn Softwareanforderungen ), Anhang B ( Metriken für die Softwareentwicklung ) und Anhang C (Softwarefehler und -regeln [Link wird später hinzugefügt]]. )