C - Lehreinheit 6: Teamwork

Teamwork:
Ziel dieser Lehreinheit ist die Arbeit in kleinen Teams. Sie lernen an Hand eines möglichst einfachen Beispiels, wie man die Aufteilung von Arbeiten im Team plant und organisiert, wie man getrennt entwickelt, testet, und die Produkte zu einem gemeinsamen Projekt zusammenführt.
Dazu finden sie auf dieser Seite zwei Übungs-Beispiele (1) (2).

Organisation:
Die Stärke eines (gut organisierten) Teams ist die hohe Produktionsleistung, eine Schwäche der dafür notwendige Aufwand an Organisation. Es kommt daher darauf an, wie gut sie organisieren, dass möglichst immer alle Mitglieder ihres Teams gleichzeitig arbeiten können, und dass die Stand- und Wartezeiten möglichst kurz sind.
Ein so einfaches Projekt wie das Übungsbeispiel wird man normalerweise nicht im Team aufteilen, da ein/e einzelne/r ProgrammiererIn viel effizienter arbeiten kann. Sie sollen jedoch damit so viel an Erfahrung gewinnen, dass sie in der Lage sind, ein komplexes Projekt im Team auszuführen - dort kommen die Vorteile der Team-Arbeit voll zum Tragen.
Ein Tip: Wenn sie das Übungs-Beispiel 1 erfolgreich abgeschlossen haben, messen sie bei allen weiteren Team-Projekten die Zeit für die einzelnen Phasen.

Als Orientierung kann ihnen diese Einteilung in Entwicklungs-Phasen helfen:

Analyse und Planung: Ziel ist die Aufteilung der Arbeiten an die Team-Mitglieder.
Analysieren sie ihr Projekt und erstellen sie ein Flussdiagramm. Dieses (übergeordnete) Diagramm sollte große Funktionsblöcke, jedoch keine Einzelheiten enthalten. Ideal ist es, wenn sich daraus direkt eine Aufteilung der Arbeiten auf die Mitglieder des Teams ableiten lässt. Schließen sie diese Phase so rasch wie möglich ab, denn alle Mitglieder des Teams müssen bis dahin warten (bzw. sich an der Planung beteiligen).
Diese Phase ist abgeschlossen, wenn jedes Mitglied im Team ihre/seine Aufgaben erhalten hat.

Detailplanung: Ziel ist die (erste) Definition der Schnittstellen.
Jedes Team-Mitglied erstellt für ihren/seinen Bereich ein eigenes (!) Flussdiagramm. Konzentrieren sie sich auf größere Funktionsblöcke und vermeiden sie unnötige Details. Definieren sie Eingangsdaten (z.B. Argumente ihrer Funktionen), Ausgangsdaten (z.B. return / Typ ihrer Funktionen) sowie sonstige beeinflusste Daten (z.B. über Pointer). Koordinieren sie diese Schnittstellen so rasch wie möglich mit ihrer/m Projekt-LeiterIn..
Achtung: Bis zu diesem Punkt verläuft die Planung allgemein, d.h. ohne Rücksicht auf die später verwendeten Programmiersprachen, Bibliotheken und sonstigen Module.
Planen sie sorgfältig, aber rechnen sie evtl. mit späteren Änderungen dieser und anderer Definitionen.
Diese Phase ist abgeschlossen, wenn alle Schnittstellen definiert sind.

Entwicklungs-Umgebung: Ziel ist die Einrichtung der kompletten Test-Umgebung.
Jedes einzelne Team-Mitglied richtet nun ihre/seine Test-Umgebung ein. Das Ziel ist, dass alle Module unabhängig voneinander entwickelt und getestet werden können, sowie dass die fertigen Module so einfach wie möglich in das gesamte Projekt integriert werden können.
Projekt-LeiterIn: Ihre Test-Umgebung umfasst das "Hauptprogramm" (in C die Funktion main) sowie das Minimum der notwendigen Funktions-Aufrufe. Organisieren sie ihr Projekt so, dass die Beiträge ihrer KollegInnen ohne Änderung (z.B. als komplette Quellcode-Datei oder als OBJ-Datei) integriert werden können. Im Anhang finden sie dazu ein Beispiel.
Team-Mitglied: Ihre Test-Umgebung umfasst ihr eigenes "Hauptprogramm", reduziert auf das absolut notwendige Mindestmass. Dazu kommt ihr eigener Anteil am Projekt (in einer eigenen Datei) und die minimal notwendige Umgebung.
Diese Phase ist abgeschlossen, wenn Projektleitung und alle Team-Mitglieder über eine funktionierende eigene Test-Umgebung verfügen.

Prototypen: Ziel ist ein lauffähiger erster Prototyp des Gesamtprojekts.
Alle Team-Mitglieder erstellen Prototypen ihrer Funktionen. Diese erfüllen die formalen Kriterien der Schnittstellen, führen jedoch normalerweise keine Arbeiten aus. Ziel dieser Phase ist es, einen ersten gemeinsamen Proto ihres Projekts herzustellen. Allenfalls werden die Schnittstellen-Definitionen nochmals überarbeitet.
Projekt-LeiterIn: Ihr Proto ruft jedes einzelne Modul auf und stellt sicher, dass die Schnittstellen so wie vereinbart funktionieren. Dazu benötigen sie die fertigen Protos aller Team-Mitglieder. Sie erteilen jedem Team-Mitglied einzeln das ok für die weitere Entwicklung
Team-Mitglied: Ihr Proto meldet Aufruf und korrekte Funktion. Sobald sie das sichergestellt haben, liefern sie ihren Proto (als Datei) an die Projektleitung, die ihn integriert und testet. Von dort erhalten sie das ok für die weitere Entwicklung (in der Zwischenzeit können sie ihre Test-Umgebung ausbauen).
Diese Phase ist abgeschlossen, wenn alle Team-Mitglieder das ok für ihren getesten Proto erhalten haben.

Entwicklung: Ziel ist das funktionierende Gesamt-Projekt.
Alle Team-Mitglieder entwickeln nun ihre Module und testen sie in ihrer eigenen Umgebung. Gehen sie in kleinen Schritten vor und sichern sie fertige Arbeiten (Speichern, Dokumentieren, Freigeben->Projektleitung). Nun kann man laufend das Entstehen des Team-Projekts verfolgen. Die Funktionalität wird laufend ergänzt und erweitert. Jedes Modul durchläuft mehrere Zyklen von Entwicklung, Test, Intergration, Test, weiterer Entwicklung, usw.
Falls sie mehrere Module entwickeln: Betten sie jedes einzelne in eine eigene Test-Umgebung ein - diese muss sich rasch aktivieren lassen, wenn sie ihr Modul später debuggen oder ändern müssen. Allenfalls fügen sie eine Zwischen-Ebene ein, in der sie mehrere (getrennt entwickelte) eigene Module gemeinsam testen können. Halten sie jede Test-Umgebung so klein wie möglich und vermeiden sie unnötigen Overhead.
Ein gutes Team liefert laufend gut getestete Teil-Module mit langsam zunemhender Funktionalität. Ein schlechtes Team liefert fehlerhafte (zu wenig getestete) Module oder in zu langen Abständen (zu viel neue Funktionalität, hohes Fehler-Risiko).
Diese Phase ist abgeschlossen, wenn das gesamte Projekt so funktioniert wie geplant.

