Direkt zum Hauptinhalt

Absprachen (Entwicklung) [Code of conduct]

IssueBoard

Einträge

  • Kein Editieren von Kommentaren durch andere Entwickler // 2020-10-06
  • Keine endlose Checkbox-Liste // 2020-10-06
  • Bei Problemen mit Oberflächen sollte vor dem MergeRequest der Ersteller des Eintrags die Lösung prüfen // 2012-07-12 (siehe Erkannte Probleme > Auslastung durch MR)
  • Sammelbugs nur für Feldtests: Aufwendigen Problemfällen, die ‚nur‘ unter realen Bedingungen wirklich geprüft werden können. // 2020-11-30 (siehe Erkannte Probleme > Feldtest)

Bearbeitung von Einträgen

  • Einträge (Issue) werden durch Sternanzahl priorisiert unabhängig davon, welche weiteren Markierungen (Label) er trägt // 2022-11-01
  • Über die Markierungen wird gesteuert, was für ein Eintrag hier gemeint ist // 2022-11-01
    • Neue Funktionalität mit Einfluss auf die Oberfläche (Kunden-releveant) → Feature-Request
    • Neue Funktionalität ohne Einfluss auf die Oberfläche, Umbauten in der Auslieferungsstruktur → Tech Issue / Optimization
    • Umbau der alten Funktionalität auf moderne Füße → Rework / Optimization
    • Fehler und Fehlverhalten → Bug
  • Meilensteine werden entweder zeitlich limitiert oder sind das Sammelbecken für technische / thematische Einträge. Neue Einträge werden Montags einem Meilenstein zugewiesen und werden priorisiert // 2022-11-01
  • Um die Schätzungen zu verbessern, soll, wenn ein Eintrag eine Zeitschätzung hat (Kommentar: /estimate <Zeit> - neuere Einträge überschreiben alte), der Entwickler die aufgewendete Zeit in das Issue schreiben (Kommentar: /spend <Zeit> - mehrere Einträge addieren sich).  // 2021-01-18
  • Wenn die Stage Analysis fertig ist, soll eine Schätzung für den Zeitaufwand eingetragen werden. // 2021-02-15
  • Die Einträge werden im Montags-Meeting geschlossen, um ggf. noch Labels zu vergeben, wie 'Tested' oder 'ToBeTested' // 2021-03-12
  • Die Einträge, die den Test nicht bestanden haben, werden vom Tester zurück in die Stage Development geschoben. // 2022-01-31
  • Einträge, die mehr Aufwand als einen Tag bedeuten oder umfangreichere Umbauten mit sich ziehen ('Feature', 'Optimization'), sollen einen Reviewer zugewiesen bekommen (idealerweise am Montag, wenn der Auftrag verteilt wird (siehe Montags-Meeting 2021-07-12). // 2022-01-31
  • Bei der Entwicklung darauf achten, nur Dateien einzuschecken, die auch wirklich Teil der Lösung sind, um die Übersicht für den Reviewer nicht zu erschweren. // 2022-02-28
  • Teilerfolge nicht auf State: Review, sondern Merge-Request (Draft/WIP) // 2020-10-06
  • Draft/WIP-Merge-Requests werden nur dann überprüft, wenn eine namentliche Nennung erfolgt.
    Mittels Drafts/WIP können aber schon mal die Pipeline getestet werden. // 2021-01-29
  • Merge-Requests erhalten, da sie für das Change-Log genutzt werden sollen, eine ordentlich beschreibende Überschrift und eine Beschreibung der Änderungen mit dem Link zum zugehörigen Issue. Darüberhinaus gehende Testanweisungen sollten in einen separaten Kommentar laufen.  // 2023-01-16
  • Um den Überblick zu bewahren, schaut sich FD im Wesentlichen nur noch Meilensteine an die Feature-getrieben sind. Technische Aufgaben klärt das Team unter sich, aber Rückfragen sind jederzeit erlaubt (siehe Erkannte Probleme > Hohe Auslastung) // 2022-11-01
  • Es soll keine Issues mehr bearbeitet werden, ohne dass sie einem Meilenstein zugewiesen sind, eine Schätzung vorliegt und Labels vorhanden sind (siehe Erkannte Probleme > Übersicht) // 2024-02-12

  • Bearbeitungsreihenfolge der Einträge: // 2020-10-06

    1. Bugs (Sterne 3, 2, 1)
    2. Optimization (Sterne 3, 2, 1)
    3. Feature Request (Sterne 3, 2, 1)

Montags-Meeting:

Vorbereitung

  • Vorstellung von Features. Neue entwickelte Features sollen präsentiert werden. // 2021-01-29
  • Prüfen des Stand: (Offene Issues, Geschlossene Issues, Worum geht es in diesen Issues?, ...) // 2020-10-06
    • Wenn Issue länger als 5 Tage gedauert hat: // 2020-11-02 (siehe Erkannte Probleme > Geringe-Entwickler-Performance)
      Selbstkritische Prüfung: Was hält mich von der Arbeit ab?
      Pro-Aktiver Zugang bei Problemen/ offenen Punkten; Keine ‚fast-fertig-Issues‘ liegen lassen.
      Aufteilung vorbereiten.
      • Was ist fertig?
      • Welche Punkte sind offen und wie kann man die Aufgabe zerlegen?
      • Wo lagen die Problem mit der Abarbeitung und der Einschätzung?
    • Issues, die aus Sicht des Entwicklers fertig sind (finaler MR - kein Draft), werden von ihm in Review geschoben. Im Meeting wird besprochen, ob dort noch Dokumentationspflicht und Test-Möglichkeit besteht. // 2021-03-22

Durchführung

  • Die Issues werden besprochen und geschaut, ob Dokumentation noch nötig ist und ob ein Test durchgeführt werden kann und ggf. worden ist. // 2021-03-12
  • Im Montag-Meeting sollten für einen Issue nicht nur ein Bearbeiter zugewiesen werden, sondern auch ein Reviewer, der bei den Diskussionen dabei ist und als Co-Entwickler genutzt werden kann, um Fragen zu stellen und ein Review for dem MergeRequest durchzuführen // 2021-07-12 (siehe Erkannte Probleme > Auslastung durch MR)
  • Am Ende des Meetings werden neue Features präsentiert // 2021-01-29
  • Alle Issues, die To-Be-Documented-Label haben oder die ein ChangeLog-Label, müssen in dem Changelog beachtet werden.

Erkannte Probleme:

  • [2020-11-02]: Geringe-Entwickler-Performance: Es werden kaum Issues abgeschlossen
  • [2020-11-30]: Feldtest: Sammelbugs zum Testen von aufwendigen Problemfällen, die ‚nur‘ unter realen Bedingungen wirklich geprüft werden können.
  • [2021-07-12]: Auslastung durch MR: Die Menge der MergeRequests und die Kontrolle dieser lastet Andreas und Holger stark aus, so dass kaum produktive Arbeit getätigt werden kann. Darüber hinaus erzeugen Oberflächen-Issues häufig noch mehrere MRs, da das Ergebnis nicht den Vorstellungen des Issue-Erstellers wiederspiegeln.
  • [2022-11-01]: Hohe Auslastung von Frank Dühnelt. Gerade in der Saison ist es ein extrem schwere Aufgabe, den Überblick über die Einträge zu wahren, Entwickler-Anfragen und Kundenbeschwerden gerecht zu werden.
  • [2024-02-12]: Übersicht: Damit Frank Dühnelt die Aufgaben gegeneinander bewerten kann, soll es keine Issue geben, die keinem Meilenstein zugewiesen sind und bei den Entwicklern sollten nur wenige nicht-In-Bearbeitung-befindliche Issues liegen.
nach oben