Ein Artikel über den Prozess agiler Softwareentwicklung. Von der Idee zur Implementierung.
Agile Softwareentwicklung bezieht sich auf Softwareentwicklungsmethoden, die auf der Idee der iterativen Entwicklung basieren, bei denen selbstorganisierten, funktionsübergreifenden Teams zusammen arbeiten und Lösungen entwickeln. Der jeweilige Wert oder Nutzen für den Kunden wird durch die Priorisierung abgebildet. Damit wird in jeder Stufe immer vorrangig der höchste Kundenwert mit Ressourcen versorgt, danach absteigend die anderen Anforderungen.
In der Softwareentwicklung ist agil (manchmal auch agile oder Agile geschrieben) eine Reihe von Praktiken, die die Effektivität von Softwareentwicklern, Teams und Organisationen deutlich verbessern. Sie beinhaltet die Ermittlung von Anforderungen und die Entwicklung von Lösungen durch die Zusammenarbeit von sich selbst organisierenden und funktionsübergreifenden Teams und ihren Kunden/Endbenutzern.
Sie befürwortet eine adaptive Planung, eine evolutionäre Entwicklung, eine frühzeitige Lieferung und eine kontinuierliche Verbesserung und fördert flexible Reaktionen auf Änderungen der Anforderungen, der Verfügbarkeit von Ressourcen und des Verständnisses der zu lösenden Probleme.
Scrum, eine agile Entwiklungsmethode, wird für Projekte wie Webtechnologie oder die Entwicklung eines Produkts für einen neuen Markt, d.h. ein Produkt mit vielen Anforderungen oder sich schnell ändernden Anforderungen, verwendet. Sie ist die Basis für diesen Artikel.
NEW
1
Stories(User-Story), ehemals Anforderungen, können direkt aus den Fachbereichen kommen oder es sind organisatorisch unterstützende Business-Analysten vorhanden. Letztere führen Interviews in den Fachbereichen durch und sorgen dafür, dass alle Aspekte der Story besprochen und genannt werden. Empfehlenswert sind Abstimmungen mit Fachabteilungen, Umsetzern und Business-Analysten.
2
In einem Akzeptanzprozess wird die Vollständigkeit der Story mit allen notwendigen Parametern überprüft und ggf. die Klärung oder Ergänzung organisiert und vorgenommen. Dieser Prozess wird von der Entwicklungsabteilung vorgenommen. Alle notwendigen Formulare, Regeln, Voraussetzungen sind in der jeweiligen Fachabteilung bekannt. Dazu sind Schulungen vor Einführung des agilen Prozesses sehr sinnvoll.
3
Die Story bekommt eine Priorisierung. Das Team legt die Priorisierung fest und orientiert sich dabei an den schon vergebenen Priortitäten. Die Priorität im Vergleich zu allen anderen im Prozess vorhandenen Aufgaben vergeben. Die Priorität ist äusserst wichtig für die Durchlaufgeschwindigkeit(velocity) bis zur und innerhalb der Umsetzung. D.h. niedrig priorisierte Stories werden auch in den Folgeprozessen mit niedriger Priorität bearbeitet. Stories mit hoher Priorität können andere Stories auch vor der Umsetzung „überholen“
4
Sind alle inhaltlichen Voraussetzungen erfüllt, erfolgt die Übergabe in das SCOPING
SCOPING
1
In regelmäßig stattfindenden Scoping-Meetings sitzen Product-Owner
und Entwicklung zusammen und führen das Scoping durch.. Am Ende des Prozesses wird die sogenannte T-Shirt-Size festgelegt.
2
Ggf. wird eine Story in mehrere Stories zerlegt. Danach wird jede Story gemeinsam reflektiert, gemeinsames Verständnis über sie hergestellt und grob das Wie der Umsetzung festgelegt
3
Am Ende des Prozesses wird die sogenannte T-Shirt-Size festgelegt. Die T-Shirt Sizes sind vorher für das Projekt festgelegt worden. Das kann z.B. sein:
4
Übergabe ins BACKLOG
BACKLOG
1
Übernahme der Story in das Backlog.
2
Es entsteht eine priorisierte Liste aller Stories.
3
Übergabe in Grooming.
GROOMING
1
Backlog Grooming, auch als Backlog Refinement oder Story Time bezeichnet, ist ein wiederkehrendes Ereignis für agile Produktentwicklungsteams. Der Hauptzweck einer Backlog-Grooming-Sitzung besteht darin, sicherzustellen, dass die Stories der nächsten Sprints im Product Backlog für die Sprintplanung vorbereitet sind. Das Ergebnis sind eine exakte Aufwandsschätzung je Story.
2
Außerdem werden für jede Story die Akzeptanzkriterien des Ergebnisses festgelegt. Es sind Bedingungen, die die Software erfüllen muss, um die Bedürfnisse der Kunden zu befriedigen.
3
Übergabe an Todo.
TODO
1
Die Stories finden sich in der „TO DO“-Liste wieder. Diese ist elementar für das Sprint-Planning-Meeting. In diesem Meeting matchet das Team mit dem Product-Owner die im nächsten Sprint vorhandenen Ressourcen mit den in der „TO DO“-Liste vorhandenen „Ready-To-Run“ Stories.
2
Die im nächsten Sprint umzusetzenden Stories werden für das im Sprint zu erstellende Release vorgesehen und aus der „TO DO“-Liste entnommen. Sie werden Teil der Sprintdefinition.
SPRINT
1
Ein Sprint ist ein wiederholbares, festes Zeitfenster, in dem ein „fertiges“ Produkt von höchstmöglichem Wert erstellt wird. Der Sprint ist der Kern der agilen Methodik und kann als ein Ereignis betrachtet werden, das z.B. in Scrum alle anderen Scrum-Ereignisse wie Daily Scrum, Scrum Review und Sprint Retrospective einschließt.
2
Es finden tägliche Besprechungen statt, um den Fortschritt des Projekts und etwaige Schwierigkeiten zu erörtern, mit denen ein Teammitglied bei der Durchführung des Projekts konfrontiert ist.
Jeder Mitarbeiter nimmt zu jeder seiner Stories kurz Stellung:
- Was habe ich geschafft?
- Was mache ich heute?
- Was blockiert mich? Wo brauche ich Hilfe?
Das Ergebnis des Sprints ist ein fertiges Produkt, wenn auch mit einigen Abstufungen.
RELEASE
1
Das fertig entwickelte und getestete Produkt wird formal an das Release-Management übergeben. Inhalte sind:
1. Programm im vereinbarten Fomat (kompiliert, vorkompiliert, Source)
2. Release-Notes die alle Unterschiede zur Vorversion(Neue Funktion, Bugfix) und ggf. eine Konfigurationsanleitung enthalten.
2
Das Release-Management prüft auf Vollständigkeit. Ggf. werden noch Rückfragen an die Entwicklung gestellt und das Feedback mit in die Release-Notes aufgenommen.
3
Das Release-Management organisiert das Deployment in das oder die Live-System(e).