Zum Inhalt springen

Der Targetprocess-Import: umziehen mit der ganzen Geschichte

Version 0.9.64 Min. Lesezeit

Kein Team fängt mit einem leeren Board an. Wer GODAV Pro einführen will, hat seine Epics, Stories und Requests meistens schon jahrelang in einem anderen Werkzeug gepflegt, zum Beispiel in Targetprocess. Ohne Import hieße der Umstieg: alles abtippen oder die Geschichte zurücklassen. Beides ist keine Option, also gibt es seit dieser Version unter Integrationen einen Import, der den Bestand herüberholt.

Die Liste der Importe unter Integrationen Jeder Import ist ein eigener Eintrag mit eigenem Wizard.

Eingerichtet wird der Import in einem Wizard aus sechs Schritten, und kein Feld darin verlangt, dass man eine Abfrage tippt. Dahinter steht ein neutrales Importmodell, das nur Begriffe kennt, die jedes Fremdsystem hat: Projekt, Vorgang, Status, Priorität, Person. Genau ein Adapter weiß, wie Targetprocess diese Dinge nennt. Ich hätte den Import direkt gegen dessen Schnittstelle schreiben können, das wäre schneller gegangen. Kommt aber irgendwann ein zweites System dazu, brauche ich so nur einen zweiten Adapter, und Wizard, Prüfung und Lauf bleiben, wie sie sind. Hier geht es darum, wie die Daten ankommen, wie man den Umfang eingrenzt, und warum ein Haken wichtiger ist als alle anderen.

Die Geschichte zieht mit um

Ein importierter Vorgang trägt als „Erstellt am“ das Datum aus Targetprocess, nicht den Tag des Imports. Das klingt selbstverständlich, ist aber die einzige Stelle in ganz GODAV, an der ein Erstellungsdatum nicht „jetzt“ ist. Ich hätte es mir einfach machen und das Importdatum stehen lassen können. Dann hätten aber alle Berichte über Durchlaufzeiten behauptet, jede Anfrage der letzten Jahre sei am selben Dienstag eingegangen und in Rekordzeit bearbeitet worden. Ein Bericht, der mit erfundener Geschichte rechnet, ist schlimmer als keiner.

Bei Personen bin ich bewusst zurückhaltend geblieben. Aus einem Import entsteht kein Konto. Wer drüben zugewiesen war und hier niemandem zugeordnet ist, bleibt unzugewiesen, und Kommentare beginnen mit einer kurzen Zeile, von wem und wann sie ursprünglich stammen. Anfragende dürfen dagegen entstehen, denn das sind Menschen von außen, die ohnehin kein Konto haben. Vorgänge, deren Elternvorgang außerhalb des Umfangs liegt, landen in einem Sammelvorgang ihrer Ebene, statt still zu verschwinden.

Filter und Feldmapping je Vorgangsart

Selten will man wirklich alles übernehmen. Deshalb hat jede Vorgangsart im Schritt „Umfang“ einen eigenen Filter. Man baut ihn aus Feld, Operator und Wert zusammen oder tippt ihn direkt. Der Baukasten schreibt dabei in denselben sichtbaren Text, es gibt also keinen zweiten, versteckten Zustand. „Treffer zählen“ fragt Targetprocess, wie viele Vorgänge der Ausdruck trifft.

Der Schritt Umfang mit Filterbaukasten und Feldmapping für Requests Filter und Feldmapping hängen an der einzelnen Vorgangsart.

Spannend war die Frage, was mit den Kindern eines aussortierten Vorgangs geschieht. Meine Antwort: Sie fallen nur dann mit heraus, wenn die Elternart selbst angehakt ist. Wer Features importiert und eines davon wegfiltert, will dessen Stories nicht haben. Wer dagegen nur Stories importiert, hat über Features gar nichts gesagt, und dann wäre es eine Überraschung, wenn ein Filter auf Feature-Ebene trotzdem Stories verschluckte.

Daneben steht das Feldmapping: Ein Feld aus Targetprocess, auch ein selbst angelegtes, füllt ein Feld hier, etwa Priorität, Schätzung, Zieltermin, Schlagworte oder ein benutzerdefiniertes Feld. Angeboten wird nur, was vom Typ her passt. Story Points habe ich absichtlich weggelassen, weil GODAV sie nirgends anzeigt, und ein Import, der Werte schreibt, die niemand sieht, ist eine Attrappe. Eine Ganzzahl wird übrigens nicht gerundet: Aus 2,5 still eine 3 zu machen, wäre ein anderer Wert. Und ein späterer Lauf zieht Werte nach, aber ein leerer Wert drüben lässt den Wert hier stehen.

Der wichtigste Haken: still importieren

Ganz am Ende, direkt über „Import starten“, steht Benachrichtigungen unterdrücken, und er ist ab Werk gesetzt, als einziger Schalter des ganzen Wizards.

Die Prüfung mit dem gesetzten Haken „Benachrichtigungen unterdrücken“ Ab Werk gesetzt: Der Lauf meldet nichts, was er selbst auslöst.

Der Grund ist der teuerste Fehler, den dieser Bereich machen kann. Ein importierter Request ist für GODAV ein neu angelegter Request, und darauf folgt normalerweise eine Eingangsbestätigung an den Anfragenden. Ein Lauf über zweihundert alte Anfragen hätte zweihundert echten Kunden geschrieben, für Anliegen von vor Jahren. Diese Mails sind draußen und lassen sich nicht zurückholen. Ein Lauf, der versehentlich geschwiegen hat, ist dagegen schnell nachgeholt. Von zwei möglichen Fehlern habe ich den gewählt, der sich rückgängig machen lässt.

Der Haken unterdrückt nur, was der Lauf selbst auslöst, und zwar per Mail und in Teams. Was ein Kollege währenddessen kommentiert, wird ganz normal gemeldet. Erinnerungen an Zieltermine bleiben bewusst unberührt: Unterdrückt würden sie als erledigt gelten und nie mehr verschickt. Die Karte des Laufs vermerkt hinterher, dass er still war. Wer Wochen später fragt, warum zu diesen Vorgängen niemand Post bekommen hat, findet die Antwort dort.

Außerdem

  • Der Lauf arbeitet im Hintergrund, zeigt Fortschritt und Protokoll und lässt sich abbrechen, und zwar immer erst nach dem Vorgang, an dem er gerade arbeitet. Ein halb angelegter Vorgang wäre schlimmer als einer zu viel.
  • Startet der Server mitten im Lauf neu, wird der Lauf als abgebrochen markiert, statt ewig einen Fortschritt anzuzeigen, der sich nicht mehr bewegt.

Der Import ist mit Targetprocess gestartet, aber nicht darauf festgelegt. Kommt ein zweites System dazu, bekommt es einen eigenen Adapter, und alles, was hier beschrieben ist, gilt dann einfach weiter.

  • Integrationen
  • Vorgänge
  • Mail