Die 7 Schritte zu Ihrer Software
5. Umsetzung
Der/die Product Owner trägt zunächst das Projekt mit dem geschätzten Aufwand in die Planung des ausgewählten Teams ein. Die Teamplanung erfolgt in einem Excel-Sheet, das sich als grobe Projekt-Übersicht bewährt hat und in dem unter anderem auch die Urlaube einzelner Teammitglieder, Feiertage etc. berücksichtigt sind.
Bei der nächsten Sprintplanung wird das Projekt vom Team detaillierter eingeplant (Start, Durchlaufzeit & Ende). Das Team macht diese Planung vollkommen eigenständig und gibt dem/der Product Owner danach die Info.
Manchmal kommt es vor, dass es für ein Projekt aus guten Gründen eine bestimmte Deadline gibt (z.B. ein Event, bei dem die neue App oder die neue Website präsentiert werden soll). Wenn das Team diese nicht erreichen kann, da andere Projekte davor eingeplant sind, ist es Aufgabe des/der Product Owners gemeinsam mit den anderen Product Ownern die Projekte neu zu priorisieren, um das Projekt vorschieben zu können. Das bedeutet natürlich auch, dass die Product Owner mit ihren jeweiligen Kunden reden, um die neuen Zeitpläne abzustimmen. So müssen diese zwar etwas länger auf ihre Software-Lösung warten, dafür können wir aber auch dafür sorgen, dass wirklich dringende Projekte schnell umgesetzt werden!
Oben im Text haben wir von "Sprintplanung" geredet und so mancher wird den ersten Teil des Worts nur aus dem Sport kennen. In unserem Fall kommt er aus der agilen Softwareentwicklung: Unsere Teams arbeiten in einwöchigen Sprints. Die Planung dieser Sprints findet also einmal die Woche statt (pro Team an unterschiedlichen Wochentagen). In dieser Sprintplanung wird zum einen der vergangene Sprint betrachtet (Lief es wie geplant? Ist alles fertig?), zum anderen der kommende Sprint geplant.
Die Basis für die Planung sind die sogenannten User Stories. Das sind in Alltagsprache geschriebene Anforderungen an die Software. Sie sind aus User-Sicht geschrieben und folgen idealerweise der Formel: "Um diesen Nutzen zu haben, möchte ich als User das tun können." (z.B. "Als registrierter Webshop-Nutzer möchte ich meine letzten Bestellungen aufrufen können, um ein Produkt einfach nachbestellen zu können."). Diese User Stories wurden schon in der Vorprojektphase bei der Konzeptionierung des Projekts geschrieben und mit dem Kunden besprochen.
Die Sprintplanung macht das Team alleine, nur wenn es spezielle Fragen zum Projekt oder einer User Story hat holt es den/die Product Owner dazu – dieser sollte dementsprechend idealerweise zu diesem Zeitpunkt greifbar sein. Wichtig ist uns auch, dass das Team nur an geplanten Dingen arbeitet; für ungeplante Arbeiten wird extra ein gewisser Prozentsatz an Arbeitszeit fix bei der Sprintplanung eingeplant!
Der/die Product Owner ist übrigens während des gesamten Projekts Ansprechpartner des Kunden, repräsentiert den Kunden gegenüber dem Team und testet die fertiggestellten Funktionen. Gleichzeitig hat er auch die Verantwortung für den finanziellen Erfolg des Projekts.
Womit wir arbeiten
Ein paar kurze Worte zu unseren "Werkzeugen": Neben dem schon erwähnten Excel-Sheet verwenden wir in der CSS den Team Foundation Server (TFS) von Microsoft. Über den TFS können Projekte geplant, erstellt und verwaltet werden.
Damit verbunden ist ein Tool, dass wir selbst entwickelt haben und sich "Alice" nennt. In Alice können unsere Entwickler und Entwicklerinnen sowie Product Owner nach den User Stories suchen, um die darauf verwendete Zeit zu buchen. Diese Buchungen sind für uns sehr wichtig: Die so gesammelten Daten sind Erfahrungswerte, auf Basis derer wir noch bessere Schätzungen für neue Projekte machen können. Außerdem können wir anhand dieser Buchungen Projekte abrechnen, die auf Aufwand gemacht werden, sowie generell den Projektstand einsehen.
Die Demos für Kunden
Ein wichtiger Teil der Umsetzung sind die regelmäßigen Demo-Meetings mit dem Kunden, entweder persönlich oder als Telefonkonferenz. Theoretisch können wir jede Woche, nach jedem Sprint, dem Kunden die neuen Features präsentieren. Praktisch findet – abhängig von der Projekt-Art – eine Demo sinnvollerweise alle zwei oder drei Wochen statt.
Die Demo-Meetings bieten dem Kunden die Möglichkeit, von Anfang an Feedback zu geben und zu testen. Idealerweise sind auf Kundeseite schon Personen dabei, die die Software-Lösung nach der Fertigstellung nutzen werden, da diese das beste Feedback geben können. Dieses regelmäßige Feedback sorgt dafür, dass wir schnell und ohne großen Aufwand kleine Kurskorrekturen vornehmen können und nicht am Ende dem fertigen, großen "Tanker" mühsam eine neue Richtung geben müssen.
In vielen Fällen ist bei dem Demo-Meeting auch das Team anwesend. So bekommt es direkt das Feedback vom Kunden und kann so besser verstehen, was gewünscht wird.
Generell haben wir von Anfang an ein UAT-System (UAT steht für User Acceptance Test), auf das auch der Kunde jederzeit zugreifen kann (sinnvollerweise ab einem bestimmten Projekt-Stand).