BitTorrent Download mit Aria2 und Powershell

Im Rahmen von einem Projekt musste ich mich vor kurzem mit einem Dateidownload via BitTorrent intensiv beschäftigen. Dabei hab ich mir ein paar Open Source varianten angeschaut und bin schliesslich bei Aria2 hängen geblieben. Das Aria Projekt bietet eine ganze menge an Protokollen (HTTP, SFTP, FTP ,etc.) an, um Daten herunterzuladen. Bei der Analyse bin auf die RPC Schnittstelle gestossen, über die man Aria quasi fernbedienen kann. Die RPC Schnittstelle kann entweder Json oder XML Datenstrukturen verarbeiten.

Bei testen hab ich schnell ein paar Powershell skripte genutzt, um die Interaktion mit Aria besser zu verstehen. Als Vorbereitung muss man erstmal Aria konfgiurieren, damit die RPC Schnistelle überhaupt verfügbar ist. Man kann entwender alle Konfig-Parameter über die aria.config Datei einstellen oder man gibt einfach ein paar Kommandozeilenparameter beim Starten von Aria mit:

aria2c.exe --enable-rpc --rpc-listen-all

Bei der option –rpc-listen-all geht es nicht um den Port, sondern um das Network-Interface. D.h. ob Aria reagiert auf Call für localhost oder IP. Zum testen kann man einfach alle Interface anschalten und gut. Für später sollte man sich aber die Absicherungsmethoden wie SSL und Secrete-Token mal genauer anschauen.

Mit dem folgenden Powershell-Skript spricht man die RPC Schnittstelle an und übergibt einen Torrent File. Der Torrent File beinhaltet qausi die Informationen, welche Dateien von welchem BitTorrent Server geladen werden soll:

# setting vars
# url points to aria2 rpc host
$url = "http://localhost:6800/jsonrpc"
#path to torrent file
$torrent = "C:\002315_0001.torrent"
#directory to download to
$dir = "C:\\temp\\download"
 
#read the content of torrent file and encode base64
$enc = [convert]::ToBase64String((get-content $torrent -encoding byte))
 
#setting the command for rpc
$command = @"{"jsonrpc": "2.0","id": 11,"method": "aria2.addTorrent", "params": ["$enc",[],{"dir": "$dir"}]}
"@
 
#debug print 
write-host $command
 
#setting the weblient
$bytes = [System.Text.Encoding]::UTF8.GetBytes($command)
$web = [System.Net.WebRequest]::Create($url)
$web.Method = "POST"
$web.ContentLength = $bytes.Length
$web.ContentType = "application/x-www-form-urlencoded"
 
#executing against the rpc
$stream = $web.GetRequestStream()
$stream.Write($bytes,0,$bytes.Length)
$stream.close()
 
#read the responds from rpc
$reader = New-Object System.IO.Streamreader -ArgumentList $web.GetResponse().GetResponseStream()
$json = $reader.ReadToEnd() 
$reader.Close()
 
#convert the repond json in object
$null = [System.Reflection.Assembly]::LoadWithPartialName("System.Web.Extensions")
$ser = New-Object System.Web.Script.Serialization.JavaScriptSerializer
$obj = $ser.DeserializeObject($json)
 
#looking in the result
$gid = $obj.result
 
#debug print result
write-host $gid

Als erfolgreiche Rückantwort von der RPC Schnittstelle erhält man eine GID zurück. Das ist im Grunde nur ein eindeutiger Schlüssel für den gestarteten Download, über den man im nächsten Schritt abfragen kann, ob der Download fertig ist oder ob es schiefging. D.h. man fragt quasi den Status ab:

# setting vars
# url points to aria2 rpc host
$url = "http://localhost:6800/jsonrpc"
#gid unique identifier for the download job
$gid = "401ffd2682ba057c"
 
$command = '{"jsonrpc": "2.0", "method": "aria2.tellStatus", "params":["$gid"], "id": 1}'
 
