Stefan's Blog

Im Projekt "Die Umsetzung von Grob nach Fein"

Veröffentlicht 08.11.2024
image

Wie in einem vorigen Post schon beschrieben ist es wichtig, ob es ein Einführungs- oder Entwicklungsprojekt ist. Ist das Klar und eventuelle Vorarbeiten abgeschlossen, wird mit einem einfachen Fall in der Umsetzung begonnen und Schritt für Schritt mehr Komplexität umgesetzt und getestet – dies so lange und mit Optimierungs-Schritten wie nötig.

Bisher waren die Phasen eher sequenziell, oder wie andere Methodologien schreiben, "Wasserfall". Es wurden also alle Themen aufgenommen und zusammengefasst, bis die Phase abgeschlossen wurde. Bei dieser Phase "Umsetzung von Grob nach Fein" ist es anders. Es macht aus Erfahrung keinen Sinn, alles ganz genau aufzuschreiben, und dann umzusetzen, weil das Zielbild zum einen nicht allen von Beginn klar ist und wenn es vermeintlich klar ist, haben doch einige nicht das Abstraktionsvermögen, sich schon zu Beginn das Ergebnis vorzustellen.

Mir ist hier wichtig, dass es kein verfehlen ist, wenn man sich die Lösung nicht gleich komplett vorstellen kann. Das ist eher normal und diejenigen, die das Vorstellungsvermögen haben, sind oft jene, die das von Berufswegen her tun. Ein Fachbereich, der spezialisiert auf das Tagesgeschäft ist, muss sich die Lösung nicht im Detail vorstellen können. Dafür wurden sogenannte agile oder iterative Projekte (auch) erfunden.

Aus der Phase "Übersetzung in Systeme" ist der neue Prozessablauf mit Beschreibungen und Systembezug, sowie deren Use Cases herausgekommen. Viel tiefer muss ein "Konzept" meiner Meinung nach nicht sein.

Die Umsetzung nimmt sich nun jeden Prozess (Haupt- Begleitenden- und Sub-Prozess) vor und setzt diese nach dem SetUp von einfach nach komplex mit Berechtigungseinstellungen im System um.

Wichtig ist hier aber immer zu bedenken, dass es auch komplexe Use Cases zu den Prozessen gibt, daher bin ich kein Freund von "einfach mal Loslegen", wie es in der Agilen Herangehensweise oft praktiziert wird. Ein Plan und grobes Zielbild mit den meissten Use Cases muss schon vorhanden sein.

Ein Use Case ist ein in sich abgeschlossener Arbeitsablauf mit einem definierten Start und Ende mit einem Prozess-Bezug. Daher sollten diese herangezogen werden und im System mit User Stories versehen werden, die dann realisiert, getestet und freigegeben werden, um dann abschliessend den Use Casse am System vollständig durchlaufen zu können. Auf die genaue Vorgehensweise und den Unterschied Use Case zu Test Case gehe ich in einem späteren Post ein.