Wir organisieren die Zusammenarbeit mit Ihnen im Projekt und in der laufenden Betreuung über ein virtuelles Scrum-Board

Zentraler Bestandteil unserer Zusammenarbeit ist ein virtuelles Board in welchem Sie genauso wie wir Zugriff haben.

Die Oberfläche haben wir dabei in die sechs Bereiche „Product Backlog“, „Sprint Backlog“, „Im Gange“, „Testen“, „Bug-Behaftet“ und „Erledigt“ unterteilt.

Auf den einzelnen „Reitern/Spalten“ finden Sie diverse Karte, die je nach Zuordnung –  noch nicht bearbeitet, bis zu abgeschlossen – eingeteilt sind.

Product Backlog

Sprint Backlog

Im Gange

Testen

Bug-Behaftet

Erledigt

Was ist Trello?

Einen ersten Überblick finden Sie in unserem Kurz-Video zu unserer Arbeitsweise anhand unseres Beispielboards.

 

Trello ist ein Tool bzw. eine Kommunikationsplattform, die Ihnen und uns, dem Team der World-of-edv, den Austausch während Ihrer Projektphase um ein vielfaches erleichtert. Im Trello ist der Scrum-Gedanke fest verankert. Die Oberfläche hat eine intuitive Bedienung und es wird von links nach rechts gearbeitet, bis die Karten in Spalte „Erledigt“ landen. Die Karteikarten lassen sich mittels Checklisten flexibel organisieren. Dank einer Kalenderfunktion und Mitteilungen bleiben Sie immer am neuesten Stand. Auch Ihre Mitarbeiter können an das Board zugreifen und Dateien, wie z.B. Bilder oder Excel-Tabellen hochladen.

Das Trello können Sie am Browser, am Handy oder Tablet verwenden, oder sogar offline. Probieren Sie es aus!

Die 6 Spalten im Board genauer erklärt

Diese Spalte ist „Ihr Reich“. Zum Projektstart unterstützen wir Sie bei der Erstellung der ersten Karten. Dort tragen Sie lfd. Ihre Wünsche und Anforderungen an Ihre Lösung in Form von User Storys ein. Sie legen die Prioritäten für diese Karten fest, indem Sie diese in der Reihenfolge (von oben nach unten) durchsortieren, welche von uns als erstes bearbeitet werden sollen. Diese Karten werden, bevor wir diese in Bearbeitung nehmen, mit Ihnen besprochen und von uns mit einem geschätzten, zeitlichen Aufwand versehen. Bevor wir die Karten in den nächsten Sprint „ziehen“ ist Ihrerseits noch eine Freigabe der Arbeiten notwendig. So behalten Sie den Überblick, welche Arbeiten in welcher Reihenfolge zu welchen Aufwänden abgearbeitet werden.

Die sich dort befindlichen Arbeiten sind geschätzt, soweit definiert, dass unsere Techniker wissen, was zu erledigen ist und sollten in einem zeitlichen Rahmen der kommenden zwei Wochen erledigt werden. Dort stimmen wir uns abhängig der freigegebenen Arbeiten, der Kapazität seitens unserer Technik-Abteilung und der Dringlichkeit Ihrer Arbeiten ab, welche aus dem Product Backlog in den kommenden Sprint verschoben werden sollen.

An diesen Vorgängen wird aktuell gerade gearbeitet und wir kommunizieren intensiv mit Ihnen über unser Scrum-Board. So behalten Sie und wir auch bei größeren Projekten den Überblick wer hier wo auf welche Information von wem wartet. Dadurch bietet Ihnen unser Scrum-Board maximale Transparenz. So bleiben Sie immer auf dem Laufenden, was gerade in Ihrem Projekt passiert.

Wenn einzelne Arbeitsschritte (Karten) von unserer Seite soweit im Testsystem implementiert sind, dass diese von Ihnen geprüft und gegengetestet werden können, bewegen wir die Karten in diese Spalte. Sie erhalten dann die Info, dass wir Ihnen diese Funktion nun gerne zeigen möchten und Sie darin schulen möchten. Wir sprechen dieses im Detail mit Ihnen ab, wie dies funktioniert und was dabei zu beachten ist. Ihre Aufgabe ist es nun, dieses zu prüfen und zu testen, ob Sie mit der Funktion „klar kommen“, oder ob hier noch etwas angepasst werden muss und/oder vor Produktiv-Einsatz nachgeschult werden sollte. Wenn Ihrerseits positives Feedback zu der Programmierung/Konfiguration erfolgt, wird durch unserer Techniker für Sie eine Dokumentation erstellt und Ihnen ausgehändigt.

Sollte ein Problem bei der umgesetzten Programmierung/Konfiguration aufgetreten sein, verschieben Sie die Karte in den Reiter „Bug-Behaftet“ und nehmen mit uns Kontakt auf. Daraufhin werden wir nach Input Ihrerseits die Karte wieder in „In Bearbeitung“ zurück schieben und die gewünschten Anpassungen vornehmen. Daraufhin wird die Karte wieder zu testen verschoben und Sie erhalten Info, dass dieses nun von uns angepasst wurde mit der Bitte dieses nun nochmal zu testen.

Alle abgeschlossenen Arbeiten landen in dieser Rubrik inkl. der kompletten in der Karte aufgelaufenen Kommunikation und Dokumentation. Dieses ist also ein wahre Wissens-Fundgrube zu Ihrem Projekt.

Für jede Aufgabe eine Karte

 

Jedes Projekt, kleine wie große, lassen sich in einzelne Arbeitspakete einteilen. Dabei durchläuft jeder dieser Karten, respektive Arbeitspakete, einen gewissen Prozess, welchen wir Ihnen auch anhand unseres ausführlicheren Beispielvideos (unten) weiter beschreiben möchten. Eine der zentralen Regeln von Scrum besteht darin, dass schnell potenziell lauffähige Software geliefert wird. So werden von uns in Abstimmung mit Ihnen iterationsweise einzelne Karte aus dem Product-Backlog in den Sprint-Backlog verschoben und zeitnah abgearbeitet, damit diese am Ende des Sprints auf in die Rubrik „Erledigt“ gestellt werden können.

Unsere Definition of Done spiegelt unsere Arbeitsweise innerhalb des Software-Projektes und auch innerhalb der einzelnen Arbeitspakete wieder. Diese Arbeitsschritte sind chronologisch aufgebaut und stellen neben der reinen zu leistenden Arbeit einen Ablaufplan innerhalb der Arbeitspakete da.

Wir haben die oft abgebildeten Scrum-Zettel-Tafeln auf eine virtuelle Ebene gebracht, in der Sie von überall aus zugreifen und informieren können und um auch direkt mit uns interagieren. So behalten Sie Ihr Projekt stets im Blick und wissen was passiert.

Die Qualitätskriterien

Wir nehmen dabei die Qualität der Arbeiten die wir für Sie Leisten dürfen sehr ernst. Dabei haben wir eine mehrstufige Definition of Done erarbeitet, mit welcher wir sicherstellen, dass die Arbeiten nach einem einheitlichen Schema und gleichbleibend hohen Qualitätsstandard durchgeführt werden. Der Ablauf von allen Tätigkeiten mit Projekt-Charakter stellt sich dabei wie folgt dar.

Die DoD (Definition of Done) ist ein fester Bestandteil einer Checkliste im Scrum Board.

 

Die Qualitätskriterien genauer erklärt

Bevor wir mit einem Arbeitspaket beginnen wird zum Start des Sprints mit Ihnen über diesen Teilschritt gesprochen, welche Erwartungshaltungen bzw. Anforderungen Sie im Detail an dieses Software-Modul, diese Programmierung, diese Schnittstelle, oder ähnliches haben. Beispiel: Bei einer DHL-Anbindung im Lager besprechen wir welche Services Sie für den Versand nutzen, welche Länder Sie beliefern, welche Datenbankfelder übertragen werden sollen, welches System die Tracking-Infos an den Kunden sendet, etc. All diese Teil-Informationen werden soweit besprochen, dass unser ERP-Consultant weiss, was zu konfigurieren/programmieren ist.

Durch diese Absprachen zu Beginn entstehen die Akzeptanzkriterien. Dort legen Sie (bzw. gerne auch wir gemeinsam) schriftlich fest, welche Anforderungen an die fertige Arbeit gestellt werden. Dieses versteht sich als eine Definition dessen, was Sie von der Programmierung erwarten, nicht wie diese technisch umgesetzt wird.

Dieses kann sowohl zeitliche Komponenten (15 Sek. Bis 100.000 Datensätzen gelesen sind und weitergearbeitet werden kann) als auch Stabilitätskritieren (selbst 1.000.000 Datensätze darf das System nicht abstürzen), sowie einfach fachliche Anforderungen wie beim Beispiel der DHL-Anbindung haben alle definierten Anwendungsfälle ohne Probleme zu funktionieren (z.B. Mehrpaketsendung per Nachnahme mit Zollinhaltserklärung in ein Drittland).

Aufgrund dieser Abstimmung und den Akzeptanzkriterien ergeben sich die Fragen und Antworten zu Auswirkungsanalyse. Dort stellen wir uns die Fragen, was muss alles berücksichtigt werden, damit in Ihre Konfiguration die einzelnen Prozesse sauber in einander greifen, und was wir hier ggf. an Wechselwirkungen berücksichtigen müssen.

  1. Welche Daten werden wie verändert?
  2. Welche vorausgegangenen Prozesse müssen verändert werden?
  3. Welche nachgelagerten Prozesse müsse dafür angepasst werden?
  4.  Müssen bestehende Daten aufgrund der Anpassung geändert werden?

Zu 1) Wir prüfen, welche Daten wie verändert werden aufgrund dieser Tätigkeiten, im vergleich zu dem wie Sie evtl. vorher im System verarbeitet wurden.