#debug print 
write-host $command
 
#setting the weblient
$bytes = [System.Text.Encoding]::UTF8.GetBytes($command)
$web = [System.Net.WebRequest]::Create($url)
$web.Method = "POST"
$web.ContentLength = $bytes.Length
$web.ContentType = "application/x-www-form-urlencoded"
 
#executing against the rpc
$stream = $web.GetRequestStream()
$stream.Write($bytes,0,$bytes.Length)
$stream.close()
 
#read the responds from rpc
$reader = New-Object System.IO.Streamreader -ArgumentList $web.GetResponse().GetResponseStream()
$json = $reader.ReadToEnd() 
$reader.Close()
 
#convert the repond json in object
$null = [System.Reflection.Assembly]::LoadWithPartialName("System.Web.Extensions")
$ser = New-Object System.Web.Script.Serialization.JavaScriptSerializer
$obj = $ser.DeserializeObject($json)
 
#debug print result
write-host ($obj.result | Format-Table | Out-String)
 
#debug of status
$obj.result["status"]

Im Attribut Status stehen dann klar informationen wie Active, Complete, Error, etc. drinnen. Somit kann man dann entsprechend auf den Status reagieren und entweder die heruntergeladenen Daten im Download Verzeichnis abholen oder entsprechend neuaufsetzen und den Download noch mal starten, falls es einen Fehler gab.

Kleine Tipp noch am Rande, es gibt ein WebUi für Aria, der ebenfalls die RPC Schnittstelle nutzt. Das ist super praktisch wenn man debuggen möchte und man kann sich ein paar Beispiele anschauen, wie man mit der Schnittstelle umgeht falls man mehrere Befehle auf einmal an die RPC Schnittstelle senden möchte. Die Schnittstelle unterstützt nämlich Mulitcalls, d.h. man kann mehrere Befehle in einem Request an den Server stellen und erhält dem entsprechend auf mehrere Json formatierte Rückantworten.

http://www.agile-coding.net/bittorrent-download-mit-aria2-und-powershell/

Ökonomie in der agilen Softwareentwicklung

Seit ein paar Wochen beschäftige ich mich intensiv mit ASP und C# von Microsoft. In meiner Karriere als „Software-Projekt-Mensch“ habe ich bereits viele Projekte mit PHP und Java umgesetzt. Mir ist früher schon aufgefallen, dass der Overhead beim Entwickeln in einer Entwicklungsumgebung wie Visual Studio oder Eclipse wesentlich größer ist, als wenn ich schnell ein paar PHP Skripte mit Notepad++ in einem LAMP Stack hacke.

Dieses mal habe ich aber mal einen gut vergleichbaren Fall, da ich ein Web System mit PHP bereits vollständig gebastelt hatte und jetzt lediglich das Gleiche in ASP/C# umsetzen muss. In meinem jugendlichen Leichtsinn, dachte ich im ersten Moment dass es nicht lange dauern kann. Hab ja schon die gesamte Logik und muss das ja nur schnell mal von PHP nach C# „übersetzen“. Diese Meinung war vor allem geprägt davon, dass ich die Businesslogik innerhalb des Web System mit XML und XLST erledigt hatte. D.h. ich muss nur die gleichen XML Daten generieren und mit den gleichen Stylesheets transformieren. Ganz klar ging ich davon aus, dass 90% der gesamten Logik in allgemeingültiger Form bereits vorhanden sind. Dazu kommt, dass ich die Kommunikation mit dem Backend mit JQuery und Javascript erstellt und das komplette Layout war in HTML mit CSS3 gesetzt. Hier und da hab ich noch ein JQuery Plugin verwendet. So what! Ich muss ja nur ein bisschen das XSLT und die AJAX Verbindungen auf der Serverseite umbiegen.

