Einleitung Folien - public.fh

Team-Projekt
© Helmke
Hon. Prof. Dr.-Ing. Hartmut Helmke
in
Deutsches Zentrum für
Luft- und Raumfahrt e.V. (DLR)
Institut für Flugführung
Abteilung Lotsenassistenzsysteme
Lilienthalplatz 7
38108 Braunschweig
Tel. 0531 295-2599
E-Mail: [email protected]
SS 2015
V 1.05; © Prof. Helmke
1
Team-Projekt
© Helmke
Hartmut Helmke
Diploma degree in Computer Science from the
University Karlsruhe (Germany)
Since 1989 with DLR’s Institute of Flight Guidance
Since 1999 with department of Controller
Assistance, deputy department leader since
2005
Coordinates the development of AMAN 4DCARMA.
Prof. Helmke is an assistant professor for Computer
Science at Ostfalia University (Wolfenbüttel)
since 2001. 25 courses at Ostfalia, 23 at
DLR.
[email protected]
+49 531 295-2599
Project Lead of AcListant® since Feb. 2013.
SS 2015
www.DLR.de/fl • Chart 2
V 1.05; © Prof. Helmke
Team-Projekt
© Helmke
Wann machen wir?
Vorschlag: 8:15 bis 11:30
Sie suchen sich die Pause.
SS 2015
V 1.05; © Prof. Helmke
3
Team-Projekt
© Helmke
Lothar Christoffels
Malte Jauer
Gerald Siol
SS 2015
Christian Weiß
V 1.05; © Prof. Helmke
4
Team-Projekt
© Helmke
Flugzeuge über Europa
SS 2015
V 1.05; © Prof. Helmke
5
Team-Projekt
© Helmke
Ihre Aufgabe: Wegpunkte und Path-Stretching anklicken
Trajektorie, die Zielzeit einhält berechnen
SS 2015
V 1.05; © Prof. Helmke
6
Team-Projekt
© Helmke
zeitlicher Verlauf von Höhe und Geschwindigkeit
SS 2015
V 1.05; © Prof. Helmke
7
Team-Projekt
© Helmke
Was fehlt
Die Software zur Berechnung der Trajektorien
ist schon als Executable für Windows
vorhanden
Es fehlt eine GUI, per „Clicky-Bunti“ den
Auftrag einzugeben.
Das ganze soll als Client-Server-Anwendung
per Web-Interface nutzbar sein.
SS 2015
V 1.05; © Prof. Helmke
8
Team-Projekt
© Helmke
Webbasierte Client-Server-Anwendung
SS 2015
V 1.05; © Prof. Helmke
9
Team-Projekt
© Helmke
Kompetenzziele des Team-Projektes
Studierende sammeln Erfahrung in der Software-Entwicklung im Team.
Sehr generisch
Es geht um Softentwicklung, aber vor allem um das „Leben“ im Team.
 Softskills
