Roadmap
Unsere Software wird kontinuierlich weiter entwickelt
Wir bereiten dazu in einem Trello Board tagesaktuell auf, wie wir die weitere Entwicklung der IDA planen und auf welche Module wir in welcher Reihenfolge den Fokus der Entwicklung legen.
Klicke einfach auf diesen Link zum Trello Board, um die Roadmap zu öffnen:
Das Board ist öffentlich; es wird also kein Trello Account benötigt um es zu betrachten. Kommentare sind auf diesem Board freigegeben - dazu braucht man dann allerdings schon einen Account. Hier noch ein paar Erläuterungen zur Roadmap, die man auch im Board auf der Karten “Über diese Roadmap” findet:
Was beinhaltet die Roadmap?
Die Roadmap beinhaltet strategische Themen zur Weiterentwicklung unserer Produkte. Es beinhaltet keine Details oder einzelne Arbeitspakete sondern ist ein Tool, um Transparenz zu geben und Zusammenarbeit auf mittlerer Flughöhe zu unterstützen.
Typischerweise sind in den Karten Ausbaustufen von Modulen in der IDA oder Erweiterungen und Anbindungen des IDADWH und der DaisyChain aufgeführt - oder signifikante Anpassungen an der Architektur oder Infrastruktur der IDA.
Unterteilung in Reifegrade
Wir treiben die Entwicklung unserer Module in Etappen voran. Die dabei zu erreichenden Reifegradstufen kennzeichnen wir mit einem Label, das die geplanten Maßnahmen zuordnet:
Lila = Reifegrad I: Initial/ Basis Kernfunktionalität sowie Funktionen zur Erfassung von Stammdaten.
Dunkelblau = Reifegrad II: Prozessfunktionen Implementierung von Prozessen im Rahmen des jeweiligen Moduls, aber auch Modulübergreifend
Grün = Reifegrad III: Komfortfunktionen Funktionen etwa zur Visualisierung von Bewertbarkeit von Prozessen, zusätzliche Reports oder Sichten
Hellblau = Reifegrad IV: Kontinuierliche Verbessung Detailoptimierungen und kontinuierliche Weiterentwicklung der Prozesse und Funktionen
Aktiv
In der Spalte "Aktiv" sollte jeder Mitarbeiter nicht mehr als zwei Themen gleichzeitig bearbeiten. Da idealerweise aber mehrere Mitarbeiter gleichzeitig an einem Thema arbeiten, sollte die Anzahl an aktiven Themen idealerweise deutlich kleiner sein, als die Anzahl der Softwareentwickler mal zwei.
Kurzfristig, mittelfristig und langfristig
Aus der Spalte "kurzfristig" bedienen wir uns, wenn wir in den Arbeitspaketen zu den Karten in der Spalte "Aktiv" keine Aufgaben mehr finden.
Inwieweit Karten aus "mittelfristig" und "langfristig" jeweils nachrücken, hängt einerseits von den gewohnt engen Abstimmungen mit unseren Kunden ab und natürlich aber auch, wie viel Zeit wir außerhalb der Reihe in die Pflege der bestehenden Software investieren müssen und wie viele Themen neu rein geschoben werden. Besonderes Augenmerk gilt natürlich auch der Frage, ob es Abhängigkeiten zwischen Modulen und ihrer Reife gibt.
Breite oder Tiefe?
Grundsätzlich sehen wir im Zusammenwirken der Module den größten Wirkungseffekt unserer IDA. Dabei macht es in der Regel wenig Sinn, wenn einzelne Module einen sehr hohen Reifegrad haben, während andere Module noch nicht einmal initial bzw. nur in geringer Reife verfügbar sind. (Beispiel: was nützt ein besonders weit entwickeltes Auftragssteuerungsmodul [MES], wenn das Finanz- und Controllingmodul [FI] keine kommerziellen Daten in das MES einspeisen und daraus weiterverarbeiten kann.) Deswegen streben wir einen homogenen Fortschritt in der Reife der Module an und wollen in der jeweiligen Reifegradstufe zunächst mit allen Modulen den Status "Initial/ Basic" erreichen, dann mit allen Modulen den Status "Prozessfunktionen" usw.
Die Frage "Breite oder Tiefe" würden wir deswegen so beantworten, dass wir mit der Breite in die Tiefe wollen.
Warum wir keine Zeitangaben machen
Softwareentwicklung ist ein kreativer Prozess, der sich langfristig im Spannungsfeld sich ändernder Rahmenbedingungen vollzieht. Aus jeder Karte dieser Roadmap gehen jede Menge Arbeitspakete hervor, die wir jeweils erst kurzfristig vor der Bearbeitung detailliert spezifizieren. Erst dann bekommen wir ein Gefühl für den tatsächlichen Aufwand.
Durch die enge Abstimmung mit unseren Kunden lassen wir Feedback in diese Planung einfließen und orientieren uns bei den Priorisierungen immer auch an deren betrieblichen Erfordernissen.
So wird es unmöglich - und auch unseriös - die Roadmap mit Zeitvorgaben zu unterlegen.
Die Alternative zu diesem sog. agilen Vorgehensmodell ist die ingenieurmäßige Softwareentwicklung. In den 00er Jahren und insbesondere in diesem Jahrzehnt begann man sich davon abzuwenden. Komplexe Softwareprojekte, wie sie heute üblich sind und wie wir es auch auf dieser Roadmap wiederspiegeln, sind damit schlicht und ergreifend nicht mehr zu beherrschen.