Also erstmal Kaffee gekocht und die ersten vier Stunden gingen dafür drauf Visual Studio runterzuladen, Updates und Servicepacks zu installieren. Danach dann lizenzieren, Umgebung konfigurieren und die ersten paar Code-Schritte zu testen. Hierbei ist mir bereits klargeworden, dass es wesentlich länger dauert, wenn ich etwas codiere und mir das Ergebnis im Browser anzuschauen. Bei jedem Klick auf den Play-Button im Visual Studio, wird immer erst Codestruktur geprüft, kompiliert und im Lokalen Webserver deployed. Das dauert etwa 3-4 Sekunden bis überhaupt das Ergebnis im Browser anfängt zu laden. Übrigens, bei Java Projekten in Eclipse dauert das auch so lange bis man irgendwas im Browser überhaupt sehen kann.

Die gleichen Aktivitäten im LAMP Stack, kostet überhaupt keine Zeit. Klar, der Code wird nicht überprüft oder kompiliert. Das Deployment in den Webserver fällt bei mir auch weg, da ich bei PHP immer im Root Verzeichnis meiner Webseite entwickele. Der Vergleich klingt jetzt etwas merkwürdige, da ich im Grunde technologisch Äpfel mit Birnen vergleiche. Lasst mal das Technische weg und seht es mal rein vom Blickwinkel der Zeit die für das Entwickeln drauf geht. Da kommen im Laufe von ein paar Sprints schnell ein paar Minuten zusammen wo man nur auf das Ergebnis wartet. Und aus Minuten werden irgendwann auch Stunden…

Zeit ist ja ein entscheidender Faktor bei der kommerziellen Softwareentwicklung, da alles letztendlich unter finanziellen Gesichtspunkten entschieden wird. Hierbei sind die Aufwandsschätzungen der Entwickler ein wichtiger Faktor. Nur wenn gut und realitätsnah geschätzt wird, haben Projekte überhaupt eine Chance im finanziell „Grünen-Bereich“ zu kommen. Zum Thema Aufwandsschätzungen habe ich bereits ein paar Artikel verfasst, schaut einfach mal nach Planning Poker in agilen Entwicklungsprojekten mit SCRUM oder Der agile Festpreis. Dort habe ich jeweils die Aspekte für Zeit und Geld bereits genauer betrachtet.

Neben der Zeit die für das Warten auf das Ergebnis drauf geht, bin ich auch erstaunt wie viel Platz auf den Festplatten für die Projekte drauf geht. Im oben genannten PHP Projekt, hab ich mit allen Frameworks, Bilddaten und Plugins keine 800 Kilobytes auf der Festplatte des Webserers im Beschlag. Das vergleichbare C# Projekt hat etwa 2 Megabytes konsumiert. Nur noch mal zur Erinnerung, in beiden Webseiten stecken die gleichen XSLT, Bilddaten und Javascript Framework drinnen! Das C# Ergebnis ist fast 2,5 mal größer als das vergleichbare PHP Projekt mit dem gleichen Leistungsumfang.

Der verbrauchte Plattenplatz ist heute längst nicht mehr so kostenintensiv wie früher, trotzdem ist es ein Faktor in der ökonomischen Betrachtung. In Summe kann ich keine Vergleichsmatrix aufbauen, hierbei gehen Einsatzgebiete von C#, PHP und Java zu weit auseinander. Obendrein hab ich weder die Zeit oder den Platzkonsum der einzelnen Entwicklungsumgebungen vergleichbar gemacht. Wichtig an diesem Artikel ist, dass die genutzte Technologie nicht nur Auswirkungen auf die Funktionsweise eines Produktes hat, sondern auch direkte Auswirkung auf die Kommerziellen Aspekte. Allein durch die Nutzung der unumgänglichen Entwicklungsumgebungen, ist der Aufwand für C# oder Java Entwicklung immer größer als in einer Entwicklungsumgebung „weniger-abhängigen“ Sprache wie PHP. Man kann PHP Entwicklungsumgebungen nutzen, muss es aber nicht wenn man es nicht will. Diese Option gibt es nicht für C# oder Java.

