koleso-webestimator – Agenten-kalibrierte Schätzungen für Umbraco / .NET
Schätzungen für Umbraco/.NET-Webarbeiten, bei denen ein KI-Agent den Code schreibt und ein Mensch ihn reviewt.
Die wichtigste Tatsache hinter diesem Skill, basierend auf ~300 echten Tickets aus 10 Umbraco-Projekten:
Das Codieren ist selten der Grund für eine falsche Schätzung. Große Arbeiten, die in menschlichen Entwicklertagen geschätzt wurden, überschritten das Ziel um ~4×. Kleine „2–3 h“-Tickets unterschritten das Ziel um 2–3×. Beide Fehler haben dieselbe Ursache: die Arbeit rund um den Code – Deployments, uSync-Importe, manuelle Schritte pro Umgebung, reales CMS-Verhalten, das Tests nicht sehen können, QA-Wellen und Klärungsschleifen mit dem Kunden – wurde entweder als „Risikozuschlag“ aufgebläht oder ganz weggelassen.
Daher hat jede Schätzung hier zwei Hauptkategorien:
- Aufwand – Stunden, die jemand tatsächlich arbeitet: Agenten-Coding + Review plus die Blöcke, die nicht schrumpfen.
- Kalenderzeit – verstrichene Zeit, dominiert von Warten auf Antworten, Deploy-Fenstern und QA-Warteschlangen. Niemals mit dem Aufwand vermischt.
Referenzdateien (lesen, wenn der Schritt es sagt):
references/calibration.md– Agenten-Coding-Raten und die nicht schrumpfenden Blöcke mit Standardgrößenreferences/patterns.md– Referenzzeiten für häufige Umbraco / Razor / Vue / Backoffice-Aufgabenreferences/platform-risks.md– CMS-Verhaltensweisen, die zusätzliche Deploy-Verify-Runden kostenreferences/honesty-rules.md– Pflichtregeln und Eskalationsschwellenreferences/output-format.md– Die interne Aufschlüsselung und die kundenorientierte Antwortreferences/calibration-log.md– Wie man Schätzung vs. Ist aufzeichnet, damit die Zahlen besser werdenreferences/review-checklist.md– Review-Modus: Prüfen einer vorhandenen Schätzung
Arbeitsablauf
Schritt 0 – Finde die Spezifikation und den Plan und entscheide über die Schätzungsbasis
Bevor du Code liest, suche nach Planungsdokumenten zu dieser Aufgabe. Suche in:
- dem Repository:
spec.md,SPEC.md,docs/spec/**,docs/specs/**,docs/plans/**(Dateien mit Namen*-plan.md,*-design.md,*-analysis.md,*-spec*.md),docs/handover/**,docs/adr/**und jede Datei, deren Name den Ticket-Key oder den Feature-Slug enthält; - dem Ticket: seiner Beschreibung, Anhängen und Kommentaren sowie jeder verlinkten Spezifikationsseite (z. B. Confluence);
- früheren Schätzungen für dasselbe Ticket. Eine vorherige Schätzung, eine abgelehnte Option oder eine offene Frage ändert die Zahl.
Wähle dann eine Basis für die Schätzung und gib sie am Anfang der Ausgabe an:
A. Planbasierte Schätzung. Eine Spezifikation und/oder ein Feature-Plan existiert.
- Lese jedes gefundene Dokument vollständig, nicht nur die Überschriften: Anforderungen, Akzeptanzkriterien, Phasen, Dateilisten, offene Fragen, Überarbeitungen/Abweichungen und Review-Entscheidungen.
- Schätze pro Planphase und verwende die eigenen Dateilisten und Schritte des Plans als Unteraufgaben-Gerüst (Schritt 4).
- Ordne jede Spezifikationsanforderung / jedes Akzeptanzkriterium einer Zeile der Schätzung zu. Liste jede Anforderung auf, die keine Phase abdeckt, und jede Phase, die keine Anforderung verlangt.
- Übernimm die offenen Fragen des Plans in die Fragenliste der Ausgabe, jeweils mit ihrer Standardantwort.
- Prüfe, ob der Plan veraltet ist: Vergleiche, was er nennt (Dateien, Aliase, Dokumenttypen) mit dem aktuellen Code. Zeilen, die nicht mehr passen, sind eine Annahme, die gekennzeichnet werden muss, nicht etwas, das stillschweigend bepreist wird.
- Spannen können enger und die Konfidenz höher sein (siehe
references/honesty-rules.md).
B. Schnelle Schätzung (sichtbarer Umfang). Keine Spezifikation und kein Plan gefunden.
- Sage es gleich am Anfang deutlich: „Keine Spezifikation oder Feature-Plan gefunden – dies ist eine schnelle Schätzung des sichtbaren Umfangs.“ Liste auf, wo du gesucht hast.
- Schätze nur aus dem Tickettext und dem Code. Spannen sind weiter und die Konfidenz ist auf Mittel begrenzt.
- Liste auf, was eine Spezifikation oder ein Plan klären müsste, damit die Zahl stabiler wird (die Fragen, die betroffenen Bereiche, die du nicht eingrenzen konntest).
- Biete den nächsten Schritt an: Schreibe einen Plan für das Ticket und schätze dann erneut daraus (Basis A). Sage, in welche Richtung du erwartest, dass sich die planbasierte Zahl bewegt, und warum.
Wenn nur ein partielles Dokument existiert (z. B. eine Spezifikation aber kein Plan oder ein Plan für eine andere Phase), verwende Basis A für das, was es abdeckt, und Basis B für den Rest, und kennzeichne jede Zeile.
Auch: Wenn ein Kalibrierungsprotokoll existiert (references/calibration-log.md erklärt wo), lies die letzten Einträge für
ähnliche Arbeitstypen.
Schritt 1 – Erkenne den Stack
Verwende deine Datei-Suchwerkzeuge (keine Shell-spezifischen Befehle – dies läuft oft auf Windows). Notiere:
| Suche nach | Sagt dir |
|---|---|
*.csproj → Umbraco.Cms PackageReference-Version, TargetFramework | Umbraco-Hauptversion (10/13 = AngularJS Backoffice; 14+ = Bellissima Lit/TS) und .NET-Version |
ModelsMode in appsettings*.json, generierter Modelle-Ordner | Stark typisierte Modelle vs. dynamisches IPublishedContent |
uSync/-Ordner + uSync-Einstellungen (ExportOnSave, ImportOnFirstBoot, deaktivierte Handler) | Ob Schemaänderungen einen manuellen Import pro Umgebung benötigen |
App_Plugins/*/package.manifest vs. umbraco-package.json + ein Client/ Vite-Projekt | Backoffice-Erweiterungstechnologie |
package.json-Dateien: vue, nuxt, react, lit, jquery; Build-Ausgabeort | Frontend-Typ und ob seine Build-Ausgabe eingecheckt ist |
SCSS-Compiler-Konfiguration, eingechecktes kompiliertes CSS, rtl/ltr-Ordner | Style-Pipeline und RTL-Duplizierung |
Sprachen in uSync Languages/, dir="rtl" in Layouts | Anzahl der Kulturen und RTL-Verifikationsaufwand |
| Testprojekte (xUnit/NUnit/Playwright), ob Razor beim Build kompiliert wird | Was ein grüner Testlauf tatsächlich beweist |
Composers/, Hangfire, Examine-Index-Konfiguration, Migrationen, benutzerdefinierte DB-Tabellen | Hintergrundjobs, Suche, benutzerdefinierte Daten |
| CI/Deploy-Dateien, Hosting-Hinweise (App Service, IIS, Docker) | Wie viele Umgebungen und ob Deployments manuell sind |
Wenn du die Codebasis nicht lesen kannst, sage dies in der Ausgabe und erweitere alle Spannen um das 2–3-fache (siehe Ehrlichkeitsregeln).
Schritt 2 – Lese den Code, der der Aufgabe am nächsten ist
Finde bestehende Beispiele: den nächsten vorhandenen Dokumenttyp, Partial, Controller, Vue-Island, Backoffice-Element oder Import, der etwas Ähnliches tut. Lese 2–4 dieser Dateien. Überprüfe jede faktische Behauptung, die du in der Schätzung aufstellen wirst, gegen den Code oder das uSync-Schema – z. B., bevor du schreibst „dieses Feld existiert nicht“, durchsuche die Content-Type-Konfigurationen. Eine falsche Behauptung kostet eine vollständige Kunden-Klärungsschleife.
Schritt 3 – Klassifiziere
| Dimension | Optionen |
|---|---|
| Arbeitstyp | siehe Tabelle in references/calibration.md (Dokumenttyp/Schema, Razor-Seite vs. Design, Vue-Island, Backoffice-Erweiterung, API/Controller, Suche, Hintergrundjob, Import von Kundendaten, Drittanbieter-Integration, Upgrade, Untersuchung, Bug) |
| Vorhandene Beispiele | Hoch / Mittel / Niedrig |
| Spezifikationsklarheit | Klar / Teilweise / Vage |
| Schreibt CMS-Daten? | Erstellt, speichert oder veröffentlicht der Code Inhalte, Blöcke, Medien oder kultur-spezifische Werte? |
| Frontend gegen ein Design? | Pixel-geprüfte Figma-Arbeit löst eine QA-Welle aus |
| Kulturen × Breakpoints | z. B. 3 Sprachen (eine RTL) × Desktop/Mobil |
| Umgebungen, die es erreichen muss | Lokal, Dev, Stage, Prod – und welche Schritte auf welcher manuell sind |
| Externe Partei | Kundeninhalte, eine Vendor-API, ein Drittanbieter-Script, eine Pipeline eines anderen Teams |
Schritt 4 – Zerlege und bewerte das Coding mit Agentengeschwindigkeit
Mit einem Plan (Basis A) sind die Phasen des Plans die übergeordneten Gruppen und seine Schritte/Dateilisten die Unteraufgaben; erfinde keine andere Aufschlüsselung. Ohne Plan (Basis B) erstellst du die Aufschlüsselung selbst.
Zerlege die Arbeit in Unteraufgaben von 15 Min – 2 h Agentenarbeit pro Stück. Bewerte sie anhand
references/patterns.md und der Raten in references/calibration.md. Füge dann Review-Zeit hinzu
(Standard 30–50 % des Agenten-Codings für Produktionscode; weniger für Tests und Styles).
Bewerte Coding niemals in menschlichen Entwicklertagen und füge dann „Risikozuschlag“ hinzu. Das ist der ~4×-Überschuss.
Wenn ein Referenzwert, den du verwendest, in menschlicher Zeit ist, konvertiere ihn mit den Multiplikatoren in calibration.md.
Schritt 5 – Füge die Blöcke hinzu, die nicht schrumpfen
Aus references/calibration.md → „Nicht schrumpfende Blöcke“. Füge jeden zutreffenden als eigene Zeile hinzu,
mit eigener Spanne:
- Ship-Overhead pro Umgebung (Build, Deploy, uSync-Import, Wörterbuch-/Inhaltsbearbeitungen, erneutes Speichern, Smoke-Check)
- Echte CMS-Verifikationsrunden wenn der Code CMS-Daten schreibt oder vom Laufzeitverhalten abhängt (
platform-risks.md) - Eigentümer-/Lokaler Lauf + QA-Übergabe
- QA-Welle für Frontend-Arbeiten gegen ein Design (Triage, Fixes, „Kein Bug“-Antworten)
- Mehrsprachige / RTL-Verifikationsmatrix
- Klärungsschleifen die du erwartest, bevor der Umfang festgelegt ist
- Upgrade-Schleppe für Versionsupgrades (Regression-Lauf, Runbook, Probe, Post-Deploy-Fixes)
- Prozess-Overhead wenn das Team Pläne, Reviews, Verifikationsdokumente und Übergaben pro Ticket schreibt
Wende die Klein-Ticket-Untergrenze an: jedes Ticket, das eine gemeinsame Umgebung erreichen muss, kostet mindestens den Ship-Overhead, selbst wenn der Code nur eine Zeile ist.
Schritt 6 – Kalenderzeit
Liste auf, wovon die verstrichene Zeit abhängt: offene Fragen an den Kunden, Inhalte die der Kunde liefern muss, Anbieterantworten, Deploy-Fenster, QA-Verfügbarkeit. Gib die Kalenderzeit separat an (z. B. „2–3 h Aufwand; realistisch 1–2 Wochen verstrichen, während Q1–Q4 beantwortet werden“).
Schritt 7 – Selbstprüfung
- Unteraufgaben-Spannen ergeben den Gesamtwert.
- Keine einzelne Unteraufgabe ist über 2 h Agentenarbeit ohne aufgeteilt zu sein.
- Jeder nicht schrumpfende Block wurde berücksichtigt; die ausgelassenen wurden absichtlich ausgelassen (sage warum).
- Keine menschlichen Entwicklertage irgendwo; eine Einheit (Stunden) durchgehend.
- Jede „existiert nicht“ / „bereits unterstützt“-Behauptung wurde im Code oder Schema verifiziert.
- Konfidenz ist konsistent mit den Modifikatoren in
honesty-rules.md. - Gesamt > 40 h → in Meilensteine aufteilen und jeden schätzen.
- Die Basis (planbasiert / schnell / gemischt) wird oben angegeben. Mit einem Plan wird jede Spezifikationsanforderung einer Zeile zugeordnet und jede Planphase bepreist. Ohne einen Plan sagt die Ausgabe dies und listet auf, wo du gesucht hast.
Schritt 8 – Ausgabe
Verwende references/output-format.md: eine interne Aufschlüsselung für den Entwickler und eine kundenorientierte Antwort
(Tabelle mit Stundenspannen, Gesamtspanne, separat bepreiste Optionen, Annahmen, nummerierte Fragen jeweils mit der
Standardantwort, die die Schätzung annimmt, Risiken, Kalendernotiz).
Notiere dann die Schätzung im Kalibrierungsprotokoll (references/calibration-log.md): automatisch, wenn die
Anweisungen des Benutzers einen Protokollort nennen, andernfalls biete an, eines zu beginnen. Protokolliere, was das Skill
produziert hat und, sobald bekannt, was tatsächlich an den Kunden gesendet wurde.
Modi
Einzeln – der Arbeitsablauf oben.
Stapel – für eine Spezifikation, ein Epic oder ein Backlog: führe Schritte 0–2 einmal aus, dann Schritte 3–7 pro Element (2–5 Unteraufgaben pro Stück). Ausgabe: eine Tabelle (Element, Ebene, Aufwandsspanne, Größe, Konfidenz, Top-Risiko), gemeinsame Annahmen, abteilungsübergreifende Abhängigkeiten, eine vorgeschlagene Reihenfolge und die nicht schrumpfenden Blöcke einmal für den gesamten Stapel, wo sie wirklich geteilt werden (ein Deploy + ein uSync-Import können mehrere Elemente tragen; eine QA-Welle pro Seite, nicht pro Element).
Neuschätzung – nachdem der Kunde Fragen beantwortet oder der Umfang sich geändert hat: zeige nur das Delta (entfernte Zeilen, hinzugefügte Zeilen, überarbeiteter Gesamtwert, welche Frage es verursacht hat). Kunden beantworten die Fragen und bitten dann darum, die Zahl zu bestätigen – mach das Delta einfach zu genehmigen.
Review – wenn eine Schätzung bereits existiert (in einer Spezifikation, einem Plan, einem Ticket-Kommentar) und du gebeten wirst, sie zu
prüfen: schätze nicht von Grund auf neu. Folge references/review-checklist.md:
- sammle alle Versionen: das eingecheckte Dokument, die Kundenkopie, den Code, den es zitiert;
- überprüfe die Arithmetik, dann ob Basis und Konfidenz den Ehrlichkeitsregeln entsprechen;
- überprüfe die Struktur (Review-Anteil, Blöcke, Anforderungsabdeckung, Optionen, Standardwerte);
- überprüfe die Schlüsselfakten erneut in Code und Schema und suche nach den Plattformrisiken, die es übersieht.
Trenne interne Korrekturen von Änderungen, die der Kunde sehen muss. Empfehle, eine Zahl nur dann erneut zu veröffentlichen, wenn sie sich ändert.
Kalibrieren – wenn du gebeten wirst, zu bewerten, wie die Schätzungen gelaufen sind („wie genau waren wir“, „kalibriere das Skill“, „Retrospektive zu den Schätzungen“), oder am Ende eines Testzeitraums:
- Lese das gesamte Kalibrierungsprotokoll. Fülle für jeden abgeschlossenen Eintrag den Ist-Wert und seine Quelle (eigene Zeit, Ticket-Worklog – beachte, wenn es ein Team-Gesamtwert ist –, git aktive Tage) aus oder prüfe ihn; frage nach fehlenden Ist-Werten, anstatt zu raten.
- Berechne Verhältnisse pro Arbeitstyp und pro Block, für die an den Kunden gesendete Zahl und für die Zahl des Skills.
- Finde die systematischen Fehler: welche Arbeitstypen, welche Blöcke (QA-Welle, Ship-Overhead, Verifikationsrunden, Klärung), welche Regeln (Konfidenz, Klein-Ticket-Untergrenze) waren falsch, und wo die manuellen Anpassungen richtig waren.
- Schlage konkrete Änderungen an
references/calibration.md,patterns.md,platform-risks.mdoder den Regeln vor, jede verknüpft mit den Protokollzeilen, die sie rechtfertigen. Bei weniger als ~3 Datenpunkten für einen Typ: vermerken, nicht ändern. - Wende nur die Änderungen an, die der Benutzer genehmigt, füge einen datierten Changelog-Eintrag zur README des Skills hinzu und füge eine Zeile zum Protokoll hinzu, die besagt, welche Kalibrierung die nächsten Schätzungen verwenden.
Untersuchung – für „Finde heraus, warum…“-Tickets: Timebox setzen (typischerweise 0,25–1 h), angeben, was die Timebox bringt, und die wahrscheinlichen Ergebnisse auflisten, einschließlich „kein Bug“, „bereits eingebaut“ und „Upstream-CMS-Bug – warte auf Version X“. Diese Ergebnisse sind häufig und günstig; bepreise eine Untersuchung nicht so, als ob eine Behebung sicher ist.