Workshop Teil 1: Die Idee. Das Management hat eine Idee für ein neues Projekt. Wolkige Vorstellungen, grobe Ideen. Wir sind damit beauftragt aus dieser vagen Idee ein brauchbares Produkt zu machen.
Dies ist die Wiki-Aufbereitung der Mitschrift von Joe, sie enthält nochmals Tipps und Informationen, die am Abend noch nicht zur Sprache kamen.
Die Teilnehmer des Workshops spielen die Rolle eines Entwicklungsteams. Ein Kunde (z.B. aus einer anderen Abteilung eines Konzerns) kommt hereingeschneit und bestellt eine neue Web-Anwendung.
Er benötigt eine Anwendung zum Erfassen und Verwalten von Mitarbeiteprofilen von Softwareentwicklen, seine Abteilung hat dort einen Markt erkannt und will dort tätig werden. Man hat dort einige wolkige Ideen, aber noch keine allzu detaillierten Vorstellungen.
Beim Entwicklungsteam haben wir Glück: Das Team können wir aus erfahrenen Mitarbeitern selbst zusammenstellen, brauchen für dieses Planspiel also nicht auf Entwickler Rücksicht nehmen die aus „nicht-fachlichen“ Gründen ins Projekt geschoben werden.
Der Kunde hat eine konkrete Anforderung: Er will ein Portal, in dem sich Softwareentwickler registrieren können und anstelle der üblichen „ich kann Java nicht/bisschen/mittel/gut“ eine Erfahrungswertung haben „ich habe 7 Jahre Erfahrung mit Java und 6 Monate mit Ruby“
Die genauen Anforderungen müssen noch durch Gespräche mit den Beteiligten festgelegt werden.
Für das Rollenspiel nehmen wir an, dass ein Budget für die Entwicklung vorhanden ist.
SGS Workshop (nachträglich eingefügt)
Eine Möglichkeit, die Projektbeteiligten, die Ziele und den Umfang des Projekts auszuloten ist der SGS Workshop. SGS steht für Stakeholders, Goals, Scope.
Dem SGS Workshop liegt die Erfahrung zugrunde, dass Stakeholders, Goals und Scope von verschiedenen Teams in verschiedener Reihenfolge ermittelt werden - und dass Erkenntnisse bei dem einen neue Fragen beim anderen Aufwirft.
Der SGS Workshop behandelt schlicht alle drei in einem einzigen Workshop.
Exkurs: Gewaltfreie Kommunikation Beim Erfassen von Requirements und Reden mit den Stakeholden müssen wir viel kommunizieren. Hier bietet sich an, sich einmal mit der Gewaltfreien Kommunikation nach Marshall Rosenberg zu beschäftigen. Diese erlaubt es auf Bedürfnisse von Menschen zu hören.
Drüber hinaus ist es auch sinnvoll für Verhandlungssituationen - auch diese können beim Requirements Enigneering entstehen - einmal vom Harvard Konzept gehört zu haben.
(Bei SGS sind das die Stakeholder)
Das Entwicklungsteam muss ermitteln, wer beim Kunden welche Rolle spielt und wie er auf das Projekt Einfluß nimmt. Die Kommunikation zwischen verschiedenen Kommunikationskulturen (z.B. Techniker / Nichttechniker) muß funktionieren.
Nichts ist gefährlicher als der Nachsatz „Wenn das Projekt fertig ist, können wir es ja als Produkt verkaufen“. Wir ignorieren damit, dass Endkunden ganz andere Bedürfnisse haben als der spezifische Personenkreis, für den wir entwickelt haben.
Anders läuft es bei einen Produkt. Auch wenn man einen Erstkunden hat nach dessen Vorgaben man entwickelt, kann man dessen Wünsche nach „goldenen Wasserhähnen“ auch mal ablehnen.
Bei der Kommunikation mit dem Kunden müssen Missverständnisse vermieden werden, die Requirements müssen gelten. Hierzu kann man verschiedene Mittel einsetzen:
Die Ideen, die beim Kunden existieren müssen erzählt und erfasst werden. Ideen außerhalb der Umsetzungsdomäne (Scope) werden abgelehnt, andere Ideen werden verstanden und priorisiert. Rollen, Daten (DB-Felder), Funktionalitäten - all dies dient als Input.
Ein Lösungsansatz oder sogar ein Prototyp wird entwickelt. Das Ergebnis prüft man zusammen mit dem Kunden wie weit es seine Bedürfnisse erfüllt und geht danach in die nächste Runde: Die Schritte „Wer macht was?“ und folgende werden durchlaufen bis Zufriedenheit herrscht.
Der Lösungsansatz (Papier) oder der Prototyp bekommt die Rolle eines Lastenhefts.
Prototypoptik
Ein Prototyp sollte nicht wie eine fertige Software aussehen, erst recht nicht ein Wireframe. Das Tool Balsamiq Mockups verwendet deswegen z.B eine Bleistiftoptik. Joel Spolsky verwendet als Platzhalter für unfertige Funktionen z.B. handgeschriebene Buttons in der Software.