Dokumentation: Ziel ist es, das Projekt so abzuschliessen, dass (später) möglichst viele Teile der Arbeit weiter verwendet werden können. Während der Entwicklung dokumentieren sie laufend, nach Abschluss sehen sie alles nochmals durch, korrigieren und ergänzen. Die Dokumentation soll so beschaffen sein, dass sie selbst ebenso wie jede/r andere ProgrammiererIn auch nach Monaten die Arbeit sofort wieder aufnehmen können. Sie dokumentieren normalerweise sowohl im Code (comments) als auch in einer eigenen Datei (Zusammenfassung, Beschreibung, Schnittstellen...). Alle zum Projekt gehörenden Teile werden eindeutig zusammengefasst und archiviert.
Mit Abschluss dieses Phase ist das Projekt beendet.

Team-Projekt 1:

Aufgabe: Erstellen sie ein Konsolen-Programm mit 2 unabhängigen Teil-Funktionen (Unterprogrammen). Organisieren sie die Arbeit in einem Team von 3 Personen.
Die beiden Teil-Funktionen sollen keine andere Arbeit ausführen, als sich auf der Konsole zu melden - dieses absolute Minimal-Team-Projekt kann natürlich von jeder/m einzelnen ProgrammiererIn rascher erledigt werden - über sie trotzdem daran die Phasen der Zusammenarbeit.

Analyse und Planung:
Rechts ein Muster dieses Flussdiagramms.
Projekt-LeiterIn (Gelb) übernimmt die Koordination, Team-Mitglied (Blau) erstellt Modul A, Team-Mitglied (Grün) erstellt Modul B.
Legen sie in wenigen Worten die gewünschte Funktionalität der beiden Module sowie des gesamten Projekts fest. Mit diesen Angaben können die Team-Mitglieder (Blau) und (Grün) bereits gleichzeitig und unabhängig voneinander weiterplanen.

Detailplanung:
Team-Mitglied (Blau) hat dieses einfache Flussdiagramm seiner Aufgabe "Modul A" erstellt.
(Blau) kommt bei der Analyse zu folgendem Schluss:
Modul A benötigt eine Eingangs-Variable (int) und liefert eine Ausgangs-Variable (int).
Die Projektleitung (Gelb) ändert diesen Vorschlag und fügt eine weitere Eingangs-Variable (int) dazu.
Dann erhält (Blau) das ok für die nächste Entwicklungsphase:

Entwicklungs-Umgebung:
Die Projektleitung (Z) erstellt folgende Entwicklungs- und Test-Umgebung:

Eine Header-Datei (team.h) enthält alle gemeinsam genutzten Angaben. Sie kann einfach an alle Team-Mitglieder verteilt werden.

Die beiden Quellcodedateien (team_a.cpp und team_b.cpp) werden von den Team-Mitgliedern (Blau) und (Grün) zur Verfügung gestellt. Eine weitere Quellcodedatei (team_z.cpp) enthält gemeinsam genutzte Bibliotheks-Funktionen und steht ebenfalls allen Team-Mitgliedern zur Verfügung.

Bis die beiden Quellcodedateien von ihren Team-Mitgliedern eintreffen, können sie bereits an der Dokumentation oder an gemeinsam benutzten Bibliotheken (libraries) arbeiten. Sie sollten auch überlegen, mit welchen Daten (regulär - im Wertebereich, aber auch irregulär) sie die Module testen wollen, und diese Tests vorbereiten.

Team-Mitglied (Blau) erstellt folgende Entwicklungs-Umgebung:

Die Header-Datei (team.h) und die Bibliotheks-Funktionen (team_z.cpp) werden von der Projektleitung (Gelb) zur Verfügung gestellt.

Ein eigenes "Hauptprogramm" (main) wird so erstellt, dass es nur den zum Test von Modul A benötigten Code enthält. Dazu kommt natürlich das Modul A (team_a.cpp), das eigentliche Produkt des Team-Mitglieds (Blau).

Nach Fertigstellung der Entwicklungs-Umgebung wird diese kurz getestet.

