Von der Bestellung zur fertigen Software


Das ist der dritte Teil einer Artikel-Serie, die Einblicke in CSS bietet. Die ersten zwei finden Sie hier:

  1. That's how we roll: Die Organisation der CSS
  2. Von der Anfrage zum Angebot


 

Nehmen wir den Faden aus unserem letzten Artikel auf und starten wir an der Stelle, an der ein (Neu-)Kunde unser Angebot angenommen und die Umsetzung einer individuellen Software-Lösung bestellt hat.

Unser Product Owner, der den Kunden schon seit dessen Anfrage begleitet, bleibt auch weiterhin sein Ansprechpartner und ist für das Projekt verantwortlich. Das unterscheidet uns von anderen Unternehmen, in denen der Vertrieb nach der Beauftragung das Projekt weitergibt.

[Kurzer Einschub für alle, die sich jetzt fragen, was denn ein "Product Owner" ist: Der Begriff "Product Owner" stammt aus Scrum, einem der bekanntesten Vertreter des agilen Projektmanagements. Product Owner sind die internen Stellvertreter des Kunden in unserem Team. Sie sind die Ansprechpartner unserer Kunden und repräsentieren die Wünsche und Anforderungen der Auftraggeber und User der Software. Über die Jahre haben wir für die CSS eine eigene agile Kultur entwickelt, die Elemente aus mehreren agilen Ansätzen enthält, unter anderem Scrum.]

 

Das Team wird ausgewählt

Der verantwortliche Product Owner stimmt sich nun mit unserem Team Manager ab, der den Überblick über die Auslastung der Entwicklungsteams hat. In den meisten Fällen wird das Team, das schon in der Vorprojektphase die Schätzungen gemacht hat, auch das Projekt umsetzen. Sollte dieses Team ausgelastet sein, wird ein anderes Team mit dem nötigen Skillset ausgewählt.

Der Product Owner trägt als nächsten Schritt 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 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 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!
 

Das Team startet

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 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 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).

An dem mit dem Kunden abgestimmten Termin erfolgt der "Live Release" der Software-Lösung. Erfahrungsgemäß kommt danach noch sehr viel Feedback, da trotz der Demo-Meetings vieles erst auffällt, wenn die Software intensiv von unterschiedlichsten Usern genützt wird. Die Zeit für dieses Feedback berücksichtigen wir schon in unserer Planung.
 

Unser Softwareservice

Mit dem Live Release endet unsere Arbeit natürlich nicht. Wir bieten im Bereich Softwareservice (Wartung) verschiedene Leistungen an, die auf den jeweiligen Kunden und die Technologie zugeschnitten sind. Dabei arbeiten wir sowohl reaktiv (sprich: wir lösen auftauchende Probleme), als auch proaktiv (wir kümmern uns zum Beispiel um rechtzeitige Updates). Auch nach der Lieferung der Software ist der Product Owner weiterhin der Ansprechpartner für den Kunden und verantwortlich dafür, dass dieser über lange Zeit mit seiner Software glücklich ist!

 

Text: Isabel Birnstingl, Johannes Widmann & Sven Schweiger
Zeichnungen: Isabel Birnstingl


 

Sie möchten mehr über uns erfahren und haben ein interessantes Software-Projekt für uns? Dann kontaktieren Sie uns!