Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
+359
@@ -0,0 +1,359 @@
|
||||
# Agile Teams (Work in Progress)
|
||||
|
||||
Version: 82 | Last modified: 2026-05-20T12:07:14.685+02:00
|
||||
Source: confluence page ID 270407642
|
||||
|
||||
---
|
||||
|
||||
Teams:
|
||||
|
||||
Art TrioBild (freiwillig) | Name | Rolle | seit wann bei KuK | Kernkompetenzen | Homebase | Sonstiges (freiwillig) |
|
||||
|
||||
|  | RTE | 01.02.2024 | Aufbau und Steuerung eines leistungsfähigen ARTs.
|
||||
Role Model für agile Werte. Zusammen mit unserem Agile Coach und den Team Coaches förder und forder ich den agilen Reifegrad und das Mindset über alle ART Mitglieder hinweg. | Bielefeld | Earlybird Â
|
||||
Sport Â
|
||||
Frauen bei der Bahn Mitglied |
|
||||
|
||||
| Â
|
||||
| System Architekt | Â
|
||||
| Medieninformatiker
|
||||
Backend + Frontend-Entwicklung
|
||||
Verteilte Systeme / Microservices
|
||||
DevOps, CI/CD Pipelines
|
||||
Kubernetes, Container
|
||||
AWS, Cloud Native, Serverless
|
||||
Chaos Engineering
|
||||
Testing
|
||||
Machine Learning
|
||||
seit 2017 bei der Bahn
|
||||
3 Jahre Agile Product Developer be DB Vertrieb
|
||||
3 Jahre Implementation Lead bei DB Vertrieb / DB Fernverkehr
|
||||
seit 2023 Architekt bei der DB Systel
|
||||
seit 2024 Systel PO vom Team NextGT
|
||||
| Office:
|
||||
Frankfurt/Main
|
||||
Home Office: Hasselroth-Niedermittlau (~40 km östlich von Frankfurt)
|
||||
| Papa von Joshua
|
||||
Musiker: Schlagzeug, Gitarre
|
||||
Sport: Kraftsport, EMS, HIT-Training, Joggen, FuÃball
|
||||
Gärtnern: Fachwart für Obst- und Gartenbau, eigener Gemüsegarten, eigenen Apfelwein keltern
|
||||
Technik: Videographie, Fotographie, Audio-Recordings, Computergrafik (2D und 3D)
|
||||
|
|
||||
|
||||
| Â
|
||||
| System Architekt | 01.12.2023 | Ich befinde mich gerne im IT-Umfeld mit Schwerpunkt im (Dev-) Ops Bereich. Meine Werkzeuge sind docker, helm, gitlab, kubernetes, aws. | Berlin | Ich fahre gerne Motorrad, Fahrrad und spiele gerne Tischtennis. |
|
||||
|
||||
| Â | Product Manager | 01.06.2023 | BWLer: Kann theoretisch alles aber nix richtig...Â
|
||||
Ich löse gerne Probleme (daher auch gerne bei der Eisenbahn, da gibt es immer genug) und beschäftige mich gerne mit neuen Themen.
|
||||
Erfahrung:
|
||||
15 Jahre Know-How aus der Produktion im Fernverkehr
|
||||
Datenanalyse
|
||||
Projektmanagement
|
||||
Software Einführung
|
||||
| Friedrichsdorf | Ich bin Papa von 2 wunderbaren Töchtern und wenn ich mit Arbeit und Familie nicht ausgelastet bin dann:
|
||||
versuche ich mich Fit zu halten (Badminton, Rudern, Fahrrad fahren, Rollschuh laufen und im Sommer schwimmen)
|
||||
klimper ich gerne auf meiner Gitarre
|
||||
in dem Jahr geboren, in dem Ralf seine erste Zeile Code geschrieben hat Â
|
||||
|
|
||||
|
||||
| Â | Business Owner | 01.07.2023 | Ingenieur
|
||||
Ich habe Erfahrung als Entwickler, SM, PO, PM und als BO und behaupte einen guten Ãberblick über agile Entwicklung zu haben.
|
||||
| Kölle | Ich versuche einmal Tag Sport zu machen, was mir mittlerweile oft gelingt.Â
|
||||
Ich baue gerne Möbel und besitze super viele Werkzeuge.Â
|
||||
Am liebsten verbringe ich meinen Urlaub auf Segelbooten.Â
|
||||
|
||||
|
|
||||
Team IrisBild (freiwillig) | Name | Rolle | seit wann bei KuK | Kernkompetenzen | Homebase | Sonstiges (freiwillig) |
|
||||
|
||||
|  | Team Coach | 01.04.2024 | Ich lebe agile Werte und Prinzipien und unterstütze mein Team bei der täglichen Arbeit, indem ich als Moderator oder Facilator aggiere. Ich räume Hindernisse aus dem Weg und strebe danach, Prozesse kontinuierlich zu verbessern.Â
|
||||
| Bonn
|
||||
| Ich mag Sommer, Sonne und Strand. Im Winter stehe ich am liebsten auf dem Snowboard. Wenn du was wissen möchtest, stell mir gerne einen Termin für einen Kaffee ein.
|
||||
|
|
||||
|
||||
| Â | Product Owner |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| Â | BE | Ende 2023 | Optimierung, Datenanalyen, Prozesse & Fachlichkeit | Frankfurt a.M. | FuÃball, Musik, Pfadfinder |
|
||||
|
||||
| Â
|
||||
| .NET Entwickler | Juli 2023 | Backend-Entwicklung, Routing, Umlegungsverfahren, Datenbanken, AWS, Docker, Kubernetes | Frankfurt | Engagiere mich als FuÃball-Trainer für die Kinder. Wenn es sich ergibt spiele ich gerne auch mal Schach. |
|
||||
|
||||
|  | Entwickler | Januar 2025 | Backend-Entwicklung, Camunda, Datenbank, AWS, Java | Nürnberg | Ich spiele gerne FuÃball und bin auÃerdem als aktiver Schiedsrichter in der Schiedsrichtergruppe Nürnberg tätig. Zusätzlich spiele ich gerne Videospiele. |
|
||||
|
||||
| Â | Frontend Entwickler |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
Team CortexBild (freiwillig) | Name | Rolle | seit wann bei KuK | Kernkompetenzen | Homebase | Sonstiges (freiwillig) |
|
||||
|
||||
| Â | Product Owner | August 2023 | Eisenbahn und Digitalisierung zusammenbringen mit Fokus auf Fahrplanung
|
||||
Brücken schlagen zwischen fachlichem Prozess und IT
|
||||
Argumente Sammeln und Lösungen finden
|
||||
Zuhören
|
||||
Dinge erklären
|
||||
Netzwerke bilden
|
||||
Von allem ein bisschen (Infrastruktur, Fahrzeug, Betrieb)
|
||||
| Nürnberg | Zwei Drei Kinder, ein Schrebergarten, Sport
|
||||
Baumarkteinkauf mit dem Fahrrad
|
||||
Zwischendurch immer mal wieder daran denken, wie gut es uns doch allen geht
|
||||
|
|
||||
|
||||
|  | BE | Januar 2026 | Analyse von Geschäftsprozessen
|
||||
Anforderungsanalyse, fachliche und technische Analysen
|
||||
Technische Analyse von Schnittstellen
|
||||
Modellierung und Visualisierung von Analyseergebnissen
|
||||
Agile Methoden, Scrum, Kanban
|
||||
Scrum Product Owner
|
||||
Jira, Confluence
|
||||
| Ingolstadt | DrauÃen in der Natur sein, Wandern, Volleyball
|
||||
Brett- und Kartenspiele
|
||||
|
|
||||
|
||||
| Â
|
||||
| Full-Stack Entwickler | Juli 2024 | Entwicklung, Microservices, Infrastruktur, CI/CD und Integration in der Cloud
|
||||
IT-Security
|
||||
Architektur
|
||||
Diverse Mengen an Halbwissen so zusammenführen, dass die Vereinigungsmenge (hoffentlich) Ganzwissen ergibt Â
|
||||
Witze machen, die niemand als Witze erkennt, und Leute dadurch verwirren
|
||||
| Frankfurt | Klettern und Bergsteigen, Abenteuerreisen
|
||||
Ich reise gerne weit, ohne zu fliegen, z.B zu Fuà oder mit Bahn und Schiff. Auch mal gerne bis Teneriffa oder Irland.
|
||||
Musik: Metal, Metalcore, Punk
|
||||
Seit Januar 2025 Vater einer Tochter
|
||||
|
|
||||
|
||||
| Â
|
||||
| Fachlicher AP aus dem Fahrplan | Quartal 2024
|
||||
| Strategische Fahrplan- und Kapazitätsthemen sind mein berufliches Hobby
|
||||
Ansonsten Modellierungstätigkeiten des Güter- und des Personenverkehrs innerhalb unserer Haus- und Hofprodukte Visum, PlanIT und Viriato
|
||||
| Bensheim (an der schönen BergstraÃe ) | Meine Family ("beste Ehefrau von allen" plus 18 Jahre alte Tochter und 11 Jahre alter Sohn)
|
||||
Sonst mache ich sehr gerne Sport (Tennis und Tischtennis jeweils im Verein, früher Handballer) und fotografiere total gerne (wer mal reinschauen möchte ), Wildlife, Makros oder meine Tochter in ihren selbst genähten Kostümen aus früheren Epochen. 😊Â
|
||||
|
||||
|
|
||||
|
||||
| Â
|
||||
| (Frontend-)Entwickler | April 2024 | Alles in und ums (Angular)-Frontend. Mitdenken beim Design und der UX, aber hab auch Backenderfahrungen gemacht und könnte da mitarbeiten.
|
||||
AuÃerdem auch ein kleines bisschen Bahnwissen. Das Team und die Teamstimmung ist mir auch sehr wichtig,
|
||||
| Ottobrunn bei München | Fahrrad (Rennrad) und sehr gerne Ausflüge. (Geschichts-)Museen, kleine und groÃe Städte, wandern.
|
||||
Und 100 andere Hobbys, die immer mal wieder den Weg in mein Leben finden. Wenn ihr mal ein Thema sucht um mit mir zu reden, einfach fragen was grade aktuell ist
|
||||
|
|
||||
|
||||
| Â
|
||||
| UX Consultant | Juli 2023 | Contentmarketing (z.B. DB Planet, Newsletter), Markenidentität entwickeln (z.B. Logo)
|
||||
Rapid Prototyping, Low-Fidelity, High-Fidelity (z.B. Interaktiv und visuell)
|
||||
Nutzer befragen (z.B. Interviews, Umfragen, etc.), Nutzer beobachten, Zielgruppenanalyse (z.B. Persona, Customer Journey, User Journey), User Flows / Use Cases erstellen, Anwendungsanalyse und Bewertung (z.B. Heuristische Analysen, Expertenreview), Validieren, Testing
|
||||
UI Konzeption, Funktionsdesign (Interaktionskonzept, Handbuch), Komponentendesign, Design Systeme nutzen & gestalten (z.B. Standards einsetzen und pflegen), Design spezifizieren (z.B. Erstellung Playbook, Design Guidlines, etc.), Visual Design
|
||||
Business Understanding: Verständnis Anwender / Problem / Aufgabenstellung
|
||||
Features und Stories zielgruppenkonform formulieren (Anforderungen, Akzeptanzkriterien, Benefithypothesis)
|
||||
UX Coaching (z.B. Figma)
|
||||
| Berlin | Ich liebe meine Familie/ koche und backe gerne/ liebe Kunst, Musik, Sprachen und Kulturen
|
||||
AuÃerdem male ich gerne, am liebsten Portraits
|
||||
Ich singe und tanze gerne
|
||||
Ich skate gern, kletter gerne, am liebsten auf Bäumen. Ich schwimme gerne, am liebsten im Meer. Im See ist auch ok.
|
||||
Ich bin liebend gern in der Natur!
|
||||
Fahrrad fahren, Tischtennis spielen
|
||||
Fotografieren, DIY (Häkeln, Schmuck basteln)
|
||||
Alles im Leben feiern
|
||||
|
|
||||
|
||||
| Â |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| Â |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| Â | Frontend-Entwickler | Juni 2025 | Alles rund um Frontend, JavaScript und TypeScript, HTML, CSS
|
||||
UX/UI mitdenken, planen und umsetzen und dabei die Performance im Fokus! | Hannover | Liebe Sprachen, reisen, Kulturen, Architektur und Natur
|
||||
Mache meinen Drohnenführerschein
|
||||
Mache YouTube
|
||||
Investor und Börsianer
|
||||
Fitness
|
||||
|
|
||||
Team ThalamusBild (freiwillig) | Name | Rolle | seit wann bei KuK | Kernkompetenzen | Homebase | Sonstiges (freiwillig) |
|
||||
|
||||
| Â | Product Owner | August 2023 | Reden
|
||||
Ansonsten:Â
|
||||
Prozessanalyse und -design
|
||||
Facharchitektur
|
||||
IT-Anwendungsgestaltung
|
||||
IT-Anwendungen inkl. ihrer fachlichen Prozesse ans Laufen bringen mit allem, was dazu gehört
|
||||
| Bensheim | Lesen, Reisen und Brettspiele
|
||||
Zeit mit meiner Tochter und meinem Mann
|
||||
|
|
||||
|
||||
| Â
|
||||
| Scrum Master | Januar 2025 |
|
||||
|
||||
| Willanzheim |
|
||||
|
|
||||
|
||||
| Â
|
||||
| BE | August 2023 | Ich mag die Diskussion und teile gerne, ob gefragt oder nicht, meine Meinung. Der Eiertanz um den heiÃen Brei ist auch nicht so mein Ding.
|
||||
Sprecht mich gerne an bei Themen rund um Modellierung & Python. Ansonsten bin ich immer für einen schlechten Spruch zu haben!
|
||||
|
|
||||
|
||||
Saarbrücken
|
||||
| Musik
|
||||
Zucht südamerikanischer Zierwelse (L66 & L333)Â
|
||||
Brett- & KartenspieleÂ
|
||||
|
|
||||
|
||||
| Â
|
||||
| BE |
|
||||
|
|
||||
|
||||
|
|
||||
|
||||
|
|
||||
|
|
||||
|
||||
| Â
|
||||
| Backend Entwickler | Q3 / 2024 | Technische Schulden aufbauenhauptsächliche Backend mit Java
|
||||
Frontend nur wenn es sein muss
|
||||
|
||||
| offiziell Frankfurt
|
||||
meistens Geseke
|
||||
|
|
||||
|
||||
|
|
||||
|
||||
| Â
|
||||
| Backend Entwickler |
|
||||
|
|
||||
|
|
||||
|
||||
|
|
||||
|
||||
|
|
||||
|
||||
| Â
|
||||
| Backend Entwickler |
|
||||
|
|
||||
|
|
||||
|
||||
|
|
||||
|
||||
|
|
||||
|
||||
| Â
|
||||
| Frontend Entwickler | Juli 2024 | Frontends mit modernen Frameworks bauen
|
||||
UI Entwürfe kritisieren
|
||||
Stylesheets refaktorieren
|
||||
Leute über die Wichtigkeit von Barrierefreiheit aufklären
|
||||
| Hamm
|
||||
(Da wo der Zug getrennt wird)
|
||||
| Meine Familie
|
||||
Kraftsport
|
||||
Laufen
|
||||
Golf
|
||||
Kochen und Backen
|
||||
Auf Festivals raven gehen
|
||||
|
|
||||
|
||||
| Â
|
||||
| Frontend Entwickler | Q4 / 2024 | Fullstack Entwicklung
|
||||
Lösungen für Komplexe Themen erarbeiten
|
||||
Coole UIs bauen
|
||||
| Kaiserslautern
|
||||
| Reisen
|
||||
Festivals
|
||||
Game Development
|
||||
Irgendwas mit Microcontrollern bauenÂ
|
||||
|
|
||||
|
||||
| Â
|
||||
| Frontend Entwickler |
|
||||
|
|
||||
|
|
||||
|
||||
|
|
||||
|
|
||||
|
||||
| Â | QA | Q4 / 2024 | alles rund um QA
|
||||
| Kassel | Meine Familie
|
||||
Basketball
|
||||
Tauchen
|
||||
|
|
||||
|
||||
| Â
|
||||
| QA |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
Team HippocampusBild (freiwillig) | Name | Rolle | seit wann bei KuK | Kernkompetenzen | Homebase | Sonstiges (freiwillig) |
|
||||
|
||||
| Â
|
||||
| Product Owner | September 2023 | Logisches Denken und Hinterfragen
|
||||
10 Jahre Fahrplan-IT-Wissen
|
||||
| Frankfurt | Fitnessstudio (4x die Woche)
|
||||
Musical Verein (Musical Tomorrow)
|
||||
Radfahren (Gravel-Bike/Rennradtouren)
|
||||
Bonsai (Workshop zum anerkannten Bonsai-Gestalter)
|
||||
Altdeutsche Philatelie (mittlerweile auch als Business )
|
||||
Reisen
|
||||
Ski fahren
|
||||
Brettspiele / Hidden Identity Spiele
|
||||
|
|
||||
|
||||
| Â
|
||||
| Scrum Master | Januar 2025 |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| Â
|
||||
| BE | Ende 2023 | Ich bin Business Engineer mit Schwerpunkt auf Fahrplanerstellung und die zugehörige Systemlandschaft | Frankfurt | Nachteule
|
||||
Spiele Tischtennis, Badminton, Squash
|
||||
Sehe einen Sinn hinter dem was wir machen .
|
||||
|
|
||||
|
||||
| Â
|
||||
| Backend Entwickler |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| Â
|
||||
| Fullstack Entwickler |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| Â
|
||||
| Frontend Entwickler |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| Â
|
||||
| Frontend Entwickler | Mai 2025 | Full-Stack Entwicklung mit (Type|Java)script, Java, Python
|
||||
DevOps
|
||||
Docker
|
||||
| Dortmund |
|
||||
|
|
||||
|
||||
| Â
|
||||
| Backend Entwickler | Juli 2025 |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| Â
|
||||
| Backend Entwickler | Mai 2026 |
|
||||
| Köln |
|
||||
|
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# DB Planet/ Teams / IT-Produkt Idee
|
||||
|
||||
Version: 7 | Last modified: 2024-01-31T13:00:31.931+01:00
|
||||
Source: confluence page ID 306226898
|
||||
|
||||
---
|
||||
|
||||
https://db-planet.deutschebahn.com/pages/kapazitaetsstrategie-und-kapazitaetsplanung-k-k/apps/content/team-k-k
|
||||
TeamsTeambaumÂ
|
||||
|
||||
Konstruktionsvorbereitung
|
||||
Im Team Konstruktionsvorbereitung werden die Anmeldungen und Rückmeldungen der Fahrlagen unserer Kunden systematisiert. Dopplungen und ähnliche Anmeldungen werden identifiziert. Mehrungen und Minderungen gegenüber eines Vergleichsfahrplans werden dargestellt.
|
||||
Integrierte Prozesssteuerung
|
||||
Die integrierte Prozesssteuerung ist eine Anwendung, die - wie der Name sagt - den gesamten Prozess inkl. Abhängigkeiten darstellt. Der Nutzer kann auf unterschiedliche Systeme und Services mittels DeepLinks zugreifen, um möglichst einfach unterschiedliche Systeme und Tools zu erreichen. Des Weiteren werden Prozesskennzahlen bzw. Arbeitsstände der jeweiligen Prozessschritte dargestellt.
|
||||
Kapazitätsgrenzen und Bewertung
|
||||
Das Modul zeigt Abweichungen zwischen einem Fahrplanstand und Kapazitätsgrenzen dar. Kapazitätsgrenzen stellen sicher, dass ausreichend Kapazitäten für alle Verkehrsarten zur Verfügung stehen. Die Bewertungen von Fahrplankonzepten werden ebenfalls visualisiert.
|
||||
Netzproduktdarstellung
|
||||
Im Team Netzproduktdarstellung werden Fahrplankonzepte visuell aufbereitet und in einer modernen Weboberfläche zur Verfügung gestellt. Die Darstellung der Planungsergebnisse als Netzgrafik werden durch Such- und Gruppierungsfunktionen unterstützt.
|
||||
|
||||
IT-Produktehttps://db-planet.deutschebahn.com/pages/kapazitaetsstrategie-und-kapazitaetsplanung-k-k/apps/content/mvp-idee
|
||||
STRUKTUR DB Planet: IT-ProdukteÃbergeordnete Fähigkeitenkarte
|
||||
übergeordnete Zeitschiene
|
||||
Ausbaustufen je Produkt
|
||||
UI Entwürfe je Produkt
|
||||
INPUT: TeamslidesPrepToPath
|
||||
|
||||
CapaGuard
|
||||
|
||||
NetzLotse
|
||||
|
||||
InProHub
|
||||
|
||||
Eine integrierte Sicht auf den Gesamtprozess inkl. aller Produkte:
|
||||
1.Kapazitätsnutzungskonzepte (Leuchtturm-KNK und Jahres-KNK)
|
||||
2.Kapazitätsrahmenverträge (KRV)
|
||||
3.Kapazitätsnutzungsplan (KNP)
|
||||
Eingangstor für alle Nutzer:Â
|
||||
1.Zugangsberechtigte / EVU
|
||||
2.DB Netz / EIU
|
||||
Zentrale Absprungbasis für alle angebundenen IT-Module:Â
|
||||
1.Kundenanmeldungen
|
||||
2.Trassenkonstruktion
|
||||
3.Fahrplanbewertung
|
||||
4.Darstellung Fahrplankonzepte
|
||||
5.usw...
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
# DevOps Anforderungen im Team
|
||||
|
||||
Version: 4 | Last modified: 2025-08-25T13:59:47.059+02:00
|
||||
Source: confluence page ID 474095243
|
||||
|
||||
---
|
||||
|
||||
Rollen & VerantwortlichkeitenRolle | Beschreibung |
|
||||
AG (Auftraggeber) | Fachliche Anforderungen, Budget, Abnahme von Leistungen |
|
||||
ART-Trio | Kombination aus Release Train Engineer, Product Manager und System Architect im SAFe-Kontext |
|
||||
DevOps-Team | Entwicklung, Betrieb und Automatisierung (CI/CD, Monitoring, Deployments, Cloud-Ressourcen) |
|
||||
PM (Projektmanager) | Koordination des Projektes, Zeit- und Ressourcenplanung |
|
||||
PO (Product Owner) | Fachliche Priorisierung, Abstimmung mit Auftraggeber, Sicherstellung der Anforderungen |
|
||||
Release Train Architect | Verantwortlich für die übergreifende Architektur im gesamten Release Train, Schnittstelle zwischen Teams und Systemarchitekten |
|
||||
Scrum Master | Prozessbegleitung im agilen Vorgehen, Unterstützung bei Hindernissen |
|
||||
Security-Beauftragter (Team) | Vom Team ernannte Person, koordiniert Sicherheitsthemen, führt regelmäÃige Security-Checks durch und arbeitet eng mit dem System Architect zusammen |
|
||||
Systemarchitekt | Verantwortlich für die Systemarchitektur, Schutzbedarfsfeststellung, Netzwerksegmentierung; Zusammenarbeit mit Security-Beauftragtem bei Sicherheitsfragen |
|
||||
Checkliste / Self-AssessmentBereich | Anforderung | Status | ToDo / Nächste Schritte | Verantwortlich |
|
||||
1. Verantwortlichkeiten und Rollen | Sind alle relevanten Rollen (Betreiber, AG = Auftraggeber, IT-Asset-Owner, PO, Remediation Manager) klar benannt und dokumentiert? | 🔴 Offen | Rollenliste erstellen und in Confluence dokumentieren. Remediation Manager = alle Mitgleider des DevOps Team (auÃer Asset-Owner)? SIT Team â CNP | PO |
|
||||
|
||||
| Ist geregelt, welche Verantwortlichkeiten im Team, beim AG und bei Dienstleistern liegen? | 🟡 In Arbeit | Team (DevOps-Team): Codeentwicklung, CI/CD-Betrieb, Monitoring, Deployments (via CNP/ArgoCD) â Welche Entscheidungen/Freihaben haben wir bezüglich technischer Anforderungen
|
||||
AG (im SAFe-Kontext: ART-Trio = PM, RTE, System Architect): Fachliche Anforderungen (PM), Budgetfreigaben (RTE), technische Anforderungen/Unterstützungen (System Architect)
|
||||
Dienstleister: Betrieb der Cloud Native Platform (SIT Team) inkl. ArgoCD-Basisbetrieb und AWS-Infrastruktur
|
||||
| Team |
|
||||
2. Datenschutz | Liegt eine aktuelle Abstimmung mit dem AG für die Verarbeitung personenbezogener Daten vor? | 🔴 Offen | Rücksprache mit AG & Datenschutzbeauftragtem, ob aktuelle Freigabe vorliegt | Team / Datenschutzbeauftragter |
|
||||
|
||||
| Gibt es Prozesse zum schnellen Umsetzen der Betroffenenrechte (Löschung, Auskunft, Berichtigung)? | 🔴 Offen | Prüfen, ob personenbezogene Daten verarbeitet werden; falls ja: Prozess definieren und abstimmen | Team / Datenschutzbeauftragter |
|
||||
|
||||
| Werden personenbezogene Daten ausschlieÃlich verschlüsselt gespeichert und übertragen? | 🟢 Erledigt | Dokumentation der eingesetzten Verschlüsselung (AWS + DocumentDB, TLS in Transit, Encryption at Rest) ergänzen | Team / CNP |
|
||||
|
||||
| Sind alle Test- und Schulungssysteme frei von echten personenbezogenen Daten? | 🔴 Offen | Prüfen, ob in Test-/Schulungssystemen echte Namen/IDs vorkommen; falls ja: Anonymisierung/Pseudonymisierung umsetzen | Team / Datenschutzbeauftragter |
|
||||
|
||||
| Existieren dokumentierte technische und organisatorische MaÃnahmen (TOM)? | 🟢 Erledigt | TOM-Dokumentation jährlich prüfen und aktualisieren | Team / Datenschutzbeauftragter |
|
||||
|
||||
| Gibt es ein Verfahren zur sofortigen Meldung von Datenschutzvorfällen? | 🔴 Offen | Zuständige Datenschutzbeauftragte identifizieren und Ablaufplan dokumentieren | ART-Trio / Datenschutzstelle |
|
||||
|
||||
| Ist festgehalten, wie personenbezogene Daten in Logs, Fehlerbeschreibungen oder beim Einsatz von Dienstleistern behandelt werden? | 🟢 Erledigt | Links zu relevanten Richtlinien im Confluence-Bereich hinterlegen | Team |
|
||||
3. IT-Sicherheit | Wie ist das Team über aktuelle Schwachstellen, Patchstände und verfügbare Scans/Pentests informiert? | 🟢 Erledigt | Dokumentation der eingesetzten Security-Checks in Confluence aktuell halten | Team |
|
||||
|
||||
| Gibt es regelmäÃige Security-Checks (Scans, Pentests, Compliance-Check/CSA)? | 🟡 In Arbeit | Prüfen, ob ergänzende periodische Tests notwendig sind | Team / Systemarchitekt |
|
||||
|
||||
| Werden technische Benutzerkonten nach Genehmigung und nach dem Minimalprinzip genutzt? | 🟢 Erledigt | Aktuelle Rollen- und Berechtigungsliste im Confluence hinterlegen | Team |
|
||||
|
||||
| Sind gesicherte Admin-Zugänge und Multi-Faktor-Authentifizierung (wo notwendig) umgesetzt? | 🟢 Erledigt | RegelmäÃige Ãberprüfung der Zugriffsrechte auf Secrets & KeyPass-Einträge | Team |
|
||||
|
||||
| Existiert ein vollständiger Wiederherstellungsplan (Business-Continuity)? | 🟢 Erledigt | Plan jährlich überprüfen und mit aktuellen Plattform-Ãnderungen abgleichen | Team |
|
||||
|
||||
| Ist eine Trennung zwischen Entwicklungs-, Test- und Produktionsumgebung implementiert? | 🟢 Erledigt | Sicherstellen, dass keine produktiven Daten in nicht-prod-Umgebungen genutzt werden | Team |
|
||||
4. Prozesse & Betriebsmanagement | Sind alle Service-, Change-, Incident- und Problem-Management-Prozesse bekannt und dokumentiert? | 🔴 Offen | Links zu den aktuellen Prozessdokus im Team hinterlegen | Team |
|
||||
|
||||
| Werden Operations-Dokumentationen (Runbooks, Incident-Anleitungen) gepflegt? | 🟡 In Arbeit | Review aller Runbooks; fehlende Szenarien ergänzen | Team |
|
||||
|
||||
| Sind SLAs mit AG und Dienstleistern regelmäÃig überprüft und dokumentiert? | 🔴 Offen | Mit AG/Dienstleistern abstimmen, ob SLAs existieren und wie die Einhaltung dokumentiert wird | AG / ART-Trio |
|
||||
|
||||
| Existiert ein Konfigurationsmanagement und ist jede Ãnderung nachvollziehbar? | 🟢 Erledigt | Sicherstellen, dass Doku zu Helm-/ArgoCD-Prozessen aktuell ist | Team |
|
||||
|
||||
| Werden regelmäÃig Konten und Berechtigungen überprüft? | 🟡 In Arbeit | Quartalsweise Access Review etablieren | Team / Scrum Master |
|
||||
5. Cloud & Architektur | Ist der Schutzbedarf und die Netzwerksegmentierung dokumentiert? | 🟢 Erledigt | Jährliche Ãberprüfung/Aktualisierung der Doku | Team / Systemarchitekt |
|
||||
|
||||
| Erfolgt die Verschlüsselung (auch BYOK) und Schlüsselrotation aktiv? | 🟡 In Arbeit | Option für automatische Rotation evaluieren | Team |
|
||||
|
||||
| Ist festgelegt, wie Zugriffsrechte und Vertrauensstellungen zu externen Partnern geregelt sind? | 🟢 Erledigt | Falls externe Partner dazukommen: formale Regelung ergänzen | Team + beteiligte Teams |
|
||||
|
||||
| Sind die Cloud-spezifischen Vorgaben (Trennung Prod/Dev/IAT, Einschränkung technischer Benutzer) umgesetzt? | 🟢 Erledigt | Quartalsweises Berechtigungs-Review pro Environment | Team |
|
||||
6. Kontrolle & Verbesserung | Werden Compliance-Checks/CSAs regelmäÃig durchgeführt? | 🔴 Offen | Klären, ob durch ART-Trio/Systemarchitekt durchgeführt wird | Systemarchitekt / ART-Trio |
|
||||
|
||||
| Gibt es dokumentierte MaÃnahmen zu gefundenen Schwachstellen und Risiken? | 🟢 Erledigt | Schulung im Team zur Nutzung der Schwachstellenmanagement-Seite | Team |
|
||||
|
||||
| Wird die eigene Prozess- und Dokumentationsqualität überprüft und kontinuierlich verbessert? | 🟢 Erledigt | Lessons Learned aus Retros auch in Prozess-/Dokumentationsänderungen einflieÃen lassen | Team / Scrum Master |
|
||||
7. Betriebsrat & Organisation | Sind alle Vorgaben der GBVen eingehalten (z. B. Rufbereitschaft, Arbeiten auÃerhalb Regelarbeitszeit, Dokumentationspflichten)? | 🔴 Offen | Mit Betriebsrat oder HR abstimmen, ob Vorgaben erfüllt sind |
|
||||
|
|
||||
|
||||
| Sind Beteiligungspflichten und die Kommunikation an den Betriebsrat berücksichtigt? | 🟡 In Arbeit | Bestätigung durch ART-Trio einholen und Informationsfluss ins Team sicherstellen | ART-Trio |
|
||||
+162
@@ -0,0 +1,162 @@
|
||||
# Fokusthema: Umgebungsmanagement (Team 1)
|
||||
|
||||
Version: 20 | Last modified: 2025-08-22T10:49:23.649+02:00
|
||||
Source: confluence page ID 449094070
|
||||
|
||||
---
|
||||
|
||||
Ziele / AgendaAusgangssituationBegriffe
|
||||
Umgebungen & Umgebungsmanagement pro stagewelche mocks, welche tests, aws services, umgebung pro Qualitätsstufe, stehende umgebung oder wegwerf umgebung, artifactory, datenqualität
|
||||
|
||||
Tests
|
||||
Was sagt C2S-Plattform und TTT
|
||||
|
||||
Aktuelle Probleme
|
||||
Was sind unsere Erwartungen an ein Zielbild
|
||||
Zielbild mit Orientierung an C2S-Plattform und TTT
|
||||
AppendixWarum mocken wir
|
||||
|
||||
Ausgangssituation
|
||||
|
||||
Begriffe (orientierung an Zielbild TTT)
|
||||
Begriff | Erklärung |
|
||||
Preprd
|
||||
| dev, iat, abn |
|
||||
Prod | prod |
|
||||
Quality Coach | Ziel: pro team teamübergreifende Anforderungen aus Sicht des Testings steuern
|
||||
aktuell nicht bekannt
|
||||
|
|
||||
Systemtest / Systemintergrationstest
|
||||
| Durchlauf (happy-path) von einem Camunda "Gesamt"-Workflow (z.B. KNK_gesamt)
|
||||
Mock von ART-Fremdsystemenverwendung von mocks nach neuer Definition sieheÂ
|
||||
verwendung keiner mocks nach bisheriger definition siehe Testarchitektur
|
||||
|
||||
Werkzeuge: Thunderclient (,Manuelle Usertasks)
|
||||
|
|
||||
Integrationstest
|
||||
| Integrationstests evaluieren, wie verschiedene Komponenten miteinander interagieren. Ziel ist es, sicherzustellen, dass die Schnittstellen korrekt funktionieren und dass die Integration der Module reibungslos verläuft.
|
||||
|
||||
Werkzeuge: Thunderclient, Robotframework
|
||||
|
|
||||
Geschäftsprozesstest
|
||||
| Haben wir das überhaupt oder ist das nicht unter Systemtest zu finden?
|
||||
definiert hier https://kuk.gitpages.tech.rz.db.de/doc/architektur/07-test/01-test-concept.html
|
||||
|
|
||||
E2E-Tests (=realisiert durch Geschäftsprozesstests z.B. auf kut)
|
||||
| Haben wir das überhaupt oder ist das nicht unter Systemtest zu finden?
|
||||
Unterschied zu Geschäftsprozess tests: Es wird auf Datenkorrektheit geprüft (z.B. Prüfen Perlschnur zu Produktionsauftrat)
|
||||
|
|
||||
Account/Mandant/Tenant
|
||||
| CNP-Mandant (z.B. kuk-dev) siehe https://kuk.gitpages.tech.rz.db.de/doc/architektur/02-arc42/07-deployment-view.html
|
||||
|
|
||||
Stage | Qualitätsstufe im Entwicklungsprozess: dev, test, abn, prod (oder nur preprd und prod)
|
||||
|
|
||||
Umgebung/Environment | läuffähigen Softwareverbund mit einem Zweck/Tag
|
||||
Aktuell haben wir immer exakt 1 Umgebung für 1 Stage
|
||||
|
|
||||
Cluster | Technische Laufzeitumgebung mit einem Rechnerpool für mehrere Umgebungen (einer stage)
|
||||
|
|
||||
Service | WebApplikation (kein einmaliger cron-job)
|
||||
|
|
||||
Release | fachliches Release:
|
||||
technisches Release:
|
||||
prozess:Â
|
||||
|
|
||||
Deployment |
|
||||
|
|
||||
|
||||
welche mocks, welche tests, aws services, umgebung pro Qualitätsstufe, stehende umgebung oder wegwerf umgebung, artifactory, datenqualität
|
||||
|
||||
probleme:
|
||||
Unsicherheit bezüglich der Umgebung
|
||||
Unsicherheit bezüglich konkret der dev Umgebung gerade richtung abn
|
||||
Wollen wir mehr umgebung haben
|
||||
wo machen wir lup und systemtest
|
||||
art-fremde apps mocken
|
||||
camunda mocken2 sichteninprohub will gesamtprozess testen
|
||||
andere apps wollen teilprozess testen
|
||||
|
||||
prozessmocks
|
||||
umgebung = namespace â nein
|
||||
umgebung = controlplane oder umgebung = namespace + eigener nodepool (falls notwendig) (korrektes setzen von affinities, taints, tolerations notwendig)
|
||||
stage = cnp tenant
|
||||
service kommunikation nur zwischen services auf einer envservices verknüpfen mit anderen services auf anderen env's wegen verschiedener datenqualitätart-intern: motivation: von dev auf iat da bessere datenqualität Gegenargument: eher daran arbeiten datenqualität auch auf z.B. dev zu erhöhen, könnte evt. zu verwirrung im art führen
|
||||
art-extern: kontrolle nicht bei uns
|
||||
|
||||
schauen das dev auch anspruch das stabil ist (nicht perma down)
|
||||
mocks vs proxiesproxies > mocks für simulation (z.B. von schnittstellen)z.B. Ordnungsrahmen api, kapaguard wenn ids nicht da,
|
||||
|
||||
Infrastruktur (aws services)entwicklungsgrad: aws service durch localstack ersetzen
|
||||
kosteneffizient: weniger ressourcen pro z.B. ec2, spot instances > normale instancen (muss nicht bei jedem service )
|
||||
Produktionsgrad:
|
||||
|
||||
lup art-übergreifend > lup art-intern bezüglich der abhängigkeiten
|
||||
diskussion lup bleibt offen
|
||||
camunda prozess mockenmotivation: teilprozess pro app durchlaufen
|
||||
überbrücken der zeit bis wir systemtest haben
|
||||
alle in camunda dev tenant rein deployen
|
||||
wer hat usecase: unterprozess mocken
|
||||
aktuell:2 camunda instances: dev,abndev: 1 tenant pro appmotivation/vorteil: verschiedene prozesse mocken pro app, jedes produkt hat umgebung um seine prozesse zu testen (und andere zu mocken)prozesstests
|
||||
|
||||
nachteil: ist eigentlich komponententest auf einer EU (nicht IEU)
|
||||
|
||||
abn: 1 tenant iat, abn, prod
|
||||
|
||||
zielbildalternativenweiterhin auf dev tenant pro app
|
||||
nur 1 tenant (kuk-dev)
|
||||
1 tenant für inprohub und 1 tenant für alle anderen
|
||||
|
||||
frage: ist dev eine EU oder IEUEU hab ich ja schon lokal
|
||||
|
||||
Systemtest definieren
|
||||
Integrationstest
|
||||
|
||||
https://kuk.gitpages.tech.rz.db.de/doc/architektur/04-runbook/02-architecture-overview.html
|
||||
|
||||
Aktuelles (Zielbild) Umgebungsmanagement
|
||||
|
||||
Grobteinteilung | preprod | prod |
|
||||
Qualitätsstufe | dev | test | abn | prod |
|
||||
Stage
|
||||
| dev | iat | abn | prod |
|
||||
Umgebung
|
||||
| kuk-dev | kuk-iat | kuk-abn | kuk-prod |
|
||||
Up-Time
|
||||
| 6:00-20:00 | 8:00-20:00 | 8:00-20:00 | durchgängig |
|
||||
SLA
|
||||
| - | - | - | Bronze |
|
||||
KuK Verfahrenscluster | kuk-dev | kuk-iat | kuk-abn | kuk-prod |
|
||||
CNP Cluster | cnp-iat | cnp-iat | cnp-iat | cnp-prod |
|
||||
Camunda Cluster/Instance/Umgebung | cluster-c2s-kuk-dev | cluster-c2s-kuk-dev | cluster-c2s-kuk-abn | cluster-c2s-kuk-abn |
|
||||
Camunda Mandant ID | dev, dev-capaguard, dev-fps,
|
||||
dev-ids, dev-iph, dev-netzlotse-dev-tas
|
||||
| iat | abn | prod |
|
||||
Camunda Modeler | ja
|
||||
| ja | nein | nein |
|
||||
Reifegrad Infrastruktur | Kosteneffizient | Kosteneffizient | Produktionsgrad | Produktionsgrad |
|
||||
Datenbestand | Testdaten | Testdaten | (anonymisierte) prod-daten | prod-daten |
|
||||
Tests | Unit-test | Integrationstests, Systemtests | LuP-Test (ggf. art-übergreifend),
|
||||
E2E/KTU-Tests, Smoke-Tests
|
||||
| Smoke-Tests |
|
||||
Monitoring/Logging | Logging, Monitoring, Alerting
|
||||
| Logging, Monitoring, Alerting | Logging, Monitoring, Alerting | Logging, Monitoring, Alerting |
|
||||
Konnektivität | keine mocks
|
||||
Ausnahmen: BEP, FAPS
|
||||
Proxies?
|
||||
| keine mocks
|
||||
Ausnahme: BEP, FAPS
|
||||
Proxies?
|
||||
| keine mocks | keine mocks |
|
||||
Zielumgebung zur Konnektivität
|
||||
ART-interner Services
|
||||
| kuk-dev
|
||||
| kuk-iat
|
||||
| kuk-abn | kuk-prod |
|
||||
Zielumgebung zur Konnektivität
|
||||
ART-externer Services
|
||||
| kuk-abn
|
||||
| kuk-abn
|
||||
| kuk-abn | kuk-prod |
|
||||
Artifactory Techuser | iat | iat | iat | prod |
|
||||
Artifactory Repository Anbindung | stage | stage | prod | prod |
|
||||
Lebenszyklus Umgebung | stehend | stehend | stehend | stehend |
|
||||
@@ -0,0 +1,16 @@
|
||||
# Onboarding Team Cortex
|
||||
|
||||
Version: 5 | Last modified: 2025-06-27T08:10:47.070+02:00
|
||||
Source: confluence page ID 457675862
|
||||
|
||||
---
|
||||
|
||||
Allgemeines Onboarding im ART:Â On-/Offboarding neuer Mitarbeiter
|
||||
Einige der Inhalte sind veraltet. Deshalb korrigiert bitte in Absprache mit Julius (fachliche Inhalte), dem Team (technische Inhalte) und den Architekten Florian Thom und Stefan SchmeiÃer (übergreifende architektonische Inhalte) die veralteten Inhalte direkt in den Confluence-Seiten.
|
||||
|
||||
Team Sprint Board: https://arija.jaas.service.deutschebahn.com/secure/RapidBoard.jspa?projectKey=KUKT3&rapidView=1375
|
||||
Cortex Abwesenheitskalender und Team Space:Â
|
||||
Entwicklungshandbuch ART-Weit:Â https://kuk.gitpages.tech.rz.db.de/doc/entwicklungshandbuch/
|
||||
Lokale Entwicklungsfähigkeit herstellen für
|
||||
Prep2Plan-Frontend https://git.tech.rz.db.de/kuk/app/prep2plan/prep2plan-frontend
|
||||
Fahlragen-Persistence-Service https://git.tech.rz.db.de/kuk/app/fahrlagen-integration/fahrlagen-persistence-service
|
||||
+132
@@ -0,0 +1,132 @@
|
||||
# Onboarding Team Hippocampus
|
||||
|
||||
Version: 10 | Last modified: 2024-10-10T10:17:42.670+02:00
|
||||
Source: confluence page ID 324801344
|
||||
|
||||
---
|
||||
|
||||
Auf dieser Seite wird ein kleines Onboarding Paket zur Verfügung gestellt, das Themen abdeckt, die besonders relevant für das Team Hippocampus und den CapaGuard sind.
|
||||
|
||||
Der CapaGuard ist für die verschiedenen Umgebungen zu erreichen unter:
|
||||
Entwicklungsumgebung (dev):
|
||||
https://kapaguard-frontend-kuk-dev.cnp-test.comp.db.de/home
|
||||
Testumgebung (iat):
|
||||
https://kapaguard-frontend-kuk-iat.cnp-test.comp.db.de/home
|
||||
Abnahmeumgebung (abn):
|
||||
https://kapaguard-frontend-kuk-abn.cnp-test.comp.db.de/home
|
||||
Ãber die Master-App:
|
||||
https://kuk-frontend.kuk-dev.cnp-test.comp.db.de/kapaguard/home
|
||||
https://kuk-frontend.kuk-iat.cnp-test.comp.db.de/kapaguard/home
|
||||
Fachliche Grundlagen
|
||||
|
||||
Einstieg
|
||||
Ãbersicht Produkte und fachlicher Kontext Art K&K
|
||||
Folienmaster Art K&K
|
||||
|
||||
Es empfiehlt sich zunächst folgende Inhalte aus dem Infopaket des ART K&K zu lesen:
|
||||
Link zum Infopaket K&K
|
||||
Unter 02 - Fachlich:
|
||||
Einstieg ART K&K
|
||||
Produkte ART K&KÂ
|
||||
Unter 04 - Informationen zu Projekten und Regularien
|
||||
Kapazitätsplanung und âZuweisung der Zukunft (KaZu-Novum)Es lohnt auch ein Blick in die Finanzierungsvereinbarung mit dem Bund zu KaZu Novum: FinVe-Ziele KaZu Novum
|
||||
Besonders relevant für das Team Hippocampus:[KNK] 1b: Ermittlung und Abgleich Ober und Untergrenze D-Takt und Sockelangebot
|
||||
[KNK] 2b: Kennzahlenbasierte Konstruktionsbewertung: verkehrlich, kapazitativ und qualitativ
|
||||
[KNK] 3a: IT unterstützte Kapazitätsauswahl im Konfliktfall
|
||||
[KNK] 3b: Kennzeichnung bei Ãbersteuerung des Sockelangebots
|
||||
[KRV] 1a: Kapabänder aus KNK inkl. Abgleich KRV-Bestellung zum Kapa-Band
|
||||
[KRV] 2a: IT-gestützte Prüfung der KRV-Bestellung auf KNK-Konformität und optimale Kapazitätsnutzung
|
||||
[KNP] 1b: Abgleich mit Sockelkapazitäten
|
||||
|
||||
mittelfristiges Konzept für eine optimierte Kapazitätsnutzung (mKoK)Insbesondere ein Blick auf den Prozess mKoK 26 lohnt (entspricht dem Ist-Zustand) - Link zum Prozess mKoK 26
|
||||
Für einen Ãberblick: Konzeption des mKoK 26 - Link zum Foliensatz im Sharepoint
|
||||
Interessante Slides für den CapaGuard:Grobprozesse 19-22 (Use Case Sockelangebot, hier unterstützt perspektivisch der CapaGuard)
|
||||
Bestand & Mehrung 55-61 (Sockelangebot + Mehrung)Â
|
||||
Abgleich Sockelangebot 101-104 (Grobe Beschreibung des bisherigen Vorgehens für den Abgleich)
|
||||
Ãbersicht IT Systeme für Konstruktion aktuell 121 (Idee für 2028, nur noch Viriato)
|
||||
|
||||
Entwicklungshandbuch
|
||||
Installationsanweisungen, Best Practices und alle weiteren Informationen zur Entwicklung im ART K&K
|
||||
Entwicklungshandbuch ART K&K
|
||||
|
||||
Architekturübersicht
|
||||
Ãbersicht über die einzelnen IT-Systeme und Services des ART K&K, inkl. Systemkontext (je PI aktualisiert)Â
|
||||
Ãbersicht IT-Systeme und Services ART K&K (Architekturhandbuch)
|
||||
|
||||
Informationen zum CapaGuard MVP Ein grober Ãberblick über die Fachlichkeit des CapaGuard und den Entwicklungsstand ist in folgendem Foliensatz gegeben
|
||||
CapaGuard Onboarding Ãberblick
|
||||
Für die Entwicklung des CapaGuard verwenden wir Git und GitLab, man findet den CapaGuard unter
|
||||
https://git.tech.rz.db.de/kuk/app/kapaguard
|
||||
HandbuchEine Ãbersicht über aktuelle Funktionalitäten des CapaGuard, inkl. fachlichem Kontext/fachlichen Anwendungsfällen ist im Handbuch der Anwendung zu finden
|
||||
CapaGuard Handbuch
|
||||
SockelangebotEin weiterer zentraler Input für den CapaGuard ist das Sockelangebot, das aus einem anderen IT System (Netzmonitor) exportiert und im CapaGuard importiert wird.
|
||||
Ãberblick Sockelangebot aus dem CapaGuard Handbuch
|
||||
CapaGuard Handbuch Sockelangebot
|
||||
Eine ausführliche Beschreibung des Sockelangebotes ist zu finden unterÂ
|
||||
CapaGuard Git-Doku Sockelangebot
|
||||
Das Sockelangebot ist dabei auch zentral für die Definition der Objekte Kapazitätsabschnitte
|
||||
CapaGuard Handbuch Kapazitätsabschnitte
|
||||
|
||||
Einige Informationen zum Netzmonitor finden sich auf folgender Confluence SeiteÂ
|
||||
Confluence-Seite zum Netzmonitor
|
||||
oder auch auf der DB-Planet Seite des Netzmonitor
|
||||
Db-Planet Netzmonitor
|
||||
Konstruktionsstand - mKoK 2026Exemplarisch für den SPFV - wie sieht der mKoK 2026 (synthetisches 2h Fenster) in der Form einer Netzgrafik aus
|
||||
mKoK 26 Netzgrafiken (Pdf Download)
|
||||
Kundeninformationen zum mKoK 2026
|
||||
Unterlage mKoK 2026 Kundeninformation
|
||||
Wie wird der Konstruktionsstand im CapaGuard verwendet
|
||||
CapaGuard Handbuch Konstruktionsstand
|
||||
Datengrundlage für den Konstruktionsstand mKoK 2026 im CapaGuard ist zur Zeit eine .railml aus einem Viriato Export (für mehr Informationen siehe unten)Â
|
||||
Deutschland-Takt (D-Takt)Die Verkehrsmengen des Deutschlandtaktes stellen eine weitere, für den CapaGuard relevante Kennzahl dar.
|
||||
Die Verkehrsmengen des D-Takt liegen in der Form einer .railml (aus Viriato, siehe unten) vor.Â
|
||||
Erläuterungen zum D-Takt und zum Format railml:
|
||||
CapaGuard Git-Doku Deutschlandtakt
|
||||
Vertiefung (sehr ausführlich):
|
||||
Abschlussbericht D-TaktÂ
|
||||
Infrastruktur und Geokoordinatenâ Im Zielbild erhält der CapaGuard die Infrastruktur für ein Zielfahrplanjahr aus einer Schnittstelle zum Infrastrukturmanager (IM)Â
|
||||
Der Infrastrukturmanager wird durch den ART IDBF entwickelt, einige Informationen finden sich unter
|
||||
DB-Planet ART IDBF
|
||||
Eine Schnittstelle zum CapaGuard stellt die sogenannte "Ordnungsrahmen-API" dar, die einen Export von makroskopischer Infrastruktur auf der Ebene Betriebsstellen und Streckenabschnitte erlaubt
|
||||
Ordnungsrahmen API im API-PortalÂ
|
||||
Eine detaillierte Beschreibung der Ordnungsrahmen-API findet sich unter
|
||||
CapaGuard Git-Doku OR-API
|
||||
Vertiefung (sehr ausführlich): Dokumentation des Infrastrukturmanagers (IDBF)
|
||||
https://infrastruktur-manager.gitpages.tech.rz.db.de/doku/Runbook/01-system-profile.html
|
||||
Geokoordinaten erhält der CapaGuard zum einen über STREDA.X sowie aus weiteren Quellen/manueller Bearbeitung.Â
|
||||
Für eine grobe Beschreibung siehe
|
||||
CapaGuard Git-Doku Geokoordinaten
|
||||
|
||||
Testing, UI/UX und Release im ART K&KUI/UX Entscheidungen/Vorgaben für den ART K&K sind zu finden unter
|
||||
Confluence-Seite UI Konzept ART K&K
|
||||
DB konforme Icons können u.a. hier gefunden werdenÂ
|
||||
https://db-ui.github.io/core/review/507-provide-dark-mode/?p=viewall-base-icons
|
||||
|
||||
Informationen und Guidelines zum Testing sind im Architekturhandbuch zu finden
|
||||
Architekturhandbuch: Testing Guidelines
|
||||
Aktuell Probleme werden in der Test-CoP besprochen und die Themen hier gesammelt
|
||||
Themen des Test CoPs (Unterseiten)
|
||||
Unit-Tests sind für die jeweiligen Komponenten geschrieben.
|
||||
Automatsierte End-to-End Tests im Robotframework sind zu finden unter
|
||||
KuK-Git CapaGurad Robot-Tests
|
||||
|
||||
Die IT-Systeme im Art K&K sind noch nicht produktiv, aber der Releaseprozess wird bereits verprobt.Â
|
||||
Der Prozess ist hier abgebildet
|
||||
Releaseprozess ART K&K
|
||||
|
||||
Vertiefung (optional bzw. bei Interesse)ArcsAusgangspunkt für die Konzeption eines MVPs sind die Arcs aus der Bautaktkonzeption (HaKo)Â
|
||||
Zentrale Begriffe der Bautaktkonzeption sind auf folgender DB-Planet Seite erklärt
|
||||
Db-Planet Bautaktwiki
|
||||
Eine detaillierte Erklärung zur Erstellung und Verwendung der Arcs findet sich auf folgender Seite
|
||||
Confluence-Seite Arcs
|
||||
ViriatoInformationen zum Konstruktionssystem Viriato für den mKoK 2028 (relevant für das CapaGuard MVP)Â
|
||||
Broschüre Viriato
|
||||
Informationen zum Output Dateiformat .railml findet man unterÂ
|
||||
Handbuch Viriato SST
|
||||
Neues Konstruktionssystemâ Im Zielbild soll die Konstruktion der Fahrpläne des Projektes KaZu Novum mit einem neuen (mikroskopischen) Konstruktionssystem erfolgen
|
||||
â Der CapaGuard stellt dann einen Service für den Abgleich des Konstruktionsstandes mit de Sockelangebot bereit und muss dazu voraussichtlich auf das Backend des neuen Konstruktionssystems zugreifen
|
||||
Das neue Konstruktionssystem wird durch den ART EKON realisiert, einige Informationen findet man auf
|
||||
DB-Planet ART EKON
|
||||
Weitere Anforderungen/UseCases des CapaGuardÃbersicht der UseCases -Â Ãbersicht CapaGuard UseCases
|
||||
UseCase für KRVFoliensätze aus Absprache mit dem KRV: Foliensatz Termin 2 - Austausch KRV , Foliensatz Termin 1 - Austausch KRV
|
||||
Konzept der Messpunkte und Kapa-Bänder: Confluence-Seite Kapazitätsbänder
|
||||
@@ -0,0 +1,44 @@
|
||||
# Onboarding Team IRIS
|
||||
|
||||
Version: 3 | Last modified: 2026-01-16T15:16:22.076+01:00
|
||||
Source: confluence page ID 528179195
|
||||
|
||||
---
|
||||
|
||||
Auf dieser Confluence Seite finden sich alle teamspezifischen Onboarding-Materialien für den Start bei Team IRIS.
|
||||
|
||||
Als genereller Startpunkt im ART K&K gibt es eine Orientierungsliste unterÂ
|
||||
https://arija-confluence.jaas.service.deutschebahn.com/x/FwwjEQ
|
||||
auf der auch alle wichtigen Zugänge (Git, Sharepoint, Confluence, AriJa etc.) gelistet sind.Â
|
||||
|
||||
Unter https://arija-confluence.jaas.service.deutschebahn.com/x/Wa5hEÂ findet sich auch ein Infopaket mit einer Ãbersicht des Business Case des ART K&K und den Anwendungen.Â
|
||||
Für einen allgemeinen Ãberblick über die Onboarding Materialien des ART K&K bitte zunächst die Abschnitte
|
||||
01 Organisatorisch
|
||||
02 Fachlich
|
||||
03 Methodisch (falls nicht bekannt)Â
|
||||
sichten.Â
|
||||
|
||||
Für den Start als Entwickler ist das Entwicklerhandbuch zentral, in welchem der TechStack und alle notwendigen Zugänge beschrieben sind
|
||||
https://kuk.gitpages.tech.rz.db.de/doc/entwicklungshandbuch/00-entwicklungshandbuch.html
|
||||
|
||||
Für den fachlichen Einstieg im Team IRIS empfiehlt es sich insbesondere folgende Abschnitte im Anwendungshandbuch Prep2Plan zu lesen:
|
||||
Trassenaggregationsservice - https://kuk.gitpages.tech.rz.db.de/app/prep2plan/prep2plan-benutzerhandbuch/01-overview/05-trassenaggregationsservice.html
|
||||
Netzlotse Service - https://kuk.gitpages.tech.rz.db.de/app/prep2plan/prep2plan-benutzerhandbuch/01-overview/06-netzlotseservice.html
|
||||
Verkehrsmengenzählung im TAS - https://kuk.gitpages.tech.rz.db.de/app/prep2plan/prep2plan-benutzerhandbuch/01-overview/07-Logik_Verkehrsartenmengen.html
|
||||
Konstruktionsergebnis in Prep2Plan (inkl. der Unterseiten) - https://kuk.gitpages.tech.rz.db.de/app/prep2plan/prep2plan-benutzerhandbuch/04-trassentaktliste/00-overview.html
|
||||
|
||||
Eine sehr nützliche Ãbersichtsseite mit Links zu Handbüchern, den Anwendungen und den Prozessen im ART K&K ist die Index-Seite
|
||||
https://kuk.gitpages.tech.rz.db.de/index/Â
|
||||
|
||||
Die jeweiligen Services die im Team IRIS betreut werden sind hier im GIT zu finden:
|
||||
Service Trassenaggregationsservice (TAS) - https://git.tech.rz.db.de/kuk/app/tas
|
||||
Service Netzlotse - https://git.tech.rz.db.de/kuk/app/netzlotse/netzlotse-backendÂ
|
||||
Service Netzlotse Layout Prozessor - https://git.tech.rz.db.de/kuk/app/netzlotse/netzgrafik-layout-processor
|
||||
UI Lib Netzgrafik - https://git.tech.rz.db.de/kuk/lib/frontend/kuk-ui-libraryÂ
|
||||
Pipeline Templates - https://git.tech.rz.db.de/kuk/pip/pipeline-templatesÂ
|
||||
Zentrale APIs der Services - https://git.tech.rz.db.de/kuk/app/apis
|
||||
Testdaten - Â https://git.tech.rz.db.de/kuk/pip/kuk-mock-dataÂ
|
||||
|
||||
AriJa (DB Version von Jira)
|
||||
Team IRIS Board - https://arija.jaas.service.deutschebahn.com/secure/RapidBoard.jspa?rapidView=1426&projectKey=KUKIRIS
|
||||
Team IRIS Agile Hive mit der Ãbersicht über das PI - https://arija.jaas.service.deutschebahn.com/projects/KUKIRIS?selectedItem=net.seibertmedia.agilehive.agile-hive-plugin:breakout-board
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
# Schätzlogik Team Thalamus
|
||||
|
||||
Version: 8 | Last modified: 2025-06-23T11:39:26.454+02:00
|
||||
Source: confluence page ID 391268722
|
||||
|
||||
---
|
||||
|
||||
Wir schätzen Storys idealerweise relativ zueinander
|
||||
Wir orientieren uns dabei an vier Kriterien
|
||||
|
||||
Volumen:
|
||||
Wie viel Aufwand steckt in der Story? â mehr Aufwand, mehr Story Points
|
||||
Wie viel Testaufwand steckt in der Story? â mehr Testfälle, mehr Story Points
|
||||
Kompliziertheit:
|
||||
Wie viele Bereiche sind mitverantwortlich? (FE, BE, T, BA) â ab zwei hat die Story mindst. 2 Punkte
|
||||
Wie viele Abhängigkeiten haben wir? (SST, andere Teams)
|
||||
Wie viele Komponenten sind betroffen?
|
||||
Unsicherheit
|
||||
Gibt es groÃe Unklarheiten? â dann mindst. 5 Story Points
|
||||
Wissen - AusreiÃerpotential â mindst. 5 Story Points
|
||||
Sind wir in "Camunda-Neuland" unterwegs?
|
||||
haben wir groÃe teamübergreifende Abstimmungen?
|
||||
Kennen wir die Lösung nicht wirklich und müssen erstmal ausprobieren?
|
||||
|
||||
Storyvergleich aktuelles PI
|
||||
|
||||
1 | 2 | 3 | 5 | 8 | 13 |
|
||||
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,status,resolutionkey,summary,type,status,resolution20project = "24003" AND "Program Increment" = 284 AND "Story Points" = "1" d1143f0d-33c0-3f1c-b44b-7720150f306e
|
||||
| das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,status,resolutionkey,summary,type,status,resolution20project = "24003" AND "Program Increment" = 284 AND "Story Points" = "2" d1143f0d-33c0-3f1c-b44b-7720150f306e
|
||||
| das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,status,resolutionkey,summary,type,status,resolution20project = "24003" AND "Program Increment" = 284 AND "Story Points" = "3" d1143f0d-33c0-3f1c-b44b-7720150f306e
|
||||
| das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,status,resolutionkey,summary,type,status,resolution20project = "24003" AND "Program Increment" = 284 AND "Story Points" = "5" d1143f0d-33c0-3f1c-b44b-7720150f306e
|
||||
| das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,status,resolutionkey,summary,type,status,resolution20project = "24003" AND "Program Increment" = 284 AND "Story Points" = "8" d1143f0d-33c0-3f1c-b44b-7720150f306e
|
||||
| das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,status,resolutionkey,summary,type,status,resolution20project = "24003" AND "Program Increment" = 277 AND "Story Points" = "13" d1143f0d-33c0-3f1c-b44b-7720150f306e
|
||||
|
|
||||
@@ -0,0 +1,8 @@
|
||||
# Team Cortex
|
||||
|
||||
Version: 6 | Last modified: 2024-09-30T15:34:32.607+02:00
|
||||
Source: confluence page ID 304421681
|
||||
|
||||
---
|
||||
|
||||
7508370f-08ad-488d-95bd-6ea74381ac0e,9311910c-118b-4c19-a1fb-412003efdc78,076332de-60d3-4e8b-958a-1ab288d608cdtrue
|
||||
@@ -0,0 +1,46 @@
|
||||
# Team Hippocampus
|
||||
|
||||
Version: 17 | Last modified: 2026-05-22T09:57:29.233+02:00
|
||||
Source: confluence page ID 304428823
|
||||
|
||||
---
|
||||
|
||||
Wer wir sindÂ
|
||||
Name | Rolle | Organisation |
|
||||
Julian Müller | PO | DB Systel |
|
||||
Simon Stafflinger | SM | DB InfraGO |
|
||||
Stefan Hartmann | BE | DB Systel |
|
||||
Dominik Reggentin | Dev | DB Systel |
|
||||
Joe Petereit | Dev | DB Systel |
|
||||
Daniel Seidewitz | Dev | Extern |
|
||||
Robert Weyres | Dev | Extern |
|
||||
Jens Dambruch | Dev | DB Systel |
|
||||
Roman Minchyn | Dev | Extern |
|
||||
Fabian Fetting | Dev | Extern |
|
||||
|
||||
7508370f-08ad-488d-95bd-6ea74381ac0e,a684ef54-7417-4048-9f0e-01074a1a625a,076332de-60d3-4e8b-958a-1ab288d608cd
|
||||
Regeltermine Team Hippocampus
|
||||
Termin | Zeit |
|
||||
Daily | Montag bis Freitag von 09:45 - 10:15 Uhr |
|
||||
Weekly | Gemeinsames Weekly mit dem gesamten ART K&K, donnerstags 11:00 - 12:00 Uhr |
|
||||
Planning | Alle 2 Wochen mittwochs von 13:00 - 14:30 Uhr |
|
||||
Refinement | Alle 2 Wochen mittwochs von 13:00 - 14:30 Uhr (1 Woche versetzt zu Planning) |
|
||||
Retro | Alle 2 Wochen montags von 13:00 - 14:00 Uhr (1 Woche versetzt zu Planning) |
|
||||
|
||||
Sharepoint Team Hippocampus
|
||||
Auf dem Sharepoint des ART K&K können im folgenden Ordner
|
||||
Sharepoint K&K Ordner - Team Hippocampus
|
||||
zentral gröÃere Dateien/Präsentationen abgelegt werden.
|
||||
|
||||
Konvention für das Erstellen von neuen User Stories in Jira
|
||||
Folgende Vereinbarungen wurden für das Erstellen von neuen User Stories in Jira getroffen:
|
||||
|
||||
Abschnitt | Regeln |
|
||||
Akzeptanzkriterien | Akzeptanzkriterien werden durchnummeriert
|
||||
Akzeptanzkriterien werden kurz und prägnant, am besten im Stil der Satzschablone formuliert. Die Satzschablone gilt als Orientierung nicht als Pflichtmuster.
|
||||
|
|
||||
Beschreibung | Die Beschreibung fängt immer mit dem User Story Text an: "Als Benutzter (Wer: Bezeichnung der Rolle), möchte ich (Was: Was will der Benutzter machen?), um zu (Wozu/Warum: Grund aus dem er die Aktivität machen möchte).
|
||||
Details unter der Story werden im Freitext formuliert
|
||||
Optional: Themen, die explizit ausgeklammert werden, werden in der Beschreibung unter dem Abschnitt "Out of Scope" beschrieben. Falls in Out of Scope etwas beschrieben wird, ist immer ein Link zu der Story setzen, in der die Umsetzung erfolgt. Existiert hierfür keine Story, ist diese anzulegen und mit der ursprünglichen Story zu verknüpfen.
|
||||
Optional: Gibt es offene Fragen, sind diese unter der Ãberschrift offene Punkte zu vermerken. Gibt es offene Punkte kann die Story nicht Sprint ready sein.
|
||||
|
|
||||
@@ -0,0 +1,12 @@
|
||||
# Team Iris
|
||||
|
||||
Version: 6 | Last modified: 2024-05-03T15:06:27.917+02:00
|
||||
Source: confluence page ID 304428009
|
||||
|
||||
---
|
||||
|
||||
7508370f-08ad-488d-95bd-6ea74381ac0e,180a1617-cd57-4eca-9d7e-19335807e489,076332de-60d3-4e8b-958a-1ab288d608cdtrue
|
||||
|
||||
Arija BoardÂ
|
||||
|
||||
true
|
||||
@@ -0,0 +1,8 @@
|
||||
# Team KuKquck
|
||||
|
||||
Version: 1 | Last modified: 2024-01-15T09:05:39.586+01:00
|
||||
Source: confluence page ID 304428056
|
||||
|
||||
---
|
||||
|
||||
Arija BoardÂ
|
||||
@@ -0,0 +1,8 @@
|
||||
# Team Thalamus
|
||||
|
||||
Version: 3 | Last modified: 2024-04-26T08:08:10.262+02:00
|
||||
Source: confluence page ID 301362187
|
||||
|
||||
---
|
||||
|
||||
7508370f-08ad-488d-95bd-6ea74381ac0e,1837d6da-4afe-4777-bb37-ff9832dce889,076332de-60d3-4e8b-958a-1ab288d608cd
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
# UX-Konzepte anderer Value Teams/ARTs
|
||||
|
||||
Version: 13 | Last modified: 2023-11-15T11:11:31.519+01:00
|
||||
Source: confluence page ID 294192518
|
||||
|
||||
---
|
||||
|
||||
Value Team O2C, ART Bestellsystem und ART APNAnsprechpartner: Bernd Klebl
|
||||
UX KonzeptIm ART Oder 2 Cash haben verschiedene Anwendungen UX Konzepte. Die Konzepte für APN (Anlagenportal Netz) und das NBS (Neues Bestellsystem) erscheinen hilfreich, da sie im Confluence dokumentiert sind. Leider gibt es kein übergreifendes Konzept, sondern nur systembezogene Konzepte. O2C hat ein Portal und eine Webservice Schnittstelle.
|
||||
Nachfolgend sind Links auf Seiten eingefügt, die als hilfreich für die Erstellung eines eigenen UX Konzeptes erachtet werden, bzw. an denen man sich orientieren kann.
|
||||
UX-Design APNÂ
|
||||
Personas in APNÂ
|
||||
Frameset des Bestellportals (Ansprechpartnerin für Personas im Bestellsystem ist Ana Cvitkovic)
|
||||
Ein hilfreicher Hinweis von Bernd Klebl ist, sich bei Anwendungen die EVUs benutzen sollen, an Systemen zu orientieren, die sich mit Fahrplänen in der Kommunikation mit den EVUs beschäftigen wie bpsw. APN, Bestellsystem oder KomBau. Dagegen stehen Anwendungen, die nur DB Netz intern verwendet werden. Hier sollte eine Orientierung an IFP (bspw. neues Konstruktionssystem) ausrichtet sein.
|
||||
Kontaktaufnahme zu ZugangsberechtigtenDie Abstimmung mit den EVUs betrifft ungefähr 800 Zugangsberechtigte in Produktion, die der TPN Fachbetriebsführung bekannt sind: https://fahrweg.dbnetze.com/fahrweg-de/kunden/Netzzugang-und-Regulierung/taf-tap-tsi/evu_schnittstelle-9764508#. Bernd verweist darauf, dass diese sich als vielfache Konkurrenten eigentlich gar nicht unterhalten.
|
||||
Value Team C2S, ART KommunikationAnsprechpartner: Salvatore Pellegrino
|
||||
UX KonzeptDas ART Kommunikation mit der Anwendung KomBau arbeitet aktuell an einem UX Konzept. Es gibt noch keine Informationen auf Confluence die gesichtet werden können. Für die Kundenkommunikation mit den EVUs verfolgt das ART zwei Formate:
|
||||
Mentoring: Dieses Format befindet sich im Aufbau. Es orientiert sich an bereits bestehenden Formaten anderer Geschäftsfelder. Ein Mentor ist hier ein Anwender aus dem EVU Bereich, der Zugriff auf eine Testumgebung hat, um den Fortschritt zu tracken und jederzeit das "Look & Feel" der Anwendung ausprobieren kann. Er hat Kontakt zu einer Person aus dem ART, um sofort Feedback geben zu können. Zum Austausch mit den Organsiationseinheiten, die ein solches Format bereits etabliert haben, wird mit eingeladen.
|
||||
Showcase: Alle 3 Monate wird das sogenannte Showcaseformat durchgeführt, dass ein sehr gutes Feedback seitens der Kunden bekommt. Das Format wird in 2 separaten Veranstaltungen DB Netz-intern und extern (EVUs) durchgeführt. Es dauert 2-3 Stunden und ist in Vorbereitung, Durchführung und Nachbereitung sehr aufwendig. Es sind zwischen 100 und 140 Gästen anwesend. Einladungen erfolgen 6-8 Wochen im voraus, sonst kann eine Teilnahme nicht sichergestellt werden. KOMBau verwendet methodisch das Worldcafe, um das Format durchführen zu können. Hier eine Präsentation mit weiteren Informationen zum Format: Showcaseformat in KomBau.Â
|
||||
Kontaktaufnahme zu ZugangsberechtigtenDie Kontaktaufnahme zu Zugangsberechtigten ist über DB Vertrieb herzustellen. DB Vertrieb kennt sich mit den Verfahrensweisen aus, um eine diskriminierungsfreie Auswahl an Zugangsberechtigen zu ermitteln, die im späteren Verlauf mit dem jeweiligen ART zusammenarbeiten können. Ansprechpartner bei DB Vertrieb für KOMBau waren Louis Leinweber und Frank Schleinhege.
|
||||
Ãbergreifende AktivitätenBei der Entwicklung einer eigenen UX Strategie sollten die aktuellen Aktivitäten in Value Team C2S und ART Capacity Management überprüft werden. Die Folgenden Epics sind auf ihren Bearbeitungsstand zu prüfen, um dem Cooperate Design Gedanken Rechnung zu tragen und sich an übergeordnete Standards anzugleichen.:
|
||||
https://arija.jaas.service.deutschebahn.com/browse/KUPCM-788 â Solution-weite UX/UI-Angleichungen
|
||||
https://arija.jaas.service.deutschebahn.com/browse/C2SIFP-746 â Definition übergreifender UX/UI-Patterns für Konsistenz
|
||||
Reference in New Issue
Block a user