Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
knowhow:planspiel20110622 [2011/08/30 23:58] admin angelegt |
knowhow:planspiel20110622 [2012/02/19 14:10] (aktuell) Florian Sesser Tags hinzugefügt |
||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | === Workshop | + | ===== Von der Idee zum Release. Ein Rollenspiel. ===== |
- | * Rollenspiel: Froh " | + | Workshop Teil 1: Die Idee. Das Management |
- | * 37 Signals (Basecamp): " | + | Dies ist die Wiki-Aufbereitung der [[agenda:a0411: |
- | * Exkurs: " | + | === Auftakt === |
- | * spezifisches Requirement A) "Jahre Erfahrung pro Fachgebiet im Profil erfassen" | + | 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. |
- | * Budget " | + | |
- | * Wer macht was | + | Er benötigt eine Anwendung zum Erfassen |
- | * Rollenverteilung beim Kunden ermitteln | + | |
- | * Kommunikation zwischen Tech und non-Tech bei Requirements/ | + | |
- | * Klären: Produkt oder Projekt? | + | |
- | * Nachsatz: "Wenn das Projekt fertig ist können wir es ja als Produkt verkaufen" | + | |
- | * Unterschiedliche Vorstellungen innerhalb des Kunden klären | + | |
- | * Assoziationen zunächst jeder für sich entwickeln, dann in der Runde konsolidieren (Hilfsmittel: | + | |
- | * wenn möglich unabhängig von der Organisationsstruktur | + | |
- | * Ideen, die beim Kunden rumgeistern, | + | === Unser Team === |
- | * Zusammenhänge zwischen den Ideen verstehen | + | |
- | * Ideen außerhalb der Umsetzungsdomäne identifizieren und " | + | |
- | * Ideen sind: Rollen, Daten (DB-Felder), | + | |
- | * ungeklärte Probleme dürfen *explizit* offen bleiben | + | |
- | * " | + | 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 " |
- | * z.B. aus dem Blickwinkel unterschiedlicher Rollen | + | |
- | * Zyklisch ab "Unterschiedliche Vorstellungen" | + | === Anforderungen des Kunden === |
+ | Der Kunde hat eine konkrete Anforderung: | ||
- | * Flo: Tool " | + | 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. |
- | * Funkionierendes Beispiel: "Dünner" | + | |
- | * Froh: Confluence | + | <WRAP center round tip 75%> |
+ | //**__SGS Workshop (nachträglich eingefügt)__**// | ||
+ | |||
+ | Eine Möglichkeit, | ||
+ | |||
+ | Dem SGS Workshop liegt die Erfahrung zugrunde, dass Stakeholders, | ||
+ | |||
+ | Der SGS Workshop behandelt schlicht alle drei in einem einzigen Workshop. | ||
+ | </ | ||
+ | |||
+ | |||
+ | <WRAP center round tip 75%> | ||
+ | // | ||
+ | Beim Erfassen von Requirements und Reden mit den Stakeholden müssen wir viel kommunizieren. Hier bietet sich an, sich einmal mit der [[http:// | ||
+ | |||
+ | 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 | ||
+ | |||
+ | Anders läuft es bei einen Produkt. Auch wenn man einen Erstkunden hat nach dessen Vorgaben man entwickelt, kann man dessen Wünsche nach " | ||
+ | |||
+ | == 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, | ||
+ | * 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), | ||
+ | |||
+ | == 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. | ||
+ | |||
+ | <WRAP center round tip 75%> | ||
+ | // | ||
+ | |||
+ | Ein Prototyp sollte nicht wie eine fertige Software aussehen, erst recht nicht ein Wireframe. Das Tool [[http:// | ||
+ | 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 " | ||
+ | |||
+ | * Gegenbeispiel: "Schlanker" | ||
+ | |||
+ | * Dokumentation: Wiki, z.B. Confluence | ||
+ | |||
+ | * Grundregel: Es gibt nur // | ||
* Abstimmungs-Meetings: | * Abstimmungs-Meetings: | ||
Zeile 46: | Zeile 94: | ||
* Martin: Gibt es Strategien, mit angeordneter Kommunikationstrennung effizient/ | * Martin: Gibt es Strategien, mit angeordneter Kommunikationstrennung effizient/ | ||
* -> praktisch nur " | * -> praktisch nur " | ||
- | |||
* Plan für den nächsten Schritt: Architektur/ | * Plan für den nächsten Schritt: Architektur/ | ||
+ | |||
* Interesse von Flo: Wie kommt man aus den Requirements zu einer Roadmap | * Interesse von Flo: Wie kommt man aus den Requirements zu einer Roadmap | ||
+ | |||
* Froh: " | * Froh: " | ||
+ | |||
* Michi: Bei feststehendem Endtermin pragmatisch | * Michi: Bei feststehendem Endtermin pragmatisch | ||
- Klickdummy | - Klickdummy | ||
- in schnellen Iterationen Features (nach Abhängigkeiten) | - in schnellen Iterationen Features (nach Abhängigkeiten) | ||
+ | |||
* Froh: Vereinbarte Iterationen helfen, disjunkte Teams zu synchronisieren | * Froh: Vereinbarte Iterationen helfen, disjunkte Teams zu synchronisieren | ||
- | |||
* WIE schreibt man die Ergebnisse der obigen Erfassung auf!? | * WIE schreibt man die Ergebnisse der obigen Erfassung auf!? | ||
+ | |||
* ZIELGRUPPE/ | * ZIELGRUPPE/ | ||
+ | |||
* Ein Dokument kann auch für viele Konsumenten vorgesehen sein - Beispiel FuncSpec (Martin) | * Ein Dokument kann auch für viele Konsumenten vorgesehen sein - Beispiel FuncSpec (Martin) | ||
+ | |||
* Flo: Trac-Schema mit " | * Flo: Trac-Schema mit " | ||
* Obere Layer dienen auch als Input für Übersetzer/ | * Obere Layer dienen auch als Input für Übersetzer/ | ||
+ | {{ : | ||
+ | |||
+ | |||
+ | {{tag> |