So machen Sie das Beste daraus MotioCI bei der Unterstützung bewährter Praktiken

MotioCI verfügt über integrierte Plugins für die Erstellung von Cognos Analytics-Berichten. Sie sperren den Bericht, an dem Sie arbeiten. Wenn Sie dann mit Ihrer Bearbeitungssitzung fertig sind, checken Sie sie ein und fügen einen Kommentar hinzu, um aufzuzeichnen, was Sie getan haben. Sie können in den Kommentar einen Verweis auf ein Ticket in einem externen Fehlerverfolgungs- oder Änderungsanforderungssystem einfügen.

Weitere Details zum Einrichten der Verbindung finden Sie zwischen MotioCI und Ihr Drittanbieter-Ticketsystem in der MotioCI Administratorhandbuch unter Verwendung MotioCI mit Ticketsystemen von Drittanbietern. Ein Schlüsselwort (behebt, schließen) mit der Ticketnummer schließt das Ticket. Oder verwenden Sie ein Schlüsselwort wie Referenzen plus die Ticketnummer schreibt den Check-in-Kommentar in das Ticketing-System und lässt das Ticket offen.

Die Verwendung eines Ticketing-Systems – wie Atlassian® JIRA, Microsoft Windows™ Trac oder vielen anderen – unterstützt das Projektmanagement, indem es bestimmte Aufgaben, Probleme und deren Lösung verfolgt. Tickets bieten ein Kommunikationsmittel zwischen Autoren oder Berichtsentwicklern und Endbenutzern, dem Testteam und anderen Beteiligten. Ein Ticketing-System bietet auch eine Methode zur Verfolgung von Fehlern und stellt sicher, dass sie behoben werden, bevor ein Bericht an die Produktion weitergeleitet wird.

Typischer Workflow für die Berichtsentwicklung

Um es klar zu sagen, die Integration von MotioCI mit einem Ticketing-System ist nicht die einzige Möglichkeit, wie Ihr Team mit dem Ticketing-System interagiert. Typischerweise, wie im begleitenden Workflow-Diagramm dargestellt, ist der Prozess der Berichtsentwicklung in einer Cognos Analytics-Umgebung mit MotioCI könnte so etwas sein:

1. Rückstand. Ein neues Ticket wird erstellt. Ein Business Analyst dokumentiert die Geschäftsanforderungen für einen neuen Bericht und gibt sie direkt in das Ticketsystem ein, indem er ein Ticket erstellt. Er legt das Ticket in die Rückstand Zustand.
2. Entwicklung. Die Backlog-Tickets können auf verschiedene Weise priorisiert werden, aber letztendlich wird das Ticket einem Berichtsentwickler zugewiesen und mit seinem Namen gekennzeichnet. Der Status des Tickets kann geändert werden in_dev. Sie erstellt einen neuen Bericht. Während sie den Bericht in Cognos Analytics entwickelt, checkt sie ihre Änderungen ein und verweist im Check-in-Kommentar auf das Ticket, z. B. „Neuen Bericht erstellt; erste Version; Eingabeaufforderungsseite und unterstützende Abfragen hinzugefügt, Refs Nr. 592“. Oder „Faktenabfrage und Kreuztabelle hinzugefügt; Filter und Formatierung, Refs Nr. 592.“ (Im MotioCI, die Hashtag-Nummer wird zu einem Hyperlink direkt zum Ticket.) Sie kann den Bericht auschecken, Änderungen vornehmen und ihn mit der Ticketreferenz mehrmals über einen Zeitraum von Tagen wieder einchecken.
3. Entwicklung abgeschlossen. Nachdem die Berichtsentwicklerin den Bericht fertiggestellt und getestet hat, vermerkt sie im Ticket im Ticketsystem, dass er bereit ist, von der QA getestet zu werden, und ändert den Status von in_Dev zu bereit_für_QA. Dieser Zustand ist eine Flagge für die MotioCI Administrator oder Rolle, die für die Förderung von Cognos-Berichten verantwortlich ist, dass der Bericht zum Testen in die QA-Umgebung migriert werden kann.
4. Promotion zur QS. Der Administrator stuft den Bericht hoch und ändert den Status auf in_QA. Dieser Zustand teilt dem QA-Team mit, dass der Bericht zum Testen bereit ist.
5. Testen. Das QA-Team testet den Bericht anhand der Geschäftsanforderungen. Der Bericht besteht die Tests entweder oder besteht sie nicht. Wenn der Bericht den QA-Test nicht besteht, wird das Ticket mit gekennzeichnet in Dev Status, der für Korrekturen an den Berichtsentwickler zurückgesendet wird.
6. Test erfolgreich. Wenn der Bericht bestanden wird, teilt das QA-Team dem Administrator mit, dass es bereit ist, in die Produktion hochzustufen, indem es ihn kennzeichnet bereit für Prod Zustand.
7. Promotion zur Produktion. Sobald der Bericht produktionsbereit ist, können endgültige Genehmigungen eingeholt und die Veröffentlichung geplant werden, möglicherweise in Bündelung mit anderen fertigen Berichten. Der Administrator stuft den Bericht in die Cognos-Produktionsumgebung hoch. Er legt das Ticket ein Erledigt Status, der angibt, dass Entwicklung und Tests abgeschlossen sind und in die Produktion übergegangen sind. Damit ist das Ticket geschlossen.