Ich werde für mich in Zukunft die vorgenannten Faktoren stärker in Betracht ziehen, wenn ich nach Aufwand für die Umsetzung befragt werde.

http://www.agile-coding.net/oekonomie-in-der-agilen-softwareentwicklung/

Cookies mit PHP verwenden

Unter Cookies versteht man einen begrenzten Speicherbereich innerhalb des Browsers, der vom Server gesetzt und ausgelesen werden kann. Mit Cookies kann man quasi benutzerbezogene Informationen ablegen und vom Client und Server aus benutzen. Cookies sind im Grunde standardisiert und eigentlich alle Browserorientierte Programmiersprachen können Cookies verwenden. PHP bietet die Methode setcookie() zum setzen und die Globale Variable $_COOKIE zum Auslesen an.

Wie man die Daten innerhalb des Cookies organisiert, kann man selbst bestimmen. Viele Entwickler gehen her und setzen die Daten innerhalb des Cookies mit einem Trennzeichen. Im Folgenden Beispiel, werden drei Informationen (Username, SessionID und Role) in einen Cookie gesetzt. Die Daten werden mit einem Semikolon getrennt abgelegt:

/*combine the values */
$value = $user.';'.$sessioID.';'.$role;
 
/* set the values in the cookie */
setcookie("name of the cookie", $value, time()+3600)

Jeder Cookie muss man mit einem Namen versorgen, man kann hier zum Beispiel den Namen der Domain nehmen. Zusätzlich sollte jeder Cookie eine Haltbarkeitsdatum erhalten. Damit man der Browser die gespeicherten Informationen auch wieder vergessen kann. Das mach Sinn, wenn man eine Benutzer-Session über Cookies steuert. Ihr habt das bestimmt schon bei Websiten gesehen, wo man sich anloggen muss. Viele bieten beim Einloggen eine Option an, eingeloggt zu bleiben. Eine solche Funktion wird im Regelfall über Cookies realisiert.

Um die Informationen aus dem oben gesetzten Cookie wieder auslesen möchte, muss man in PHP die Globale Variable $_COOKIE auswerten:

/*pull the data in local var*/
$s = $_COOKIE; 
 
/*explode the data into dedicated vars*/
@list($user, $sessionID, $role) = explode(";", $s);

Zu den bereits genannten Optionen für einen Cookie, kann man noch optional angeben, ob der Cookie über eine verschlüsselte Verbindung genutzt werden soll (secure) und zusätzlich kann man unterbinden, dass der Cookie von anderen Browsersprachen wie Javascript (httponly) genutzt weden kann.

Man sollte aber immer sehr genau nachdenken, welche Informationen man in einen Cookie setzt. Wenn man wichtige Informationen klarlesbar in einen Browser setzt, kann das im Grunde zu einer Sicherheitslücke führen. D.h. das obige Beispiel darf man so nicht in der Produktion verwenden. Da der Speicherplatz in einem Cookie begrenzt ist, sollte man sparsam damit umgehen.

Vergesst bitte auch nicht, dass jeder User im Browser die Verwendung von Cookies einschränken kann. D.h. es besteht das Risiko, dass einzelne User gar keine Cookies akzeptieren oder viel kurzfristiger als man es erwartet, vom Browser einfach gelöscht werden.

http://www.agile-coding.net/cookies-mit-php-verwenden/

Der agile Festpreis

Hinter den Worten „agiler Festpreis“ versteckt sich ein sehr interessanter Ansatz, um die Probleme mit den kommerziellen Aspekten von agilen Entwicklungsmethoden (z.B. Scrum) zu lösen. Das Problem steckt vorallem in den heute üblichen Verträge, die meistens einen fest definierten Funktionsumfang beschreiben und auf deren Grundlage die Schätzungen von Personentagen, dann ein Fixpreis berrechnet. Die Veränderung des Funktionsumfanges oder meiste daraus resultierenden Änderung der Personentage, führt immer zu einem unangnehmen Diskussionsbedarf. Der agile Festpreis bietet genau für dieses Problem mögliche Lösungswege an.

Grundliegendes Element für die Etablierung eines agilen Festpreis Vertrages zwischen den Vertragspartnern ist ein offenes und vertrauensvolles Verhältnis. Die Nutzung für ein solches Vertragswerk im Neukundenumfeld nur schwierig zu realisieren. Einfacher ist es mit Vertragspartnern die bereits miteinander Erfahrungen gesammelt haben. Der Kunde muss schließlich das Vertrauen zu den Prognosen des Anbieter haben, um bei den Verhandlungen des Vertragswerkes bereits sicher zu sein, dass das gewünschte Produkt am Ende der Entwicklung auch funktioniert.

Die Funktionsweise des agilen Festpreises beginnt in der Erarbeitung des Produkt Backlogs. In dieser Phase müssen Epics aufgenommen und nach und nach werden detailiert. Unter einem Epic verstehen man quasi einen bestimmten Themenblock, dem User stories zugewiesen werden. Als Beispiel für ein Epic könnten man eine User Verwaltung nennen und eine dazugehörige User story könnte die folgende sein: Als ein Benutzer möchte ich mich selbst registrieren können. Dieses Product Backlog erstellen die Vertragspartner am besten innerhalb von Workshops. Je nach Größe des Vorhabens können das auch mehrere Workshops sein, zumindest bis zu dem Punkt wo es keine neuen Ideen entstehen. In der Scrum Terminologie sind die Teilnehmer dieser Workshops meistens die sog. Stakeholder. D.h. der Personenkreis der bestimmt was das Product können soll. Wenn das Product Backlog nun existiert und soweit konkretisiert ist, dass das Scum Team mit den Schätzungen anfangen kann, dann muss das Product Backlog vor dem Hinzukommen neuer Epics geschützt werden. Jetzt muss das Scrum Team die einzelnen Stories schätzen und falls User Stories nicht fein genug detailiert wurde, ist der Product Owner gefragt, diese offenen Stories mit den Stakeholdern zu klären. Ob und wie eine User Story als „abarbeitbar“ definiert, nennt man Definition of Ready (DOR). Entspricht eine User Story nicht diesem Standard, wird das Team diese auch nicht in die Schätzung mit aufnehmen. Wenn das Scrum Team seine Arbeit beendet hat und alle Storypoints summiert sind, kann die nächste Phase der Vertragsverhandlungen beginnen. Die Vertragpartner kennen jetzt quasi den maximalen Funktionsumfang und die dafür nötigen Storypoints. Man kann quasi vergleichen, dass der eingangserwähnte fest definierte Funktionsumfang und die Schätzungen von Personentagen vorliegen. Nun muss der Anbieter nur noch den Geldwert für einen Storypoint nennen und schon kann man die Gesamtkosten der Produktentwicklung ausrechen. Wie kommt man jetzt aber an diesen Multiplikator? Hierfür muss die durschnittliche Verlocity eine Scrum Teams nehmen, durch die Anzahl der Teammitglieder teilen und mit dem typischen Internen Kostensatz für einen Mitarbeiter multiplizieren. Der Interne Kostensatz für Mitarbeiter benutzen viele Unternehmen bereits für die Berechung von Stundensätzen. Zusätzlich darf man nicht vergessen noch den den Gewinnen in dieser Rechnung mit auf zunehmen. Eine Beispiel Rechnung könnte so aussehen:

Durschnittliche Velocity des Teams ist 35
Das Team besteht aus 7 MitgliedernDer Interne Kostensatz liegt bei 70,- €
Der geforderte Gewinn liegt bei 100,-€

Daraus ergibt sich die Rechnung: 35 / 7 * (70 + 100) = 850,- €

