Keystone - Projektmanagement Marke Eigenbau
Jan Ellermann
In der ATMINA Solutions GmbH haben wir vor einigen Jahren entschieden, nicht auf die handelsüblichen Projektmanagement-Tools zu setzen, sondern die Entwicklung eines eigenen Tools zu wagen. Welche Erfahrungen wir dabei machen konnten und wie unser Tool inzwischen gewachsen ist, möchten wir euch in diesem Blogbeitrag vorstellen.
Ob Kunde oder Entwickler - Du fragst dich, was dich bei uns erwartet? Schau herein und gewinne einen Einblick hinter die Kulissen!
Warum eine Eigenentwicklung?
JIRA, Asana, awork, Linear und sogar Excel sind nur ein Bruchteil der Tools, die es auf dem Markt zu entdecken gibt. Warum sollte man sich also für den Aufwand einer Eigenentwicklung entscheiden?
Unser Wunsch
Für uns hat es eine hohe Priorität, dass unsere Kunden während der gesamten Produktentwicklung nicht nur informiert, sondern aktiv in den Entwicklungsprozess eingebunden sind. Sie arbeiten eng mit unseren Teams zusammen und haben die Möglichkeit, die Gestaltung des Produkts direkt mitzubestimmen. Sie sollen beispielsweise jederzeit in der Lage sein, Einfluss auf die Inhalte ihres Backlogs zu nehmen. Wir wünschen uns eine Software, die nicht nur uns während der Organisation unterstützt, sondern auch alltäglich und gerne von jedem unserer Kunden genutzt wird.
Das Problem
Und hier stoßen wir oft auf ein großes Problem mit den vorhandenen Lösungen. Die Komplexität der Anwendungen ist von Natur aus hoch, da die Tools auf dem Markt eine sehr breite Aufstellung von Funktionen und Integrationen anbieten müssen. Der agile Entwicklungsprozess passt sich schnell an Situationen, wie der Projektgröße, Komplexität oder auch der Anzahl der beteiligten Personen an. Jedes Softwareentwicklungsunternehmen, jeder Kunde und jedes Projekt unterscheiden sich voneinander. Eine richtige Lösung für alle Gegebenheiten gibt es nicht. Somit wird ein großer Teil der bereitgestellten Funktionen der fertigen Lösungen oftmals gar nicht oder falsch genutzt. Daraus resultiert, dass die Bedienung der vorhandenen Projektmanagement-Tools für fachfremde Anwender, alles andere als intuitiv ist.
Auch möchte ich hier noch ein weiteres sehr wichtiges Kriterium für unsere Entscheidung erwähnen. Als Unternehmen entwickeln wir uns stetig weiter. Es ist immer unser Anspruch, dazuzulernen. Unser Workflow passt sich daher durch unsere Erfahrungen und Retrospektiven an. Die genauen Anforderungen an ein Tool verändern sich somit immer wieder. Ein Projektmanagement-Tool darf uns in der Entwicklung unseres Prozesses nicht im Wege stehen.
Die Vision
Es gilt also, ein Tool zu entwickeln, welches die Anforderungen unserer Entwickler, aber auch unserer Kunden optimal erfüllt. Dabei soll die Software nur Funktionen anbieten, welche für uns nützlich sind, um die Bedienung möglichst einfach zu gestalten. Neue Nutzer sollen sich ohne zusätzliche Erklärungen in ihren Projekten zurechtfinden können und nicht davor zurückschrecken, alle Bereiche der App zu erforschen. Gleichzeitig muss die Software leicht anpassbar sein, um neuen Anforderungen gerecht zu werden. Dies ermöglicht uns, wie auch während der agilen Entwicklung, mit schnellen Änderungen zu experimentieren, um unsere Organisation der verschiedenen Projekte zu verbessern.
Technische Grundlagen - Die Qual der Wahl?
Klicke hier, falls du den technischen Teil überspringen möchtest
Unsere nun gefundenen Anforderungen geben uns eine gute Grundlage für eine ganze Reihe von Entscheidungen. Schnell wird klar, wir setzen auf React als Frontend. Nicht nur sind wir den Umgang mit dem Framework aus anderen Projekten gewohnt, auch bietet es uns die Möglichkeit, das UI sehr schnell und effizient anzupassen.
Für das Backend kommt für uns nur .NET in Frage, durch welches wir eine sehr hohe Langlebigkeit für den Kern der Software gewinnen. Außerdem ermöglicht uns ein komplexes Verfahren, unseren Usecase optimal abzubilden.
Event Sourcing
"Neue Nutzer sollen sich ohne zusätzliche Erklärungen in ihrem Projekt zurechtfinden können und nicht davor zurückschrecken, alle Bereiche der App zu erforschen."
Wie nimmt man Nutzern am leichtesten die Angst, einen Button zu drücken? Man sagt ihnen, dass sie mit keiner einzigen Aktion in der Software einen Schaden verursachen können. Selbst dann nicht, wenn sie alle verfügbaren Inhalte löschen. Klingt einleuchtend, aber wie setzt man das in die Praxis um? Hier kommt Event Sourcing ins Spiel.
Anstatt Daten wie gewohnt in die Zellen von Tabellen zu schreiben, wird beim Event Sourcing jede Aktion, die in der Anwendung ausgeführt wird, als ein Event protokolliert. Diese Events werden in einer Datenbank gespeichert und können jederzeit wieder abgerufen werden. Es wird also nie der tatsächliche Zustand der Daten gespeichert, sondern die gesamte Historie aller Ereignisse. Somit ist es mit Leichtigkeit möglich, den Zustand der Daten zu jedem beliebigen Zeitpunkt wiederherzustellen.
Dieses Konzept bietet gleich mehrere Vorteile:
- Jede Veränderung der Daten kann zurückgenommen werden.
- Wir müssen nicht im Voraus überlegen, welche Daten für eine spätere Analyse oder Statistik gespeichert werden müssen, da alle Informationen verfügbar bleiben.
- Das Anpassen oder Erweitern des Datensatzes ist durch die Historie der Daten sehr sicher.
Keystone nutzt für die Speicherung von Daten ausschließlich Event Sourcing. Da das Thema für sich allerdings eine ganze Bibliothek an Büchern füllen könnte, wollen wir es hier dabei belassen.
Keystone - Projektorganisation für Entwickler und Kunden
Keystone ist längst keine Beta mehr und seit vielen Monaten Teil unseres Alltags und all unserer Projekte geworden. Die Anwendung ist sowohl im Browser auf dem Desktop und mobilen Geräten verfügbar, kann aber auch als Anwendung installiert werden (PWA). Um euch nicht nur einen Einblick in das Tool, sondern auch in unseren Prozess zu ermöglichen, möchte ich hier die wichtigsten Funktionen vorstellen:
Verwaltung von Projekten
In einer klassischen Übersicht finden wir all unsere Projekte und können uns diese zuweisen, sodass wir immer schnell und einfach auf das richtige Projekt wechseln können. Während ein interner Benutzer alle Projekte einsehen kann, werden Kunden nur ihre eigenen Projekte angezeigt.
Einsicht in die wichtigsten Projektdetails
Auf der Detailseite eines Projektes finden wir Kontaktmöglichkeiten zu Kunden und Entwicklern, eine Übersicht aller relevanten Informationen und eine Liste von nützlichen Links, z. B. zu Testinstanzen, MIRO Boards und Weiterem.
Storymapping
Bevor wir mit der eigentlichen Entwicklung beginnen, erstellen wir oft im Verlauf unserer Strategiesprints zusammen mit dem Kunden eine Storymap. Sie bietet uns eine grobe Übersicht über die Funktionen des zu entwickelnden Produktes. Die einzelnen Karten lassen sich einfach hin und her verschieben und in verschiedene Iterationen gruppieren. Das System ist dabei sehr einfach gehalten, sodass wir die Beschriftungen immer optimal an unsere Bedürfnisse anpassen können.
Backlog
Das Herz eines Projektes ist der Backlog. Hier werden alle Arbeiten, die wir für das Projekt erledigen müssen, aufgelistet, im Detail beschrieben und priorisiert. Backlogitems können neben einem Titel und einer Beschreibung noch weitere verschiedenste Informationen beinhalten, wie z. B. Schätzungen, Dateianhänge oder Abhängigkeiten zu anderen Items. Sowohl Kunden als auch Entwickler können die einzelnen Items bearbeiten, mit Kommentaren versehen und sehen den aktuellen Status der einzelnen Items. Items aus dem Backlog sind automatisch mit den Issues in GitLab synchronisiert, sodass wir die Inhalte nicht doppelt pflegen müssen, und Keystone immer unsere einzige Quelle der Wahrheit bleibt. Wird ein neues Item bearbeitet, wird im Hintergrund ein neues Issue inkl. Merge Request in GitLab erstellt.
Sprintplanung und Planning Poker
Unsere Sprints beginnen mit einer Sprintplanung. Mit den Entwicklern zusammen besprechen wir die Inhalte der nächsten Iteration, formulieren ggf. technische Details aus und klären offene Fragen. Dabei wird der Aufwand der Items im Backlog geschätzt, um zu entscheiden, wie viele Aufgaben wir in den Sprint mit aufnehmen können und um Missverständnisse in den Anforderungen aufzudecken. Gehen die Schätzungen mal sehr weit auseinander, ist das ein sicherer Indikator dafür, dass die Items nicht klar genug definiert sind. Das in Keystone integrierte Planning Poker ermöglicht uns dabei, diese Schätzungen zu jeder Zeit schnell und einfach durchzuführen.
Dashboard für Entwickler
Unser Dashboard richtet sich hauptsächlich an unsere Entwickler. Hier finden wir ein klassisches Kanban-Board mit allen aktuellen Aufgaben des laufenden Sprints. Beim Verschieben der Items wird der Zustand automatisch mit GitLab synchronisiert. Das Dashboard hilft sowohl der Entwicklung als auch Organisation, einen guten Überblick über die aktuelle Auslastung zu behalten.
Zusätzlich ist unser Tool für die Zeiterfassung (Toggl) im Dashboard integriert, sodass uns beim Bearbeiten der Items zusätzliche Eintragungen erspart bleiben und wir uns möglichst wenig darum kümmern müssen.
Halbjahresumfragen
Zweimal im Jahr führen wir intern eine Umfrage durch. Jeder Mitarbeiter kann anonym Kommentare abgeben, welche Themen ihm wichtig sind und wie wir unseren Prozess verbessern können. Die Fragen decken dabei so gut wie alle Bereiche unserer Firma ab. Neben individuellen Wünschen geht es um unsere Arbeitsatmosphäre, OKR, die Geschäftsführung und vieles mehr. Auch heikle Themen können so offen angesprochen und diskutiert werden.
Die Antworten der Umfragen werden in Keystone offen dargestellt, sodass wir die Ergebnisse, auch vergangener Jahre, immer einsehen und vergleichen können. Die letzten Jahre haben uns bestätigt, wie wichtig dieses Tool ist, um uns als Unternehmen voranzubringen.
Rechnungslauf
Als einzige Quelle der Wahrheit, dem Backlog aller Projekte, unserer Kunden und der Integration unserer Zeiterfassung ist der nächste offensichtliche Schritt die Abwicklung unserer Rechnungen. So haben wir im vergangenen Jahr unseren Fokus auf die Umsetzung eines Rechnungslaufs in Keystone gelegt.
Leistungsaufstellungen sind, durch direkten Bezug zu Backlog Items, von der Anforderung bis zur Rechnungsposition nachvollziehbar. Durch die Integration von kontenbasierter Buchführung sind Projektbudgets jederzeit transparent - unabhängig vom Abrechnungsmodell (monatlich, Abschläge, Vorauszahlung für Serviceverträge). Durch die Integration mit Lexoffice sichern wir regelkonforme Erzeugung von Rechnungen, Unterstützung des xRechnung Standards, sowie einen Feedback-Loop zum Rechnungswesen (Zahlungseingänge). Hinterlegte Verträge lösen regelmäßige Rechnungen für Serviceverträge, Hosting und ähnliches aus.
Tools von und für Entwickler
Als Teil unserer täglichen Arbeit und internen Entwicklung dürfen natürlich einige Sonderfunktionen nicht fehlen. So besitzt Keystone z. B. die Möglichkeit, API Keys zu erstellen, sodass unsere Datenbasis auch für externe Tools zugänglich ist.
So ist während unserer Personal Developer Days bereits eine Raycast-Extension und eine CLI als alternative Steuerung für Keystone entstanden.
Fazit
Auch wenn die Entwicklung Keystones uns vor einen großen Aufwand und einen ganzen Haufen von Herausforderungen gestellt hat, so sind wir uns einig, dass dieser Weg für uns als Firma von unschätzbaren Wert war. Nicht nur konnten wir durch die Arbeit an dem Tool enorm viel Wissen in unterschiedlichsten Bereichen erlangen, wir konnten auch unser initiales Ziel erfüllen - eine leicht zu bedienende, aber dennoch mächtige und anpassbare Lösung zu schaffen, die unsere Organisation und Prozesse unterstützt und verbessert. Unsere Entwickler und unsere Kunden nutzen Keystone täglich und schätzen es.
Durch die Entwicklung von Keystone haben wir unverzichtbare Erkenntnisse über die Organisation unserer Projekte gewinnen können. Wir brennen darauf, unsere internen Tools und damit auch uns in Zukunft weiterzuentwickeln.
Hat dich die Neugier gepackt? Dann schau doch einfach mal vorbei, ruf uns an oder schreibe uns eine E-Mail! Du findest uns in der Theaterstraße 8 im Herzen von Hannover.
Themen:
- Allgemein
- Softwareentwicklung
- Projektmanagement