Management des Berichtsentwicklungsprozesses

Dieser Ticketverwaltungsprozess impliziert und bewährte Praktiken diktieren Folgendes:

• Jeder neue Bericht sollte ein Ticket mit den Geschäftsanforderungen haben, nach denen der Bericht gestaltet werden soll.
• Jeder Fehler sollte ein Ticket haben, um alle Fehler oder Probleme mit einem Bericht aufzuzeichnen.
• Jedes Mal, wenn ein Bericht bearbeitet wird, wird die MotioCI Der Check-in-Kommentar sollte die adressierte Ticketnummer enthalten.
• Jeder Bericht, der von Dev zu QA hochgestuft wird, sollte ein zugehöriges Ticket haben, mit dem ein Administrator bestätigen kann, dass die Entwicklung abgeschlossen wurde und bereit ist, in die QA-Umgebung verschoben zu werden.
• Jeder Bericht, der von der QA in die Produktion hochgestuft wird, sollte ein Ticket haben, das einen Verlauf aufweist, aus dem hervorgeht, dass die Entwicklung abgeschlossen ist, die QA bestanden hat, alle erforderlichen Managementgenehmigungen erhalten hat und hochgestuft wurde.
• Jeder Bericht in der Produktionsumgebung sollte eine haben digital Paper Trail von der Konzeption über das Testen bis hin zur Fixierung, Lösung, Genehmigung und Promotion.

Dieser letzte Punkt ist ein Favorit der Auditoren zur Validierung. Sie könnte fragen: „Können Sie mir zeigen, wie Sie bestätigen, dass alle Berichte in der Produktionsumgebung Ihrem dokumentierten Ticketing- und Genehmigungsprozess entsprechen?“ Eine Möglichkeit, dem Prüfer zu antworten, könnte darin bestehen, eine Liste aller migrierten Berichte bereitzustellen und ihn die Tickets durchsuchen zu lassen, um nach einem zu suchen, der nicht Ihrem Prozess entspricht.

Alternativ und idealerweise können Sie eine Liste mit Berichten bereitstellen, die dies tun nicht Halten Sie sich an den von Ihnen definierten Entwicklungs- und Ticketing-Prozess. Hier wird dieser Bericht nützlich sein: „Ohne Tickets beworbene Berichte“. Es ist ein Ausnahmebericht aus einer Liste von Berichten, bei denen dies der Fall ist nicht hat sich an die Best Practices gehalten, jede Berichtsänderung mit einem Ticket zu verknüpfen. Dies ist einer der wenigen Berichte, die leer bleiben sollen. Es hat keine Datensätze, wenn allen hochgestuften Berichten ein Ticket zugeordnet ist. Mit anderen Worten, ein Bericht wird nur dann in der Liste angezeigt, wenn er sich in der Produktionsumgebung befindet und der hochgestufte Bericht im Kommentar nicht auf eine Ticketnummer verweist.

Prozess mit Vorteilen

Was sind die Vorteile des Prozesses oder warum sollten Sie dies in Ihrer Organisation tun?

• Verbesserte Zusammenarbeit im Team: Das Ticketing-System kann tatsächlich Personen in Rollen zusammenbringen, die normalerweise nicht miteinander kommunizieren. Beispielsweise Berichtsautoren und Endbenutzer oder Projektmanager und das QA-Team. Der Ticket-Trail bietet einen gemeinsamen Ort für die Kommunikation über eine gemeinsam genutzte Ressource, den in Entwicklung befindlichen Bericht.
• Reduzierte Kosten:
  • Fehler, die früher erkannt und behoben werden, sind viel kostengünstiger, als wenn sie in die Produktion gelangen.
  • Verbesserte Effizienz – Berichtsautoren arbeiten immer mit einem Ticket, das eine klar definierte Leistungsbeschreibung ist.
  • Zeitersparnis durch Automatisierung manueller Prozesse
• Verbesserte Dokumentation: Dieser Prozess wird zu einer selbstdokumentierenden Wissensdatenbank mit Fehlern und deren Lösung.
• Verbesserte Prognosen und Analysen: Sie können jetzt wichtige Leistungsindikatoren verfolgen und sie mit Service Level Agreements vergleichen. Die meisten Ticketsysteme bieten diese Arten von Analysen.
• Verbesserter interner Support: Ihr Support-Team, andere Berichtsentwickler (und sogar Ihr zukünftiges Ich!) können nachsehen, wie ähnliche Fehler in der Vergangenheit behoben wurden. Diese gemeinsame Wissensbasis kann zu einer schnellen Behebung von Fehlern führen.
• Verbesserte Endbenutzerzufriedenheit: Mit direktem Zugang zu Entwicklern über das Ticketing-System können Benutzer mit einer schnellen Behebung von Fehlern rechnen und den Fortschritt eines angeforderten Berichts durch das System überwachen.

Zusammenfassung

Dies ist ein Beispiel dafür, wie sich die Befolgung bewährter Praktiken und der Wert der Befolgung klar definierter Prozesse auszahlt. Weiter das Neue MotioCI report, „Reports Promoted with no Tickets“ kann eine große Hilfe bei der Beantwortung von Fragen eines Wirtschaftsprüfers oder einfach bei der internen Überwachung der Einhaltung von Unternehmensstandards sein.