Zu 2) Dieser in diesem Arbeitspaket dargestellt Prozess benötigt eine gewisse Datenbasis, damit dieser korrekt durchlaufen werden kann. Werden diese nun notwendigen Daten durch alle vorgegangen Prozesse korrekt erzeugt, damit dieser Prozess ohne Probleme funktioniert, oder müssen weiter „vorne im System“ auch noch Anpassungen vorgenommen werden. Unsere Spezialisten prüfen dieses im Vorfeld, ob alle notwendigen Datenbankfelder entsprechend gefüllt sind.

Zu 3) Ebenso prüfen wir die darauf folgenden Prozesse, ob durch dieses Arbeitspaket im späteren Handling Probleme auftreten können, da Daten z. B. durch eine Schnittstelle unvollständig befüllt werden, was dann später im System bei einem anderen Prozess aufgrund unzureichender Daten zu Fehlern führen würde.

Zu 4) Sind bereits Daten im System, welche aufgrund einer neuen Funktion überarbeitet werden müssten, stimmen wir diese mit Ihnen ab, wie diese Daten modifiziert werden können und/oder sollen.

Erst jetzt kann Ihnen realistisch der Aufwand so abgeschätzt werden, der sich auch tatsächlich in dem Rahmen bewegen wird, der durch die nachfolgende Programmierung, Dokumentation und Schulung für diesen Arbeitsschritt für Ihre Individuelle Anforderung entstehen wird.

Hier erfolgt das tatsächliche „Do“, also die Programmierung/Konfiguration der tatsächlichen Arbeit an sich.

Ob im ERP-System, in der Archiv-Lösung oder bei einem Cloud-Infrastruktur-Projekt stellt dieses immer das Herzstück einer Karte/Arbeitspaketes dar.

Nachdem die Arbeiten durch den Techniker umgesetzt wurden, werden durch uns alle Prüfungen entlang der vorher mit Ihnen festgelegten Akzeptanzkriterien geprüft und ggf. Daten entsprechen der Auswirkungsanalyse überarbeitet.

Wenn wir selbst in der Programmierung keine Fehler mehr finden konnten und alle Arbeitsabläufe wiie zu Beginn besprochen funktionieren, erhalten Sie von uns eine Einweisung in diesen Teilbereich der Software, mit dem Ziel, dass Sie dieses dann selbständig bedienen und ggf. als ProductOwner/KeyUser auch Ihre Kollegen schulen können.

Die Prüfung obliegt Ihnen, in welcher Sie alle Sachverhalte gegenchecken und ggf. nochmals auf uns zukommen, indem Sie die nicht gewünschte Funktionsweise beschreiben und uns damit kontaktieren, damit wir diese Anpassung, Erweiterung oder Fehlerbehebung für Sie umsetzen können.

Aufgrund des von Ihnen abgenommenen Funktionsstandes wird dann von der Anpassung eine Dokumentation erstellt. Je nach Umfang der Arbeiten wird Ihnen eine Vorab-Version der Doku auch im Zuge der Schulung bereits zur Verfügung gestellt. Sollten sich im Zuge der Prüfung Anpassungen ergeben, werden natürlich auch die Schulungsunterlagen aktualisiert.

Im Zuge der Dokumentation prüft nun ein zweiter technischer Consultant die Dokumentation und bespricht dieses intern mit dem Programmierer, welcher die Arbeiten umgesetzt hat. Dieses führt dazu, dass im Sinne eines 4-Augen-Prizips die Arbeiten anhand des Niedergeschriebenen intern nochmals gegengeprüft wird.

Die bisherigen Arbeits-Schritte wurden alle in Ihrem Testsystem durchgeführt. Erst jetzt, nachdem Sie und wir geprüft haben, es eine ordentliche Beschreibung zu dem Arbeitsprozess gibt, werden die  vorgenommen Anpassungen in das Live-System in den Produktiv-Betrieb übernommen und stehen von nun an für Ihre Mitarbeiter zu Verfügung.

Oft ist es Im Zuge der Live-Schaltung notwendig, dass direkt dazu bestehende Datensätze bearbeitet werden müssen. Dieser Arbeitsschritt ist sicherlich nicht bei allen Arbeiten notwendig, spielt aber oft eine elementare Rolle, damit die eingesetzt Programmierung korrekt läuft. Bei der DHL-Anbindung, die z. B. Aufgrund der Artikelabmessungen Sperrgut erkennen soll (wurde dann in den Akzeptanzkriterien definiert), müsste die Information auch in den Artikeldaten hinterlegt werden, damit diese Programmierung korrekt arbeiten kann. Ihre Lageristen haben dieses Informationen inzwischen in einer Excel-Liste gepflegt welche wir hier mit in das System importieren.

Im Nachgang werden Sie von uns kontaktiert damit wir zeitnah Ihr geschätztes Feedback erhalten, wie Sie die Umsetzung dieses Arbeitspaketes bzw. dieses Sprints empfunden haben, und wie wir noch besser werden können. Wir freuen uns hier über einen offenen Dialog und konstruktive Kritik.

Machen Sie sich selber ein Bild davon. Probieren Sie Scrum Board gleich aus!