Von der Idee zum Release. Ein Rollenspiel.

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.

Auftakt

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.

Unser Team

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.

Anforderungen des Kunden

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.

Wer macht was?

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

Projekt oder Produkt?

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.

Kommunikation

Bei der Kommunikation mit dem Kunden müssen Missverständnisse vermieden werden, die Requirements müssen gelten. Hierzu kann man verschiedene Mittel einsetzen:

  • Was ausgemacht ist wird von allen Teilnehmern für sich interpretiert, danach wird in der Runde sichergestellt, dass ein gemeinsames Verständnis existiert.
  • Konventionen können helfen: z.B. bei User Stories gibt es schriftliche Confirmations. Wenn die Confirmations erfüllt sind, muss die Story abgenommen werden. Es zählt der Wortlaut. Da der Kunde die Confirmations diktieren kann, wird er seine Anforderungen genau festlegen.
  • Weiterbildung ist nützlich: Bei Scrum ist gibt es z.B. einen einzelnen Ansprechpartner des Teams - den Product Owner. Der PO ist nicht technisch, gehört optimalerweise zum Kunden, er ist eine Einzelperson und er hat eine Weiterbildung als PO besucht.
Anforderungen

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.

Prototypen

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.

Diskussionsteil

  • Kommiteentscheidungen dauern oft so lange, dass man den „Vorteil“ hat die Software fertig zu implementieren, während der langwierige Entscheidungsprozeß noch läuft (Martin)
  • Gegenbeispiel: „Schlanker“ Prozeß, in Dokumentationstemplates nur das nötigste ausfüllen.
  • Dokumentation: Wiki, z.B. Confluence oder Trac. Ein Archtekturtemplate wie ARC 42 ist sehr hilfreich.
  • Grundregel: Es gibt nur einen Platz, an dem dokumentiert wird
  • Abstimmungs-Meetings: Wechselnde, kleine Gruppen zusammenstellen
  • Modell von Flo Dünkel ist eine Implementierung von Flo Sessers Konzept: Verschiedene Entwickler grob am Telefon z.B. 2 Tage vorher auf ein Thema „anspitzen“, dann in Gesprächsrunde konsolidieren
  • Froh: „Ich habe mir als Einzelgänger einen Job im stillen Kämmerchen ausgesucht und stelle nun im Leben fest, daß der Schwerpunkt auf Kommunizieren und Abstimmen liegt.“
  • Conway's Law: Die Systemarchitektur wird ein Abbild der Kommunikationsstruktur im Team.
  • Martin: Gibt es Strategien, mit angeordneter Kommunikationstrennung effizient/effektiv umzugehen?
    • → praktisch nur „Nebenkanäle“, Social Engineering
  • Plan für den nächsten Schritt: Architektur/Umsetzungsplan fur die oben erfassten Ideen/Prototypen
  • Interesse von Flo: Wie kommt man aus den Requirements zu einer Roadmap
  • Froh: „Growth Paper“; als „Gate“ des Konzernprozesses
  • Michi: Bei feststehendem Endtermin pragmatisch
    1. Klickdummy
    2. in schnellen Iterationen Features (nach Abhängigkeiten)
  • Froh: Vereinbarte Iterationen helfen, disjunkte Teams zu synchronisieren
  • WIE schreibt man die Ergebnisse der obigen Erfassung auf!?
  • ZIELGRUPPE/Zielperson der Dokumentation explizit aufzeigen!
  • Ein Dokument kann auch für viele Konsumenten vorgesehen sein - Beispiel FuncSpec (Martin)
  • Flo: Trac-Schema mit „Drill-Down“-Funktionalität (aus technischem Blickwinkel)
    • Obere Layer dienen auch als Input für Übersetzer/graphische Designer/usw.