Der Preis für einen Storypoint  wird vertraglich fixiert und wird im Verlauf des Entiwicklungsprozess auch nicht verändert. Die Zahl sollte trotzdem kurz vor der Vertragsverhandlung berechnet werden, da sich die durschnitlliche Velocity im Verlauf eines Jahres verändern kann.

Im Verlauf dieser Phase der Vertragsverhandlungen wurde nun der Gesamtumfang und die Gesamtkosten des Entwicklungsvorhabens ermittelt. Weiterhin wird nun die Summe der Storypoints festgelegt, die das Scrum Team mindestens im Verlaufe jedes Sprints erreichen muss. Diese Festlegung erlaubt nun das Berechnen des spätesten Fertigstellungsdatum. Zusätzich kann diese Festlegungen nun dazu dienen, dass die Vertragspartner das Vorhaben vorzeitig beenden können. Wenn quasi die Lieferquote aus irgendwelchen Gründen nicht eingehalten werden kann, ist es den Vertragspartnern möglich den Vertrag zu kündigen.

Da nun der späteste Liefertermin bekannt ist, wird auch der Zahlungstermin definiert. Im besten Fall einigen sich die Vertragparteien auf die Zahlung von Sprints. D.h. immer wenn Teilabnahmen im Rahmen des Scrum Reviews Meetings durchgeführt wurde, wird eine Teilrechnung fällig. Die Vorteile dieser Methode liegt klar auf der Hand, der Lieferant hat keine lange Vorfinanzierung zu leisten und der Kunde erhält zeitnahe ein funktionierendes Inkrement des gewünschten Produktes.

Das Thema des agilen Festpreises ist sicherlich wesentlich umfangreicher als ich es hier in diesem Artikel darstellen kann. Es gibt am Markt Bücher die mehrere hundert Seiten starkt sind. Zusätzlich hat jedes Unternehmen eine andere Implementierung aus dem Scrum Framework. Somit muss auch die Implementierung des agilen Festpreises für jedes Unternehmen in angepasster Form durchgeführt werden. Trotzdem kann ich es aber sehr empfehlen, zu dem Thema zu recherchieren und zu prüfen ob man Methoden auf dem Gesamtkonstrukt anwenden möchte. Ich halte es für eine sehr interresante Variante, um die kommerziellen Probleme in der agilen Softwareentwicklung anzugehen.

http://www.agile-coding.net/der-agile-festpreis/

Vorlage für User Stories (User Story Template)

User Stories sollten nach einem bestimmten Muster erstellen und im Product Backlog verwaltet werden. Wenn man User Stories immer nach dem gleichen Muster gestaltet, erhöht man die Chance im Team ein gemeinsames Verständnis für die Aufgabe zu erlangen.

Jede User Story sollte die folgenden informellen Aspekte erfüllen:

  • Wer wird diese Feature in erster Konsequnz nutzen?
  • Gibt es noch weitere Nutzer?
  • Was muss im Endeffekt getan werden?
  • Welchen „geschäftlichen“ nutzen hat das Feature?
  • Mit welchen anderen Features hängt es ggf. zusammen?

Je nachdem wie das Team User Stories definieren möchte, könnte man noch die folgenden Informationen ebenfalls hinzufügen:

  • Wie wird das Feature demonstriert?
  • Wie wird das Feature getestet?

Um alle diese Informationen in eine User Story aufnehmen zu können, sollte man jede User Story nach einer gewissen Strutkur aufbauen. Eine der meisten verwendeten Vorlagen ist gestaltet sich nach dem folgenden Muster:

