Allgemeines
AMANA implementiert das GlobalTaxCenter mit Hilfe von Scrum. "Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren." (Zitat aus dem Scrum Guide, deutsche Übersetzung aus dem November 2020) Es ist somit eine Methode für agile Softwareentwicklung und agiles Projektmanagement.
Die aus unserem Entwicklungsprozess resultierenden GTC-Versionen sind in der folgenden Grafik veranschaulicht.
Hauptversionen und Stabilisierungen
Dreimal im Jahr stellen wir unseren Kunden eine Hauptversion zur Verfügung (R1, R2, R3). Das R1 wird im späten Frühjahr veröffentlicht und ist vor allem für unsere Tax Return-Kunden von Interesse, da darin die neuesten Entwicklungen für die Steuererklärung enthalten sind. Das R2 legt in der Regel den Fokus auf Integrations- und Jahresabschlussthemen. Es wird im Herbst veröffentlicht. Das R3 stellt unseren Tax Return-Kunden zum Jahreswechsel die neue KapESt-Anmeldung zur Verfügung.
Für die Hauptversionen pflegen wir jeweils einen Stabilisierungsbranch über den gesamten Supportzeitraum hinweg. Sofern relevante Fehlerbehebungen oder andere notwendige Anpassungen (z.B. Corona-Hilfepaket) in der Stabilisierungsversion vorgenommen wurden, erstellen wir circa alle 3 Wochen eine neue Bugfix-Version. Die Release Notes, die über die Änderungen informieren, können aus dem GTC selbst oder dem Handbuch aufgerufen werden. Die jeweilige Version kann bei Bedarf durch unsere Kunden angefordert und installiert werden. Es erfolgt keine automatische Bereitstellung einer neuen Bugfix-Version.
Fortlaufende Entwicklungen
Neue Funktionen und Anforderungsänderungen (Change Requests) implementieren wir in der Regel im Hauptentwicklungszweig. Dieser ist letztendlich auch die Basis für die Hauptversionen. Unser Scrum-Entwicklungszyklus (=Sprintlänge) beträgt zur Zeit drei Wochen. Nach diesen 3 Wochen erstellen wir jeweils eine Minor-Version aus dem Hauptentwicklungszweig.
Drei Wochen nach der Version R1 (21.00.00) kommen zwei neue Versionen: Version 21.01.00, in welcher Bugfixes und neue Features enthalten sind, sowie die Version 21.00.01, in welcher nur die Funktionen aus der R1-Version und Bugfixes enthalten sind. Dies zieht sich bis zum Release der Version R2 (21.06.00) in diesem Rhythmus hin. In dieser neuen Hauptversion sind dann alle Bugfixes des R1-Stabilisierungs-Branches, als auch die neuen Funktionen des Hauptentwicklungszweigs enthalten. Der Weg zu den nächsten Hauptversionen verläuft analog.
Alte Hauptversionen (im Beispiel 20.11.xx) werden bis zum Supportende ebenfalls mit Bugfixes versorgt, sofern nötig.
Beispiel:
In der Grafik kommt im ersten Sprint nach der Hauptversion "Bugticket #001" hinzu. Dieser Bugfix steht in beiden Versionen 21.01.00 und 21.00.01 zur Verfügung. Im kommenden Sprint kommt ein neues "Feature #002" hinzu. Da neue Funktionen nur im Hauptentwicklungszweig inkludiert werden, steht es nur in Version 21.02.00 zur Verfügung. Im wiederum nächsten Sprint kommt das "Bugticket #003" hinzu. Dieses hat ebenfalls Relevanz für die letzte Version 20.11.03. Aus diesem Grund wird hier neben den Versionen 21.03.00 und 21.00.03 eine neue Version 20.11.04 mit dem Bugfix bereitgestellt.
Hinweis zu den Minor-Versionen
Beachten Sie bitte, dass für die Minor-Versionen keine Stabilisierung-Branches gepflegt werden. Sollten Sie eine Minor-Version einsetzen und feststellen, dass sich das GTC nicht wie gewünscht verhält, besteht nur die Möglichkeit auf die nächste Minor- oder Hauptversion zu wechseln.
Berechnungsgrundlagen und Patches
Die Berechnungsgrundlage (BRG) wird immer dann verwendet, wenn ein Bugfix oder ein neues Feature die Berechnungen des GTC verändert. In diesem Fall möchte der Nutzer natürlich nicht, dass eine alte, ggf. bereits geschlossene Periode eine neue Berechnung erhält. Die BRG lässt sich unter "Letzte Berechnungsgrundlage" und unter "aktivierte Patches" in den Periodenstammdaten einstellen. Eine höhere eingestellte "Letzte Berechnungsgrundlage" enthält auch immer die Berechnungen von niedrigeren BRGs. Im Feld aktivierte Patches lassen sich einzelne BRGs zu der eingestellten Berechnungsgrundlage dazuschalten.
Beispiel:
In der Grafik kommt in der Version 20.01.00 und 20.00.01 ein Bugfix mit der BRG 1300078 hinzu. Die neueste Berechnungsgrundlage der Minor Version 20.01.00 ist nun 1300078 und der Stable Version 20.00.01 weiterhin 130000. Es lässt sich jedoch in der 20.00.01 die BRG 130078 zuschalten.