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.

An diesem Szenario spielen den Weg einer Software von der Idee zum fertigen Produkt nach. Auf dem Weg dokumentieren wir, wann wir was warum gemacht haben. Nach dieser Reise werden wir eine Form der Dokumentation gewählt haben, Rollen identifiziert, Stakeholder kennen gelernt, Kommunikationstechniken geübt. Requirements wurden gefunden, ein Plan wurde aufgestellt. Wir haben eine Softwarearchitektur gefunden und die Realisierung in die Wege geleitet

• Rollenspiel: Froh „bestellt“ eine Web-Anwendung zum Profil-Management (analog GULP) bei einem Entwicklungsteam (restliche Teilnehmer)
• Beim Entwicklungsteam haben wir Glück: Für dieses Rollenspiel dürfen wir unser Entwicklungsteam frei aussuchen und arbeiten nur mit Mitarbeitern unserer Wahl zusammen.
• Exkurs: Beim Erfassen von Requirements und Reden mit den Stakeholden müssen wir viel kommunizieren. Hier bietet sich an, sich einmal mit der „Gewaltfreie Kommunikation“ nach Marshall Rosenberg zu beschäftigen.

• spezifisches Requirement A) „Jahre Erfahrung pro Fachgebiet im Profil erfassen“
• Budget „vorhanden“ (Aufhänger: Planungsteam 4 Personen)

• Wer macht was
  • Rollenverteilung beim Kunden ermitteln
  • Kommunikation zwischen Tech und non-Tech bei Requirements/im Projektverlauf aufrechterhalten
• Klären: Produkt oder Projekt?
  • Nachsatz: „Wenn das Projekt fertig ist können wir es ja als Produkt verkaufen“ vermeiden
• Unterschiedliche Vorstellungen innerhalb des Kunden klären
  • Assoziationen zunächst jeder für sich entwickeln, dann in der Runde konsolidieren (Hilfsmittel: Jeder schreibt seine auf)
  • wenn möglich unabhängig von der Organisationsstruktur

• Ideen, die beim Kunden rumgeistern, zusammen mit Prioritäten/Gewichten erfassen/erzählen lassen
  • Zusammenhänge zwischen den Ideen verstehen
  • Ideen außerhalb der Umsetzungsdomäne identifizieren und „ablehnen“
    • Ideen sind: Rollen, Daten (DB-Felder), Funktionalitäten
  • ungeklärte Probleme dürfen *explizit* offen bleiben

• „Zeichenphase“: Lösungsansätze/Prototypen entwickeln, vom Kunden beurteilen lassen
  • z.B. aus dem Blickwinkel unterschiedlicher Rollen

• Zyklisch ab „Unterschiedliche Vorstellungen“ bzw. „Wer macht was“, bis der Prototyp genau genug als Implementierungsvorlage ist. Prototyp bekommt die Rolle eines Lastenhefts.

• Flo: Tool „Balsamiq Mockups“ ⇒ Bleistiftoptik, analog Idee von Joel Spolsky: Unfertige Funktionen im UI „handschreiben“

• Martin: „Vorteil“ von Komitee-Entscheidungen: Man hat genug Zeit das Zeug fertig zu machen, während der Entscheidungsprozess langwierig läuft
• Funkionierendes Beispiel: „Dünner“ Prozess, in Templates nur das nötigste Ausfüllen
• Froh: Confluence + ARC42-Template; Martin: Trac, Pläne durch Confluence zu ersetzen

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