Software Projekt 2017/18 - Software Engineering€¦ · Software Projekt 2017/18 Plenum in Woche 2...

Post on 14-Jul-2020

5 views 0 download

Transcript of Software Projekt 2017/18 - Software Engineering€¦ · Software Projekt 2017/18 Plenum in Woche 2...

Software Projekt 2017/18Plenum in Woche 2

Prof. Kurt Schneider

FG Software EngineeringLeibniz Universität Hannover

KS@inf.uni-hannover.deTel. +49-511 -762-19666

Agenda

1. Erfahrungsaustausch – wie war die Regelkommunikation?

2. Spezifikation und Template dafür

3. Visionsvideos3. Visionsvideos

4. Ausblick auf die nächsten Aktivitäten

2

Projektlandschaft

DeisterApp

Informtionund

Führung

Agile Animator

SE-Tool für das InfoLAB, mit Kinect

Volleyball

Turnier-planer Jedes Team erstellt

eine Anwendung(z.B. Volleyball-2)

1 Auftrag – bis zu 3 ProjekteVerschiedene Produkte – teilweise mehrfach beauftragt (alle Produkte sollen eingesetzt werden)

3Kurt.Schneider@inf.uni-hannover.de

iQ4S

Fragebogen-designer

(z.B. Volleyball-2)

ProductLiner

Software-familien planen

Metis

Polizeiarbeit unterstützen

Text-O-Mat

StilsicherSchreiben

Wer, wann, wo?

1 2 3 4 5 6

Coach Risch Prenner Koch Brinkop Kortum Treptau

Raum G306 InfoLAB G323 B417 InfoLOUNGE G325

13h TextOMat1 Metis-1 Volley-3 iQ4S-2 AgileAnim 2

14h TextOMat2 Metis-2 Deister-1 iQ4S-3 PL-2 Volley-1

4Kurt.Schneider@inf.uni-hannover.de

15h iQ4S-1 AgileAnim1 Deister-2 PL-1 Volley-2

16:30h Plenum in B305 nach Bedarf

1. Erfahrungsaustausch im TownHall-Meeting

• Wie hat die Teamfindung geklappt?

• Wie sind Sie mit dem Kunden zurecht gekommen?– Und er mit Ihnen?

• Das nächste Mal: SCRUM – Industrie-Standard, muss man können

• Sonstige Fragen, die Sie miteinander diskutieren wollen?

5Kurt.Schneider@inf.uni-hannover.de

Ihr Verhältnis zum Kunden

• Kunde möchte, dass Sie Erfolg haben– Denn dann bekommt er/sie das Produkt, das er/sie will

• Wir halten nicht mit Anforderungen hinterm Berg– Kunden versuchen, Ihnen möglichst viel Information zu geben

– In der Regel müssen Sie aber fragen und notieren – nicht der Kunde!

6

• Sie sind verantwortlich– Sie müssen nachfragen, wenn etwas zu vage od. widersprüchlich ist

• Kunde hat seinen Nutzen im Blick– Sofern Sie dazu beitragen, hilft Kunde nach Kräften

– Tun Sie es nicht, wird auch Kunde das Interesse verlieren

• Ohne zufriedenen Kunden werden Sie keinen Erfolg haben!– Seien Sie höflich, respektvoll und professionell – eine Selbstverständlichkeit

SCRUM Master

SCRUMRoom

SCRUM team 7+/-2

ProductOwner(Kunde)

Visuelle Zusammenfassung von SCRUM

Room

ProductBacklog(priorisiert)

SPRINTDaily SCRUM

15 min.

SPRINTBacklog

Increment

2. Spezifikation und Template

• Noch einmal: Rolle der Spezifikation im Prozess

• Wozu dient das Template? Wozu nicht?

• Wie läuft die „Freigabe durch den Kunden“ ab?• Wie läuft die „Freigabe durch den Kunden“ ab?

• Quality Gate am 1. Tag der Iteration 1 (nach Exploration)

8Kurt.Schneider@inf.uni-hannover.de

Ablauf und Entwicklungsprozess

Exploration Iteration 1 Iteration 2 Polishing

Skizze+

Template

Back-log:

Stories Programmier-konvention

Kunde

9

Spez.

CodePräsentation

• Iterative Arbeitsweise: 4 Inkremente• Wenig Bürokratie• Hier nur die wichtigsten Dokumente gezeigt

Kunde

Ablauf in JEDEM Projekt

Projektskizzeals Lastenheft

(„Zweiseiter“) Spezifikation• Einzelne Anforderungen• Rahmenbedingungen

Template für

Spezifikation

Leiten Story Cards ab, aktualisieren Anforderungenund Prioritäten

Story 031 ….2 ….

Story 021 ….2 ….

Story 011 ….2 ….

Kurt.Schneider@inf.uni-hannover.de 10

• Rahmenbedingungen• Ideen des Kunden• Möglichkeiten, die Sie finden• Lösungsvarianten

Sie haben/erhalten:grobes Lastenheft und ein Template

Kunde kommt insTeam (mehrfach)

Sie erheben Anforderungen, bekommen vielleichtDokumente vom Kunden,verfeinern Spezifikation …

… erstellen Skizzen, Mockups,Prototypen – und Sieprogrammieren, testen im Team.

Am Schluss steht die großePräsentation – und deröffentliche Einsatz!

Projektkalender (Intro+Exploration)

heute

11Kurt.Schneider@inf.uni-hannover.de

Di/Mi: Sie geben die Spezifikation ab; Tutor+Kunde prüfen, evtl. Überarbeitung

3. Visionsvideos

• Was ist ein Visionsvideo und wozu dient es?

• Beispiele aus dem Vorjahr – zur Diskussion gestellt

• Hier verläuft die Forschungsfront!ViViReq

• Hier verläuft die Forschungsfront!

• Anspruch an die Videos und an Sie: Praxis, nicht Forschung

12Kurt.Schneider@inf.uni-hannover.de

Exploration: Die Aufgabe erforschen

• Ziel: Eine valide Spezifikation, gutes Aufgabenverständnis

– Korrekte Kundenanforderungen zu diesem Zeitpunkt

• Großer Spielraum: Sie dürfen vieles einsetzen

– Fragen Sie den Kunden, lesen Sie seine Dokumente

– Erstellen Sie Prototypen: Papier, elektronisch, Video

• Visionsvideo von 1-2 Minuten: wie stellen Sie sich Ihre SW im Einsatz vor?

– Lassen Sie den Kunden dazu Stellung nehmen

– Erproben Sie schwierige Lösungsideen oder Architekturen

– Gehen Sie technische Risiken an, um sie zu entschärfen

• Die Spezifikation enthält Mission, Anforderungen und Prioritäten

13Kurt.Schneider@inf.uni-hannover.de

Seit 2017: Hochinteressante Kunden

14Kurt.Schneider@inf.uni-hannover.de

4. Ausblick

• Exploration ist enorm wichtig: keine Zeit verlieren!

• Bleiben Sie kreativ, nutzen Sie das ganze Team

• Fangen Sie jetzt auch schon an, die Spezifikation zu • Fangen Sie jetzt auch schon an, die Spezifikation zu schreiben

15Kurt.Schneider@inf.uni-hannover.de

Intranet: Nicht nur ein Angebot

16Kurt.Schneider@inf.uni-hannover.de

Was muss ich tun, um erfolgreich zu sein?

• Generell

– In allen Phasen aktiv mitarbeiten

– Formale Vorgaben erfüllen (z.B. Anwesenheit am Präsenztag Mittwoch)

– Programmieren – nicht nur Getter und Setter

– Durch Verhalten zum Teamerfolg beitragen

• Konkreter

– Jede/r muss programmieren

– So kommunizieren und abstimmen, dass Ihr Projekt ein Erfolg wird

• Ein Produkt entsteht, das der Kunde gut findet und abnimmt

• Gute Qualität entsteht (siehe unten)

• Arbeit im Team wird als angenehm empfunden

– Arbeiten Sie systematisch, folgen Sie SWT, SWQ-Prinzipien

• Sehen Sie bitte in den Unterlagen nach, was man tun kann/sollte – wirklich: tun Sie es!

• Respektvoller Umgang mit Kunden und Kollegen – wie im „richtigen Leben“

– Qualitätsanforderungen

• Der Kunde ist die Quelle der Anforderungen – auch Qualitätsanforderungen und Prioritäten

• Achten Sie auf eine verständliche, vollständige und klar geschriebene Spezifikation

• Schreiben Sie gut strukturierten und getesteten Code (mit Kommentaren, Entwurfsprinzipien, usw.: SWT, SWQ)

• Zum Abnahmetest wird Ihre SW von einem Dritten aus dem SVN geladen, installiert und bedient.

Rollen und Aufgaben

• Im Team– Projektleiter eines Teilprojekts: Koordination und ggf. Entscheidung

– Qualitätsbeauftragte: Q-Aufgaben koordinieren und anleiten

– Entwickler: Alle Teilnehmer sind auch Entwickler

– Sonderaufgaben (für Spezifikation, Präsentation usw.)– Sonderaufgaben (für Spezifikation, Präsentation usw.)

• Im Umfeld– Kunde (Backlog-Owner): Anforderungen, Referenz für Projekterfolg

– Koordinator des SWP: Kommunikation, Planung, Org. in FunGate

– Tutor/Coach: Beobachtet Team, gibt Hinweise, berichtet der Leitung

– Hintergrund-Support: Einzelne Experten-Vorträge

– Eskalation, falls nötig: Team Tutor Koord./Prof. Schneider

18Kurt.Schneider@inf.uni-hannover.de