Als ein Administrator von der Benutzerverwaltung, möchte ich über die Anzeigeliste der Benutzerkonten der Lage sein, Benutzerkonten vollständig zu administrieren. D.h. ich möchte Benutzerkonten anlegen, bearbeiten und löschen können.  Jedes Benutzerkonto muss die folgenden Informationen haben:

  1. Benutzername (Mindestens 8 Zeichen, der Benutzername darft nicht die eMail Adresse sein)
  2. Anrede (Herr oder Frau als Auswahlbox)
  3. Vollständiger Name (Vor- und Nachname getrennt)
  4. Adresse (Strasse, Hausnummer, Postleitzahl und Ort getrennt)
  5. eMail Adresse (Eingabe auf „@“ und „.“ zu prüfen)
  6. Passwort (Mindestens 6 Zeichen, bestehend aus min. einem Großbuchstaben und min. 2 Sonderzeichen)

Die Möglichkeit des Anlegens, Editierens und Löschens sollen in einzelnen Dialogen realisert werden. Ich benötige diese Feature, um Benutzerkonten losglöst vom Registrierungsprozess verwalten zu können.

Diese Beispiel User Story beantwortet alle Fragen aus der obigen Anforderungsliste. Überprüfen wir diese Festellung an Hand der gestellten Fragen:

  • Wer wird diese Feature in erster Konsequnz nutzen? Administratoren
  • Gibt es noch weitere Nutzer? Nein
  • Was muss im Endeffekt getan werden? Benutzerkonten Bearbeitunsfunktionen auf der Liste der Benutzerkonten durchzuführen
  • Welchen „geschäftlichen“ nutzen hat das Feature? Eigenständige Verwaltung der Benutzerkonten durch den Administrator
  • Mit welchen anderen Features hängt es ggf. zusammen? Mit dem Registrierungsprozess und der Übersichtsliste der Benutzerkonten

Man findet in User Stories explizite und impliziete Anforderungen. Ich fokusiere das Teams gerne auf die implizieten Anforderungen und spreche diese in den Scrum Meetings durch. Das ist wichtig da impliziete Anforderungen immer durch die Wahrnehmung jedes Team Mitgliedes ggf. anders Wahrgenommen werden können als explizite Features. Um das Risiko eines Missverständnisses zu verringern, muss man als Scrum Master darauf achten, dass die Diskussion innerhalb der Gruppe die Features von allen Seiten betrachtet. Ich versuche daher gerne ähnliche Umsetzungen in anderen Produkten als Beispiel zu zeigen. Zu dieser Anforderung an eine Benutzerverwaltung würde ich z.B. die Benutzerverwaltung von WordPress zeigen, um die Diskussion über die User Story zu unterstüzen.

Wichtig ist es in den Grooming Sessions und in der Sprint Planung muss das Team die User Story mit Informationen zur Umsetzung anreíchern. Das geschieht meistens automatisch innerhalb der Diskussion. Während der Diskussion enstehen meistens Fragen zu den einzelnen User Stories und diese Fragen müssen geklärt und an die betreffende Stelle in der User Story geschrieben werden. Im obigen Beispiel erkennt man diese zusätzlichen Informationen aus der Disskussion innerhalb der Klammern.

User Stories sind „Lebendegebilde“ und werden von Meeting zu Meeting verändert, erweitert oder neu aufgeteilt. Sollte das Team feststellen, dass eine User Story eigentlich zu groß und damit zu unverständlich ist, Muss man versuchen Teile der User Story in eigene User Stories herunter zu brechen und neu zu definieren. Im obigen Beispiel könnte man zum Beispiel das Anlegen, oder das Editieren in eigene User Story auslagern.

Das gemeinsame Verständnis innerhalb des Teams für den Inhalt einer User Story sehr wichtig. Für manche Teams kann es hilfreich sein eine Definition of Ready DOR zu definieren. Die DOR defniert welche Kriterien eine User Story erfüllen muss, um als READY zur Umsetzung zu betrachten. Das hilft dem Product Owner bereits frühzeitig zu erkennen, welche Informationen für eine User Story bereitgestellt werden müssen und erleichtert in der Sprint Planung die Auswahl von einzelnen User Stories für den angehenden Sprint.

http://www.agile-coding.net/vorlage-fuer-user-stories-user-story-template/