Die Organisation muss Steuerungsmaßnahmen für den Entwicklungsprozess anwenden, um sicherzustellen, dass die zu erzielenden Ergebnisse definiert sind, Überprüfungen durchgeführt werden [..], jegliche notwendigen Maßnahmen zu Problemen eingeleitet werden, die während der Überprüfungen, oder Verifizierungs- und Validierungstätigkeiten bestimmt wurden und dokumentierte Informationen über diese Tätigkeiten aufbewahrt werden.
ISO 9001, Kapitel 8.3

Steuerungsmaßnahmen für den Entwicklungsprozess, wie sie in der Qualitätsmanagementnorm ISO 9001 (2015) von der Organisation gefordert werden, sind integraler Teil der agilen Prozessmodelle. Anforderungen des Kunden werden als Storys in einem Backlog in Jira erfasst, priorisiert und in Sprints umgesetzt. Jede Story beschreibt eine Entwicklungsaufgabe. Mit den Akzeptanzkriterien definiert der Produktverantwortliche, wann eine Story aus seiner Sicht fertig ist. Das Team kann zusätzlich eine selbst bestimmte zusätzliches Regelwerk für die erfolgreiche Fertigstellung jeder Entwicklungsaufgabe festlegen.

In unserem Entwicklungsprozess mit Gitlab spiegelt sich die Struktur des Backlogs in den Merge-Requests wieder. Abhängig vom Architekturstil und der Projektorganisation führt die Umsetzung einer Story zu einem oder mehreren Merge-Requests. Story in Jira und Merge-Request in Gitlab sind miteinander verknüpft.

Ein Merge-Request ist außerdem eine unverzichtbare Qualitätskontrolle (englisch: quality gate) für Code. Ein Entwickler schließt seine Änderungen ab. Er ist aus seiner Sicht fertig. Jetzt folgen eine Reihe von Prüfungen, die aus dem Regelwerk für die erfolgreiche Fertigstellung (englisch: definition of done) stammen.

Zuerst wird mit einem Build-Tool geprüft, ob der Code prinzipiell in Ordnung ist, d.h. fehlerfrei kompiliert und alle Modultests (englisch: unit tests) erfolgreich ausführbar sind. Wichtig ist, dass diese Prüfung allein auf dem Code gemacht wird, der eingecheckt ist. So wird auch ausgeschlossen, dass Code im Git fehlt.

In einem weiteren Schritt wird die Code-Qualität anhand von Metriken überprüft. Mit JaCoCo prüfen wir die Code-Coverage der Unittests. Ein übliches Ziel ist ein Wert von 80%. Mit SonarQube visualisieren wir neben der Code-Coverage noch viele weitere Metriken, die einen Hinweis auf die Qualität des Codes geben: Anzahl offener Defekte, Angreifbarkeit (englisch: vulnerability) und technische Schulden (englisch: code smells).

Weiterlesen auf gitlab.com

Eine bewährte Praxis ist die Durchführung von Code-Reviews. Änderungen am Code werden von mindestens einem weiteren Teammitglied überprüft. Ein wichtiges Ziel dieser Maßnahme ist der Wissensaustausch. Der Reviewer hat einerseits die Chance, von der Implementierung des Entwicklers zu lernen. Andererseits kann ein Reviewer dem Entwickler Hinweise auf mögliche Verbesserungen oder potentielle Fehler im Code geben. Ein Reviewer hat außerdem ein Auge auf die im Team vereinbarten Programmierregeln.

Die erfolgreiche Durchführung eines Code-Reviews wird durch das Klicken auf “Approve” bestätigt. Der Reviewer kann zusätzlich noch eine Bewertung abgeben. Ein Klick auf :thumbs up: bedeutet, dass der Code in Ordnung ist. Mit einem Klick auf :thumbs down: kann ein Code-Reviewer das Feedback geben, dass der Code zwar formal korrekt ist, aber nach seiner Einschätzung nicht optimal ist.

Weiterlesen auf gitlab.com

Bei der Durchführung eines Code-Reviews kann es passieren, dass der Reviewer eine Frage hat, die er gerne dem Entwickler zur Diskussion stellen möchte. Die Diskussion wird für alle Teammitglieder sichtbar geführt. Jeder kann seine Meinung äußern.

Weiterlesen auf gitlab.com

Mit dem konsequenten Einsatz der genannten Funktionen von Gitlab werden die Anforderungen der ISO 9001 erfüllt.

Die ISO 9001 fordert erstens Steuerungsmaßnahmen für den Entwicklungsprozess,  um sicherzustellen, dass die zu erzielenden Ergebnisse definiert sind. Eine Entwicklungsaufgabe wird in einem agilen Prozessmodell durch eine Story im Backlog beschrieben. Die Anforderung der ISO 9001 erfüllen wir durch die Formulierung von Akzeptanzkriterien. Das ist Erwartungsmanagement im kleinen Stil.

Die ISO 9001 fordert zweitens Steuerungsmaßnahmen für den Entwicklungsprozess,  um sicherzustellen, dass Überprüfungen durchgeführt werden. Jede Änderung am Code kann erst kundenwirksam werden, wenn der Merge-Request abgeschlossen wurde. Damit ist sichergestellt, dass

  • alle automatisch ausführbaren Prüfungen positiv verlaufen sind.
  • mindestens ein weiteres Teammitglied sich den Code kritisch angesehen hat und Feedback zur Code-Qualität gegeben hat.
  • alle offenen Diskussionen beendet wurden.

Akzeptanzkriterien sind in der Regel sehr gut geeignet für die Entwicklung von Testfällen, die beispielsweise im Review vom Team genutzt werden, um die Erfüllung der Akzeptanzkriterien bei der Präsentation der Story zu zeigen.

Die ISO 9001 fordert drittens Steuerungsmaßnahmen für den Entwicklungsprozess, um sicherzustellen, dass dokumentierte Informationen über diese Tätigkeiten aufbewahrt werden. Ein Merge-Request ist dokumentierte Information. Er beinhaltet alle Änderungen und Diskussionen und kann auch angesehen werden, wenn die Entwicklungsaufgabe längst abgeschlossen wurde. Die Verwendung von Merge-Requests kann mit dem Rollenkonzept von Gitlab sogar erzwungen werden.