|
|
|
# Software Entwicklung
|
|
|
|
Wir arbeiten grundsätzlich agil, orientiert an SCRUM.
|
|
|
|
|
|
|
|
### Wichtigste Rollen:
|
|
|
|
- Product Owner: Michael
|
|
|
|
- Scrum Master: Simon - Entwickler: wir alle
|
|
|
|
- Stakeholders: alle Projektpartner, Datenschutzkoordinatorin, ...
|
|
|
|
|
|
|
|
### Issues
|
|
|
|
- Alle identifizierten Aufgaben werden als Issues im GitLab abgelegt. Sie definieren das Backlog.
|
|
|
|
- Im Rahmen eines Sprints wandern die entsprechend priorisierten Aufgaben in den Sprint Meilenstein.
|
|
|
|
|
|
|
|
### Sprints
|
|
|
|
Siehe dazu auch https://www.inloox.de/unternehmen/blog/artikel/scrum-grundlagen-einfach-erklaert-der-sprint/
|
|
|
|
- Ein Sprint beginnt mit einem Sprint Planning Meeting. Ein Sprint hat eine definierte Dauer (momentan etwa einen Monat), typisch wären eher drei Wochen.
|
|
|
|
- Im Sprint Planning Meeting werden gemeinsam die Aufgaben aus dem Backlog ausgewählt, die am wichtigsten sind, und die im Gesamtumfang gut in diesem Sprint abgearbeitet werden können.
|
|
|
|
- Die Aufgaben in einem Sprint werden typischerweise nicht geändert. Ausnahme sind allerdings ggf. die Behebung von Softwarefehlern oder kurzfristig sehr dringenden Aufgaben.
|
|
|
|
- Am Burn-Down-Chart kann man nachvollziehen, ob der Sprint tatsächlich in der entsprechenden Zeit sein Ziel erreicht. Man sollte sich deshalb immer möglichst auf eine Aufgabe konzentrieren und diese abschliessen.
|
|
|
|
- Am Ende eine Sprints gibt es ein Sprint Review Meeting bzw. Sprint Retrospection Meeting
|
|
|
|
|
|
|
|
# Definition of Done (DoD) für Issues
|
|
|
|
|
|
|
|
- Idealerweise sollten alle Issues als **Branches** (nach der Namenskonvention von GitLab und https://nvie.com/posts/a-successful-git-branching-model/) abgearbeitet werden.
|
|
|
|
Ausnahmen: "Triviale" Änderungen: Verbesserungen Testcoverage, Überschaubare Behebung von Code Smells, sehr lokale Änderungen ohne erwartbare Auswirkungen auf andere Entwickler.
|
|
|
|
- **Vier Augenprinzip** (ein anderer Entwickler/Tester/Nutzer) akkzeptiert die Lösung. Bitte nicht selbst einen Issue schliessen, sondern typsicherweise demjenigen zurückgeben, der den Issue angelegt hat.
|
|
|
|
- Nach erfolgreichem "Review" kann der Tester oder der Entwickler den Branch mergen. Anschliessend sollte der Branch gelöscht werden.
|
|
|
|
- **keine bekannten offenen Probleme** (Funktionale Verbesserungen die im Laufe der Entwicklung/Tests identifiziert wurden ggf. ins Backlog)
|
|
|
|
- **Dokumentation**: kritische Konzepte: Interfaces, Komplexe Datenstrukturen müssen dokumentiert sein.
|
|
|
|
- Zielsetzung der Dokumentation:
|
|
|
|
- Ein neuer Entwickler, der sich in JHipster, ElasticSearch, ... allgemein eingearbeitet hat, soll
|
|
|
|
sich mit der CodeAbility-Dokumentation im Projekt zurechtfinden. D.h. Sonderlocken, komplexe Umsetzungen, zusätzliche Architekturprinzipien sollten dokumentiert werden.
|
|
|
|
- **Saubere Code Basis**: Aufräumen von Zwischencode
|
|
|
|
- Erfolgreiche **Unit Tests**: hinreichende Testüberdeckung für neuen Code
|
|
|
|
- Automatisierte Continuous Integration
|
|
|
|
|
|
|
|
# Entwicklungsumgebung vs. Produktive Umgebung
|
|
|
|
|
|
|
|
- Entwicklung und Tests finden **ausschliesslich in der Entwicklungsumgebung (bzw. auf lokalen Umgebungen) statt**
|
|
|
|
- Änderungen an Produktivumgebungen nur, wenn diese vorher in der Entwicklungsumgebung auf ihre Auswirkungen sauber geprüft worden sind.
|
|
|
|
- Minimale Unterbrechungen des produktiven Betriebs. Soweit möglich/sinnvoll angekündigt (z.B. ArTEMiS: Systemmitteilungen, Sharing Plattform: Systemmitteilung über GitLab Messages). Idealerweise außerhalb der Kernzeiten.
|
|
|
|
- Nutzerfreundliche Upgrade Strategien: Beim Update von Formaten (z.B. MetaDaten) sollte eine automatische Migration weitgehend möglich sein.
|
|
|
|
- Das Aufsetzen der Produktivumgebung muss sauber dokumentiert sein. Theoretisch muss anhand der Dokumentation jeder Entwickler in der Lage sein, eine Entwicklungs-/Produktivumgebung aufzusetzen.
|
|
|
|
|
|
|
|
# Security
|
|
|
|
- Starke Passwörter für alle Accounts! Keine Wiederverwendung von Passwörtern!
|
|
|
|
- Password management im Team mit [KeePass](https://keepass.info/))
|
|
|
|
- Möglichst keine Gruppenuser: adminMock, studentMock, ... !
|
|
|
|
- Dokumentation der Backup-Strategie
|
|
|
|
- TODO: Festlegen der Anforderung: Maximale Ausfallzeiten, Maximale Wiederherstellungszeit, Maximale Datenverluste |
