Spielregeln - srybi/datavis GitHub Wiki

Die Spielregeln spiegeln ursprünglich festgelegte Gedanken zum Teamwork und während des Projekt aufgekommene "Lessons Learned" wieder.

Sie werden nicht strikt kontrolliert sondern dienen stattdessen jedem als Leitfaden für das reibungslose Arbeiten im Projekt.

PL: Einladung wird spätestens 3 Tage vor dem Meeting gesendet. Formal, mit Agenda. An: Kunde, Coach, Team.

Protokoll spätestens 3 Tage nach Meeting kurze Benachrichtigung per E-Mail an Kunde, Team, Coach,

Es muss bei jedem stattfinden Meeting Protokoll geführt werden. Das Team wechselt sich intern mit der Protokollführung ab. Das Template ist im Wiki Repository abgelegt. Das Protokoll muss folgende Punkte beinhalten:

Disclaimer:
Tatsächliche Stand-Up Meetings, mit den Themen (What have I done? What was the problem? What will I do?) werden im Team nicht durchgeführt. Im Laufe der Sprints hat sich jedoch trotzdem eine Alternativlösung ergeben, die hier dokumentiert wird.

Das Team trifft sich bei Bedarf in kurzen Discord-Sessions, um den Stand der Entwicklung abzusprechen. Um den Aufwand dieser Treffen nicht zu erhöhen, sind Protokolle hier nicht notwendig. Es ist jedoch trotzdem zu empfehlen kurz den Inhalt des Treffens festzuhalten. Entweder auf dem Discord Server oder auf der zur Verfügung gestellten Wiki-Page.

Außerdem ist jeder Entwickler dazu aufgefordert seinen Fortschritt durch eine Chat Message im Channel #coding zu dokumentieren.

• Zeit
• Anwesende
• Protokollführer
• Grober Inhalt des Meetings
• Beschlüsse, Feststellungen & Action Items

Nach Fertigstellung des Protokolls muss dieses...

• Vom QB freigegeben werden
• Im Wiki Repository abgelegt und in der Terminübersicht verlinkt werden

Die README.md Datei ist der Einstiegspunkt für den Besucher unseres Repositories und muss deswegen die folgende Punkte abgedeckt haben

• Kurze Beschreibung der App
• Installationsanleitung
• Überblick der Verzeichnisstruktur

Die oben gennanten Punkte müssen im produktiven Branch stets zu dem aktuellen Stand der Applikation passsen.

Im Repository wird nach dem Git-Flow Branching Modell gearbeitet. Eine genauere Erklärung ist im README zu finden. Alle neu angelegten branches für features, fixes, etc. müssen aus dem Development-Branch stammen. Deswegen die folgenden Schritte beachten:

git checkout dev
git branch feature/new-cool-stuff
git checkout feature/new-cool-stuff

19.05: Das 4-Augen Prinzip um auf den Dev-Branch zu mergen wird aufgehoben. Ein voller Review findet nicht statt und somit stellt dies nur ein Hindernis dar. Das 4-Augen Prinzip für den Prod-Branch bleibt bestehen.

Um eine saubere Versionskontrolle zu gewährleisten ist eine saubere Commit-History ausschlaggebend.

• Alle Commit Messages sollten einen ähnlichen Aufbau haben. Eine gute Vorgehensweise ist hier zufinden. Im Wesentlichen muss die Commit Message in folgende Satzstruktur eingefügt werden können:
  If applied, this commit will >>commit msg<<.

  Beispiel:
  Der Entwickler hat einen Schreibfehler im README verbessert. Der folgende Commit-Befehl ist zu verwenden:
  git commit -m "Fix Typo in README"

• Commits decken im besten Fall nur einen einzelnen Teil der Änderung ab. Ein Entwickler muss somit im Laufe seiner Session mehr mals commiten. Beim Arbeiten mit dem Terminal kann der Dateipfad übergeben werden

  Beispiel (weiterführend):
  Der Entwickler hat bevor er den Schreibfehler im README gefunden und verbessert hat, auch noch andere Datein bearbeitet. Es ist nun wichtig nicht alle seine Änderungen auf ein Mal zu commiten. Der folgenden Commit-Befehl ist zu verwenden:
  git commit -m "Fix Typo in README" ./README.md

Um den Code für andere Teammitglieder zugänglicher zu machen, ist darauf zu achten Kommentare hinzuzufügen.

Die Ausgestaltung und der Umfang liegt im eigenen Ermessen.

• Nie im Try-Catch nur ein e.printStackTrace(); eintragen, da dieser in Verbose Loggt. Immer mindestens eine Log.Error oder Log.Debug hinzufügen.

• In Protokollen festgehaltene Action Items werden als Issues aufgenommen. Jedes Teammitglied ist für sein zugewiesenes Issue verantwortlich, kontrolliert und schließt es selber.

• User Stories werden vor der Bearbeitung noch einmal auf Konsistenz und Vollständigkeit der Akzeptanzkriterien geprüft

• Qualitätsanforderungen werden als User Story markiert und im Dev Board aufgenommen

• Bugfixes werden im Dev-Board aufgenommen

Alle notwendigen Dokumente werden entweder in im Repository der Wiki abgelegt oder über onedrive für jeden sichtbar dargestellt

Folgende Syntax für Page-Links innerhalb der Wiki nutzen:

[Link zur page](Page)  # nicht die komplette URL verwenden

• Die Dokumente sind sichtbar zu verlinken, damit man schnell und einfach auf sie zugreifen kann
• Falls ein Teammitglied bei einem Meeting oder Standup nicht teilnehmen konnte, wird er zeitnahe über Discord über den (neuen) Stand des Projektes informiert.
• Die zum JF-fertigzustellende Arbeit ist spätestens am Samstag der Woche zu besprechen, damit eventuelle Änderungen bis zu einem finalen Review spätestens am Sonntag durchgeführt werden können.
• Es wird zwischen Teammeetings, Besprechungen und Standups unterschieden:

Teammeetings erfordern normalerweise die Anwesenheit aller und werden mit normalem Protokoll geführt.

Besprechungen sind terminierte und spontan entstandene Meetings zwischen zwei oder mehr Mitgliedern. Sie werden stichpunktartig in "Standups" festgehalten

Standups sind 15-minütige agile Meetings. Mitglieder präsentieren kurz ihre geleistete Arbeit und halten den Stand selbständig in "Standups" fest.

• Changes werden in Anlehnung an den agilen SCRUM Prozess durchgeführt.
• User Stories werden im Sprint Backlog vor jedem Sprint nach Team und Kundenabsprache gewählt.
• Während des Sprint gibt es keine Änderungen am Sprint Backlog
• Nach Sprint werden die implementierten Änderungen dem Kunden präsentiert und Feedback angenommen
• Neue Anforderungen / Anforderungsänderungen werden für den nächsten Sprint Backlog gewählt