SS 2015
V 1.05; © Prof. Helmke
10
Team-Projekt
© Helmke
Lehrinhalte des Team-Projektes
Praktische Umsetzung der vermittelten Lehrinhalte in Programmieren und
ggfs. Softwaretechnik.
5 Credits, also 150 Stunden Aufwand.
SS 2015
V 1.05; © Prof. Helmke
11
Team-Projekt
© Helmke
Rahmenbedingungen
•
•
•
Keine Klausur
5 Credtis, d.h. 150 Stunden bis Semesterende pro Teilnehmer
Für eine 10er-Gruppe stehen 1.500h zur Verfügung
•
Jeder Dozent möchte 150 h bis Semesterende, bei 30 Credits sind
das pro Nase 900 h, bei 15 Wochen ca. 60 Stunden pro Woche.
Sie wollen aber auch die 5 Credits.
•
SS 2015
V 1.05; © Prof. Helmke
12
Team-Projekt
SS 2015
Termine des Sommersemesters 2015
V 1.05; © Prof. Helmke
© Helmke
13
Team-Projekt
SS 2015
Termine des Sommersemesters 2015
V 1.05; © Prof. Helmke
© Helmke
14
Team-Projekt
© Helmke
Spezielle Termine
6.3.
13.3.
27.3
Gruppeneinteilung, Aufgabe verstehen
Vorstellung der Gruppe
Requirements-Dokument vorstellen bzw. Demo der ersten
Implementierung
3.4
Karfreitag, fällt aus
10.4 Gruppe A, B, C: ggf. Zwischendemo
17.4 Gruppe D, E, F: ggf. Zwischendemo
24.4 Enddemo: 1. Teil; Ideen für zweite Aufgabe vorbesprechen
1. Mai Fällt aus
8.5.
Requirements-Dokument vorstellen bzw. ein Teil gibt Demo des
Standes (Gruppe A, B, C)
15. Mai Himmelfahrt fällt aus
22.5 Restliche Gruppen: Zwischen-Demo (Gruppe D, E, F)
29.5 ggf. Zwischendemo (Gruppe A, B, C)
4.6
ggf. Zwischen-Demo (Gruppe D, E, F)
11.6
Enddemo
SS 2015
V 1.05; © Prof. Helmke
15
Team-Projekt
© Helmke
Gruppeneinteilung
•
•
•
X Teilnehmer pro Gruppe streben wir heute an  Wir losen
Bilden Sie Zweier-Teams. Wir gruppieren zu Teams
Wir behalten uns eine Umstrukturierung der Gruppen bis
Semesterende vor
•
Die Gruppen tragen nächste Woche ihre ersten Ergebnisse des
Teamfindungsprozesses vor
•
Alle Gruppen dürfen bei den anderen Gruppen zuhören, müssen es
aber nicht, seien Sie aber pünktlich für Ihren Slot anwesend.
SS 2015
V 1.05; © Prof. Helmke
16
Team-Projekt
© Helmke
Gruppeneinteilung
SS 2015
V 1.05; © Prof. Helmke
17
Team-Projekt
© Helmke
Wollen Sie
Arrival Interval
Calculator oder
Trajektorien
Generator?
SS 2015
V 1.05; © Prof. Helmke
18
Team-Projekt
© Helmke
Literatur
Jochen Ludewig, Horst Lichter:
Software Engineering, dpunkt Verlag, 2013 (3. korrigierte Auflage)
Bernd Müller:
Software-Technik, Vorlesungsskript, Fakultät für Informatik,
Ostfalia, Hochschule Braunschweig/Wolfenbüttel,
Ian Sommerville:
Software Engineering, 9. Auflage. Addison-Wesley Verlag, 2012
Ian Sommerville:
Software Engineering, 9. Auflage in Englisch. Addison-Wesley Verlag,
2010
SS 2015
V 1.05; © Prof. Helmke
19
Team-Projekt
© Helmke
Literatur
Chris Rupp & die SOPHISTen:
Requirements-Engineering und –Management — Professionelle, iterative,
Anforderungsanalyse für die Praxis, Hanser Verlag, 2014
6. Aktualisierte Auflage
Hans-Peter Mössenböck.
Sprechen Sie Java? Eine Einführung in das systematische
Programmieren 5. Auflage, dpunkt-Verlag, 2014
SS 2015
V 1.05; © Prof. Helmke
20
Team-Projekt
© Helmke
Sonstige Literatur
Scott Ambler:
Introduction to User Stories. Initial User Stories. Artikel in Englisch,
http://www.agilemodeling.com/artifacts/userStory.htm;
Kent Beck, Erich Gamma:
JUnit Cookbook. Artikel in Englisch,
http://junit.sourceforge.net/doc/cookbook/cookbook.htm;
SS 2015
V 1.05; © Prof. Helmke
21
Team-Projekt
© Helmke
Carl Rogers:
Du kannst Menschen nichts lehren,
Du kannst Ihnen nur helfen, es in sich zu entdecken.
Team-Projekt
© Helmke
Erwartungen an Vortrag nächste Woche
Siehe pdf-Folien plus Bewertungskriterien
SS 2015
V 1.05; © Prof. Helmke
23
Team-Projekt
© Helmke
Feedback SS 14: Empfehlungen an Nachfolger (1)
1. Nicht allzu viele andere Fächer belegen
2. IT-Manager sollten ein paar Informatiker dabei haben
3. Code von Betreuern hätte zusammen mit Betreuern stärker zu Beginn
analysiert werden müssen.
4. Viele Bonuspunkte erreichen
5. Nichts auf letzten Drücker terminieren
6. Fristen setzen und auf Einhaltung dringen
7. Häufige Teammeetings abhalten
8. Von Beginn an dran bleiben (so wir es gemacht haben)
9. Frühzeitig den Sprint beginnen
10. Aufgaben sinnvoll an die Teammitglieder zu verteilen (sonst machen 2
alles)
11. Vor allem am Anfang viel Zeit in Planung stecken, das vermeidet
Fehler im späteren Verlauf
V 3.11; © Prof. Helmke
24
Team-Projekt
© Helmke
Feedback SS 14: Empfehlungen an Nachfolger (2)
1. „printToConsole“ in eine Klasse auslagern, die nicht mit eingecheckt
wird
2. Viel fragen
3. Um Hilfe bitten (auch die Betreuer), sich nicht alleine zu lange
festbeißen
4. Fach nicht unterschätzen
5. Betreuer/ Dozenten mit Fragen nerven
V 3.11; © Prof. Helmke
25
Team-Projekt
© Helmke
Feedback SS 14: Vorträge der anderen Gruppen sinnvoll? (1)
1.
2.
3.
4.
5.
6.
7.
Nein, es wurde kein Codegezeigt
Nein, Projektfortschritt der anderen nicht so interessant
Nein, man schaut eher auf seine eigenen Probleme
Nein: I
Nein, aber dennoch interessant die Stände und Ergebnisse der anderen
Gruppe zu erfahren
Nein, weil im Grunde das gleiche wie beim eigenen Team erzählt wurde,
Konkrete Codelösungen fehlten dagegen
Nein, weil selbst schon anders implementiert wurde, trotzdem interessant
V 3.11; © Prof. Helmke
26
Team-Projekt
© Helmke
Feedback SS 14: Vorträge der anderen Gruppen sinnvoll? (1)
1.
2.
3.
4.
5.
Ja, Vereinzelt Inspiration für eigene Arbeit und Feedback um eigene Qualität
einzuschätzen
Ja, die persönliche Verunsicherung wurde beseitigt, weil im Vortrag auch
gezeigt wird, dass die andere Gruppe die gleichen Probleme hat
Ja, man sieht wie weit die anderen sind und wird aufgebaut, wenn dort
ähnliche Fehler passieren
Ja, etwas erfahren, wie sich Teams organisieren
Ja, aber nur in den ersten Sprints sinnvoll
V 3.11; © Prof. Helmke
27
Team-Projekt
© Helmke
Feedback SS 14: Wie könnte man Vorträge verbessern? (1)
1. In den ersten Sprints mehr Code zeigen
V 3.11; © Prof. Helmke
28
Team-Projekt
© Helmke
Feedback SS 14: Transparenz der Bewertung (1)
1.
2.
3.
4.
5.
6.
7.
8.
9.
Manchmal war erst nach Bewertung klar, was gemacht werden sollte
Teilweise erst nach Bewertung klar, was genau bewertet wird
Nicht immer ohne Rückfragen zu verstehen, manchmal hätte ein Satz mehr
geholfen
Manchmal war erst nach der Bewertung ersichtlich, welche Aufgaben wirklich
übernommen werden sollten
Ja, sehr ausführlich
Ja: I
Transparenz war gut und man konnte sich vorbereiten, bevor bewertet wurde
Teilweise ja, aber auch mal auf die individuellen Stärken des Teams eingehen
(HHe ???, unterschiedlich bewerten?)
Teilweise nicht nachvollziehbar, zu wenig erklärt
V 3.11; © Prof. Helmke
29
Team-Projekt
© Helmke
Feedback SS 14: Jeder aus Team gleiche Punktzahl
1.
2.
3.
4.
War O.K.
Ja, weil jeder im Rahmen seiner Kenntnisse zum Gesamterfolg beigetragen
hat
Ja: I I I I I I I | I
Ja, aber gilt nicht immer
V 3.11; © Prof. Helmke
30
Team-Projekt
© Helmke
Feedback SS 14: Losverfahren in Ordnung
1.
2.
3.
4.
5.
Ja: I I I I I I
Nein I
Jein: I
Ja, aber wir hatten Glück, weil unsere Teammitglieder ähnliche Stundenpläne
hatten
Ja, aber besser erst selbst in Gruppen aufteilen und den Rest bei Losverfahren
V 3.11; © Prof. Helmke
31
Team-Projekt
© Helmke
Feedback SS 14: Wettbewerb am Ende
1.
2.
3.
4.
5.
6.
Ja, fördert Motivation: I I
Ja, etwas Spaß zum Semesterende
Ja: I I I I I
Ja, es motiviert und zeigt nochmals die Ergebnisse jeder Gruppe
Nein, da es selbst mit Wettbewerb keine Chance mehr 1,0 gab, auch wenn
man noch viel Zeit investiert hätte (Hhe: Das war nicht korrekt, in jedem Team
gab es mindestens drei Leute mit besser als gut als Bewertung, Praktisch gilt
es vielleicht schon, wenn der eigene Code bereits so „kaputt“ ist, dass man
damit einfach nicht mehr gewinnen kann)
Ja, aber Punktevergabe unfair (Hhe: Warum?)
V 3.11; © Prof. Helmke
32
Team-Projekt
© Helmke
Feedback SS 14: Jedes Mal ein anderer Scrum-Master sinnvoll? (7)
1.
2.
3.
4.
5.
6.
7.
8.
Ja, jeder sollte mal machen
Ja, so konnte jeder Scrum kennenlernen, auch wenn es gute und andere
Scrummaster gab
Nein: I I
Vielleicht: I I
Ja: I I I
Sinnvoll, wenn er/sie gut ist
Vielleicht, sollte das Team selbst entscheiden
Ja, denn praktische Erfahrung ist Gold wert
V 3.11; © Prof. Helmke
33
Team-Projekt
© Helmke
Feedback SS 14: Test-first (8)
1.
2.
3.
4.
5.
6.
7.
Gut und akzeptiert
Macht schon Sinn
Muss sein
Anstrengend, zeitaufwändig, viel Vorarbeit nötig, ABER sinnvoll
Zum ersten mal praktiziert, besser als ohne
Oft unrealistisch, weil man oft erst mal nur ausprobieren will
Sehr sinnvoll, anfangs schwierig, da man erst mal lernen muss, wie
man richtig testet
8. Schwierig, vor allem am Anfang, Hieraus müsste in Software-Technik
mehr drauf eingegangen werden
9. Ist O.K.
10. Gut, allerdings zu wenig Erfahrung, wie man es richtig macht
V 3.11; © Prof. Helmke
34
Team-Projekt
© Helmke
Feedback SS 14: Sonstiges (1)
1. War trotz allem die sinnvollste und lehrreichste Veranstaltung
2. Einsatz von Scrum in den Ostfalia-Lehrveranstaltungen schwierig
3. Von Anfang an sollte feststehen, wer Entwickler, Scrummaster ist
(nicht den Scrummaster wechseln).
4. IT-Manager sind keine Programmierer
5. Teilweise unklare Aufgabenstellungen
6. Bewertung gerechter als eine „Müller“-Bewertung
7. Durch Feedback der Betreuer oft Arbeit am Sa/So erforderlich, ggf.
Abgabetermin auf Samstag vorverlegen, bzw. Bonuspunkte, wenn
nicht am Sonntag fertig gestellt wird. (Hhe Es gab Bonuspunkte für
frühere Abgabe, Feedback am Freitag war als Hilfe gedacht, um noch
Korrekturen vor Bewertung durchführen zu können, ist nur vorher
möglich, wenn vorher etwas (>75%) vorliegt.)
V 3.11; © Prof. Helmke
35

Download Report