Skip to content

Instantly share code, notes, and snippets.

@TheMeinerLP

TheMeinerLP/EinfachGustaf.md

Last active December 29, 2025 00:23
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save TheMeinerLP/1097d07896b96baf1f309838bd3e0678 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save TheMeinerLP/1097d07896b96baf1f309838bd3e0678 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
EinfachGustaf.md

gRPC-Learning + Feature-Aufwand für Bukkit: Punktmodell → Zeit

Ziel: Vorhersagen, wie viel Zeit ein Bukkit-Entwickler braucht, um gRPC produktiv zu nutzen. Dazu trennen wir Feature-Aufwand (Produktivcode) und Anlern-Aufwand (Lernrampe), rechnen beides in Points und wandeln Points über Velocity in Personentage um.

1) Grundidee

Gesamtdauer besteht aus:

  • Feature-Aufwand: der konkrete Code, den wir liefern.
  • Anlern-Aufwand: die Lernrampe (gRPC/Tooling/Async/Shading), bis jemand stabil liefern kann.

Beides wird als Points bewertet.

2) Feature-Points

Wir bewerten pro Dimension einen Wert von 1 bis 5 und gewichten ihn.

Dimensionen (1–5):

  • C = Logik-Komplexität
  • I = Integrationen/Externes (gRPC-Service, Auth, Netzwerk)
  • B = Bukkit-/Plugin-Friction (Mainthread, Lifecycle, Scheduler)
  • U = Unklarheit/Risiko
  • Q = Qualitätsanspruch (Tests, Timeouts, Retries, Observability)

Formel: P_feat = 2C + 1.5I + 1B + 1.5U + 1*Q

3) Learning-Points

Für relevante Skill-Themen schätzen wir Familiarity F im Bereich [0..1]:

  • 0 = komplett neu
  • 1 = sitzt sicher

Faktoren:

  • F_grpc = gRPC/Protobuf Erfahrung
  • F_async = Async/Concurrency Erfahrung
  • F_build = Gradle/Maven Tooling & Codegen Erfahrung
  • F_shade = Shading/Relocation/Plugin-Classloader Erfahrung

Formel: P_learn = 8*(1 - F_grpc) + 3*(1 - F_async) + 2*(1 - F_build) + 4*(1 - F_shade)

4) Umrechnung in Zeit (Personentage)

Wir nehmen:

  • V = Velocity in Points pro Personentag (aus historischen Daten, sonst schätzen)
  • M = Overhead-Faktor (Meetings, Reviews, CI, Support), typisch 1.15–1.40

Formel: T_days = ((P_feat + P_learn) / V) * M

5) Beispielrechnung: Bukkit-Dev baut gRPC-Client produktiv

Feature: Plugin lädt Spielerprofil per unary gRPC call, macht das async, bringt Ergebnis main-thread-sicher zurück, mit Timeouts/Logging und sauberem Packaging.

Schritt A: Feature-Bewertung (1–5)

C=2 (wenig Logik) I=3 (externer Call, Channel, Fehlerfälle) B=3 (Bukkit-Threading/Lifecycle) U=2 (relativ klar) Q=3 (solide Robustheit)

Berechnung: P_feat = 22 + 1.53 + 13 + 1.52 + 1*3 = 4 + 4.5 + 3 + 3 + 3 = 17.5

Schritt B: Familiarity (0–1)

F_grpc=0.1 (fast neu) F_async=0.6 (okay) F_build=0.7 (okay) F_shade=0.3 (unsicher)

Berechnung: P_learn = 8*(1-0.1) + 3*(1-0.6) + 2*(1-0.7) + 4*(1-0.3) = 80.9 + 30.4 + 20.3 + 40.7 = 7.2 + 1.2 + 0.6 + 2.8 = 11.8

Schritt C: Zeitberechnung

P_total = P_feat + P_learn = 17.5 + 11.8 = 29.3

Annahmen: V = 5 Points/Tag M = 1.25

T_days = (29.3 / 5) * 1.25 = 5.86 * 1.25 = 7.325

Ergebnis: ca. 7.3 Personentage bis “produktiver gRPC-Client im Bukkit-Plugin” (unter diesen Annahmen).

6) P80 statt Wunschdenken

Für eine konservativere Schätzung: T_P80 ≈ T_days * 1.4 bis 1.6

Grund: Bukkit + gRPC trifft gerne auf Threading-Fallen, Dependency-Konflikte, Shading/Relocation und Debugging.

7) Kalibrierung (damit’s nicht nur hübsch aussieht)

Damit das Modell treffsicher wird, braucht ihr:

  1. historische Daten → Velocity V bestimmen
  2. 10–30 alte Tickets nachträglich scoren → Gewichte feinjustieren

Ohne Kalibrierung bleibt es eine Zahl, die sich wichtig fühlt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment