Backlogs im Scrum-Prozess

Im Scrum-Prozess wird oftmals zwischen Sprint-Backlog, Produkt-Backlog und Release-Backlog unterschieden. Das Sprint-Backlog besteht dabei aus den Aufgaben (im weiteren Verlauf Stories genannt), die das Team für eine Iteration (Sprint) angenommen hat. Das Ziel eines jeden Sprints ist es, dass alle angenommenen Stories bis zum Ende des Sprints erledigt werden. Ist dies nicht der Fall, wandern nicht erledigte Stories entweder zurück ins Produkt-Backlog oder in den nächsten Sprint.

Sprint Backlog zur Verwaltung von Stories, die sich in einem Sprint befinden

Das Produkt-Backlog (kurz: Backlog) ist eine Ansammlung von Stories, die für das Team bereitstehen und in nächster Zeit umgesetzt werden sollen. Der Product Owner pflegt das Backlog, erstellt neue Stories und schreibt die Anforderungen von Stories aus. Das Team kommt mit dem Product Owner und dem Scrum Master in Estimation Meetings zusammen, um Stories aus dem Produkt-Backlog zu schätzen. Dabei wird oftmals als Schätzeinheit auf Story Points zurückgegriffen, welche nicht den Aufwand, sondern die Komplexität einer Story darstellen.

Das Product Backlog beinhaltet alle Stories des Produktes/Teams, die der Product Owner bereits erfasst hat. Stories werden darin priorisiert.

Mit Hilfe von geschätzten Stories und der Velocity, also dem Durchsatz an Story Points, den das Team bisher erzielt hat (bzw. die Anzahl der Story Points, die das Team pro Sprint erledigt), kann eine Vorausschau bzgl. der Fertigstellung von Stories erstellt werden. Dies kann zum Beispiel dazu genutzt werden, einen Release-Plan auf Basis von Stories zu erstellen. Doch werden Stories oftmals erst im Laufe eines Projektes generiert und folglich erst später geschätzt, weshalb diese Methode für größere Projekte nicht unbedingt geeignet ist. Daher besteht das Release-Backlog bisweilen nicht aus Stories, sondern aus sog. Master Stories. Diese werden grob geschätzt und eine ungefähre Komplexität wird angegeben. Im Verlauf des Projektes werden die einzelnen Stories einer Master Story erstellt und geschätzt und die Abweichung zur Master Story berechnet. Dies fließt in das Burn-Up-Chart ein, welches zur Visualisierung von Projekt-Fortschritten eingesetzt wird. Durch das grobe Schätzen am Anfang und dem granularen Schätzen während des Projektes, wird die Menge der zu erledigenden Aufgaben ggf. im Laufe eines Projektes steigen. Ein Beispiel eines solchen Burn-Up-Charts, der im Laufe des Projektes ansteigt, zeigt die folgende Abbildung:

burn-up-chart-270x250@2x

Das Release Backlog kann eine Untermenge des Product Backlogs darstellen und liefert eine Aussage darüber, wann ein Teilprojekt ausgeliefert werden könnnte.

Neben den Backlogs zur Verwaltung von Stories, welche vom Team und dem Product Owner eingesetzt werden, verfügt auch der Scrum Master über ein eigenes Backlog. In diesem Impediment-Backlog werden alle Hindernisse und potentielle Optimierungen festgehalten. Der Scrum Master nimmt – beispielsweise aus der Sprint-Retrospektive oder dem Daily Stand-up (bzw. Daily Sprint) – Aufgaben auf, die durch das Team generiert oder durch den Scrum Master als Verbesserungspotential erkannt wurden. Der Fortschritt zur Abarbeitung der darin enthaltenen Punkte kann somit visualisiert und eine Priorisierung vorgenommen werden. Das Impediment-Backlog sollte dabei zumindest für das gesamte Team einsehbar sein.

Meetings im Scrum-Prozess

Meetings im Scrum-Prozess

Estimation