Prototypen:
Nun erstellen die beiden Team-Mitglieder (Blau) und (Grün) erste Prototypen ihrer Module. Die Gestaltung folgt keinen fixen Regeln, sollte aber sehr sparsam ausfallen, da die fertigen Prototypen möglichst bald an die Projektleitung geliefert werden sollen.
Faustregel: Dokumentieren sie alle Eingangs- und Ausgangsvariablen, sowie die Funktion des Moduls selbst ("Hallo !").

Die Projektleitung testet die Prototypen und erteilt bei korrekter Funktion das ok für die weitere Entwicklung.

Entwicklung:
Die beiden Team-Mitglieder (Blau) und (Grün) erweitern nun schrittweise die Funktionalität ihrer Module. Nach jedem Schritt wird in der eigenen Umgebung getestet.
Nach allen größeren Schritten sowie nach festgelegten Zeiten (real Tage, als Übung Stunden) werden die jeweils neuesten fehlerfreien Modul-Versionen an die Projektleitung geliefert.
Die Projektleitung (Gelb) testet das Zusammenspiel der Module und organisiert alle zwischenzeitlich erfolgten Änderungen (Dokumentation, Kommunikation an die Team-Mitglieder).
Jedes Modul durchläuft typisch einige Zyklen:
Entwicklung (Blau) - Test (Blau) - Lieferung - Test (Gelb) - Rückmeldung ->

Zuletzt liegt das fertig funktionsfähige Modul (Runtime-Version) vor.

Dokumentation:
Nun folgt eine Revision und Zusammenfassung der vorliegenden Dokumentation. Die Module werden archiviert, das Projekt abgeschlossen.

Team-Projekt 2:

Aufgabe: Erstellen sie das Konsolen-Programm FILTER, welches beliebige Dateien "filtert", d.h. nach vorgegebenen Regeln verarbeitet. Das Programm soll über die Commandline in dieser Form bedient werden:
FILTER INFILE OUTFILE CONTROL PARAMETER1 PARAMETER2...

FILTER: Der Name des Programms (Runtime-Version).
INFILE: Angabe des Dateinamens der Eingangs-Datei
OUTFILE: Angabe des Dateinamens der Ausgangs-Datei
CONTROL: Code zur Auswahl aus mehreren verschiedenen Filter-Funktionen.
PARAMETER1...n: Optional, falls einer ihrer Filter ein zusätzliches User-Argument benötigt.

Legen sie selbst fest, was passieren soll, wenn mehr oder weniger als 3 Argumente in der Commandline eingegeben werden, bzw. wenn eines oder mehrere der Argumente unverständlich sind. Überlegen sie, wie sie ihren Usern Hilfe anbieten können.

Erstellen sie das Programm in der Version 1.0 mit mindestens einer Filter-Funktion, sorgen sie jedoch vor, dass im Endausbau beliebig viele verschiedene Filter-Funktionen ausgeführt werden können.
Auswahl möglicher Filter (als Beispiel & Anregung):

Ersetze alle "non-printable characters" durch ein Platzhalter-Zeichen, z.B. "."

Ersetze alle Kleinbuchstaben durch Großbuchstaben (und umgekehrt)

Ersetze alle Umlaute und das scharfe ß durch äquivalente Zeichenfolgen

Ersetze alle Zeichenfolgen CR/LF durch CR und umgekehrt.

Ersetze alle ANSI-Zeichen durch DOS-Zeichen und umgekehrt

Setze fixe Zeilenlängen ein, d.h. verkürze längere Zeilen auf die gewünschte Länge

Numeriere alle Zeilen einer Datei

Entferne Zeilen-Numerierung aus einer Datei.

Ersetze jedes Auftreten des Wortes " EUR " durch das Zeichen € und umgekehrt.

Erstellen sie so rasch wie möglich eine marktfähige Version 1.0 des Programms FILTER und legen sie eine "Upgrade"-Pipeline für den weiteren Ausbau von FILTER an.

Aktuelle Daten dieser Seite	Letzte Änderung: