Der Titel fasst die Frage ziemlich gut zusammen. Wie machst du das? Sollten Sie die Implementierung von HTTPS überhaupt zu einer User Story machen?
Ich dachte an:
" Als Seitenbesucher möchte ich, dass die gesamte Kommunikation mit dem Dienst sicher ist, damit die Datenintegrität gewahrt bleibt ". Klingt ziemlich doof, wenn du mich fragst. Andersherum wäre:
" Als technischer Manager möchte ich, dass der Zugriff auf Webseiten sicher ist, damit die Informationen des Seitenbesuchers sicher sind ". Klingt auch blöd.
Ich würde mich eher auf die Notwendigkeit als auf die Umsetzung konzentrieren. Die User Story wäre dann einfach:
„Als Benutzer möchte ich, dass alle personenbezogenen Daten, die ich (dem Unternehmen) gebe, privat und sicher bleiben.“
Wobei HTTPS dann ein Implementierungsdetail dieser Geschichte ist. Wenn Sie schließlich andere Mittel finden würden, um die Anforderung zu erfüllen (z. B. überhaupt keine persönlichen Informationen zu erhalten), wäre HTTPS irrelevant.
Sie könnten auch so etwas wie "sogar von einem böswilligen Angreifer" anhängen, was es besser testbar machen sollte (siehe INVEST-Mnemonik ) - stellen Sie sicher, dass alle gängigen Angriffe (außer Social Engineering, das nicht wirklich lösbar ist ...) fehlschlagen.
Denken Sie nur daran, dass es dem Benutzer nicht wirklich wichtig sein sollte, ob die Webseite sicher ist. Sie kümmern sich darum, dass ihre Daten nicht kompromittiert werden. Sie könnten eine (möglicherweise sehr große) User Story haben, in der alles Notwendige gesichert ist. (Abhängig davon, wie groß es ist, kann es INVEST jedoch ungültig machen.)
Alternativ könnten Sie es in Ihre Definition of Done backen (siehe diese Antwort ). Beachten Sie, dass das DoD an und für sich keine User Story, Task oder Epic ist – es ist ein Teil der Akzeptanzkriterien für Storys. Wenn Ihr DoD eine ausreichende Sicherheit als Anforderung enthält und Sie eine Story haben, die diese Sicherheit noch nicht hat, kann die Story nicht als „Fertig“ betrachtet (und somit niedergebrannt) werden, bis sie die DoD-Anforderungen erfüllt.
Erstens missbrauchen Sie potenziell User Stories als Mechanismus. Eine User Story entsteht aus einem echten Bedürfnis heraus, sie sollte nicht erfunden oder verändert werden, um zum Prozess zu passen.
Wie auch immer, es könnte so etwas sein:
Als Chief Security Manager möchte ich, dass die gesamte Kommunikation zwischen all unseren Anwendungen und allen Clients über HTTPs erfolgt, damit das Risiko eines MITM-Angriffs verringert wird.
Oder:
Als Seitenbesucher möchte ich in meinem Browser ein „grünes Schloss“ sehen, damit ich mich sicher und geschützt fühle.
Beachten Sie den Unterschied zwischen den beiden. Wenn Sie beispielsweise eine mobile App mit Client-Server-Interaktion haben, zwingt Sie eine API – First Story, diese ebenfalls zu behandeln.
Sie könnten es auch einfach als allgemeine "Aufgabe" haben. Nicht alles muss in einem User-Story-Format geschrieben werden.
Als Aufgabentitel würde ich „HTTPS implementieren“ empfehlen.
User Stories eignen sich hervorragend, um ein Problem zu beschreiben, insbesondere aus Kundensicht (oder in der Rolle eines Kunden). Sie helfen den Kunden auch, ihre Probleme so zu strukturieren, dass sie weniger wahrscheinlich das vorschlagen, was sie für eine Lösung halten.
Aber man muss praktisch sein, das gehört zum agilen Manifest.
Hier gibt es kein Missverständnis des Problems; Es gibt keine großartige Interpretation und es ist keine „Aufgeschlossenheit“ erforderlich. Eine User Story könnte in diesem Fall ein ansonsten klares Ergebnis trüben.
Tun Sie sich und Ihrem Team einen Gefallen, indem Sie es einfach halten. Aber auf jeden Fall protokollieren, nachverfolgen und eine Definition of Done erstellen, damit es getestet und dimensioniert werden kann.
Sarow
Mohammed