In regelmäßigen Abständen findet ein sog. Estimation Meeting statt, um neue Stories zu schätzen oder bereits geschätzte Stories nochmals zu schätzen. Das Ziel, diese Schätzungen in einem regelmäßig stattfindenden Meeting durchzuführen, liegt darin, dass das Team während des Sprints so nicht in seiner Arbeit unterbrochen wird.
Das Estimation Meeting dient dem Product Owner einzuordnen, wie komplex eine Aufgabe ist und er erhält Rückmeldung darüber, ob noch weitere Informationen von ihm oder dem Kunden benötigt werden, um eine Story zu schätzen bzw. im nächsten Sprint anzugehen. Der Product Owner überträgt die Schätzungen in die Stories in dessen Produkt-Backlog und lässt Schätzungen ggf. bei der Priorisierung mit einfließen.

  • Üblicherweise wird ein Estimation Meeting pro Sprint durchgeführt
  • Die Moderation übernimmt der Product Owner
  • Alle Team-Mitglieder schätzen die Stories
  • Eine Meeting-Dauer von 30 bis maximal 90 Minuten sollte angestrebt werden

Sprint Planning 1

In diesem Meeting stellt der Product Owner eine Reihe von Stories aus seinem Produkt-Backlog vor, die er im nächsten Sprint umgesetzt haben möchte. Im Dialog mit dem Team werden die Möglichkeiten zur Umsetzung der Stories erörtert, fehlende Angaben ergänzt und das Team übernimmt Stories in das Sprint-Commitment. Der Scrum Master moderiert das Meeting und hilft somit dem Product Owner, dessen Stories zu präsentieren und dem Team, den Inhalt des nächsten Sprints zu definieren.

Das Sprint Planning 1 stellt die Weichen für das Sprint-Commitment, also der Verpflichtung von Product Owner und Team, das gemeinsame Ziel des nächsten Sprints zu erreichen.

Sprint Planning 2

Die im Sprint Planning 1 durch das Team aufgenommene Stories, werden im Sprint Planning 2 im Detail durchgesprochen und Aufgaben generiert. In diesem Meeting, in dem nur das Team und der Srum Master teilnehmen, wird das endgültige Commitment, also die Auswahl an Stories, die das Team im nächsten Sprint umsetzen möchte, aufgestellt. Sowohl das Sprint Planning 1, als auch das Sprint Planning 2 finden direkt am Start eines neuen Sprints statt.

Am Ende des Meetings erstellt das Team zusammen mit dem Scrum Master eine Liste aller Sprint-Aufgaben und überreicht sie dem Product Owner.

Sprint Review

Im Sprint Review stellt das Team die Ergebnisse des Sprints vor und es erfolgt eine Abnahme durch den Product Owner. Im Optimalfall sind in diesen Meetings auch die Kunden anwesend, um neue Funktionalitäten direkt präsentiert zu bekommen. Mit Hilfe dieses Meetings wird überprüft, ob das gemeinsame Sprint-Ziel erreicht werden konnte. Dabei erfolgt keine schlichte Präsentation des Standes, sondern die Funktionalität wird in der Software vorgeführt.
Neben dem Team, Scrum Master und Product Owner, können auch Gäste und Interessiert an diesem Meeting teilnehmen und sich über den aktuellen Stand informieren.
Üblicherweise findet das Sprint Review am Ende eines Sprints statt und sollte maximal 90 Minuten dauern.

Sprint Retrospective

In diesem Meeting wird der Verlauf des letzten Sprints diskutiert. Ergebnisse werden besprochen, Punkte, die es in Zukunft zu verbessern gilt, evaluiert und ein Aktionsplan entworfen. Oftmals ist es der Scrum Master, der mit neuen umzusetzenden Aufgaben aus diesem Meeting herausgeht. Aber auch das Team generiert sich im Rahmen dieses Meetings Aufgaben, die zumeist parallel zum täglichen Geschäft durchgeführt werden. Insbesondere im Hinblick auf Verbesserungen in den Team-internen Arbeitsabläufen, Kommunikation mit dem Product Owner, dem Einhalten der Team-Regeln usw.

Scrum-of-Scrum

Bestehen in einer Organisation mehrere Teams, kann der Austausch zwischen diesen Teams mittels dieses Meetings stattfinden. Dabei treffen sich Vertreter der jeweiligen Teams einmal pro Tag und berichten über aktuelle Hindernisse und den Fortschritt des Sprint Backlogs. Besonders Sinnvoll ist diese Art von Austausch, wenn es viele Abhängigkeiten zwischen den Teams gibt und eine häufige Synchronisation notwendig ist.

