Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
knowhow:planspiel20110622 [2011/08/31 00:26] admin |
knowhow:planspiel20110622 [2012/02/19 14:10] (aktuell) Florian Sesser Tags hinzugefügt |
||
|---|---|---|---|
| Zeile 3: | Zeile 3: | ||
| Workshop Teil 1: Die Idee. Das Management hat eine Idee für ein neues Projekt. Wolkige Vorstellungen, | Workshop Teil 1: Die Idee. Das Management hat eine Idee für ein neues Projekt. Wolkige Vorstellungen, | ||
| - | An diesem Szenario spielen den Weg einer Software | + | Dies ist die Wiki-Aufbereitung der [[agenda: |
| + | === 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, | ||
| - | * Rollenspiel: | + | === Unser Team === |
| - | * 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 " | + | |
| - | * spezifisches Requirement A) "Jahre Erfahrung pro Fachgebiet im Profil erfassen" | + | Beim Entwicklungsteam haben wir Glück: Das Team können wir aus erfahrenen Mitarbeitern selbst zusammenstellen, |
| - | * Budget " | + | |
| - | * Wer macht was | + | === Anforderungen des Kunden |
| - | * Rollenverteilung beim Kunden | + | Der Kunde hat eine konkrete Anforderung: |
| - | * Kommunikation zwischen Tech und non-Tech bei Requirements/im Projektverlauf aufrechterhalten | + | |
| - | * Klären: Produkt oder Projekt? | + | |
| - | * Nachsatz: | + | |
| - | * 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, | + | Die genauen Anforderungen müssen noch durch Gespräche |
| - | * Zusammenhänge zwischen | + | |
| - | * Ideen außerhalb der Umsetzungsdomäne identifizieren und " | + | |
| - | * Ideen sind: Rollen, Daten (DB-Felder), | + | |
| - | * ungeklärte Probleme dürfen *explizit* offen bleiben | + | |
| - | * " | + | Für das Rollenspiel nehmen wir an, dass ein Budget für die Entwicklung vorhanden ist. |
| - | * z.B. aus dem Blickwinkel unterschiedlicher Rollen | + | |
| - | | + | <WRAP center round tip 75%> |
| + | //**__SGS Workshop (nachträglich eingefügt)__**// | ||
| - | * Flo: Tool " | + | Eine Möglichkeit, die Projektbeteiligten, |
| - | | + | Dem SGS Workshop liegt die Erfahrung zugrunde, dass Stakeholders, |
| - | * Funkionierendes Beispiel: "Dünner" | + | |
| - | * Froh: Confluence | + | Der SGS Workshop behandelt schlicht alle drei in einem einzigen Workshop. |
| + | </ | ||
| + | |||
| + | |||
| + | <WRAP center round tip 75%> | ||
| + | //**__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 [[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 52: | 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> | ||