In 7 Schritten zur Software für Qualitätsmanagement

Neue Ideen für eine Standardsoftware erwachsen natürlich nicht aus dem Nichts. Es gibt bereits eine Grundlage und ein hohes Maß an Expertise, die mit neuen, spannenden Ideen erweitert werden können. Bei der Babtec ist die Zentrale dieser Ideenentwicklung das Produktmanagement. Durch eine intensive Marktbeobachtung wird der Bedarf der Anwender immer wieder neu ermittelt. Dabei liegt ein besonderes Augenmerk auf der Entstehung oder Veränderungen von Normen, auf die in der Produktion umgehend reagiert werden muss. Aber auch das Auftreten neuer Fragestellungen und Herausforderungen innerhalb der industriellen Produktion kann zu neuen Lösungsideen inspirieren. Ein besonders anwenderorientierter Weg zur Ideenfindung sind beim Support eingereichte Änderungswünsche. Etwa fünfzig dieser Change Requests gehen jeden Monat ein. Sie werden hinsichtlich Bedarf und Umsetzbarkeit analysiert; wird eine gewünschte Änderung als relevant bewertet, so wird die Idee weiterverfolgt.

Die durch Marktbeobachtung oder Change Request inspirierte Idee legt der Produktmanager nun dem Portfolio Board vor, das sich aus drei Entscheidungsträgern zusammensetzt. Die Idee wird diskutiert und im Hinblick auf Unternehmens- und Produktstrategie analysiert. Gibt das Portfolio Board das „Go“, erstellt der entsprechende Produktmanager ein Konzept zur Produktidee. Neben Bedarfserläuterung und einem Konstruktionsentwurf werden hier auch betriebsökonomische Erwägungen dargelegt. Völlig neue Produkte werden am Ende der ersten Konzeptionsphase in einem PEP-Sheet abgebildet, das mit den Geschäftsführern der Babtec  besprochen wird. Diese entscheiden dann über die Umsetzung. Die Realisierung von Änderungen oder Weiterentwicklungen bestehender Software-Elemente wird im Team der Produktmanager beschlossen.

Nun beginnt die Phase der theoretischen Entwicklung. Der Produktmanager geht in die Tiefe des neuen Features, beschreibt genau, wie es aussehen und sich verhalten soll. Er wird dabei zum Anwalt des Kunden, indem er dessen Sicht einnimmt und sich fragt, was der Anwender bei der Benutzung erleben möchte. Schon in dieser Phase der Produktkonstruktion werden durch den Produkt- manager die Product Backlog Items, kurz PBI, erstellt. Die große Menge an zu verarbeitenden Informationen aus der Konstruktionsphase wird hier in kleinere Arbeitspakete für die Entwickler unterteilt. In jedem PBI wird die konkrete Zielsetzung desselben dargestellt und genau beschrieben, wie es sich bei allen geplanten Aktionen verhalten muss. Detailliert definierte Akzeptanzkriterien sind die Grundlage für die Qualitätssicherung während der Softwareentwicklung und die erfolgreiche Abnahme durch den Produktmanager. Ein neues Feature kann dabei eine Vielzahl an PBI enthalten. Diese PBI sind die Grundlage, um die Konstruktion des Produkts aus der Theorie in die Praxis zu bringen.

Die Zusammenarbeit zwischen Produktmanager und Entwicklungsteam ist in der Übergangsphase von der Theorie in die Praxis essentiell. Daher findet zu jedem PBI ein Meeting statt, im Zuge dessen zusätzliche Erläuterungen erfolgen und offene Fragen geklärt werden. Denn nur, wenn der Software-Entwickler die Ziele, Beschreibungen und Wünsche des Produktmanagers genau versteht und sich zu eigen macht, kann er das Produkt ideal programmieren. Gleiches gilt für die Qualitätssicherung, weshalb auch der spätere Tester bereits zu diesem Zeitpunkt involviert wird. Nach dem Austausch zu dem jeweiligen PBI gibt das Entwicklungsteam eine Schätzung über die benötigte Programmier- und Testzeit ab, die ins Item aufgenommen wird. Dann erst wird das PBI offiziell in das Product Backlog der Entwickler eingepflegt.

„PBI“ und „Product Backlog“ sind Begriffe aus der agilen Ent- wicklungsmethode SCRUM, nach der die Software BabtecQ ebenso wie die Cloud-Services im BabtecQube programmiert werden. Ziel dieser Methode ist, stets flexibel den Kurs anpassen zu können und sich immer wieder selbst in seinem Tun zu hinterfragen. Aus den PBI entsteht im Product Backlog eine Aufgabenliste für die Entwickler. Programmiert wird in zweiwöchigen Sprints, für die sich die Entwickler ihre PBI aus dem Product Backlog in ihr jeweiliges Sprint Backlog ziehen. Jeden Tag gibt es ein Stand-up-Meeting am SCRUM-Board. Hier reflektiert jeder Entwickler den Fortschritt des vergangenen Tages und erforderliche Korrekturen können unmittelbar erfolgen. Weiterer wichtiger Bestandteil des Entwicklungsprozesses ist das Code-Review, bei dem im Vier-Augen-Prinzip von einem anderen Entwickler das Codierte überprüft wird. Im Nighly Built schließlich wird der Quellcode von Software und Cloud-Lösung jede Nacht neu zusammengebaut und neue Items werden implementiert.

Fünf Tester sind für die Qualitätssicherung von neu codierten Items verantwortlich. Auf der Basis der Akzeptanzkriterien wird ein Test-Case durchgeführt. Bei einem solchen Test-Case wird eine beispielhafte Anwendung entsprechend einer vorher formulierten Test-Beschreibung durchgeführt. Das Item muss sich während des Tests exakt den Akzeptanzkriterien entsprechend verhalten. Der Test-Case wird präzise dokumentiert; kommt es zu Abweichungen, geht das Item zurück an den Entwickler. Dieser muss nachbessern und auch den Prozess des Code-Review erneut durchlaufen, bevor das Item wieder zum Software-Tester gelangt. Erst wenn der Tester sein OK gibt, wird das Item an den verantwortlichen Produktmanager übergeben. Dieser überprüft das Item noch einmal dahingehend, ob es den textlich fixierten Vorstellungen des Produktmanagements entspricht. Bei positiver Bilanz endet hier der Sprint des Items mit einer Abnahme.

Natürlich entsteht in einem zweiwöchigen Sprint nicht nur ein Item, sondern es wird zeitgleich an mehreren Features mit vielen einzelnen PBI gearbeitet. Veröffentlicht werden die neuen Software- und Cloud-Features jeweils halbjährlich in einem Major Release. Diesen großen Meilensteinen im Jahr geht immer ein sogenannter Code Freeze voraus. Ab diesem Zeitpunkt wird der Quellcode „eingefroren“; Änderungen sind dann nicht mehr vorgesehen. Es werden Tests zum Verhalten der neuen Features innerhalb der gesamten Software oder Cloud-Lösung durchgeführt und die schriftlichen Dokumentationen für den Anwender vervollständigt. Und dann ist es endlich soweit. Der Leiter des Produktmanagements erteilt die Release-Freigabe und eine neue Version der Lösung wird dem Anwender als Update zur Verfügung gestellt, gefolgt von optimierenden Service-Packs im Sechs-Wochen-Rhythmus.