Daily Scrum

Dieses Meeting findet täglich außer am ersten Tag des Sprints statt. Das Meeting ist vom Team für das Team. Die einzelnen Team-Mitglieder berichten dabei abwechselnd in wenigen Sätzen vom bisherigen Fortschritt, was als nächstes gemacht wird und über etwaige Hindernisse. Das Meeting besteht also aus:

  • Was habe ich gestern gemacht?
  • Was mache ich heute?
  • Was hindert mich daran, die gesteckten Ziele zu erreichen?

Aufkommende Hindernisse werden vom Scrum Master aufgenommen und in das Impediment Backlog eintragen.
Normalerweise findet dieses tägliche Meeting früh morgens und in der Nähe der Aufgabentafel (auch Taskboard genannt) statt. Es handelt es sich um ein time-boxed Meeting, das maximal 15 Minuten dauern sollte und soll dem Team dabei helfen, die Arbeit zu planen und sich selbst zu organisieren.

Typischerweise bestehen die Regeln des Meetings aus:

  • Das Meeting wird vom gesamten Team durchgeführt
  • Die Dauer beträgt maximal 15 Minuten
  • Es findet jeden Tag zur gleichen Zeit und am gleichen Ort statt
  • Zuschauer sind erlaubt, dürfen sich aber nicht aktiv am Meeting beteiligen
  • Das Meeting dient zum Aufdecken von Problemen, aber nicht zur Lösungsfindung
  • Ein Team-Mitglied oder der Scrum Master moderieren das Meeting

Rollen in Scrum

Der Begriff Scrum

Der Begriff Scrum hat seinen Ursprung in der Sportart Rugby und heißt aus dem Englischen übersetzt Gedränge. Das angeordnete Gedränge ist dabei die Standardsituation, das Spiel nach Unterbrechungen fortzusetzen. Im Rugby geht es sehr rau zu, allerdings werden die Rugby-Regeln dabei stets verfolgt. Ähnlich verhält es sich zu Scrum: es gibt nicht viele Regeln im Scrum-Alltag, doch diese werden eingehalten und machen Scrum aus.

Rollen

Im Kern besteht Scrum aus den Rollen des Scrum-Teams, des Scrum Masters und des Product Owners. Darüber hinaus gibt es Kunden und das Management. Im Folgenden werden die einzelnen Rollen und deren Aufgaben erläutert.

Scrum-Team

Das Scrum-Team besteht u.a. aus Entwicklern, Testern, Analysten und Grafikern. Die einzelnen Rollen im Scrum-Team arbeiten eng zusammen und interagieren miteinander regelmäßig. Das Scrum-Team ist selbstorganisiert, verfügt über ausreichende Berechtigungen und Vollmachten, ist im Optimalfall nicht räumlich voneinander getrennt und trägt die Verantwortung für die Qualität der Resultate. Idealerweise besteht ein Scrum-Team aus 5 bis 9 Mitgliedern.

Scrum Master

Der Scrum Master ist das Bindeglied zwischen dem Scrum-Team und dem Management. Es ist die Aufgabe des Scrum Masters das Scrum-Team zu begleiten und zu unterstützen, auf die Einhaltung der Regeln zu achten, Hindernisse aus dem Weg zu räumen, Meetings zu moderieren und für Transparenz zu sorgen. Ferner ist der Scrum Master dafür verantwortlich, Team-Mitglieder zu schulen, damit diese ihre Rollen optimal einnehmen können, den Scrum-Prozess zu optimieren und in der Organisation zu etablieren.

Product Owner

Der Product Owner ist für die Übersetzung der Visionen in Aufgaben zuständig. Er hat direkten Kontakt mit den Kunden und erarbeitet, mit Unterstützung des Scrum Masters, ein Produkt-Backlog. Aufgaben werden durch den Product Owner ausgearbeitet, Anforderungen formuliert und Abnahmekriterien aufgestellt. Ferner erfolgt eine Priorisierung durch den Product Owner und die Abnahmen der erledigten Aufgaben am Sprint-Ende.

Kunden

Beim Kunden kann es sich entweder um externe Endkunden, aber auch um interne Kunden, z.B. einem anderen Scrum-Team oder Abteilung, handeln. Ein Kunde erarbeitet mit dem Product Owner zusammen eine Vision und beauftragt sie. In einem gut funktionierenden Umfeld, ist der Kunde stets im Fortschritt des Projektes involviert und bekommt in regelmäßigen Abständen Zwischenstände präsentiert und nimmt diese ab.

Management

Eine wesentliche Rolle nimmt das Management im Scrum-Prozess ein. Da das Scrum-Team viel Verantwortung und Selbstorganisation übertragen bekommt, liegt es am Management zu gewährleisten, dass beides auch durch das Scrum-Team angewandt werden kann und gewährt die notwendigen Freiräume. Das Management stellt Ressourcen bereit und erhält über den Scrum Master und den Product Owner Einblick in den aktuellen Fortschritt. Oftmals ist es das Management, welches Hindernisse, die durch den Scrum Master aufgedeckt oder an den Scrum Master herangetragen wurden, beseitigt.

Agiles Projektmanagement am Beispiel von Scrum

Sie haben schon von agiler Softwareentwicklung gehört und möchten gerne wissen, um was es dabei geht? Sie möchten Projektmanagement betreiben, doch die reguläre Art ist Ihnen zu umfangreich? Sie möchten den für Ihr Unternehmen optimalen Weg zur Softwareentwicklung herausfinden?

Der Kurs „Agiles Projektmanagement am Beispiel von Scrum“, durchgeführt von der VHS Wiesbaden, begleitet Sie durch die Welt der agilen Softwareentwicklung am Beispiel von Scrum und dessen Verbindung zum agilen Projektmanagement. Sie werden eine Reihe von Verfahren und Methoden kennenlernen, die sich im Rahmen von agiler Softwareentwicklung, aber auch bei herkömmlichen Projektmanagement anwenden lassen. Ziel ist nicht das Wissen der Theorie, sondern die Erkenntnis der Flexibilität, um agiles Projektmanagement erfolgreich im Unternehmen umsetzen zu können.

Inhalt des Seminars:

  • Agile Softwareentwicklung: Begriffe und Methoden
  • Definition von Scrum, dem Scrum Flow und den Rollen in Scrum
  • Scrum-Meetings (Daily Scrum, Sprint Planning 1 und 2, Sprint Retrospective, Sprint Review)
  • Die Auswirkung von Scrum auf Team-Zusammenhalt, Interaktion mit Vorgesetzten und Kunden, gemeinsame Planung und transparente Umsetzung von Aufgaben
  • Agiler Werkzeugkasten (Praktiken und Methoden)
  • Agiles Projektmanagement: Rolle des Projektleiters, Meilensteine, Stakeholder, Aufgabenplanung und Fortschrittsvisualisierung

Das Seminar findet sowohl im Frühjahr, als auch im Herbst 2014 statt.

Frühjar 2014
Mo. 19.05.2014 – Fr. 23.05.2014 http://www.vhs-wiesbaden.de/index.php?id=19&kathaupt=11&knr=G54850BU

Herbst 2014
Mo. 17.11.2014 – Fr. 21.11.2014 http://www.vhs-wiesbaden.de/index.php?id=19&kathaupt=11&knr=H54850BU

Hier befinden sich weitere Informationen zum Vorgehensmodell Scrum.


Termine für 2020 finden Sie hier: Bildungsurlaub 2020

REST-Webservice mit PHP ansprechen

REST-Webservice mit PHP ansprechen

In diesem Beitrag geht es um das Ansprechen eines REST-Webservices mittels PHP, wobei der REST-Webservice die Ergebnisse mit Hilfe von JSON zurückliefert. REST steht für Representational State Transfer und stellt eine Möglichkeit zur Implementierung einer Schnittstelle dar. Rückgaben können auf verschiedene Arten erfolgen, z.B. durch XML oder JSON. Das Ansprechen eines SOAP-Webservices ist mit Hilfe der in PHP eingebauten Soap-Klasse möglich (SoapClient). Für das Arbeiten mit einem REST-Webservice kann beispielsweise auf cURL zurückgegriffen werden, was auch Inhalt dieses Beitrags sein wird.

Methode zum Aufruf des Services

public function callAPI($data = false)
{
	$curl = curl_init();
	curl_setopt($curl, CURLOPT_POST, 1);
	curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
	curl_setopt($curl, CURLOPT_URL, $this->serviceUrl);
	curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
	curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 0);
	curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 0);
	$ret = curl_exec($curl);
	if ($ret === false) {
		$ret = null;
	}
	curl_close($curl);
	return $ret;
}

Zunächst wird mit curl_init(); eine neue cURL-Instanz erzeugt. Post-Daten können eingesetzt werden (curl_setopt($curl, CURLOPT_POSTFIELDS, $data);) und die URL zum Webservice wird gesetzt (curl_setopt($curl, CURLOPT_URL, $this->serviceUrl);). Anschließend wird der Service aufgerufen und der Rückgabewert zurückgegeben ($ret = curl_exec($curl);). Wichtig ist, dass vor der Rückgabe die cURL-Verbindung geschlossen wird (curl_close($curl);).

Methode zum Auslesen der JSON-Rückgabe

Angenommen, in der Rückgabe stecken Benutzerinformationen als JSON-Objekt, kann das Auslesen mit folgende Methode vorgenommen werden:

public function getUserEntityFromInfo($userInfo) {
	$obj = json_decode($userInfo);
	if ($obj && isset($obj->{'username'})) {
		$user = new UserEntity();
		$user->setuserName($obj->{'username'});
		$user->setemail($obj->{'useremail'});
		return $user;
	}
	return null;
}

Dabei wird zunächst das JSON-Objekt anhand des Strings erzeugt ($obj = json_decode($userInfo);). Beinhaltet das Objekt username, so werden username und useremail ausgelesen. Die Klasse UserEntity besteht in diesem Beispiel lediglich aus Getter- und Setter-Methoden.

Die komplette Klasse

class RestExample {
	
	private $serviceUrl = "https://www.myservice.com/servicename";
	
	public function callAPI($data = false)
	{
		$curl = curl_init();
		curl_setopt($curl, CURLOPT_POST, 1);
		curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
		curl_setopt($curl, CURLOPT_URL, $this->serviceUrl);
		curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
		curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 0);
		curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 0);
		$ret = curl_exec($curl);
		if ($ret === false) {
			$ret = null;
		}
		curl_close($curl);
		return $ret;
	}
	
	public function getUserEntityFromInfo($userInfo) {
		$obj = json_decode($userInfo);
		if ($obj && isset($obj->{'username'})) {
			$user = new UserEntity();
			$user->setuserName($obj->{'username'});
			$user->setemail($obj->{'useremail'});
			return $user;
		}
		return null;
	}
}

Aufruf der Klasse

Das folgende Beispiel zeigt, wie diese Klasse aufgerufen und Post-Werte übergeben werden können.

$restClient = new RestExample();
$curlPostData = array(
		'MyFirstProperty' => 123,
		'MySecondEntry' => "testdata"
);
$ret = $restClient->callAPI($curlPostData);
if ($ret != null) {
	$user = $restClient->getUserEntityFromInfo($ret);
	if ($user != null) {
		echo $user->getuserName();
	}
	else {
		echo "Benutzerinformationen konnten nicht geladen werden.";
	}
}
else {
	echo "Keine Rückgabe nach Webservice-Aufruf erhalten.";
}

Chrome-Extension zum Testen eines REST-Webservices

Zum Schnellen Testen eines REST-Webservices, bietet sich die Google Chrome-Extension Advance REST Client an. Mit dieser Extension können sowohl GET- als auch POST-Requests getestet werden und das Übergeben von Variablen ist möglich.

Anmerkungen

Die hier gezeigten Beispiele sind bewusst recht simpel gehalten. Das Aufrufen eines REST-Webservices wird gezeigt und es ist ersichtlich, wie POST-Daten übergeben werden können. Auch das Erzeugen eines JSON-Objektes wird gezeigt.