Prozesse darstellen

##Wiederholende Prozesse/Abläufe ###Daily Unser Agiles Team besteht aus 5 Teammitglieder. Wir arbeiten nach dem Scrum-Prinzipp. Bei jedem Zusamentreffen der Gruppe wird ein Daily Scrum Meeting gestartet, dieses dauert maximal 10 Minuten. Dabei spricht jedes Teammitglied einzeln über:

• Welche Arbeiten wurde gemacht?
• Gab es Probleme bei diesen Arbeiten? Wenn ja, welche?
  • Dabei darf keine Lösung besprochen werden, denn es besteht die Gefahr, dass nur zwei Personen reden und die anderen Zuhören müssen, ohne das sie irgendetwas mit diesem Thema zu tun haben. So wäre die Zeit der anderen Mitglieders verschwendet. Jedoch kann entschieden werden, wer nach dem Daily der Person bei dem Problem helfen kann.
• Was wird heute erledigt? (oder bis zum nächsten Treffen des Teams)

###Planning Bevor ein Release-Prozess anfängt wird immer zuerst geplannt. Dazu wird ein Planning Meeting mit allen Teammitglieders durchgeführt. Dabei werden die schon vorher erstellen Stories und Tasks geschätz und dann dem Release zugeordnet. Das schätzen dieser Stories funktioniert folgendermasse:

1. Der Task wird von jedem Mitglied gelesen.
2. Jede/-r wählt eine Fibonacci Nummer aus, die dieser denkt würde für den Task passen. Möglich sind: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ∞, ? und ☕.
   1. ? -> Der Task wurde nicht verstanden.
   2. ∞ -> Task muss gesplittet werden, ist unmöglich zu lesen oder ist kontinuierlich durch den ganzen Sprint zu erledigen
   3. ☕ -> Eine Pause wird benötigt.
3. Die Personen, die die tiefste und die höchste Nummer haben, diskutieren warum. Danach wird entschieden, was die definitive Schätzung ist.
4. Dieser Vorgang wiederholt sich bis alle Stories geschätzt wurden.

Später wird der Sprint gestartet und jeden nimmt sich einen Task und weist ihm sich selber zu. Dannach wird er abgearbeitet und dann wird im Trello dokumentiert ob die Schätzung richtig geschätzt wurde oder nicht. Und wie viel Fibonacci Punkte man dann schlussendlich gebraucht hatte.

Review bzw. DOD (Definition of Done)

Sobald ein Task fetig gestellt wurde, wird ein Review , des Typs "Inspektion" durchgeführt. Eine andere Person übernimmt diesen Task, dabei sind seine/ihre Aufgaben:

• bei einer Applikation:
  • Funktionale Testen
  • vorhandene Unit Tests durchzuführen
  • Clean Code und Guidelines sicherzustellen
• bei Texten oder Dokumentation:
  • Verständlichkeit prüfen
  • Roter Faden analysieren
  • Lesbarkeit von Bildern und Diagramme prüfen
  • Vollständigkeit prüfen
  • Grammatik prüfen

Schlägt einer dieser Punkte fehl, wird der Task wieder aufgemacht und die vorherige Person muss die Probleme lösen. Die Review-Person muss nach jedem Review in der Story (Trello) dokumentieren, ob der Task in Ordnung ist oder noch Bearbeitungen braucht (diese müssen beschrieben werden). Sobald der Task reviewed wurde, kann der für diesen Task erstellter Branch in der master gemerged werden.

Wir haben uns explizit entschieden kein Review-Bericht oder Meeting zu erstellen und durchführen. Wir denken, dass dieses Projekt ein kleineres Schulprojekt ist und somit zu viel Zeit aufwenden würde, wenn diese Arbeiten auch noch erledigt werden müssten.

Retro

Nach jedem Release wird eine Retrospektive gemacht. Dabei schreiben alle Mitglieder des Teams positive und negative Punkte auf. Dabei geht es nciht um funktionale oder programmpfezifische Dinge, sondern um zum Beispiel die Team-Atmosphäre. Dies hilft allen Mitglieder, beim nächsten Release, die negativen Punkte zu vermeiden oder zu verbessern und die positiven Punkte beizuhalten. So wird auchjedem klar, wie die anderen Personen denken, dies hilft auch die Teammitglieder zu motivieren.

Während und nach jedem Retro Meeting wird ein kleines Protokoll erstellt.

##Umgang mit Lösungsansatz Sobald eine Personen eine Task bekommt. Muss er sich eine Lösung für das Problem überlegen, wie dies zu lösen sein könnte. Sobald eine gefunden wurde, kann (muss aber nicht) ein AdHoc-Meeting einberufen werden, wobei ein oder mehrere Lösungsvorschläge präsentiert und diskutiert werden. Sobald dies erfolgt ist, kann die Implementation beginnen. Beim Review wird überprüft und die Lösung so wie besprochen implementiert wurde. Wenn kein Meeting durchgeführt wurde, muss die Review-Person den Lösungvorschlag genau durchdenken und sich überlegen obes nicht einen besseren Weg gäbe - ist jedoch nicht immer vorteilhaft, da veilleicht die Arbeit nochmals neu gemacht werden muss.

##Wie erreicht das Team eine kontinuierliche Produktverbesserung? Das Team erreicht eine konntinuierliche Produktverbesserung durch die Reviews und Retros. Das Retro führt zu Verbesserungen im internen Team, somit können Leistungen der einzelnen Mitglieder besser ausgenutzt und eingeplannt werden. Auch können Konflikte inerhalb des Teams verhinderet oder gelöst werden. Das Review verhindert funktionelle Probleme. Da sProgramm wird dadurch durch mehrere Personen, immer wieder getestet. Auch Textstücke werden mehrmals durch verschiedene Personen gelsene, somit ist der Text eher verständlich und fehlerfrei.