Hier möchte ich meinen Weg aufzeigen. Mit den Scrum Mittel kann sich jeder sein eigenes System erstellen.
Startphase
Der Auftraggeber hat eine Idee von einem Produkt. Zuerst wird das Gesamtbild, das Endprodukt besprochen. Ich lasse mir als die Vision erklären.
Sollte der Auftraggeber keine Userstories haben. Lege ich für das Projekt welche an. Wir besprechen die Userstories. So kann der Auftraggeber nochmal prüfen, ob sein Produktwunsch verstanden wurde.
Release-Planung
Wenn die Userstories besprochen sind, ordnet der ProduktOwner (Auftraggeber) diese in eine Reihenfolge. Ich erstelle dann ein Produkt-Roadmap. Dazu reicht oft ein DIN A4 oder A3 Blatt aus. Diese ist immer präsent aufgehängt oder liegt am Arbeitsplatz. Damit kann man gut den Focus auf das Projektziel halten. Das verhindert auch mehr Arbeit, die nicht bestellt wurde.
Schätzung der Userstories
Nach der Schätzung der Userstories kann ich die eigentliche Arbeit beginne. Bevorzugt in einem 1-Wochensprint oder 2 Wochen Sprint. Da in diesen kurzen Abständen, das Feedback schneller eingebunden werden kann. Besonders dann wichtig, wenn der Kunde selbst nur eine vage Vorstellung vom End-Produkt hat.
Sprint vorbereiten
Die Userstories werden in der Reihenfolge abgearbeitet. Für die Tasks nehmen ich DIN A4 Blätter. Jede Userstory hat sein eigenes Blatt. Das Blatt liegt beim Arbeiten im Querformat vor der Tastatur und erlaubt mir immer einen schnellen Einblick. Die Userstory kommt als Überschrift als Stichpunkt auf das Blatt oben. Wenn ich an mehreren Projekten arbeite, schreibe ich meist auch ein Kürzel für das Projekt mit dazu. So kann man gut die Task-Blätter organisieren. Auf ein ScrumBoard verzichte ich damit. Vor mir liegt die Produkt-Roadmap und die Blätter mit den Userstories.
Die Userstories stappel ich. Damit bleibt der Focus auf das aktuelle Abarbeitungspaket. Auf jedem Blatt erfasse ich die nötigen Schritte für die Umsetzung. Das sind die Tasks. Wenn die Reihenfolge im Laufe der Entwicklung geändert wird, schreibe ich mir Zahlen an die Tasks. Wenn es zu unübersichtlich wird, schreibe ich das Blatt einfach neu.
Durch das Erfassen der Tasks gehe ich den Entwicklungsprozess der Userstory im Kopf durch. Dabei fallen mir Arbeitsschritte ein, die ich vorher vergessen habe zu berücksichtigen. Im Laufe der Entwicklung kommen auch immer wieder Tasks dazu oder manche werden entfernt. Das Entfernen demonstriere ich durch das Durchstreichen mit wellenartige Linien. So kann ich abgearbeitete Tasks von verworfenen gut trennen.
Zeitschätzung jederzeit möglich
Da sich die Tasks bei mir tatsächlich immer im gleichen Zeitbereich bewegen, kann ich auch schnell eine Aussage über die Dauer geben. Somit kann ich die eigentliche Schätzung gut anpassen. Ich zähle einfach die Tasks und multipliziere diese mit meiner durchschnittlichen Zeit pro Task.
Sprint machen
Wenn die Tasks stehen, geht es los. Ich arbeite die Tasks der Reihe nach ab. Daten und Informationen die ich benötige und mir im Laufe der Entwicklung einfallen, werden direkt auf das Blatt geschrieben. So bleibt alles zusammen.
Jeder erledigte Task wird durchgestrichen. Das gibt eine gutes Gefühl und motiviert gleich zu weiteren Arbeiten. Die Tasks selbst sind in der Regel auch kurz und klein gehalten. Die umgesetzten Tasks werden wenn möglich sofort in ein Quellcode-Versionierungssystem eingecheckt. Damit bleiben die Änderungen erhalten und man kann schnell wieder den alten Zustand herstellen.
Daily Scrum
Ist nicht wirklich nötig. Da ich alleine an dem Projekt arbeite. Aber für den Beginn der Entwicklung sichte ich meist nochmal die erledigten Tasks und reflektiere nochmals was zu tun ist. Auch ein Blick auf die Gesamtstory ist sehr vorteilhaft, also die Roadmap ansehen.
Sprint Review
Das Sprint Review mache ich mit dem Kunden entweder gemeinsam, Live per Skype oder er sendet mir seine Anmerkungen per Email zu. Das Inkrement stelle ich dafür auf meinen Testserver und sende ihm den Link zu. Rework kommt in die nächste Sprintplanung. Damit kann ich dann auch Verlängerungen in der Projektdauer gleich kommunizieren.
Sprint Retrospektive
Ist etwas schwierig alleine. Da kann helfen, den Kunden zu fragen, ob er noch eine andere oder verbesserte Kommunikation wünscht. Für mich versuche ich schon während der Entwicklung, Optimierungen gleicht anzuwenden. Motto: Man lernt nie aus. Dafür lese ich mich immer wieder in Bücher für besseres Programmieren und Testen ein.
Fazit
ScrumForOne geht. Man muss etwas disziplinierter sein, aber kann schnell gute Erfolge erzielen. Viel Spass mit diesen Anregungen.
Keine Kommentare:
Kommentar veröffentlichen