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.

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

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

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.

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