Scrum, Storypoints und Schätzungen

Im Scrum werden größere Aufgaben in User Stories zerlegt. Diese User Stories werden anschließend geschätzt. Dabei wird nicht die Zeit geschätzt welche das Team für die Aufgabe benötigt. Stattdessen wird die Komplexität der User Story geschätzt. Story Points sind dabei die abstrakte Einheit um Komplexität bzw. die Größe der Story einschätzen zu können. Nun ist es für Menschen kompliziert akkurat zu schätzen wo der Komplexitätswert einer User Story liegt. Was Menschen besser können ist es eine User Story mit einer anderen User Story zu vergleichen. Man definiert bzw. nutzt bestehende User Stories als Referenz, welche man bereits bearbeitet hat und weißt ihnen einen Referenzwert zu. Als Werte nutzt man dabei eine modifizierte Fibonaci-Reihe nach dem Schema:

1, 2, 3, 5, 8, 13, 20, 40, 100

Mit Hilfe der Referenz-Stories können nun die neuen User Stories bzw. ihre Komplexität geschätzt werden. Bei der Planung schaut man wie viele Story Points man im letzten Sprint erfolgreich bearbeitet hat und nutzt diese Zahl für die neue Planung. Neben den Referenz-Stories, welche zur Einschätzung der Komplexität dienen, wird während der Planung meist auch Planning Poker gespielt. Kern des Prozesses ist dabei das verdeckte Schätzen der Komplexität. Nachdem die Karten aufgedeckt wurde, erklären die beiden Mitspieler mit der niedrigsten und der höchsten Karte ihre Einschätzung. Anschließend wird das ganze wiederholt, bis das Team eine fundierte Einschätzung der Komplexität vorliegen hat.

Karten für das Planning Poker

Karten für das Planning Poker

Für den Product Owner ist es natürlich wichtig zu wissen, wie viel Zeit die eingeschätzten Tickets benötigen. Dazu bedient man sich des Velocity-Faktors. Dieser ergibt sich aus dem was das Team in den letzten Sprints an Story Points abgearbeitet hat. Wenn das Team in acht Stunden z.B. durchschnittlich 4,3 Story Points abarbeitet, kann der Product Owner die benötigte Zeit abschätzen.

Remote-Branch unter Git umbenennen

Um unter Git einen Branch umzubenennen nutzt man den entsprechenden Terminalbefehl:

git branch -m oldBranchname newBranchname

Damit wird der Branch im lokalen Repository umbenannt. Wenn dieser nun mittels git push auf den entfernten Remote übertragen wird, so entsteht dort ein neuer Branch. Um die Umbenennung auch auf dem Remote durchzuführen muss der alte Branch auf dem Remote gelöscht werden:

git push origin :oldBranchname

Damit wird der alte Branch auf dem Remote gelöscht und die Umbenennung ist abgeschlossenen.

Screen-Session wieder aufnehmen

Wenn man unter Linux eine Session mittels screen gestartet hat und diese später wieder aufrufen möchte, so nutzt man den Befehl:

screen -r

Unter bestimmten Bedingungen kann es vorkommen, das die Sitzung noch gebunden ist. Auf der Konsole würde das dann wie folgt aussehen:

# screen -r

There is a screen on:
	29711.ubuntu-release-upgrade-screen-window	(05/05/2016 04:09:56 PM)	(Attached)
There is no screen to be resumed matching 29711.ubuntu-release-upgrade-screen-window.

Vorkommen kann so etwas z.B. wenn man die SSH-Verbindung während einer Screen-Sitzung verliert. Damit man diese Screen-Sitzung wieder aufnehmen kann, muss die bestehende Bindung zuerst wieder gelöst werden. Dazu gibt es das Kommando:

screen -d

welches die Bindung löst. Bei mehreren offenen Sitzungen muss zusätzlich die ID der Sitzung angegeben werden. Anschließend kann die Sitzung wieder mittels:

screen -r

aufgenommen werden.

do-release-upgrade findet keine neue Version

Wenn man auf einem Ubuntu-Server:

do-release-upgrade

eingibt so wird auf die aktuelle Version (je nachdem welche Einstellungen man in der Datei /etc/update-manager/release-upgrades getätigt hat) aktualisiert. Allerdings kann es bei LTS-Releases vorkommen das man stattdessen die Meldung:

Checking for a new Ubuntu release
No new release found

Der Grund hierfür ist, das man bei einem LTS Release erst mit dem ersten Pointrelease, also z.B. 16.04.1 upgraden kann. Damit soll Fehlern vorgebeugt werden, welche in der ersten Release-Version noch vorhanden sein könnten. Möchte man auf dem entsprechenden Gerät trotzdem die aktuelle Version installieren so muss man den Parameter -p nutzen:

do-release-upgrade -p

Damit wird das versucht das aktuelle Release zu installieren, was von LTS zu LTS Version dazu führt das die aktuelle LTS Version installiert wird auch wenn kein Pointrelease verfügbar ist.