Agiles Vorgehen in der COUNTIT

Agiles Vorgehensmodell in der COUNT IT

Bei COUNT IT bist du nie auf dich alleine gestellt. Hast du Fragen, so helfen dir deine Kollegen/Kolleginnen gerne weiter. 

Als agiles Vorgehensmodell in Projekten verwenden wir zum Großteil SCRUM. Nähere Details hierzu erklären wir hier ...

Mitglieder eines Projektteams sitzen in unmittelbarer Nähe

Die Nähe der Mitglieder fördert nicht nur die Produktivität der MitarbeiterInnen, sondern auch die Kommunikation zwischen ihnen.

Dies wirkt sich positiv auf das Ergebnis aus.

Tunnel- und Pair-Programming

Tunnel-Programming:

Um schwierige Bugs in einem Programmcode zu finden, braucht man höchste Konzentration ohne von außen gestört zu werden.

Um die Umgebung auszublenden gibt es bei uns Kopfhörer und eine Ampel um den anderen Mitarbeiter zu signalisieren, ob man im Tunnel ist oder nicht.

Rot bei der Ampel bedeutet, dass man nicht gestört werden möchte. Gelb bedeutet, dass man nur bedingt gestört werden darf. Und Grün bedeutet, dass man jederzeit gestört werden darf.

Pair-Programming:

Hierbei sitzen zwei Personen an einem PC und tauschen abwechselnd die Tastatur und Maus zum Programmieren, wobei zwischen den Personen keine Schüler-Lehrer Beziehung herrscht.

Das Paar-Programmieren verbessert die Qualität des Codes und somit des Projekts.

Team Foundation Server

SCRUM-Dashboard

Das SCRUM-Dashboard ist mit einem Taskboard aus SCRUM vergleichbar.

Es bietet eine Übersicht über die Aufgaben des Projektes und deren Fertigstellungsgrad.

Die Spalten des SCRUM-Dashboards im TFS sind "To do", "In progress" und "Done".

SCRUM-Dashboard im Team Foundation Server

Jeder Check-In kann zu einem Task in dem SCRUM Dashboard zugewiesen werden.

Dies unterstützt die Überschaubarkeit der Aufgaben und deren Erreichung.

Gated Check-In

Um Änderungen an einem Projekt auf den TFS laden zu können, wird vorerst geprüft, ob mit dem hinzufügen von neuen Funktionen, nicht alte Funktionen beschädigt worden sind.

Um zu prüfen ob alle Funktionen funktionieren, werden vor einem Check-In sogenannte statische Code-Analysen und ausgewählte Integrationstests durchgeführt.

Die statische Code-Analysen prüfen den Quellcode auf eine Reihe formaler Fehler. Die Integrationstests prüfen, ob alle Funktionen interagieren können und das richtige Resultat liefern.

Code Reviews

Code Reviews finden häufig im Pair-Programming statt, was eine Verbesserung der Codequalität bewirkt.

Ein Code Review ist das durchlesen eines Programmcodes von einem anderen Mitarbeiten. Dies kann zum Beispiel auch mögliche Fehler im Programm aufdecken.

Nightly Build

Zwischen jeden Arbeitstag werden über die Nacht alle Integrationstests durchgeführt.

Bei Gated Check-In's ist es nicht von Vorteil alle Integrationstests auszuführen, da es zu viel Zeit in Anspruch nehmen würde. Deswegen werden sie über die Nacht durch ausgeführt.

Dies erspart Zeit, da nicht während der Arbeitszeit auf die Integrationstestergebnisse gewartet werden muss, sondern das Ergebnis sofort am frühen Morgen zu sehen sind.

Automatisierte Tests

Test die oft wiederholte werden, sollten automatisiert werden. Der Vorteil davon sind detailliertere Rückmeldungen als bei manuellen Tests.

Der Nachteil davon ist, dass keine unvorhersehbaren Fehler gefunden werden können.

Whiteboards

Für die schnelle Aufzeichnung und Skizzierung von Diagrammen, Datenmodellen oder sonstiges, ist ein Whiteboard sehr hilfreich.

Das Whiteboard bietet mehr Platz als ein Papier und da es an der Wand hängt, bietet es Sicht für alle Mitarbeiter im Raum.